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

Howard Butler howard at hobu.co
Thu May 13 08:41:31 PDT 2021

> On May 13, 2021, at 4:44 AM, Even Rouault <even.rouault at spatialys.com> wrote:
> Hi,
> Motion:
> adopt RFC 81: support for coordinate epochs in geospatial formats ( https://github.com/OSGeo/gdal/pull/3827 )
> Starting with my +1


I'm not enthusiastic about the proposed implementation. I don't have an alternative solution which would allow me to veto it, however. Here's why I think it is bad to decorate all of these old formats with our own epoch metadata:

It is magical

If you have GDAL-extended versions of a few select data formats and you have the correct chain of PROJ and GDAL, the behavior of your coordinates is going to change for various transformations. This could be confusing and challenging to track down in debugging scenarios. The discrepancies between doing the same transformations in different softwares will be especially noticeable. 

It extends existing formats in GDAL's own way

Are there many other cases where GDAL augments and extends behavior of formats by bolting on metadata bits? I can think of some GeoTIFF tags where GDAL has done this in the past. Some of them have been adopted industry-wide, but most have not. We definitely haven't done that to a long list of formats like this RFC proposes to do.

No corresponding socializing activity

Is GDAL going to go to the GeoJSON, GeoPackage, GeoTIFF, Flatgeobuf, GML, JPEG2000, KML, and Shapefile communities and advocate for these improvements? It would be a lot of time and effort to go back after the fact and officially augment all of these formats with epoch metadata.  Many of these are never going to have new versions either, so there isn't much hope of a new format version coming along with support for coordinate epochs. 

Is the format of epoch standardized?

The proposed epoch format, such as 2021.3, *looks* like a floating point number, but it isn't really, is it? Do you ever need more precision than a year and a day? *shrug* It seems like it's own special time format. Is there a standard time format that could instead be used here?


More information about the gdal-dev mailing list