[gdal-dev] ogr2ogr reprojection, features are not transformed

[Etienne Tourigny]

Even,

I had tried that as I thought it could be the cause, however:

I get the same result, although the +towgs84 parameters are set in the
source OGRCT.

You can see the shapes are identical in size:
-rw------- 1 tourigny tourigny 371684 2011-11-15 20:52 LC_CIDADE_32722.shp
-rw------- 1 tourigny tourigny 371684 2011-11-15 19:35 LC_CIDADE_sad69.shp
-rw------- 1 tourigny tourigny 371684 2011-11-15 19:33 LC_CIDADE.shp
-rw------- 1 tourigny tourigny 371684 2011-11-15 20:46 LC_CIDADE_wgs84-2.shp

$ ogr2ogr --debug on -s_srs EPSG:4618 -t_srs EPSG:4326
LC_CIDADE_wgs84-2.shp LC_CIDADE.shpOGR:
OGROpen(LC_CIDADE.shp/0x9b5170) succeeded as ESRI Shapefile.OGRCT:
Source: +proj=longlat +ellps=aust_SA +towgs84=-57,1,-41,0,0,0,0
+no_defs OGRCT: Target: +proj=longlat +datum=WGS84 +no_defs Shape:
5806 features read on layer 'LC_CIDADE'.
When I try to transform to UTM, same things happens (shp file is not
modified). That is even more puzzling.

 $  ogr2ogr --debug on -s_srs EPSG:4618 -t_srs EPSG:32722
LC_CIDADE_32722.shp LC_CIDADE.shp
OGR: OGROpen(LC_CIDADE.shp/0xdd0650) succeeded as ESRI Shapefile.
OGRCT: Source: +proj=longlat +ellps=aust_SA +towgs84=-57,1,-41,0,0,0,0 +no_defs
OGRCT: Target: +proj=utm +zone=22 +south +datum=WGS84 +units=m +no_defs
Shape: DBF Codepage = LDID/87 for LC_CIDADE_32722
Shape: Treating as encoding 'ISO-8859-1'.
Shape: 5806 features read on layer 'LC_CIDADE'.


Posted 2 files at
http://dl.dropbox.com/u/15998214/LC_CIDADE.zip
http://dl.dropbox.com/u/15998214/brazil.zip


Thanks,
Etienne

On Tue, Nov 15, 2011 at 8:36 PM, Even Rouault
<even.rouault at mines-paris.org> wrote:
> Etienne,
>>
>> I am working with data in the SAD69 Datum (EPSG:4618) from Brazil's
>> IBGE and when I convert any data to/from WGS84 (EPSG:4362) it appears
>> that there is absolutely no shift in the coordinates.
>
> 4326 you meant ?
>
>>
>> I understand that they are similar datums, but one would expect a visible
>> shift. The only changes are in the files are the .prj file which contain
>> the SAD69 or WGS84 GEOGCS.
>>
>> I use the following command:
>>
>> $ ogr2ogr --debug on -t_srs EPSG:4326 LC_CIDADE_wgs84.shp LC_CIDADE.shp
>>
>> OGR: OGROpen(LC_CIDADE.shp/0x1384170) succeeded as ESRI Shapefile.
>> OGRCT: Source: +proj=longlat +ellps=aust_SA +no_defs
>> OGRCT: Target: +proj=longlat +datum=WGS84 +no_defs
>> Shape: DBF Codepage = LDID/87 for LC_CIDADE_wgs84
>> Shape: Treating as encoding 'ISO-8859-1'.
>> Shape: 5806 features read on layer 'LC_CIDADE'.
>
> The issue is that the .prj format (ESRI WKT) doesn't store the TOWGS84
> parameters. So you have to manually specify the source SRS so that GDAL can
> fetch it from the EPSG database.
>
> Try :
>
> ogr2ogr --debug on -s_srs EPSG:4618 -t_srs EPSG:4326 LC_CIDADE_wgs84.shp
> LC_CIDADE.shp
>
> Perhaps the shapefile driver could call AutoIdentifyEPSG() to fill the part
> losts in .prj format, but it wouldn't help for your case, because just a few
> SRS are autodetected currently.
>
> Best regards,
>
> Even
>