[postgis-devel] spatial_ref_sys view

[Sandro Santilli]

On Fri, Feb 04, 2022 at 10:07:40AM -0800, Paul Ramsey wrote:
> I've been trying to figure out my objections to this, it worries my greatly but for amorphous reasons. I think, as I noted earlier, I cannot perceive the value of the improvement outweighing the complexity of the extra machinery. Some bullet point thoughts:
> 
> * Most users don't have custom entries, most users live in the space
>   of long-existing EPSG codes. They get nothing out of this.

I sent an email to postgis-users asking about their custom entries, so
hopefully we'll know more about this in a few days.

Reguarding "long-existing EPSG codes": it looks like 74 records
from our spatial_ref_sys table changed some attribute values between
PostGIS-2.3 and PostGIS-2.4. You can see the list of changed srids
here: https://dronie.osgeo.org/postgis/postgis/2798/1/3

All those SRIDs have auth_name = EPSG.

As a result, people who upgraded from 2.3 are going to have old
values and people started fresh are goign to have the new values,
for the *same* SRIDs.

Out of "this", they'd get the updated codes (or the option to retain
the old codes).

> * Those users who do have custom entries, have largely figured out how
>   to exist in the current regime. They use ranges that are out of the way
>   of the system entries. Maybe they follow our documented recommendations
>   (we have those, right?)

The current documentation doesn't really say anything about ranges:
https://postgis.net/docs/manual-dev/using_postgis_dbmanagement.html#user-spatial-ref-sys
An old proposal of mine (2012) was never effectively adopted to become
official documentation:
https://lists.osgeo.org/pipermail/postgis-devel/2012-February/018440.html

I would add that my proposed solution would still work for people
following the current documentation (the INSERT to spatial_ref_sys
will result in the entry being added to the spatial_ref_sys_user).

> * Updates to EPSG definitions with new better measurements, etc, for
>   existing SRS definitions will happen magically now anyways, since the
>   AUTH_NAME/AUTH_SRID pair is what's used to map from an SRID to an actual
>   projection transformation. Update your proj: get the new state-of-the-art
>   for all existing systems.

As you mentioned in an earlier thread, this would be opaque to
user, because the proj4string and srtext could then be completely
out-of-sync with the proj db. If we really want to go there so
I'm with Raul about dropping the table as a whole, maybe replacing
it with a view (for OGC compliancy) returning the data as queried
from the proj.db by a C function (I'm assuming this is possible).

> So we're really down to just folks who absolutely need net-new EPSG
> definitions, but ... cannot figure out to load spatial_ref_sys.sql?

Or cannot figure out to upgrade proj, if loading sptial_ref_sys.sql
would be useless ?

> More docs / better docs feels like a reasonable approach to this.

This is very true.

> Basically, if you're sophisticated enough to use custom SRS definitions,
> you're sophisticated enough to read whatever best practices we want to
> provide to make sure those definitions easily survive an upgrade.

Right, so how would such best practice look like ?

What would you recommend to a user who has the need to define custom
CRSs while still willing to possibly use standard codes ?

--strk;