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

[Roger Bivand]

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

-- 
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: Roger.Bivand at nhh.no