[Qgis-developer] Future of spatialite provider?

Even Rouault even.rouault at spatialys.com
Mon Mar 13 14:31:42 PDT 2017


On lundi 13 mars 2017 21:25:54 CET Andreas Neumann wrote:
> Hi Josef,
> 
>  From http://www.gdal.org/drv_geopackage.html
> 
> "The core GeoPackage specification does not currently support
> non-spatial tables, but starting with GDAL 2.0, the driver allows
> creating and reading such tables via the Aspatial Support
> (gdal_aspatial) extension. Note: starting with GDAL 2.2, the driver will
> also, by default, list non spatial tables that are not registered
> through the gdal_aspatial extension."
> 
> So with newer GDAL versions it is possible to create and read
> non-spatial tables.

Andreas,

This thread was about the spatialite driver ;-) Support for spatial and non-spatial layers has 
always existed in OGR core, but what is available for a given format is driver specific.

Regarding GeoPackage the doc was a bit out of date. I've just updated it :

"""
Non-spatial tables

The core GeoPackage specification of GeoPackage 1.0 and 1.1 did not support non-spatial 
tables. This was added in GeoPackage 1.2 as the "attributes" data type.

Starting with GDAL 2.0, the driver allows creating and reading non-spatial tables with the 
Aspatial Support (gdal_aspatial) extension.

Starting with GDAL 2.2, the driver will also, by default, list non spatial tables that are not 
registered through the gdal_aspatial extension, and support the GeoPackage 1.2 "attributes" 
data type as well. Starting with GDAL 2.2, non spatial tables are by default created following 
the GeoPackage 1.2 "attributes" data type (can be controlled with the ASPATIAL_VARIANT 
layer creation option)
"""

Regarding the SQLite/Spatialite driver, there is an opening option, LIST_ALL_TABLES=YES, 
that can be set so as to list all tables, and not only those registered in the geometry_columns 
table. 
http://gdal.org/drv_sqlite.html

Even

> 
> Andreas
> 
> On 13.03.2017 17:13, josef k wrote:
> > Here is just a reminder from a user/plugin maintainer, please ignore
> > if not relevant.
> > 
> > If the spatialite data provider is to be removed then we will have to
> > update some plugins to reflect that which is ok, not a big deal. But
> > it is important that the current features of the spatialite data
> > provider are included into the OGR provider before changing.
> > 
> > E.g. we are using the spatalite data provider in plugins to add
> > non-spatial spatialite tables. I could not achieve this by using the
> > OGR provider (although it was a couple of years ago I was looking into
> > this and it may have changed by now).
> > 
> > regards
> > Josef
> > 
> >     On Mon, 13 Mar 2017 11:28:45 +1000, Nyall Dawson wrote:
> >         I'm wondering what the future of the spatialite provider
> >         should be. I
> >         find it odd that spatialite layers utilise the dedicated
> >         spatialite
> >         provider, but geopackage layers use the OGR provider.
> >         
> >         I think there's potential value in removing the spatialite
> >         provider
> >         and always reading these layers via OGR.
> > 
> > _______________________________________________
> > Qgis-developer mailing list
> > Qgis-developer at lists.osgeo.org
> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20170313/8bbd97a5/attachment.html>


More information about the Qgis-developer mailing list