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

[Sandro Santilli]

On Wed, Mar 16, 2022 at 09:20:10AM -0400, Greg Troxel wrote:
> Sandro Santilli <strk at kbt.io> writes:
> 
> > Another solution proposed was to still keep a single table but NEVER
> > automatically upgrade it, providing a function to select "system
> > entries" to use for populating the single table, when needed.
> 
> With that, you don't get fixes to system values on upgrade, and I don't
> see a way to merge them.

You don't get them automatically, but you can refresh to the system
values by DELETEing your entries and INSERTing the ones from the
system function.

In the other solution (the 2 tables) you'd only need to DELETE the
shadowing entries you don't need anymore.

> Overall, if someone wants a different/extra value then it feels like one
> of two cases:
> 
>   there is a bug in the postgis data (and a bug in EPSG), and it should
>   be fixed upstream, and it's workaround until then
> 
>   they are doing something local not appropriate for upstream, because
>   it is a local CRS, or its a wrong thing to counteract some other local
>   problem as a workaround, etc.
> 
> So it would be extra cool if there were a way to say "print out local
> shadowing entries that are not actually different from upstream" so
> there's a nice path to recovering from the local entry after the bug is
> fixed.

In my 2-tables branch I had automatic cleanup of matching entries on
upgrade, so you'd always only have different-from-upstream entries
in the user (shadowing) table. And those shadowing entries would be
reported by postgis_full_version().

--strk;