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

[Kurt Schwehr]

I've tried pinging David Sandwell at Scripps, geodesy / rtk / surveying
folks at UNH CCOM, and Paul Wessel / Dietmar Muller of GMT about a week ago
and haven't gotten any useful response.

I'm +0 and feeling like Sean that we really could use some feedback from
other communities.

Having epoch info is great, but I feel like I have no clue about what is a
sufficient solution.

-kurt

On Mon, May 24, 2021 at 3:40 PM Sean Gillies via gdal-dev <
gdal-dev at lists.osgeo.org> wrote:

> 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
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20210524/757ac371/attachment.html>