Opened 17 years ago

Closed 17 years ago

#1537 closed defect (fixed)

ogr_sql: FID not usable in WHERE clause

Reported by: wollah Owned by: Mateusz Łoskot
Priority: normal Milestone: 1.4.1
Component: default Version: 1.4.0
Severity: normal Keywords:
Cc: warmerdam

Description

A statement like:

SELECT FID,* FROM buildings WHERE FID=4128

will not work in GDAL/OGR 1.4.0 when applied to a MapInfo.tab. The same works fine when using GDAL/OGR 1.3.2

Attachments (1)

mapinfotab.zip (288.2 KB ) - added by wollah 17 years ago.
the file in question was too big to attach. But it works with any of my MITabs

Download all attachments as: .zip

Change History (8)

by wollah, 17 years ago

Attachment: mapinfotab.zip added

the file in question was too big to attach. But it works with any of my MITabs

comment:1 by warmerdam, 17 years ago

Cc: warmerdam added
Milestone: 1.4.1
Owner: changed from warmerdam to Mateusz Łoskot

Mateusz,

Please try to reproduce this with GDAL 1.4.0, and then check to see if it is already fixed in trunk and/or 1.4 branch. I suspect it relates to the fix for ticket #1528, though this manifestation is somewhat different.

If/when fixed, I would also like you to add something to the test suite to handle this case issue.

comment:2 by wollah, 17 years ago

Resolution: fixed
Status: newclosed

Frank,

it is fixed at least in gdal-svn-2007.03.28. I forgot to mention that I am building gdal from source (Windows/VC++). It has been working in 1.3.2 and did not work with the sources 1.4.0 dated 01/02/07.

comment:3 by warmerdam, 17 years ago

Resolution: fixed
Status: closedreopened

Excellent, I'm pleased it fixed in trunk.

I'm still going to re-open this ticket for Mateusz to do a few things.

1) Verify that he can reproduce the bug in GDAL 1.4.0.

2) Verify that it is fixed in the 1.4 stable branch.

3) Add some sort of test to gdalautotest for this problem, since it apparently wasn't revealed by the existing test suite.

Note that item 3 is fairly low priority and can certainly wait till after the 1.4.1 release.

comment:4 by Mateusz Łoskot, 17 years ago

2) Verify that it is fixed in the 1.4 stable branch.

I can not reproduce the bug in 1.4 stable branch, on Linux, so I'm inclined to confirm it's been fixed there. Here are my tests:

mloskot:~/dev/gdal/bugs/1537$ ls
DI_Boe.DAT  DI_Boe.ID  DI_Boe.IND  DI_Boe.MAP  DI_Boe.TAB
  • Using SELECT
ogrinfo . -ro -sql 'SELECT FID,* FROM DI_Boe WHERE FID=4117' 
INFO: Open of `.'
      using driver `MapInfo File' successful.

Layer name: DI_Boe
Geometry: Line String
Feature Count: 1
Extent: (3483118.959010, 5528162.466999) - (3490144.051010, 5532149.768998)
Layer SRS WKT:
LOCAL_CS["Nonearth",
    UNIT["Meter",1.0]]
FID: Integer (0.0)
Folie: String (3.0)
_Obj: String (4.0)
ObjSchluessel: String (4.0)
ObjNr: String (7.0)
GEO: String (2.0)
OGRFeature(DI_Boe):4117
  FID (Integer) = 4117
  Folie (String) = 29
  _Obj (String) = 
  ObjSchluessel (String) = 
  ObjNr (String) = D0038LG
  GEO (String) = LA
  LINESTRING (3488046.381205634213984 5529823.677014435641468,3488047.421189342625439 5529827.347016385756433)
  • Using WHERE clause only - as a confirmation of test case above
ogrinfo . DI_Boe -ro -where 'FID=4117' 
INFO: Open of `.'
      using driver `MapInfo File' successful.

