[PROJ] Seeking clarification on PROJ support for temporal transformations

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[PROJ] Seeking clarification on PROJ support for temporal transformations

Nyall Dawson
Hi Proj list!

I'm seeking some clarification on the current status in PROJ regarding
handling of 4d time-based coordinate transformations. My understanding
is that PROJ v6 supports this (at least for some transformation
types), but I'm unsure to what level.

So, my initial questions are:

- are you aware of any client applications (outside of those provided
with PROJ) which are currently utilising 4d transformations?

- how complete is PROJ's implemention of ISO 19111? If I have a WKT2
definition including epoch information, is PROJ able to read this and
utilise it to perform 4d transforms? Does current PROJ c api allow
retrieval of epoch information from a CRS object? (I can't see which
method would do this in the API reference). And conversely, if you
wanted to create a CRS object coinciding to a particular epoch, would
you need to manually hand-craft a WKT2 string encapsulating this?

- (more on the gdal side, but..) does any existing data format support
WKT2, and in particular, would allow a dataset to be referenced with
an epoch based CRS definition?

Cheers,
Nyall
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Seeking clarification on PROJ support for temporal transformations

Even Rouault-2
Hi Nyall,

> So, my initial questions are:
>
> - are you aware of any client applications (outside of those provided
> with PROJ) which are currently utilising 4d transformations?

GDAL can, but this requires usual manual interaction to specify coordinate
epoch.

>
> - how complete is PROJ's implemention of ISO 19111? If I have a WKT2
> definition including epoch information, is PROJ able to read this and
> utilise it to perform 4d transforms? Does current PROJ c api allow
> retrieval of epoch information from a CRS object? (I can't see which
> method would do this in the API reference). And conversely, if you
> wanted to create a CRS object coinciding to a particular epoch, would
> you need to manually hand-craft a WKT2 string encapsulating this?

Ah, epochs... There are 2 kind of epochs to consider in WKT2:2018. One that
characterizes the definition of a dynamic CRS

Like:

GEOGCRS["WGS 84 (G1762)",
  DYNAMIC[FRAMEEPOCH[2005.0]],
  TRF["World Geodetic System 1984 (G1762)",
    ELLIPSOID["WGS 84",6378137,298.257223563,LENGTHUNIT["metre",1.0]
    ]
  ],
  CS[ellipsoidal,3],
    AXIS["(lat)",north,ANGLEUNIT["degree",0.0174532925199433]],
    AXIS["(lon)",east,ANGLEUNIT["degree",0.0174532925199433]],
    AXIS["ellipsoidal height (h)",up,LENGTHUNIT["metre",1.0]]
]

That one is supported by PROJ, but there's no particular behaviour regarding
it, except storing the frame epoch in a metadata, and be able to re-export it.
This is mostly an information that has no direct consequence on time-based
transformations (the frame epoch might be used as the central epoch for time-
dependent transformations from/to such a dynamic CRS, but I don't think this
is necessarily always the case)

And one that characterizes the epoch of the coordinate themselves. Like:

COORDINATEMETADATA[
  GEOGCRS["WGS 84 (G1762)",
    DYNAMIC[FRAMEEPOCH[2005.0]],
    DATUM["World Geodetic System 1984 (G1762)",
      ELLIPSOID["WGS 84",6378137,298.257223563,LENGTHUNIT["metre",1.0]]
    ],
    CS[ellipsoidal,3],
      AXIS["(lat)",north,ANGLEUNIT["degree",0.0174532925199433]],
      AXIS["(lon)",east,ANGLEUNIT["degree",0.0174532925199433]],
      AXIS["ellipsoidal height (h)",up,LENGTHUNIT["metre",1.0]]
  ],
  EPOCH[2016.47]
]

That one is not supported currently by PROJ. The above object is not a CRS by
itself, so I wasn't sure what to do with it. Probably it could be accepted as
a CRS, and the EPOCH of the coordinate could be used to override/set the
coordinate epoch in X,Y,Z,T tuples. We had a discussion a few weeks ago in a
thread on this ML about this specfication of coordinate epochs together with
the CRS, like "WGS 84 (G1726)@2016.47" :

https://lists.osgeo.org/pipermail/proj/2019-June/008668.html
https://lists.osgeo.org/pipermail/proj/2019-June/008669.html
https://lists.osgeo.org/pipermail/proj/2019-June/008670.html

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

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).
If you wanted to do that with a coordinate in Australia expressed in ITRF2014
you could do that in 2 steps:
ITRF2014 -> GDA2020 (using epoch XXXX as the 4th coordinate)
GDA2020 -> ITRF2014 (using epoch YYYY as the 4th coordinate)

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

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

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Seeking clarification on PROJ support for temporal transformations

Nyall Dawson
On Tue, 27 Aug 2019 at 19:19, Even Rouault <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Seeking clarification on PROJ support for temporal transformations

Even Rouault-2
On mardi 27 août 2019 19:42:31 CEST Nyall Dawson wrote:
> On Tue, 27 Aug 2019 at 19:19, Even Rouault <[hidden email]>
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@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!)?

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
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Seeking clarification on PROJ support for temporal transformations

Nyall Dawson
On Wed, 28 Aug 2019 at 01:26, Even Rouault <[hidden email]> wrote:
>
> > 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...

Well -- I think it IS a fundamental part of the definition, of equal
importance to other parameters such as false easting/northing. Without
the epoch information the coordinate data becomes meaningless, and
it's required in order to accurately position them. While it would
theoretically be possible to store this information somewhere else in
a dataset's metadata, it's such an integral part of the CRS that
shoving it right into the CRS definition is the right way forward...

Nyall


>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Seeking clarification on PROJ support for temporal transformations

Kristian Evers-2
Nyall,

The epoch of a coordinate, e.g. the time it was measured, has nothing to do with the CRS definition.
But it is important once you want to transform from one CRS to another or propagate the coordinate
through time in the same CRS. Coordinates in a dataset will not necessarily have the same
measuring time/epoch, which is why it is not a good idea to store that information alongside the CRS
description. This is why 4D coordinates are necessary for dynamic CRS's. You need a XYZT geometry,
as it were.

There are of course exceptions, for instance a raster image where all pixels are captured simultaneous by the sensor. For that it would be nice to have a way to register the capture time in a standardized way. I am not sure if this is already possible with WKT2:2018.

/Kristian

-----Original Message-----
From: PROJ <[hidden email]> On Behalf Of Nyall Dawson
Sent: 27. august 2019 22:49
To: Even Rouault <[hidden email]>
Cc: PROJ <[hidden email]>
Subject: Re: [PROJ] Seeking clarification on PROJ support for temporal transformations

On Wed, 28 Aug 2019 at 01:26, Even Rouault <[hidden email]> wrote:
>
> > 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...

Well -- I think it IS a fundamental part of the definition, of equal
importance to other parameters such as false easting/northing. Without
the epoch information the coordinate data becomes meaningless, and
it's required in order to accurately position them. While it would
theoretically be possible to store this information somewhere else in
a dataset's metadata, it's such an integral part of the CRS that
shoving it right into the CRS definition is the right way forward...

Nyall


>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Seeking clarification on PROJ support for temporal transformations

Kristian Evers-2
In reply to this post by Even Rouault-2
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@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 <[hidden email]> On Behalf Of Even Rouault
Sent: 27. august 2019 18:27
To: Nyall Dawson <[hidden email]>
Cc: PROJ <[hidden email]>
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 <[hidden email]>
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@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!)?

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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Seeking clarification on PROJ support for temporal transformations

Chris Crook
In reply to this post by Kristian Evers-2
Nyall

