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

[Roger Bivand]

On Tue, 14 Dec 2010, Even Rouault wrote:

> 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.

Even,

Thanks, that is great! Checked here, both with ogr2ogr and within the 
rgdal for the R interface.

Agus, you can regain the functionality by anonymous checkout of GDAL and 
installing from source - the odd "jumping the gun" binary you have should 
probably be abandoned.

Best wishes,

Roger

>
> 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
>

-- 
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