[PROJ] EPSG v10 update status

[Greg Troxel]

Even Rouault <even.rouault at spatialys.com> writes:

> Sorry to just copy&paste
> https://docs.opengeospatial.org/as/18-005r4/18-005r4.html , but this is the inspiring 
> document for WKT:2019, all PROJ "metadata" handling and EPSG database content

No problem - thanks for the pointer.

> """
> 3.1.20
> dynamic reference frame
> dynamic datum
> reference frame in which the defining parameters include time evolution
> Note 1 to entry: The defining parameters that have time evolution are usually a coordinate 
> set.
> """

I interpet that as one of:

  datums defined by a set of station coordinates at a reference epoch
  and station velocities

  datums defined by a time-dependent transformation to another datum.

> Here's the extensive list of what is considered in EPSG as a dynamic datum:
>
> $ sqlite3 data/proj.db  "select 'EPSG:' || code || ', ' || name from geodetic_datum where 
> frame_reference_epoch is not null order by name" 
>
> (snip)
> EPSG:1291, Australian Terrestrial Reference Frame 2014
> EPSG:1272, IGb14
> EPSG:1165, International Terrestrial Reference Frame 2014
> EPSG:6324, WGS 72 Transit Broadcast Ephemeris
> EPSG:6760, World Geodetic System 1966
> EPSG:6322, World Geodetic System 1972
> EPSG:1154, World Geodetic System 1984 (G1150)
> EPSG:1155, World Geodetic System 1984 (G1674)
> EPSG:1156, World Geodetic System 1984 (G1762)
> EPSG:1152, World Geodetic System 1984 (G730)
> EPSG:1153, World Geodetic System 1984 (G873)
> EPSG:1166, World Geodetic System 1984 (Transit)
>
> From a quick look, at least for the datums with which I've some familiarity, it looks like they 
> are datums which are not crust-fixed.

NAD83(2011) is missing from this list, but it is almost always used as
"epoch 2010.0".

I see having a reference epoch as a statement that the coordinates of a
point in that datum change over time, not so much as the datum having a
time-dependent definition.   I realize it's hard to be non-circular here.

> For example, Australia's GDA2020 which is crust-fixed is not there, altough it has a time-
> dependent Helmert transformation to ATRF2014 and ITRF2014 (both listed above)

It looks like GDA2020 is defined in terms of ITRF2014 and a
time-dependent transformation.  Thus it seems squarely a dynamic datum
based on the above definition.


Part of what I'm having trouble understanding is that as an example,
when you get a solution out of NRCAN PPP as IRTRF2014, it is "epoch of
data", meaning the ITF2014 coordinates of the station at that moment.
ITRF2014's reference epoch is the date at which the published stations
had the published coordinates.  So data in IRF2014 may be of an epoch
that is not the reference epoch, and I think proj doesn't yet deal with
that.

This seems analogous to NAD83, which has the same issues, except:

  velocities are much lower (so more people can ignore them)

  it's conventional to use the reference epcoh coordinates for other
  stations so you get reference epoch coordinates for your station,
  modulo non-uniform motion (because you mostly stay on one plate and
  can get away with this)
  
>> datum ensembles... This is the most annoying part. The "World Geodetic
>> System 1984" and "European Terrestrial Reference System 1989" datum
>> have now in EPSG 10 a " ensemble" suffix in their names to reflect the
>> new nature of those objects.
>> I don't follow why NAD83 isn't listed here, and I wonder if you think
>> there's a good reason, or just 'it ought to be but nobody has done the
>> work yet'.
>
> I don't know why the NAD83 family isn't there. Probably depends on NOAA deciding on how 
> it wants to deal with that.

Interesting concept that they would decide :-)  Did NGA really weigh in
on what EPSG is doing, for WGS84?

(I don't mean to suggest their input isn't wanted or useful; I would
very much pay attentiont to anything anyone from either group said!)

All that said, NGS publications make it clear that NAD83 is very much a
datum ensemble by this definition.

>> Also, I wonder if ITRFxxxx is going to be treated as datum ensemble.  As
>> I understand it, ITRFxxxx are successive realizations for ITRS (which is
>> itself not a datum).
>
> I don't know. But given the below definition taken again from 18-005r4, I'm wondering if 
> someone who bothers enough to express coordinates in a ITRFxxxx datum would be really 
> keen in seeing them degraded in a coarser ITRS ensemble. You could just use the WGS 84 
> ensemble for the same purpose I guess.

I guess that's the big point.  As I see it, in an ideal world, we
wouldn't need datum ensembles because data would be labeled in the
actual realization it is in.   We need ensembles because of all the data
that is "I know this is in some flavor of WGS84 but I don't know which."

It's therefore a fair point that the world does not seem to have data
that is labeled as 'some kind of ITRF'.


> """
> A Datum Ensemble is a construct to facilitate the merging of realizations of the same 
> Terrestrial Reference System or Vertical Reference System for lower accuracy spatial 
> manipulation. In this document, datum ensemble is a collection of two or more reference 
> frames that are realizations of one Terrestrial or Vertical Reference System and which for all 
> but the highest accuracy requirements may be considered to be insignificantly different from 
> each other. Datasets referenced to the various realizations may be merged without change 
> of coordinates.

The last sentence is interesting and surprising.

I would expect that if there is a high-quality transform between two
members of an ensemble, and data is expressed in those members, that
transform will be used.

I would also expect an ensemble to implicitly declare a low-accuracy
transform (perhaps that accuracy is or should be carried in the ensemble
definition) among any two members.