Re: Seeking clarification on PROJ support for temporal transformations

On Tue, 27 Aug 2019 at 19:19, Even Rouault <[email protected]> wrote:
>
> 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).

Ok - so taking for example the parameters listed on page 9 of
http://icsm.gov.au/sites/default/files/2019-03/ATRF%20Technical%20Implementation%20Plan%20v2.1_0.pdf,
it would be possible to manually perform this transformation in PROJ
today...

> Changes of coordinate epochs, in the same dynamic CRS, like from CRS@XXXX to
> CRS@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).

What's the ultimate "end goal" here though? Will it reside as the
responsibility of client applications to create the helmert
transformation using these parameters? Will future versions of PROJ
have the internal smarts to avoid client code writing this logic
themselves (obviously, funding dependent!)? Is this being blocked by
the EPSG registry itself and lack of means of encapsulating the
transformation parameters? Is the WKT2 standard capable of describing
the details of a dynamic CRS transform? So many questions! :)

> > - (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.

So effectively we're dependent on a future GeoPackage extension
allowing WKT2:2018?

> > 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.

But, if I understand correctly, WKT2:2018 would be the ultimate answer
to this, in that it would allow us to specify the epoch of a dataset
as an integral part of the data's CRS definition (which it is). So the
standard exists already -- the problem is just(!) that no data formats
support the standard...

Nyall


>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
_______________________________________________
PROJ mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/proj