Hi Even
On 02.09.2017 21:49, Even Rouault wrote:
There's a flow in your reproducer. You run OGR_DS_ExecuteSQL( ds,
subsetQuery, NULL, NULL ); but do not use the resulting result layer.
So basically this has no effect on the rest of your code (except a
memory leak).
Ah yes indeed!
[...]
The reason is that when issuing a SQL request there's no guarantee
that it will result in a set of rows with unique identifiers (think of
a join that could make several rows appear twice), so the FID on the
result set of ExecuteSQL() are just a sequence starting at 0.
Ok makes sense. Though as far as QGIS goes, is there a case where a
subset query can result in duplicates?
If you know that your request will result in a result set with real
FIDs you can use the following trick to get the FID column as a
regular column (renaming the ogc_fid as something else, since there's
special logic to ignre "ogc_fid as a regular field. If your FID field
name is already something else than this default "ogc_fid", then
you'll already get it as a regular field)
$ ogrinfo poly.sqlite -sql "select ogc_fid as this_is_the_fid, * from
poly where ogc_fid = 10"
INFO: Open of `poly.sqlite'
using driver `SQLite' successful.
Layer name: SELECT
Geometry: Unknown (any)
[...]
Geometry Column = GEOMETRY
this_is_the_fid: Integer (0.0)
area: Real (0.0)
eas_id: Integer64 (0.0)
prfedea: String (0.0)
OGRFeature(SELECT):0
this_is_the_fid (Integer) = 10
area (Real) = 5268.813
eas_id (Integer64) = 170
prfedea (String) = 35043413
POLYGON ((479750.6875 4764702.0,479658.59375 4764670.0,479640.09375
4764721.0,479735.90625 4764752.0,479750.6875 4764702.0))
Something like this [1] seems to fix the issue, don't know if it's the
best way forward though?
Thanks
Sandro
[1]
https://github.com/manisandro/QGIS/commit/e95eea6dfa3e7ce7d0c0796352fa39943be80031
_______________________________________________
QGIS-Developer mailing list
[email protected]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer