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 >> > [email protected] >> 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 > [email protected] > https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html _______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
