[PROJ] Seeking clarification on PROJ support for temporal transformations

[Even Rouault]

Hi Nyall,

> So, my initial questions are:
> 
> - are you aware of any client applications (outside of those provided
> with PROJ) which are currently utilising 4d transformations?

GDAL can, but this requires usual manual interaction to specify coordinate 
epoch.

> 
> - how complete is PROJ's implemention of ISO 19111? If I have a WKT2
> definition including epoch information, is PROJ able to read this and
> utilise it to perform 4d transforms? Does current PROJ c api allow
> retrieval of epoch information from a CRS object? (I can't see which
> method would do this in the API reference). And conversely, if you
> wanted to create a CRS object coinciding to a particular epoch, would
> you need to manually hand-craft a WKT2 string encapsulating this?

Ah, epochs... There are 2 kind of epochs to consider in WKT2:2018. One that 
characterizes the definition of a dynamic CRS

Like:

GEOGCRS["WGS 84 (G1762)",
  DYNAMIC[FRAMEEPOCH[2005.0]],
  TRF["World Geodetic System 1984 (G1762)",
    ELLIPSOID["WGS 84",6378137,298.257223563,LENGTHUNIT["metre",1.0]
    ]
  ],
  CS[ellipsoidal,3],
    AXIS["(lat)",north,ANGLEUNIT["degree",0.0174532925199433]],
    AXIS["(lon)",east,ANGLEUNIT["degree",0.0174532925199433]],
    AXIS["ellipsoidal height (h)",up,LENGTHUNIT["metre",1.0]]
]

That one is supported by PROJ, but there's no particular behaviour regarding 
it, except storing the frame epoch in a metadata, and be able to re-export it. 
This is mostly an information that has no direct consequence on time-based 
transformations (the frame epoch might be used as the central epoch for time-
dependent transformations from/to such a dynamic CRS, but I don't think this 
is necessarily always the case)

And one that characterizes the epoch of the coordinate themselves. Like:

COORDINATEMETADATA[
  GEOGCRS["WGS 84 (G1762)",
    DYNAMIC[FRAMEEPOCH[2005.0]],
    DATUM["World Geodetic System 1984 (G1762)",
      ELLIPSOID["WGS 84",6378137,298.257223563,LENGTHUNIT["metre",1.0]]
    ],
    CS[ellipsoidal,3],
      AXIS["(lat)",north,ANGLEUNIT["degree",0.0174532925199433]],
      AXIS["(lon)",east,ANGLEUNIT["degree",0.0174532925199433]],
      AXIS["ellipsoidal height (h)",up,LENGTHUNIT["metre",1.0]]
  ],
  EPOCH[2016.47]
]

That one is not supported currently by PROJ. The above object is not a CRS by 
itself, so I wasn't sure what to do with it. Probably it could be accepted as 
a CRS, and the EPOCH of the coordinate could be used to override/set the 
coordinate epoch in X,Y,Z,T tuples. We had a discussion a few weeks ago in a 
thread on this ML about this specfication of coordinate epochs together with 
the CRS, like "WGS 84 (G1726)@2016.47" :

https://lists.osgeo.org/pipermail/proj/2019-June/008668.html
https://lists.osgeo.org/pipermail/proj/2019-June/008669.html
https://lists.osgeo.org/pipermail/proj/2019-June/008670.html

What is supported in PROJ currently is using transformations between plate-
fixed CRS (like GDA2020) and Earth-fixed CRS (like ITRF), when a time-
dependent coordinate frame rotation/position vector transformation is 
available in the EPSG dataset (15-parameter Helmert transformation).

Changes of coordinate epochs, in the same dynamic CRS, like from CRS at XXXX to 
CRS at YYYY, which would likely use plate motion models, are not supported. 
There's no related data in the EPSG dataset for that, nor specific 
transformations in PROJ (but probably that time based Helmert could be used).
If you wanted to do that with a coordinate in Australia expressed in ITRF2014 
you could do that in 2 steps:
ITRF2014 -> GDA2020 (using epoch XXXX as the 4th coordinate)
GDA2020 -> ITRF2014 (using epoch YYYY as the 4th coordinate)

> 
> - (more on the gdal side, but..) does any existing data format support
> WKT2,

Yes, GeoPackage can support WKT2:2015 as a (official) extension (but WKT2:2015 
didn't support any of the above WKT2:2018 constructs). The GDAL GeoPackage 
driver in GDAL 3 supports this extension.

> and in particular, would allow a dataset to be referenced with
> an epoch based CRS definition?

That's the point which is particularly lacking. There are no raster/vector 
formats that have standardized a way of storing a coordinate epoch.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com