[Qgis-developer] GDAL 2.1 can update Geojson files - What is missing in QGIS to edit GeoJSON files ?

[Even Rouault]

Le jeudi 14 janvier 2016 18:49:40, Matthias Kuhn a écrit :
> On 01/14/2016 06:32 PM, Even Rouault wrote:
> > Le jeudi 14 janvier 2016 18:04:00, Matthias Kuhn a écrit :
> >> On 01/14/2016 05:42 PM, Even Rouault wrote:
> >>>> It will benefit from expression compiling (for filtering and order by)
> >>>> which results in performance improvements when it can be applied.
> >>> 
> >>> I'm not completely sure to know what you refer to in the QGIS context
> >>> but the OGR SetAttributeFilter() method is directly evaluated by the
> >>> SQLite request engine as a WHERE clause, and similarly for the
> >>> ExecuteSQL() API.
> >> 
> >> It tries to compile QgsExpressions to native SQL syntax.
> >> 
> >> I think the point of using OGR that it offers an awesome abstraction
> >> layer where the consumer doesn't need to care about the backend.
> >> 
> >> As soon as ExecuteSQL is used this abstraction no longer applies and it
> >> just adds another layer of uncertainty (different library versions...)
> >> and may potentially hide internals of the backends which may be useful
> >> in some cases (datatypes, backend metadata, available indexes, ...), so
> >> the advantage is gone while it complicates advanced topics.
> >> Or did I miss something?
> > 
> > - datatypes: all the ones listed in "Table 1. GeoPackage Data Types"
> > http://www.geopackage.org/spec/#_sqlite_container have an OGR equivalent
> > - backend metadata: not sure what you're thinking exactly too. But at
> > some point this has to be translated in the QGIS abstraction too, no ? -
> > available indexes: not present in the OGR abstraction currently (but the
> > abstraction can be extended if needed, as it has been done in the past).
> > Is QGIS aware of which indices exist ?
> > 
> > A possibility would be to have a thin GeoPackage provider (I guess it
> > could probably even by generic to most OGR drivers that have native
> > SQL92 capabilities) extending the base OGR one + using its capabilities
> > with the specificities of GPKG (eg adding the SORT BY clause). Or a more
> > quick&dirty way would be to hack that directly in the OGR provider for
> > the vetted OGR drivers.
> 
> I was referring to databases in general (expression compilation is also
> done for MSSQL, Oracle, Postgres)
> 
> I do not doubt that for every requirement an interface can also be
> implemented in OGR but it still adds an extra roundtrip in the
> development cycle, its presence has to be guaranteed on the client
> system (we're still at 1.10.x on win, not sure about all linux distros
> and mac) and an extra layer of possible errors, performance loss...

I can understand those reasons (althoug I'm a bit skeptical about the 
performance loss. That would mean the translation from OGRFeature to 
QGISFeature becomes really significant in performance profiles)

> 
> What would be the advantage of using OGR when using ExecuteSQL?

Just that the GPKG driver already exists (that was my main point) and in 
theory GDAL/OGR is the natural place to deal with file formats.

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com