From lr at pcorp.us Wed Sep 2 10:10:50 2026 From: lr at pcorp.us (Regina Obe) Date: Wed, 2 Sep 2026 13:10:50 -0400 Subject: PostGIS 3.7.0rc2 coming late this week early next week Message-ID: <001c01dd3afe$01846160$048d2420$@pcorp.us> I'm planning to release PostGIS 3.7.0rc2 probably Sunday or Monday. So far only changes are some additional checks in configure for doc requirements and some cleanup in docs and README.postgis of requirements that Greg had pointed out. Sandro also made some none user-facing issues around our Google fuzz checking. I'm also taking this opportunity to finalize the release notes for 3.7.0. Let me know if anyone has issues with this plan. Thanks, Regina From lr at pcorp.us Tue Sep 8 14:38:40 2026 From: lr at pcorp.us (Regina Obe) Date: Tue, 8 Sep 2026 17:38:40 -0400 Subject: PostGIS 3.7.0rc2 released Message-ID: <001001dd3fda$6a50e610$3ef2b230$@pcorp.us> The PostGIS Team is pleased to release PostGIS 3.7.0rc2! Best Served with PostgreSQL 19 Beta 3 , GEOS 3.15.0 , This version requires PostgreSQL 14 - 19beta3, GEOS 3.10 or higher, and Proj 6.1+. To take advantage of all features, GEOS 3.15+ is needed. To take advantage of all SFCGAL features SFCGAL 2.3.0+ is needed. This release contains fixes since 3.7.0rc1 release. Details at: https://postgis.net/2026/09/PostGIS-3.7.0rc2/ Source: https://download.osgeo.org/postgis/source/postgis-3.7.0rc2.tar.gz PDF En: https://download.osgeo.org/postgis/docs/postgis-3.7.0rc2-en.pdf HTML: https://download.osgeo.org/postgis/docs/doc-html-3.7.0rc2.tar.gz NOTE: postgis_tiger_geocoder and address_standardizer are no longer part of the PostGIS source code. Latest release of postgis_tiger_geocoder is noted - https://postgis.net/2026/08/PostGIS-Tiger-Geocoder-2025.2/ address_standardizer latest version is https://github.com/postgis/address_standardizer/releases/tag/v3.7.0 , but a 4.0.0 will be released around the same time or shortly after PostGIS 3.7.0. If you run into any issues, feel free to reply to this email or report on our ticket tracker as detailed on https://postgis.net/development/bug_reporting/ Thanks, PostGIS Development Team From j1 at jimenezshaw.com Wed Sep 9 04:09:04 2026 From: j1 at jimenezshaw.com (Javier Jimenez Shaw) Date: Wed, 9 Sep 2026 13:09:04 +0200 Subject: WKT2 in PostGIS Message-ID: Hi In the new PROJ release 9.9.0 that will be released soon, the latest version of EPSG is included. All European realizations are included in the WKT2 of any CRS using the ETRS89 datum ensemble. This is an example of EPSG:25830, with 4264 chars. https://epsg.org/crs/wkt/id/25830 If you format it a bit nicely it goes up to 4874. And this is just an example. I know that this one can be expressed just with the code. However some people (including me) need to define a CRS that is not defined in EPSG. For that we are using WKT2. I realized today that in PostGIS the table containing the CRS has fields limited to 2048 chars, in particular "srtext". https://postgis.net/docs/using_postgis_dbmanagement.html#spatial_ref_sys_table CREATE TABLE spatial_ref_sys ( srid INTEGER NOT NULL PRIMARY KEY, auth_name VARCHAR(256), auth_srid INTEGER, srtext VARCHAR(2048), proj4text VARCHAR(2048) ) If I have to define a CRS with WKT2 because I need some features only available in WKT2, it may not work in PostGIS. Am I right? Thank you. Javier. PS this was first asked in https://lists.osgeo.org/pipermail/proj/2026-September/012183.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From lr at pcorp.us Wed Sep 9 08:39:59 2026 From: lr at pcorp.us (Regina Obe) Date: Wed, 9 Sep 2026 11:39:59 -0400 Subject: PostGIS Day 2026 virtual conference November 19th Message-ID: <00a701dd4071$7977a830$6c66f890$@pcorp.us> PostGIS Day 2026 will be November 19. Call for talk ideas is open now. Registration is free! This is a virtual community conference all about PostGIS geospatial. Details: https://www.snowflake.com/en/postgis-day/ CFP: https://talks.osgeo.org/postgis-day-2026/cfp Hope to see you all there, Regina From lr at pcorp.us Wed Sep 9 08:47:43 2026 From: lr at pcorp.us (Regina Obe) Date: Wed, 9 Sep 2026 11:47:43 -0400 Subject: WKT2 in PostGIS In-Reply-To: References: Message-ID: <00a801dd4072$8e2d0f30$aa872d90$@pcorp.us> Javier, We?ve been hesitant to touch this table to increase it. I know someone else requested this. Our feeling is the proj.db should be the authoritative source for most of these. I there a reason you wouldn?t add this to proj directly? The issue with putting it in postgis spatial_ref_sys is if you use your system beyond postgis You?d have to duplicate the entry anyway. But I am and I think others were concerned for many users especially those who don?t need these defs elsewhere, it?s easier to edit postgis.spatial_ref_sys, PostGIS for since I think 3.0 has delegated most stuff to the proj.db table and just uses spatial_ref_sys auth_srid to look up the record in proj.db and largely ignores what is in srtext/proj4text columns. I have to check the auth_name. I think we used to ignore what was in auth_name and assumed any auth_srid matched up with auth_name = epsg, but that I think changed somewhere across the line. Paul, If per chance you have remember or have the energy to chime in on this, that would be much appreciated. Thanks, Regina From: Javier Jimenez Shaw Sent: Wednesday, September 9, 2026 7:09 AM To: postgis-devel at lists.osgeo.org Subject: WKT2 in PostGIS Hi In the new PROJ release 9.9.0 that will be released soon, the latest version of EPSG is included. All European realizations are included in the WKT2 of any CRS using the ETRS89 datum ensemble. This is an example of EPSG:25830, with 4264 chars. https://epsg.org/crs/wkt/id/25830 If you format it a bit nicely it goes up to 4874. And this is just an example. I know that this one can be expressed just with the code. However some people (including me) need to define a CRS that is not defined in EPSG. For that we are using WKT2. I realized today that in PostGIS the table containing the CRS has fields limited to 2048 chars, in particular "srtext". https://postgis.net/docs/using_postgis_dbmanagement.html#spatial_ref_sys_table CREATE TABLE spatial_ref_sys ( srid INTEGER NOT NULL PRIMARY KEY, auth_name VARCHAR(256), auth_srid INTEGER, srtext VARCHAR(2048), proj4text VARCHAR(2048) ) If I have to define a CRS with WKT2 because I need some features only available in WKT2, it may not work in PostGIS. Am I right? Thank you. Javier. PS this was first asked in https://lists.osgeo.org/pipermail/proj/2026-September/012183.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From pramsey at cleverelephant.ca Wed Sep 9 08:49:15 2026 From: pramsey at cleverelephant.ca (Paul Ramsey) Date: Wed, 9 Sep 2026 08:49:15 -0700 Subject: WKT2 in PostGIS In-Reply-To: <00a801dd4072$8e2d0f30$aa872d90$@pcorp.us> References: <00a801dd4072$8e2d0f30$aa872d90$@pcorp.us> Message-ID: Why wouldn?t we just change those column definitions from varchar(N) to text? > On Sep 9, 2026, at 8:47?AM, Regina Obe wrote: > > Javier, > > We?ve been hesitant to touch this table to increase it. I know someone else requested this. > Our feeling is the proj.db should be the authoritative source for most of these. > > I there a reason you wouldn?t add this to proj directly? The issue with putting it in postgis spatial_ref_sys is if you use your system beyond postgis > You?d have to duplicate the entry anyway. > > But I am and I think others were concerned for many users especially those who don?t need these defs elsewhere, it?s easier to edit postgis.spatial_ref_sys, > > PostGIS for since I think 3.0 has delegated most stuff to the proj.db table and just uses spatial_ref_sys auth_srid to look up the record in proj.db and largely ignores what is in srtext/proj4text columns. > > I have to check the auth_name. I think we used to ignore what was in auth_name and assumed any auth_srid matched up with auth_name = epsg, but that I think changed somewhere across the line. > > Paul, > > If per chance you have remember or have the energy to chime in on this, that would be much appreciated. > > Thanks, > Regina > > From: Javier Jimenez Shaw > Sent: Wednesday, September 9, 2026 7:09 AM > To: postgis-devel at lists.osgeo.org > Subject: WKT2 in PostGIS > > Hi > > In the new PROJ release 9.9.0 that will be released soon, the latest version of EPSG is included. > All European realizations are included in the WKT2 of any CRS using the ETRS89 datum ensemble. > This is an example of EPSG:25830, with 4264 chars. > https://epsg.org/crs/wkt/id/25830 > If you format it a bit nicely it goes up to 4874. And this is just an example. > > I know that this one can be expressed just with the code. However some people (including me) need to define a CRS that is not defined in EPSG. For that we are using WKT2. > > I realized today that in PostGIS the table containing the CRS has fields limited to 2048 chars, in particular "srtext". > https://postgis.net/docs/using_postgis_dbmanagement.html#spatial_ref_sys_table > > CREATE TABLE spatial_ref_sys ( > srid INTEGER NOT NULL PRIMARY KEY, > auth_name VARCHAR(256), > auth_srid INTEGER, > srtext VARCHAR(2048), > proj4text VARCHAR(2048) > ) > > If I have to define a CRS with WKT2 because I need some features only available in WKT2, it may not work in PostGIS. Am I right? > > Thank you. > Javier. > > PS this was first asked in https://lists.osgeo.org/pipermail/proj/2026-September/012183.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From j1 at jimenezshaw.com Wed Sep 9 09:12:01 2026 From: j1 at jimenezshaw.com (Javier Jimenez Shaw) Date: Wed, 9 Sep 2026 18:12:01 +0200 Subject: WKT2 in PostGIS In-Reply-To: References: <00a801dd4072$8e2d0f30$aa872d90$@pcorp.us> Message-ID: Hi Maybe I was not clear on my initial explanation. Let me develop it. Most of the cases a user will use a CRS from the EPSG. There are well know ones like 4326, 32612 or 25830. That is covering many users. Cool. However, not every CRS is in EPSG. There are "infinite" CRSs, just playing with the parameters of the projections. And WKT2 gives even more options. One typical case is a site calibration or site localization, where the CRS is defined particularly for a location, like a construction site. There is a talk in FOSS4G2023 about it with PROJ. In those cases, the EPSG catalog is useless, and the user can define it with WKT2. If I understood correctly, that would be a user defined CRS. There is the potential problem with the size of "srtext". The WKT2 that defines the CRS can have more than 2048 chars. (In understand that PostGIS is supporting WKT2. PROJ does for years) The example of EPSG:25830 was just an example on how can the WKT2 grow. It was already very verbose (compared to WKT1) before the new addition of realizations to ETRS89. As Paul says, probably changing to TEXT is the simplest solution. I don't know the possible consequences. Thank you Javier. On Wed, 9 Sept 2026 at 17:49, Paul Ramsey wrote: > Why wouldn?t we just change those column definitions from varchar(N) to > text? > > On Sep 9, 2026, at 8:47?AM, Regina Obe wrote: > > Javier, > > We?ve been hesitant to touch this table to increase it. I know someone > else requested this. > Our feeling is the proj.db should be the authoritative source for most of > these. > > I there a reason you wouldn?t add this to proj directly? The issue with > putting it in postgis spatial_ref_sys is if you use your system beyond > postgis > You?d have to duplicate the entry anyway. > > But I am and I think others were concerned for many users especially those > who don?t need these defs elsewhere, it?s easier to edit > postgis.spatial_ref_sys, > > PostGIS for since I think 3.0 has delegated most stuff to the proj.db > table and just uses spatial_ref_sys auth_srid to look up the record in > proj.db and largely ignores what is in srtext/proj4text columns. > > I have to check the auth_name. I think we used to ignore what was in > auth_name and assumed any auth_srid matched up with auth_name = epsg, but > that I think changed somewhere across the line. > > Paul, > > If per chance you have remember or have the energy to chime in on this, > that would be much appreciated. > > Thanks, > Regina > > *From:* Javier Jimenez Shaw > *Sent:* Wednesday, September 9, 2026 7:09 AM > *To:* postgis-devel at lists.osgeo.org > *Subject:* WKT2 in PostGIS > > Hi > > In the new PROJ release 9.9.0 that will be released soon, the latest > version of EPSG is included. > All European realizations are included in the WKT2 of any CRS using the > ETRS89 datum ensemble. > This is an example of EPSG:25830, with 4264 chars. > https://epsg.org/crs/wkt/id/25830 > If you format it a bit nicely it goes up to 4874. And this is just an > example. > > I know that this one can be expressed just with the code. However some > people (including me) need to define a CRS that is not defined in EPSG. For > that we are using WKT2. > > I realized today that in PostGIS the table containing the CRS has fields > limited to 2048 chars, in particular "srtext". > > https://postgis.net/docs/using_postgis_dbmanagement.html#spatial_ref_sys_table > > CREATE TABLE spatial_ref_sys ( > srid INTEGER NOT NULL PRIMARY KEY, > auth_name VARCHAR(256), > auth_srid INTEGER, > srtext VARCHAR(2048), > proj4text VARCHAR(2048) > ) > > If I have to define a CRS with WKT2 because I need some features only > available in WKT2, it may not work in PostGIS. Am I right? > > Thank you. > Javier. > > PS this was first asked in > https://lists.osgeo.org/pipermail/proj/2026-September/012183.html > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lr at pcorp.us Wed Sep 9 09:18:22 2026 From: lr at pcorp.us (Regina Obe) Date: Wed, 9 Sep 2026 12:18:22 -0400 Subject: WKT2 in PostGIS In-Reply-To: References: <00a801dd4072$8e2d0f30$aa872d90$@pcorp.us> Message-ID: <00b401dd4076$d6132380$82396a80$@pcorp.us> I thought you or somebody else was against that. My only issue with that is at this point, it?s guaranteed each row falls into an 8kb chunk. Making that text would make it unpredictable and it?s questionable the gain we get from that. This would only be useful for users who define their own custom projections correct and even then given those are few and far between and they probably need it more than for PostGIS, is a postgis really the best place t have this defined? From: Paul Ramsey Sent: Wednesday, September 9, 2026 11:49 AM To: Regina Obe Cc: Javier Jimenez Shaw ; PostGIS Development Discussion Subject: Re: WKT2 in PostGIS Why wouldn?t we just change those column definitions from varchar(N) to text? On Sep 9, 2026, at 8:47?AM, Regina Obe > wrote: Javier, We?ve been hesitant to touch this table to increase it. I know someone else requested this. Our feeling is the proj.db should be the authoritative source for most of these. I there a reason you wouldn?t add this to proj directly? The issue with putting it in postgis spatial_ref_sys is if you use your system beyond postgis You?d have to duplicate the entry anyway. But I am and I think others were concerned for many users especially those who don?t need these defs elsewhere, it?s easier to edit postgis.spatial_ref_sys, PostGIS for since I think 3.0 has delegated most stuff to the proj.db table and just uses spatial_ref_sys auth_srid to look up the record in proj.db and largely ignores what is in srtext/proj4text columns. I have to check the auth_name. I think we used to ignore what was in auth_name and assumed any auth_srid matched up with auth_name = epsg, but that I think changed somewhere across the line. Paul, If per chance you have remember or have the energy to chime in on this, that would be much appreciated. Thanks, Regina From: Javier Jimenez Shaw > Sent: Wednesday, September 9, 2026 7:09 AM To: postgis-devel at lists.osgeo.org Subject: WKT2 in PostGIS Hi In the new PROJ release 9.9.0 that will be released soon, the latest version of EPSG is included. All European realizations are included in the WKT2 of any CRS using the ETRS89 datum ensemble. This is an example of EPSG:25830, with 4264 chars. https://epsg.org/crs/wkt/id/25830 If you format it a bit nicely it goes up to 4874. And this is just an example. I know that this one can be expressed just with the code. However some people (including me) need to define a CRS that is not defined in EPSG. For that we are using WKT2. I realized today that in PostGIS the table containing the CRS has fields limited to 2048 chars, in particular "srtext". https://postgis.net/docs/using_postgis_dbmanagement.html#spatial_ref_sys_table CREATE TABLE spatial_ref_sys ( srid INTEGER NOT NULL PRIMARY KEY, auth_name VARCHAR(256), auth_srid INTEGER, srtext VARCHAR(2048), proj4text VARCHAR(2048) ) If I have to define a CRS with WKT2 because I need some features only available in WKT2, it may not work in PostGIS. Am I right? Thank you. Javier. PS this was first asked in https://lists.osgeo.org/pipermail/proj/2026-September/012183.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From lr at pcorp.us Wed Sep 9 10:01:57 2026 From: lr at pcorp.us (Regina Obe) Date: Wed, 9 Sep 2026 13:01:57 -0400 Subject: WKT2 in PostGIS In-Reply-To: References: Message-ID: <00c701dd407c$ecc04990$c640dcb0$@pcorp.us> My main question is ? is PostGIS really the right place to do that or should it be done in PROJ_AUX_DB as we had discussed here - https://lists.osgeo.org/pipermail/postgis-users/2025-May/046796.html But I?m fine with changing srtext to text. It might create some minor upgrade issues mostly if for some reason someone has decided to create a view against spatial_ref_sys which I suspect few people have. From: Javier Jimenez Shaw Sent: Wednesday, September 9, 2026 7:09 AM To: postgis-devel at lists.osgeo.org Subject: WKT2 in PostGIS Hi In the new PROJ release 9.9.0 that will be released soon, the latest version of EPSG is included. All European realizations are included in the WKT2 of any CRS using the ETRS89 datum ensemble. This is an example of EPSG:25830, with 4264 chars. https://epsg.org/crs/wkt/id/25830 If you format it a bit nicely it goes up to 4874. And this is just an example. I know that this one can be expressed just with the code. However some people (including me) need to define a CRS that is not defined in EPSG. For that we are using WKT2. I realized today that in PostGIS the table containing the CRS has fields limited to 2048 chars, in particular "srtext". https://postgis.net/docs/using_postgis_dbmanagement.html#spatial_ref_sys_table CREATE TABLE spatial_ref_sys ( srid INTEGER NOT NULL PRIMARY KEY, auth_name VARCHAR(256), auth_srid INTEGER, srtext VARCHAR(2048), proj4text VARCHAR(2048) ) If I have to define a CRS with WKT2 because I need some features only available in WKT2, it may not work in PostGIS. Am I right? Thank you. Javier. PS this was first asked in https://lists.osgeo.org/pipermail/proj/2026-September/012183.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From pjduplooy.gis at gmail.com Wed Sep 9 10:06:59 2026 From: pjduplooy.gis at gmail.com (Gandalf the Gray) Date: Wed, 9 Sep 2026 19:06:59 +0200 Subject: Winnie down Message-ID: Hi Regina Winnie is down. Pieter -------------- next part -------------- An HTML attachment was scrubbed... URL: From lr at pcorp.us Wed Sep 9 10:27:27 2026 From: lr at pcorp.us (Regina Obe) Date: Wed, 9 Sep 2026 13:27:27 -0400 Subject: Winnie down In-Reply-To: References: Message-ID: <00d501dd4080$7d15b8b0$77412a10$@pcorp.us> Seems to be an ISP/Router issue cause I can get to it locally but not from an external server. I?ll send a note once I have working again. From: Gandalf the Gray Sent: Wednesday, September 9, 2026 1:07 PM To: postgis-devel at lists.osgeo.org Subject: Winnie down Hi Regina Winnie is down. Pieter -------------- next part -------------- An HTML attachment was scrubbed... URL: From lr at pcorp.us Wed Sep 9 12:27:32 2026 From: lr at pcorp.us (Regina Obe) Date: Wed, 9 Sep 2026 15:27:32 -0400 Subject: Winnie down In-Reply-To: References: Message-ID: <001601dd4091$4375eba0$ca61c2e0$@pcorp.us> It?s back up at the moment. Seems to be an issue with our router though which we are still troubleshooting. From: Gandalf the Gray Sent: Wednesday, September 9, 2026 1:07 PM To: postgis-devel at lists.osgeo.org Subject: Winnie down Hi Regina Winnie is down. Pieter -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruce.rindahl at gmail.com Thu Sep 10 17:19:39 2026 From: bruce.rindahl at gmail.com (Bruce Rindahl) Date: Thu, 10 Sep 2026 18:19:39 -0600 Subject: Drop testing on 32 bit ARM Message-ID: Regina has been testing everything on a 32 bit ARM machine (berrie) for years. Recommend dropping 32 bit builds as I don't think anyone is using postgres/postGIS on 32 bit any more. Linux and Debian are publicly stating 32 bit support will stop soon. -- Bruce Rindahl -------------- next part -------------- An HTML attachment was scrubbed... URL: From lr at pcorp.us Fri Sep 11 05:57:51 2026 From: lr at pcorp.us (Regina Obe) Date: Fri, 11 Sep 2026 08:57:51 -0400 Subject: Drop testing on 32 bit ARM In-Reply-To: References: Message-ID: <000c01dd41ed$282aa180$787fe480$@pcorp.us> I think others have said still testing 32-bit is not worth whatever it finds. So I?m okay with letting go over it. From: Bruce Rindahl Sent: Thursday, September 10, 2026 8:20 PM To: PostGIS Development Discussion Subject: Drop testing on 32 bit ARM Regina has been testing everything on a 32 bit ARM machine (berrie) for years. Recommend dropping 32 bit builds as I don't think anyone is using postgres/postGIS on 32 bit any more. Linux and Debian are publicly stating 32 bit support will stop soon. -- Bruce Rindahl -------------- next part -------------- An HTML attachment was scrubbed... URL: