Brent, to use that experimental feature (available in 1.9.0), you need to set GDAL_FIX_ESRI_WKT=TOWGS84
Try the following: GDAL_FIX_ESRI_WKT=TOWGS84 gdalsrsinfo <yourfile.shp> If you see the towgs84 parameters in the PROJ.4 string, then it will work with ogr2ogr. This is documented in http://www.gdal.org/ogr/classOGRSpatialReference.html#ad556dfdc04d9ec5f1714fc6b5e0eb6a6 More information here http://trac.osgeo.org/gdal/ticket/4345 If it works, please report here, and if not, please send me your shapefile so I can make improvements Etienne On Sat, Feb 18, 2012 at 4:53 PM, Hermann Peifer <[email protected]> wrote: > On 18/02/2012 20:11, Brent Fraser wrote: >> >> I have some shapefiles I thought I would look at in Google Earth, so I >> used ogr2ogr (v1.8.1) to convert them to KML: >> >> ogr2ogr -f "KML" Lines_OGR.kml Lines.shp >> >> but they appeared about 100 meters Northeast of my expectation, leading >> me to believe there was a Datum problem. >> > > OGR interprets your .prj file like this: > +proj=utm +zone=35 +ellps=intl +units=m +no_defs > > ...and the EPSG code like this: > +proj=utm +zone=35 +ellps=intl +towgs84=-87,-98,-121,0,0,0,0 +units=m > +no_defs > > As there is no +towgs84 parameter in the 1st case, you end up with the 100m > shift. In trunk, there is some code that should enable some sort of EPSG > code auto-detection, but this is still experimental... > > Hermann > > > _______________________________________________ > gdal-dev mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/gdal-dev _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