I wonder if the distinction here is that a reference epoch is a parameter of some coordinate transformation functions, such as 14-15 (with ref epoch) Bursa Wolf transformation, rather than a fundamental parameter of the datum.  Similarly false easting is a parameter of some projection transformations.

Traditionally we also like to associate reference epochs with datums, which historically were somewhat arbitrary, for example when the datum was calculated or standardised.   These days they also tend to be used to as an epoch at which the datum was aligned with a global datum.  So in Australia the datum GDA2020 is defined to be aligned with ITRFxxxx (2014?) at 2020.  In New Zealand we used to say that a  NZGD2000 coordinate was "where an object was in 2000", but that is clearly a nonsense for something that didn't exist in 2000, and in any case it is not even true anymore as we have changed some coordinates following earthquakes, but they are still NZGD2000 coordinates.

Essential point is that some transformation functions use a reference epoch, some don't.  The epoch is a parameter of a transformation.  As Even also says, the critical thing is that there is an epoch associated with data.  Without that many datum transformations become even more ambiguous than they already are!

Cheers
Chris

-----Original Message-----
From: PROJ [mailto:[hidden email]] On Behalf Of Kristian Evers
Sent: Wednesday, 28 August 2019 8:13 a.m.
To: Nyall Dawson; Even Rouault
Cc: PROJ
Subject: Re: [PROJ] Seeking clarification on PROJ support for temporal transformations

Nyall,

The epoch of a coordinate, e.g. the time it was measured, has nothing to do with the CRS definition.
But it is important once you want to transform from one CRS to another or propagate the coordinate through time in the same CRS. Coordinates in a dataset will not necessarily have the same measuring time/epoch, which is why it is not a good idea to store that information alongside the CRS description. This is why 4D coordinates are necessary for dynamic CRS's. You need a XYZT geometry, as it were.

There are of course exceptions, for instance a raster image where all pixels are captured simultaneous by the sensor. For that it would be nice to have a way to register the capture time in a standardized way. I am not sure if this is already possible with WKT2:2018.

/Kristian

-----Original Message-----
From: PROJ <[hidden email]> On Behalf Of Nyall Dawson
Sent: 27. august 2019 22:49
To: Even Rouault <[hidden email]>
Cc: PROJ <[hidden email]>
Subject: Re: [PROJ] Seeking clarification on PROJ support for temporal transformations

On Wed, 28 Aug 2019 at 01:26, Even Rouault <[hidden email]> wrote:
>
> > 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...

Well -- I think it IS a fundamental part of the definition, of equal importance to other parameters such as false easting/northing. Without the epoch information the coordinate data becomes meaningless, and it's required in order to accurately position them. While it would theoretically be possible to store this information somewhere else in a dataset's metadata, it's such an integral part of the CRS that shoving it right into the CRS definition is the right way forward...

Nyall


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

________________________________

This message contains information, which may be in confidence and may be subject to legal privilege. If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify us immediately (Phone 0800 665 463 or [hidden email]) and destroy the original message. LINZ accepts no responsibility for changes to this email, or for any attachments, after its transmission from LINZ. Thank You.
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Seeking clarification on PROJ support for temporal transformations

Even Rouault-2
In reply to this post by Kristian Evers-2
On mardi 27 août 2019 20:12:27 EEST Kristian Evers wrote:
> Nyall,
>
> The epoch of a coordinate, e.g. the time it was measured, has nothing to do
> with the CRS definition.
 But it is important once you want to transform

> from one CRS to another or propagate the coordinate through time in the
> same CRS. Coordinates in a dataset will not necessarily have the same
> measuring time/epoch, which is why it is not a good idea to store that
> information alongside the CRS description. This is why 4D coordinates are
> necessary for dynamic CRS's. You need a XYZT geometry, as it were.
>
> There are of course exceptions, for instance a raster image where all pixels
> are captured simultaneous by the sensor. For that it would be nice to have
> a way to register the capture time in a standardized way. I am not sure if
> this is already possible with WKT2:2018.

The COORDINATEMETADATA[] WKT2:2018 construct I showed in the first reply to
this thread would be a way to do that. That construct is not acknowledged as a
CRS by itself but a pair consisting of a CRS + a coordinate epoch

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Seeking clarification on PROJ support for temporal transformations

Even Rouault-2
In reply to this post by Even Rouault-2
> WKT2:2018 isn't yet published. Hopefully should come out "soon" from ISO /
> OGC.

OK, I actually see it has now been finally published !
http://docs.opengeospatial.org/is/18-010r7/18-010r7.html

And the ISO19111 spec called on the OGC side as Abstract Topic 2 was already
available at
http://docs.opengeospatial.org/as/18-005r4/18-005r4.html

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Seeking clarification on PROJ support for temporal transformations

Nyall Dawson
In reply to this post by Kristian Evers-2
On Wed, 28 Aug 2019 at 06:12, Kristian Evers <[hidden email]> wrote:
>
> Nyall,
>
> The epoch of a coordinate, e.g. the time it was measured, has nothing to do with the CRS definition.
> But it is important once you want to transform from one CRS to another or propagate the coordinate
> through time in the same CRS. Coordinates in a dataset will not necessarily have the same
> measuring time/epoch, which is why it is not a good idea to store that information alongside the CRS
> description. This is why 4D coordinates are necessary for dynamic CRS's. You need a XYZT geometry,
> as it were.

Right... I've been down this rabbit hole already :) My thoughts:

Realistically, we are years away from having support for per-feature
(or per-node(!)) epochs in geospatial data. This brings with it a
whole raft of complications, including throwing out all existing data
formats and replacing them with new formats which support the extra
dimension, and also huge complexities in the UI/UX for end-user
applications. Then there's the added storage/memory/processing
overhead of handling the extra dimension for every geometry
feature/node.

In the near future we're best off aiming for per-dataset epochs. I.e.
a layer has a single reference epoch which applies to all
features/nodes in that layer. This is practically achievable within
the next couple of years, as (above discussions aside) we'd be able to
store the per-dataset epoch in the WKT2 definition of the layer (or in
some other metadata field, or as a sidecar file). The software would
then need to ensure that any newly added features are correctly
transformed back into the reference epoch for the layer to ensure all
features have the same consistent epoch, but that's relatively
straightforward.

Nyall

>
> There are of course exceptions, for instance a raster image where all pixels are captured simultaneous by the sensor. For that it would be nice to have a way to register the capture time in a standardized way. I am not sure if this is already possible with WKT2:2018.
>
> /Kristian
>
> -----Original Message-----
> From: PROJ <[hidden email]> On Behalf Of Nyall Dawson
> Sent: 27. august 2019 22:49
> To: Even Rouault <[hidden email]>
> Cc: PROJ <[hidden email]>
> Subject: Re: [PROJ] Seeking clarification on PROJ support for temporal transformations
>
> On Wed, 28 Aug 2019 at 01:26, Even Rouault <[hidden email]> wrote:
> >
> > > 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...
>
> Well -- I think it IS a fundamental part of the definition, of equal
> importance to other parameters such as false easting/northing. Without
> the epoch information the coordinate data becomes meaningless, and
> it's required in order to accurately position them. While it would
> theoretically be possible to store this information somewhere else in
> a dataset's metadata, it's such an integral part of the CRS that
> shoving it right into the CRS definition is the right way forward...
>
> Nyall
>
>
> >
> > --
> > Spatialys - Geospatial professional services
> > http://www.spatialys.com
> _______________________________________________
> PROJ mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/proj
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Seeking clarification on PROJ support for temporal transformations

