[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