[PROJ] [EXTERNAL] [gdal-dev] Static/Dynamic datum problems
kreve at sdfe.dk
Tue Jun 25 08:51:11 PDT 2019
> 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
>> 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
> - 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:
> or with a grid:
> 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
More information about the PROJ