[PROJ] EPSG v10 update status

[Greg Troxel]

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

> Hi Even,
>
> I've been trying to get my head around how the introduction of datum
> ensembles will impact downstream projects, and specifically how things
> will/should change for users of these applications.
>
> Am I correct in my understanding that a ensemble is (at this stage) a
> "metadata only" concept, which indicates that the datum is only
> suitable for approximate spatial referencing? Or does a datum being
> flagged as an ensemble also influence the operations determined by
> PROJ and their order of precedence?
>
> How would you imagine a downstream project like QGIS should respond to
> this concept? Should we add a user-visible flag on any CRS definitions
> associated with a datum ensemble to say "Warning: ensemble datum, not
> for use in accurate spatial referencing"? What other user-facing
> changes do you think should be introduced?
>
> Nyall

Sort of related: I am having a CRS problem with QGIS and the world (not
fair to blame QGIS/proj) and I thought it might be helpful to explain
it.  It's a little long but I hope straightforward.

This note is written about qgis 3.10 and proj 6.3.2 on NetBSD.  I have
tried Mac QGIS but it has proj 5 and things are much worse.

I'm in Massachusetts, US, and thus have a lot of data in "NAD83(2011)
epoch 2010.0".  (skippable details: This is a plate-fixed datum, but
there is an epoch because coordinates change over time.  However, the
changes are at the maybe 2 mm/year level and thus ignored by pretty much
everyone.  One gets epoch 2010.0 values for GPS observations today,
because the practice is to use the epcoh 2010 values as the reference
station coordinates.  I'll drop the epoch 2010.0 in the rest of this
email, because that has nothing to do with my problem.)

Some of this data is from GPS processed by OPUS, and some from GNSS RTK
from my state's reference network.  My state also makes 15cm imagery
available as NAD83(2011) UTM and they report having have done ground
control to 0.1m RMS.  My checking of that vs GNSS fails to support a
hypothesis that the imagery is worse than 0.5m anywhere, eve allowing
for deck railings which are tricky for orthorectification.  The point is
that the accuracy of the imagery registration is much better than a
meter, and thus much lower than the NAD83/ITRF offset.

There is also vector data from the state, in NAD83(2011), with varying
accuracy.  Some of it (parcels) seems sub-meter in quality in some spots.

My state also publishes TMS of some of the layers, including the 15cm
imagery and the parcels layer.  These are therefore in WGS84 spherical
mercator.  Spherical mercator is of course not a problem, but this is
the fuzzy WGS84 datum ensemble.

Obviously when publishing as TMS the data should have been reprojected
from NAD83(2011) to WGS84(G1762) because original WGS84 is an irrelevant
historical curiousity for spring 2019 imagery ground controlled to
NAD83(2011).  I 95%+ think this is true, but I'm still trying to check,
confounded by the issue I'm writing about.

I also have some data in ITRF2014, basically output from NRCAN PPP and
OPUS.  I put this into a hand-created gpx.

I have some data in gpx format that was recorded via RTK with a
NAD83(2011) reference station.

There are precise transforms from NAD83(2011) to WGS84(G1762), or
certainly one can fake this in proj/QGIS by telling QGIS that the data
is ITRF2014.  When I do this (label the gpx with ITRF2014 as ITRF2014,
and the RTK/NAD83(2011) gpx as NAD83(2011)), everything lines up.

I am using NAD83(2011) UTM as my project CRS, to avoid reprojecting the
good imagery.

I noticed that the gpx with ITRF when I added it was treated as WGS84
(which is how gpx is defined) and given a null transform to NAD83.  That
was easy to fix by labeling it ITRF2014.

However, the iamgery that is in TMS ("WGS84") is I believe also not
transformed to NAD83, on the theory that a null transform is valid from
"WGS84" to NAD83(2011).  This is definitely a bug -- but it's hard to
say exactly where.

It also seems wrong that if I set project CRS to NAD83(2011) one thing
happens (null transform from WGS84) but if I set it to ITRF2014 another
(proper transfrom from NAD83 and a now-correct null transform from WGS84
to ITRF2014).

One theory is that it's a bug that TMS is defined in a datum ensemble,
rather then being defined to be in the latest WGS84.  But that seems
entirely unfixable.

My preferred theory is that while NAD83 and WGS84, whentreated as
ensembles, can be said to have a null transform (in that the oldest
versions of each can be said to match), that is not a reasoable
approach, and that while one should not ascribe high accuracy to a
transform with ensembles, the best choice oftransform is the one between
the most recent member of each ensemble.

This basically would result in treating WGS84 web mercator as probably
being WGS84(G1762) and transforming it as if it was.  This reduces the
error in the case when people are being careful/modern, and puts the
error on the cases when the data is actually in WGS84(TRANSIT) in which
case it already has a lot of fuzz.

Without this interpretation, I don't see how anyone can publish imagery
as TMS and expect users to be able to line anything up with it, without
meter-level errors or getting lucky about project CRS.

With this "choose best" approach, I don't see who is harmed.

This is sort of related to Nyall's question, and I thought the struggles
of someone who actually understands these issues and is still having
trouble might be useful.

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/20201011/7a101a9c/attachment.sig>