Nyall Dawson
In reply to this post by Chris Crook
On Wed, 28 Aug 2019 at 06:27, Chris Crook <[hidden email]> wrote:
>
> Nyall
>
> I wonder if the distinction here is that a reference epoch is a parameter of some coordinate transformation functions, such as 14-15 (with ref epoch) Bursa Wolf transformation, rather than a fundamental parameter of the datum.  Similarly false easting is a parameter of some projection transformations.

Fair point - but I think Even's follow up regarding storing CRS + a
coordinate epoch (via COORDINATEMETADATA[] WKT2:2018 construct) at a
whole-of-dataset level would address this.

So I guess the EPSG registry (or similar) would include the CRS
definition with its component transformation parameters, and then the
COORDINATEMETADATA element gives the remaining piece of the puzzle
required to use the coordinates...

(This is my new favorite PROJ mailing list thread!)

Nyall


>
> Traditionally we also like to associate reference epochs with datums, which historically were somewhat arbitrary, for example when the datum was calculated or standardised.   These days they also tend to be used to as an epoch at which the datum was aligned with a global datum.  So in Australia the datum GDA2020 is defined to be aligned with ITRFxxxx (2014?) at 2020.  In New Zealand we used to say that a  NZGD2000 coordinate was "where an object was in 2000", but that is clearly a nonsense for something that didn't exist in 2000, and in any case it is not even true anymore as we have changed some coordinates following earthquakes, but they are still NZGD2000 coordinates.
>
> Essential point is that some transformation functions use a reference epoch, some don't.  The epoch is a parameter of a transformation.  As Even also says, the critical thing is that there is an epoch associated with data.  Without that many datum transformations become even more ambiguous than they already are!
>
> Cheers
> Chris
>
> -----Original Message-----
> From: PROJ [mailto:[hidden email]] On Behalf Of Kristian Evers
> Sent: Wednesday, 28 August 2019 8:13 a.m.
> To: Nyall Dawson; Even Rouault
> Cc: PROJ
> Subject: Re: [PROJ] Seeking clarification on PROJ support for temporal transformations
>
> Nyall,
>
> The epoch of a coordinate, e.g. the time it was measured, has nothing to do with the CRS definition.
> But it is important once you want to transform from one CRS to another or propagate the coordinate through time in the same CRS. Coordinates in a dataset will not necessarily have the same measuring time/epoch, which is why it is not a good idea to store that information alongside the CRS description. This is why 4D coordinates are necessary for dynamic CRS's. You need a XYZT geometry, as it were.
>
> There are of course exceptions, for instance a raster image where all pixels are captured simultaneous by the sensor. For that it would be nice to have a way to register the capture time in a standardized way. I am not sure if this is already possible with WKT2:2018.
>
> /Kristian
>
> -----Original Message-----
> From: PROJ <[hidden email]> On Behalf Of Nyall Dawson
> Sent: 27. august 2019 22:49
> To: Even Rouault <[hidden email]>
> Cc: PROJ <[hidden email]>
> Subject: Re: [PROJ] Seeking clarification on PROJ support for temporal transformations
>
> On Wed, 28 Aug 2019 at 01:26, Even Rouault <[hidden email]> wrote:
> >
> > > 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...
>
> Well -- I think it IS a fundamental part of the definition, of equal importance to other parameters such as false easting/northing. Without the epoch information the coordinate data becomes meaningless, and it's required in order to accurately position them. While it would theoretically be possible to store this information somewhere else in a dataset's metadata, it's such an integral part of the CRS that shoving it right into the CRS definition is the right way forward...
>
> Nyall
>
>
> >
> > --
> > Spatialys - Geospatial professional services http://www.spatialys.com
> _______________________________________________
> PROJ mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/proj
> _______________________________________________
> PROJ mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/proj
>
> ________________________________
>
> This message contains information, which may be in confidence and may be subject to legal privilege. If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify us immediately (Phone 0800 665 463 or [hidden email]) and destroy the original message. LINZ accepts no responsibility for changes to this email, or for any attachments, after its transmission from LINZ. Thank You.
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Seeking clarification on PROJ support for temporal transformations

Nyall Dawson
In reply to this post by Even Rouault-2
On Wed, 28 Aug 2019 at 01:26, Even Rouault <[hidden email]> wrote:
> > 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...

I concede this point -- the specs clearly are in your favour:

16.1: "Coordinate epoch is not part of a CRS definition, it is
additional metadata for the coordinates which is required to ensure
that they are unambiguous when referenced to a dynamic CRS."

Nyall

>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Seeking clarification on PROJ support for temporal transformations

Even Rouault-2
In reply to this post by Kristian Evers-2
>
> 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@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
>

That's interesting !

I believe there's a small mistake in the ITRF2014 file (or the IGN page might
have been updated in the meantime) for the ITRF2014:ITRF94 entry. It lacks a
+drz=0.00002 (the ITRF96 entry as well). I can see it in http://itrf.ign.fr/
doc_ITRF/Transfo-ITRF2014_ITRFs.txt and it is also there in the EPSG dataset:

$ projinfo -s ITRF2014 -t ITRF94 -o PROJ -q
+proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert
+xy_in=deg +xy_out=rad +step +proj=cart +ellps=GRS80 +step +inv +proj=helmert
+x=-0.0074 +y=0.0005 +z=0.0628 +rx=0 +ry=0 +rz=-0.00026 +s=-0.0038 +dx=-0.0001
+dy=0.0005 +dz=0.0033 +drx=0 +dry=0 +drz=-2e-05 +ds=-0.00012 +t_epoch=2010
+convention=position_vector +step +inv +proj=cart +ellps=GRS80 +step
+proj=unitconvert +xy_in=rad +xy_out=deg +step +proj=axisswap +order=2,1

(the signs are different due to EPSG having ITRF94 to ITRF2014 natively, and
thus PROJ applying a +inv)

Another detail: the pipeline you mention above is from GR96 to ITRF2014, right
(due to the 'inv' of ITRF2014:ITRF94) ?
And the last step which I assume is for the northamerica plate motion doesn't
seem to have any effect as you forced t_obs in the previous step to the
t_epoch of that step, so the time difference is 0.


$ echo " 2768773.7909  -1598552.2935  5500477.1338" | src/cct +proj=pipeline
+ellps=GRS80 +step +inv +init=ITRF2014:ITRF94 +t_obs=1996.623
 2768773.7710  -1598552.2904  5500477.1757

$ echo " 2768773.7909  -1598552.2935  5500477.1338" | src/cct +proj=pipeline
+ellps=GRS80 +step +inv +init=ITRF2014:ITRF94 +t_obs=1996.623 +step +inv
+init=ITRF2014:NOAM +t_epoch=1996.623
 2768773.7710  -1598552.2904  5500477.1757

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Seeking clarification on PROJ support for temporal transformations

Cameron Shorter
In reply to this post by Nyall Dawson
I'm interested in this thread because Joel Haasdyk (from NSW Spatial
Services) will be presenting at the OGC Technical Committee in a few
weeks on the topics of Australia's experience and pain that we are
facing with time-dependent datums, misaligned maps in web mapping, need
to update OGC standards, and a bit more.

I'm helping Joel collate the list of challenges and potential solutions,
and this thread is a topic which should be on the list.

In particular, I want to question the technical implementability of
storing observation time with every single coordinate. While this is an
option for a few high precision use cases, I'd argue that the vast
majority of use cases would want to store datasets in a globally
recognised fixed epoch to facilitate interoperability.

So a dataset could store:
* Coordinates of all features, stored at a fixed epoch
* Observation date
* Point Motion Operation (PCO) used to move to fixed epoch. (PCO is new
term for transformation between epochs). This PCO hopefully can be
applied in reverse to get back to the original observation date.

So what should I capture about feasibility of implementation, and
whether it addresses real world use cases.

