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

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

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

jmckenna
Administrator



-------- Forwarded Message --------


           EPSG NEWS: ver 9.0 release


           On 15th December 2016, EPSG Dataset ver 9.0 was released
           (Access and SQL download).


           Version 9.0 replaces version 8.9 of 2016-02-15 and includes
           the revisions made only in the on-line registry in versions
           8.9.2 through v8.9.5. New to version 9.0, 2016-02-15 (Access
           and SQL download): - Changes as documented in Change Records
           through 2016.059, but with actions still remaining on some
           change requests. - New data for Australia, New Zealand, Papua
           New Guinea, Russia, St. Helena, United States, WGS 84 G
           realisations and ITRF. - Significant revision to data for
           United Kingdom. - Minor revision to data for Argentina,
           Australia, Brazil, Bulgaria, Christmas Island, Cote d'Ivoire,
           East Timor, Indonesia, Ireland, New Caledonia, New Zealand,
           Norfolk Island, Papua New Guinea, Solomon Islands, United
           Kingdom and United States. - In the Access database version of
           the Dataset the data declaration for the
           datum.realization_epoch attribute has been changed from
           char(4) to char(10) to allow dates to be given to day resolution.


           Online registry reports have been updated to reflect the full
           resolution stored in the registry, but registry content has
           always had resolution of a day and is unaffected by these
           changes. Data previously released only in versions 8.9.2
           through 8.9.5 in online registry, now included in full v9.0
           release of Access and SQL download: - New data for Australia,
           Bulgaria, France, Germany, India, Italy, Ireland, Ukraine,
           United Kingdom and ITRF2014. - Significant revision to data
           for Albania, Ukraine and ITRF89 to ITRF2000 transformation. -
           Minor revisions to data for. Argentina, Australia, Bhutan,
           Bolivia, Brunei, Chile, Colombia, Costa Rica, Croatia,
           Estonia, Greenland, Iceland, Indonesia, Iraq, Japan, Latvia,
           Libya, Lithuania, Madagascar, Malaysia, Mauritania, Mexico,
           Mozambique, Oman, Panama, Peru, Portugal (Azores), Reunion,
           Serbia, South America (SIRGAS and SIRGAS2000), Spain (Canary
           Islands), Switzerland, Tonga, Uruguay, United Kingdom, United
           States, Venezuela and Zaire. - The length of abbreviations has
           been changed to a nominal maximum of 32 characters.


           Thank you, EPSG


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

Re: Fwd: PSG Dataset ver 9.0 released on 15th December 2016

Greg Troxel-2

Jeff McKenna <[hidden email]> writes:

>            EPSG NEWS: ver 9.0 release
>
>            On 15th December 2016, EPSG Dataset ver 9.0 was released
>            (Access and SQL download).

There is a pkgsrc (portable packaging system) entry for the EPSG
dataset.   I tried to update it to 9.0, but found that I couldn't fetch
the files.  I expected there was perhaps churn in file naming
conventions, 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.

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

 - Are the database files freely redistributable?

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

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

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj

