From even.rouault at spatialys.com  Tue Jan 10 08:25:34 2017
From: even.rouault at spatialys.com (Even Rouault)
Date: Tue, 10 Jan 2017 14:25:34 +0100
Subject: [Proj] EPSG v9.0 upgrade
Message-ID: <3120596.LBnunzVJ1o@even-i700>

Hi,

I've updated to the EPSG v9.0 database.

The relevant tickets are:
* libgeotiff: https://trac.osgeo.org/geotiff/ticket/83
* GDAL: https://trac.osgeo.org/gdal/ticket/6772
* proj.4: proj.4: ?https://github.com/OSGeo/proj.4/issues/477
* postgis: ?https://trac.osgeo.org/postgis/ticket/3684 (patch submitted)

Combined with that update, I've also applied datum shift overrides for EPSG:4149 (CH1903), 
EPSG:3844 (Pulkovo 1942(58) / Stereo70 Romania), EPSG:31251,31252,31253 (MGI (Ferro) / 
Austria), EPSG:2397/2398/2399 (Pulkovo 1942(83) / 3-degree Gauss-Kruger zone 3,4,5), EPSG:
2065 (S-JTSK (Ferro) / Krovak).

Those were awaiting in various GDAL/libgeotif/proj tickets (*), and were not doable until now 
for most of them, since there was no possibility of defining datum shift overrides specific to 
projected coordinate systems, before the changes done in https://trac.osgeo.org/geotiff/
changeset/2747 and
https://trac.osgeo.org/gdal/changeset/37080

Even


(*) From libgeotiff ChangeLog:

2017-01-10 Even Rouault <even dot rouault at spatialys dot com>

	* csv/datum_shift_pref.csv: add overrides for PCS 2065
	(S-JTSK (Ferro) / Krovak)
	Fixes https://trac.osgeo.org/gdal/ticket/4762 and
	https://github.com/OSGeo/proj.4/issues/185

2017-01-10 Even Rouault <even dot rouault at spatialys dot com>

	* csv/datum_shift_pref.csv: add overrides for PCS 2397/2398/2399
	(Pulkovo 1942(83) / 3-degree Gauss-Kruger zone 3,4,5)
	Fixes https://github.com/OSGeo/proj.4/issues/235

2017-01-10 Even Rouault <even dot rouault at spatialys dot com>

	* csv/datum_shift_pref.csv: add overrides for PCS 31251,31252,31253
	(MGI (Ferro) / Austria)
	Fixes https://github.com/OSGeo/proj.4/issues/254

2017-01-10 Even Rouault <even dot rouault at spatialys dot com>

	* csv/build_pcs.py, csv/datum_shift_pref.csv: add mechanism to define
	TOWGS84 parameters per PCS (instead of only relying on the TOWGS84
	parameters of the underlying GCS).
	Add override for EPSG:3844 ("Pulkovo 1942(58) / Stereo70" Romania)
	Fixes https://trac.osgeo.org/geotiff/ticket/52

2017-01-10 Even Rouault <even dot rouault at spatialys dot com>

	* csv/datum_shift_pref.csv: add override for CH1903 (EPSG:4149)
	Fixes https://trac.osgeo.org/geotiff/ticket/73


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maptools.org/pipermail/proj/attachments/20170110/80edee37/attachment.htm 

From ndzinn at comcast.net  Tue Jan 10 09:13:50 2017
From: ndzinn at comcast.net (Noel Zinn (cc))
Date: Tue, 10 Jan 2017 08:13:50 -0600
Subject: [Proj] EPSG v9.0 upgrade
In-Reply-To: <3120596.LBnunzVJ1o@even-i700>
References: <3120596.LBnunzVJ1o@even-i700>
Message-ID: <B6EF12A8FF4A4CE9BAE6C4D52CEE49A9@NoelDellPC>

Evan,

Congratulations on your recognition in xyHt magazine?s ?40 under 40? edition.

Noel

Noel Zinn, Principal, Hydrometronics LLC
+1-832-539-1472 (office), +1-281-221-0051 (cell)
noel.zinn at hydrometronics.com (email)
http://www.hydrometronics.com (website)


From: Even Rouault 
Sent: Tuesday, January 10, 2017 7:25 AM
To: gdal-dev at lists.osgeo.org 
Cc: proj at lists.maptools.org ; geotiff at lists.maptools.org ; qgis-developer at lists.osgeo.org ; 'PostGIS Development Discussion' ; grass-dev at lists.osgeo.org 
Subject: [Proj] EPSG v9.0 upgrade

