[gdal-dev] Motion: adopt RFC 81: support for coordinate epochs in geospatial formats

[Even Rouault]

Hi Sean,
> Hi Even, Howard:
>
> I'm inclined to approve, but I feel like there should be more 
> discussion, not just among PROJ developers and developers of cutting 
> edge formats. We should work to draw a wider group in on this.
Various OGC standard working groups are aware of that topic since this 
was raised I think in a plenary meeting more than one year ago. I see 
that in Testbed 17 the working group on the "OGC Features and Geometry 
JSON" (the "extension" of GeoJSON) is aware of that, but has not 
proposed any solution. I've just pointed them to my proposal.
>
> Howard, are you suggesting that there should be a configuration option 
> to opt in to this new feature?
>
> A surprise 1-2 meter shift is going to break builds and applications, 
> I agree. I think a lot of us are tolerating inaccuracy due to using 
> time-varying CRS but are going to be caught out by changes in the 
> actual numbers.
The mere introduction of this new capability isn't going to change any 
behavior. It is only going to change behavior if people do add a 
coordinate epoch in their datasets, and in that case, one can expect 
them to want more accurate coordinate transformations. That said adding 
a config option in the OGRProjCT class to ignore the coordinate epoch is 
trivial...
>
> Now that I think about it, I think the RFC should say more about what 
> it will do for the ensemble OGC:CRS84.
I'm not sure what kind of transformations will be possible when 
operating on the WGS 84 ensemble. Within what is available strictly 
speaking in EPSG, probably none. But we have had repeated discussions on 
the PROJ mailing list regarding this, and potentially one option could 
be to consider that a "recent" coordinate epoch on WGS 84 would mean 
that people actually use the latest WGS 84 realization, WGS 84 (G1762) 
currently, and so use transformations available from/to that 
realization. But nothing regarding this has been implemented yet. To get 
a time-dependent transformation, you need to specify a non-ensemble datum.
>
> To me, it seems that the parameterization or description of coordinate 
> epochs in OGC 19-005r4 is a bit sketchy.
Could you precise ?
>
> Even, are you saying that coordinate shifts in PROJ are entirely 
> functions of the datetime delta since the coordinate epoch?

Currently what is available in PROJ for transformations between a 
dynamic CRS and a static CRS is mostly through using 15-parameter 
Helmert transformation: 
https://proj.org/operations/transformations/helmert.html (*). Those 
Helmert transformations can have non-time dependent components (the 
"classic" 7-parameter transformtion, ala TOWGS84) + a time-dependant 
component that is generally a rotation in spherical coordinates w.r.t 
Earth centre and of an amplitude proportional to (coordinate_epoch - 
central_epoch) where central_epoch is a constant of the transformation 
(e.g the GDA2020 to ITRF2014 transformation uses central_epoch=2020.0). 
But they are not "entirely functions of the datetime delta", since the 
value of the longitude, latitude, ellipsoidal height of the coordinate 
has also an influence on the result (not completely sure to understand 
your question).

To be complete on the topic, there are a few esoteric cases where 
https://proj.org/operations/transformations/deformation.html grids are 
used, and the amplitude of the correction is also proportional to 
(coordinate_epoch - central_epoch), but this is specific to a NKG 
(Nordic countries) CRS code

And there's the very particular case of transformations between ITRF96 
and NZGD2000 (New Zealand) which uses a more complex deformation model 
(https://proj.org/operations/transformations/defmodel.html), where the 
time parameter can decide if corrections related to earthquakes are 
applied depending on the location and if you're before or after the date 
of the earthquake.

Even

-- 

http://www.spatialys.com
My software is free, but my time generally not.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20210525/7d50d80c/attachment-0001.html>