[PROJ] Seeking clarification on PROJ support for temporal transformations

[Cameron Shorter]

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