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

[Sean Gillies]

Hi all,

I've got a suggestion about limiting the number of formats.

GeoJSON and KML don't need support for a coordinate epoch. Both of these
are pretty cleared intended for low accuracy data (1-2 meters). KML and
GeoJSON don't support any CRS other than OGC:CRS84, which uses (it has been
pointed out many times) a datum ensemble that RFC 81 does not intend to
address. Right, Even? So let's leave these formats the way they are.

GML, GeoPackage, PostGIS, and the actively used raster formats like GeoTIFF
seem like the important ones to me.

On Thu, May 27, 2021 at 7:40 AM Even Rouault <even.rouault at spatialys.com>
wrote:

> Hi,
>
> - merging the underlying API without any format support is I believe of
> little interest. So I'll wait for at least one format (likely
> GeoPackage) to have merged in the master of their specification an
> official way of storing the coordinate epoch. I've also prepared an
> enhancement of the GeoTIFF spec regarding this
> (https://github.com/opengeospatial/geotiff/pull/99) that will likely be
> discussed at the next OGC GeoTIFF SWG meeting.
>
> - I've just chatted with Howard and a good compromise could be that for
> formats that will have an official way of storing the coordinate epoch,
> we store it by default (when it is set), and for formats that we
> unilaterally extend (GML, KML, GeoJSON, etc.), we require an explicit
> GDAL_ENABLE_COORD_EPOCH_STORAGE=YES configuration option to be set
> (default would be NO). We might revisit in the future the default value.
>
> - On the vector side of things, things will probably get more
> complicated for some drivers, as it is likely that Spatialite (see
> https://groups.google.com/g/spatialite-users/c/NtbuBpRzYBE) or PostGIS
> might have per-geometry coordinate epoch, not at the layer level. But I
> don't think that would invalidate having support for it at the layer
> level (those database already support a per-geometry CRS, but GDAL
> support for that is probably lacking a bit in those drivers), as a
> OGRGeometry can potentially be associated with its own
> OGRSpatialReference object.
>
> Even
>
> Le 27/05/2021 à 15:01, Howard Butler a écrit :
> >
> >> On May 26, 2021, at 8:33 PM, Nyall Dawson <nyall.dawson at gmail.com>
> wrote:
> >>
> >> Can I make the suggestion that a subset of
> >> https://github.com/OSGeo/gdal/pull/3827 could be created and be merged
> >> on its own? Specifically the commits which add the underlying API for
> >> GDAL to handle epochs should be controversy-free and suitable for
> >> merge outside of the larger/trickier question of patching in support
> >> to the data formats.
> > :thumbsup:
> >
> > As for the patching of data formats with GDAL application-specific
> metadata, as I said, I don't have a better option, but I'm satisfied if the
> process of writing epochs into metadata is opt-in (some kind of global CRS
> option? we already have magic switches like that).
> >
> > Howard
> >
> >
>


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