[PROJ] Tie breakers used when ordering candidate operations
Greg Troxel
gdt at lexort.com
Thu Feb 11 16:19:09 PST 2021
Nyall Dawson <nyall.dawson at gmail.com> writes:
> Well - as background I've been asked by ICSM (Australia) what's
> required to get proj's ordering of the operations for conversion of
> EPSG:4326 to 4283.
<wicked cantankerous (as we say in Boston)>
Stepping way back:
1) One bug in EPSG, from my viewpoint, is that they use the declared
accuracies of transforms as provided by the transform publisher. I
realize that departing from that is hard. But these are not really
consistent. EPSG does not intend these accuracies to be compared. Yet
proj does compare them. So EPSG probably would see this as a bug in
proj, yet not have a good answer for "is this transform better than the
other transform".
2) WGS84 is a datum ensemble:
While it's ok to accept data in WGS84, it is in 2020 not ok to produce
data labeled as WGS84, rather than say WGS84(G7162).
People talk about WGS84, but there is no accurate way to *access* any
of the members of the WGS84 ensemble, let alone accessing the
ensemble. AIUI, the most accurate way (for a person outside US DoD)
to access even WGS84(G1762) is via a non-differential (meaning not
even WAAS) solution of L1/L2C. If you use WAAS you are then in the
coordinate systme of the WAAS reference stations, which is really hard
to understand, but I think it's ITRF2008. However, ITRF2014 and
ITRF2008 are very close, ITRF2008 is pretty much the same thing as
WGS84(G1762), and ITRF2014 can be accessed.
https://www.unoosa.org/pdf/icg/2016/icg11/wgd/02wgd.pdf
3) The difficult problem here is the TMS spec defaulting to WGS84. I
have seen TMS data that turns out to actually be in WGS85(G1762)
published by MassGIS that checks at the 10 cm level vs positions in
NAD83(2011) epoch 2010.0 relative to the source imagery's native CRS and
RTK. I see this as a serious bug and TMS should be amended to specify
some ITRF instead. Until then, I see TMS as meaning that that data
should be in the realization of WGS84 that is in operational use for
GPS, and definitely not be considered to be in an ensemble.
So, I think people who ask for transforms to WGS84 should be told "That
doesn't really make sense any more; I will assume you mean WGS84(G1762)
which is basically the same as ITRF2014" and then you should use those
transforms instead.
</>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20210211/16315cec/attachment.sig>
More information about the PROJ
mailing list