NullPointerException when reading geometry about simple-features-wkb-java

[bosborn]

You can give these changes a shot. This test uses your WKB hex String.

wkb.zip

[bosborn]

I'll go ahead and release a version 1.0.6 of this library for this issue and #12. After that you can pull it directly from the central repository. I can close this issue after the release.

Further releases will be a part of a simple features refactor which will require some minor refactors with package names.

• simple-features-java
• simple-features-proj-java
• simple-features-geojson-java
• geopackage-wkb-java (this library) will be renamed to simple-features-wkb-java

[bosborn]

@GrayCygnus

1.0.6 has been released

• https://github.com/ngageoint/geopackage-wkb-java/releases/tag/1.0.6
• http://search.maven.org/#artifactdetails%7Cmil.nga%7Cwkb%7C1.0.6%7Cjar

[bosborn]

Thanks, I had forgot... updated now.

[GrayCygnus]

Further Debugging and tracing I found:

• byteOrderValue = reader.readByte() has a value of 48
• This causes byteOrder to become LITTLE_ENDIAN and set such to the reader (despite the original being BIG_ENDIAN)
• geometryTypeWkbCode = reader.readInt() is 808857649
• This results in a geometryTypeCode of 649 (the enum only has up to 14!). The comments indicate this line should return the "last 2 digits" but we can see it returns 3
• This also results in geometryTypeMode of 808857. This line says it returns the "first digit", but we can see it returned 6 digits instead.
• Because of all of this, the call to GeometryType.fromCode() results in null and then the switch fails with the Null pointer exception.

Hope this helps find the problem (something to do with the "forced" conversion to Little Endian perhaps?)

Cheers

[bosborn]

Thanks for the detailed information. The WKB you provided is in hex. Based upon the first value of 48 you mentioned, it seems like you may be using the hex String bytes.
[48, 49, 48, 54, 48, ...
If this is the case, the first step would be to convert the hex to bytes.

After converting the hex to bytes, you should see something like this:
[1, 6, 0, 0, -128, ...

I assumed this would be the end of the issue you are seeing, but I ran into another problem. The first byte of 1 indicates that the geometry is indeed stored as Little Endian. The next 4 bytes is where we run into an issue. Those 4 bytes should be an unsigned integer representing the geometry type and options (z, m). The little endian bytes [6, 0, 0, -128] result in an unsigned integer of 2147483654. The last byte of -128 for the multi polygon and the embedded polygon is causing problems. The unsigned integer should be a value in the ranges 0-17, 1000-1017, 2000-2017, 3000-3017. When I zero out the -128 values for the multi polygon and polygon (the first 2 instances in the byte array), the geometry parses correctly. For a multipolygon, expected combinations of the first 5 bytes include:

• 6 - Big Endian: [0, 0, 0, 0, 6], Little Endian: [1, 6, 0, 0, 0]
• 1006 w/ Z - Big Endian: [0, 0, 0, 3, -18], Little Endian: [1, -18, 3, 0, 0]
• 2006 w/ M - Big Endian: [0, 0, 0, 7, -42], Little Endian: [1, -42, 7, 0, 0]
• 3006 w/ Z & M - Big Endian: [0, 0, 0, 11, -66], Little Endian: [1, -66, 11, 0, 0]

Based upon what I can determine from the spec, the provided WKB is not valid. Did you generate the WKB or receive it from somewhere?

As a work around, we could bitwise the 4 byte unsigned integer to only view the lowest 16 bits. This would ignore the second two bytes (or first two for big endian) since no valid values should currently be using them.
unsigned_int & 0xfffff
I'm not sure if GeoServer and QGis are only evaluating the least 16 significant bits already in order to process that WKB.

[bosborn]

After looking at QGIS, it looks like the WKB is using a 2.5 geometry type. Point25D is 0x80000001, so MultiPolygon25D would be 0x80000006 resulting in the 2147483654 value I'm seeing.

We don't currently support the 2.5 geometries but probably could. If the geometry structures do not change, it would simply handle them as the base type objects and provide a method to check for 2.5. Are the 2.5 geometries defined in any available specs? They do not appear to be a part of any OGC standards.

[bosborn]

Found it:
Adam's 2.5 D Simple Features Proposal (OGC 99-402r2)

Dug up a copy through the OGC portal

[GrayCygnus]

Hey there, @bosborn thanks for your fast reply. I will take a look at the links you provided and inform here what I achieve.

Regarding your question, I generated that wkb previous to inserting it on my PostGIS DB. I used the command shp2psql with a .shp file directly to create such query. That command also did the conversion to wkb for the geometry field. I'll write back when I try your suggestions.

Cheers

[GrayCygnus]

@bosborn I included the .jar file you posted and it worked! Now the wkb is successfully read and the Geometry object is instantiated.

Thanks for your support :) I will now continue reading about this library to learn how to extract the coordinates of my polygons.

Seems to me that this issue is now solved (should I close it?). I suppose that in the meantime I should use the .jar you sent while these changes reach the main branch, right? And when they reach it update the dependency to use 1.0.6?

Thanks again for your help

[GrayCygnus]

Thanks @bosborn really appreciate it, already included it on my Gradle and tested it successfully.

As a side note, I see that the Javadocs API still refers to the 1.0.5 version in the title, in case this is something you wish to update as well (probably just the name and the refactorings you mentioned).

Happy coding :)