Hi,



I've updated to the EPSG v9.0 database.



The relevant tickets are:

* libgeotiff: https://trac.osgeo.org/geotiff/ticket/83

* GDAL: https://trac.osgeo.org/gdal/ticket/6772

* proj.4: proj.4: ?https://github.com/OSGeo/proj.4/issues/477

* postgis: ?https://trac.osgeo.org/postgis/ticket/3684 (patch submitted)



Combined with that update, I've also applied datum shift overrides for EPSG:4149 (CH1903), EPSG:3844 (Pulkovo 1942(58) / Stereo70 Romania), EPSG:31251,31252,31253 (MGI (Ferro) / Austria), EPSG:2397/2398/2399 (Pulkovo 1942(83) / 3-degree Gauss-Kruger zone 3,4,5), EPSG:2065 (S-JTSK (Ferro) / Krovak).



Those were awaiting in various GDAL/libgeotif/proj tickets (*), and were not doable until now for most of them, since there was no possibility of defining datum shift overrides specific to projected coordinate systems, before the changes done in https://trac.osgeo.org/geotiff/changeset/2747 and

https://trac.osgeo.org/gdal/changeset/37080



Even





(*) From libgeotiff ChangeLog:



2017-01-10 Even Rouault <even dot rouault at spatialys dot com>



* csv/datum_shift_pref.csv: add overrides for PCS 2065

(S-JTSK (Ferro) / Krovak)

Fixes https://trac.osgeo.org/gdal/ticket/4762 and

https://github.com/OSGeo/proj.4/issues/185



2017-01-10 Even Rouault <even dot rouault at spatialys dot com>



* csv/datum_shift_pref.csv: add overrides for PCS 2397/2398/2399

(Pulkovo 1942(83) / 3-degree Gauss-Kruger zone 3,4,5)

Fixes https://github.com/OSGeo/proj.4/issues/235



2017-01-10 Even Rouault <even dot rouault at spatialys dot com>



* csv/datum_shift_pref.csv: add overrides for PCS 31251,31252,31253

(MGI (Ferro) / Austria)

Fixes https://github.com/OSGeo/proj.4/issues/254



2017-01-10 Even Rouault <even dot rouault at spatialys dot com>



* csv/build_pcs.py, csv/datum_shift_pref.csv: add mechanism to define

TOWGS84 parameters per PCS (instead of only relying on the TOWGS84

parameters of the underlying GCS).

Add override for EPSG:3844 ("Pulkovo 1942(58) / Stereo70" Romania)

Fixes https://trac.osgeo.org/geotiff/ticket/52



2017-01-10 Even Rouault <even dot rouault at spatialys dot com>



* csv/datum_shift_pref.csv: add override for CH1903 (EPSG:4149)

Fixes https://trac.osgeo.org/geotiff/ticket/73





-- 

Spatialys - Geospatial professional services

http://www.spatialys.com



--------------------------------------------------------------------------------
_______________________________________________
Proj mailing list
Proj at lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maptools.org/pipermail/proj/attachments/20170110/ea56eea6/attachment-0001.htm 

From alexgleith at gmail.com  Tue Jan 17 19:01:02 2017
From: alexgleith at gmail.com (Alex Leith)
Date: Wed, 18 Jan 2017 00:01:02 +0000
Subject: [Proj] ICSM (Australia) transformation file licensing
Message-ID: <CAEvGJsq+ePO_UGmDO11RBqJ7d5Psm+U8fnzLuXKCX98M_PNYYA@mail.gmail.com>

Hi

I'm working with ICSM to incorporate Australian ntv2 grids into open source
software. There are two existing GSB files, and there will be another soon
for the new GDA2020 datum. ICSM are able and prepared to license the files
in any way.

I'd like to know what license to apply to these files in order to best
enable their inclusion into Proj4 and other projects?

Regards,

Alex
-- 

Alex Leith
0419 189 050
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maptools.org/pipermail/proj/attachments/20170118/891e54c7/attachment.htm 

