[PROJ] World UTM in a proper datum

[Greg Troxel]

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
-------------- 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/20210419/8c9e59ef/attachment.sig>