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

[Kristian Evers]

> On 25 Jun 2019, at 17:38, Even Rouault <even.rouault at spatialys.com> wrote:
> 
>> 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.

This could work, yes. Of course my suggestion above also extends to the source
epoch when applicable:

cs2cs  <source>@<source epoch>  <destination>@<destination 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.

Well, that’s a first for me :-)

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

Time. In hindsigt I think +t_0 would have been a better parameter name. When
I first wrote this code I thought it would be necessary to include more +t_
parameters, for example +t_obs that was used in the deformation operation initially.
You live and learn, I guess.

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