[PROJ] Tie breakers used when ordering candidate operations

[Greg Troxel]

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>