srtext 2048 length limit

[Paul Ramsey]

> On May 21, 2025, at 8:07 AM, Regina Obe <lr at pcorp.us> wrote:
> 
>> 
>>> On May 21, 2025, at 7:43 AM, Regina Obe <lr at pcorp.us> wrote:
>>> 
>>> The general advice is if you want to make changes, you should make it in
>> your proj.db database since that is the first source of truth for PostGIS these
>> days.
>>> 
>> 
>> Er, not really. If you want to change an INSTALLED srs, then you kind of have to
>> do it in proj.db, since that’s the first place we check when dereferencing an
>> SRID number. If you want to ADD a new srs, you can add a line to
>> spatial_ref_sys. Frankly, even if you wanted to change an existing srs, the
>> smart thing to do would be to add a new line and a new srid number to
>> spatial_ref_sys, because there’s nothing stopping proj.db from being over-
>> written by software upgrades etc.
>> 
>> P=
> 
> But if you added it to proj.db too with just the new srid you added in spatial_ref_sys wouldn't it read from proj.db?

Yeah, but, why? I don’t tend to think of proj.db as something normal humans mess with, and definitely since it’s bundled with the proj software packages there’s a likelihood of it getting overwritten on upgrade, which makes it a poor place for local customizations.

> The reason I was thinking it's the preferred way is I recall a while back on this list someone wanting to add a custom spatial_ref_sys to PostGIS,
> But they needed it to agree everywhere, e.g. in their QGIS use, the mapserver use etc, so they always aligned their proj.dbs in use to be the same.
> 
> I guess if all you care about is PostGIS, then it doesn't much matter.
> 
> We do read the srtext these days if it is not in proj.db already right and pass it off to proj to decipher?
> 

Correct. 

P