Update to EPSG registry v9

[ndawson]

The EPSG registry v9 is now available (although the page at ​http://www.epsg.org/EPSGDataset/WhatIsNew lists an incorrect release date).

This release includes some critical changes for Australian users.

Note: I'm willing to tackle these changes myself if I can get some pointers from the GDAL maintainers. Is there a script/documented process which was used to handle updates like ​https://github.com/OSGeo/gdal/commit/3a316f2158090ba5123692e21f3dd46ce9279fe2 ?

[Even Rouault]

In 37081:

Update to EPSG v9.0 database + 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) (fixes #4762, #6772)

[Even Rouault]

Corresponding tickets for upstream and downstream projects :

• libgeotiff: ​https://trac.osgeo.org/geotiff/ticket/83
• proj.4: ​https://github.com/OSGeo/proj.4/issues/477
• postgis: ​https://trac.osgeo.org/postgis/ticket/3684

[Even Rouault]

The procedure to update is described in ​https://trac.osgeo.org/geotiff/browser/trunk/libgeotiff/csv/README

[Even Rouault]

In 37083:

Adjust expected result after EPSG upgrade (refs #6772)

[ndawson]

Thanks Even! Are these database upgrades valid for backporting too?

[Even Rouault]

Replying to ndawson:

Thanks Even! Are these database upgrades valid for backporting too?

I don't think we have ever backported EPSG upgrades in stable releases. As there are changes to existing codes, that could easily break downstream software (for example I had to change a expected result in GDAL autotest suite).