[gdal-dev] troubles with OVERRIDE_PROJ_DATUM_WITH_TOWGS84

[G. Allegri]

Frank,
I think the opposite. Maybe it's useful for users (even if I think
it's dangerous and should be avoided) to suggest an approximate
transformation, but for services the tranformation should be chosen
carefully and shouldn't assume a default one when a correct default
isn't available.

One proposals come from the GFOSS.it community is to consider a couple
of new fields to characterize the epsg code: an authority code, and
maybe an internal id for each CRS.
Having "official" EPSG codes following the EPSG Registry would keep
Proj4 consitent with a standard de facto. Then we could have other
"gdal", "gfoss.it", etc. codes derived from the offical EPSG but with
custom adjustments, like local transformations or whatelse.
Would it be technically difficult, while maintaining
retrocompatibility to let applications adopt it or not?

In the meanwhile I will ask the GFOSS.it community to consider the
opportunity to add a datum_shift_pref.csv row.

The idea of a DATUMSHIT selector would be nice ;)
giovanni

2012/5/22 Frank Warmerdam <warmerdam at pobox.com>:
> 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