Martin, I agree that the JTS WKBReader shouldn't be hacked to support the
SpatialLite BLOB format or whatever else come along with a slightly
different interpretation of the standard, and this is a great compromise
solution. Is this change something we can expect in JTS 1.14?
Thanks............ lreeder
On Sun, Apr 21, 2013 at 10:19 AM, Martin Davis <mtncl...@telus.net> wrote:
> 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
>
------------------------------------------------------------------------------
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
