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

Javier Jimenez Shaw j1 at jimenezshaw.com
Thu May 13 12:20:41 PDT 2021

My two cents:

About NGS / NOAA, I know that the new CRS they are preparing for 2022 it
clearly time dependent. I attended an online conference (oriented to
surveyors) last year about it, and they insisted a lot on the time variable
and plates drift.
There are some of them in the PROJ mailing list (maybe here as well) -there
was a discussion about including some grid files in PROJ-data-. Maybe
involving them in this topic may produce more traction.

.___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ... .... ._ .__
Entre dos pensamientos racionales
hay infinitos pensamientos irracionales.

On Thu, 13 May 2021 at 19:54, Greg Troxel <gdt at lexort.com> wrote:

adopt RFC 81: support for coordinate epochs in geospatial formats (
https://github.com/OSGeo/gdal/pull/3827 )

> Howard Butler <howard at hobu.co> writes:
> > 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.
> (I don't count formally.)
> I think I agree with Even's position here.  And, I see this as not being
> "GDAL's own way", but "a proposed way for the open geospatial community".
> 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.
> Obviously the US NGS keeps track of such things in their bluebook and
> NGS Integrated Datbase formats as they transform positions among epochs
> when doing adjustments, but that's a rather specialized and not so
> relevant to GIS format.
> _______________________________________________
> 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/20210513/f8fcd02a/attachment.html>

More information about the gdal-dev mailing list