From sebastic at xs4all.nl  Wed Jan 18 01:33:44 2017
From: sebastic at xs4all.nl (Sebastiaan Couwenberg)
Date: Wed, 18 Jan 2017 07:33:44 +0100
Subject: [Proj] ICSM (Australia) transformation file licensing
In-Reply-To: <CAEvGJsq+ePO_UGmDO11RBqJ7d5Psm+U8fnzLuXKCX98M_PNYYA@mail.gmail.com>
References: <CAEvGJsq+ePO_UGmDO11RBqJ7d5Psm+U8fnzLuXKCX98M_PNYYA@mail.gmail.com>
Message-ID: <54c38d10-adb6-ff70-d949-a1c25ba51258@xs4all.nl>

On 01/18/2017 01:01 AM, Alex Leith wrote:
> I'm working with ICSM to incorporate Australian ntv2 grids into open source
> software. There are two existing GSB files, and there will be another soon
> for the new GDA2020 datum. ICSM are able and prepared to license the files
> in any way.
> 
> I'd like to know what license to apply to these files in order to best
> enable their inclusion into Proj4 and other projects?

The NTv2 grids already included in the proj-datumgrids distribution are
in the public domain. Creative Commons CC0 is a better choice than PD
because it covers more jurisdictions.

The license for the Australian grids needs to be compatible with the
terms of the GPL-2+ to allow other projects (PostGIS specifically) to
include it too.

Please don't disallow modification of the correction values like EPSG
and many other national grids following their lead, those terms are
incompatible with the GPL-2+.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

From martin.desruisseaux at geomatys.com  Wed Jan 18 03:17:07 2017
From: martin.desruisseaux at geomatys.com (Martin Desruisseaux)
Date: Wed, 18 Jan 2017 17:17:07 +0900
Subject: [Proj] ICSM (Australia) transformation file licensing
In-Reply-To: <54c38d10-adb6-ff70-d949-a1c25ba51258@xs4all.nl>
References: <CAEvGJsq+ePO_UGmDO11RBqJ7d5Psm+U8fnzLuXKCX98M_PNYYA@mail.gmail.com>
	<54c38d10-adb6-ff70-d949-a1c25ba51258@xs4all.nl>
Message-ID: <370b13fb-fb80-39cc-94c8-8ab0a1f63dc3@geomatys.com>

Le 18/01/2017 ? 15:33, Sebastiaan Couwenberg a ?crit :

> Please don't disallow modification of the correction values like EPSG
> and many other national grids following their lead, those terms are
> incompatible with the GPL-2+.
>
Well, there is discussion at OGC about "open standard" versus "open
source". A summary is available in the "OGC API white paper" at [1].
Chapter 5 lists criterion similar to Open Source software, but
intentionally excludes from that list the freedom to modify the standard.

Open Source and Open Standard have different goals. The purpose of a
standard (even open) is compromised if anyone is allowed to modify it.
Of course restrictions like the EPSG terms of use are annoying for open
source licenses like GPL or Apache, but consequences of allowing
departure can be worst. The mess about axis order is an example.
(Actually the problem is not that much that some software change the
axis order, but that they are still using the "EPSG" name for their
modified CRS).

EPSG terms of use try to find a compromise by actually allowing some
modifications, provided that they preserve numerical equivalence. If
numerical equivalence is broken, then the modified CRS shall not be
named "EPSG". It can be a safety issue in transportation and other
domains if someone though that a coordinate was given in the "EPSG:4326"
CRS while actually it was given in "MyOwnTasteOfEPSG:4326" CRS. It seems
to me that the same issue applies to datum grid shift files and other
data published by authoritative agencies.

I would like to stress out that above does not forbid all modifications.
Some modifications are okay if they either preserve numerical
equivalence or make very clear (by using a different name among others)
that the modified data are not any more compliant with the standard. The
golden rule is to not mislead the users.

I agree that this is annoying for open source software, but we can
workaround by putting the data in a "non-free" (or other name)
repository for making clear that those data are subject to different
licensing conditions than the GPL ones. If forcing the users to download
two bundles is considered too annoying, I think it is still possible to
have a single bundle if the data terms of use are shown together with
the GPL license when the user get Proj.4.

    Martin


[1]
https://raw.githubusercontent.com/opengeospatial/api_whitepaper/master/book.pdf


