<div dir="ltr"><div>Hi all,</div><div><br></div><div>I've got a suggestion about limiting the number of formats.</div><div><br></div><div>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.</div><div><br></div><div>GML, GeoPackage, PostGIS, and the actively used raster formats like GeoTIFF seem like the important ones to me.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 27, 2021 at 7:40 AM Even Rouault <<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
- merging the underlying API without any format support is I believe of <br>
little interest. So I'll wait for at least one format (likely <br>
GeoPackage) to have merged in the master of their specification an <br>
official way of storing the coordinate epoch. I've also prepared an <br>
enhancement of the GeoTIFF spec regarding this <br>
(<a href="https://github.com/opengeospatial/geotiff/pull/99" rel="noreferrer" target="_blank">https://github.com/opengeospatial/geotiff/pull/99</a>) that will likely be <br>
discussed at the next OGC GeoTIFF SWG meeting.<br>
<br>
- I've just chatted with Howard and a good compromise could be that for <br>
formats that will have an official way of storing the coordinate epoch, <br>
we store it by default (when it is set), and for formats that we <br>
unilaterally extend (GML, KML, GeoJSON, etc.), we require an explicit <br>
GDAL_ENABLE_COORD_EPOCH_STORAGE=YES configuration option to be set <br>
(default would be NO). We might revisit in the future the default value.<br>
<br>
- On the vector side of things, things will probably get more <br>
complicated for some drivers, as it is likely that Spatialite (see <br>
<a href="https://groups.google.com/g/spatialite-users/c/NtbuBpRzYBE" rel="noreferrer" target="_blank">https://groups.google.com/g/spatialite-users/c/NtbuBpRzYBE</a>) or PostGIS <br>
might have per-geometry coordinate epoch, not at the layer level. But I <br>
don't think that would invalidate having support for it at the layer <br>
level (those database already support a per-geometry CRS, but GDAL <br>
support for that is probably lacking a bit in those drivers), as a <br>
OGRGeometry can potentially be associated with its own <br>
OGRSpatialReference object.<br>
<br>
Even<br>
<br>
Le 27/05/2021 à 15:01, Howard Butler a écrit :<br>
><br>
>> On May 26, 2021, at 8:33 PM, Nyall Dawson <<a href="mailto:nyall.dawson@gmail.com" target="_blank">nyall.dawson@gmail.com</a>> wrote:<br>
>><br>
>> Can I make the suggestion that a subset of<br>
>> <a href="https://github.com/OSGeo/gdal/pull/3827" rel="noreferrer" target="_blank">https://github.com/OSGeo/gdal/pull/3827</a> could be created and be merged<br>
>> on its own? Specifically the commits which add the underlying API for<br>
>> GDAL to handle epochs should be controversy-free and suitable for<br>
>> merge outside of the larger/trickier question of patching in support<br>
>> to the data formats.<br>
> :thumbsup:<br>
><br>
> 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).<br>
><br>
> Howard<br>
><br>
><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr">Sean Gillies</div></div></div>