A deprecated datum shift has been listed as preferred by datum_shift_pref.csv.

[mikrit]

I noticed that the current gcs.csv entry for EPSG:4313 (Belge 1972) is

4313,Belge 1972,6313,Reseau National Belge 1972,6313,9122,7022,8901,1,0,6422,15749,1,9607,-106.8686,52.2978,-103.7239,-0.3366,0.457,-1.8422,1.2747

(taken from  http://svn.osgeo.org/metacrs/geotiff/trunk/libgeotiff/csv). This means that the datum shift EPSG:15749 is used. But this datum shift was deprecated in March 2007, and replaced by EPSG:15929. Reason: "Error in sign of dS parameter value" (It should be -1.2747).

In general, some deprecated datum shifts can be quite useful. Because EPSG has sometimes deprecated an entire datum (and all associated datum shifts) for a trivial reason, like a spelling error in the name of the datum. In these cases, if you have old data files tagged with the deprecated datum code, it is useful if the datum shift remains in gcs.csv. (It wouldn't remain if all deprecated datum shifts are discarded when generating gcs.csv).

Unfortunately, I don't know any clever way to distinguish the harmful deprecated datum shifts from the useful ones. (Except by manual inspection, of course.)

[mikrit]

Sorry, I was jumping to conclusions. The python script in the trunk seems to check deprecation status correctly. However, in datum_shift_pref.csv, there is an entry that makes the deprecated datum shift 15749 the preferred one for this datum:

# From Jan:  http://bugzilla.remotesensing.org/show_bug.cgi?id=1336,
# and michael:  http://trac.osgeo.org/gdal/ticket/3362
#
4313,15749

So I have been involved in this before (I didn't remember). Looking at the GDAL ticket, my impression is that it was fixed at the time, but that recent work has unfixed it again.

It seems to be just a typo in the datum_shift_pref.csv entry. But I think the python script no longer needs any special hints for this datum, so that the entry can be removed. (If not, I think 15929 should be the preferred datum shift.)
Regards,

Mikael

[warmerdam]

With the override removed the default chose was transformation 1609 instead of 15929. 1609 is listed as being to an accuracy of 1m, while 15929 says 0.5 meters for the same area so I have adjusted the preference to be 15929 as Mikael suggests. Done in trunk in time for 1.4.0 release (r2026).