#1083 closed defect (wontfix)

Update secore's EPSG database

Reported by: dmisev Owned by: dmisev
Priority: major Milestone: 9.1.x
Component: secore Version: development
Keywords: Cc: mdumitru, pbaumann
Complexity: Trivial

Description

The EPSG database in secore is 8.5, and the latest available version is 8.7.5.

Attachments (1)

changes_from_v8.5_to_v8.7.5.txt (54.8 KB) - added by dmisev 20 months ago.

Download all attachments as: .zip

Change History (10)

comment:1 Changed 20 months ago by dmisev

Patch submitted.

comment:2 Changed 20 months ago by pbaumann

good to have it in, although installations anyway will need to update continuously. Surprisingly, I found OGP quite active in releasing new CRSs.

comment:3 Changed 20 months ago by dmisev

I didn't realize this new version is backwards incompatible, so I reverted to 8.5 now.

Most notable changes seem to be that the axis abbreviation Long has changed to Lon now (e.g. in WGS 84), so any queries we have that subset on Long need to be updated to use axis name Lon now..

I'm not sure how should we handle this, any thoughts?

comment:4 Changed 20 months ago by mdumitru

Petascope retrieves the CRS everytime a server is restarted (or in case it is not in cache yet) and takes the axis names from it, so it should work by default. However, it will break any existing application that assumed EPSG:4326 has an axis called "Long". They can change the CRS resolver to a local one that uses the old database I guess and deal with it.

The question is if we are responsible as secore distributors of maintaining backwards compatibility by distributing the old database? I know I wouldn't be happy to update rasdaman (and through it secore) and see that my old requests are not working anymore.

Either way, it seems quite strange that they would change the name of the axis, it will only cause confusion and will bring nothing of value...

comment:5 Changed 20 months ago by dmisev

It's a tricky situation, on one hand we want to have the latest definitions, on the other hand we want to maintain backwards compatibility, of which the epsg-registry doesn't seem to care much.

We had a concept of axis aliases, e.g. x = Long = Lon.. but I don't think this is a good solution, we cannot possibly go through all the changes and make sure we support them without breaking queries.

I guess we'll just have to accept the changes and simply do nothing beyond announcing on mailing lists that definitions have changed and queries need to be updated, perhaps attaching the release notes from the epsg-registry. I'd just wait with updating the db in rasdaman, until opengis.net redirects to our server, so we are sure that we are in sync.

comment:6 Changed 20 months ago by dmisev

Can't figure out how to get a proper list of the changes, this is the best I found: http://www.epsg.org/WhatIsNew

Changed 20 months ago by dmisev

comment:7 Changed 20 months ago by dmisev

Ok I figured out how to extract the change requests, see attachment:changes_from_v8.5_to_v8.7.5.txt

Any volunteers to go through them and see if there are any other backwards incompatible changes affecting us? :-)

comment:8 Changed 20 months ago by pbaumann

AFAICR we had arranged secore for OGC with a single-button function for updating from EPSG - suggest to leave it to the admin to update, and not do it automatically. Hence, an "old" version would suffice, and we would not continuously run into such extra trouble when (obviously) EPSG has no good discipline in major/minor version changes.

comment:9 Changed 20 months ago by dmisev

  • Resolution set to wontfix
  • Status changed from new to closed

Ok so nothing to do on our side regarding the update, we keep distributing v8.5.

Note: See TracTickets for help on using tickets.