<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">
      <p>Le 19/01/2017 à 04:34, Even Rouault a écrit :</p>
    </div>
    <blockquote cite="mid:1686182.M3UKYyI3vf@even-i700" type="cite">
      <p style=" margin-top:0px; margin-bottom:0px; margin-left:0px;
        margin-right:0px; -qt-block-indent:0; text-indent:0px;
        -qt-user-state:0;">The issue with axis order is not only found
        in the proj.4/geotiff/GDAL/etc software stack, but it is also
        deeply anchored in OGC standards themselves, so I don't see it
        to be solved any time soon. See this excellent retrospective
        from Carl Reed:
        <a class="moz-txt-link-freetext" href="https://lists.osgeo.org/pipermail/standards/2016-October/000989.html">https://lists.osgeo.org/pipermail/standards/2016-October/000989.html</a>
      </p>
    </blockquote>
    <p>As Carl said, older WMS and WFS standards were unclear about axis
      order except for EPSG:4326. The same issue happens also with units
      of measurement, which were unclear in the first WKT specification
      before they were clarified in OGC 01-009 and more recently in ISO
      19162 (WKT 2). But those historical facts show how difficult it is
      to fix problems caused by departure from a standard (including OGC
      departing from EPSG). This history can be taken as an argument
      against allowing unrestricted changes to a standard.</p>
    <p>The axis order policy discussed in latest OGC meetings is that if
      the order is not as defined by the authority, then the departure
      shall be obvious from the metadata. For example by using a CRS
      identifier like "EPSG:4326;axisOrder=(lon,lat)" (example only -
      not an official syntax).<br>
    </p>
    <p><br>
    </p>
    <blockquote cite="mid:1686182.M3UKYyI3vf@even-i700" type="cite">
      <p style=" margin-top:0px; margin-bottom:0px; margin-left:0px;
        margin-right:0px; -qt-block-indent:0; text-indent:0px;
        -qt-user-state:0;">And even some recent OGC standards still
        don't respect EPSG axis order, or at least this is my
        interpretation of the GeoPackage standard
        (<a class="moz-txt-link-freetext" href="http://www.geopackage.org/spec/">http://www.geopackage.org/spec/</a>) mentionning in footnote 11 :
        The axis order in WKB is always (x,y{,z}{,m}) where x is easting
        or longitude, y is northing or latitude, z is optional elevation
        and m is optional measure.</p>
    </blockquote>
    <p>In that case this is a legacy standard (WKB) incorporated into a
      newer one. If OGC were defining WKB today, I don't think they
      would have specified it that way. Geopackage requirement 11 [1]
      also said: "The record with an srs_id of 4326 SHALL correspond to
      WGS-84 as defined by EPSG in 4326" with links to EPSG
      documentation and registry with (latitude, longitude) axis order.
      Requirement 11 and footnote 11 may seem to contradict each other,
      but maybe not completely since the "spatial_ref_sys" table allows
      CRS definitions from different organizations (not necessarily
      EPSG).</p>
    <p>In the process of adopting GeoJSON as an IETF standard, they
      preferred to exclude any CRS definition (other than saying that
      the default is CRS:84) rather than adopting the GeoJSON usage of
      EPSG codes with non-compliant axis order. We have been told that,
      ironically, IETF has been easier to convince about the importance
      of standard compliance than the geospatial community.<br>
    </p>
    <p><br>
    </p>
    <blockquote cite="mid:1686182.M3UKYyI3vf@even-i700" type="cite">
      <p style="-qt-paragraph-type:empty; margin-top:0px;
        margin-bottom:0px; margin-left:0px; margin-right:0px;
        -qt-block-indent:0; text-indent:0px; ">and mandating the
        EPSG:4326 definition to be: GEOGCS ["WGS 84", DATUM ["World
        Geodetic System 1984", SPHEROID["WGS 84", 6378137, 298.257223563
        , AUTHORITY["EPSG","7030"]], AUTHORITY["EPSG","6326"]],
        PRIMEM["Greenwich", 0 , AUTHORITY["EPSG","8901"]],
        UNIT["degree", 0.017453292519943278, AUTHORITY["EPSG","9102"]],
        AUTHORITY["EPSG","4326"] so with no explicit axis order.</p>
    </blockquote>
    <p>They do not mandate the WKT to be exactly like that since they
      also said "ignoring any optional EBNF components <twin axes>
      and <to wgs84> and whitespace differences in the returned
      text". However I'm not sure if the editor realized that when axes
      are omitted in WKT 1, the default is (longitude, latitude), which
      introduce a contradiction with above-cited requirement 11. I will
      post an email on OGC mailing list asking for a clarification.</p>
    <p><br>
    </p>
    <p>
      <blockquote type="cite">While I can understand the motivation from
        authoritative sources to not see their data to be modified and
        misused, so as not to alter their credibility, the practical
        implications of restricting changes is a practical burden.</blockquote>
      In long term, I don't think that discarding the data integrity
      concerns as "less important" than open source convenience will
      work. As we are entering in a "big data" world, I expect those
      concerns to increase, maybe sometime with human life at play (e.g.
      medicine). My personal opinion is that open source should prepare
      to adapt, if not for EPSG at least for other data to come in next
      years. Again it does not mean that no change are allowed, but to
      reduce the risk that the data are not what the user think they
      are. This is not necessarily incompatible with open source - see
      next paragraph about name.<br>
    </p>
    <p><br>
    </p>
    <blockquote cite="mid:1686182.M3UKYyI3vf@even-i700" type="cite">
      <p>One simple solution to solve the issue of allowing
        modifications while not presenting modified data as being the
        one from the original provider is to have a clause similar to
        the one found in the ZLib license : "Altered source versions
        must not be misrepresented as being the original software"</p>
    </blockquote>
    <p>Apache license also has a similar restriction. If a company
      changes an Apache Foo software, they can not name it "Apache Foo"
      anymore [2]. They can call it "MyCompany Whatever" instead. I see
      clause 6vii of EPSG terms of use ("No data that has been modified
      other than as permitted in these Terms of Use shall be attributed
      to the EPSG Dataset") as a similar restriction. Maybe actually the
      EPSG condition is even more flexible than Apache in this regard
      since EPSG gives a list of changes that we are allowed to do and
      still keep the "EPSG" name, while Apache license does not mention
      any exception to their restriction.<br>
    </p>
    <p>I think that international standards and sensitive data need
      slightly different licenses than open source software. It may
      cause incompatibilities in the foreseeable future, but open source
      have resolved other incompatibilities issues in the past (e.g.
      incompatibility between Apache and GPL licenses, resolved with
      Apache 2 + GPL 3). In the meantime, we have workarounds.<br>
    </p>
    <p>    Martin</p>
    <p><br>
    </p>
    <p>[1] <a class="moz-txt-link-freetext" href="http://www.geopackage.org/spec/#gpkg_spatial_ref_sys_cols">http://www.geopackage.org/spec/#gpkg_spatial_ref_sys_cols</a><br>
      [2] <a class="moz-txt-link-freetext" href="http://www.apache.org/foundation/license-faq.html#Name-changes">http://www.apache.org/foundation/license-faq.html#Name-changes</a></p>
    <p><br>
    </p>
  </body>
</html>