Script that chooses datum shifts ought to prefer those with better accuracy.

[mikrit]

The datum shift dragon seems to be almost slayed (  http://fwarmerdam.blogspot.com/2010_03_01_archive.html ). Great work.

The four heuristics, described on the blog, makes sense. But I'd like to see a fifth heuristic: Other things being equal, a datum shift with better accuracy should be preferred.

I've done similar work on my own, where I used the Accuracy field of EPSG. But in retrospect, this is a somewhat fragile approach, since the confidence of the Accuracy varies with the Information Source, and isn't stated. For example, "Cape to WGS 84(1)", epsg:1128, has an Accuracy of 9 m, but since the Information Source is US DMA, I conclude that the Accuracy confidence is only 2/3 (one sigma); my own rule of thumb then says that worst error can be 2.5 times larger, which is 22.5 m. On the other hand, "Cape to WGS 84(2)", epsg:1129, has an Accuracy of 15 m, but the Remarks indicate that this is the max error (100% confidence). So for Cape, I needed a manual choice, like yours in datum_shift_pref.csv, to ensure I got the better datum shift.

So I think it could be easier just to prefer a 7-parameter shift over a 3-parameter shift. This should usually give the better datum shift. (I know Noel Zinn might not agree, see Proj mailing list archives from October 2010, but I still think I am right).

Well, as I am writing this, I realize that the "7-better-than-3" heuristic would not help for Cape (I had a vague recollection that the better shift for Cape had 7 parameters, but I was wrong).

So, perhaps I should just suggest some combination of "7-better-than-3" and using the Accuracy field: either one of these heuristics, or both in some way. There will still be some datums, as the Cape example shows, where the script would choose an inferior datum shift. But in average, I think the quality of the selected datum shifts would increase.

Best regards.

[warmerdam]

Mikael,

I had contemplated using the accuracy in the selection but grew concerned that the more accurate conversions are often for more local areas and would be dangerous to select as a general transformation for a whole datum. Thus selecting the transformation with the largest possible area of use is a key criteria in the selection. However, there is no reason we could not use accuracy as a secondary criteria.

The whole discussion of 7 vs 3 on the list makes me hesitant to treat 7 parameter transforms as inherently better.

I'm going to just leave this ticket open for the time being since I'm not in datum management mode right now. But I'll keep it as an intention to update build_pcs.py to utilize accuracy as a secondary criteria in selection.

[mikrit]

Fine. (I agree that area is more important than accuracy.)