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>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]
> Lähetetty: 12. heinäkuuta 2013 0:24
> Vastaanottaja: Rahkonen Jukka
> Cc: 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>> 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>
> 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
> 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
