[PROJ] Seeking clarification on PROJ support for temporal transformations

[Nyall Dawson]

On Wed, 28 Aug 2019 at 06:27, Chris Crook <ccrook at linz.govt.nz> 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:proj-bounces at lists.osgeo.org] 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 <proj-bounces at lists.osgeo.org> On Behalf Of Nyall Dawson
> Sent: 27. august 2019 22:49
> To: Even Rouault <even.rouault at spatialys.com>
> Cc: PROJ <proj at lists.osgeo.org>
> Subject: Re: [PROJ] Seeking clarification on PROJ support for temporal transformations
>
> On Wed, 28 Aug 2019 at 01:26, Even Rouault <even.rouault at spatialys.com> 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
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> 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 info at linz.govt.nz) 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.