Re: [JPP-Devel] Spatialite multigeometry trouble and JTS v. 1.13

Michaël Michaud Sun, 21 Apr 2013 06:46:49 -0700

Hi Ede,

ok, just dug some more into "OpenGIS Simple Features Specification for SQL"
http://portal.opengeospatial.org/files/?artifact_id=829


and as far as i read on page 3-24 and later, a little bit unclear, but it seems 
to me that endianess is not repeated (see the Polygon example with /two/ rings) 
but left away. for multi geometries the standard expects the sub geometries 
first value is the wkb type.

My interpretation of p 3-26 is that MultiPolygon has a byte order, awkbtype (6), a number of polygons, then an array of polygons, *eachpolygon having in turn a byte order*, a wkbtype (3), a number of ring...So yes, I think the byte order is repeated and sub-geometries do notstarts with geometry type. The example with the polygon made of tworings is another thing as it is not a multi-geometry.In spatialite, after the number of entities (polygons) in a collectioncomes a byte mark (hex=69), the geometry type, the geometry classspecific...

As a result, the byte number should be the same, and the only differenceis that each simple geometry starts with a byte order in wkb and with0x69 in spatialite, which could explain that JTS 1.12 did readspatialite geometry if it just ignored this particular byte which is notvery useful (one must be particularly vicious to change byete orderinside a single multigeometry object )


Michaël


all of this seems to be implemented in spatiallite as described below. so are 
we totally sure that JTS is not buggy in this regard? after all it reads like 
WKB analogue to WKT is supposed to be the cross platform implemented 
identically everywhere standard.

..ede

PS: i'd really like to compare

On 21.04.2013 14:14, edgar.sol...@web.de wrote:

regarding your interpretation below i just found the following

http://www.gaia-gis.it/spatialite-2.1/SpatiaLite-manual.html#t3.2

which states:

"
The Well-Known Binary (WKB) representation for geometric values is defined by 
the OpenGIS specification.
"

and

"
Component representation is as follows:

     The byte order ...
     The WKB type is represented as a four-bytes unsigned integer ...
     SNIP
     Collection type geometries [MultiPoint, MultiLineString, MultiPolygon and 
GeometryCollections] value has:
         the number of entities, represented as a four-bytes unsigned integer.
         a corresponding array of Points, LineStrings or Polygons as needed
         *note that each elementary entity has to be prefixed by its own WKB 
type.*

"

both informations together suggest to me that
A) they claim to be standard conform
B) the mysterious bytevalue is in fact a WKB type representation for the 
following WKB

/additionally/

selecting geometries AsText() should result in WKTs, as far as i read page 2-29 
of
http://portal.opengeospatial.org/files/?artifact_id=829

maybe this helps.. 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

------------------------------------------------------------------------------
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

Re: [JPP-Devel] Spatialite multigeometry trouble and JTS v. 1.13

Reply via email to