Opened 13 years ago
Closed 13 years ago
#4156 closed defect (invalid)
OGR Datasource --> ExecuteSQL returns wrong feature
Reported by: | mjigmond | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | OGR_SF | Version: | 1.8.0 |
Severity: | normal | Keywords: | ExecuteSQL |
Cc: |
Description
The following script returns the wrong feature using ExecuteSQL.
#!/usr/bin/python from osgeo import ogr import sys, math, time, os aquifer = '/data/romania/judeteEPSG3844.shp' aqDS = ogr.Open(aquifer) sql = 'select * from judeteEPSG3844 where DENJUD = "CLUJ"' aqLayer = aqDS.ExecuteSQL(sql) feat = aqLayer.GetFeature(0) print aqLayer.GetFeatureCount() print feat.GetField('DENJUD') aqDS.ReleaseResultSet(aqLayer)
Result of print statements:
1 TELEORMAN
Expected result:
1 CLUJ
I also tried a different SQL statement:
sql = 'select * from judeteEPSG3844 where DENJUD like "CLUJ"'
with the same wrong result.
Sample shapefile attached.
-marius
Attachments (1)
Change History (4)
by , 13 years ago
Attachment: | testBUG4156.tar.bz2 added |
---|
comment:1 by , 13 years ago
comment:2 by , 13 years ago
Component: | default → OGR_SF |
---|---|
Status: | new → assigned |
comment:3 by , 13 years ago
Resolution: | → invalid |
---|---|
Status: | assigned → closed |
The problem is the use of GetFeature(0) instead of GetNextFeature().
ExecuteSQL() returns a layer which can be iterated over to fetch the matching results. But you cannot expect them to be renumbered with fid's starting at zero.
In the case of the OGR implementation GetFeature() on the ExecuteSQL() layer is basically processing a feature from the underlying layer with that FID if you request things by fid.
Just change:
feat = aqLayer.GetFeature(0)
to
feature = aqLayer.GetNextFeature()
I had to select a subset of the original shapefile due to size restrictions.