Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Error in geometry decoding: ArrayIndexOutOfBoundsException #183

Open
springmeyer opened this issue Jun 21, 2024 · 1 comment
Open

Error in geometry decoding: ArrayIndexOutOfBoundsException #183

springmeyer opened this issue Jun 21, 2024 · 1 comment
Labels
bug Something isn't working

Comments

@springmeyer
Copy link
Collaborator

In the non-advanced path, we hit this error with both the vectorized and non-vectorized decoders:

    java.lang.ArrayIndexOutOfBoundsException: Index -5 out of bounds for length 4
        at com.mlt.metadata.stream.StreamMetadata.decode(StreamMetadata.java:66)
        at com.mlt.metadata.stream.StreamMetadataDecoder.decode(StreamMetadataDecoder.java:8)
        at com.mlt.decoder.GeometryDecoder.decodeGeometryColumn(GeometryDecoder.java:28)
        at com.mlt.decoder.MltDecoder.decodeMlTile(MltDecoder.java:77)
        at com.mlt.decoder.MltDecoderTest.testTile(MltDecoderTest.java:200)
        at com.mlt.decoder.MltDecoderTest.decodeOMTTiles2(MltDecoderTest.java:146)

Currently seeing this with 3 OMT test fixtures:

  • "13_4265_5467"
  • "14_8298_10748"
  • "14_8299_10748"

A replication with the CLI:

› java -jar build/libs/encode.jar -mvt ../test/fixtures/omt/13_4265_5467.mvt -decode -vectorized
java.lang.ArrayIndexOutOfBoundsException: Index -5 out of bounds for length 4
	at com.mlt.metadata.stream.StreamMetadata.decode(StreamMetadata.java:66)
	at com.mlt.metadata.stream.StreamMetadataDecoder.decode(StreamMetadataDecoder.java:8)
	at com.mlt.decoder.vectorized.VectorizedGeometryDecoder.decodeToRandomAccessFormat(VectorizedGeometryDecoder.java:100)
	at com.mlt.decoder.MltDecoder.decodeMlTileVectorized(MltDecoder.java:161)
	at com.mlt.tools.Encode.main(Encode.java:254)
springmeyer added a commit to springmeyer/maplibre-tile-spec that referenced this issue Jun 21, 2024
@springmeyer
Add a reference to maplibre#183
06b2cf4
@springmeyer springmeyer added the bug Something isn't working label Jun 21, 2024
@springmeyer springmeyer mentioned this issue Jun 21, 2024
Merged
2 tasks
@springmeyer
Copy link
Collaborator Author

@mactrem of the errors I see in the new test coverage this feels like the most common and highest priority. Let me know if you either have an idea of what might be the problem or have time to take a look?

springmeyer added a commit that referenced this issue Jun 25, 2024
@springmeyer
Test additional code paths in java decoder (#180)
b3edfa4 
Currently we do not fully test all these combinations:

 - Vectorized path + advanced encodings
 - Vectorized path + without advanced encodings
 - Non-Vectorized path + advanced encodings
 - Non-Vectorized path + without advanced encodings
 
This PR starts testing all those paths.

The code coverage changes are:

 - **overall:** `36%`to `45%`
 - **mlt.converter:** `64%` to `85%`
 - **mlt.decoder:** `55%` to `71%`

In addition this PR includes:

- Some refactoring in TestUtils.java to share more code between
vectorized and non-vectorized
- Improvements to TestUtils.java around geometry comparisons (refs #178)
 - Improvements to TestUtils.java around property comparisons

Finally, this PR does not attempt to solve any bugs. Rather it finds,
isolates, and writes tests harnesses to capture them in code. Once bugs
are solved in the future it should be easy to update the tests
accordingly.

TODO:
- [x] ~This PR uncovered a number of bugs that do not have open issues
and did not have tests that hit them until now. So I need to create
following issues to capture fixing these.~
     - Added:
        - #181
        - #182 
        - #183 
        - #184
        - #185
        - #186
- [ ] Property nesting in MLT makes comparison to MVT difficult so I
disabled it in this test refactor because comparison to MVT is what the
decoder tests rely on. My sense is that standalone unit tests of nesting
might be more appropriate than including nesting in the decoder tests.
Do others agree?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@springmeyer