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)

testBUG4156.tar.bz2 (890.2 KB ) - added by mjigmond 13 years ago.

Download all attachments as: .zip

Change History (4)

by mjigmond, 13 years ago

Attachment: testBUG4156.tar.bz2 added

comment:1 by mjigmond, 13 years ago

I had to select a subset of the original shapefile due to size restrictions.

comment:2 by warmerdam, 13 years ago

Component: defaultOGR_SF
Status: newassigned

comment:3 by warmerdam, 13 years ago

Resolution: invalid
Status: assignedclosed

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()
Note: See TracTickets for help on using tickets.