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

[Sean Gillies]

Hi Even, Howard:

I'm inclined to approve, but I feel like there should be more discussion,
not just among PROJ developers and developers of cutting edge formats. We
should work to draw a wider group in on this.

On Thu, May 13, 2021 at 10:01 AM Even Rouault <even.rouault at spatialys.com>
wrote:

> 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.
>

Howard, are you suggesting that there should be a configuration option to
opt in to this new feature?

A surprise 1-2 meter shift is going to break builds and applications, I
agree. I think a lot of us are tolerating inaccuracy due to using
time-varying CRS but are going to be caught out by changes in the actual
numbers.


> >
> > 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.
> >
>

For GeoJSON, at least, I think proposing a "coordinate_epoch" property is
pragmatic. This doesn't do anything for GeoJSON feature sequences, though.
And it doesn't do anything about data that's already out there that will
never be re-processed.

Now that I think about it, I think the RFC should say more about what it
will do for the ensemble OGC:CRS84.


> > 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
>

To me, it seems that the parameterization or description of coordinate
epochs in OGC 19-005r4 is a bit sketchy.

Even, are you saying that coordinate shifts in PROJ are entirely functions
of the datetime delta since the coordinate epoch?

-- 
Sean Gillies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20210524/6b8623c6/attachment.html>