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

Matthias Kuhn matthias at opengis.ch
Thu Jan 14 10:15:03 PST 2016

On 01/14/2016 07:07 PM, Even Rouault wrote:
> 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)

Fair enough, this particular point is unlikely to be significant

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

And it does a good job with it, at least there is GPKG support already!

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/49b6c129/attachment.sig>

More information about the Qgis-developer mailing list