Hey guys, I have been lurking on this thread... I agree that it would be bizarre to switch endianess in the middle of a WKB blob. I suspect that the standard did not really have the intent of supporting this, they just provided multiple endian code items as a side-effect of reusing the definition of the component WKB representations.
In fact, now that I reread it, the JTS bug report that caused the change in JTS 1.13 (http://sourceforge.net/tracker/?func=detail&aid=3543534&group_id=128875&atid=713120) wasn't about supporting internal endian change, but about the fact that the JTS 1.12 WKBReader wouldn't change endianess *ever*, even between different geometries. This of course is a definite bug. But the fix went a little further than necessary, perhaps. I'm not keen on explicitly committing to support SpatialLite BLOB format in JTS, since that's just a bunch more to test. But how about this for a solution? The WKBReader can be changed to only switch endianess when the code is one of the two specified in the standard (0 = BigEndian, 1 = LittleEndian). If any other code is read then the endianess will be left unchanged. That should handle the SpatialLite BLOB format, right? And it avoids any explicit dependency on magic numbers from SpatialLite. And it still allows switching endianness mid-WKB, as per the standard, should anyone be so perverse as to do that. This is pretty much Michael's suggestion, but even simpler. I won't bother throwing an error message for now. There is an unused provision for a "strict" flag in WKBReader - perhaps at some point that can be exposed and in that case an error could be thrown. In general though it seems better to be lenient when reading. Martin On 4/21/2013 8:27 AM, edgar.sol...@web.de wrote: > On 21.04.2013 17:13, Michaël Michaud wrote: >> Hi >>> well - the SRID code is the only thing that seems to be added between JTS >>> 1.7 and 1.8. >>> >>> some more observations: >>> >>> what Larry's DBQuery actually does is stripping MBR header and end marker >>> from the spatiallite blob and handing it over to JTS. as Michael correctly >>> discovered is the endianess byte used differently in there, so what >>> actually would need to be done is the WKB would have to be postprocessed >>> before giving it to JTS. but before we try that: >>> >>> i had a look at >>> >>> https://sourceforge.net/apps/mediawiki/jump-pilot/index.php?title=OpenJUMP_with_SpatialLite#Using_SpatiaLite_with_Spatialite_Reader_Plugin >>> sources and it seems to bring with a full blown BLOB parser. >>> >>> Jukka, Michael: could you check if this plugin suffers from the same >>> problem? i would guess not. if not, we could reuse the parser, single it >>> out as a jar etc. >> I recently patched Spatialite Plugin after Jukka'request, but it suffers >> from the same problem (parser just read the first few bytes then use JTS >> WKBReader). >> >> I had a look in JTS WKBParser (which is short and easy to read). >> >> The key part is in readGeometry(), lines >> int byteOrder = byteOrderWKB == WKBConstants.wkbNDR ? >> ByteOrderValues.LITTLE_ENDIAN : ByteOrderValues.BIG_ENDIAN; >> dis.setOrder(byteOrder); >> >> Unfortunately, this method is private. >> We could suggest to Martin to change it to >> >> switch(byteOrderWKB) { >> case WKBConstants.wkbNDR: >> dis.setOrder(ByteOrderValues.LITTLE_ENDIAN); >> break; >> case WKBConstants.wkbXDR:dis.setOrder(ByteOrderValues.BIG_ENDIAN); >> break; >> case 0x69 : // keep previous byte order, this is a spatialite >> geometry >> break; >> default : >> throw Exception("This case is neither a pure wkb neither a >> spatialite wkb"); >> } >> >> Seems that it could tolerate spatialite geometry and be as strict as it >> is now for wkb. >> >> What do you think ? >> > oh. i see, the reader switches to big endian because of the 0x69 value.. > can't be good ;) > wrt. to the patch. > it works around the standard. having a switch case is good, to find corrupt > datasets. > adding spatialite specifics is a mixup of standards. maybe a class that > extends JTS's WKBParser implementing the specifics (cutting header,end, 0x69) > would be a cleaner solutions. > > but as you say: up to Martin. we can always extend WKBParser ourselfs if he > doesn't like it upstream. > > ..ede > ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
