Re: Seeking clarification on PROJ support for temporal transformations

On Wed, 28 Aug 2019 at 09:07, Cameron Shorter <[email protected]> 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 <[email protected]> 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
> [email protected]
> https://lists.osgeo.org/mailman/listinfo/proj
_______________________________________________
PROJ mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/proj