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

[Greg Troxel]

Sandro Santilli <strk at kbt.io> writes:

> So what you did was modifying what we call a "system entry"
> (srid=3310) to fix a (possible) bug you found in PostGIS itself.
>
> Now I guess you'll want YOUR version of the proj4text value to survive upgrades.
>
> At the moment PostGIS soft upgrades are NOT going to revert your change,
> but someone considers it a bug:
>
>     https://trac.osgeo.org/postgis/ticket/5024
>
> Your experience suggests it is NOT necessarely a bug, so a comment in
> that ticket might be good to have too.
>
> Still, PostGIS *hard* upgrades (implying dump/restore) will instead
> get rid of your updates because srid=3310 is "BETWEEN 3174 AND 3791"
> as found in `extcondition` column of pg_extension for extname='postgis'
> and thus the record will NOT be included in the dump.

The entries that are configured in the sources are part of postgis, and
changing them after install is sort of like editing a file in
$prefix/share.  The right way to do this is to edit the sources and
rebuild.

Of course, one can say that if a user wants to change something for a
reason that isn't a bug, they sould be able to configure

>
> This discrepancy between hard and soft upgrades is what I'd like to
> see fixed with a new simplified method of dealing with upgrades.
>
> The solution I suggested was to keep separate tables for "system entries"
> and "user entries", so that "user entries" would always "shadow"
> "system entries" (allowing overrides) and would always be carried between
> upgrades.

I think this makes sense.  The semantics are that the user wants to have
entries in the table that differ from the project's values, so  a
mechanism aligned to those semantics sounds good.

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

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20220316/786acdbf/attachment.sig>