Hi, It looks that both Spatialite BLOB and GeoPackage BLOB in the sample database show code 00 00 00 06 for a 2D MultiPolygon but that does not tell anything yet. We should test geometries with Z and M with different WKB readers for knowing the state of interoperability. Based on the blog by Paul Ramsey the OGC and ISO wkb are using different codes for geometries with Z and M but I can't verify because I do not have the ISO standard.
Myself I am a non-developer and I can't make any tests with wkb readers. I am just a curious GIS user and even I may be able to read and interpret some bytes with my bare eyes if there is a good reference available I can't do anything with them by coding. You are right that Spatialite BLOB is not exactly WKB because it does not repeat the endianness byte for each part of multigeometries and geometry collections. -Jukka Rahkonen- ________________________________ Chris Holmes wrote: > Hey Jukka, thanks for all the feedback. I've been working on the > specification, and just send the information to the group (and I hope to use > this experience to figure out how to help open up the process more, so you > could join it just like an open source project instead of me having to be a > go between). > So the reason we decided for WKB for the blob was to ensure that more > existing WKB readers could make use of it. Spatialite's blob isn't _quite_ > wkb, at least that's what people in the working group discussed. So if the > ISO wkb doesn't work with most readers then we definitely did something > seriously wrong. If you could try it out that'd be great. Though the > geopackage Justin created I believe used JTS to create the wkb, so it should > be able to read it. Note also that there's another open source geopackage > implementation, at https://bitbucket.org/luciad/libgpkg > I'll make sure the specification says what to do about features with empty > geometries, if it's not there already. I don't remember discussions that > we've had that have talked about it explicitly. This is great feedback. > A core design goal that I pushed a lot was to be able to have geopackage > blobs be able to be read and written without needing any additional > libraries, like spatialite. > There have been lots of changes since 0.7.2, to support exactly the use case > you describe, so hopefully the newer version of the spec makes it easier to > understand. So it should be as simple as you describe. > The variable bytes for the envelope size was based on a suggestion from Paul > Ramsey. It does make the reader slightly more complicated, but it leads to a > very significant space saving for points, since there's no good reason to > include an envelope on a point. > Thanks again for this Jukka, it's quite helpful. > Chris On Sat, Jul 13, 2013 at 5:19 AM, Rahkonen Jukka <jukka.rahko...@mmmtike.fi<mailto:jukka.rahko...@mmmtike.fi>> wrote: Hi, It looks like the GeoPackage BLOB is pretty close to Spatialite BLOB but still so much different that no existing software can read it out of the box. Differences are in a new magic numbers, dropping out the geometry type code, and support for several alternatives for storing the feature bounding box. The latter means that there are four alternatives for how many bytes must be skipped before the WKB part begins. I am sure if using ISO 13249 WKB instead of OGC WKB will make any additional trouble but let's hope not but I can't even interpret which WKB there is included in spearfish GeoPackege sample. It may be that JTS does not read ISO WKB and that would be sad http://sourceforge.net/p/jts-topo-suite/code/878/tree/trunk/jts/java/src/com/vividsolutions/jts/io/WKBReader.java General note about the GeoPackage specification is that I am not sure if it supports features with empty geometries or not. Features with empty geometries are not uncommon in GIS work (new parcel is created by administration and stored into database but it is not digitized yet etc.) so I hope that GeoPackage developers have not forgotten this. The Spearfish sample database does not have "not null" constraint for the geometry field so null geometry seems to be OK. Sometimes empty geometries would be better as Paul Ramsey wrote http://blog.cleverelephant.ca/2010/03/nothing-nada-zip-bupkus.html One scenario in GeoPackage is that any SQLite capable client could just read the Geopackage BLOBs without a need to know anything more about GeoPackage. The OpenJUMP DB Query plugin http://sourceforge.net/projects/jumpdbqplugin/ seems to be almost ready for that because is can already do the same with Spatialite BLOB. The plugin does not care about stuff like geometry_columns but it just rips off the WKB part of the BLOB and sends it to JTS Wkb reader. The logic used by the plugin is to analyze the Spatialite BLOB is described in the source code as //From http://www.gaia-gis.it/spatialite-2.1/SpatiaLite-manual.html //Spatialite geometry blobs are WKB-like, with some specifics to //spatialite: For our purposes, this should be good enough: //the 39th byte must be 0x7C (marks MBR end) //and the blob must end with 0xFE I must say that for a non-programmer like me it is much more easy to understand the Spatialite BLOB structure from the document http://www.gaia-gis.it/gaia-sins/BLOB-Geometry.html than to understand how the Geopackage BLOB is built by reading the GeoPackage implementation specification v. 0.7.2. Now I believe that if somebody wants just to read the WKB part from the GeoPackage BLOB it could be done like this: 1) Check if BLOB begins with "GPB" bytes (47 50 42). If yes, then it is a GeoPagkage BLOB. 2) Study the fourth byte and find the "E" bits (1, 2, and 3). 3) Skip the four srs_id bytes and based on the envelope type, either 0, 32, 48, or 64 bytes more. 4) Here starts the WKB Thus the first byte of WKB is either byte number 9, 41, 57, or 73. Have I understood it right and counted the bytes correctly? If I have, then I suppose that DB Query Plugin would work with GeoPackage BLOBs after someone adds a few lines of code for checking the envelope flags for getting the correct numbers of bytes to skip. Flags.java by Justin seems to do this. For comparison here is the corresponding part of the Spatialite BLOB reader. tt is enough to start always from the 40th byte because there is only one way for giving envelope in Spatialite and it has a fixed length. >From >\jumpdbplugin-src-0.8.2.zip\jumpdbplugin-src-0.8.2\src\org\freevoice\jumpdbqueryextension\spatialite\JumpSpatialiteDbQuery.java //copy the byte array, removing the MBR at the front, //and the ending OxFE byte at the end byte[] wkb = new byte[blobAsBytes.length - 39]; System.arraycopy(blobAsBytes, 39, wkb, 1, blobAsBytes.length - 1 - 39); //prepend byte-order byte wkb[0] = blobAsBytes[1]; What do you think, could it really be that simple? Or does ISO WKB vs. OGC WKB break the simplicity? -Jukka Rahkonen- ________________________________ Lähettäjä: Justin Deoliveira [jdeol...@opengeo.org<mailto:jdeol...@opengeo.org>] Lähetetty: 12. heinäkuuta 2013 0:24 Vastaanottaja: Rahkonen Jukka Cc: geoserver-devel@lists.sourceforge.net<mailto:geoserver-devel@lists.sourceforge.net> Aihe: Re: [Geoserver-devel] geopackage community module Hey Jukka, You can find a sample package with the spearfish data here. http://dev.opengeo.org/~jdeolive/geopkg/spearfish.zip Just unzip it and you should be able to connect to the resulting .geopackage file with any sqlite client. -Justin On Thu, Jul 11, 2013 at 2:48 PM, Rahkonen Jukka <jukka.rahko...@mmmtike.fi<mailto:jukka.rahko...@mmmtike.fi><mailto:jukka.rahko...@mmmtike.fi<mailto:jukka.rahko...@mmmtike.fi>>> wrote: Hi, Interesting. It would be nice to see how a geopackage file with metadata tables and some vectors looks like. Is there any sample available? -Jukka Rahkonen- ________________________________ Justin Deoliveira wrote: > Hi all, > To go along with the geopkg module just added to geotools we have also > developed an output format for geoserver capable of producing a geopackage > file from a wms request. I would like to add it as a community module. > The code is up in my github repo. https://github.com/jdeolive/geoserver/compare/geopkg -Justin -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net<mailto:Geoserver-devel@lists.sourceforge.net><mailto:Geoserver-devel@lists.sourceforge.net<mailto:Geoserver-devel@lists.sourceforge.net>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net<mailto:Geoserver-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/geoserver-devel ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
