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

Raj Singh rsingh at opengeospatial.org
Thu May 22 22:27:21 EDT 2014


That's great news! It's been added to http://www.geopackage.org/#implementations.
---
Raj
The OGC: Making location count.
http://www.opengeospatial.org/ogc/organization/staff/rsingh


On May 22, at 9:20 AM, Paul Daisey <pdaisey1331 at gmail.com> wrote:

> 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 [4 Updates]
>> 	• 4.2.0 RC1 [1 Update]
>> 	• GeoPackage (GPKG) support in 4.2.0 [5 Updates]
>>  version 4.2.0 RC0
>> 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
>> 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
>> 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.
>> To post to this group, send email to 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
> 
> 
> 
> http://www.imagemattersllc.com



More information about the Geopackage mailing list