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.roua...@spatialys.com <mailto:even.roua...@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
<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.daw...@gmail.com <mailto:nyall.daw...@gmail.com>> 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@lists.osgeo.org
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@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
