[PATCH] Update spatial_ref_sys.sql to EPSG v9.2

[rouault]

Update already done in master version of GDAL, libgeotiff and proj.4

[rouault]

Full spatial_ref_sys.sql zipped

[rouault]

Patch

[strk]

In 16156:

Update SRS to EPSG 9.2

Patch by Even Rouault
Closes #3944

[strk]

Do we want to backport these Regina, Paul ?

[robe]

I would say back to 2.4. wouldn't bother with further than 2.3 since we've EOL'd 2.2 already. The changes look like mostly new entries and minor updates to 2 or 3 existing.

[pramsey]

The manual fixes from #3427 need to be brought forward. In particular, there's a whole pile specific to New Zealand almost all of them, really.

[rouault]

The manual fixes from #3427 need to be brought forward. In particular, there's a whole pile specific to New Zealand almost all of them, really.

The fix for that should likely be implemented in GDAL importFromEPSG() rather than manual hacking in PostGIS derived file (that way the proj.4 'espg' file which is a derivative of GDAL as PostGIS 'spatial_ref_sys.sql' would also benefit from it). And there are also subtle implications since when having both +towgs84 and +nadgrids, I believe only +nadgrids is taken into account even if the grid is not available (might have changed with all the recent work in proj master, but not sure)

[pramsey]

In 16158:

Manual fixes from PostGIS users (not many left now) to EPSG file
References #3944

[pramsey]

In 16159:

Manual fixes from PostGIS users (not many left now) to EPSG file
References #3944

[pramsey]

You say "manual hacking" with such distaste Regards the NZ changes, we probably only put them in at the request of the NZ people, so presumably they did something for them, at the time. Where would an upstream ticket go, geotiff or gdal?

[rouault]

You say "manual hacking" with such distaste

Yes, because otherwise we have inconsistent conversion rules in the stack, and people will not replicate the same results when using ST_Transform() in PostGIS vs in GDAL, proj commandlines or with QGIS.

Where would an upstream ticket go, geotiff or gdal?

Likely GDAL. We should probably use data/coordinate_operation.csv and data/coordinate_operation_parameter_value.csv to find the appropriate grid. But the subject is non-trivial since proj4 4.x only support DatumA ←→ WGS84 ←—> DatumB conversions, whereas a lot of grids implement DatumA ←→ DatumB conversions. proj 5 will better handle this

[jpalmer]

I did the orginal request on behalf of the NZ people(!): See ​https://trac.osgeo.org/postgis/ticket/631. I submitted the changes to ensure the higher accuracy NZ datum shift grids are used, because the geotiff/EPSG database that provided the SRS data didn't support this.

But the subject is non-trivial since proj4 4.x only support DatumA ←→ WGS84 ←—> DatumB conversions, whereas a lot of grids implement DatumA ←→ DatumB conversions. proj 5 will better handle this

Yes I remember this was exactly the reason why I didn't try to submit the changes upstream to geotiff/EPSG codebase.

proj 5 will better handle this

Yes the option to define multiple pipeline seems the right time to fix this. The people in QGIS could also benefit from this upstream work with the latest datum shift work they are doing: ​https://github.com/qgis/QGIS/pull/5535

[pramsey]

I'm going to close this here and leave upstreaming the NZ work to you, @jpalmer