[PROJ] Seeking clarification on PROJ support for temporal transformations

[Kristian Evers]

Even,

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

A global plate motion model is part of ITRF2014 [0]. It comes in the form of 
Euler pole rotation parameters. They can be used in a time-dependent Helmert
Transformation. Some time ago I included all the parameters in the ITRF2014 init
file [1]. I use them to transform data from ITRF2014 to the local Greenlandic frame
GR96 (effectively ITRF94 at 1996.623). I've defined a pipeline like this:

proj = pipeline ellps = GRS80
            step inv init = ITRF2014:ITRF94 t_obs = 1996.623
            step inv init = ITRF2014:NOAM   t_epoch=1996.623

I believe that somewhere you can get a set of polygons that define the areas of the
Various tectonic plates. Possible a link is included in the paper in [0] (it's been a while
since I read it).

Regionally or locally it is not uncommon to have 

/Kristian

[0] https://academic.oup.com/gji/article-abstract/209/3/1906/3095992?redirectedFrom=fulltext
[1] https://github.com/OSGeo/PROJ/blob/master/data/ITRF2014


-----Original Message-----
From: PROJ <proj-bounces at lists.osgeo.org> On Behalf Of Even Rouault
Sent: 27. august 2019 18:27
To: Nyall Dawson <nyall.dawson at gmail.com>
Cc: PROJ <proj at lists.osgeo.org>
Subject: Re: [PROJ] Seeking clarification on PROJ support for temporal transformations

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.


> 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
_______________________________________________
PROJ mailing list
PROJ at lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/proj