<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>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).</p>
    <p>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 <span
        class="aCOpRe"><span><em>OGC Features</em> and <em>Geometries
            JSON</em> SWG </span></span> comes with something regarding
      this.<br>
    </p>
    <p>Even<br>
    </p>
    <div class="moz-cite-prefix">Le 27/05/2021 à 19:24, Sean Gillies via
      gdal-dev a écrit :<br>
    </div>
    <blockquote type="cite"
cite="mid:CADPhZXwosVHKyeGHkQ_R9y6fUVuJh0aSiKOYnSwMgi61bYKLaw@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <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"
              moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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"
              moz-do-not-send="true">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" moz-do-not-send="true">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>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
gdal-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/gdal-dev">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a>
</pre>
    </blockquote>
    <pre class="moz-signature" cols="72">-- 
<a class="moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
  </body>
</html>