Hi, One possible source for troubles came into my mind. People will not be satisfied with the delivered GeoPackages but they will want to modify and combine data from several packages. With SQLite it is very easy to add data from other SQLite data files by using the Attach database method. Now the possible problem is that srs_id in the feature tables are referring to srid column of the spatial_ref_sys table of the mother SQLite database. This means that srid X used in the attached table does not necessarily mean the same as the same srid code in the main GeoPackage. If user adds data as "create table added_data as select * from attached_table" the BLOBs are copied as is and the result can be unexpected. User should after this simple step to - check the meaning of srid=X from the attached GeoPackage - find the code for the same reference system from the main GeoPackage - if corresponding srtext or auth_name/auth_srid combination is missing from the main GeoPackage, add new line into spatial_ref_sys - if same srtext is found but with different srids, update the GeoPackage BLOBs in the table that is copied into the main db to use correct code
In the sample spearfish GeoPackege srid=auth_srid on every row (and epsg is the only auth in the table) but that will not be the case always. Spatialite BLOBs contain also references to srid code used in the local database so this is not a new issue and perhaps not so big trouble because I do not remember that anybody has complained about is in the Spatialite users forum. Perhaps because spatial_ref_sys table in Spatialite is most often created and populated by a Spatialite SQL function so the srids usually have a perfect match. Perhaps the GeoPackage spec might have an annex about best practise to add tables into the package from other attached GeoPackeges. I wonder also that if some special SQL functions are needed in any case as listed in Annex D, why not to include ST_AsBinary and let the database engine to resolve the slight but inevidently existing GeoPackage BLOB pecularities? Then the GeoPackage clients would have two alternatives: use their own GeoPackage BLOB parser or use some basic GeoPackage SQLite extension that outputs the same WKB that comes from PostGIS and Spatialite with "select ST_AsBinary(geom)..." Standards are funny, I never knew before today that there exists these OGC "Well Known Binaries" and ISO "(Not as) Well Known Binaries" -Jukka Rahkonen- ________________________________________ Lähettäjä: Rahkonen Jukka [jukka.rahko...@mmmtike.fi] Lähetetty: 13. heinäkuuta 2013 12:19 Vastaanottaja: geoserver-devel@lists.sourceforge.net Aihe: Re: [Geoserver-devel] geopackage community module 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