signature.asc (167 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: PSG Dataset ver 9.0 released on 15th December 2016

Martin Desruisseaux-3

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



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

Re: PSG Dataset ver 9.0 released on 15th December 2016

Howard Butler-3

> On Dec 18, 2016, at 11:24 PM, Martin Desruisseaux <[hidden email]> wrote:
>
> 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.

This has been a desire of mine as well. The first step is to get the libraries on a common yet extensible database. I proposed SQLite [1], which is everywhere nowadays. The EPSG db isn't provided in SQLite, but the CRS software constellation has many more dictionaries than just EPSG to worry about.

I'd love to talk about this topic at the Daytona Code Sprint [2]. Come join me to focus on Proj.4 and open source CRS issues. The http://proj4.org website and infrastructure was an outcome of the Paris Code Sprint [3] last year, for example.

Howard

[1] https://lists.osgeo.org/pipermail/metacrs/2015-August/000846.html
[2] https://wiki.osgeo.org/wiki/Daytona_Beach_Code_Sprint_2017#Participants
[3] https://wiki.osgeo.org/wiki/Paris_Code_Sprint_2016
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: EPSG Dataset ver 9.0 released on 15th December 2016

Martin Desruisseaux-3
Le 20/12/2016 à 01:39, Howard Butler a écrit :

> This has been a desire of mine as well. The first step is to get the
> libraries on a common yet extensible database. I proposed SQLite [1],
> which is everywhere nowadays.
>
Indeed, SQLite is also the database behind Geopackage.


> The EPSG db isn't provided in SQLite,
>
The PostgreSQL variant of EPSG SQL scripts is quite standard I think,
except maybe for the "replace" functions at the end of the "data.sql"
file (those last instructions can be skipped with little harm anyway).
We have been able to run them on Derby and HSQL with few changes. I
presume that running them on SQLite would not be too difficult.


> but the CRS software constellation has many more dictionaries than
> just EPSG to worry about.
>
Right, we have seen an interest from some space agencies for planetary
CRS (Mars, Venus, etc.) this year. This raises new issues, for example
some map projection formulas are approximated by series expansions with
a number of terms designed for Earth's eccentricity, which doesn't work
for Jupiter for instance. But this is another story.


> I'd love to talk about this topic at the Daytona Code Sprint [2]. Come
> join me to focus on Proj.4 and open source CRS issues. The
> http://proj4.org website and infrastructure was an outcome of the
> Paris Code Sprint [3] last year, for example.
>
On my side I will be in Asia at the code sprint time. But maybe this
mailing list is a good place to continue discussion as needed? I'm also
considering doing a talk at some FOSS4G event...

    Martin


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

Re: PSG Dataset ver 9.0 released on 15th December 2016

Roger Bivand
In reply to this post by Howard Butler-3
Could I just interject a question about being able to query the version of EPSG in use; because code definitions change between versions, it would be very useful, say in proj, to be able to ask which version of EPSG is present in share/proj. Were more modern solutions considered, reporting the version in use would still remain important.

Thanks for the heads-up!

Roger
Roger Bivand
NHH Norwegian School of Economics, Bergen, Norway
Reply | Threaded
Open this post in threaded view
|

Re: PSG Dataset ver 9.0 released on 15th December 2016

Howard Butler-3

> On Dec 19, 2016, at 2:03 PM, Roger Bivand <[hidden email]> wrote:
>
> Could I just interject a question about being able to query the version of
> EPSG in use; because code definitions change between versions, it would be
> very useful, say in proj, to be able to ask which version of EPSG is present
> in share/proj. Were more modern solutions considered, reporting the version
> in use would still remain important.
>
> Thanks for the heads-up!

Filed. https://github.com/OSGeo/proj.4/issues/471
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: PSG Dataset ver 9.0 released on 15th December 2016

Kristian Evers-2
In reply to this post by Howard Butler-3
+1 on creating a Grand Unified Geodetic Database. That would be a hell of a lot better than what we have now and with the new and improved geodetic capabilities in Proj.4 the timing couldn't be better!

After FOSS4G in Bonn there were some discussion about a similar effort on the OSGeo Disscusion list. It wasn't very focused and I am not sure anything came out of it but at least it underlines that there is an interest in this sort of thing.

It is not very likely for me to attend the code sprint either. I also think that this mailing list is a good place for the initial discussions. If it gets some traction and actual work is done at the code sprint I will do my best to participate remotely.


/Kristian

> -----Oprindelig meddelelse-----
> Fra: [hidden email] [mailto:proj-
> [hidden email]] På vegne af Howard Butler
> Sendt: 19. december 2016 17:40
> Til: PROJ.4 and general Projections Discussions
> Emne: Re: [Proj] PSG Dataset ver 9.0 released on 15th December 2016
>
>
> > On Dec 18, 2016, at 11:24 PM, Martin Desruisseaux
> <[hidden email]> wrote:
> >
> > 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.
>
> This has been a desire of mine as well. The first step is to get the libraries on a
> common yet extensible database. I proposed SQLite [1], which is
> everywhere nowadays. The EPSG db isn't provided in SQLite, but the CRS
> software constellation has many more dictionaries than just EPSG to worry
> about.
>
> I'd love to talk about this topic at the Daytona Code Sprint [2]. Come join me
> to focus on Proj.4 and open source CRS issues. The http://proj4.org website
> and infrastructure was an outcome of the Paris Code Sprint [3] last year, for
> example.
>
> Howard
>
> [1] https://lists.osgeo.org/pipermail/metacrs/2015-August/000846.html
> [2]
> https://wiki.osgeo.org/wiki/Daytona_Beach_Code_Sprint_2017#Participants
> [3] https://wiki.osgeo.org/wiki/Paris_Code_Sprint_2016
> _______________________________________________
> Proj mailing list
> [hidden email]
> http://lists.maptools.org/mailman/listinfo/proj
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: EPSG Dataset ver 9.0 released on 15th December 2016

Martin Desruisseaux-3
Le 20/12/2016 à 18:50, Kristian Evers a écrit :

> +1 on creating a Grand Unified Geodetic Database. That would be a hell
> of a lot better than what we have now
>
I'm not sure what would be the intend of a Grand Unified Geodetic
Database... But I would not recommend creating a new source of CRS
definitions. The EPSG database is quite good in my opinion. The problem
is not EPSG itself, but rather how some software use it. The Proj.4 CSV
files are oversimplification. Giving to Proj.4 a more complete access to
EPSG data, with SQLite as proposed by Howard or with whatever storage
engine achieves the same goal, would be a more effective step I think.

Of course it does not mean to not support other authorities in addition
of EPSG, but I would see that as a secondary goal compared to improving
EPSG support.

    Martin


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

Re: EPSG Dataset ver 9.0 released on 15th December 2016

Kristian Evers-2
Martin,

Don't take that too seriously... It was just my tongue in cheek way of
referring to Howards proposal. The EPSG database is a fantastic
starting point and would for the most part cover everyone's needs.

However, I do think that it is a good idea to think in broader terms
than the EPSG DB when designing a new system.  Something compatible
with the EPSG DB that can also be extended to suit CRS needs not
covered by the EPSG DB.

/Kristian

> -----Oprindelig meddelelse-----
> Fra: [hidden email] [mailto:proj-
> [hidden email]] På vegne af Martin Desruisseaux
> Sendt: 20. december 2016 16:46
> Til: [hidden email]
> Emne: Re: [Proj] EPSG Dataset ver 9.0 released on 15th December 2016
>
> Le 20/12/2016 à 18:50, Kristian Evers a écrit :
>
> > +1 on creating a Grand Unified Geodetic Database. That would be a hell
> > of a lot better than what we have now
> >
> I'm not sure what would be the intend of a Grand Unified Geodetic
> Database... But I would not recommend creating a new source of CRS
> definitions. The EPSG database is quite good in my opinion. The problem
> is not EPSG itself, but rather how some software use it. The Proj.4 CSV
> files are oversimplification. Giving to Proj.4 a more complete access to
> EPSG data, with SQLite as proposed by Howard or with whatever storage
> engine achieves the same goal, would be a more effective step I think.
>
> Of course it does not mean to not support other authorities in addition
> of EPSG, but I would see that as a secondary goal compared to improving
> EPSG support.
>
>     Martin
>
>
> _______________________________________________
> Proj mailing list
> [hidden email]
> http://lists.maptools.org/mailman/listinfo/proj
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: EPSG Dataset ver 9.0 released on 15th December 2016

Howard Butler-3
In reply to this post by Martin Desruisseaux-3

> On Dec 19, 2016, at 11:35 AM, Martin Desruisseaux <[hidden email]> wrote:
>
>> The EPSG db isn't provided in SQLite,
>>
> The PostgreSQL variant of EPSG SQL scripts is quite standard I think,
> except maybe for the "replace" functions at the end of the "data.sql"
> file (those last instructions can be skipped with little harm anyway).
> We have been able to run them on Derby and HSQL with few changes. I
> presume that running them on SQLite would not be too difficult.

You were correct. Except for one simple function name replacement, I was able to easily make a SQLite EPSG db with the PostgreSQL files. See https://github.com/hobu/crs for my working tree.


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj