[gdal-dev] Odd 1.7.3 <> 1.8.0 trunk OGR difference (shapefile driver?)

[Even Rouault]

Roger,

thanks for your report and the precise spotting of the problem.

The regression of behaviour you saw was not intended at all. It is now fixed in 
SVN (r21257) and I've added new test cases in the test suite r21258 to match 
that use case.

Best regards,

Even

Le mardi 14 décembre 2010 19:41:42, Roger Bivand a écrit :
> Hi,
> 
> Agus Lobo has drawn my attention to an oddity (here using GADM Tunisia
> shapefiles) introduced between 1.7.3 and current(ish) trunk:
> 
> $ ogr2ogr --version
> GDAL 1.7.3, released 2010/11/10
> $ ls TUN*
> TUN_adm0.dbf  TUN_adm0.shp  TUN_adm1.sbn  TUN_adm2.dbf  TUN_adm2.shp
> TUN_adm0.prj  TUN_adm0.shx  TUN_adm1.sbx  TUN_adm2.prj  TUN_adm2.shx
> TUN_adm0.sbn  TUN_adm1.dbf  TUN_adm1.shp  TUN_adm2.sbn  TUN_adm.zip
> TUN_adm0.sbx  TUN_adm1.prj  TUN_adm1.shx  TUN_adm2.sbx  TUN_readme.txt
> $ ogr2ogr -f "ESRI Shapefile" TUN TUN_adm0.shp -nln TUN
> $ ls TUN*
> TUN_adm0.dbf  TUN_adm0.shp  TUN_adm1.sbn  TUN_adm2.dbf  TUN_adm2.shp
> TUN_adm0.prj  TUN_adm0.shx  TUN_adm1.sbx  TUN_adm2.prj  TUN_adm2.shx
> TUN_adm0.sbn  TUN_adm1.dbf  TUN_adm1.shp  TUN_adm2.sbn  TUN_adm.zip
> TUN_adm0.sbx  TUN_adm1.prj  TUN_adm1.shx  TUN_adm2.sbx  TUN_readme.txt
> 
> TUN:
> TUN.dbf  TUN.prj  TUN.shp  TUN.shx
> 
> where:
> 
> ogr2ogr -f "ESRI Shapefile" TUN TUN_adm0.shp -nln TUN
> 
> creates a new DSN (TUN), and populates it with files. But in 1.8.0 (SVN
> 21235):
> 
> $ rm -rf TUN TUN.*
> # swap GDAL versions
> $ ogr2ogr --version
> GDAL 1.8dev, released 2010/01/19
> $ ogr2ogr --version
> GDAL 1.8dev, released 2010/01/19
> [rsb at reclus2 bigshape]$ ogr2ogr -f "ESRI Shapefile" TUN TUN_adm0.shp -nln
> TUN
> [rsb at reclus2 bigshape]$ ls TUN*
> TUN_adm0.dbf  TUN_adm0.shx  TUN_adm1.shp  TUN_adm2.sbx  TUN.prj
> TUN_adm0.prj  TUN_adm1.dbf  TUN_adm1.shx  TUN_adm2.shp  TUN_readme.txt
> TUN_adm0.sbn  TUN_adm1.prj  TUN_adm2.dbf  TUN_adm2.shx  TUN.shp
> TUN_adm0.sbx  TUN_adm1.sbn  TUN_adm2.prj  TUN_adm.zip   TUN.shx
> TUN_adm0.shp  TUN_adm1.sbx  TUN_adm2.sbn  TUN.dbf
> 
> TUN:
> 
> it creates the new DSN directory, but does not put the files inside it,
> but rather in the working directory. If the new DSN and layer have
> different names:
> 
> $ rm -rf TUN TUN.*
> $ ls TUN*
> $ ogr2ogr -f "ESRI Shapefile" TUN TUN_adm0.shp -nln TUN0
> $ ls TUN*
> 
> it works. This also affects the R OGR interface, but it can be reproduced
> with ogr2ogr, so it is inside OGR somewhere. Is the change intended?
> 
> With a different driver, it also works, so maybe it is in shape:
> 
> $ rm -rf TUN TUN.*
> $ ogr2ogr -f "Mapinfo File" TUN TUN_adm0.shp -nln TUN
> $ ls TUN*
> TUN_adm0.dbf  TUN_adm0.shp  TUN_adm1.sbn  TUN_adm2.dbf  TUN_adm2.shp
> TUN_adm0.prj  TUN_adm0.shx  TUN_adm1.sbx  TUN_adm2.prj  TUN_adm2.shx
> TUN_adm0.sbn  TUN_adm1.dbf  TUN_adm1.shp  TUN_adm2.sbn  TUN_adm.zip
> TUN_adm0.sbx  TUN_adm1.prj  TUN_adm1.shx  TUN_adm2.sbx  TUN_readme.txt
> 
> TUN:
> TUN.dat  TUN.id  TUN.map  TUN.tab
> 
> as expected. Have the changes "to improve the user Shapefile experience"
> got overenthusiastic, maybe? This breaks existing behaviour, so needs
> justification if sustained. It looks like line 509 in
> 
> trunk/gdal/ogr/ogrsf_frmts/shape/ogrshapedatasource.cpp
> 
> with:
> 
> EQUAL(CPLGetBasename(pszName), pszLayerName))
> 
> being the smoking gun change? The DSN is TUN, not TUN.shp, but is being
> mistaken for TUN.shp, isn't it?
> 
> Best wishes,
> 
> Roger