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. _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
