[gdal-dev] Motion: adopt RFC 81: support for coordinate epochs in geospatial formats
jratike80
jukka.rahkonen at maanmittauslaitos.fi
Thu May 27 13:43:20 PDT 2021
Hi,
The group description of Features and Geometries JSON SWG
https://www.ogc.org/projects/groups/featgeojsonswg does not mention dynamic
coordinate systems but I can at least try to add the topic into the agenda
in the kick-off on next Tuesday (2021-06-01) even I am just on observer in
the group.
-Jukka Rahkonen-
Even Rouault-2 wrote
> That said, I'll probably drop the commit for KML as it is clearly a
> hack, but I think support for GeoJSON, which is cleaner, could still be
> useful at some point as it is widely used as an exchange format. But
> I'll defer for GeoJSON until we see if the /OGC Features/ and
> /Geometries JSON/ SWG comes with something regarding this.
Even Rouault-2 wrote
> Regarding KML and GeoJSON and OGC:CRS84 (or EPSG:4326 since they are the
> same thing, except axis order), that's a good and hard question.
> Actually that extends to *any* CRS built on top of them, like all the
> EPSG:32[6|7][01-60] UTM CRS, and that's probably for those later than
> things are the most problematic since there's no EPSG code for a UTM WGS
> 84 (G1762) CRS. I guess people would potentially want to attach a
> coordinate epoch to them, and have a (non-encoded-in-the-format)
> convention that they actually mean WGS 84 (G1762) (or possibly an
> earlier realization. The datum ensemble reality of WGS 84 is really due
> to Transit which differs significantly from later realizations, which
> are pretty consistent between them within a few centimers) . So I
> wouldn't forbid such uses (I actually got private feedback that some
> people would even want to store coordinate epoch for CRS that aren't
> considered by EPSG as dynamic CRS, but which, for advanced uses, can
> still have things like deformation models, like NAD83(2011) that is used
> for most people as a static CRS, but is more a snapshot of a dynamic CRS
> with a conventional reference epoch of 2010.0).
>
> That said, I'll probably drop the commit for KML as it is clearly a
> hack, but I think support for GeoJSON, which is cleaner, could still be
> useful at some point as it is widely used as an exchange format. But
> I'll defer for GeoJSON until we see if the /OGC Features/ and
> /Geometries JSON/ SWG comes with something regarding this.
>
> Even
>
> Le 27/05/2021 à 19:24, Sean Gillies via gdal-dev a écrit :
>> 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@
> <mailto:
> even.rouault@
> >> 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
>> <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
>> <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@
> <mailto:
> nyall.dawson@
> >> wrote:
>> >>
>> >> Can I make the suggestion that a subset of
>> >> https://github.com/OSGeo/gdal/pull/3827
>> <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
>>
>> _______________________________________________
>> gdal-dev mailing list
>>
> gdal-dev at .osgeo
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at .osgeo
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
More information about the gdal-dev
mailing list