[Proj] ICSM (Australia) transformation file licensing

Wed Jan 18 21:32:34 PST 2017

Le 19/01/2017 à 04:34, Even Rouault a écrit :

> 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:
> https://lists.osgeo.org/pipermail/standards/2016-October/000989.html
>
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.

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

> And even some recent OGC standards still don't respect EPSG axis
> order, or at least this is my interpretation of the GeoPackage
> standard (http://www.geopackage.org/spec/) 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.
>
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).

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.

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

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

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

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.

    Martin

[1] http://www.geopackage.org/spec/#gpkg_spatial_ref_sys_cols
[2] http://www.apache.org/foundation/license-faq.html#Name-changes

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20170119/79d6bbf8/attachment.html>