[PROJ] EPSG v10 update status

[Greg Troxel]

Nyall Dawson <nyall.dawson at gmail.com> writes:

>> With PROJ 8 / epsg10_part2, the WKT:2019 output of a CRS using WGS84
>> will show the ENSEMBLE[] and the 2m ensemble accuracy, so that's
>> already a form of warning (but probably most people not aware of the
>> issue won't realize what this means)
>
> Is the 2m accuracy for the ensemble correct here? I was of the
> understanding that the inherent ambiguity in EPSG:4326 is in the order
> of 10s of meters!

2m sounds reasonable to me.  Really only WGS84(TRANSIT) is that far off
from the rest.  This link:
  https://confluence.qps.nl/qinsy/latest/en/world-geodetic-system-1984-wgs84-182618391.html

claims that the shifts between realizations are

  0.70m, 0.20m, 0.06m, 0.06m, 0.01m

and later gives WGS84/ITRF transforms.

I have never heard of 10s of meters ambiguity in WGS84.  (Certainly, use
of GPS to determine positions with L1-only equipment with SA resulted in
the order of 100m error, but that's a different matter.)

Given that WGS84(G730) was introduced on 1994-06-29, it seems unlikely
that there is much data actually in WGS84TRANSIT), and extremely
unlikely that any of that has accuracy better than 10s of meters.

So I think it's a disservice to users to tar all "WGS84" data with even
2m of datum ensemble fuzz.  As a theoretical accuracy estimate, that's
one thing, but it's not ok to skip transforms.  As things stand, the
incorrect null transforms will introduce more error than the actual
original errors.

So I think the world should consider WGS84', defined as some WGS84 >=
WGS84(G730) and thus not WGS84(TRANSIT), has having 20cm or so of
ensemble error, and assume that people who say WGS84 and don't know what
they are doing mean WGS84', and that any errors from that assumption are
tiny compared to intrincsic error in WGS84(TRANSIT).
  

Another approach is to pop up a bunch of checkboxes and ask people to
check all realzations that are used in the layer, and have a series of
ensembles for the ensemble they actually have.  This reduces in practice
to "no, I don't have any WGS84(TRANSIT) data".

>> There's also the fact that there are none projected CRS available in
>> EPSG based on any of the realizations of WGS84 or ETRS89... So users
>> have no easy choice of a better alternative, if they want to stay in
>> the 'family' of the datum ensemble.
>
> Still, that's THEIR choice. At least they've been made aware of the
> consequences of their decision...

The real problem, not really fixable by us is that data is labeled as
WGS84, when it should be labeled more carefully, becuase of the
deficiency in the EPSG data set.  Granted, some might not be more
careful, but right now when using TMS it's basically not possible.

Can anyone explain why there aren't codepoints in EPSG for the various
WGS84 realizations.  I get it that there has never been a high-accuracy
method to access WGS84 realizations, but still they are important
concepts and thus should have codepoints.  Or does the new dataset come
with those and this is now fixed?

>> And not all datum ensembles are the same. (well, there are just 2
>> geodetic datums in EPSG for now :-)). But the ensemble accuracy of
>> ETRS89 is 0.1 m. Not the same story as the 2 m of WGS84. So for
>> European users ETRS89 is quite a reasonable choice for a lot of use
>> cases. I don't believe the use of a given realization of it is very
>> frequent, at least in the GIS field. People would actually rather
>> use a national datum when available (in France RGF93 which in its
>> latest version is a realization of ETRF2000 at epoch 2009.0, similar
>> story for CHTRF95 in Switzerland, etc.), mostly for legal reasons,
>> than a generic pan-european ETRF realization.

FWIW, NAD83 obviously belongs as a datum ensemble, and should have
roughly 2m as the ensemble accuracy.  (I wonder if ETRS89 has better
accuracy due to using GPS positioning in the first realization?  0.1m
would be remarkable for classical methods.)

> So maybe we should include the ensemble accuracy in the warning. Something like
>
> "Warning: saving this dataset to the xxxxx ensemble datum used by
> EPSG:xxxx will result in a maximum positional accuracy of x.x meters.
> If higher accuracy is required then an alternative CRS should be used.
> (Please contact even.rouault at spatialys.com to ask which CRS he'd
> recommend using for your particular circumstances.)" ;)

Sounds good :-) Here, if someone is trying to save as WGS84, they should
perhaps be advised to save as WGS84(G1762).  But they can't do that now.
(They can use ITRF2014, but it takes more knowledge to see that as
reasonable.)


Another view is to say that data in a datum ensemble should be presumed
to be in the most recent realization of the ensemble, with the caveat
that data that actually was in older realizations will acquire errors
from that mislabeling.  That puts the errors on the data that is more
likely to have them, and avoids degrading recent data or data that
originated in a higher-accuracy datum and is simply being stored.

-------------- 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/20201012/9e7fdca9/attachment.sig>