The last draft of the paper I'm pulling together is here:
https://docs.google.com/document/d/15uBX2qICODRkiHXeksT0zEy6TuysanIxuc4anV0o5F0/edit?usp=drive_web&ouid=110542442124937335472

I'm planning to put out another version at the end of the week.

Cheers, Cameron

On 28/8/19 7:25 am, Nyall Dawson wrote:

> On Wed, 28 Aug 2019 at 01:26, Even Rouault <[hidden email]> wrote:
>>> 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...
> I concede this point -- the specs clearly are in your favour:
>
> 16.1: "Coordinate epoch is not part of a CRS definition, it is
> additional metadata for the coordinates which is required to ensure
> that they are unambiguous when referenced to a dynamic CRS."
>
> Nyall
>
On 28/8/19 6:53 am, Nyall Dawson wrote:

> Right... I've been down this rabbit hole already:)  My thoughts:
>
> Realistically, we are years away from having support for per-feature
> (or per-node(!)) epochs in geospatial data. This brings with it a
> whole raft of complications, including throwing out all existing data
> formats and replacing them with new formats which support the extra
> dimension, and also huge complexities in the UI/UX for end-user
> applications. Then there's the added storage/memory/processing
> overhead of handling the extra dimension for every geometry
> feature/node.
>
> In the near future we're best off aiming for per-dataset epochs. I.e.
> a layer has a single reference epoch which applies to all
> features/nodes in that layer. This is practically achievable within
> the next couple of years, as (above discussions aside) we'd be able to
> store the per-dataset epoch in the WKT2 definition of the layer (or in
> some other metadata field, or as a sidecar file). The software would
> then need to ensure that any newly added features are correctly
> transformed back into the reference epoch for the layer to ensure all
> features have the same consistent epoch, but that's relatively
> straightforward.
>
> Nyall
>

--
Cameron Shorter
Technology Demystifier
Open Technologies and Geospatial Consultant

M +61 (0) 419 142 254

_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Seeking clarification on PROJ support for temporal transformations

Nyall Dawson
On Wed, 28 Aug 2019 at 09:07, Cameron Shorter <[hidden email]> wrote:

>
> I'm interested in this thread because Joel Haasdyk (from NSW Spatial
> Services) will be presenting at the OGC Technical Committee in a few
> weeks on the topics of Australia's experience and pain that we are
> facing with time-dependent datums, misaligned maps in web mapping, need
> to update OGC standards, and a bit more.
>
> I'm helping Joel collate the list of challenges and potential solutions,
> and this thread is a topic which should be on the list.
>
> In particular, I want to question the technical implementability of
> storing observation time with every single coordinate. While this is an
> option for a few high precision use cases, I'd argue that the vast
> majority of use cases would want to store datasets in a globally
> recognised fixed epoch to facilitate interoperability.
>
> So a dataset could store:
> * Coordinates of all features, stored at a fixed epoch
> * Observation date

This raises an important distinction that we need to keep in mind when
epoch-based datasets become widespread -- we need to carefully present
coordinate epoch as a distinct and completely different concept vs
"observation date". While the WKT2 standard gives us a way of
representing the coordinate epoch, observation/capture date would sit
more comfortably along with other dataset metadata (eg. via
ISO19115)...

Nyall

> * Point Motion Operation (PCO) used to move to fixed epoch. (PCO is new
> term for transformation between epochs). This PCO hopefully can be
> applied in reverse to get back to the original observation date.
>
> So what should I capture about feasibility of implementation, and
> whether it addresses real world use cases.
>
> The last draft of the paper I'm pulling together is here:
> https://docs.google.com/document/d/15uBX2qICODRkiHXeksT0zEy6TuysanIxuc4anV0o5F0/edit?usp=drive_web&ouid=110542442124937335472
>
> I'm planning to put out another version at the end of the week.
>
> Cheers, Cameron
>
> On 28/8/19 7:25 am, Nyall Dawson wrote:
> > On Wed, 28 Aug 2019 at 01:26, Even Rouault <[hidden email]> wrote:
> >>> 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...
> > I concede this point -- the specs clearly are in your favour:
> >
> > 16.1: "Coordinate epoch is not part of a CRS definition, it is
> > additional metadata for the coordinates which is required to ensure
> > that they are unambiguous when referenced to a dynamic CRS."
> >
> > Nyall
> >
> On 28/8/19 6:53 am, Nyall Dawson wrote:
>
> > Right... I've been down this rabbit hole already:)  My thoughts:
> >
> > Realistically, we are years away from having support for per-feature
> > (or per-node(!)) epochs in geospatial data. This brings with it a
> > whole raft of complications, including throwing out all existing data
> > formats and replacing them with new formats which support the extra
> > dimension, and also huge complexities in the UI/UX for end-user
> > applications. Then there's the added storage/memory/processing
> > overhead of handling the extra dimension for every geometry
> > feature/node.
> >
> > In the near future we're best off aiming for per-dataset epochs. I.e.
> > a layer has a single reference epoch which applies to all
> > features/nodes in that layer. This is practically achievable within
> > the next couple of years, as (above discussions aside) we'd be able to
> > store the per-dataset epoch in the WKT2 definition of the layer (or in
> > some other metadata field, or as a sidecar file). The software would
> > then need to ensure that any newly added features are correctly
> > transformed back into the reference epoch for the layer to ensure all
> > features have the same consistent epoch, but that's relatively
> > straightforward.
> >
> > Nyall
> >
>
> --
> Cameron Shorter
> Technology Demystifier
> Open Technologies and Geospatial Consultant
>
> M +61 (0) 419 142 254
>
> _______________________________________________
> PROJ mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/proj
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Seeking clarification on PROJ support for temporal transformations

Joel Haasdyk
In reply to this post by Nyall Dawson
Apologies for coming in late to the conversation, and replying to the DIGEST no less...


Certainly,
It is extremely important to bring into focus and differentiate between different ‘epochs’, e.g.
     (1) ‘Epoch of Expression’ (i.e. the date at which the coordinate is described w.r.t. the CRS).
          a. Explicit for time-dependence frames ITRF2014 (@epoch of expression)
          b. Implicit for static frames:  GDA2020, implicitly @2020.0)
          c .Forgotten for the masses: WGS84(@epoch of expression???)
     (2 ) ‘Epoch of Observation’ (i.e. the timestamp at which the data was gathered)
     (3) ‘Realisation epoch’, (i.e. ITRF2014 vs ITRF2008)
     (4) ‘Reference epoch’ (i.e. ITRF2014 has reference epoch 2010-01-01)
          ARRRGGG!  
          I've just discovered that EPSG calls this the ‘realization epoch’. Why does it call (3) then??
           See EPSG::7789 (ITRF2014), 5332 (ITRF2008), 4269 (NAD83), 7842 (GDA2020)
 

Of all of these, I think ‘Epoch of Expression’ is paramount!
     • ‘Epoch of Expression’ is mandatory to properly describe the coordinate position in the CRS.
     • ‘Epoch of Observation’ on the other hand is optional metadata.
          Along with transformation methods (or lineage), this can be employed to recreate the original observations…
           but is not _necessary_ to describe position.
           Note1)
               “ITRF2014(@2010.0), observed at [unknown epoch]”is more immediately useful, than
               “ITRF2014(@unknown epoch), observed at 2015.9”
           Note2)
                As the rate of change of a dynamic feature approaches the rate of change of the tectonic plate,
                the appropriate choice of how to describe the feature becomes more interesting.
                ITRF2014(@2010) @timeseries isn’t a very informative dataset for a perfectly plate-fixed feature! ;-)
     • ‘Realisation epoch’ simply forms part of the CRS definition, but can be a source of confusion for users.
          This is simply an ‘identifier’ which usually denotes the era in which a datum was defined
          (often denoting the latest data employed in the definition of the datum).
     • ‘Reference Epoch’ is just used under the bonnet. E.g. the reference point (t0) for defining time-dependent
          parameters such as in a 15 parameter transformation.

 
