[gdal-dev] troubles with OVERRIDE_PROJ_DATUM_WITH_TOWGS84
G. Allegri
giohappy at gmail.com
Tue May 22 17:25:33 EDT 2012
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
2012/5/22 Frank Warmerdam <warmerdam at pobox.com>:
> On Tue, May 22, 2012 at 1:47 PM, G. Allegri <giohappy at gmail.com> wrote:
>>> Your issue with EPSG:3003 is of a different kind, and related to another change where the new logic now peaks up the EPSG preferred transformation whereas it didn't before
>>
>> Hi Even,
>> I have some difficults to follow the overall flow controlling the
>> peaking of the preferred transformation. What is the general rational
>> that define a transformation considered "preferred"?
>> In the case reported by Maddalena, the chosen transformation
>> parameters are (approximately) good for central Italy, while they are
>> not well suited for other regions of our country. In our case they're
>> "preferred" only by some italians :)
>
> Giovanni,
>
> The logic for deciding which available datum shift to use as
> preferred is embedded in:
>
> http://svn.osgeo.org/metacrs/geotiff/trunk/libgeotiff/csv/build_pcs.py
>
> The logic around setting pref_rec and preferred_op is the key.
>
> Skimming the logic it:
> * Prefers the transformation with the largest area of use.
> * avoids deprecated transformations.
> * avoids records that have been superceeded.
>
> I believe I discuss the topic in:
>
> http://fwarmerdam.blogspot.com/2010/03/in-last-few-weeks-i-believe-i-have-made.html
>
> There is the possibility of pre-setting a preferred datum transformation in:
>
> http://svn.osgeo.org/metacrs/geotiff/trunk/libgeotiff/csv/datum_shift_pref.csv
>
> If you feel there is a more appropriate set of shift parameters to use
> for the datum in question, please file a ticket (ideally against libgeotiff)
> with a justification I can reference when I add it in the file. Hopefully
> a reasonably convincing explanation.
>
> Also, please understand that no set of shift values is ideal and I
> prefer something broadly reasonable to something that is super
> in one local region and very poor in another where the datum is
> used. The "largest area of use" rule of thumb is intended to
> select on this basis.
>
> 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
More information about the gdal-dev
mailing list