[PROJ] World UTM in a proper datum

[Lesparre, Jochem]

The use of WGS84(G1762) in international standards would make no sense, ITRF2014 should be used instead. So I strongly disagree with Greg on this (his point 7). But I admit this is a minor problem. However, I would prefer a different solution for the main problem too.

I think we should consider to NOT solve the inaccurate transformation of the ensemble (point 6), because keeping it like this forces people to stop using the ensemble label WGS84 for precise applications and make them use a precise realisation (e.g. ITRF2014) instead, thus solving the main problem completely (point 2, 3, 4, 5). For inaccurate applications the label WGS84 for the ensemble is fine, so we do not need to make people to change that (point 1).

If we partly solve the inaccuracy of the transformation of the ensemble (point 6) in one of the two ways Greg suggests, it will be much harder to make people aware of the remaining accuracy problem of the ensemble and it will therefore take much longer (if ever) too get that solved (point 1, 2, 3, 4, 5, 7).

Kind regards, Jochem


-----Original Message-----
From: PROJ <proj-bounces at lists.osgeo.org> On Behalf Of Greg Troxel
Sent: maandag 19 april 2021 15:06
To: proj at lists.osgeo.org
Subject: Re: [PROJ] World UTM in a proper datum


I think it's important to separate the multiple problems:

  1) People label data as "WGS84" when with omly a little care it could be
  labeled with a particular realization.

  2) People think their data is in WGS84 because it came out of a GNSS
  receiver, but they don't know if they were using SBAS, and even
  clueful people have a really hard time figuring out what datums the
  various SBAS are in.  And I have seen nothing that describes how any
  particular receiver deals with multiconstellation solutions and
  transforms (or not) among the frames, or e.g. what the output frame is
  when one configures for GLONASS only.

  3) Standards for data representation specify WGS84.  The two that come
  to mind are GPX and TMS, and I hope that's it.  In my view the bigger
  problem is TMS, because it is relatively easy to avoid GPX and use
  geojson instead in most cases, or it's simply "transform to GPX and
  load into device".

  4) People transform data to WGS84.  It doesn't really make sense to
  transform to an ensemble.  I suppose one could do a survey about
  prevalance and flip coins and pick a realization from the ensemble and
  transform to that, and then label it as the ensemble.  (Yes, I know
  that's ridiculous, but it points out how nonsensical transforming to
  an ensemble is.)

  5) People want to transform to WGS84, contrary to (4), because of (3).

  6) proj's behavior when transforming to an ensemble is sometimes to
  skip the transform because more or less the logical distance from
  source CRS to the ensemble is small compared to the ensemble intrinsic
  error.

  7) The fact that WGS84 was defined by one country is not a problem;
  many other datums were defined by one country.  If that were the only
  issue, people would only be talking about point 3 above, and arguing
  about the political point of saying WGS84(G1762) instead of ITRF2008,
  and not having data accuracy issues from incorrect null transforms.
  It would therefore not be a proj-land issue.

We in proj-land can't fix 1 and 2.  We certainly cannot fix 7.

We can rail against 3, but probably with little success.

Given 3, we can't do much about 5 and 4, other than to tell people to transform to the most recent realization instead and then use the data in situations calling for WGS84, but there's little hope of any significant number of them listening.  (I personally transform from
NAD83(2011) to ITRF2014 for use in web mapping, so that the transform actually happens.)

We can fix 6, where

  Ensembles have a notion of "most recent/best member".  (For WGS84 it
  is uncontroversial that today this is WGS84(G7162).)

  Transforms to an ensemble are interpreted as a transform to the best
  member of the ensemble.  The error budget does not include the
  ensemble fuzz, but the output is labeled as the ensemble as
  requested.  (Therefore if there is another transform in a pipeline the
  ensemble error will be attributed.)

  Transforms from an ensemble are treated as a concatenation of a
  transform from the ensemble to the best member, followed by the
  appopriate transform from the best member.  The first of those is a
  null transform carrying the ensemble intrinsic error, and the second
  is how it is

  (This requires adjusting the EPSG database to remove/avoid using
  transforms that are from or to the ensemble if there are reasonable
  paths from/to the best member)

  (Probably this should lead to examining all transforms to/from
  ensembles i the database and seeing if they are really to/from a
  specific member.)

Another approach (could be done in parallel) is:

  Take a poll and ask if anyone has any data in WGS84(TRANSIT).  Ask
  what the sigma is.  Ask them to explain how they obtained it.  Decline
  to accept "I had NAD83 and I just relabeled it" as valid.

  Failing to find any, decide that the term WGS84 as an ensemble will,
  in proj-land, not include WGS84(TRANSIT), and that anyone with data in
  that frame thus needs to label it precisely.  This removes most of the
  intrinsic error, creating a great benefit to many, while causing
  nearly zero harm to perhaps zero actual people.

  repeat for WGS84(G730), and possibly for the next, but by now the
  realizations have converged pretty well.

In other words, I assert that there is no data in either TRANSIT or G730 that has anywhere near 2m accuracy, and thus kicking them out of the ensemble -- which is a device to accomodate people who are being fuzzy
-- does no harm.

Greg


Disclaimer:
De inhoud van dit bericht is uitsluitend bestemd voor geadresseerde.
Gebruik van de inhoud van dit bericht door anderen zonder toestemming van het Kadaster
is onrechtmatig. Mocht dit bericht ten onrechte bij u terecht komen, dan verzoeken wij u
dit direct te melden aan de verzender en het bericht te vernietigen.
Aan de inhoud van dit bericht kunnen geen rechten worden ontleend.

Disclaimer:
The content of this message is meant to be received by the addressee only.
Use of the content of this message by anyone other than the addressee without the consent
of the Kadaster is unlawful. If you have received this message, but are not the addressee,
please contact the sender immediately and destroy the message.
No rights can be derived from the content of this message.