Re: [Proj] Common SQLite-based dictionaries

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [Proj] Common SQLite-based dictionaries

Howard Butler-3
I'm trying to push all of this traffic to the MetaCRS list so we don't spread the discussion everywhere...

> On Aug 2, 2015, at 11:02 AM, Huw James <[hidden email]> wrote:
>
> Dear Even,
>
> people working today with CRS tend to assume that there is one set of parameters to perform a particular coordinate conversion.
>
> In the real world we have coordinates that were derived from some Latitude & Longitude on some datum that used datum transformations, ellipsoid definitions and numerical precision that are far different from those used today. The parameters and precision that were used were often the best available at the time which often preceded any satellite derive knowledge.
>
> There are many assets around the world whose coordinates and ownership are defined by coordinates that would change if current EPSG or other "standard" parameters were used. This would include moving valuable assets across national and private property boundaries. Disallowing customization of datum and projection parameters would cause no end of confusion in the real world.

I wasn't proposing to disallow customization, in fact, I was proposing to regularize it across all three projects (GDAL, proj.4, libgeotiff).

> By saying that coordinates based on custom parameters for ED50 & UTM can be supported by defining a new custom datum for UTM and ED50 is not useful since the link between ED50 and the new pseudoED50 and the link between UTM and the new pseudoUTM are both lost and it is unlikely that some destination computer would have definitions or code for these new pseudo CRS definitions.
>
> I think it is better to define the customized CRS as ED50 & UTM with its non-standard definitions. Systems that do not support historical CRS conversions will not be adopted by users that need to deal with existing data.
>
> Today's users tend to think that coordinates can be defined to 1 mm precision or less. This is a recent capability. When surveying and navigation accuracy was at 50 m it seemed foolish to define parameters or coordinate conversion software with sub-meter precision.

Historical transforms and time epochs are a hard problem. I don't personally have many answers on that other than to say, "yes, we need some support for that!". My hope is attacking the dictionary management problem provides some efficiencies to allow that challenge to be broached.






_______________________________________________
MetaCRS mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/metacrs
Reply | Threaded
Open this post in threaded view
|

Re: [Proj] Common SQLite-based dictionaries

Howard Butler-3
I'm trying to push all of this traffic to the MetaCRS list so we don't spread the discussion everywhere...

> On Aug 2, 2015, at 3:47 PM, Martin Desruisseaux <[hidden email]> wrote:
>
> Hello all
>
> Just out of curiosity, if a SQL-like database is used, why defining new
> tables instead than using the EPSG ones directly? (note that EPSG allows
> users to define their own CRS, provided that they use a code outside the
> reserved range).

My proposal, loosely defined, is to *start* with the EPSG db and augment as necessary. The current dictionaries are essentially that, but in flat file form.

