[gdal-dev] Motion: adopt RFC 81: support for coordinate epochs in geospatial formats
even.rouault at spatialys.com
Thu May 13 11:11:08 PDT 2021
> 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
My software is free, but my time generally not.
More information about the gdal-dev