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 ?
Michaël
>
> ..ede
>
>
> On 21.04.2013 15:53, Michaël Michaud wrote:
>> Hi,
>>
>> In JTS revision 637, Martin took care of the successive byte order
>>
>> "Fixed WKBReader to handle successive geometrys with different endianness"
>> http://jts-topo-suite.svn.sourceforge.net/viewvc/jts-topo-suite/trunk/jts/java/src/com/vividsolutions/jts/io/WKBReader.java?r1=57&r2=637
>>
>> Maybe there is also something with SRID handling, but I don't think so as it
>> would make no difference between simple and multiple geometries.
>>
>> Michaël
>>
>>> 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, a
>>> wkbtype (6), a number of polygons, then an array of polygons, *each polygon
>>> 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 not starts
>>> with geometry type. The example with the polygon made of two rings is
>>> another thing as it is not a multi-geometry.
>>> In spatialite, after the number of entities (polygons) in a collection
>>> comes a byte mark (hex=69), the geometry type, the geometry class
>>> specific...
>>>
>>> As a result, the byte number should be the same, and the only difference is
>>> that each simple geometry starts with a byte order in wkb and with 0x69 in
>>> spatialite, which could explain that JTS 1.12 did read spatialite geometry
>>> if it just ignored this particular byte which is not very useful (one must
>>> be particularly vicious to change byete order inside 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
>>
>>
>> ------------------------------------------------------------------------------
>> 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
