<div dir="auto">Thank you, Paul and Regina, for the prompt response.<div dir="auto"><br></div><div dir="auto">I don't have a specific example at hand right now, but from what I observed, the issue seems to arise when the WKT is in a 'prettified' format where elements are indented with extra spaces for readability. If those extra spaces are removed, the WKT would likely fit within the 2048 limit. However, it would be helpful to have a way to store it as-is, without needing to strip the formatting.</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, May 21, 2025, 4:59 PM Paul Ramsey <<a href="mailto:pramsey@cleverelephant.ca">pramsey@cleverelephant.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
> On May 21, 2025, at 7:43 AM, Regina Obe <<a href="mailto:lr@pcorp.us" target="_blank" rel="noreferrer">lr@pcorp.us</a>> wrote:<br>
> <br>
> 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.<br>
> <br>
<br>
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.<br>
<br>
P</blockquote></div>