<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>