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
