Hello Florian
Le 22/11/2022 à 18:44, Florian Micklich a écrit :
I didn't know that proj4j itself uses EPSG data.
The CSV files in [1] are derived from EPSG tables. The file structures
are different than EPSG database schema, but the data that they contain
are EPSG data. The same information is also provided in WKT format in
[2] (this file somewhat duplicates the CSV tables). Some peoples on PROJ
mailing list have argued that rewriting EPSG data in a different format
free them from EPSG licensing terms, but this is not true. Translating a
software in a different language is a derivative work and is still
subject to the licensing terms of the copyright owner. In the same way
that translating a book does not suppress the rights of the original
author on the translated book. In the case of EPSG data, IOGP allows us
to reformat the data in a different way, but under some conditions
specified in their Terms of Use. And doing so does not give us the right
to erase the EPSG terms of use from the derivative work.
The value of EPSG geodetic dataset is not in the database schema
(converting that to a different data structure is the easy part), but in
the data themselves. Creating a new "EPSG-like" dataset from scratch
would be a huge effort, well beyond our capability. We would have to
visit all national mapping agencies in the world, ask them to provide
documentation about the Coordinate Reference System they have defined
(including historical ones), consolidate all those information in some
tables, etc. So the CSV files [1] in PROJ4 contain an enormous amount of
EPSG work, even if the data structures are different.
[1]https://github.com/locationtech/proj4j/tree/master/src/main/resources/proj4
[2]https://raw.githubusercontent.com/locationtech/proj4j/master/src/main/resources/proj4/wkt/epsg.properties
Until now I thought it would be a good alternative lib besides EPSG
approach.
When creating a Coordinate Reference System (CRS) from an EPSG code such
as "EPSG:4326", we are using the EPSG geodetic dataset. I think that if
a software contains e.g. 10 EPSG codes (compared to the ~6000
definitions in the full dataset), it could be considered Fair Use. But
including the full dataset requires that we comply with EPSG Terms Of Use.
However if CRS are created from user-supplied WKT strings (or PROJ4
parameter strings), then no EPSG code is involved. The WKT definition
string may contain an AUTHORITY["EPSG", 4326] element, but it only means
"see EPSG:4326 for more complete information".
So what would be your advise with proj4(j) and how to handle that kind
of implementation in an Apache project?
EPSG geodetic dataset is not needed when the CRS is built from WKT, GML
or some file formats like NetCDF and some (not all) GeoTIFF files. So
the approach taken in Apache SIS applications (JavaFX and console
application) is to start without EPSG data. Then the first time that an
EPSG code is really needed, the application popups a dialog box (in
JavaFX) or an interactive prompt (in console application) asking users
if they want to download the EPSG geodetic dataset. If users click
"yes", the EPSG Terms of Use is shown and the application asks users if
they accept. If they confirm, then the EPSG geodetic dataset is
downloaded and a database is created locally.
Note that above procedure is needed only for software downloaded
directly from Apache servers. Anyone can bundle an application outside
Apache which contains the Apache software + EPSG data. The only
condition for being allowed to do that is to include the EPSG Terms of
Use (in addition of Apache license) in the application bundle.
Officially it is running on MIT license.
Yes, this issue has been raised on their mailing list. PROJ maintainers
have choose to ignore. Some of them pretended that EPSG Terms of Use do
not apply to them anymore because they converted the PostgreSQL scripts
to SQLite scripts. I'm not a lawyer, but I think that this argument has
zero chance to hold in court. For now they rely on the fact that IOGP
(the owner of EPSG database) does not want to upset the geodetic community.
Martin
