[postgis-users] Help shaping the future: how do your use of spatial_ref_sys ?

[Sandro Santilli]

On Wed, Feb 09, 2022 at 01:28:13PM +0000, Robert Coup wrote:
> On Fri, 4 Feb 2022 at 17:05, Sandro Santilli <strk at kbt.io> wrote:

> >   - Do you ever update the table with entries from newer
> >     spatial_ref_sys.sql ?
> 
> Yes. We keep postgis' spatial_ref_sys synchronised with the Proj DB version
> we're running as best we can to make life simpler.

Did you implement your custom scripts to do so ?

> If we're moving things:
> 
> 1. is spatial_ref_sys redundant for anything non-custom? Proj has a full
> database now, why does PostGIS need it's own?

I think if we dropped support for older libproj (< 6.1) we could say all
columns but srid,auth_name,auth_srid would be redundant for non-custom records.

> 2. proj4text should disappear altogether too. If people have existing
> proj4text they want to use... `projinfo -o WKT2:2019 '{my-proj4text}'`

Do you think exposing a PostGIS function for doing that would be
useful ?

> 3. Since CUSTOM:4326 and EPSG:4326 clash - the PK is the number; and
> SRID-is-integer is part of SF-SQL (ie: that's not going to change anytime
> soon) could we at least help people put their custom CRS in the right
> place? Is there a defined custom number range we could use to initialise a
> sequence?

PostGIS SRID is not necessarely the auth_srid, so those two are disjoint.
Helping people put their custom CRS in the right place is the goal of
this thread. There's no officially defined custom number range, just a
proposal from 2012 which didn't get much attention:
https://lists.osgeo.org/pipermail/postgis-devel/2012-February/018440.html

The problem with that proposal is that ranges were defined base on the
state of packaged entries AT THAT TIME. My concern is that we cannot
really predict how bigger the "system entries" may get. For instance,
2315 ESRI entries we added at some point (I think after 2012).
I guess 900,913 "shall be enough for anybody" but you never know, right ?

> I think since Proj has gotten a lot smarter since v4, PostGIS should tend
> towards helping people use it (supporting pipelines, using it's
> DB/transform grids/etc) rather than adding additional abstractions over the
> top.

I agree supporting pipelines will be a good addition. We still want to
map a geometry to its CRS though, which is what spatial_ref_sys table
(or view) is about, don't we ?

--strk;