[Geopackage] [SpatiaLite-Users] Digest for spatialite-users at googlegroups.com - 10 updates in 3 topics

Paul Daisey pdaisey1331 at gmail.com
Thu May 22 09:20:21 EDT 2014


Sandro, Brad:
     Thank you and any other developers involved very much for adding 
GeoPackage support to SpatiaLite!

Raj, Greg:
     Please add a SpatiaLite link from the implementations list on 
http://www.geopackage.org/ to 
https://www.gaia-gis.it/fossil/libspatialite/index

     Thanks,
Paul

On 5/21/2014 8:20 PM, spatialite-users at googlegroups.com wrote:
> Today's topic summary
>
> Group: http://groups.google.com/group/spatialite-users/topics
>
>   * version 4.2.0 RC0 <#group_thread_0> [4 Updates]
>   * 4.2.0 RC1 <#group_thread_1> [1 Update]
>   * GeoPackage (GPKG) support in 4.2.0 <#group_thread_2> [5 Updates]
>
> version 4.2.0 RC0 
> <http://groups.google.com/group/spatialite-users/t/ce418ffa03c1c979>
>
>     sandro furieri <a.furieri at lqt.it> May 21 12:20PM -0700
>
>     the first Release Candidate for the next 4.2.0 is now
>     available; please see:
>
>     http://www.gaia-gis.it/gaia-sins/libspatialite-4.2.0-rc0.tar.gz
>     http://www.gaia-gis.it/gaia-sins/libspatialite-4.2.0-rc0.zip
>
>     bye Sandro
>
>     Even Rouault <even.rouault at mines-paris.org> May 21 09:40PM +0200
>
>     Le mercredi 21 mai 2014 21:20:37, sandro furieri a écrit :
>     > available; please see:
>
>     > http://www.gaia-gis.it/gaia-sins/libspatialite-4.2.0-rc0.tar.gz
>     > http://www.gaia-gis.it/gaia-sins/libspatialite-4.2.0-rc0.zip
>
>     Sandro,
>
>     Looks good to me, as far as GDAL is concerned. Pass the regression
>     tests of
>     the SQLite/Spatialite driver on Ubuntu 10.04 AMD64.
>
>     Even
>
>     -- 
>     Geospatial professional services
>     http://even.rouault.free.fr/services.html
>
>     "Volker Fröhlich" <volker27 at gmx.at> May 22 12:47AM +0200
>
>     Am 2014-05-21 21:20, schrieb sandro furieri:
>
>     > http://www.gaia-gis.it/gaia-sins/libspatialite-4.2.0-rc0.tar.gz
>     > http://www.gaia-gis.it/gaia-sins/libspatialite-4.2.0-rc0.zip
>
>     > bye Sandro
>
>     mod_spatialite is a bit like a private shared library, right? In that
>     case I think it should be installed to a subdirectory, like
>     /usr/lib64/mod_spatialite or something. Furthermore I assume, that
>     ABI
>     versioning doesn't make sense there.
>
>     The libspatialite tests on 32 bit Intel all run fine for me, but
>     on 64
>     bit Intel one test fails (Fedora Rawhide):
>
>     FAIL: check_bufovflw
>     ====================
>
>     Unexpected result (WKT 3D): GEOMETRYCOLLECTION Z(POINT
>     Z(100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
>
>     100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
>
>     100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000),
>
>     LINESTRING Z(0 0 0,
>     100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
>
>     100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
>
>     100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000),
>
>     POLYGON Z((0 0 0,
>     100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
>
>     0 0,
>     100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
>
>     100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
>
>     100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000,
>
>     0
>     100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
>
>     0, 0 0 0), (5 5 0,
>     100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
>
>     5 0,
>     100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
>
>     100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
>
>     0, 5 0 0, 5 5 0)))
>
>     Greetings,
>
>     Volker
>
>     a.furieri at lqt.it May 22 02:07AM +0200
>
>     On Thu, 22 May 2014 00:47:48 +0200, Volker Fröhlich wrote:
>     >> http://www.gaia-gis.it/gaia-sins/libspatialite-4.2.0-rc0.zip
>
>     >> bye Sandro
>
>     > mod_spatialite is a bit like a private shared library, right?
>
>     yes, it precisely is a "loadable module"; a concept initially
>     introduced by BSD and now supported as such only by Mac OS X
>     "bundles".
>     On Linux there is no real distrinction betweem loadable modules
>     and shared library; all them are anyway shared object.
>     The main difference between a loadable module and a shared
>     library is in that you can directly link a shared library;
>     but this is never expected to be possibile on behalf of a
>     loadable module, which is always intended (as the name says)
>     to be dynamically loaded/unloaded by some other process.
>
>
>     > In that case I think it should be installed to a subdirectory, like
>     > /usr/lib64/mod_spatialite or something.
>
>     the unique relevant thing is that the module should be placed
>     in a dir directly covered by the standard platform search rules,
>     so to avoid any need for the user to set LD_LIBRARY_PATH or
>     to specify an absolute path while executing:
>
>     SELECT load_extension('mod_spatialite');
>
>
>     > Furthermore I assume, that ABI versioning doesn't make sense there.
>
>     > The libspatialite tests on 32 bit Intel all run fine for me, but on
>     > 64 bit Intel one test fails (Fedora Rawhide):
>
>     it's very puzzling indeed; on my Fedora 20 64 bit anything runs
>     nicely.
>     just for the sake of curiosity, the same identical issue was already
>     reported few weeks ago by the Debian maintainers, and in that case
>     too the failure emerged on gcc 4.9 x86_64
>     my educated guess: it's probably related to some obscure bug affecting
>     gcc 4.9 x86_64 ;-)
>
>     bye Sandro
>
> 4.2.0 RC1 
> <http://groups.google.com/group/spatialite-users/t/16fde478bdbb9b28>
>
>     sandro furieri <a.furieri at lqt.it> May 21 04:34PM -0700
>
>     fixed an issue reported by Even Rouault:
>     GPKG support missing to update the "gpkg_contents" table
>
>     the current Release Candidate is now RC1
>
>     http://www.gaia-gis.it/gaia-sins/libspatialite-4.2.0-rc1.tar.gz
>     http://www.gaia-gis.it/gaia-sins/libspatialite-4.2.0-rc1.zip
>
>     bye Sandro
>
> GeoPackage (GPKG) support in 4.2.0 
> <http://groups.google.com/group/spatialite-users/t/f4315e19de4d3e1>
>
>     sandro furieri <a.furieri at lqt.it> May 21 02:18PM -0700
>
>     GeoPackage (GPKG) support available in 4.2.0
>
>     starting since v. 4.2.0 libspatialite will start
>     supporting the new OGC GPKG data format [1]
>
>     a very short abstract about GPKG:
>     - it's based on SQLite, exactly as SpatiaLite is.
>     - anyway GPKG and SpatiaLite adopt a completely
>     different table layout.
>     - more important than all: GPKG adopts a Geometry
>     binary encoding completely different from the
>     one supported by SpatiaLite (and absolutely not
>     compatible).
>     - GPKG is not really intended to be a full fledged
>     Spatial DBMS; it's more kind of a standardized
>     exchange format, not necessarily requiring an
>     advanced Spatial SQL support.
>     The main Spatial Processing capabilities are
>     always assumed to be deployed autonomously by
>     each different client application.
>     - SpatiaLite follows a conceptually inverted
>     approach; the main Spatial Processing capabilities
>     are always assumed to be in the DBMS itself, not
>     in client applications.
>     - short conclusion: both SpatiaLite and GPKG share
>     many common similarities (mainly due to the
>     underlying SQLite base support).
>     but they are and will remain two different and
>     well separated components, being intended for
>     completely different scopes.
>     SpatiaLite mainly is a data processing tool;
>     GPKG mainly is a neutral exchange format.
>
>
>     new SQL functions supporting GPKG
>     =================================
>     (please consult "spatialite-sql-latest.html" from
>     the RC0 source tarball for more specific details)
>
>     general support:
>     ----------------
>     - CheckGeoPackageMetaData(): will recognize if the
>     currently connected DB-file presents a GPKG layout
>     - gpkgCreateBaseTables(): will initialize all
>     "metadata" tables required by the GPKG layout
>     - gpkgInsertEpsgSRID(): allows to populate the GPKG
>     "gpkg_spatial_ref_sys_table"
>
>     raster (tiles) support:
>     -----------------------
>     - gpkgCreateTilesTable(), gpkgCreateTilesZoomLevel(),
>     gpkgAddTileTriggers(), gpkgGetNormalZoom(),
>     gpkgGetNormalRow(), gpkgGetImageType()
>     I imagine that Brad Hards will probably be happy to
>     add few more infos about GPKG raster/tiles handling.
>
>     vector (Geometry) support:
>     --------------------------
>     - gpkgAddGeometryColumn(), gpkgAddGeometryTriggers(),
>     gpkgAddSpatialIndex(), gpkgMakePoint(),
>     gpkgMakePointZ(), gpkgMakePointM(), gpkgMakePointZM(),
>     GPKG_IsAssignable(), IsValidGPB(), AsGPB(), GeomFromGPB(),
>     CastAutomagic()
>     The most interesting surely are:
>     - IsValidGPB(): will recognize if a BLOB does actually
>     corresponds to a valid GPKG binary geometry
>     - AsGPB(): will transform a SpatiaLite's own binary
>     Geometry into a GPKG binary Geometry
>     - GeomFromGPB(): will transform a GPKG own binary
>     Geometry into a SpatiaLite's own binary Geometry
>     - CastAutomagic(): will indifferently accept both
>     GPKG and SpatiaLite BLOB Geometries, then returning
>     anyway a SpatiaLite's own BLOB Geometry.
>
>     Please note:
>     ------------
>     - gpkgAddGeometryTriggers() will add all triggers
>     defined in Annexes M/N
>     - gpkgAddSpatialIndex() will create the corresponding
>     rtree_<t>_<c> Spatial Index, and will add all
>     triggers defined in Annex L
>     Such triggers necessarily require a library support
>     for the following SQL functions:
>     - ST_IsEmpty()
>     - ST_MinX(), ST_MinY(), ST_MaxX(), ST_MaxY()
>     - ST_Srid()
>     - ST_GeometryType(), GPKG_IsAssignable()
>     - ST_Is3D(), ST_IsMeasured(), ST_MinZ(), ST_MaxZ(),
>     ST_MinM(), ST_MaxM()
>     SpatiaLite is intended to be capable to support this
>     kind of minimalistic SQL core even in the case of
>     GPKG binary geometries.
>
>
>     new VirtualGPKG Virtual Tables
>     ==============================
>     any GPKG table containing a Geometry column can now be
>     wrapped by a corresponding VirtualGPKG table.
>     after this you simply have to target your SQL queries
>     on behalf of the VirtualGPKG table: the VirtualGPKG
>     logic will silently serialize/deserialize BLOB
>     Geometries as appropriate, and a VirtualGPKG table
>     could be then used exactly in the same way as if
>     it was a native SpatiaLite table.
>
>     VirtualGPKG supports unconstrained SELECT, INSERT,
>     UPDATE and DELETE operations; so, thanks to VirtualVPKG
>     intermediation, you are now allowed to perform any
>     possible kind of Spatial Analysis and Spatial Data
>     Processing even when using a GPKG target.
>
>     SQL auxiliary functions supporting VirtualGPKG:
>     -----------------------------------------------
>     - AutoGPKGStart(): this function will automatically
>     scan the "gpkg_geometry_columns" metadata table,
>     then automatically creating a VirtualGPKG wrapper
>     for each table.
>     - AutoGPKGStop(): this function will automatically
>     scan the "gpkg_geometry_columns" metadata table,
>     then automatically destroying any VirtualGPKG
>     wrapper eventually found.
>     So you can invoke AutoGPKGStart() immediately after
>     connecting to a GPKG datasource, then invoking
>     AutoGPKGStop() immediately before quitting.
>     Following this approach the GPKG db-file will never
>     permanently incorporate any SpatiaLite specific
>     item, but you'll be anyway able to effectively
>     target a GPKG datasource using SpatiaLite in the
>     most painless way.
>
>
>     final remark:
>     -------------
>     accordingly to all this, now the build time option
>     "--enable-geopackage=yes" will be assumed by default.
>     you could anyway selectively disable at all the
>     GeoPackage support by explicitly setting:
>     --disable-geopackage
>
>     bye Sandro
>
>     [1] http://www.geopackage.org/spec/
>
>     Even Rouault <even.rouault at mines-paris.org> May 21 11:34PM +0200
>
>     Sandro,
>
>     how is supposed to be conformant the test file ./test/gpkg_test.gpkg ?
>
>     I have a major interoperabililty problem when opening it with OGR
>     GPKG driver.
>     The issue is that none of the tables is registered in
>     gpkg_contents, so the
>     driver doesn't see them.
>
>     My understanding of
>     http://www.geopackage.org/spec/#_geometry_columns and
>     particularly
>
>     Requirement 23
>
>     Values of the gpkg_geometry_columns table_name column SHALL reference
>     values in the gpkg_contents table_name column for rows with a
>     data_type of
>     features.
>
>     is that any table mentionned in gpkg_geometry_columns should also
>     be listed in
>     gpkg_contents.
>
>     Another issue I can see is that the geometry columns in the CREATE
>     TABLE
>     statetement are of type BLOB and not GEOMETRY, POINT, etc...
>
>     I could not find a precise requirement on this but this is what is
>     suggested by
>     http://www.geopackage.org/spec/#example_feature_table_sql and the
>     3 samples at
>     http://www.geopackage.org/#sampledata do that too.
>
>
>     Even
>
>     Le mercredi 21 mai 2014 23:18:33, sandro furieri a écrit :
>
>     -- 
>     Geospatial professional services
>     http://even.rouault.free.fr/services.html
>
>     Even Rouault <even.rouault at mines-paris.org> May 22 12:11AM +0200
>
>     Le mercredi 21 mai 2014 23:34:18, Even Rouault a écrit :
>     > Sandro,
>
>     While looking at the code, I see that in SUPPORTED_GEOMETRY_TYPES
>     array in
>     gpkgAddGeometryColumn.c there is "GEOMCOLLECTION". I think it
>     should be
>     "GEOMETRYCOLLECTION" instead as in table 44 of Annex E (
>     http://www.geopackage.org/spec/#geometry_types )
>
>     But... the string GeomCollection appears at a few occurrences in the
>     GeoPackage specification, so CC'ing the GeoPackage list so that
>     they share some
>     light. Looks like there is an inconsistency
>
>     SFS traditionnaly has called it GEOMETRYCOLLECTION AFAIK. But
>     damned! when
>     checking ogc 99-049 OpenGIS Simple Features Specification For SQL
>     I can see
>     that both are used !
>
>     -- 
>     Geospatial professional services
>     http://even.rouault.free.fr/services.html
>
>     a.furieri at lqt.it May 22 12:33AM +0200
>
>     On Thu, 22 May 2014 00:11:06 +0200, Even Rouault wrote:
>     > checking ogc 99-049 OpenGIS Simple Features Specification For SQL I
>     > can see
>     > that both are used !
>
>     LOL :-D
>
>     Even,
>     you are reading directly into my mind ...
>
>     Yes, I noticed that the GPKG specs are rather obscure / unclear
>     about this topic; anyway I received the personal impression that
>     GEOMCOLLECTION was someway the preferred name.
>     (being probably based on the more recents "top secret" ISO
>     SQL/MM specs)
>
>     I suppose than when reading from a GPKG being prepared to support
>     both alias names indifferently should probably be the safer approach.
>
>     International Standard: a polite name to define a messy chaos :-D
>
>     bye Sandro
>
>     p.s.
>     ... a further doubt: it looks like every GPKG table shall necessarily
>     have a Primary Key declared as "INTEGER AUTOINCREMENT"
>     What's happen e.g. while exporting form an origin table presenting
>     a multi-column PK ?
>     we could eventually ignore the original PK, then defaulting to
>     some other INTEGER AUTOINCREMENT id; but this will obviously
>     kill any possible relationship based on Foreign Keys referencing
>     the original multi-column PK
>
>     sandro furieri <a.furieri at lqt.it> May 21 04:31PM -0700
>
>     Il giorno mercoledì 21 maggio 2014 23:34:18 UTC+2, EvenR ha scritto:
>     > The issue is that none of the tables is registered in
>     gpkg_contents, so
>     > the
>     > driver doesn't see them.
>
>     Fixed in RC1: now "gpkg_contents" will be correctly updated
>     (and replaced the "gpkg_test.gpkg" test sample)
>
>     bye Sandro
>
> -- 
> You received this message because you are subscribed to the Google 
> Groups "SpatiaLite Users" group.
> To unsubscribe from this group and stop receiving emails from it, send 
> an email to spatialite-users+unsubscribe at googlegroups.com 
> <mailto:spatialite-users+unsubscribe at googlegroups.com>.
> To post to this group, send email to spatialite-users at googlegroups.com 
> <mailto:spatialite-users at googlegroups.com>.
> Visit this group at http://groups.google.com/group/spatialite-users.
> For more options, visit https://groups.google.com/d/optout.

-- 

    Paul W. Daisey, Jr.
    Image Matters LLC
    201 Loudoun Street SW
    Leesburg, VA 20175

    Phone  703-669-5510
    Fax    703-669-5515
    Cell   301-651-7148
    pauld at imagemattersllc.com  <mailto://pauld@imagemattersllc.com>

http://www.imagemattersllc.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geopackage/attachments/20140522/9f1a8c71/attachment-0001.html>


More information about the Geopackage mailing list