From: Regina Obe Date: Wed, 9 Sep 2026 10:42:00 -0400 Subject: longer EPSG WKT2 In-Reply-To: References: Message-ID: <009201dd4069$5fe686f0$1fb394d0$@pcorp.us> > EPSG now has an ensemble for ETRS89 and those have many members, e.g. > > https://epsg.org/crs/wkt/id/25830 > > which are well beyond the 2048 size in the table definition. > > I therefore wonder: > > What version of the EPSG database does postgis come with (seems hard > to find in NEWS?)? > > What is the relationship between the postgis EPSG version and the proj > EPSG version? > > Should the table fields become larger? Perhaps 16384? > > and > > If postgis depends on proj, why isn't it just using the EPSG database > from proj? > > > (This issue was raised by Javier on the proj list.) It is mostly just using the proj.db. Anything beyond storage of srid and auth_srid is considered legacy use in PostGIS. PostGIS always checks proj.db for core definitions if the auth_srid exists in the proj.db. The srtext / proj4text is only used of the definitions don't exist in proj.db. We've had this debate for a while if PostGIS should just come with an essentially empty spatial_ref_sys and as part of user responsibility load what they need to load from proj.db and even making spatial_ref_sys a view that just wraps a function that reads from proj.db. That would largely solve the issue with have with pg_upgrade that in some cases tables are loaded before spatial_ref_sys is populated. There was discussion that editing the proj.db is harder to edit than the spatial_ref_sys for users wanting to define their own custom projection, so that was the big boo against getting rid of spatial_ref_sys as a table. Other reason is it would probably kill performance.