As for feature vs dataset level metadata, I’ve always thought feature level metadata was not practicable to implement, as Nyall has suggested below.
However, if I were to create a standard from scratch I would suggest that it should / could simply support the level of detail required by the user or application.
          • Provide dataset level Epoch of Expression, and WHERE REQUIRED allow features to specify their own epoch which supersedes (or modifies) the data-level metadata.
          • Separately, provide for (optional) dataset-level Epoch of Observation, which is also extensible to the feature level if required.
          •Granularity of epoch could be achieved by the supplied precision,
             i.e. decimal places of the year, although this isn’t generally human readable
             (but we live with Lat and Long in this form…)

Sorry for the long post... that's what I get for reading all your contributions in one go!

Joel Haasdyk | GDA2020 Implementation Program Manager (NSW)
--------------------------------------------------------------------------------------------------
Spatial Services | Department of Customer Service
p (02) 87376322 | m 0427 229 589
e [hidden email]
w www.spatial.nsw.gov.au
Level 14 West, McKell Building, 2-24 Rawson Place, Sydney NSW 2000

https://www.icsm.gov.au/gda2020 (FAQs & Forum)
--------------------------------------------------------------------------------------------------


-----Original Message-----
From: PROJ <[hidden email]> On Behalf Of [hidden email]
Sent: Wednesday, 28 August 2019 9:07 AM
To: [hidden email]
Subject: PROJ Digest, Vol 10, Issue 20

Send PROJ mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        https://clicktime.symantec.com/37hUAv7MQPNaUxxwsjPTNpr7Vc?u=https%3A%2F%2Flists.osgeo.org%2Fmailman%2Flistinfo%2Fproj
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific than "Re: Contents of PROJ digest..."


Today's Topics:

   1. Re: Seeking clarification on PROJ support for temporal
      transformations (Even Rouault)
   2. Re: Seeking clarification on PROJ support for temporal
      transformations (Nyall Dawson)
   3. Re: Seeking clarification on PROJ support for temporal
      transformations (Nyall Dawson)
   4. Re: Seeking clarification on PROJ support for temporal
      transformations (Nyall Dawson)
   5. Re: Seeking clarification on PROJ support for temporal
      transformations (Even Rouault)
   6. Re: Seeking clarification on PROJ support for temporal
      transformations (Cameron Shorter)


----------------------------------------------------------------------

Message: 1
Date: Tue, 27 Aug 2019 23:34:35 +0300
From: Even Rouault <[hidden email]>
To: [hidden email]
Subject: Re: [PROJ] Seeking clarification on PROJ support for temporal
        transformations
Message-ID: <4138519.eZhnYTKfua@even-i700>
Content-Type: text/plain; charset="us-ascii"

> WKT2:2018 isn't yet published. Hopefully should come out "soon" from
> ISO / OGC.

OK, I actually see it has now been finally published !
https://clicktime.symantec.com/3JRKQYkqoKCNcPGd1eoi9AL7Vc?u=http%3A%2F%2Fdocs.opengeospatial.org%2Fis%2F18-010r7%2F18-010r7.html

And the ISO19111 spec called on the OGC side as Abstract Topic 2 was already available at https://clicktime.symantec.com/3RHKY1g1VYCn14v29BsQFC97Vc?u=http%3A%2F%2Fdocs.opengeospatial.org%2Fas%2F18-005r4%2F18-005r4.html

--
Spatialys - Geospatial professional services https://clicktime.symantec.com/3LRVJEevh8vqiD9DDeK88QQ7Vc?u=http%3A%2F%2Fwww.spatialys.com


------------------------------

Message: 2
Date: Wed, 28 Aug 2019 06:53:22 +1000
From: Nyall Dawson <[hidden email]>
To: Kristian Evers <[hidden email]>
Cc: Even Rouault <[hidden email]>, PROJ
        <[hidden email]>
Subject: Re: [PROJ] Seeking clarification on PROJ support for temporal
        transformations
Message-ID:
        <[hidden email]>
Content-Type: text/plain; charset="UTF-8"

On Wed, 28 Aug 2019 at 06:12, Kristian Evers <[hidden email]> wrote:
>
> Nyall,
>
> The epoch of a coordinate, e.g. the time it was measured, has nothing to do with the CRS definition.
> But it is important once you want to transform from one CRS to another or propagate the coordinate
> through time in the same CRS. Coordinates in a dataset will not necessarily have the same
> measuring time/epoch, which is why it is not a good idea to store that information alongside the CRS
> description. This is why 4D coordinates are necessary for dynamic CRS's. You need a XYZT geometry,
> as it were.

Right... I've been down this rabbit hole already :) My thoughts:

Realistically, we are years away from having support for per-feature
(or per-node(!)) epochs in geospatial data. This brings with it a
whole raft of complications, including throwing out all existing data
formats and replacing them with new formats which support the extra
dimension, and also huge complexities in the UI/UX for end-user
applications. Then there's the added storage/memory/processing
overhead of handling the extra dimension for every geometry
feature/node.

In the near future we're best off aiming for per-dataset epochs. I.e.
a layer has a single reference epoch which applies to all
features/nodes in that layer. This is practically achievable within
the next couple of years, as (above discussions aside) we'd be able to
store the per-dataset epoch in the WKT2 definition of the layer (or in
some other metadata field, or as a sidecar file). The software would
then need to ensure that any newly added features are correctly
transformed back into the reference epoch for the layer to ensure all
features have the same consistent epoch, but that's relatively
straightforward.

Nyall

>
> There are of course exceptions, for instance a raster image where all pixels are captured simultaneous by the sensor. For that it would be nice to have a way to register the capture time in a standardized way. I am not sure if this is already possible with WKT2:2018.
>
> /Kristian
>
> -----Original Message-----
> From: PROJ <[hidden email]> On Behalf Of Nyall Dawson
> Sent: 27. august 2019 22:49
> To: Even Rouault <[hidden email]>
> Cc: PROJ <[hidden email]>
> Subject: Re: [PROJ] Seeking clarification on PROJ support for temporal transformations
>
> On Wed, 28 Aug 2019 at 01:26, Even Rouault <[hidden email]> wrote:
> >
> > > 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...
>
> Well -- I think it IS a fundamental part of the definition, of equal
> importance to other parameters such as false easting/northing. Without
> the epoch information the coordinate data becomes meaningless, and
> it's required in order to accurately position them. While it would
> theoretically be possible to store this information somewhere else in
> a dataset's metadata, it's such an integral part of the CRS that
> shoving it right into the CRS definition is the right way forward...
>
> Nyall
>
>
> >
> > --
> > Spatialys - Geospatial professional services
> > https://clicktime.symantec.com/3LRVJEevh8vqiD9DDeK88QQ7Vc?u=http%3A%2F%2Fwww.spatialys.com
> _______________________________________________
> PROJ mailing list
> [hidden email]
> https://clicktime.symantec.com/37hUAv7MQPNaUxxwsjPTNpr7Vc?u=https%3A%2F%2Flists.osgeo.org%2Fmailman%2Flistinfo%2Fproj


------------------------------

Message: 3
Date: Wed, 28 Aug 2019 06:56:09 +1000
From: Nyall Dawson <[hidden email]>
To: Chris Crook <[hidden email]>
Cc: Kristian Evers <[hidden email]>, Even Rouault
        <[hidden email]>,  PROJ <[hidden email]>
Subject: Re: [PROJ] Seeking clarification on PROJ support for temporal
        transformations
