Yep, I'll make the change shortly.
On 4/21/2013 8:22 PM, Larry Reeder wrote:
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
<mailto: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
<mailto:edgar.sol...@web.de> wrote:
> On 21.04.2013 17 <tel:21.04.2013%2017>: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
<mailto: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
------------------------------------------------------------------------------
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
