[postgis-devel] spatial_ref_sys maintainance

[Paul Ramsey]

EPSG:2065
https://lists.osgeo.org/pipermail/postgis-devel/2012-July/021533.html

EPSG:3844
https://lists.osgeo.org/pipermail/postgis-devel/2012-June/020890.html

This last one looks like it could be an error in the EPSG database
itself, fixable far upstream.

P


On Thu, Jan 28, 2016 at 1:37 AM, Even Rouault
<even.rouault at spatialys.com> wrote:
> Le jeudi 28 janvier 2016 10:20:02, Sandro Santilli a écrit :
>> I've seen spatial_ref_sys was first updated with some automatic
>> export from GDAL and then manually tweaked to add "historical manual
>> diffs" [1].
>>
>> Is the process documented somewhere ? How can we ensure these manual
>> diffs are always retained in the future ?
>>
>> Also, updating that table currently requires manually tweaking
>> the extensions/postgis/sql_bits/mark_editable_objects.sql.in file,
>> which is error prone [2]. Can it be automated to reduce the risk ?
>
> It seems odd that those tweakings are restricted to PostGIS only. They should
> also apply to GDAL, libgeotiff, proj.4 (and depending QGIS etc.) as well to
> avoid inconsistencies.
>
> Given the current chain of generation, they could be dealt as overrides in
> libgeotiff .csv files, which would cause all downstream (GDAL, proj.4 & PostGIS)
> to inherit from them.
>
> From what I can see, the overrides are mainly for SRS with Datum =
> New_Zealand_Geodetic_Datum_1949 (addition of +nadgrids=nzgd2kgrid0005.gsb,
> actually this one could also be dealt in proj.4 itself in the definition of the
> nzgd49 datum ), EPSG:2065 (S-JTSK (Ferro) / Krovak), EPSG 3844 (Pulkovo
> 1942(58) / Stereo70), and the addition of EPSG:900913.
> Some justification of the overrides of EPSG:2066 and EPSG 3844 would be useful.
>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/postgis-devel