Ticket #33 (closed enhancement: wontfix)
Script that chooses datum shifts ought to prefer those with better accuracy.
|Reported by:||mikrit||Owned by:||warmerdam|
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.