From gdt at lexort.com  Wed Jan 18 07:32:04 2017
From: gdt at lexort.com (Greg Troxel)
Date: Wed, 18 Jan 2017 07:32:04 -0500
Subject: [Proj] ICSM (Australia) transformation file licensing
In-Reply-To: <54c38d10-adb6-ff70-d949-a1c25ba51258@xs4all.nl> (Sebastiaan
	Couwenberg's message of "Wed, 18 Jan 2017 07:33:44 +0100")
References: <CAEvGJsq+ePO_UGmDO11RBqJ7d5Psm+U8fnzLuXKCX98M_PNYYA@mail.gmail.com>
	<54c38d10-adb6-ff70-d949-a1c25ba51258@xs4all.nl>
Message-ID: <smu7f5sblbv.fsf@linuxpal.mit.edu>


Sebastiaan Couwenberg <sebastic at xs4all.nl> writes:

> On 01/18/2017 01:01 AM, Alex Leith wrote:
>> I'm working with ICSM to incorporate Australian ntv2 grids into open source
>> software. There are two existing GSB files, and there will be another soon
>> for the new GDA2020 datum. ICSM are able and prepared to license the files
>> in any way.
>> 
>> I'd like to know what license to apply to these files in order to best
>> enable their inclusion into Proj4 and other projects?
>
> The NTv2 grids already included in the proj-datumgrids distribution are
> in the public domain. Creative Commons CC0 is a better choice than PD
> because it covers more jurisdictions.
>
> The license for the Australian grids needs to be compatible with the
> terms of the GPL-2+ to allow other projects (PostGIS specifically) to
> include it too.
>
> Please don't disallow modification of the correction values like EPSG
> and many other national grids following their lead, those terms are
> incompatible with the GPL-2+.

Agreed.  Before I read Sebastian's reply I was going to suggest CC0.  I
really do not think there is much actual danger of trouble.  Everyone in
the community knows that randomly changing projection code files to
return wrong data is not helpful and I really don't think people are
going to do it.  And if they did, everybody else would then shun such a
distribution.  For example, proj is legally free to make a change that
computes UTM by adding 17m to easting and northing, and that would have
a similar effect of users getting wrong data.  But no one is worried
about that happening, and rightly so.

A license that doesn't permit modifications is not compatible with all
Free Software.  It's not just GPL; such a license is also not compatible
with the BSD license.  (It is true that BSD-licensed projects are less
bothered by non-free data licenses, because distributing a tarball that
is mostly Free plus some non-free data, while not under a Free license,
is under a messy license that is compatible with the BSD license.  But
the package is no longer Free Software.)

A middle ground might be CC0 with some extra text:

  To preserve integrity of the projection data, users are strongly
  requested not to make modifications that change numeric results.

Another approach might be to use a 2-clause BSD license that, while
permitting modification, does not allow the modified work to be
distributed under the original name.   But I would suggest that this is
not necessary and just causes needless work from people who are making
changes like fixing == to = to make shell scripts follow POSIX, who then
have to think about whether their change is one that triggers the clause
prohibiting using the name for modified works.

The real way to ensure integrity of geodetic calculation is to publish
test vectors and perhaps code, and encourage those to be added to unit
tests in software that uses the transforms.  Again these can be CC0 --
no one is going to pay attention to modified test vectors.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 162 bytes
Desc: not available
Url : http://lists.maptools.org/pipermail/proj/attachments/20170118/2ba0ff61/attachment.pgp 

From martin.desruisseaux at geomatys.com  Wed Jan 18 12:22:16 2017
From: martin.desruisseaux at geomatys.com (Martin Desruisseaux)
Date: Thu, 19 Jan 2017 02:22:16 +0900
Subject: [Proj] ICSM (Australia) transformation file licensing
In-Reply-To: <smu7f5sblbv.fsf@linuxpal.mit.edu>
References: <CAEvGJsq+ePO_UGmDO11RBqJ7d5Psm+U8fnzLuXKCX98M_PNYYA@mail.gmail.com>
	<54c38d10-adb6-ff70-d949-a1c25ba51258@xs4all.nl>
	<smu7f5sblbv.fsf@linuxpal.mit.edu>
Message-ID: <3c8a778d-e6bc-375b-7621-6bee14e21d31@geomatys.com>

Le 18/01/2017 ? 21:32, Greg Troxel a ?crit :

> Everyone in the community knows that randomly changing projection code
> files to return wrong data is not helpful and I really don't think
> people are going to do it.
>
But isn't what Proj.4 did when changing axis order? I see units of
measurement issues (e.g. in WKT) as another example.


> A license that doesn't permit modifications is not compatible with all
> Free Software. It's not just GPL; such a license is also not
> compatible with the BSD license.
>
Indeed. But some issues are more important than compatibility with open
source licenses, and standard integrity may be considered as one of
them. Projects who change the data do that because they think that their
changes are legitimate, not because they want to be evil. A typical
example is ignoring some aspects that a developer considers as useless
complexity (e.g. axis order and units of measurement). It is okay to not
implement every aspects of a standard, but when ignoring an aspect
breaks the interoperability goal of that standard, we have a problem.
The EPSG example teaches us that not everyone has an understanding of
"legitimate change" that preserve data integrity, thus the EPSG effort
to clarify which changes are permitted.


> Another approach might be to use a 2-clause BSD license that, while
> permitting modification, does not allow the modified work to be
> distributed under the original name. But I would suggest that this is
> not necessary and just causes needless work from people who are making
> changes like fixing == to = to make shell scripts follow POSIX, who
> then have to think about whether their change is one that triggers the
> clause prohibiting using the name for modified works.
>
I think that protecting the original name could help. But I'm not sure
to understand correctly if in above paragraph, "not necessary" means
"because we do not expect peoples to do that" or "because the
consequences are not considered important"?


> The real way to ensure integrity of geodetic calculation is to publish
> test vectors and perhaps code, and encourage those to be added to unit
> tests in software that uses the transforms. Again these can be CC0 --
> no one is going to pay attention to modified test vectors.
>
Right - this is also what EPSG tried to do with Geospatial Integrity of
Geoscience Software (GIGS) tests. I would support moving forward with
this approach and I can help, but this could be the subject of another
thread.

    Regards,

        Martin



From sebastic at xs4all.nl  Wed Jan 18 13:31:14 2017
From: sebastic at xs4all.nl (Sebastiaan Couwenberg)
Date: Wed, 18 Jan 2017 19:31:14 +0100
Subject: [Proj] ICSM (Australia) transformation file licensing
In-Reply-To: <370b13fb-fb80-39cc-94c8-8ab0a1f63dc3@geomatys.com>
References: <CAEvGJsq+ePO_UGmDO11RBqJ7d5Psm+U8fnzLuXKCX98M_PNYYA@mail.gmail.com>
	<54c38d10-adb6-ff70-d949-a1c25ba51258@xs4all.nl>
	<370b13fb-fb80-39cc-94c8-8ab0a1f63dc3@geomatys.com>
Message-ID: <51f24249-fc6a-23fd-cb7f-055cddb8b5e0@xs4all.nl>

On 01/18/2017 09:17 AM, Martin Desruisseaux wrote:
> Le 18/01/2017 ? 15:33, Sebastiaan Couwenberg a ?crit :
> 
>> Please don't disallow modification of the correction values like EPSG
>> and many other national grids following their lead, those terms are
>> incompatible with the GPL-2+.
>
> Well, there is discussion at OGC about "open standard" versus "open
> source". A summary is available in the "OGC API white paper" at [1].
> Chapter 5 lists criterion similar to Open Source software, but
> intentionally excludes from that list the freedom to modify the standard.

I've tried to have a discussion with OGC about the issues with their
licensing of standards and their implementation in Free Software
projects several times in the past, all I every got was a reply that
they would discuss it internally and never heard from them again.

This lead me to give up on ever making progress on this issue, the core
of geospatial software is simply non-free and the organisations involved
have not shown willingness to work with the community to resolve that.

The authors of the AC codec made a similar decision to not allow
modification, which subsequently made its use in LASzip problematic
enough that it cannot be included in Linux distributions and users of
LiDAR projects are forced to maintain custom builds because
distributions cannot provide support the LAZ format.

> Open Source and Open Standard have different goals. The purpose of a
> standard (even open) is compromised if anyone is allowed to modify it.
> Of course restrictions like the EPSG terms of use are annoying for open
> source licenses like GPL or Apache, but consequences of allowing
> departure can be worst. The mess about axis order is an example.
> (Actually the problem is not that much that some software change the
> axis order, but that they are still using the "EPSG" name for their
> modified CRS).

Open Source implementations of Open Standards help them thrive,
licensing Open Standards in ways that make them incompatible with open
source projects hinder adoption of the standards.

PROJ.4 using the EPSG name is indeed a problem that should be fixed.

> EPSG terms of use try to find a compromise by actually allowing some
> modifications, provided that they preserve numerical equivalence. If
> numerical equivalence is broken, then the modified CRS shall not be
> named "EPSG". It can be a safety issue in transportation and other
> domains if someone though that a coordinate was given in the "EPSG:4326"
> CRS while actually it was given in "MyOwnTasteOfEPSG:4326" CRS. It seems
> to me that the same issue applies to datum grid shift files and other
> data published by authoritative agencies.
> 
> I would like to stress out that above does not forbid all modifications.
> Some modifications are okay if they either preserve numerical
> equivalence or make very clear (by using a different name among others)
> that the modified data are not any more compliant with the standard. The
> golden rule is to not mislead the users.

While I understand the motivations of EPSG, just like I understand them
of the Dutch Kadaster with whom I've had the same discussion after they
published their NTv2 correction grids, limiting modification is simply
incompatible with Free Software licenses.

The right to make modifications is simply essential to Free Software. As
Greg also mentioned, in practice no one wants to make use of this right
because that would make their implementation incompatible with the rest
of the world beating the purpose of standards.

> I agree that this is annoying for open source software, but we can
> workaround by putting the data in a "non-free" (or other name)
> repository for making clear that those data are subject to different
> licensing conditions than the GPL ones. If forcing the users to download
> two bundles is considered too annoying, I think it is still possible to
> have a single bundle if the data terms of use are shown together with
> the GPL license when the user get Proj.4.

"annoying" is not the right word. Limiting modification simply means
that the grid shift files cannot be included in open source projects
using Free Software licenses ensuring it cannot be working out-of-the
box. The users are forced to retrieve and install the grids themselves.

I'm my opinion, all organisations publishing national grid shift files
should consider they're stance on limiting modifications. The French and
New Zealand grids are public domain, and the Hungarian grid is GPL-2+.
They apparently consider compatibility with Free Software projects more
important than limiting modification.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

From even.rouault at spatialys.com  Wed Jan 18 14:34:38 2017
From: even.rouault at spatialys.com (Even Rouault)
Date: Wed, 18 Jan 2017 20:34:38 +0100
Subject: [Proj] ICSM (Australia) transformation file licensing
In-Reply-To: <51f24249-fc6a-23fd-cb7f-055cddb8b5e0@xs4all.nl>
References: <CAEvGJsq+ePO_UGmDO11RBqJ7d5Psm+U8fnzLuXKCX98M_PNYYA@mail.gmail.com>
	<370b13fb-fb80-39cc-94c8-8ab0a1f63dc3@geomatys.com>
	<51f24249-fc6a-23fd-cb7f-055cddb8b5e0@xs4all.nl>
Message-ID: <1686182.M3UKYyI3vf@even-i700>

> PROJ.4 using the EPSG name is indeed a problem that should be fixed.

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

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. 

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.

> I'm my opinion, all organisations publishing national grid shift files
> should consider they're stance on limiting modifications. The French and
> New Zealand grids are public domain, and the Hungarian grid is GPL-2+.
> They apparently consider compatibility with Free Software projects more
> important than limiting modification.

+1. 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. Open source software and open data also leave the 
door open to the possibility of doing non-sense with them, and that's perfectly fine. As 
raised, even if the original data is unaltered, the software can still make a wrong use of it 
anyway.

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


Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maptools.org/pipermail/proj/attachments/20170118/a3fe7a25/attachment.htm 

From martin.desruisseaux at geomatys.com  Thu Jan 19 00:32:34 2017
From: martin.desruisseaux at geomatys.com (Martin Desruisseaux)
Date: Thu, 19 Jan 2017 14:32:34 +0900
Subject: [Proj] ICSM (Australia) transformation file licensing
In-Reply-To: <1686182.M3UKYyI3vf@even-i700>
References: <CAEvGJsq+ePO_UGmDO11RBqJ7d5Psm+U8fnzLuXKCX98M_PNYYA@mail.gmail.com>
	<370b13fb-fb80-39cc-94c8-8ab0a1f63dc3@geomatys.com>
	<51f24249-fc6a-23fd-cb7f-055cddb8b5e0@xs4all.nl>
	<1686182.M3UKYyI3vf@even-i700>
Message-ID: <3051857d-b467-838b-4c95-7e6243c7751f@geomatys.com>

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.maptools.org/pipermail/proj/attachments/20170119/79d6bbf8/attachment-0001.htm 

From martin.desruisseaux at geomatys.com  Thu Jan 19 01:36:36 2017
From: martin.desruisseaux at geomatys.com (Martin Desruisseaux)
Date: Thu, 19 Jan 2017 15:36:36 +0900
Subject: [Proj] ICSM (Australia) transformation file licensing
In-Reply-To: <51f24249-fc6a-23fd-cb7f-055cddb8b5e0@xs4all.nl>
References: <CAEvGJsq+ePO_UGmDO11RBqJ7d5Psm+U8fnzLuXKCX98M_PNYYA@mail.gmail.com>
	<54c38d10-adb6-ff70-d949-a1c25ba51258@xs4all.nl>
	<370b13fb-fb80-39cc-94c8-8ab0a1f63dc3@geomatys.com>
	<51f24249-fc6a-23fd-cb7f-055cddb8b5e0@xs4all.nl>
Message-ID: <0efefffe-90c8-979e-3a26-ea01a4a4519a@geomatys.com>

Le 19/01/2017 ? 03:31, Sebastiaan Couwenberg a ?crit :

> I've tried to have a discussion with OGC about the issues with their
> licensing of standards and their implementation in Free Software
> projects several times in the past, all I every got was a reply that
> they would discuss it internally and never heard from them again.
>
Could the "API white paper" (link in my previous email) be seen as a
publication of their current state of though? Their discussions have
been reported in the Open Architecture Board (OAB) sessions in many
recent OGC meetings. The GitHub repository of the API white paper is
public - we can submit merge requests.


> This lead me to give up on ever making progress on this issue, the
> core of geospatial software is simply non-free and the organisations
> involved have not shown willingness to work with the community to
> resolve that.
>
OGC has signed a "memorandum of understanding" with OSGeo [1], giving
OGC membership for free (in my understanding) to a few OSGeo members at
some conditions documented on OSGeo wiki. There is also an agreement
between OGC and the Eclipse Software Foundation. Similar agreement
between OGC and the Apache Software Foundation has been discussed but
not yet materialized. However OGC is already active at Apache, helping
us to organize a "Geospatial track" in both Apache Conferences of 2016.

The OGC/OSGeo memorandum of understanding cites liaison contacts. My
experience with the geospatial track in Apache Conferences is that the
liaison on OGC side is responsive. Maybe your should contact the
liaisons on OSGeo side?


> While I understand the motivations of EPSG, just like I understand
> them of the Dutch Kadaster with whom I've had the same discussion
> after they published their NTv2 correction grids, limiting
> modification is simply incompatible with Free Software licenses.
>
Free software licenses are important, but not necessarily the most
important thing in the world. Some may argue that data integrity is more
important. I do not want to enter in the debate of what is most
important - I just want to said that this issue may require compromise
on both sides, and open source licenses have proved a capability to
adapt to other issues in the past (e.g. Apache-GPL compatibility,
patents, etc.).


> The right to make modifications is simply essential to Free Software.
>
The right to make modifications is not unrestricted in Free Software.
Apache has restrictions (we can not keep the "Apache" name), GPL has
restrictions (we must publish our changes), etc.


> As Greg also mentioned, in practice no one wants to make use of this
> right because that would make their implementation incompatible with
> the rest of the world beating the purpose of standards.
>
Some projects do make incompatible changes (e.g. axis order), sometime
in good faith (e.g. following the path of someone else, e.g. WMS
standard before it was fixed) but the result is still incompatibility.
Another example is the old days when Internet Explorer had its own
interpretation of HTML standard.

    Regards,

        Martin

[1]
https://wiki.osgeo.org/wiki/OSGeo_signs_Memorandum_of_Understanding_with_OGC



From howard at hobu.co  Mon Jan 23 09:12:12 2017
From: howard at hobu.co (Howard Butler)
Date: Mon, 23 Jan 2017 08:12:12 -0600
Subject: [Proj] OSGeo Daytona Code Sprint Feb 6-10th
Message-ID: <8B7C6822-0320-4EA4-828A-3D1CEDBCFF5D@hobu.co>

All,

There's still time to come to the OSGeo Daytona Code Sprint [1] and help us with the Proj.4 project. There is a rumor (unsubstantiated, but I hope it to be true) that a previous Proj.4 maintainer will also be in attendance [2]. 

I plan to spend some more time at the sprint on the concept of SQLite-based dictionaries for Proj.4 and work on website refinement. 

Howard

[1] https://wiki.osgeo.org/wiki/Daytona_Beach_Code_Sprint_2017
[2] https://wiki.osgeo.org/wiki/Daytona_Beach_Code_Sprint_2017#Participants