[Proj] Fwd: PSG Dataset ver 9.0 released on 15th December 2016

[Martin Desruisseaux]

Hello all

Le 19/12/2016 à 09:19, Greg Troxel a écrit :
> so I went to the site to figure that out, and found that
> you have to create an account and log in to download the dataset.
> That's awkward for packaging systems that fetch things for the user, and
> raises the question of whether this is open data.

In my understanding, the EPSG geodetic dataset has never been open data
in the way we define open source. EPSG dataset is redistributable, but
under some conditions that are not exactly like the usual open source
licences (more on it below).


>  - Does anyone know what's going on with the login requiremnt?

I do not remember when exactly the login requirement has been put in
place, but it exists for at least a few years.


>  - Are the database files freely redistributable?

They are redistributable under the terms of use described at
http://www.epsg.org/Termsofuse.aspx. Distribution for profit is
forbidden, unless the data are bundled in a larger software which
provide added value (I think that Proj.4 complies with this condition).
We can distribute the data in another format than the SQL scripts
provided that the CRS definitions are equivalent, but we are not allowed
to change the definitions except for the permitted changes listed in
table 1 of EPSG Terms of Use. In particular, changing axis order (e.g.
providing "EPSG:4326" in lon,lat) is not allowed in my understanding.
For those who really want (lon,lat) axis order, a policy currently under
discussion at OGC is to require that the datafile makes very clear that
axis order is changed. For example the CRS declaration in the datafile
could be "EPSG:4326;axisOrder(lon,lat)" (example only - not an official
syntax).


>  - Is there a mirror that one can just download them from?

Even if such mirror existed, I don't think it would free us from the
obligation to comply with EPSG terms of use. The legal issue has been
discussed at Apache among other:

    https://issues.apache.org/jira/browse/LEGAL-183

The resolution is that Apache does not redistribute the EPSG dataset.
Instead we provide the script in a Maven "non-free" groupId with a copy
of the terms of use. When using Apache SIS command-line tool, it offers
to download and install the dataset automatically when first needed. The
EPSG terms of uses are displayed and the user is asked if (s)he agree.


>  - Other than being in proj or postgis, is there any reason for a user
>    to want access to the raw SQL input files?

Some other libraries (e.g. Apache SIS) use the RAW SQL files for
installing a complete SQL database rather than using CSV files. However
those libraries have their own packaging and probably don't need the
files bundled in Proj.4.

Having full SQL database gives access to more information, for example
transformation paths that do not use WGS84 as a hub, area of validity
and operation accuracy. For example there is about 80 transformations
from EPSG:4267 (NAD27) to EPSG:4326 (WGS84) in the EPSG database (a
transformation for Texas, one for Alaska, one for Cuba, etc). Providing
a single "+towgs84" parameter for this pair of CRS is not sufficient. We
have also seen errors caused by the use of coordinate transformations as
a black box without realizing that the operation was for the wrong
geographic area. If Proj.4 could tell the area of validity and the
accuracy of its operations (those information are in the EPSG database),
I think that would improve safety.

More information from the EPSG database is also necessary if Proj.4
wants to free itself from its use of WGS84 as a hub (through the
"+towgs84" parameter). This so-called "early-binding" approach has
issues that have already been discussed. Note also that "TOWGS84" is not
supported any more in WKT 2 (a.k.a. ISO 19162); it is replaced by
"BOUNDCRS". Furthermore EPSG 9.0 now has 6 new "WGS 84" CRS in addition
of EPSG:4326: WGS84(G1150), WGS84(G1674), WGS84(1762), WGS84(G730),
WGS84(G873), WGS84(Transit), which make the use of a "CRS hub" less
realistic. I realize that it may not be a short term goal, but if Proj.4
wants to upgrade someday from an "early-binding" implementation to a
"late-binding" one, it may be useful to keep in mind which information
from the SQL scripts are discarded in the CSV files.

Regards,

    Martin


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