>
> If peoples still prefer to define their own tables, then I would like to
> make one suggestion:
>
> On Sunday 02 August 2015, Howard Butler wrote:
>> I'd like to propose an attempt to standardize the GDAL, proj.4, and libgeotiff
>> SRS coordinate system handling dictionaries on a SQLite database that starts
>> with EPSG
>
> I suggest to choose another name than EPSG, unless the proposed database
> would be made compliant with points 6.v, vi and vii of EPSG Term of Use
> (http://www.epsg.org/TermsOfUse). In my understanding the current CSV
> file goes beyond the permitted modification of data, for example on axis
> order. I realize that this is a controversial topic, and it is all right
> if an other convention is preferred - we are just not supposed to call
> that "EPSG".

I recognize there are some things to work through on the EPSG ToS. Thanks for bringing these issues up.

Howard
_______________________________________________
MetaCRS mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/metacrs
Reply | Threaded
Open this post in threaded view
|

Re: [Proj] Common SQLite-based dictionaries

Sebastiaan Couwenberg
On 03-08-15 15:19, Howard Butler wrote:

>> On Aug 2, 2015, at 3:47 PM, Martin Desruisseaux <[hidden email]> wrote:
>>
>> Hello all
>>
>> Just out of curiosity, if a SQL-like database is used, why defining new
>> tables instead than using the EPSG ones directly? (note that EPSG allows
>> users to define their own CRS, provided that they use a code outside the
>> reserved range).
>
> My proposal, loosely defined, is to *start* with the EPSG db and augment as necessary. The current dictionaries are essentially that, but in flat file form.
>
>>
>> If peoples still prefer to define their own tables, then I would like to
>> make one suggestion:
>>
>> On Sunday 02 August 2015, Howard Butler wrote:
>>> I'd like to propose an attempt to standardize the GDAL, proj.4, and libgeotiff
>>> SRS coordinate system handling dictionaries on a SQLite database that starts
>>> with EPSG
>>
>> I suggest to choose another name than EPSG, unless the proposed database
>> would be made compliant with points 6.v, vi and vii of EPSG Term of Use
>> (http://www.epsg.org/TermsOfUse). In my understanding the current CSV
>> file goes beyond the permitted modification of data, for example on axis
>> order. I realize that this is a controversial topic, and it is all right
>> if an other convention is preferred - we are just not supposed to call
>> that "EPSG".
>
> I recognize there are some things to work through on the EPSG ToS. Thanks for bringing these issues up.

For the eventual Debian package this is the most important issue to
resolve. The CSV files distributed with geotiff are split off because
the EPSG ToS is not acceptable for the Debian main repository, the ToS
is incompatible with the Debian Free Software Guidelines and the Open
Source Definition. The ToS discriminates against field of endeavor and
limits derived works via parameter modification restrictions.

If the proposed database derived from the EPSG database is bound by the
non-free EPSG ToS it won't be acceptable for Debian and by extension Ubuntu.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
_______________________________________________
MetaCRS mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/metacrs
Reply | Threaded
Open this post in threaded view
|

Re: [Proj] Common SQLite-based dictionaries

Howard Butler-3

> On Aug 3, 2015, at 8:32 AM, Sebastiaan Couwenberg <[hidden email]> wrote:
>> I recognize there are some things to work through on the EPSG ToS. Thanks for bringing these issues up.
>
> For the eventual Debian package this is the most important issue to
> resolve. The CSV files distributed with geotiff are split off because
> the EPSG ToS is not acceptable for the Debian main repository, the ToS
> is incompatible with the Debian Free Software Guidelines and the Open
> Source Definition. The ToS discriminates against field of endeavor and
> limits derived works via parameter modification restrictions.

Are there some links to discussion about why Debian has made this determination?

> If the proposed database derived from the EPSG database is bound by the
> non-free EPSG ToS it won't be acceptable for Debian and by extension Ubuntu.

I don't see how the situation is any different than it is now. The community can bootstrap its own db, but the amount of expertise required to do so in relation to the "convenience" of simply submitting to EPSG makes it a tough sell.
_______________________________________________
MetaCRS mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/metacrs
Reply | Threaded
Open this post in threaded view
|

Re: [Proj] Common SQLite-based dictionaries

Martin Desruisseaux-3
In reply to this post by Sebastiaan Couwenberg
Le 03/08/15 15:32, Sebastiaan Couwenberg a écrit :
> (...snip...) the ToS
> is incompatible with the Debian Free Software Guidelines and the Open
> Source Definition. The ToS discriminates against field of endeavor and
> limits derived works via parameter modification restrictions.

I'm not sure that those restrictions on modifications are incompatible
with Open Source Definition. Apache 2 is an Open Source license, despite
that it has a yet stronger restriction on modification:

http://www.apache.org/foundation/license-faq.html#Name-changes

In short: if you modify an Apache software, you are not allowed to call
your modified software "Apache" (but you can said "based on Apache").
The EPSG terms of use seems actually more flexible since it describe the
changes that you are allowed to do and still keep the "EPSG" codespace.

    Martin

_______________________________________________
MetaCRS mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/metacrs
Reply | Threaded
Open this post in threaded view
|

Re: [Proj] Common SQLite-based dictionaries

Sebastiaan Couwenberg
In reply to this post by Howard Butler-3
On 03-08-15 15:37, Howard Butler wrote:

>
>> On Aug 3, 2015, at 8:32 AM, Sebastiaan Couwenberg <[hidden email]> wrote:
>>> I recognize there are some things to work through on the EPSG ToS. Thanks for bringing these issues up.
>>
>> For the eventual Debian package this is the most important issue to
>> resolve. The CSV files distributed with geotiff are split off because
>> the EPSG ToS is not acceptable for the Debian main repository, the ToS
>> is incompatible with the Debian Free Software Guidelines and the Open
>> Source Definition. The ToS discriminates against field of endeavor and
>> limits derived works via parameter modification restrictions.
>
> Are there some links to discussion about why Debian has made this determination?

The EPSG ToS was considered non-free by the initial maintainer, and
noted this in the README for the Debian package:

"
 This version of the GeoTIFF library lacks the EPSG data files which
 are distributed in a separate non-free package libgeotiff-epsg due to
 license limitations.
"

http://anonscm.debian.org/cgit/pkg-grass/libgeotiff-dfsg.git/tree/debian/README.Debian

For libgeotiff 1.4.0 & 1.4.1 I also did a license & copyright review for
the update of the debian/copyright file with the new machine readable
format, and I also consider the EPSG ToS to be incompatible with the DFSG:

https://www.debian.org/social_contract#guidelines

If you want the opinion of Debian people other than the package
maintainers you can contact [hidden email] who review
the license & copyright of new packages before they're accepted into the
archive. Or the general [hidden email] list.

>> If the proposed database derived from the EPSG database is bound by the
>> non-free EPSG ToS it won't be acceptable for Debian and by extension Ubuntu.
>
> I don't see how the situation is any different than it is now. The community can bootstrap its own db, but the amount of expertise required to do so in relation to the "convenience" of simply submitting to EPSG makes it a tough sell.

The EPSG ToS limitions don't seem to apply to derived subsets as long as
they aren't attributed to the EPSG Dataset.

In Debian we consider the derived EPSG data in proj/nad/epsg for example
to fall under the MIT license of PROJ.4, because these are subsets of
the EPSG data.

Martin's proposal to use a different name and not attributing the
changes to the EPSG Dataset should allow new database to be licensed
freely (e.g. MIT, or maybe ODbL).

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
_______________________________________________
MetaCRS mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/metacrs
Reply | Threaded
Open this post in threaded view
|

Re: [Proj] Common SQLite-based dictionaries

Norman Vine
In reply to this post by Howard Butler-3

On Aug 3, 2015, at 9:37 AM, Howard Butler <[hidden email]> wrote:

>
>> On Aug 3, 2015, at 8:32 AM, Sebastiaan Couwenberg <[hidden email]> wrote:
>>> I recognize there are some things to work through on the EPSG ToS. Thanks for bringing these issues up.
>>
>> For the eventual Debian package this is the most important issue to
>> resolve. The CSV files distributed with geotiff are split off because
>> the EPSG ToS is not acceptable for the Debian main repository, the ToS
>> is incompatible with the Debian Free Software Guidelines and the Open
>> Source Definition. The ToS discriminates against field of endeavor and
>> limits derived works via parameter modification restrictions.
>
> Are there some links to discussion about why Debian has made this determination?


This has come up before

https://trac.osgeo.org/gdal/wiki/RevisedEPSGLicense

I appreciate EPSG's position about associating their name with changed/edited tables

Norman
_______________________________________________
MetaCRS mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/metacrs
Reply | Threaded
Open this post in threaded view
|

Re: [Proj] Common SQLite-based dictionaries

Howard Butler-3
In reply to this post by Sebastiaan Couwenberg

> On Aug 3, 2015, at 9:25 AM, Sebastiaan Couwenberg <[hidden email]> wrote:
> Martin's proposal to use a different name and not attributing the
> changes to the EPSG Dataset should allow new database to be licensed
> freely

Maybe we can come up with a clever backronym for GSPE....

> (e.g. MIT, or maybe ODbL).

Oh dear god....


_______________________________________________
MetaCRS mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/metacrs
Reply | Threaded
Open this post in threaded view
|

Re: [Proj] Common SQLite-based dictionaries

Norman Barker-2
In reply to this post by Martin Desruisseaux-3
I appreciate that ESPG is an Access database and hence there is a schema for most of the existing CRS definitions, however it does seem limiting to other uses. A Key-Value store (such as leveldb) would enable the the CRS_CODE->VALUE_DEFINITION without a schema. The value can be a GML/XML doc, JSON whatever the calling application can understand. 

I looked to use leveldb with the GDAL couchdb driver but opted for GPKG since this was already well understood in the code base. However for something like CRS I can see a schema model being restrictive.

Norman

On Mon, Aug 3, 2015 at 8:00 AM, Martin Desruisseaux <[hidden email]> wrote:
Le 03/08/15 15:32, Sebastiaan Couwenberg a écrit :
> (...snip...) the ToS
> is incompatible with the Debian Free Software Guidelines and the Open
> Source Definition. The ToS discriminates against field of endeavor and
> limits derived works via parameter modification restrictions.

I'm not sure that those restrictions on modifications are incompatible
with Open Source Definition. Apache 2 is an Open Source license, despite
that it has a yet stronger restriction on modification:

http://www.apache.org/foundation/license-faq.html#Name-changes

In short: if you modify an Apache software, you are not allowed to call
your modified software "Apache" (but you can said "based on Apache").
The EPSG terms of use seems actually more flexible since it describe the
changes that you are allowed to do and still keep the "EPSG" codespace.

    Martin

_______________________________________________
MetaCRS mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/metacrs


_______________________________________________
MetaCRS mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/metacrs
Reply | Threaded
Open this post in threaded view
|

Re: [Proj] Common SQLite-based dictionaries

Martin Desruisseaux-3
Le 03/08/15 16:46, Norman Barker a écrit :
> I appreciate that ESPG is an Access database

Just for info, the official EPSG dataset was used to be an Access
database, but today it is not anymore. The Access database is still
available for download, together with MySQL, PostgreSQL and Oracle SQL
scripts. But it is not anymore the authoritative source. The
authoritative source of EPSG definitions is now the online registry at
http://epsg-registry.org/, and the SQL scripts / Access databases are
made available mainly as convenience.

Note that this online registry also provides GML and WKT definitions for
most CRS in easily understandable URL (e.g.
http://epsg-registry.org/export.htm?wkt=urn:ogc:def:crs:EPSG::4326). The
WKT format however is "WKT 2", defined by ISO 19162 (same as OGC
document available freely on-line at
http://docs.opengeospatial.org/is/12-063r5/12-063r5.html).

Note: the above-cited WKT 2 is actually more than a format
specification. It contains also new stuff not available in previous
standard, and thus can also be seen as an evolution of ISO 19111. See
for example "Interpolation CRS" in the above-cited document.

    Martin


_______________________________________________
MetaCRS mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/metacrs
Reply | Threaded
Open this post in threaded view
|

Re: [Proj] Common SQLite-based dictionaries

Even Rouault-2
In reply to this post by Sebastiaan Couwenberg
On Monday 03 August 2015 16:25:15 Sebastiaan Couwenberg wrote:
> On 03-08-15 15:37, Howard Butler wrote:
> >> On Aug 3, 2015, at 8:32 AM, Sebastiaan Couwenberg <[hidden email]>
wrote:

> >>> I recognize there are some things to work through on the EPSG ToS.
> >>> Thanks for bringing these issues up.>>
> >> For the eventual Debian package this is the most important issue to
> >> resolve. The CSV files distributed with geotiff are split off because
> >> the EPSG ToS is not acceptable for the Debian main repository, the ToS
> >> is incompatible with the Debian Free Software Guidelines and the Open
> >> Source Definition. The ToS discriminates against field of endeavor and
> >> limits derived works via parameter modification restrictions.
> >
> > Are there some links to discussion about why Debian has made this
> > determination?
> The EPSG ToS was considered non-free by the initial maintainer, and
> noted this in the README for the Debian package:
>
> "
>  This version of the GeoTIFF library lacks the EPSG data files which
>  are distributed in a separate non-free package libgeotiff-epsg due to
>  license limitations.
> "
>
> http://anonscm.debian.org/cgit/pkg-grass/libgeotiff-dfsg.git/tree/debian/REA
> DME.Debian
>
> For libgeotiff 1.4.0 & 1.4.1 I also did a license & copyright review for
> the update of the debian/copyright file with the new machine readable
> format, and I also consider the EPSG ToS to be incompatible with the DFSG:
>
> https://www.debian.org/social_contract#guidelines
>
> If you want the opinion of Debian people other than the package
> maintainers you can contact [hidden email] who review
> the license & copyright of new packages before they're accepted into the
> archive. Or the general [hidden email] list.
>
> >> If the proposed database derived from the EPSG database is bound by the
> >> non-free EPSG ToS it won't be acceptable for Debian and by extension
> >> Ubuntu.>
> > I don't see how the situation is any different than it is now. The
> > community can bootstrap its own db, but the amount of expertise required
> > to do so in relation to the "convenience" of simply submitting to EPSG
> > makes it a tough sell.
> The EPSG ToS limitions don't seem to apply to derived subsets as long as
> they aren't attributed to the EPSG Dataset.
>
> In Debian we consider the derived EPSG data in proj/nad/epsg for example
> to fall under the MIT license of PROJ.4, because these are subsets of
> the EPSG data.
>
> Martin's proposal to use a different name and not attributing the
> changes to the EPSG Dataset should allow new database to be licensed
> freely (e.g. MIT, or maybe ODbL).

How would that be different from the current libgeotiff-epsg package ? Because
the later has epsg in its name and the directory is /usr/share/epsg_csv ?

When reading of 6.vii of http://www.epsg.org/TermsOfUse ("No data that has
been modified other than as permitted in these Terms of Use shall be attributed
to the EPSG Dataset.") , I'm not clear of what it really allows . Does that
explicetly mean that we are allowed to do any modification ? But in that case,
I'm not sure what the associated rights and obligations are.

>
> Kind Regards,
>
> Bas

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
MetaCRS mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/metacrs
Reply | Threaded
Open this post in threaded view
|

Re: [Proj] Common SQLite-based dictionaries

Sebastiaan Couwenberg
On 03-08-15 21:54, Even Rouault wrote:

> On Monday 03 August 2015 16:25:15 Sebastiaan Couwenberg wrote:
>> On 03-08-15 15:37, Howard Butler wrote:
>>>> On Aug 3, 2015, at 8:32 AM, Sebastiaan Couwenberg <[hidden email]>
> wrote:
>>>>> I recognize there are some things to work through on the EPSG ToS.
>>>>> Thanks for bringing these issues up.>>
>>>> For the eventual Debian package this is the most important issue to
>>>> resolve. The CSV files distributed with geotiff are split off because
>>>> the EPSG ToS is not acceptable for the Debian main repository, the ToS
>>>> is incompatible with the Debian Free Software Guidelines and the Open
>>>> Source Definition. The ToS discriminates against field of endeavor and
>>>> limits derived works via parameter modification restrictions.
>>>
>>> Are there some links to discussion about why Debian has made this
>>> determination?
>> The EPSG ToS was considered non-free by the initial maintainer, and
>> noted this in the README for the Debian package:
>>
>> "
>>  This version of the GeoTIFF library lacks the EPSG data files which
>>  are distributed in a separate non-free package libgeotiff-epsg due to
>>  license limitations.
>> "
>>
>> http://anonscm.debian.org/cgit/pkg-grass/libgeotiff-dfsg.git/tree/debian/REA
>> DME.Debian
>>
>> For libgeotiff 1.4.0 & 1.4.1 I also did a license & copyright review for
>> the update of the debian/copyright file with the new machine readable
>> format, and I also consider the EPSG ToS to be incompatible with the DFSG:
>>
>> https://www.debian.org/social_contract#guidelines
>>
>> If you want the opinion of Debian people other than the package
>> maintainers you can contact [hidden email] who review
>> the license & copyright of new packages before they're accepted into the
>> archive. Or the general [hidden email] list.
>>
>>>> If the proposed database derived from the EPSG database is bound by the
>>>> non-free EPSG ToS it won't be acceptable for Debian and by extension
>>>> Ubuntu.>
>>> I don't see how the situation is any different than it is now. The
>>> community can bootstrap its own db, but the amount of expertise required
>>> to do so in relation to the "convenience" of simply submitting to EPSG
>>> makes it a tough sell.
>> The EPSG ToS limitions don't seem to apply to derived subsets as long as
>> they aren't attributed to the EPSG Dataset.
>>
>> In Debian we consider the derived EPSG data in proj/nad/epsg for example
>> to fall under the MIT license of PROJ.4, because these are subsets of
>> the EPSG data.
>>
>> Martin's proposal to use a different name and not attributing the
>> changes to the EPSG Dataset should allow new database to be licensed
>> freely (e.g. MIT, or maybe ODbL).
>
> How would that be different from the current libgeotiff-epsg package ? Because
> the later has epsg in its name and the directory is /usr/share/epsg_csv ?

In essence it wouldn't be much different from the current
libgeotiff-epsg package.

But from what I understand of the proposed solution it would replace the
proj/nad/espg file for example.

This would mean a strict dependency of the gdal, proj, geotiff, etc
packages on the newly created srs-data package that includes the SRS
database built on top of the EPSG database ("standardize the [...] SRS
coordinate system handling dictionaries on a SQLite database that starts
with EPSG, with each project adding its own auxiliary tables as
necessary.").

The cascading reverse dependencies will require everything from proj on
up to move out of the Debian main repository into contrib/non-free
because at the core is a dependency on non-free data.

We have a similar unresolved problem with the OGC Document Notice terms
which disallows motification of their Standards works (CITE tests most
importantly), the XML schemas also fall under the Document Notice if you
don't use a different namespace for a modified schema.

These unavoidable non-free parts in the GFOSS ecosystem make it
impossible to build a truely free system in which the right to make
modifications is essential.

> When reading of 6.vii of http://www.epsg.org/TermsOfUse ("No data that has
> been modified other than as permitted in these Terms of Use shall be attributed
> to the EPSG Dataset.") , I'm not clear of what it really allows . Does that
> explicetly mean that we are allowed to do any modification ? But in that case,
> I'm not sure what the associated rights and obligations are.

The unabiguity was also raised in the debian-legal posts linked from:
https://trac.osgeo.org/gdal/wiki/RevisedEPSGLicense

EPSG is the only party that can authoritatively answer your question.

My interpretation is that you're allowed to make modifications if you do
not claim that EPSG is responsible for them. In a similar spirit as the
"Integrity of The Author's Source Code" compromise:

"
 The license may restrict source-code from being distributed in
 modified form only if the license allows the distribution of "patch
 files" with the source code for the purpose of modifying the program
 at build time. The license must explicitly permit distribution of
 software built from modified source code.The license may require
 derived works to carry a different name or version number from the
 original software. (This is a compromise. The Debian group encourages
 all authors not to restrict any files, source or binary, from being
 modified.)
"

https://www.debian.org/social_contract#guidelines

I can envision a project that takes the EPSG database and with a
collection of SQL scripts (patches) creates the database for proj, gdal
& friends. That would be compatible with the compromise when you apply
it to data instead of software. The EPSG ToS is just not very explicitly
about being allowed to distribute changes.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
_______________________________________________
MetaCRS mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/metacrs
Reply | Threaded
Open this post in threaded view
|

Re: [Proj] Common SQLite-based dictionaries

Martin Desruisseaux-3
In reply to this post by Even Rouault-2
Le 03/08/15 21:54, Even Rouault a écrit :
>> Martin's proposal to use a different name and not attributing the
>> changes to the EPSG Dataset should allow new database to be licensed
>> freely (e.g. MIT, or maybe ODbL).
> How would that be different from the current libgeotiff-epsg package ? Because
> the later has epsg in its name and the directory is /usr/share/epsg_csv ?

I don't think that the file or directory name matter. In my
understanding, the problem is that when a user asks to the library
"gives me the CRS for EPSG code 4326", he get a CRS which is different
than what is specified by the EPSG authority, with changes not allowed
by the terms of use. In my understanding if we really want those
different CRS, we can but we should not claim that those CRS are conform
to the EPSG definitions. So the documentation should not said "this
function returns a CRS for the given EPSG code" or "this database
contains EPSG definitions". We may said "based on EPSG definitions" however.

    Martin

_______________________________________________
MetaCRS mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/metacrs
Reply | Threaded
Open this post in threaded view
|

Re: [Proj] Common SQLite-based dictionaries

Martin Desruisseaux-3
In reply to this post by Sebastiaan Couwenberg
Le 03/08/15 22:37, Sebastiaan Couwenberg a écrit :
> I can envision a project that takes the EPSG database and with a
> collection of SQL scripts (patches) creates the database for proj, gdal
> & friends. That would be compatible with the compromise when you apply
> it to data instead of software. The EPSG ToS is just not very explicitly
> about being allowed to distribute changes.

I think that the intend of EPSG term of use is to make sure that
"EPSG:something" is understood in the same way by everyone. Applying
patches with SQL scripts compromise this goal in the same way than
modifying the data directly, unless we make clear that this is not
anymore EPSG definitions.

    Martin

_______________________________________________
MetaCRS mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/metacrs
Reply | Threaded
Open this post in threaded view
|

Re: [Proj] Common SQLite-based dictionaries

Sebastiaan Couwenberg
On 03-08-15 22:46, Martin Desruisseaux wrote:

> Le 03/08/15 22:37, Sebastiaan Couwenberg a écrit :
>> I can envision a project that takes the EPSG database and with a
>> collection of SQL scripts (patches) creates the database for proj, gdal
>> & friends. That would be compatible with the compromise when you apply
>> it to data instead of software. The EPSG ToS is just not very explicitly
>> about being allowed to distribute changes.
>
> I think that the intend of EPSG term of use is to make sure that
> "EPSG:something" is understood in the same way by everyone. Applying
> patches with SQL scripts compromise this goal in the same way than
> modifying the data directly, unless we make clear that this is not
> anymore EPSG definitions.

That's probably correct.

The official Dutch NTv2 & VDatum grids have similar restrictions for
modifications of the published correction values. Their intent of that
clause is to prevent significant differences in the results between
various software projects when the same grids are used.

That all boils down to standards being non-free in essence, because
freely modifying a standard defeats the interoperability goal. In Debian
this problem manifests in the IETF RFCs:

https://wiki.debian.org/NonFreeIETFDocuments

We need something like an Open Standards Definition to serve as
reference how to reconcile the non-free nature of standards in
free/libre/open-source software software.

The DFSG & Open Source Definition can then be amended to include a
compromise for standards that comply with the Open Standards Definition.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
_______________________________________________
MetaCRS mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/metacrs
Reply | Threaded
Open this post in threaded view
|

Re: [Proj] Common SQLite-based dictionaries

Even Rouault-2
In reply to this post by Martin Desruisseaux-3
On Monday 03 August 2015 22:46:41 Martin Desruisseaux wrote:

> Le 03/08/15 22:37, Sebastiaan Couwenberg a écrit :
> > I can envision a project that takes the EPSG database and with a
> > collection of SQL scripts (patches) creates the database for proj, gdal
> > & friends. That would be compatible with the compromise when you apply
> > it to data instead of software. The EPSG ToS is just not very explicitly
> > about being allowed to distribute changes.
>
> I think that the intend of EPSG term of use is to make sure that
> "EPSG:something" is understood in the same way by everyone. Applying
> patches with SQL scripts compromise this goal in the same way than
> modifying the data directly, unless we make clear that this is not
> anymore EPSG definitions.

Let's say we distribute a SQLite version of the PostgreSQL scripts unmodified
(or within the allowed modifications). If the *software* that use it return an
"incorrect" definition when querying EPSG:4326 (for example a WKT with AXIS
stripped), that has nothing to do with the data being distributed. It is a
bug/feature in the way the software interprets the data.

And if this database includes an extra proj.4 dedicated table with records
like '4326', '+proj=longlat +datum=WGS84 +no_defs' or '4322', '+proj=longlat
+ellps=WGS72 +towgs84=0,0,4.5,0,0,0.554,0.2263 +no_defs' that doesn't modify
the original dataset.

>
>     Martin
>
> _______________________________________________
> MetaCRS mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/metacrs

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
MetaCRS mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/metacrs
Reply | Threaded
Open this post in threaded view
|

Re: [Proj] Common SQLite-based dictionaries

Even Rouault-2
In reply to this post by Sebastiaan Couwenberg
On Monday 03 August 2015 22:37:18 Sebastiaan Couwenberg wrote:

> On 03-08-15 21:54, Even Rouault wrote:
> > On Monday 03 August 2015 16:25:15 Sebastiaan Couwenberg wrote:
> >> On 03-08-15 15:37, Howard Butler wrote:
> >>>> On Aug 3, 2015, at 8:32 AM, Sebastiaan Couwenberg <[hidden email]>
> >
> > wrote:
> >>>>> I recognize there are some things to work through on the EPSG ToS.
> >>>>> Thanks for bringing these issues up.>>
> >>>>
> >>>> For the eventual Debian package this is the most important issue to
> >>>> resolve. The CSV files distributed with geotiff are split off because
> >>>> the EPSG ToS is not acceptable for the Debian main repository, the ToS
> >>>> is incompatible with the Debian Free Software Guidelines and the Open
> >>>> Source Definition. The ToS discriminates against field of endeavor and
> >>>> limits derived works via parameter modification restrictions.
> >>>
> >>> Are there some links to discussion about why Debian has made this
> >>> determination?
> >>
> >> The EPSG ToS was considered non-free by the initial maintainer, and
> >> noted this in the README for the Debian package:
> >>
> >> "
> >>
> >>  This version of the GeoTIFF library lacks the EPSG data files which
> >>  are distributed in a separate non-free package libgeotiff-epsg due to
> >>  license limitations.
> >>
> >> "
> >>
> >> http://anonscm.debian.org/cgit/pkg-grass/libgeotiff-dfsg.git/tree/debian/
> >> REA DME.Debian
> >>
> >> For libgeotiff 1.4.0 & 1.4.1 I also did a license & copyright review for
> >> the update of the debian/copyright file with the new machine readable
> >> format, and I also consider the EPSG ToS to be incompatible with the
> >> DFSG:
> >>
> >> https://www.debian.org/social_contract#guidelines
> >>
> >> If you want the opinion of Debian people other than the package
> >> maintainers you can contact [hidden email] who review
> >> the license & copyright of new packages before they're accepted into the
> >> archive. Or the general [hidden email] list.
> >>
> >>>> If the proposed database derived from the EPSG database is bound by the
> >>>> non-free EPSG ToS it won't be acceptable for Debian and by extension
> >>>> Ubuntu.>
> >>>
> >>> I don't see how the situation is any different than it is now. The
> >>> community can bootstrap its own db, but the amount of expertise required
> >>> to do so in relation to the "convenience" of simply submitting to EPSG
> >>> makes it a tough sell.
> >>
> >> The EPSG ToS limitions don't seem to apply to derived subsets as long as
> >> they aren't attributed to the EPSG Dataset.
> >>
> >> In Debian we consider the derived EPSG data in proj/nad/epsg for example
> >> to fall under the MIT license of PROJ.4, because these are subsets of
> >> the EPSG data.
> >>
> >> Martin's proposal to use a different name and not attributing the
> >> changes to the EPSG Dataset should allow new database to be licensed
> >> freely (e.g. MIT, or maybe ODbL).
> >
> > How would that be different from the current libgeotiff-epsg package ?
> > Because the later has epsg in its name and the directory is
> > /usr/share/epsg_csv ?
> In essence it wouldn't be much different from the current
> libgeotiff-epsg package.
>
> But from what I understand of the proposed solution it would replace the
> proj/nad/espg file for example.
>
> This would mean a strict dependency of the gdal, proj, geotiff, etc
> packages on the newly created srs-data package that includes the SRS
> database built on top of the EPSG database ("standardize the [...] SRS
> coordinate system handling dictionaries on a SQLite database that starts
> with EPSG, with each project adding its own auxiliary tables as
> necessary.").
>
> The cascading reverse dependencies will require everything from proj on
> up to move out of the Debian main repository into contrib/non-free
> because at the core is a dependency on non-free data.

The dependency to the srs.db package could be a weak one ("recommended"), and
GDAL/proj/libgeotiff could be made to still work if the srs.db isn't found,
although some interesting functionality would be missing.

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
MetaCRS mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/metacrs
Reply | Threaded
Open this post in threaded view
|

Re: [Proj] Common SQLite-based dictionaries

Sebastiaan Couwenberg
On 03-08-15 23:31, Even Rouault wrote:

> On Monday 03 August 2015 22:37:18 Sebastiaan Couwenberg wrote:
>> On 03-08-15 21:54, Even Rouault wrote:
>>> On Monday 03 August 2015 16:25:15 Sebastiaan Couwenberg wrote:
>>>> On 03-08-15 15:37, Howard Butler wrote:
>>>>>> On Aug 3, 2015, at 8:32 AM, Sebastiaan Couwenberg <[hidden email]>
>>>
>>> wrote:
>>>>>>> I recognize there are some things to work through on the EPSG ToS.
>>>>>>> Thanks for bringing these issues up.>>
>>>>>>
>>>>>> For the eventual Debian package this is the most important issue to
>>>>>> resolve. The CSV files distributed with geotiff are split off because
>>>>>> the EPSG ToS is not acceptable for the Debian main repository, the ToS
>>>>>> is incompatible with the Debian Free Software Guidelines and the Open
>>>>>> Source Definition. The ToS discriminates against field of endeavor and
>>>>>> limits derived works via parameter modification restrictions.
>>>>>
>>>>> Are there some links to discussion about why Debian has made this
>>>>> determination?
>>>>
>>>> The EPSG ToS was considered non-free by the initial maintainer, and
>>>> noted this in the README for the Debian package:
>>>>
>>>> "
>>>>
>>>>  This version of the GeoTIFF library lacks the EPSG data files which
>>>>  are distributed in a separate non-free package libgeotiff-epsg due to
>>>>  license limitations.
>>>>
>>>> "
>>>>
>>>> http://anonscm.debian.org/cgit/pkg-grass/libgeotiff-dfsg.git/tree/debian/
>>>> REA DME.Debian
>>>>
>>>> For libgeotiff 1.4.0 & 1.4.1 I also did a license & copyright review for
>>>> the update of the debian/copyright file with the new machine readable
>>>> format, and I also consider the EPSG ToS to be incompatible with the
>>>> DFSG:
>>>>
>>>> https://www.debian.org/social_contract#guidelines
>>>>
>>>> If you want the opinion of Debian people other than the package
>>>> maintainers you can contact [hidden email] who review
>>>> the license & copyright of new packages before they're accepted into the
>>>> archive. Or the general [hidden email] list.
>>>>
>>>>>> If the proposed database derived from the EPSG database is bound by the
>>>>>> non-free EPSG ToS it won't be acceptable for Debian and by extension
>>>>>> Ubuntu.>
>>>>>
>>>>> I don't see how the situation is any different than it is now. The
>>>>> community can bootstrap its own db, but the amount of expertise required
>>>>> to do so in relation to the "convenience" of simply submitting to EPSG
>>>>> makes it a tough sell.
>>>>
>>>> The EPSG ToS limitions don't seem to apply to derived subsets as long as
>>>> they aren't attributed to the EPSG Dataset.
>>>>
>>>> In Debian we consider the derived EPSG data in proj/nad/epsg for example
>>>> to fall under the MIT license of PROJ.4, because these are subsets of
>>>> the EPSG data.
>>>>
>>>> Martin's proposal to use a different name and not attributing the
>>>> changes to the EPSG Dataset should allow new database to be licensed
>>>> freely (e.g. MIT, or maybe ODbL).
>>>
>>> How would that be different from the current libgeotiff-epsg package ?
>>> Because the later has epsg in its name and the directory is
>>> /usr/share/epsg_csv ?
>> In essence it wouldn't be much different from the current
>> libgeotiff-epsg package.
>>
>> But from what I understand of the proposed solution it would replace the
>> proj/nad/espg file for example.
>>
>> This would mean a strict dependency of the gdal, proj, geotiff, etc
>> packages on the newly created srs-data package that includes the SRS
>> database built on top of the EPSG database ("standardize the [...] SRS
>> coordinate system handling dictionaries on a SQLite database that starts
>> with EPSG, with each project adding its own auxiliary tables as
>> necessary.").
>>
>> The cascading reverse dependencies will require everything from proj on
>> up to move out of the Debian main repository into contrib/non-free
>> because at the core is a dependency on non-free data.
>
> The dependency to the srs.db package could be a weak one ("recommended"), and
> GDAL/proj/libgeotiff could be made to still work if the srs.db isn't found,
> although some interesting functionality would be missing.

To be Debian Policy compliant, a package in main can only Suggest a
package in non-free (as libgeotiff-dev does for libgeotiff-epsg).
Suggests are not installed by default whereas Depends & Recommends are.

Packages that have a strict dependency (expressed with Recommends or
Depends) on a non-free package but are themselves fully (dfsg-compliant)
free software live in the contrib repository. Both contrib & non-free
are not of the Debian system (but do use most of the packaging
infrastructure, builds for other architectures must be requested
explicitly for non-free).

I'm not entirely opposed to move all of the recursive dependencies to
contrib/non-free to acknowledge the reality of the esstial non-free
parts in the open geospatial ecosystem. But this is a great disservice
to our users I can't endorse. Nor do I want the increased maintenance
burden. Which brings us back to the uncomfortable position in which we
have to deal with the non-free parts in some way to keep everything else
free and functional. I don't have a good solution to this problem.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
_______________________________________________
MetaCRS mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/metacrs
Reply | Threaded
Open this post in threaded view
|

Re: [Proj] Common SQLite-based dictionaries

Martin Desruisseaux-3
In reply to this post by Even Rouault-2
Le 03/08/15 23:21, Even Rouault a écrit :
> And if this database includes an extra proj.4 dedicated table with records
> like '4326', '+proj=longlat +datum=WGS84 +no_defs' or '4322', '+proj=longlat
> +ellps=WGS72 +towgs84=0,0,4.5,0,0,0.554,0.2263 +no_defs' that doesn't modify
> the original dataset.

But it still a derivative work: EPSG did all the hard work of collecting
the data, the above table is just a reformatting of those data. We would
be unable to create such table from scratch without copying EPSG data.
In my understanding, it still fall under the EPSG terms of use.

    Martin

_______________________________________________
MetaCRS mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/metacrs
Reply | Threaded
Open this post in threaded view
|

Re: [Proj] Common SQLite-based dictionaries

Even Rouault-2
In reply to this post by Sebastiaan Couwenberg
> To be Debian Policy compliant, a package in main can only Suggest a
> package in non-free (as libgeotiff-dev does for libgeotiff-epsg).
> Suggests are not installed by default whereas Depends & Recommends are.

Thanks for the clarification. I meant something like Suggests. The idea would
be to have all other packages as first-class free packages, and even if not
ideal, somewhere in the projects documentation there would be a warning note:
"consider installing the srs_data package as well".

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
MetaCRS mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/metacrs