Message-ID:
        <[hidden email]>
Content-Type: text/plain; charset="UTF-8"

On Wed, 28 Aug 2019 at 06:27, Chris Crook <[hidden email]> wrote:
>
> Nyall
>
> I wonder if the distinction here is that a reference epoch is a parameter of some coordinate transformation functions, such as 14-15 (with ref epoch) Bursa Wolf transformation, rather than a fundamental parameter of the datum.  Similarly false easting is a parameter of some projection transformations.

Fair point - but I think Even's follow up regarding storing CRS + a
coordinate epoch (via COORDINATEMETADATA[] WKT2:2018 construct) at a
whole-of-dataset level would address this.

So I guess the EPSG registry (or similar) would include the CRS
definition with its component transformation parameters, and then the
COORDINATEMETADATA element gives the remaining piece of the puzzle
required to use the coordinates...

(This is my new favorite PROJ mailing list thread!)

Nyall


>
> Traditionally we also like to associate reference epochs with datums, which historically were somewhat arbitrary, for example when the datum was calculated or standardised.   These days they also tend to be used to as an epoch at which the datum was aligned with a global datum.  So in Australia the datum GDA2020 is defined to be aligned with ITRFxxxx (2014?) at 2020.  In New Zealand we used to say that a  NZGD2000 coordinate was "where an object was in 2000", but that is clearly a nonsense for something that didn't exist in 2000, and in any case it is not even true anymore as we have changed some coordinates following earthquakes, but they are still NZGD2000 coordinates.
>
> Essential point is that some transformation functions use a reference epoch, some don't.  The epoch is a parameter of a transformation.  As Even also says, the critical thing is that there is an epoch associated with data.  Without that many datum transformations become even more ambiguous than they already are!
>
> Cheers
> Chris
>
> -----Original Message-----
> From: PROJ [mailto:[hidden email]] On Behalf Of Kristian Evers
> Sent: Wednesday, 28 August 2019 8:13 a.m.
> To: Nyall Dawson; Even Rouault
> Cc: PROJ
> Subject: Re: [PROJ] Seeking clarification on PROJ support for temporal transformations
>
> Nyall,
>
> The epoch of a coordinate, e.g. the time it was measured, has nothing to do with the CRS definition.
> But it is important once you want to transform from one CRS to another or propagate the coordinate through time in the same CRS. Coordinates in a dataset will not necessarily have the same measuring time/epoch, which is why it is not a good idea to store that information alongside the CRS description. This is why 4D coordinates are necessary for dynamic CRS's. You need a XYZT geometry, as it were.
>
> There are of course exceptions, for instance a raster image where all pixels are captured simultaneous by the sensor. For that it would be nice to have a way to register the capture time in a standardized way. I am not sure if this is already possible with WKT2:2018.
>
> /Kristian
>
> -----Original Message-----
> From: PROJ <[hidden email]> On Behalf Of Nyall Dawson
> Sent: 27. august 2019 22:49
> To: Even Rouault <[hidden email]>
> Cc: PROJ <[hidden email]>
> Subject: Re: [PROJ] Seeking clarification on PROJ support for temporal transformations
>
> On Wed, 28 Aug 2019 at 01:26, Even Rouault <[hidden email]> wrote:
> >
> > > 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...
>
> Well -- I think it IS a fundamental part of the definition, of equal importance to other parameters such as false easting/northing. Without the epoch information the coordinate data becomes meaningless, and it's required in order to accurately position them. While it would theoretically be possible to store this information somewhere else in a dataset's metadata, it's such an integral part of the CRS that shoving it right into the CRS definition is the right way forward...
>
> Nyall
>
>
> >
> > --
> > Spatialys - Geospatial professional services https://clicktime.symantec.com/3LRVJEevh8vqiD9DDeK88QQ7Vc?u=http%3A%2F%2Fwww.spatialys.com
> _______________________________________________
> PROJ mailing list
> [hidden email]
> https://clicktime.symantec.com/37hUAv7MQPNaUxxwsjPTNpr7Vc?u=https%3A%2F%2Flists.osgeo.org%2Fmailman%2Flistinfo%2Fproj
> _______________________________________________
> PROJ mailing list
> [hidden email]
> https://clicktime.symantec.com/37hUAv7MQPNaUxxwsjPTNpr7Vc?u=https%3A%2F%2Flists.osgeo.org%2Fmailman%2Flistinfo%2Fproj
>
> ________________________________
>
> This message contains information, which may be in confidence and may be subject to legal privilege. If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify us immediately (Phone 0800 665 463 or [hidden email]) and destroy the original message. LINZ accepts no responsibility for changes to this email, or for any attachments, after its transmission from LINZ. Thank You.


------------------------------

Message: 4
Date: Wed, 28 Aug 2019 07:25:37 +1000
From: Nyall Dawson <[hidden email]>
To: Even Rouault <[hidden email]>
Cc: PROJ <[hidden email]>
Subject: Re: [PROJ] Seeking clarification on PROJ support for temporal
        transformations
Message-ID:
        <CAB28AsinJ5yAjW9bXy9wc2h91i74zAXf07BefBQuLCdrpF3q=[hidden email]>
Content-Type: text/plain; charset="UTF-8"

On Wed, 28 Aug 2019 at 01:26, Even Rouault <[hidden email]> wrote:
> > 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...

I concede this point -- the specs clearly are in your favour:

16.1: "Coordinate epoch is not part of a CRS definition, it is
additional metadata for the coordinates which is required to ensure
that they are unambiguous when referenced to a dynamic CRS."

Nyall

>
> --
> Spatialys - Geospatial professional services
> https://clicktime.symantec.com/3LRVJEevh8vqiD9DDeK88QQ7Vc?u=http%3A%2F%2Fwww.spatialys.com


------------------------------

Message: 5
Date: Wed, 28 Aug 2019 00:50:14 +0300
From: Even Rouault <[hidden email]>
To: Kristian Evers <[hidden email]>
Cc: Nyall Dawson <[hidden email]>, PROJ <[hidden email]>
Subject: Re: [PROJ] Seeking clarification on PROJ support for temporal
        transformations
Message-ID: <2096164.pDk9JYgsY7@even-i700>
Content-Type: text/plain; charset="us-ascii"

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

That's interesting !

I believe there's a small mistake in the ITRF2014 file (or the IGN page might
have been updated in the meantime) for the ITRF2014:ITRF94 entry. It lacks a
+drz=0.00002 (the ITRF96 entry as well). I can see it in https://clicktime.symantec.com/3DYnpibATcWTafjkYa66Zbh7Vc?u=http%3A%2F%2Fitrf.ign.fr%2F
doc_ITRF/Transfo-ITRF2014_ITRFs.txt and it is also there in the EPSG dataset:

$ projinfo -s ITRF2014 -t ITRF94 -o PROJ -q
+proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert
+xy_in=deg +xy_out=rad +step +proj=cart +ellps=GRS80 +step +inv +proj=helmert
+x=-0.0074 +y=0.0005 +z=0.0628 +rx=0 +ry=0 +rz=-0.00026 +s=-0.0038 +dx=-0.0001
+dy=0.0005 +dz=0.0033 +drx=0 +dry=0 +drz=-2e-05 +ds=-0.00012 +t_epoch=2010
+convention=position_vector +step +inv +proj=cart +ellps=GRS80 +step
+proj=unitconvert +xy_in=rad +xy_out=deg +step +proj=axisswap +order=2,1

(the signs are different due to EPSG having ITRF94 to ITRF2014 natively, and
thus PROJ applying a +inv)

