spatial_ref_sys maintainance

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

spatial_ref_sys maintainance

Sandro Santilli-2
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 ?

[1] https://trac.osgeo.org/postgis/ticket/3427
[2] https://trac.osgeo.org/postgis/ticket/3443

--strk;

  ()   Free GIS & Flash consultant/developer
  /\   http://strk.keybit.net/services.html
_______________________________________________
postgis-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel
Reply | Threaded
Open this post in threaded view
|

Re: spatial_ref_sys maintainance

Even Rouault-2
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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel
Reply | Threaded
Open this post in threaded view
|

Re: spatial_ref_sys maintainance

Sandro Santilli-2
In reply to this post by Sandro Santilli-2
On Thu, Jan 28, 2016 at 10:20:02AM +0100, Sandro Santilli wrote:

> 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 ?

FYI: I've automated the process with r14619 in 2.2 branch (2.2.2)
and r14620 in trunk (2.3.0).

--strk;
_______________________________________________
postgis-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel
Reply | Threaded
Open this post in threaded view
|

Re: spatial_ref_sys maintainance

Paul Ramsey
In reply to this post by Even Rouault-2
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
<[hidden email]> 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
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/postgis-devel
_______________________________________________
postgis-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel
Reply | Threaded
Open this post in threaded view
|

Re: spatial_ref_sys maintainance

Even Rouault-2
Paul,

Le jeudi 28 janvier 2016 17:18:47, Paul Ramsey a écrit :
> EPSG:2065
> https://lists.osgeo.org/pipermail/postgis-devel/2012-July/021533.html

That one is a tough one. I've requested help from our Czech friends :
https://lists.osgeo.org/pipermail/gdal-dev/2016-January/043586.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.

I think the EPSG database itself is OK. What is probably not OK is the process
that derives the +towgs84. This is a know issue in the libgeotiff script. The
EPSG database offers various datum shifts for a given datum, with different
validity areas. epsg-registry.org shows that the area of validity for
EPSG:3844 is Romania, but the underlying GEOGCS (EPSG:4179) has a broader area
of validity ("Europe - onshore - eastern - S-42(58)" which covers Albania,
Bulgaria, Czech Republic, Germany (former DDR), Hungary, Poland, Romania and
Slovakia.). Poland is likely the largest country in that area, hence the
selected datum shift which is relevant for EPSG:4179, but not for EPSG:3844
built on it.
The manual override might be an interim solution. A better solution would be
to fix the selection logic.

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
postgis-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel