[PROJ] [EXTERNAL] [gdal-dev] Static/Dynamic datum problems

[Even Rouault]

> I agree with that. We could simply adapt the same convention as used by
> geodesists: 
> 
> 	cs2cs  <source> <destination>@<destination epoch>

Makes sense (there would be the risk that people believes that the 
@destination epoch is part of the CRS designation, but
http://docs.opengeospatial.org/as/18-005r4/18-005r4.html#68 indeed uses it.

> How do you make the inverse transformation if you change the coordinate
> time from 2018.0 to 2025.0? 

Good question ! Actually in my ISO related work of past months, I spotted this 
issue but left it a bit apart as there were so many other hotter topics to 
deal with.

ISO-19111 identifies the optional sourceCoordinateEpoch and 
targetCoordinateEpoch to be properties of the CoordinateOperation class.
See http://docs.opengeospatial.org/as/18-005r4/18-005r4.html#58
In PROJ, we have a 4D X,Y,Z,time tuple instead, so there's a modelling gap 
here, which is propably the core reason for the issue you mention.

If we have
+proj=point_motion_geocentric +src_epoch= +tgt_epoch= +vx= +vy= +vz=
then this can be reversible.

You could have different modes:
- t_epoch only: then you take into account the input T, and this is not 
reversible
- s_epoch only: only possible to use in the reverse direction
- both: and then in the the forward direction, you must decide if you error 
out if the input T != src_epoch, or if you just override it with src_epoch. 
Similarly in the reverse direction.

If you chain a point motion with a 15-parameter Helmert as in some example of  
IOGP guidance note 25, then you need to change the coordinate epoch after the 
point motion operation (either by modifying the T in the coordinate tuple, or 
other internal means like filling the sourceCoordinateEpoch on the Helmert 
transformation which would then add a src_epoch parameter to the corresponding 
PROJ string ?), so that the 15-parameter Helmert operates on the new 
coordinate epoch.

> For the particular PJ object that made that
> transformation you will not be able to reverse it, since you specified
> +t_epoch=2025.0 your inverse operation will now be a null transformation
> moving the coordinate from 2025.0 to 2025.0. This is why I opted to not
> change the timestamps when I implemented the temporal Helmert.

Temporal Helmert nominately does not change the coordinate epoch, so that was 
a wise decision.

My example was clearly a hack to try to emulate the lack of a point motion 
operation for ITRF2014. In IOGP guidance note 25, point motion operations are 
either a velocity vector applied in the geocentric or geographic domains:
https://www.epsg-registry.org/export.htm?gml=urn:ogc:def:method:EPSG::1064
https://www.epsg-registry.org/export.htm?gml=urn:ogc:def:method:EPSG::1067
or with a grid:
https://www.epsg-registry.org/export.htm?gml=urn:ogc:def:method:EPSG::1070
But indeed there's perhaps a lack of expressing rotational terms in a compact 
way like Helmert allows to do.

> It is not set in stone that the inverse of an operation should be able to be
> created  but it definitely makes life simpler.

Indeed, I use and abuse of that a lot in the createOperations() code !

> It is a principal decision
> to make if we want break the possibility of creating the inverse of a
> temporal Helmert operation. 

As said above, I think the issue would affect only dedicated point motion 
operations, not 15-parameter Helmert whose central epoch parameter shouldn't 
affect coordinate epochs.
By the way: in 't_epoch', how should the t_ be interpreted: Time , Target, 
cenTral :-) ?

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