Another detail: the pipeline you mention above is from GR96 to ITRF2014, right
(due to the 'inv' of ITRF2014:ITRF94) ?
And the last step which I assume is for the northamerica plate motion doesn't
seem to have any effect as you forced t_obs in the previous step to the
t_epoch of that step, so the time difference is 0.


$ echo " 2768773.7909  -1598552.2935  5500477.1338" | src/cct +proj=pipeline
+ellps=GRS80 +step +inv +init=ITRF2014:ITRF94 +t_obs=1996.623
 2768773.7710  -1598552.2904  5500477.1757

$ echo " 2768773.7909  -1598552.2935  5500477.1338" | src/cct +proj=pipeline
+ellps=GRS80 +step +inv +init=ITRF2014:ITRF94 +t_obs=1996.623 +step +inv
+init=ITRF2014:NOAM +t_epoch=1996.623
 2768773.7710  -1598552.2904  5500477.1757

Even

--
Spatialys - Geospatial professional services
https://clicktime.symantec.com/3LRVJEevh8vqiD9DDeK88QQ7Vc?u=http%3A%2F%2Fwww.spatialys.com


------------------------------

Message: 6
Date: Wed, 28 Aug 2019 09:07:00 +1000
From: Cameron Shorter <[hidden email]>
To: [hidden email]
Cc: Joel Haasdyk <[hidden email]>
Subject: Re: [PROJ] Seeking clarification on PROJ support for temporal
        transformations
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=utf-8; format=flowed

I'm interested in this thread because Joel Haasdyk (from NSW Spatial
Services) will be presenting at the OGC Technical Committee in a few
weeks on the topics of Australia's experience and pain that we are
facing with time-dependent datums, misaligned maps in web mapping, need
to update OGC standards, and a bit more.

I'm helping Joel collate the list of challenges and potential solutions,
and this thread is a topic which should be on the list.

In particular, I want to question the technical implementability of
storing observation time with every single coordinate. While this is an
option for a few high precision use cases, I'd argue that the vast
majority of use cases would want to store datasets in a globally
recognised fixed epoch to facilitate interoperability.

So a dataset could store:
* Coordinates of all features, stored at a fixed epoch
* Observation date
* Point Motion Operation (PCO) used to move to fixed epoch. (PCO is new
term for transformation between epochs). This PCO hopefully can be
applied in reverse to get back to the original observation date.

So what should I capture about feasibility of implementation, and
whether it addresses real world use cases.

The last draft of the paper I'm pulling together is here:
https://clicktime.symantec.com/3TXKQycNfbKob6ERPJq5kdE7Vc?u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F15uBX2qICODRkiHXeksT0zEy6TuysanIxuc4anV0o5F0%2Fedit%3Fusp%3Ddrive_web%26ouid%3D110542442124937335472

I'm planning to put out another version at the end of the week.

Cheers, Cameron

On 28/8/19 7:25 am, Nyall Dawson wrote:

> On Wed, 28 Aug 2019 at 01:26, Even Rouault <[hidden email]> wrote:
>>> 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...
> I concede this point -- the specs clearly are in your favour:
>
> 16.1: "Coordinate epoch is not part of a CRS definition, it is
> additional metadata for the coordinates which is required to ensure
> that they are unambiguous when referenced to a dynamic CRS."
>
> Nyall
>
On 28/8/19 6:53 am, Nyall Dawson wrote:

> Right... I've been down this rabbit hole already:)  My thoughts:
>
> Realistically, we are years away from having support for per-feature
> (or per-node(!)) epochs in geospatial data. This brings with it a
> whole raft of complications, including throwing out all existing data
> formats and replacing them with new formats which support the extra
> dimension, and also huge complexities in the UI/UX for end-user
> applications. Then there's the added storage/memory/processing
> overhead of handling the extra dimension for every geometry
> feature/node.
>
> In the near future we're best off aiming for per-dataset epochs. I.e.
> a layer has a single reference epoch which applies to all
> features/nodes in that layer. This is practically achievable within
> the next couple of years, as (above discussions aside) we'd be able to
> store the per-dataset epoch in the WKT2 definition of the layer (or in
> some other metadata field, or as a sidecar file). The software would
> then need to ensure that any newly added features are correctly
> transformed back into the reference epoch for the layer to ensure all
> features have the same consistent epoch, but that's relatively
> straightforward.
>
> Nyall
>

--
Cameron Shorter
Technology Demystifier
Open Technologies and Geospatial Consultant

M +61 (0) 419 142 254



------------------------------

Subject: Digest Footer

_______________________________________________
PROJ mailing list
[hidden email]
https://clicktime.symantec.com/37hUAv7MQPNaUxxwsjPTNpr7Vc?u=https%3A%2F%2Flists.osgeo.org%2Fmailman%2Flistinfo%2Fproj


------------------------------

End of PROJ Digest, Vol 10, Issue 20
************************************

**********************************************************************************
This email message and any attached files is confidential and intended solely for the use of the individual or entity to whom it is addressed and may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you have received this email in error, delete all copies and notify the sender.

This email is subject to copyright. No part of it should be reproduced, published, communicated or adapted without the copyright owner's written consent. No employee or agent is authorised to conclude any binding agreement on behalf of the Department of Customer Service (DCS) by email without express written confirmation.

The views or opinions presented in this email are solely those of the author and do not necessarily represent those of the DCS. DCS accepts no liability for any loss or damage arising from the use of this email and the recipient should check this email and any attached files for the presence of viruses.

**********************************************************************************
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Seeking clarification on PROJ support for temporal transformations

Joel Haasdyk
In reply to this post by Nyall Dawson
Indeed,

Any regular tectonic plate motion can be expressed as a 3 parameter Euler Pole, which can in turn be expressed in the familiar Helmert 14 (15) parameter transformation format, as three Cartesian axial rotation rates (all other components equal 0).
See https://geodesy.noaa.gov/PUBS_LIB/NOAA_TR_NOS_NGS_0062.pdf
See http://www.quickclose.com.au/StanawayetalREFAGppt.pdf 

Case in point are these:
EPSG:: 8049 GDA2020 <=> ITRF2014, with reference epoch 2020.0)
EPSG::8448 GDA2020 <=> WGS84(G1792), with 'parameter reference epoch' @2020.0)
Where GDA2020 is essentially a snapshot of ITRF2014 at 2020.0.

So EPSG can and does publish time-dependent transformations...
(this is not new, e.g. EPSG::8078 ITRF2000 <=> ITRF2014 for example)
...just not (yet) explicitly from CRS_A(@epoch1) to CRS_A(@epoch2). I could be wrong.
However... EPSG::8049 gives you all the info you need to transform from
ITRF2014(@epoch1) <=> ITRF2014(@2020.0) <=> ITRF2014(@epoch2)

Joel Haasdyk

------------------------------

Message: 5 from Digest 20
Date: Wed, 28 Aug 2019 00:50:14 +0300
From: Even Rouault <[hidden email]>
To: Kristian Evers <[hidden email]>
Cc: Nyall Dawson <[hidden email]>, PROJ <[hidden email]>
Subject: Re: [PROJ] Seeking clarification on PROJ support for temporal
        transformations
Message-ID: <2096164.pDk9JYgsY7@even-i700>
Content-Type: text/plain; charset="us-ascii"

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

----
Also copied from Archive:

>Even Rouault even.rouault at spatialys.com
>Tue Aug 27 08:26:57 PDT 2019
>
>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.

**********************************************************************************
This email message and any attached files is confidential and intended solely for the use of the individual or entity to whom it is addressed and may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you have received this email in error, delete all copies and notify the sender.

This email is subject to copyright. No part of it should be reproduced, published, communicated or adapted without the copyright owner's written consent. No employee or agent is authorised to conclude any binding agreement on behalf of the Department of Customer Service (DCS) by email without express written confirmation.

