[gdal-dev] Reprojection differs between FWtools versions

[Frank Warmerdam]

On 8/16/08, Koen Mannaerts [fietsnet.be] <koen at fietsnet.be> wrote:
>
>  Hi all,
>
>  I noticed that ogr2ogr in FWtools 1.0.0.a7 returns a different result than
> ogr2ogr in FWtools 2.2.0, 2.2.1.


Koen,

The behavior of PROJ.4 changed between PROJ 4.5.x and
PROJ 4.6.0.  In particular, PROJ.4 will no longer attempt to
apply a change of ellipsoid when going between different
ellipsoids if no datum information is provided.

>  No doubt it's due to what I pass as arguments. The idea is to convert
> Belgian Lambert, Belgian Datum shapefiles to Lat/Lon WGS84.
>  With the following arguments 1.0.0.a7 does this correctly, 2.2.1 produces
> polylines ~110m off to the north west (Belgium).
>
>  -f "ESRI Shapefile" -s_srs "+proj=lcc +lat_2=49.8333339 +lat_1=51.166667
> +lat_0=90.0000000 +lon_0=4.3674867 +x_0=150000.013 +y_0=5400088.438 +units=m
> +ellps=intl
> +towgs84=-99.059,53.322,-112.486,0.419,-0.830,1.885,-0.999999"
> -t_srs "+proj=latlong +ellps=WGS84"


I would suggest using +datum=WGS84 in the second definition,
instead of (or addition to) +ellps=WGS84.  You will also need some
datum shift info for the intl ellipsoid.  If you want the old behavior,
provide +towgs84=0,0,0.  This means only a change of ellipsoid
will be applied, but no other datum shifting will be done.

>  Do I need to express the argument otherwise to make it work in newer
> versions?

Please also keep in mind that if you play "fast and loose" with
datum shifts, there is a substantial risk that the results are
not accurate.  At the best of times, a datum shift usually
involves some error due to the approximate nature of datum
shift formulas.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent