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