The views or opinions presented in this email are solely those of the author and do not necessarily represent those of the DCS. DCS accepts no liability for any loss or damage arising from the use of this email and the recipient should check this email and any attached files for the presence of viruses.

**********************************************************************************
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Seeking clarification on PROJ support for temporal transformations

Kristian Evers-2
In reply to this post by Even Rouault-2
> I believe there's a small mistake in the ITRF2014 file (or the IGN page might
> have been updated in the meantime) for the ITRF2014:ITRF94 entry. It lacks a
> +drz=0.00002 (the ITRF96 entry as well).

Good catch! Originally I entered the parameters manually so it is not a surprise
that I've gotten a few of them wrong.

> Another detail: the pipeline you mention above is from GR96 to ITRF2014, right
> (due to the 'inv' of ITRF2014:ITRF94) ?
> And the last step which I assume is for the northamerica plate motion doesn't
> seem to have any effect as you forced t_obs in the previous step to the
> t_epoch of that step, so the time difference is 0.

Yes. My example was quite sloppy and without context. I just wanted to give
you an idea of how to do it but I should have used a few more minutes to
give a proper example. You are right about the +t_obs parameter. My example
is outdated, this worked with PROJ 5 but since then the +t_obs parameter has
been removed. The first step works though, as you can see here:

>echo 1109816.3447  -1370509.0484  6108938.7008 2019.5 | cct.exe +proj=pipeline +step +init=ITRF2014:NOAM +t_epoch=1996.623
 1109815.8649  -1370509.0724  6108938.7826     2019.5000

This used to work with my example from the previous mail since the +t_obs
parameter did not change the t component of a coordinate.

A better approach here would be to have an operation than can change
the t component as part of the plate motion step. If I remember correctly
something like that is already present in the EPSG database so it should
just be a matter of implementing that.

/Kristian

-----Original Message-----
From: Even Rouault <[hidden email]>
Sent: 28. august 2019 00:50
To: Kristian Evers <[hidden email]>
Cc: Nyall Dawson <[hidden email]>; PROJ <[hidden email]>
Subject: Re: [PROJ] Seeking clarification on PROJ support for temporal transformations

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

That's interesting !

I believe there's a small mistake in the ITRF2014 file (or the IGN page might
have been updated in the meantime) for the ITRF2014:ITRF94 entry. It lacks a
+drz=0.00002 (the ITRF96 entry as well). I can see it in http://itrf.ign.fr/
doc_ITRF/Transfo-ITRF2014_ITRFs.txt and it is also there in the EPSG dataset:

$ projinfo -s ITRF2014 -t ITRF94 -o PROJ -q
+proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert
+xy_in=deg +xy_out=rad +step +proj=cart +ellps=GRS80 +step +inv +proj=helmert
+x=-0.0074 +y=0.0005 +z=0.0628 +rx=0 +ry=0 +rz=-0.00026 +s=-0.0038 +dx=-0.0001
+dy=0.0005 +dz=0.0033 +drx=0 +dry=0 +drz=-2e-05 +ds=-0.00012 +t_epoch=2010
+convention=position_vector +step +inv +proj=cart +ellps=GRS80 +step
+proj=unitconvert +xy_in=rad +xy_out=deg +step +proj=axisswap +order=2,1

(the signs are different due to EPSG having ITRF94 to ITRF2014 natively, and
thus PROJ applying a +inv)

Another detail: the pipeline you mention above is from GR96 to ITRF2014, right
(due to the 'inv' of ITRF2014:ITRF94) ?
And the last step which I assume is for the northamerica plate motion doesn't
seem to have any effect as you forced t_obs in the previous step to the
t_epoch of that step, so the time difference is 0.


$ echo " 2768773.7909  -1598552.2935  5500477.1338" | src/cct +proj=pipeline
+ellps=GRS80 +step +inv +init=ITRF2014:ITRF94 +t_obs=1996.623
 2768773.7710  -1598552.2904  5500477.1757

$ echo " 2768773.7909  -1598552.2935  5500477.1338" | src/cct +proj=pipeline
+ellps=GRS80 +step +inv +init=ITRF2014:ITRF94 +t_obs=1996.623 +step +inv
+init=ITRF2014:NOAM +t_epoch=1996.623
 2768773.7710  -1598552.2904  5500477.1757

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Seeking clarification on PROJ support for temporal transformations

Kristian Evers-2
In reply to this post by Nyall Dawson
> Right... I've been down this rabbit hole already :)

Me too. Contrary to you, I have the luxury of NOT maintaining a widely used
GIS application and can simply live in a perfect dream world where we do
all things geodesy correctly :-)

/Kristian

-----Original Message-----
From: Nyall Dawson <[hidden email]>
Sent: 27. august 2019 23:53
To: Kristian Evers <[hidden email]>
Cc: Even Rouault <[hidden email]>; PROJ <[hidden email]>
Subject: Re: [PROJ] Seeking clarification on PROJ support for temporal transformations

On Wed, 28 Aug 2019 at 06:12, Kristian Evers <[hidden email]> wrote:
>
> Nyall,
>
> The epoch of a coordinate, e.g. the time it was measured, has nothing to do with the CRS definition.
> But it is important once you want to transform from one CRS to another or propagate the coordinate
> through time in the same CRS. Coordinates in a dataset will not necessarily have the same
> measuring time/epoch, which is why it is not a good idea to store that information alongside the CRS
> description. This is why 4D coordinates are necessary for dynamic CRS's. You need a XYZT geometry,
> as it were.

Right... I've been down this rabbit hole already :) My thoughts:

Realistically, we are years away from having support for per-feature
(or per-node(!)) epochs in geospatial data. This brings with it a
whole raft of complications, including throwing out all existing data
formats and replacing them with new formats which support the extra
dimension, and also huge complexities in the UI/UX for end-user
applications. Then there's the added storage/memory/processing
overhead of handling the extra dimension for every geometry
feature/node.

In the near future we're best off aiming for per-dataset epochs. I.e.
a layer has a single reference epoch which applies to all
features/nodes in that layer. This is practically achievable within
the next couple of years, as (above discussions aside) we'd be able to
store the per-dataset epoch in the WKT2 definition of the layer (or in
some other metadata field, or as a sidecar file). The software would
then need to ensure that any newly added features are correctly
transformed back into the reference epoch for the layer to ensure all
features have the same consistent epoch, but that's relatively
straightforward.

Nyall

>
> There are of course exceptions, for instance a raster image where all pixels are captured simultaneous by the sensor. For that it would be nice to have a way to register the capture time in a standardized way. I am not sure if this is already possible with WKT2:2018.
>
> /Kristian
>
> -----Original Message-----
> From: PROJ <[hidden email]> On Behalf Of Nyall Dawson
> Sent: 27. august 2019 22:49
> To: Even Rouault <[hidden email]>
> Cc: PROJ <[hidden email]>
> Subject: Re: [PROJ] Seeking clarification on PROJ support for temporal transformations
>
> On Wed, 28 Aug 2019 at 01:26, Even Rouault <[hidden email]> wrote:
> >
> > > 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...
>
> Well -- I think it IS a fundamental part of the definition, of equal
> importance to other parameters such as false easting/northing. Without
> the epoch information the coordinate data becomes meaningless, and
> it's required in order to accurately position them. While it would
> theoretically be possible to store this information somewhere else in
> a dataset's metadata, it's such an integral part of the CRS that
> shoving it right into the CRS definition is the right way forward...
>
> Nyall
>
>
> >
> > --
> > Spatialys - Geospatial professional services
> > http://www.spatialys.com
> _______________________________________________
> PROJ mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/proj
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
12