[gdal-dev] troubles with OVERRIDE_PROJ_DATUM_WITH_TOWGS84

[Frank Warmerdam]

On Tue, May 22, 2012 at 2:25 PM, G. Allegri <giohappy at gmail.com> wrote:
> Thanks Frank for the clear explanation. I've missed your blog post.
> I think that the rational behind the sorting logic is the best that
> can be done if a choice must be made. The point is IF that choice
> should be made, and you give lot of reasons for it, and I suppose lot
> of users agree with having a default transformation. In general I
> think that transformation parameters shouldn't be provided as part of
> a CRS definition, but I suppose I'm not part of the majority of the
> users :)

Giovanni,

It is desirable for users to be able to select or at least override
the transformation.  But for automation of interactions with a
variety of services it is not appropriate to have to do that all the
time.

One thing I'd like to do is extend gdalsrsinfo to report a list of
potential datum shift operations available for the datum of a
given SRS, and some syntax to override the datum shift
operation when doing EPSG look ups.  For instance from
gdal/data/datum_shift.csv I see EPSG:4265 (Monte Mario)
has the following datum transformations possible:

422,1088,4265,4326,,Oil exploration and
production,2882,43,47.25,12,19.5,1,0,9603,-223.7,-67.38,1.34,,,,,0
423,1089,4265,4326,,Oil exploration and
production,2883,41.75,43.75,13.25,19,1,0,9603,-225.4,-67.7,7.85,,,,,0
424,1090,4265,4326,,Oil exploration and
production,2884,39.75,42,16,20,1,0,9603,-227.1,-68.1,14.4,,,,,0
425,1091,4265,4326,,Marine
navigation,2885,39.5,41,18,20,1,0,9603,-231.61,-68.21,13.93,,,,,0
426,1092,4265,4326,,Marine
navigation,2886,37,40.5,16,21,1,0,9603,-225.06,-67.37,14.61,,,,,0
427,1093,4265,4326,,Marine
navigation,2887,36,37.5,13,16,1,0,9603,-229.08,-65.73,20.21,,,,,0
428,1094,4265,4326,,Marine
navigation,2888,36.5,38.5,10,13,1,0,9603,-230.47,-56.08,22.43,,,,,0
429,1169,4265,4326,Derived at 1 station.,For military purposes.
Accuracy 25m in each
axis.,2339,38.5,41.5,8,10,1,0,9603,-225,-65,9,,,,,0
430,1660,4265,4326,"Parameter values from Monte Mario to ETRS89 (1)
(code 1659). Assumes ETRS89 and WGS 84 can be considered the same to
within the accuracy of the transformation.","Accuracy: 4
metres",2372,37.75,47.09,6.65,18.53,1,0,9606,-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68,1
431,1662,4265,4326,"Parameter values from Monte Mario to ETRS89 (2)
(code 1661). Assumes ETRS89 and WGS 84 can be considered the same to
within the accuracy of the transformation.","Accuracy: 4
metres",2339,38.5,41.5,8,10,1,0,9606,-168.6,-34,38.6,-0.374,-0.679,-1.379,-9.48,0
432,1664,4265,4326,"Parameter values from Monte Mario to ETRS89 (3)
(code 1663). Assumes ETRS89 and WGS 84 can be considered the same to
within the accuracy of the transformation.","Accuracy: 4
metres",2340,36.5,38.5,12,16,1,0,9606,-50.2,-50.4,84.8,-0.69,-2.012,0.459,-28.08,0

It would be nice to be able to use a parameter like:

-t_srs EPSG:3003/DATUMSHIFT:1662

in order to use the 3003 coordinate system but force selection
of the 1662 datum shift operation.

Perhaps now is a reasonable time for us to pursue this...

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