[PROJ] Seeking clarification on PROJ support for temporal transformations

[Kristian Evers]

> 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 <nyall.dawson at gmail.com> 
Sent: 27. august 2019 23:53
To: Kristian Evers <kreve at sdfe.dk>
Cc: Even Rouault <even.rouault at spatialys.com>; PROJ <proj at lists.osgeo.org>
Subject: Re: [PROJ] Seeking clarification on PROJ support for temporal transformations

On Wed, 28 Aug 2019 at 06:12, Kristian Evers <kreve at sdfe.dk> 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 <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