well spotted.. the devil is in the details! ..ede On 15.04.2013 08:44, Michaël Michaud 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 > <mailto: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 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 >
------------------------------------------------------------------------------ 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
