[gdal-dev] Motion: adopt RFC 81: support for coordinate epochs in geospatial formats

[Even Rouault]

> And, I see this as not being
> "GDAL's own way", but "a proposed way for the open geospatial community".

Except for the proposal for GeoTIFF (using a new GeoKey) and FlatGeoBuf 
(using WKT:2019 COORDINATEMETADATA[]) (and maybe GeoJSON), all solutions 
I propose are obviously in the (harmless) hack category. I don't expect 
XML comments to be a standard body vetted solution. The purpose is to 
have some support to preserve the coordinate epoch when converting 
between popular formats with GDAL tooling. The idea is that a data 
producer can have some way to encode the information if they wish. And 
if in the years to come, better ways of encoding it are found and 
standardized, the information will be here to re-encode the data in a 
more standard way.

There are number of data producers emitting data referenced against WGS 
84 with metric or submetric accuracy and they don't provide the 
coordinate epoch. That must stop.
>
> But, overall this makes me wonder: Are there any formats for expressing
> epoch in the open source/open format world, and also in the proprietary
> world?.  I'm not aware of any (which means epsilon more than zero) and a
> quick search did not turn up anything.

I'm not aware of file formats or database layouts (I raised an issue for 
PostGIS: https://trac.osgeo.org/postgis/ticket/4911). The only 'thing' 
I'm aware of that takes into account coordinate epoch is the 'OGC API - 
Features - Part 2: Coordinate Reference Systems by Reference' spec: 
https://docs.ogc.org/is/18-058/18-058.html#_storage_crs . But I wonder 
who can fill such field with none of the data backend having support for 
it. hence this RFC. I see it more as a bootstrapping than the ultimate 
solution.


-- 
http://www.spatialys.com
My software is free, but my time generally not.