[postgis-devel] Turning spatial_ref_sys into a view to separate system vs. user entries

Paul Ramsey pramsey at cleverelephant.ca
Wed Feb 2 09:55:33 PST 2022



> On Feb 2, 2022, at 9:22 AM, Raúl Marín <raul at rmr.ninja> wrote:
> 
> On 2022-02-02 17:19, Sandro Santilli wrote:
>> Are you basically saying we should just NEVER need "system"
>> spatial_ref_sys entries but ONLY custom and overridden ones?
> 
> Yes, IMO system spatial_ref_sys shoudn't exist and it should be "provided" by PROJ, and thus immutable from the Postgis side. Then spatial_ref_sys would only contain the custom SRSs added by the user. Obviously this is a large change with a lot of friction, which is why I'm not expecting anybody to do that.

This is kind of the "one true path" to a non-database spatial ref sys. It provides an immutable source of projection info (yay for st_transform indexes) and fully up-to-date info. Unfortunately the definitions would then become quite opaque to the user. 

WRT the spatial_ref_sys_usr/postgis tables, the need for SRID to remain a unique key and also the auth_srid/auth_name pairing to remain unique have to be there.

I also consider this a relatively low-value improvement (is our current set-up really a major pain point to a lot of users?) with a relatively high-risk profile (this table sits at the center of a lot of machinery both in the code base and in peoples applications). I'm fairly loath to say "go for it".

P


> 
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel



More information about the postgis-devel mailing list