From laurent.celati at gmail.com Tue Nov 4 04:19:00 2025 From: laurent.celati at gmail.com (celati Laurent) Date: Tue, 4 Nov 2025 13:19:00 +0100 Subject: Fwd: Similarity index for pairs of features with the highest overlap? In-Reply-To: References: Message-ID: Dear all, A few weeks ago, I posted an initial message: https://lists.osgeo.org/pipermail/postgis-users/2025-October/046930.html But after further thought, I'm creating a new one to provide additional inputs/clarification. As a reminder, my goal is to find a method/tool to compare the similarity/dissimilarity between two polygonal vector layers consisting of multiple features. In my use case, this comparison concerns a polygonal layer resulting from photo-interpretation work (modeling of large physiognomic units/habitats). I reattached a screenshot; this layer appears in blue. The other polygonal vector layer is a polygonal vector layer resulting from a segmentation process (using an OTB tool available via QGIS). (It is yellow in the attached screenshot): [image: SS_seg_PI_identifiants.png] In my previous post, I mentioned a possible way for one similarity indicator: "for each photo-interpreted feature/polygon, calculate the percentage (%) of area covered by the feature from the segmentation layer that has the highest overlap." To be more specific, in the example in the screenshot, it could be: "for feature number 11 (blue) from the photo-interpretation layer, I would like to know the proportion of the area covered by the feature from the segmentation layer that has the highest overlap with this feature 11 (in this specific case, it is probably feature 42 in yellow)." This could be: area of feature 42 overlapping with feature 11 / total area of feature 11. But after further thought, I think this is insufficient. That i need to go a little further. Regarding these methods for quantifying the accuracy of a segmentation/fidelity to photo-interpretation. Regarding the level/degree of similarity, I think i should integrate a "bi-similarity" aspect/logic: using an approach based *on pairs* of the most overlapping polygons: *step 1* - For each polygon feature in the input layer, retrieve the ID and geometry of the polygon from the segmentation layer that has the highest overlap. Calculate the overlap rate. (e.g., surface area of feature 42 overlapping with feature 11 / *total surface area of feature 11*). *Step 2:* - Once this first indicator is calculated, perform the calculation for the same pair/sequence of polygons calculated in step 1: perform the same calculation but this time on the total surface area of feature 42 (polygon from the segmentation). (e.g., surface area of feature 42 overlapping with feature 11 /* total surface area of feature 42*). *Step 1/2 variant:* I was thinking that a one-step variant/synthesis/summary of steps 1 and 2 could be: - (e.g., surface area of feature 42 overlapping with feature 11 / *total surface area constituted by feature 11 AND feature 42).*? * Step 3:* The idea would be, based on steps 1/2, to have a kind of overall score at the layer level. This could be a kind of average/median for all pairs of polygons? Or another metric? I imagine that this tool does not exist/is not available in QGIS. Although I discovered this plugin: https://plugins.qgis.org/plugins/similarity_plugin/#plugin-about https://github.com/panickspa/SimilarityPlugin Interesting plugin. But in my humble opinion, it only covers part of my need. To be complete, I did some research on the internet. I also found a potentially interesting indicator: https://postgis.net/docs/ST_HausdorffDistance.html https://en.wikipedia.org/wiki/Hausdorff_distance Is there a possible way, either through QGIS or PostGIS? Thanks so much. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SS_seg_PI_identifiants.png Type: image/png Size: 228559 bytes Desc: not available URL: From lorenzocurcio2 at gmail.com Tue Nov 4 17:03:37 2025 From: lorenzocurcio2 at gmail.com (Lorenzo Curcio) Date: Wed, 5 Nov 2025 02:03:37 +0100 Subject: raster2pgsql ignoring nodata (seemingly) Message-ID: Hi, I have a float32 multiband (6) GTiff raster that I'm trying to upload (tiled, given that it's 110162 x 51992) to a postgis database. The vast vast majority of this raster is empty / nodata (on all 6 bands). (it only has data for rivers and covers all of europe, any part not near a river is nodata). The statistics_valid_percent (for all layers) is barely above 3%. Despite that, whenever I try to run raster2pgsql with -t auto (and _without_ -k) it will always try and produce a 100+gb sql output file, seemingly never actually eliminating any tiles. I have tried everything I can think of, setting and resetting the raster nodata in tons of ways, manually passing it in via -N, it just doesn't change anything, raster2pgsql is always writing these huge output sql files instead of properly culling tiles (the complete lack of verbosity in raster2pgsql is not helping here . . for instance a simple print of what it considers the band nodata to be would answer this question, but if such an option exists it's not documented) Are there any ideas on what could cause this to happen or any further debugging steps? Sorry if this is not the right place to ask - please point me to where the right place would be instead if so. Thanks, Lorenzo -------------- next part -------------- An HTML attachment was scrubbed... URL: From klassen.js at gmail.com Wed Nov 5 05:48:38 2025 From: klassen.js at gmail.com (Jim Klassen) Date: Wed, 5 Nov 2025 07:48:38 -0600 Subject: Fwd: Similarity index for pairs of features with the highest overlap? In-Reply-To: References: Message-ID: <785c972a-f9a2-48f0-bf80-5902d3ab5f3a@gmail.com> The usual approach I've seen in evaluating a remote sensing classification is the confusion matrix [1] I'd either rasterize the polygons at whatever resolution seems appropriate and compute the confusion matrix from the rasters, or split the one polygon layer with the other and take the areas of each resulting polygon and assign them based on if they are in one, the other, both, or neither. [1] https://en.wikipedia.org/wiki/Confusion_matrix On 11/4/25 06:19, celati Laurent wrote: > Dear all, > > A few weeks ago, I posted an initial message: > > https://lists.osgeo.org/pipermail/postgis-users/2025-October/046930.html > > > But after further thought, I'm creating a new one to provide > additional inputs/clarification. > As a reminder, my goal is to find a method/tool to compare the > similarity/dissimilarity between two polygonal vector layers > consisting of multiple features. In my use case, this comparison > concerns a polygonal layer resulting from photo-interpretation work > (modeling of large physiognomic units/habitats). I reattached a > screenshot; this layer appears in blue. > The other polygonal vector layer is a polygonal vector layer resulting > from a segmentation process (using an OTB tool available via QGIS). > (It is yellow in the attached screenshot): > > SS_seg_PI_identifiants.png > > > In my previous post, I mentioned a possible way for one similarity > indicator: "for each photo-interpreted feature/polygon, calculate the > percentage (%) of area covered by the feature from the segmentation > layer that has the highest overlap." > To be more specific, in the example in the screenshot, it could be: > "for feature number 11 (blue) from the photo-interpretation layer, I > would like to know the proportion of the area covered by the feature > from the segmentation layer that has the highest overlap with this > feature 11 (in this specific case, it is probably feature 42 in yellow)." > This could be: area of feature 42 overlapping with feature 11 / total > area of feature 11. > > But after further thought, I think this is insufficient. That i need > to go a little further. > > Regarding these methods for quantifying the accuracy of a > segmentation/fidelity to photo-interpretation. Regarding the > level/degree of similarity, I think i should integrate a > "bi-similarity" aspect/logic: using an approach based *on pairs* of > the most overlapping polygons: > > *step 1* > - For each polygon feature in the input layer, retrieve the ID and > geometry of the polygon from the segmentation layer that has the > highest overlap. Calculate the overlap rate. > (e.g., surface area of feature 42 overlapping with feature 11 / *total > surface area of feature 11*). > * > Step 2:* > - Once this first indicator is calculated, perform the calculation for > the same pair/sequence of polygons calculated in step 1: perform the > same calculation but this time on the total surface area of feature 42 > (polygon from the segmentation). > (e.g., surface area of feature 42 overlapping with feature 11 /*total > surface area of feature 42*). > > *Step 1/2 variant:* > I was thinking that a one-step variant/synthesis/summary of steps 1 > and 2 could be: > - (e.g., surface area of feature 42 overlapping with feature 11 / > *total surface area constituted by feature 11 AND feature 42).*? > > *?Step 3:* > The idea would be, based on steps 1/2, to have a kind of overall score > at the layer level. This could be a kind of average/median for all > pairs of polygons? Or another metric? > > I imagine that this tool does not exist/is not available in QGIS. > Although I discovered this plugin: > https://plugins.qgis.org/plugins/similarity_plugin/#plugin-about > https://github.com/panickspa/SimilarityPlugin > > Interesting plugin. But in my humble opinion, it only covers part of > my need. > To be complete, I did some research on the internet. I also found a > potentially interesting indicator: > https://postgis.net/docs/ST_HausdorffDistance.html > https://en.wikipedia.org/wiki/Hausdorff_distance > > Is there a possible way, either through QGIS or PostGIS? > Thanks so much. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SS_seg_PI_identifiants.png Type: image/png Size: 228559 bytes Desc: not available URL: From Antonio.SilesAguilar at ext.esa.int Thu Nov 6 07:17:16 2025 From: Antonio.SilesAguilar at ext.esa.int (Antonio Siles Aguilar) Date: Thu, 6 Nov 2025 15:17:16 +0000 Subject: Question about pgSphere Message-ID: Hi! This is Antonio, software engineer working for the ESA, European Space Agency. We are currently dealing with an analysis of replacing pgSphere with PostGIS and I have a question about PostGIS please: We can read on https://postgis.net/documentation/getting_started/install_windows/enabling_postgis/ [image.png] ?PgSphere is not yet packaged with the PostGIS bundle, but will be in the future?. Could you tell me if there is a schedule or estimated date/version for that, please? Thank you very much for your support in advance. Kind regards, Antonio. ------------------------------------------------------------ SCO08 - Archives and SPACE Software development and operations Service Delivered by Starion Group for the European Space Agency Antonio Manuel Siles Aguilar Starion Espa?a SLU SCI-S ESAC antonio.silesaguilar at ext.esa.int This message is intended only for the recipient(s) named above. It may contain proprietary information and/or protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int). -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 60284 bytes Desc: image.png URL: From lr at pcorp.us Thu Nov 6 08:22:30 2025 From: lr at pcorp.us (Regina Obe) Date: Thu, 6 Nov 2025 11:22:30 -0500 Subject: Question about pgSphere In-Reply-To: References: Message-ID: <001801dc4f39$8cea7ca0$a6bf75e0$@pcorp.us> Antonio, I?ll start packaging it with upcoming PostGIS 3.6.1 Windows Bundle. We are working on closing a few issues in PostGIS before we release 3.6.1 and I?m also waiting for release of pgRouting 4.0 which is planned for next week. But I?m thinking probably within the next 2 weeks we?ll release 3.6.1 and then the windows bundle will follow probably a week after. So somewhere between 2-3 weeks before you?ll see it as part of the PostGIS windows bundle. From: Antonio Siles Aguilar Sent: Thursday, November 6, 2025 10:17 AM To: postgis-users at lists.osgeo.org Subject: Question about pgSphere Hi! This is Antonio, software engineer working for the ESA, European Space Agency. We are currently dealing with an analysis of replacing pgSphere with PostGIS and I have a question about PostGIS please: We can read on https://postgis.net/documentation/getting_started/install_windows/enabling_p ostgis/ ?PgSphere is not yet packaged with the PostGIS bundle, but will be in the future?. Could you tell me if there is a schedule or estimated date/version for that, please? Thank you very much for your support in advance. Kind regards, Antonio. ------------------------------------------------------------ SCO08 - Archives and SPACE Software development and operations Service Delivered by Starion Group for the European Space Agency Antonio Manuel Siles Aguilar Starion Espa?a SLU SCI-S ESAC antonio.silesaguilar at ext.esa.int This message is intended only for the recipient(s) named above. It may contain proprietary information and/or protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int ). -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 60284 bytes Desc: not available URL: From pramsey at cleverelephant.ca Mon Nov 10 11:43:46 2025 From: pramsey at cleverelephant.ca (Paul Ramsey) Date: Mon, 10 Nov 2025 11:43:46 -0800 Subject: PostGIS Day 2025 Message-ID: PostGIS Day is coming! Your favourite online event, running on the day after GIS Day, on November 20, 2025, starting at 13:00 (UTC) | 8:00 AM (ET) | 5:00 AM (PT), and going for 11 amazing hours after that! Make sure you're signed up early, webinar slots are finite and going fast! https://www.snowflake.com/postgis-day-2025/ Check out this line up of speakers and topics: 2025 is going to be a great PostGIS Day! See you online! P. Title Name Exposing PostGIS data with OGC standards Krishna Lodha Processing the World with H3 and PostGIS Darafei Praliaskouski PostGIS, the Spatial Engine of IGN for Two Decades Cedric DUPREZ Working with Geospatial Embeddings with PostGIS and PGVector Shoaib Burq PostGIS Topology: Strengths and Weaknesses Lars Aksel Opsahl Snowflake and PostGIS Together! Fawad Qureshi Innovate with PostGIS: If you do what other people do, you get what other people get bonny p mcclain Hexagonal Thinking: Managing Climate Datasets in PostGIS Alper Dincer Optimizing Sales Distribution and Routing with PostGIS: A Case Study from Kenya?s GSM Network Adam Kipkemei PostGIS in the Age of AI: Teaching Claude to Think Spatially Jaime Sanchez & Mamata Akella Your Dorky Spatial Database is My Magic Answer Machine Brian Timoney The Power of PostGIS & Apache Sedona Matt Forrest Getting OpenStreetMap data in PostGIS with osm2pgsql Jochen Topf Service-Oriented Isochrone Mapping with PostGIS and PGRouting Samuel Mather PostGIS: Spatial, special, and something else Regina Obe How State Farm uses PostGIS Michael Keller QGIS Cartography Tips & Tricks Michele Tobias Building Agentic experiences with PostGIS and CARTO in Snowflake Ryan Miller pg_lake: an Open Source Postgres Extension for Geospatial Object Storage Elizabeth Christensen Linear referencing using PostGIS Bruce Rindahl AI Agents for Querying PostGIS Brendan Ashworth What's "New" in PostGIS Paul Ramsey -------------- next part -------------- An HTML attachment was scrubbed... URL: From pramsey at cleverelephant.ca Thu Nov 13 20:11:58 2025 From: pramsey at cleverelephant.ca (Paul Ramsey) Date: Thu, 13 Nov 2025 20:11:58 -0800 Subject: PostGIS 3.6.1 Released Message-ID: The PostGIS development team is pleased to publish the 3.6.1 patch release. https://postgis.net/2025/11/PostGIS-3.6.1/ - #5978, geometry_columns needs to still parse table constraints (Paul Ramsey) - #5987, ST_GeometryN fails for non-collections (Paul Ramsey) - #5991, CircularString distance error (Paul Ramsey) - #5994, Null pointer in ST_AsGeoJsonRow (Alexander Kukushkin) - #5998, ST_Distance error on CurvePolygon (Paul Ramsey) - #5962, Consistent clipping of MULTI/POINT (Paul Ramsey) - #5998, [tiger_geocoder] [security] CVE-2022-2625, make sure tables requires by extension are owned by extension authored: Andrey Borodin (Yandex), reported by Sergey Bobrov (Kaspersky) - #5754, ST_ForcePolygonCCW reverses lines (Paul Ramsey) - #5959, #5984, Prevent histogram target overflow when analysing massive tables (Darafei Praliaskouski) - #6012, Remove memory leak from lwcircstring_from_lwpointarray (Paul Ramsey) - #6013, [tiger_geocoder] Load Tiger 2025 data (Regina Obe) - #5983, [topology] topology.FixCorruptTopoGeometryColumn to fix corruption caused by 3.6.0 upgrade (Regina Obe, Francois Bonzon) If you are If you are upgrading postgis_topology and have topogeometry columns, make sure to run after the upgrade to fix topogeometry corruption: SELECT topology.FixCorruptTopoGeometryColumn(schema_name, table_name, feature_column) FROM topology.layer; -------------- next part -------------- An HTML attachment was scrubbed... URL: From pramsey at cleverelephant.ca Tue Nov 18 09:02:06 2025 From: pramsey at cleverelephant.ca (Paul Ramsey) Date: Tue, 18 Nov 2025 09:02:06 -0800 Subject: PostGIS Day on Thursday (Nov 20) Message-ID: Last reminder, if you haven't already, sign up to attend the virtual worldwide global universal PostGIS day, this Thursday! https://www.snowflake.com/postgis-day-2025/ 22 talks, one great conference, and the best hallway chat on the internet. See you there! P -------------- next part -------------- An HTML attachment was scrubbed... URL: From bo.victor.thomsen at gmail.com Wed Nov 19 09:21:36 2025 From: bo.victor.thomsen at gmail.com (Bo Victor Thomsen) Date: Wed, 19 Nov 2025 18:21:36 +0100 Subject: Issue with st_estimatedextent function ?? Message-ID: Hi list - I'm using Postgres/Postgis as a data repository for QGIS - and it normally just works.. However I'm getting errors with tables having long names, for example: /* fdc_results.bygningskade_stormflod_rcp85_2100_t100_ssp3_7_0_20251119164 */ (Schema-name length: 11, table-name length: 59) I have tracked the issue using the log facility in QGIS. It shows, that QGIS intermittently executes a SQL command: /*SELECT st_estimatedextent('fdc_results','bygningskade_stormflod_rcp85_2100_t100_ssp3_7_0_20251119164','geom')*/ which results in an error: *ERROR: invalid name syntax* If I change the table name to: /*fdc_results.bygningskade_stormflod_rcp85_2100_t100_ssp3_7_0 */(Schema-name length: 11, table-name length: 47) the error disappears. I've done some testing and could replicate the error (and non-error) situation in PGAdmin Further testing shows that if the sum of the character lengths of the schema- and table-name is larger than 58 the function will stop with an error. Otherwise it returns a result like: "BOX(716701.25 6167151,720533.9375 6174220)" It's my understanding, that the maximum length of a tablename in PostgreSQL is 63. This same limit applies for every type of identifier in Postgres. Am I wrong to assume this? Or is there an issue with name lengths in the /**/PostGIS?st_estimatedextent/**/?function?? (It might be a coincidence but if you express the tablename like this : /*"*//*fdc_results"."bygningskade_stormflod_rcp85_2100_t100_ssp3_7_0*//*", */the total length is 63) PostgreSQL version: "PostgreSQL 17.4 on x86_64-windows, compiled by msvc-19.42.34436, 64-bit" PostGIS version: "3.5 USE_GEOS=1 USE_PROJ=1 USE_STATS=1" -- Med venlig hilsen / Best regards Bo Victor Thomsen -------------- next part -------------- An HTML attachment was scrubbed... URL: From pramsey at cleverelephant.ca Wed Nov 19 10:36:00 2025 From: pramsey at cleverelephant.ca (Paul Ramsey) Date: Wed, 19 Nov 2025 10:36:00 -0800 Subject: Issue with st_estimatedextent function ?? In-Reply-To: References: Message-ID: I cannot replicate this bug on my PostGIS 3.5.5dev environment, probably because the issue is already fixed as of 3.5.3 https://github.com/postgis/postgis/blob/stable-3.5/NEWS#L66 https://trac.osgeo.org/postgis/ticket/5819 I think you probably need a maintenance upgrade. ATB, P On Wed, Nov 19, 2025 at 9:21?AM Bo Victor Thomsen < bo.victor.thomsen at gmail.com> wrote: > Hi list - > > I'm using Postgres/Postgis as a data repository for QGIS - and it normally > just works.. However I'm getting errors with tables having long names, for > example: > > > * fdc_results.bygningskade_stormflod_rcp85_2100_t100_ssp3_7_0_20251119164 > * > (Schema-name length: 11, table-name length: 59) > > I have tracked the issue using the log facility in QGIS. It shows, that > QGIS intermittently executes a SQL command: > > *SELECT > st_estimatedextent('fdc_results','bygningskade_stormflod_rcp85_2100_t100_ssp3_7_0_20251119164','geom')* > > which results in an error: *ERROR: invalid name syntax* > > If I change the table name to: > > *fdc_results.bygningskade_stormflod_rcp85_2100_t100_ssp3_7_0 *(Schema-name > length: 11, table-name length: 47) > > the error disappears. > > I've done some testing and could replicate the error (and non-error) > situation in PGAdmin > > Further testing shows that if the sum of the character lengths of the > schema- and table-name is larger than 58 the function will stop with an > error. Otherwise it returns a result like: > > "BOX(716701.25 6167151,720533.9375 6174220)" > > It's my understanding, that the maximum length of a tablename in > PostgreSQL is 63. This same limit applies for every type of identifier in > Postgres. Am I wrong to assume this? Or is there an issue with name lengths > in the PostGIS st_estimatedextent function?? > > (It might be a coincidence but if you express the tablename like this : > *"**fdc_results"."bygningskade_stormflod_rcp85_2100_t100_ssp3_7_0**", *the > total length is 63) > > PostgreSQL version: "PostgreSQL 17.4 on x86_64-windows, compiled by > msvc-19.42.34436, 64-bit" > > PostGIS version: "3.5 USE_GEOS=1 USE_PROJ=1 USE_STATS=1" > > -- > Med venlig hilsen / Best regards > > Bo Victor Thomsen > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lr at pcorp.us Wed Nov 19 11:43:56 2025 From: lr at pcorp.us (Regina Obe) Date: Wed, 19 Nov 2025 14:43:56 -0500 Subject: Issue with st_estimatedextent function ?? In-Reply-To: References: Message-ID: <000701dc598c$d823f180$886bd480$@pcorp.us> Bo, FWIW I?m in the middle of packaging windows PostGIS 3.6.1 Bundle package ofr PG13-18. I should have that done this week. I?ll send an update to the mailing list once I have that ready. I confirm that in PostGIS 3.6.1 I can?t replicate this error, but I can in POSTGIS="3.5.2 3.5.2" [EXTENSION] PGSQL="150" GEOS="3.13.0-CAPI-1.19.0" PROJ="8.2.1 ..? From: Paul Ramsey via postgis-users Sent: Wednesday, November 19, 2025 1:36 PM To: Bo Victor Thomsen Cc: postgis-users at lists.osgeo.org Subject: Re: Issue with st_estimatedextent function ?? I cannot replicate this bug on my PostGIS 3.5.5dev environment, probably because the issue is already fixed as of 3.5.3 https://github.com/postgis/postgis/blob/stable-3.5/NEWS#L66 https://trac.osgeo.org/postgis/ticket/5819 I think you probably need a maintenance upgrade. ATB, P On Wed, Nov 19, 2025 at 9:21?AM Bo Victor Thomsen > wrote: Hi list - I'm using Postgres/Postgis as a data repository for QGIS - and it normally just works.. However I'm getting errors with tables having long names, for example: fdc_results.bygningskade_stormflod_rcp85_2100_t100_ssp3_7_0_20251119164 (Schema-name length: 11, table-name length: 59) I have tracked the issue using the log facility in QGIS. It shows, that QGIS intermittently executes a SQL command: SELECT st_estimatedextent('fdc_results','bygningskade_stormflod_rcp85_2100_t100_ssp3_7_0_20251119164','geom') which results in an error: ERROR: invalid name syntax If I change the table name to: fdc_results.bygningskade_stormflod_rcp85_2100_t100_ssp3_7_0 (Schema-name length: 11, table-name length: 47) the error disappears. I've done some testing and could replicate the error (and non-error) situation in PGAdmin Further testing shows that if the sum of the character lengths of the schema- and table-name is larger than 58 the function will stop with an error. Otherwise it returns a result like: "BOX(716701.25 6167151,720533.9375 6174220)" It's my understanding, that the maximum length of a tablename in PostgreSQL is 63. This same limit applies for every type of identifier in Postgres. Am I wrong to assume this? Or is there an issue with name lengths in the PostGIS st_estimatedextent function?? (It might be a coincidence but if you express the tablename like this : "fdc_results"."bygningskade_stormflod_rcp85_2100_t100_ssp3_7_0", the total length is 63) PostgreSQL version: "PostgreSQL 17.4 on x86_64-windows, compiled by msvc-19.42.34436, 64-bit" PostGIS version: "3.5 USE_GEOS=1 USE_PROJ=1 USE_STATS=1" -- Med venlig hilsen / Best regards Bo Victor Thomsen -------------- next part -------------- An HTML attachment was scrubbed... URL: From bo.victor.thomsen at gmail.com Wed Nov 19 11:44:17 2025 From: bo.victor.thomsen at gmail.com (Bo Victor Thomsen) Date: Wed, 19 Nov 2025 20:44:17 +0100 Subject: Issue with st_estimatedextent function ?? In-Reply-To: References: Message-ID: Hi Paul - And thank /you/ for the very quick answer ! I followed you advice and upgraded to PostGIS 3.5.3. And lo and behold: It worked !! (And I'm sorry for /not/ looking in PostGIS bug-tracker before blasting out unnecessary mails to the list - and wasting your time) . Med venlig hilsen / Best regards Bo Victor Thomsen On 19/11/2025 19.36, Paul Ramsey wrote: > I cannot replicate this bug on my PostGIS 3.5.5dev environment, > probably because the issue is already fixed as of 3.5.3 > > https://github.com/postgis/postgis/blob/stable-3.5/NEWS#L66 > https://trac.osgeo.org/postgis/ticket/5819 > > I think you probably need a maintenance upgrade. > > ATB, > P > > On Wed, Nov 19, 2025 at 9:21?AM Bo Victor Thomsen > wrote: > > Hi list - > > I'm using Postgres/Postgis as a data repository for QGIS - and it > normally just works.. However I'm getting errors with tables > having long names, for example: > /* > fdc_results.bygningskade_stormflod_rcp85_2100_t100_ssp3_7_0_20251119164 > > */ > (Schema-name length: 11, table-name length: 59) > > I have tracked the issue using the log facility in QGIS. It shows, > that QGIS intermittently executes a SQL command: > > /*SELECT > st_estimatedextent('fdc_results','bygningskade_stormflod_rcp85_2100_t100_ssp3_7_0_20251119164','geom')*/ > > which results in an error: *ERROR: invalid name syntax* > > If I change the table name to: > > /*fdc_results.bygningskade_stormflod_rcp85_2100_t100_ssp3_7_0 > */(Schema-name length: 11, table-name length: 47) > > the error disappears. > > I've done some testing and could replicate the error (and > non-error) situation in PGAdmin > > Further testing shows that if the sum of the character lengths of > the schema- and table-name is larger than 58 the function will > stop with an error. Otherwise it returns a result like: > > "BOX(716701.25 6167151,720533.9375 6174220)" > > It's my understanding, that the maximum length of a tablename in > PostgreSQL is 63. This same limit applies for every type of > identifier in Postgres. Am I wrong to assume this? Or is there an > issue with name lengths in > the?PostGIS?st_estimatedextent/**/?function?? > > (It might be a coincidence but if you express the tablename like > this : > /*"*//*fdc_results"."bygningskade_stormflod_rcp85_2100_t100_ssp3_7_0*//*", > */the total length is 63) > > PostgreSQL version: "PostgreSQL 17.4 on x86_64-windows, compiled > by msvc-19.42.34436, 64-bit" > > PostGIS version: "3.5 USE_GEOS=1 USE_PROJ=1 USE_STATS=1" > > -- > Med venlig hilsen / Best regards > > Bo Victor Thomsen > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmckenna at gatewaygeomatics.com Thu Nov 20 08:35:54 2025 From: jmckenna at gatewaygeomatics.com (Jeff McKenna) Date: Thu, 20 Nov 2025 12:35:54 -0400 Subject: Happy PostGIS Day to all Message-ID: <8c4d22c2-d301-4407-9bd1-b9cbd58154bb@gatewaygeomatics.com> https://postgisday.rocks/ to the whole #foss4g community, thanks, -jeff -- Jeff McKenna GatewayGeo: Developers of MS4W, & offering MapServer Consulting/Dev co-founder of FOSS4G http://gatewaygeo.com/ From lr at pcorp.us Sat Nov 22 01:36:57 2025 From: lr at pcorp.us (Regina Obe) Date: Sat, 22 Nov 2025 04:36:57 -0500 Subject: PostGIS Windows Bundle for PostGIS 3.6.1 for PostgreSQL 13-18 Message-ID: <000a01dc5b93$8bea4ae0$a3bee0a0$@pcorp.us> The PostGIS Windows Bundle for PostGIS 3.6.1 is available now on https://download.osgeo.org/postgis/windows/ and PostgreSQL application stackbuilder. It's available for PostgreSQL 13-18. Let me know if you run into any issues. This is the first version that includes pgSphere. Details here: https://postgis.net/documentation/getting_started/install_windows/released_v ersions/ Regards, Regina PostGIS Windows Bundle Maintainer