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

[Even Rouault]

Howard,
> 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.
Having different results in coordinate transformations due to have will 
not be much different than using different PROJ versions using different 
versions of the EPSG database, possibly with different set of grids 
installed.
>
> 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.
We are not going to invent a new raster or vector format just to add a 
coordinate epoch into it, right ? So this proposal does minor and 
backward compatible enhancements to popular existing formats.
>
> 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.
Well, this is a public RFC for everybody awareness, and there will be a 
page on GDAL doc. And I've created tickets on the GeoTIFF and GeoPackage 
OGC github repos pointing to it. I don't necessarily expect much follow 
up from them though, but at least we'll have tried to make advance the 
topic a bit.
>
> 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?

This format is a floating point number and is the accepted way of 
encoding coordinate epochs. The after decimal point part represents the 
fraction of the year. It is referenced in "OGC Abstract Specification 
Topic 2: Referencing by coordinates" 
(https://docs.opengeospatial.org/as/18-005r4/18-005r4.html). In table 4: 
coordinateEpoch: "date at which coordinates are referenced to a dynamic 
coordinate reference system, expressed as a decimal year in the 
Gregorian calendar. Example: 2017-03-25 in the Gregorian calendar is 
epoch 2017.23."

(31+28+25) / 365. = 0.23...

Two digits after the decimal point should be enough in practice. For 
'slow' and continuous phenomenons like plate drift motion, an error of a 
couple days will not change the result by more than a fraction of 
millimetre. If you use a deformation model that takes into account 
earthquakes however, you could perhaps need to add a 3rd digit to 
identify precisely the day.

Even


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