Great analysis, Michaël. Looks like the spatialite component of plugin
will need to do it's own WKB decoding instead of relying on the JTS
WkbReader, at least in part.
-lreeder
On Mon, Apr 15, 2013 at 12:44 AM, Michaël Michaud
<michael.mich...@free.fr>wrote:
> Hi,
>
> Just compared both strings to the spec,
>
> First string follows the WKB specification
> 01 endianess
> 06000000 MultiPolygon
> 02000000 Number of Polygons
> 01 endianess
> 03000000 Polygon
> 02000000 Two rings
> 04000000 Four points
> ...
>
> Second string follows the Spatialite specification
> http://www.gaia-gis.it/gaia-sins/BLOB-Geometry.html
> 01 endianess
> 06000000 MultiPolygon
> 02000000 Number of Polygons
> 69 Spatialite mark starting a new Geometry
> 03000000 Polygon
> 02000000 Two Rings
> 04000000 Four points
>
> In spatialite geometry description, endianess is not repeated for each
> component,
> instead, the 69 byte appears
> Probably the previous version of JTS could accomodate this because the byte
> order information is generally redundant, but a more strict parser will
> find
> a non authorized description for the Polygon as it does not start by the
> byte
> order.
>
> This means that the spatialite parser which just skipped the first bytes,
> then
> read the following byte stream as a wkb byte array with JTS must read each
> component as a Spatialite Geometry starting with 69.
>
> Michaël
>
>
>
> On Sun, Apr 14, 2013 at 3:39 PM, Rahkonen Jukka <jukka.rahko...@mmmtike.fi
> > wrote:
>
>> Hi,
>>
>> I made two tests:
>> 1) With PostGIS 2.1
>> select encode(ST_AsBinary(ST_GeomFromText('MULTIPOLYGON(((0 0, 10 20, 30
>> 40, 0 0), (1 1, 2 2, 3 3, 1 1)),
>> ((100 100, 110 110, 120 120, 100 100)))')), 'hex')
>> Query gives the same WKB that you used in JTS bug #3610843, that is
>>
>> "0106000000020000000103000000020000000400000000000000000000000000000000000000000000000000244000000000000034400000000000003e4000000000000044400000000000000000000000000000000004000000000000000000f03f000000000000f03f0000000000000040000000000000004000000000000008400000000000000840000000000000f03f000000000000f03f01030000000100000004000000000000000000594000000000000059400000000000805b400000000000805b400000000000005e400000000000005e4000000000000059400000000000005940"
>>
>> 2) With Spatialite
>> select
>> GeomFromWKB(x'0106000000020000006903000000020000000400000000000000000000000000000000000000000000000000244000000000000034400000000000003E4000000000000044400000000000000000000000000000000004000000000000000000F03F000000000000F03F0000000000000040000000000000004000000000000008400000000000000840000000000000F03F000000000000F03F69030000000100000004000000000000000000594000000000000059400000000000805B400000000000805B400000000000005E400000000000005E4000000000000059400000000000005940')
>> Query creates a multipolygon geometry.
>>
>>
> Jukka, these two WKB hex strings differ around the 20th character:
>
> 01060000000200000001030
> 01060000000200000069030
>
> The second one is the one I retrieved from spatialite. When I try to
> parse the second one with Postgis (1.5.3), I get an error:
>
> select
> ST_GeomFromWkb(decode('0106000000020000006903000000020000000400000000000000000000000000000000000000000000000000244000000000000034400000000000003E4000000000000044400000000000000000000000000000000004000000000000000000F03F000000000000F03F0000000000000040000000000000004000000000000008400000000000000840000000000000F03F000000000000F03F69030000000100000004000000000000000000594000000000000059400000000000805B400000000000805B400000000000005E400000000000005E4000000000000059400000000000005940',
> 'hex'));
> ERROR: invalid WKB type
> HINT: You must specify a valid OGC WKT geometry type such as POINT,
> LINESTRING or POLYGON
>
> I haven't manually verified the WKB, but it might be that spatialite is
> generating an invalid WKB, and JTS 1.12 was more forgiving about it than
> 1.13 is.
>
> -lreeder
>
>
>
>
>> Therefore it looks like the WKB is ok. But I do not understand that if
>> PostGIS gives exactly the same WKB, how it is possible that OpenJUMP works
>> with PostGIS but not with Spatialite through DB Query plugin?
>>
>> -Jukka Rahkonen-
>>
>>
>>
>
>
> ------------------------------------------------------------------------------
> 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
> listJump-pilot-devel@lists.sourceforge.nethttps://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
