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

[Matthias Kuhn]

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...

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

>>>>>> All the best

-- 
Matthias Kuhn
OPENGIS.ch - https://www.opengis.ch
Spatial • (Q)GIS • PostGIS • Open Source


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20160114/d0588f77/attachment-0001.sig>