Layer name: DI_Boe
Geometry: Line String
Feature Count: 1
Extent: (3483118.959010, 5528162.466999) - (3490144.051010, 5532149.768998)
Layer SRS WKT:
LOCAL_CS["Nonearth",
    UNIT["Meter",1.0]]
Folie: String (3.0)
_Obj: String (4.0)
ObjSchluessel: String (4.0)
ObjNr: String (7.0)
GEO: String (2.0)
OGRFeature(DI_Boe):4117
  Folie (String) = 29
  _Obj (String) = 
  ObjSchluessel (String) = 
  ObjNr (String) = D0038LG
  GEO (String) = LA
  Style = PEN(w:1px,c:#000000,id:"mapinfo-pen-2.ogr-pen-0")
  LINESTRING (3488046.381205634213984 5529823.677014435641468,3488047.421189342625439 5529827.347016385756433)

I'm building release 1.4 to check suggestion No 1.

comment:5 by Mateusz Łoskot, 17 years ago

1) Verify that he can reproduce the bug in GDAL 1.4.0.

Yes, I can reproduce the problem with GDAL 1.4.0 release. Here is my test script:

Just to confirm that ogrinfo I use comes from and uses GDAL 1.4.0

mloskot:~/dev/gdal/bugs/1537$ ldd ~/dev/gdal/release/1.4/gdal/ogr/ogrinfo | grep gdal
        libgdal.so => /home/mloskot/dev/gdal/release/1.4/gdal/libgdal.so (0xb77fd000)
        libgdal1.3.1.so.1 => /usr/lib/libgdal1.3.1.so.1 (0xb4a89000)
mloskot:~/dev/gdal/bugs/1537$ 
  • Test of SELECT statement
mloskot:~/dev/gdal/bugs/1537$ ~/dev/gdal/release/1.4/gdal/ogr/ogrinfo . DI_Boe -ro -sql 'SELECT FID,* FROM DI_Boe WHERE FID=4129'
INFO: Open of `.'
      using driver `MapInfo File' successful.
layer names ignored in combination with -sql.

Layer name: DI_Boe
Geometry: Line String
Feature Count: 0
Extent: (3483118.959010, 5528162.466999) - (3490144.051010, 5532149.768998)
Layer SRS WKT:
LOCAL_CS["Nonearth",
    UNIT["Meter",1.0]]
FID: Integer (0.0)
Folie: String (3.0)
_Obj: String (4.0)
ObjSchluessel: String (4.0)
ObjNr: String (7.0)
GEO: String (2.0)
mloskot:~/dev/gdal/bugs/1537$ 
  • Test of WHERE clause only
mloskot:~/dev/gdal/bugs/1537$ ~/dev/gdal/release/1.4/gdal/ogr/ogrinfo . DI_Boe -ro -where 'FID=4128'
INFO: Open of `.'
      using driver `MapInfo File' successful.

Layer name: DI_Boe
Geometry: Line String
Feature Count: 0
Extent: (3483118.959010, 5528162.466999) - (3490144.051010, 5532149.768998)
Layer SRS WKT:
LOCAL_CS["Nonearth",
    UNIT["Meter",1.0]]
Folie: String (3.0)
_Obj: String (4.0)
ObjSchluessel: String (4.0)
ObjNr: String (7.0)
GEO: String (2.0)

Summary:

  • Presence of the issue in GDAL 1.4.0 - confirmed
  • Problem fixed in current trunk and 1.4 stable branch - confirmed

comment:6 by Mateusz Łoskot, 17 years ago

As an additional note, the issue with ignoring FID in -sql or -where statements was not specific to MapInfo driver only but to OGR SQL engine.

comment:7 by Mateusz Łoskot, 17 years ago

Resolution: fixed
Status: reopenedclosed

3) Add some sort of test to gdalautotest for this problem

I added test case ogr_sql_15 (r11197) to the OGR SQL test suite.

I think we can consider this bug as fixed, what I'm going to do.

Note: See TracTickets for help on using tickets.