[PROJ] Seeking clarification on PROJ support for temporal transformations
Even Rouault
even.rouault at spatialys.com
Tue Aug 27 08:26:57 PDT 2019
On mardi 27 août 2019 19:42:31 CEST Nyall Dawson wrote:
> On Tue, 27 Aug 2019 at 19:19, Even Rouault <even.rouault at spatialys.com>
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%20Implementa
> tion%20Plan%20v2.1_0.pdf, it would be possible to manually perform this
> transformation in PROJ today...
Yes, this is a 14/15 parameter Helmert transformation.
>
> > Changes of coordinate epochs, in the same dynamic CRS, like from CRS at XXXX
> > to CRS at 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!)?
That would probably be the best solution.
> Is this being blocked by
> the EPSG registry itself and lack of means of encapsulating the
> transformation parameters?
Good questions. I dont't have definite answers.
The EPSG registry doesn't publish time-dependent transformations for CRS A to
CRS A currently, except for the Canadian NAD83(2011) CRS. Not sure if this is
a lack of interest, or data, or just that this isn't yet done, but will come
in future releases of the database.
I've heard there are global plate motions models, but haven't investigated
what they look like (grids, parametric models... ?) and if they are available
for "free". Otherwise you could also have models using methods like Helmert on
a per-area basis.
> Is the WKT2 standard capable of describing
> the details of a dynamic CRS transform?
WKT2 is just a generic framework to describe transformations. So you can
potentially put arbitrarily transformations in it. The key is to have
transformation names / codes that are implemented by PROJ with the appropriate
math, and up to now, I've used the ones codified by EPSG. And have the
relevant entries in the database.
> So effectively we're dependent on a future GeoPackage extension
> allowing WKT2:2018?
WKT2:2018 isn't yet published. Hopefully should come out "soon" from ISO /
OGC.
You'd likely depend on it for the COORDINATEMETADATA construct, if that is
allowed as a CRS for GeoPackage.
> 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).
Not sure to understand your "what it is", but pedantically, the epoch of the
dataset is not part of the CRS definition. Anyway...
--
Spatialys - Geospatial professional services
http://www.spatialys.com
More information about the PROJ
mailing list