[PROJ] EPSG v10 update status

[Even Rouault]

Greg,

> 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.

I don't think the last sentence matches what the authors of standard have in mind (I don't 
think a datum can be *defined* by a transformation to another datum. a datum exists as 
such. one may establish transformations to others, but they are not defining. at least for 
geodetic datums. for vertical datums, some of them are indeed defined by a geoid model 
that applies to a given geodetic datum).
It is not because there's a known time-dependent transformation between DatumYYYY and 
ITRFxxxx that DatumYYYY is a dynamic datum.  The time-dependency comes from the fact 
that ITRFxxxx is a dynamic datum, so when changing coordinates between crust-fixed 
DatumYYYY and ITRFxxxx, you need to specify the epoch of coordinates in ITRFxxxx.

> 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.

GDA2020 is intended to be a 'static' datum. Coordinates of an object attached to the 
Australian plate don't change over time in GDA2020.

> 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.

That's not true. PROJ isn't able to deal properly (at least easily) with "point motion 
operation", that is transformations in the same dynamic datum, where coordinate epoch 
changes.

But it can transform coordinates from a plate-fixed/static datum (let's say GDA2020) to a 
dynamic datum (let's say ATRF2014/ITRF2014), or the reverse. When the transformation is 
published of course.

Demo:

$ projinfo -s GDA2020 -t ITRF2014 -o PROJ -q

+proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg 
+xy_out=rad +step +proj=cart +ellps=GRS80 +step +inv +proj=helmert +x=0 +y=0 +z=0 +rx=0 
+ry=0 +rz=0 +s=0 +dx=0 +dy=0 +dz=0 +drx=0.00150379 +dry=0.00118346 +drz=0.00120716 
+ds=0 +t_epoch=2020 +convention=coordinate_frame +step +inv +proj=cart +ellps=GRS80 
+step +proj=unitconvert +xy_in=rad +xy_out=deg +step +proj=axisswap +order=2,1

You can see in the above a time-dependent Helmert transformation with the reference 
epoch being 2020 (since GDA2020  and ITRF2014 are concidered coincident for all practical 
purposes at epoch 2020.0)

Now let's try at 2020, the reference epoch of the transformation:

$ echo -30 120 0 2020 | cct $(projinfo -d 8 -s GDA2020 -t ITRF2014 -o PROJ -q)
 -30.00000000   120.00000000    0.00000000     2020.0000

And in 2030:

$ echo -30 120 0 2030 | cct $(projinfo -d 8 -s GDA2020 -t ITRF2014 -o PROJ -q)
 -29.99999472   120.00000379   -0.00169912     2030.0000


> > 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?

Well, it **IS** the responsibility of geodetic agencies to speak actively with IOGP to make 
their data conveniently available to users. Each party might have their views on the best 
solution, but from exchanges I've been copied to, such discussions are done in a constructive 
way. If an agency doesn't speak with IOGP, their data might be just ignored, or if it is needed, 
IOGP or submitters to IOGP will make their own decisions. As an individual you can also talk 
with IOGP and submit change requests:
https://epsg.org/dataset-change-requests.html

Let be realist: the PROJ team isn't staffed to do the job that IOGP does with the EPSG 
dataset. My guesstimate would be that it must be at least one-full time geodesist to maintain 
and enchance it.

> 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."

There's a practical reason for datum ensembles to be used. It is to avoid the proliferation of 
"derived objects". A projected CRS points to a geographic CRS which points to a datum/
datum ensemble. Currently you have 120 projected UTM CRS over WGS84. If you wanted to 
have them for each of the realizations, you'd have to multiply that by 6. The database would 
grow unwidely.

> > 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.

Yes, there are definitely transformations that exist between ITRF realizations. It is just that if 
you've data referenced to a datum ensemble and not a given realization, this is game over: 
you don't know which realization, so no high accuracy transformation possible.

> 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.

Such transformations exist in the database as said above. They are just not exposed in the 
datum ensemble itself (it would be quite messy !)

$ sqlite3 data/proj.db  "select code, name from coordinate_operation_view where (name 
LIKE '%ITRF%to%ITRF%' or name LIKE '%WGS 84 (G%)%to%WGS 84 (G%)%') and auth_name 
= 'EPSG' and deprecated = 0 order by name"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20201010/8e838e80/attachment-0001.html>