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 <[email protected]> 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 > _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
