<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>Hello all<br>
</p>
Le 19/12/2016 à 09:19, Greg Troxel a écrit :<br>
</div>
<blockquote cite="mid:smushpkhit9.fsf@linuxpal.mit.edu" type="cite">
<pre wrap="">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.</pre>
</blockquote>
<p align="justify">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).</p>
<p><br>
</p>
<p>
</p>
<blockquote cite="mid:smushpkhit9.fsf@linuxpal.mit.edu" type="cite">
<pre wrap=""> - Does anyone know what's going on with the login requiremnt?</pre>
</blockquote>
<p align="justify">I do not remember when exactly the login
requirement has been put in place, but it exists for at least a
few years.</p>
<p><br>
</p>
<p>
</p>
<blockquote cite="mid:smushpkhit9.fsf@linuxpal.mit.edu" type="cite">
<pre wrap=""> - Are the database files freely redistributable?</pre>
</blockquote>
<p align="justify">They are redistributable under the terms of use
described at <a class="moz-txt-link-freetext" href="http://www.epsg.org/Termsofuse.aspx">http://www.epsg.org/Termsofuse.aspx</a>. 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 <tt>"EPSG:4326"</tt>
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 <tt>"EPSG:4326;axisOrder(lon,lat)"</tt>
(example only - not an official syntax).<br>
</p>
<p><br>
</p>
<p>
</p>
<blockquote cite="mid:smushpkhit9.fsf@linuxpal.mit.edu" type="cite">
<pre wrap=""> - Is there a mirror that one can just download them from?</pre>
</blockquote>
<p align="justify">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:</p>
<blockquote>
<p><a class="moz-txt-link-freetext" href="https://issues.apache.org/jira/browse/LEGAL-183">https://issues.apache.org/jira/browse/LEGAL-183</a></p>
</blockquote>
<p align="justify">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.<br>
</p>
<p><br>
</p>
<p>
</p>
<blockquote cite="mid:smushpkhit9.fsf@linuxpal.mit.edu" type="cite">
<pre wrap=""> - Other than being in proj or postgis, is there any reason for a user
to want access to the raw SQL input files?
</pre>
</blockquote>
<p align="justify">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.</p>
<p align="justify">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 <tt>"+towgs84"</tt>
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.</p>
<p align="justify">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 <tt>"+towgs84"</tt> parameter). This so-called
"early-binding" approach has issues that have already been
discussed. Note also that <tt>"TOWGS84"</tt> is not supported any
more in WKT 2 (a.k.a. ISO 19162); it is replaced by <tt>"BOUNDCRS"</tt>.
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.</p>
<p>Regards,<br>
</p>
<p> Martin</p>
<p><br>
</p>
</body>
</html>