From anthonymdebarros at gmail.com  Sat Oct  4 11:27:50 2025
From: anthonymdebarros at gmail.com (Anthony DeBarros)
Date: Sat, 4 Oct 2025 11:27:50 -0700
Subject: Installing latest PostGIS on Windows
Message-ID: <CACJO+66JKE74Bkf6JCCgp=mDHycPwJ98yakKHpy6JuXsUVAoCQ@mail.gmail.com>

Hello,

The current EDB Windows download for PostgreSQL 18 does not include PostGIS
in StackBuilder. This typically happens with a new major PG version via
EDB, but I?ve opened a ticket anyway
<https://github.com/EnterpriseDB/edb-installers/issues/415> asking if they
plan to include PostGIS in StackBuilder going forward given that in PG 17
they dropped their Language Pack.

I?m hunting for the best step-by-step directions for downloading the 3.6.0
version of PostGIS and installing it manually on Windows, outside of
StackBuilder. Scanning the PostGIS site and not immediately seeing that.
All help appreciated.

Thanks!

Anthony DeBarros
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20251004/e4eab974/attachment.htm>

From lr at pcorp.us  Sun Oct  5 07:19:01 2025
From: lr at pcorp.us (Regina Obe)
Date: Sun, 5 Oct 2025 10:19:01 -0400
Subject: Installing latest PostGIS on Windows
In-Reply-To: <CACJO+66JKE74Bkf6JCCgp=mDHycPwJ98yakKHpy6JuXsUVAoCQ@mail.gmail.com>
References: <CACJO+66JKE74Bkf6JCCgp=mDHycPwJ98yakKHpy6JuXsUVAoCQ@mail.gmail.com>
Message-ID: <000a01dc3602$ffaaf260$ff00d720$@pcorp.us>

Check now.  It should be there.  Just released early this morning.

Please give it a new try and let me know if you run into any issues.

 

Since it includes pgRouting 4.0.0-alpha and mobilityDb 1.3.0-alpha, I?m planning to hold off on releasing the 13-17 versions until final release of pgRouting 4.0.0 and mobilityDb 1.3.0 are officially out, at which point I?ll rerelease the PostgreSQL 18 bundle.

 

Also we?ll probably be having a PostGIS 3.6.1 soon, so given the timing I might skip releasing PostGIS 3.6.0 13-17 altogether and release PostGIS 36.1. bundle for 13-18 at same time.

 

Thanks for checking,

Regina

 

 

From: Anthony DeBarros <anthonymdebarros at gmail.com> 
Sent: Saturday, October 4, 2025 2:28 PM
To: postgis-users at lists.osgeo.org
Subject: Installing latest PostGIS on Windows

 

Hello,

 

The current EDB Windows download for PostgreSQL 18 does not include PostGIS in StackBuilder. This typically happens with a new major PG version via EDB, but I?ve opened a ticket anyway <https://github.com/EnterpriseDB/edb-installers/issues/415>  asking if they plan to include PostGIS in StackBuilder going forward given that in PG 17 they dropped their Language Pack.

 

I?m hunting for the best step-by-step directions for downloading the 3.6.0 version of PostGIS and installing it manually on Windows, outside of StackBuilder. Scanning the PostGIS site and not immediately seeing that. All help appreciated.

 

Thanks!

 

Anthony DeBarros

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20251005/db8f1816/attachment.htm>

From lr at pcorp.us  Sun Oct  5 07:50:45 2025
From: lr at pcorp.us (Regina Obe)
Date: Sun, 5 Oct 2025 10:50:45 -0400
Subject: PostgreSQL 18 PostGIS 3.6 installer Windows
In-Reply-To: <CADsUavGhUJT7sZVU7e8uaWe4Mk8frE9h1y8nrtB9fX9tKEatNw@mail.gmail.com>
References: <CADsUavGhUJT7sZVU7e8uaWe4Mk8frE9h1y8nrtB9fX9tKEatNw@mail.gmail.com>
Message-ID: <001101dc3607$6eea44b0$4cbece10$@pcorp.us>

Gandalf,

 

Hmm I?ll fix the CURL_CA_BUNDLE.  Guess I missed including that. Probably won?t get to it until mid week.

 

Yap pgSphere I hadn?t had a chance to include since I was in such a rush, but yes I?ll include in next update.

 

Osm2pgrouting ? Let me get back to you on this.  But the plan is yes plan to include it, but I know Vicky was working on logistic changes to it, so it might be newer than the 2.3.8.

 

Cc?d users list in case others are interested, since this was mentioned there too.

 

From: Gandalf the Gray <pjduplooy.gis at gmail.com> 
Sent: Sunday, October 5, 2025 10:34 AM
To: postgis-devel at lists.osgeo.org
Subject: PostgreSQL 18 PostGIS 3.6 installer Windows

 

Hi Regina

 

Thank you for the installer!! I appreciate it!

 

Just a couple of comments.

 

I selected the option to install the CURL_CA_BUNDLE, but it is not in the installer.  Rapid Environment Editor indicates that C:\Program Files\PostgreSQL\18\ssl\certs\ca-bundle.crt does not exist.

 

Are you planning to build osm2pgrouting.  I built it using MSYS but cmake fails complaing about  a lot of nonexistent folders. I followed your instructions on https://github.com/pgRouting/pgrouting/wiki/Building-on-windows-with-msys2-and-mingw64-(WIP)

 

Are you planning pgsphere?

 

Otherwise there are no issues at all.

 

Thanks again.

 

Pieter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20251005/9d5686c5/attachment.htm>

From ewie at ewie.name  Sun Oct  5 17:49:29 2025
From: ewie at ewie.name (Erik Wienhold)
Date: Mon, 6 Oct 2025 02:49:29 +0200
Subject: Dissolve keeping all attributes values
 (concatenation/aggregation)?
In-Reply-To: <CAHByMH3pniw0maOV56mQECe8mriZOzHUgvE1ffT2Wd-fxec1Sw@mail.gmail.com>
References: <CAHByMH2tf=WOC0gyi1PJA1bm4ZXmYqAVCNBJ0YZpxmn-qihxKA@mail.gmail.com>
 <eb026d98-8990-41d2-a517-49b0554523c2@ewie.name>
 <CAHByMH3Wjrrp7mDcXvBmy4yrmFXW3Eq714eZqfbDjTjaWLrEWA@mail.gmail.com>
 <4fb80230-896c-4622-9a5a-19758dbfe699@ewie.name>
 <CAHByMH3pniw0maOV56mQECe8mriZOzHUgvE1ffT2Wd-fxec1Sw@mail.gmail.com>
Message-ID: <18d0325b-275e-4bd9-a5de-25d28bdff96a@ewie.name>

On 2025-09-30 19:11 +0200, celati Laurent wrote:
> The table union_v4 is in public schema.
> When i execute SHOW search_path :
> 
> "$user", public

Are you running your query in the same database?  Is something setting
an empty search path (or at least without "public") before running the
query?  Besides that, I have no clue why you might get that error.

> Le mar. 30 sept. 2025 ? 17:37, Erik Wienhold <ewie at ewie.name> a ?crit :
> 
> > On 2025-09-30 17:29 +0200, celati Laurent wrote:
> > > But when i rerun the query with the edit (adding the closing
> > parenthesis) :
> > >
> > > *SELECT     min(union_v4.max_hierar) as id,     array_agg(union_v4.id)
> > >  as ids,     union_v6.geomFROM union_v4,    (SELECT
> > >       (ST_Dump(St_multi(ST_Union(geom)))).geom as geom    FROM
> > > union_v6)WHERE     st_intersects(union_v4.geom, union_v6.geom)GROUP BY
> > > union_v6.geom*
> > >
> > > *I obtain this time the message : * ERROR: la relation ? union_v4 ?
> > > n'existe pas LINE 5: FROM union_v4, ^ ERREUR: la relation ? union_v4 ?
> > > n'existe pas SQL state: 42P01 Character: 105
> > >
> > > However, i have one table called "union_v4" within my postgis db.
> > > thanks so much.
> >
> > * In which schema is union_v4 defined?
> >
> > * What is your current search_path setting?  Check SHOW search_path;

-- 
Erik Wienhold

From pramsey at cleverelephant.ca  Mon Oct  6 13:14:24 2025
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Mon, 6 Oct 2025 13:14:24 -0700
Subject: PostGIS Day 2025, Nov 20!
Message-ID: <CACowWR2c_QEoceZNDhuEkXATxpoJ745y3GUz0ht5mj9P1O4YGQ@mail.gmail.com>

https://www.snowflake.com/postgis-day-2025/

Hello PostGIS people! November 20 on the day after GIS Day.... is PostGIS
Day! A one-day online conference where PostGIS users share their stories,
tips, tricks, hot finds and terrible realizations!

The call for papers closes soon, to be sure to submit, we want to hear your
story!

If you just want to watch, head to the signup page to make sure your slot
in the webinar is reserved.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20251006/407e7991/attachment.htm>

From mtnclimb at gmail.com  Tue Oct  7 09:29:59 2025
From: mtnclimb at gmail.com (Martin Davis)
Date: Tue, 7 Oct 2025 09:29:59 -0700
Subject: Clarification on ST_CoverageClean Parameters: snappingDistance
 and gapMaximumWidth
In-Reply-To: <CA+SiqDaWbTnR8Z0goN51BVjNw2wRXtCVFuy+CCWFWSEwDgpQNQ@mail.gmail.com>
References: <CA+SiqDaWbTnR8Z0goN51BVjNw2wRXtCVFuy+CCWFWSEwDgpQNQ@mail.gmail.com>
Message-ID: <CAK2ens2cNow=Uxa4f0sHAdJOR62NsVoTKg_xG=Qg-S_h0krrgw@mail.gmail.com>

This appears to be a bug in the PostGIS usage of GEOS.  In GEOS, this case
works correctly.  (E.g. in your first example, the narrow input polygon is
preserved).  We're looking into this now.

The ST_CoverageClean documentation and your understanding are correct:
1. snappingDistance controls vertex snapping, with -1 applying an automatic
distance, and 0.0 disabling snapping.
2. gapMaximumWidth closes gaps smaller than the specified tolerance.

Note that "gaps" are narrow closed areas which occur *between* the input
polygons (after snapping, if any,  has taken place).  Narrow input polygons
are never treated as gaps, but are preserved (as long as they are not
snapped to the point of collapse).

Answers to your questions:

1. How do these two parameters interact?

Snapping is the first phase of the cleaning process.  It operates on
the vertices and edges of the input.  It accomplishes two things: (a)
increasing the robustness of the edge-noding process and (b) removing very
narrow slivers and gores from the input.  Generally the snapping tolerance
should be small relative to the precision of the input, to avoid unwanted
distortion.  It's probably best to simply use the parameter default for
most cases.

Gap merging is done in a subsequent phase, operating on the
snapped polygons.  The gap maximum width value is dataset-dependent, but
generally at least an order of magnitude larger than the snap tolerance.

A more detailed description of the process is here:
https://lin-ear-th-inking.blogspot.com/2025/04/coverage-cleaning-in-jts.html

2. Best practices or recommended workflows for cleaning polygonal coverages
with minimal geometry distortion.

Use the default snapping tolerance, or a very small one.

3. Any known edge cases or limitations when using ST_CoverageClean.

- Gaps are merged as-is, without splitting.  This can result in "spikes"
being created by gaps which have multiple "arms".  There is work being done
on splitting gaps to avoid this problem.
- Similarly, gaps which contain a wide portion (i.e. wider than the max gap
width) and also one or more narrow "arms" will not be merged, due to the
wide portion.  Handling these could be improved via a splitting approach,
hopefully.

4. Whether gapMaximumWidth also triggers geometry simplification or sliver
removal beyond gap closing.

gapMaximumWidth only determines which gaps are merged to adjacent
polygons.  No other simplification is performed.

HTH - Martin



On Tue, Sep 23, 2025 at 6:00?AM Douglas Fan <douglas.mhfan at gmail.com> wrote:

> Dear PostGIS Developers and Users,
>
> First of all, thank you for the development of the new ST_CoverageClean
> function in PostGIS 3.6.0. It?s a fantastic addition that has already
> helped a lot in my work with polygonal coverages. I really appreciate the
> effort that went into making this tool available.
> While testing the function, I?ve encountered some behaviors that I?d like
> to better understand, particularly regarding the snappingDistance and
> gapMaximumWidth parameters.
>
> From the documentation, I understand that:
> 1. snappingDistance controls vertex snapping, with -1 applying an
> automatic distance, and 0.0 disabling snapping.
> 2. gapMaximumWidth closes gaps smaller than the specified tolerance.
>
> However, during testing with various combinations (e.g., snappingDistance
> set to -1, 0.0, 1, 2 and gapMaximumWidth set to 0, 1, 2), I noticed:
> 1. Even when snappingDistance is explicitly set to 0.0, small sliver
> vertices still appear to be snapped or altered when gapMaximumWidth is
> greater than 0.
> 2. Slivers that are thinner than the gapMaximumWidth are removed, even
> when they are not actual gaps or overlaps.
>
> This behavior seems counterintuitive, as I expected no snapping to occur
> with snappingDistance = 0.0. Could this be due to internal gap cleaning
> logic that also affects vertex positions? Or is there an implicit snapping
> step tied to gapMaximumWidth?
>
> I?d be grateful for any insights into:
>
> 1. How do these two parameters interact?
> 2. Best practices or recommended workflows for cleaning polygonal
> coverages with minimal geometry distortion.
> 3. Any known edge cases or limitations when using ST_CoverageClean.
> 4. Whether gapMaximumWidth also triggers geometry simplification or sliver
> removal beyond gap closing.
>
> Thanks in advance for your help and for the continued development of
> PostGIS.
>
> Best regards,
> Man Ho Fan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20251007/f8b1c596/attachment.htm>

From pramsey at cleverelephant.ca  Tue Oct  7 10:48:45 2025
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Tue, 7 Oct 2025 10:48:45 -0700
Subject: Clarification on ST_CoverageClean Parameters: snappingDistance
 and gapMaximumWidth
In-Reply-To: <CA+SiqDaWbTnR8Z0goN51BVjNw2wRXtCVFuy+CCWFWSEwDgpQNQ@mail.gmail.com>
References: <CA+SiqDaWbTnR8Z0goN51BVjNw2wRXtCVFuy+CCWFWSEwDgpQNQ@mail.gmail.com>
Message-ID: <CACowWR0Fdv99oPUE-1EdG81gTk+SxhzoztnH74OtWpcSSaz4eA@mail.gmail.com>

If I told you there is an error in the documentation and that the actual
signature is this, would that allay your concerns?

ST_CoverageClean (geom geometry, gapMaximumWidth float8 default 0.0,
snappingDistance float8 default -1.0, overlapMergeStrategy text default '
MERGE_LONGEST_BORDER')

P.

On Tue, Sep 23, 2025 at 5:25?AM Douglas Fan <douglas.mhfan at gmail.com> wrote:

> Dear PostGIS Developers and Users,
>
> First of all, thank you for the development of the new ST_CoverageClean
> function in PostGIS 3.6.0. It?s a fantastic addition that has already
> helped a lot in my work with polygonal coverages. I really appreciate the
> effort that went into making this tool available.
> While testing the function, I?ve encountered some behaviors that I?d like
> to better understand, particularly regarding the snappingDistance and
> gapMaximumWidth parameters.
>
> From the documentation, I understand that:
> 1. snappingDistance controls vertex snapping, with -1 applying an
> automatic distance, and 0.0 disabling snapping.
> 2. gapMaximumWidth closes gaps smaller than the specified tolerance.
>
> However, during testing with various combinations (e.g., snappingDistance
> set to -1, 0.0, 1, 2 and gapMaximumWidth set to 0, 1, 2), I noticed:
> 1. Even when snappingDistance is explicitly set to 0.0, small sliver
> vertices still appear to be snapped or altered when gapMaximumWidth is
> greater than 0.
> 2. Slivers that are thinner than the gapMaximumWidth are removed, even
> when they are not actual gaps or overlaps.
>
> This behavior seems counterintuitive, as I expected no snapping to occur
> with snappingDistance = 0.0. Could this be due to internal gap cleaning
> logic that also affects vertex positions? Or is there an implicit snapping
> step tied to gapMaximumWidth?
>
> I?d be grateful for any insights into:
>
> 1. How do these two parameters interact?
> 2. Best practices or recommended workflows for cleaning polygonal
> coverages with minimal geometry distortion.
> 3. Any known edge cases or limitations when using ST_CoverageClean.
> 4. Whether gapMaximumWidth also triggers geometry simplification or sliver
> removal beyond gap closing.
>
> Thanks in advance for your help and for the continued development of
> PostGIS.
>
> Best regards,
> Man Ho Fan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20251007/508e03b3/attachment.htm>

From mtnclimb at gmail.com  Tue Oct  7 12:11:58 2025
From: mtnclimb at gmail.com (Martin Davis)
Date: Tue, 7 Oct 2025 12:11:58 -0700
Subject: Clarification on ST_CoverageClean Parameters: snappingDistance
 and gapMaximumWidth
In-Reply-To: <CACowWR0Fdv99oPUE-1EdG81gTk+SxhzoztnH74OtWpcSSaz4eA@mail.gmail.com>
References: <CA+SiqDaWbTnR8Z0goN51BVjNw2wRXtCVFuy+CCWFWSEwDgpQNQ@mail.gmail.com>
 <CACowWR0Fdv99oPUE-1EdG81gTk+SxhzoztnH74OtWpcSSaz4eA@mail.gmail.com>
Message-ID: <CAK2ens0L7rNitcUp7ETv+5HKdP4zDUg-o+OBuuVjK1o8M+VU7g@mail.gmail.com>

And note that the correct signature

geometry ST_CoverageClean(geometry winset geom, float8 gapMaximumWidth = 0,
float8 snappingDistance = -1, text overlapMergeStrategy =
'MERGE_LONGEST_BORDER');

means that the best-practice pattern for using the function is to simply
specify the maximum gap width, leaving the snapping tolerance and overlap
merge strategy as defaulits:

CREATE TABLE  example1_c AS
  SELECT id,  ST_CoverageClean(geom, 1) OVER () AS GEOM
  FROM  example1;


On Tue, Oct 7, 2025 at 10:49?AM Paul Ramsey via postgis-users <
postgis-users at lists.osgeo.org> wrote:

> If I told you there is an error in the documentation and that the actual
> signature is this, would that allay your concerns?
>
> ST_CoverageClean (geom geometry, gapMaximumWidth float8 default 0.0,
> snappingDistance float8 default -1.0, overlapMergeStrategy text default '
> MERGE_LONGEST_BORDER')
>
> P.
>
> On Tue, Sep 23, 2025 at 5:25?AM Douglas Fan <douglas.mhfan at gmail.com>
> wrote:
>
>> Dear PostGIS Developers and Users,
>>
>> First of all, thank you for the development of the new ST_CoverageClean
>> function in PostGIS 3.6.0. It?s a fantastic addition that has already
>> helped a lot in my work with polygonal coverages. I really appreciate the
>> effort that went into making this tool available.
>> While testing the function, I?ve encountered some behaviors that I?d like
>> to better understand, particularly regarding the snappingDistance and
>> gapMaximumWidth parameters.
>>
>> From the documentation, I understand that:
>> 1. snappingDistance controls vertex snapping, with -1 applying an
>> automatic distance, and 0.0 disabling snapping.
>> 2. gapMaximumWidth closes gaps smaller than the specified tolerance.
>>
>> However, during testing with various combinations (e.g., snappingDistance
>> set to -1, 0.0, 1, 2 and gapMaximumWidth set to 0, 1, 2), I noticed:
>> 1. Even when snappingDistance is explicitly set to 0.0, small sliver
>> vertices still appear to be snapped or altered when gapMaximumWidth is
>> greater than 0.
>> 2. Slivers that are thinner than the gapMaximumWidth are removed, even
>> when they are not actual gaps or overlaps.
>>
>> This behavior seems counterintuitive, as I expected no snapping to occur
>> with snappingDistance = 0.0. Could this be due to internal gap cleaning
>> logic that also affects vertex positions? Or is there an implicit snapping
>> step tied to gapMaximumWidth?
>>
>> I?d be grateful for any insights into:
>>
>> 1. How do these two parameters interact?
>> 2. Best practices or recommended workflows for cleaning polygonal
>> coverages with minimal geometry distortion.
>> 3. Any known edge cases or limitations when using ST_CoverageClean.
>> 4. Whether gapMaximumWidth also triggers geometry simplification or
>> sliver removal beyond gap closing.
>>
>> Thanks in advance for your help and for the continued development of
>> PostGIS.
>>
>> Best regards,
>> Man Ho Fan
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20251007/30ed12d5/attachment.htm>

From douglas.mhfan at gmail.com  Wed Oct  8 01:02:14 2025
From: douglas.mhfan at gmail.com (Douglas Fan)
Date: Wed, 8 Oct 2025 10:02:14 +0200
Subject: Clarification on ST_CoverageClean Parameters: snappingDistance
 and gapMaximumWidth
In-Reply-To: <CAK2ens0L7rNitcUp7ETv+5HKdP4zDUg-o+OBuuVjK1o8M+VU7g@mail.gmail.com>
References: <CA+SiqDaWbTnR8Z0goN51BVjNw2wRXtCVFuy+CCWFWSEwDgpQNQ@mail.gmail.com>
 <CACowWR0Fdv99oPUE-1EdG81gTk+SxhzoztnH74OtWpcSSaz4eA@mail.gmail.com>
 <CAK2ens0L7rNitcUp7ETv+5HKdP4zDUg-o+OBuuVjK1o8M+VU7g@mail.gmail.com>
Message-ID: <CA+SiqDbviLDz1MS1Bdg8=DJ5ismRH2CAMNs_v6HTDAcXm69ROA@mail.gmail.com>

Thanks a lot for the explanation?it really clarified things for me. Much
appreciated! ?

Best regards,
Man Ho Fan

On Tue, Oct 7, 2025 at 9:12?PM Martin Davis <mtnclimb at gmail.com> wrote:

> And note that the correct signature
>
> geometry ST_CoverageClean(geometry winset geom, float8 gapMaximumWidth =
> 0, float8 snappingDistance = -1, text overlapMergeStrategy =
> 'MERGE_LONGEST_BORDER');
>
> means that the best-practice pattern for using the function is to simply
> specify the maximum gap width, leaving the snapping tolerance and overlap
> merge strategy as defaulits:
>
> CREATE TABLE  example1_c AS
>   SELECT id,  ST_CoverageClean(geom, 1) OVER () AS GEOM
>   FROM  example1;
>
>
> On Tue, Oct 7, 2025 at 10:49?AM Paul Ramsey via postgis-users <
> postgis-users at lists.osgeo.org> wrote:
>
>> If I told you there is an error in the documentation and that the actual
>> signature is this, would that allay your concerns?
>>
>> ST_CoverageClean (geom geometry, gapMaximumWidth float8 default 0.0,
>> snappingDistance float8 default -1.0, overlapMergeStrategy text default '
>> MERGE_LONGEST_BORDER')
>>
>> P.
>>
>> On Tue, Sep 23, 2025 at 5:25?AM Douglas Fan <douglas.mhfan at gmail.com>
>> wrote:
>>
>>> Dear PostGIS Developers and Users,
>>>
>>> First of all, thank you for the development of the new ST_CoverageClean
>>> function in PostGIS 3.6.0. It?s a fantastic addition that has already
>>> helped a lot in my work with polygonal coverages. I really appreciate the
>>> effort that went into making this tool available.
>>> While testing the function, I?ve encountered some behaviors that I?d
>>> like to better understand, particularly regarding the snappingDistance and
>>> gapMaximumWidth parameters.
>>>
>>> From the documentation, I understand that:
>>> 1. snappingDistance controls vertex snapping, with -1 applying an
>>> automatic distance, and 0.0 disabling snapping.
>>> 2. gapMaximumWidth closes gaps smaller than the specified tolerance.
>>>
>>> However, during testing with various combinations (e.g.,
>>> snappingDistance set to -1, 0.0, 1, 2 and gapMaximumWidth set to 0, 1, 2),
>>> I noticed:
>>> 1. Even when snappingDistance is explicitly set to 0.0, small sliver
>>> vertices still appear to be snapped or altered when gapMaximumWidth is
>>> greater than 0.
>>> 2. Slivers that are thinner than the gapMaximumWidth are removed, even
>>> when they are not actual gaps or overlaps.
>>>
>>> This behavior seems counterintuitive, as I expected no snapping to occur
>>> with snappingDistance = 0.0. Could this be due to internal gap cleaning
>>> logic that also affects vertex positions? Or is there an implicit snapping
>>> step tied to gapMaximumWidth?
>>>
>>> I?d be grateful for any insights into:
>>>
>>> 1. How do these two parameters interact?
>>> 2. Best practices or recommended workflows for cleaning polygonal
>>> coverages with minimal geometry distortion.
>>> 3. Any known edge cases or limitations when using ST_CoverageClean.
>>> 4. Whether gapMaximumWidth also triggers geometry simplification or
>>> sliver removal beyond gap closing.
>>>
>>> Thanks in advance for your help and for the continued development of
>>> PostGIS.
>>>
>>> Best regards,
>>> Man Ho Fan
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20251008/4bbf011f/attachment.htm>

From senhor.neto at gmail.com  Fri Oct 10 04:04:30 2025
From: senhor.neto at gmail.com (Alexandre Neto)
Date: Fri, 10 Oct 2025 11:04:30 +0000
Subject: Documentation for 3.5 and 3.6 links not working
Message-ID: <61f2bf05-cd5d-4979-a7f9-9a472383796c@mail.shortwave.com>

Hi, I was looking for the Postgis 3.5 Manual PDF and the link on this page is failing:

https://postgis.net/documentation/manual/ <https://postgis.net/documentation/manual/>

It seems 3.6 also does not work, but 3.4 works properly.

Thanks,

Alex

Sent with Shortwave <https://www.shortwave.com?utm_medium=email&utm_content=signature&utm_source=c2VuaG9yLm5ldG9AZ21haWwuY29t>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20251010/cc0f2ab2/attachment.htm>

From lr at pcorp.us  Fri Oct 10 22:53:14 2025
From: lr at pcorp.us (Regina Obe)
Date: Sat, 11 Oct 2025 01:53:14 -0400
Subject: Documentation for 3.5 and 3.6 links not working
In-Reply-To: <61f2bf05-cd5d-4979-a7f9-9a472383796c@mail.shortwave.com>
References: <61f2bf05-cd5d-4979-a7f9-9a472383796c@mail.shortwave.com>
Message-ID: <001c01dc3a73$55cc3a90$0164afb0$@pcorp.us>

Alex,

 

Thanks for alerting.  I?ve ticketed here - https://trac.osgeo.org/postgis/ticket/6002

 

The issue is because we have the pdfs lang tagged now.  

 

So the English pdf is here https://postgis.net/stuff/postgis-3.6-en.pdf  - https://postgis.net/stuff/postgis-3.5-en.pdf

 

Thanks,

Regina

 

 

From: Alexandre Neto <senhor.neto at gmail.com> 
Sent: Friday, October 10, 2025 7:05 AM
To: PostGIS Users Discussion <postgis-users at lists.osgeo.org>
Subject: Documentation for 3.5 and 3.6 links not working

 

Hi, I was looking for the Postgis 3.5 Manual PDF and the link on this page is failing:

 

https://postgis.net/documentation/manual/

 

It seems 3.6 also does not work, but 3.4 works properly.

 

Thanks,

 

Alex

 

Sent with  <https://www.shortwave.com?utm_medium=email&utm_content=signature&utm_source=c2VuaG9yLm5ldG9AZ21haWwuY29t> Shortwave 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20251011/743aaf33/attachment.htm>

From laurent.celati at gmail.com  Sun Oct 12 10:25:07 2025
From: laurent.celati at gmail.com (celati Laurent)
Date: Sun, 12 Oct 2025 19:25:07 +0200
Subject: Percentage of area overlaped / covered by feature of another layer
Message-ID: <CAHByMH2FF4G+3eWXZiDemVox6T2pSVbSje0JcYgiwLx0EPhy3A@mail.gmail.com>

Dear all,

I'm working with QGIS and, if necessary, PostGIS.
I have two vector layers :

 - A first polygonal layer resulting from vectorization work using
photointerpretation of the aerial imagery (in blue in the attached
screenshot below).
 - A second polygonal layer in the same area resulting from segmentation of
the same aerial imagery (in yellow in the attached screenshot below).

[image: SS_seg_PI_identifiants.png]


Each feature in the two layers has a unique identifier (representing thanks
to labels in the screenshot).

I'd like to be able to produce a small performance indicator of the
segmentation performs in faithfully matching the photointerpretation. I was
thinking there's probably something that could be done with geoprocessing
(union, intersection?) and a area calculation ? An indicator of
segmentation performance could be: for each photo-interpreted
feature/polygon, calculate the percentage of the surface area covered by
the feature in the segmentation layer with the biggest overlap ?
To be more specific, in the example screenshot, this could be:
"For feature 11 in photo-interpretation layer (blue), I would like to know
the percentage of the surface area covered by the feature in the
segmentation layer that has the highest overlap with this feature 11 (in
this specific case, it's probably feature 42 in yellow)."

This could be: area of feature 42 overlapping feature 11 / total area of
feature 11?

I don't know if I'm on the right path. How could we translate this needs
toward a QGIS and/or PostGIS tool?

Thanks so much
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20251012/e2211660/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SS_seg_PI_identifiants.png
Type: image/png
Size: 228559 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20251012/e2211660/attachment.png>

From lr at pcorp.us  Tue Oct 14 06:12:26 2025
From: lr at pcorp.us (Regina Obe)
Date: Tue, 14 Oct 2025 09:12:26 -0400
Subject: FW: Important FOSS4GNA Updates
In-Reply-To: <8635900ee697ecbb8a595f92d.712ae0da92.20251014105955.f4f83eae80.ab317614@mail75.atl111.rsgsv.net>
References: <8635900ee697ecbb8a595f92d.712ae0da92.20251014105955.f4f83eae80.ab317614@mail75.atl111.rsgsv.net>
Message-ID: <005201dc3d0c$307247d0$9156d770$@pcorp.us>

 

 

 

? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ? ? ?   ?? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

  <https://osgeo.us19.list-manage.com/track/open.php?u=8635900ee697ecbb8a595f92d&id=f4f83eae80&e=712ae0da92> 








 <https://www.foss4gna.org/> 









TL;DR;

 

Hotel Discount Ends Today 10/14

FOSS4GNA & Stacks Journal Submissions Open November 3rd

T-shirts, Stickers, Mugs, and More
Don't forget to vote




Thank you to our Sponsors




Platinum Sponsors












 <https://www.carahsoft.com/> 




Silver Sponsors












 <https://www.postgresql.fastware.com/> 


 <https://www.t-kartor.com/> 












 <https://cesium.com/> 


 <https://www.motivf.com/> 




Bronze Sponsors












 <https://element84.com/> 


 <https://prominentedge.com/> 


 <https://developmentseed.org/> 












 <https://wherobots.com/> 


 <https://georobotix.com/> 



	




Academic Supporters












 <https://www.library.vanderbilt.edu/gis-lab> 


 <https://visrvu.org/> 


 <https://www.psu.edu/> 



	




Supporters












 <https://www.dewberry.com/> 


 <https://www.terraframe.com/> 


 <https://www.ertcorp.com/> 


 <https://gcsgeospatial.com/> 












 <https://www.costquest.com/> 


 <https://wgicouncil.org/> 


 <https://www.iqgeo.com/> 


 <https://cercanasystems.com/> 












 <https://newmoyergeospatial.com/> 


 <https://marauders.earth/> 


 <https://earthdaily.com/> 



	




Hotel Discount Ends Today 10/14












 <https://web.cvent.com/event/5a9e1809-2ffb-484c-8998-4289fcb4199e/regProcessStep1?RefId=FOSS4GNA2025Registration> 














Tuesday, October 14th, is the last day to reserve your room at the Hyatt Regency Reston at our discounted group rate of $ 196 + taxes and fees (prevailing federal per diem). Attendees are encouraged to reserve their room today ? staying at the conference hotel helps conference organizers to meet their obligations at the venue while also putting you in the best position to meet and network with your fellow attendees.

 

The Hyatt Regency Reston, the only 4-Diamond hotel in Reston, will host the conference this year. Situated in the heart of Reston Town Center, the venue is surrounded by premier dining, shopping, and entertainment options, putting you at the center of the action.


















FOSS4GNA & Stacks Journal 
Submissions Open November 3rd


  <https://mcusercontent.com/8635900ee697ecbb8a595f92d/images/6743eb23-d129-c37e-d420-04e6f3aac7ac.png> 














To provide an open access publication outlet for participants of the FOSS4GNA Conference and to support the needs of our academic community, FOSS4GNA will partner with Stacks Journal to produce a special issue featuring the proceedings of this year's conference.

 

The Academic Committee will give preference to those presenting at the FOSS4GNA 2025 conference for inclusion. We are accepting submissions from participants that highlight geospatial work that is of interest to government, academic, and industry readers. Topics of interest include: innovative methods development, practical applications of geospatial analytics, cross-sector collaboration, visualization, and design to support geospatial exploration.


















T-shirts, Stickers, Mugs, and More












  <https://mcusercontent.com/8635900ee697ecbb8a595f92d/images/4aa5bcd3-2578-b982-d3ad-59ebf607719c.jpg> 


  <https://mcusercontent.com/8635900ee697ecbb8a595f92d/images/d7c59fed-c674-e1e7-a2d6-96723b4ab212.jpg> 


  <https://mcusercontent.com/8635900ee697ecbb8a595f92d/images/bb44a4b7-eb0f-aa01-ff2a-0c464fad632b.jpg> 


  <https://mcusercontent.com/8635900ee697ecbb8a595f92d/images/00ca434a-e971-9739-27a8-7d7abf093f12.jpg> 














Order your swag on REDBUBBLE now if you would like to have it delivered by the time of the conference. By offering many great designs across multiple types of swag, we let you choose the fun momento that reminds you of the great time you had. We are fortunate to have received many excellent designs over the last couple of years.


















Don?t Forget to Vote














This is a friendly reminder that this year's election day falls on the same day as the FOSS4GNA conference. You may be eligible to vote before the election as an absentee or early voter. State laws vary greatly, so be sure to pay attention to the information provided by your election officials or contact your local election office for help. 


  <https://mcusercontent.com/8635900ee697ecbb8a595f92d/images/32cf90d7-54d6-4592-d4c2-aa9c5b705226.png> 




























 <https://mailchi.mp/technocation/final-days-submit-to-speak-at-foss4gna-19868597?e=712ae0da92> Please Share this email with your networks








 <https://osgeo.us19.list-manage.com/track/click?u=8635900ee697ecbb8a595f92d&id=0689f56e28&e=712ae0da92> 

 <https://osgeo.us19.list-manage.com/track/click?u=8635900ee697ecbb8a595f92d&id=23a2778b67&e=712ae0da92> Share on Facebook


 <https://osgeo.us19.list-manage.com/track/click?u=8635900ee697ecbb8a595f92d&id=c7d85cadf4&e=712ae0da92> 

 <https://osgeo.us19.list-manage.com/track/click?u=8635900ee697ecbb8a595f92d&id=702701e88b&e=712ae0da92> Share on LinkedIn


 <https://us19.forward-to-friend.com/forward?u=8635900ee697ecbb8a595f92d&id=f4f83eae80&e=712ae0da92> 

 <https://us19.forward-to-friend.com/forward?u=8635900ee697ecbb8a595f92d&id=f4f83eae80&e=712ae0da92> Share with email


 <https://osgeo.us/> 












Copyright (C) 2025 OSGeo US. All rights reserved. 
You are receiving this email because you participated in an event run by The OSGeo US Chapter or opted in at our website.

Our mailing address is:
OSGeo US 73 County Road Plympton, MA 02367 USA 

Want to change how you receive these emails?

You can  <https://osgeo.us19.list-manage.com/profile?u=8635900ee697ecbb8a595f92d&id=3a908f07c0&e=712ae0da92&c=f4f83eae80> update your preferences or  <https://osgeo.us19.list-manage.com/unsubscribe?u=8635900ee697ecbb8a595f92d&id=3a908f07c0&t=b&e=712ae0da92&c=f4f83eae80> unsubscribe.

 

 <https://mailchi.mp/technocation/final-days-submit-to-speak-at-foss4gna-19868597?e=712ae0da92> View in browser



	

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20251014/c4940b2a/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 1033 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20251014/c4940b2a/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 851 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20251014/c4940b2a/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 1063 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20251014/c4940b2a/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 1139 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20251014/c4940b2a/attachment-0003.png>

From anvalanz at gmail.com  Wed Oct 15 09:22:05 2025
From: anvalanz at gmail.com (Antonio Valanzano)
Date: Wed, 15 Oct 2025 18:22:05 +0200
Subject: different results for ST_Relate with 3 parameters compared to those
 for ST_Relate with 2 parameters
Message-ID: <CANV1FQYH0T9im=NTOUEYic+V2VLkyet-L3ZvCADVkLf0n+DtqQ@mail.gmail.com>

I am following the "Introduction to PostGIS " tutorial  at
https://postgis.net/workshops/postgis-intro/
and for chapter 26 "Dimensionally Extended 9-Intersection Model"  I am
trying to replicate the examples.

If I use the two different versions of ST_Relate I do not obtain the same
result

SELECT
  d.id,
  ST_Relate(d.geom, l.geom) as patternMatrix
FROM docks as d, lakes as l
WHERE ST_Relate(d.geom, l.geom, '1FF00F212') = true;
-- 1 row
"id" "patternmatrix"
1    "1FF00F212"



SELECT
  d.id,
  ST_Relate(d.geom, l.geom) as patternMatrix
FROM docks as d, lakes as l
WHERE ST_Relate(d.geom, l.geom) = '1FF00F212';
-- 2 rows
"id" "patternmatrix"
1    "1FF00F212"
2    "1FF00F212"

Could someone give me an explanation of such a difference ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20251015/cdf28da0/attachment.htm>

From pramsey at cleverelephant.ca  Wed Oct 15 10:28:25 2025
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Wed, 15 Oct 2025 10:28:25 -0700
Subject: different results for ST_Relate with 3 parameters compared to
 those for ST_Relate with 2 parameters
In-Reply-To: <CANV1FQYH0T9im=NTOUEYic+V2VLkyet-L3ZvCADVkLf0n+DtqQ@mail.gmail.com>
References: <CANV1FQYH0T9im=NTOUEYic+V2VLkyet-L3ZvCADVkLf0n+DtqQ@mail.gmail.com>
Message-ID: <CACowWR0QR5LiwjYmud-A1wHoJAdGNsrJu0836Rsco6Ro7NFaFw@mail.gmail.com>

Maybe you have found an old bug? Running exactly the same SQL as you, I get
two rows from each query.

postgis=# SELECT

            d.id,

                     ST_Relate(d.geom, l.geom) as patternMatrix

                            FROM docks as d, lakes as l

                                     WHERE ST_Relate(d.geom, l.geom,
'1FF00F212');
 id | patternmatrix
----+---------------
  1 | 1FF00F212
  2 | 1FF00F212
(2 rows)

postgis=# SELECT
postgis-#   d.id,
postgis-#   ST_Relate(d.geom, l.geom) as patternMatrix
postgis-# FROM docks as d, lakes as l
postgis-# WHERE ST_Relate(d.geom, l.geom) = '1FF00F212';
 id | patternmatrix
----+---------------
  1 | 1FF00F212
  2 | 1FF00F212
(2 rows)

postgis=#
postgis=# select postgis_full_version();



postgis_full_version



----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 POSTGIS="3.7.0dev 3.6.0rc2-134-g5dc95f1bc" [EXTENSION] PGSQL="180"
GEOS="3.15.0dev-CAPI-1.21.0" PROJ="9.6.2 NETWORK_ENABLED=ON URL_ENDPOINT=
https://cdn.proj.org
USER_WRITABLE_DIRECTORY=/Users/pramsey/Library/Application Support/proj
DATABASE_PATH=/opt/homebrew/Cellar/proj/9.6.2/share/proj/proj.db" (compiled
against PROJ 9.6.2) LIBXML="2.9.13" LIBJSON="0.18" LIBPROTOBUF="1.5.2"
WAGYU="0.5.0 (Internal)" (core procs from "3.7.0dev
3.6.0rc2-125-g747d7732b" need upgrade)

On Wed, Oct 15, 2025 at 9:22?AM Antonio Valanzano <anvalanz at gmail.com>
wrote:

> I am following the "Introduction to PostGIS " tutorial  at
> https://postgis.net/workshops/postgis-intro/
> and for chapter 26 "Dimensionally Extended 9-Intersection Model"  I am
> trying to replicate the examples.
>
> If I use the two different versions of ST_Relate I do not obtain the same
> result
>
> SELECT
>   d.id,
>   ST_Relate(d.geom, l.geom) as patternMatrix
> FROM docks as d, lakes as l
> WHERE ST_Relate(d.geom, l.geom, '1FF00F212') = true;
> -- 1 row
> "id" "patternmatrix"
> 1    "1FF00F212"
>
>
>
> SELECT
>   d.id,
>   ST_Relate(d.geom, l.geom) as patternMatrix
> FROM docks as d, lakes as l
> WHERE ST_Relate(d.geom, l.geom) = '1FF00F212';
> -- 2 rows
> "id" "patternmatrix"
> 1    "1FF00F212"
> 2    "1FF00F212"
>
> Could someone give me an explanation of such a difference ?
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20251015/676c6a3f/attachment.htm>

From public at postholer.com  Wed Oct 15 10:45:24 2025
From: public at postholer.com (Scott)
Date: Wed, 15 Oct 2025 10:45:24 -0700
Subject: different results for ST_Relate with 3 parameters compared to
 those for ST_Relate with 2 parameters
In-Reply-To: <CACowWR0QR5LiwjYmud-A1wHoJAdGNsrJu0836Rsco6Ro7NFaFw@mail.gmail.com>
References: <CANV1FQYH0T9im=NTOUEYic+V2VLkyet-L3ZvCADVkLf0n+DtqQ@mail.gmail.com>
 <CACowWR0QR5LiwjYmud-A1wHoJAdGNsrJu0836Rsco6Ro7NFaFw@mail.gmail.com>
Message-ID: <32084090-2dbf-4000-b69e-9a39e53bb3ec@postholer.com>

Not sure if it matters, but 3 variants of st_relate exist. The WHERE for 
bool is variant 1 and the WHERE for text is variant 2. Variant 2 and 3 
return text, but are different return types. Maybe 2 different results 
is to be expected?

Docs:

https://postgis.net/docs/ST_Relate.html

Scott



On 10/15/25 10:28, Paul Ramsey via postgis-users wrote:
> Maybe you have found an old bug? Running exactly the same SQL as you, I 
> get two rows from each query.
> 
> postgis=# SELECT d.id <http://d.id>,                                     
>                                                                          
>  ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?ST_Relate(d.geom, 
> l.geom) as patternMatrix                                                 
>                                                                      
> FROM docks as d, lakes as l                                             
>                                                                          
>  ? ? ? ? ? ? ? ? ?WHERE ST_Relate(d.geom, l.geom, '1FF00F212');
>  ?id | patternmatrix
> ----+---------------
>  ? 1 | 1FF00F212
>  ? 2 | 1FF00F212
> (2 rows)
> 
> postgis=# SELECT
> postgis-# d.id <http://d.id>,
> postgis-# ? ST_Relate(d.geom, l.geom) as patternMatrix
> postgis-# FROM docks as d, lakes as l
> postgis-# WHERE ST_Relate(d.geom, l.geom) = '1FF00F212';
>  ?id | patternmatrix
> ----+---------------
>  ? 1 | 1FF00F212
>  ? 2 | 1FF00F212
> (2 rows)
> 
> postgis=#
> postgis=# select postgis_full_version();
>                                                                          
>                                                                          
>                                                                          
>  ? ? ? ? ? postgis_full_version
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>  ?POSTGIS="3.7.0dev 3.6.0rc2-134-g5dc95f1bc" [EXTENSION] PGSQL="180" 
> GEOS="3.15.0dev-CAPI-1.21.0" PROJ="9.6.2 NETWORK_ENABLED=ON 
> URL_ENDPOINT=https://cdn.proj.org <https://cdn.proj.org> 
> USER_WRITABLE_DIRECTORY=/Users/pramsey/Library/Application Support/proj 
> DATABASE_PATH=/opt/homebrew/Cellar/proj/9.6.2/share/proj/ 
> proj.db" (compiled against PROJ 9.6.2) LIBXML="2.9.13" LIBJSON="0.18" 
> LIBPROTOBUF="1.5.2" WAGYU="0.5.0 (Internal)" (core procs from "3.7.0dev 
> 3.6.0rc2-125-g747d7732b" need upgrade)
> 
> On Wed, Oct 15, 2025 at 9:22?AM Antonio Valanzano <anvalanz at gmail.com 
> <mailto:anvalanz at gmail.com>> wrote:
> 
>     I am following the "Introduction to PostGIS " tutorial? at https://
>     postgis.net/workshops/postgis-intro/ <https://postgis.net/workshops/
>     postgis-intro/>
>     and for chapter 26 "Dimensionally Extended 9-Intersection Model"? I
>     am trying to replicate the examples.
> 
>     If I use the two different versions of ST_Relate I do not obtain the
>     same result
> 
>     SELECT
>     d.id <http://d.id>,
>      ? ST_Relate(d.geom, l.geom) as patternMatrix
>     FROM docks as d, lakes as l
>     WHERE ST_Relate(d.geom, l.geom, '1FF00F212') = true;
>     -- 1 row
>     "id" "patternmatrix"
>     1 ? ?"1FF00F212"
> 
> 
> 
>     SELECT
>     d.id <http://d.id>,
>      ? ST_Relate(d.geom, l.geom) as patternMatrix
>     FROM docks as d, lakes as l
>     WHERE ST_Relate(d.geom, l.geom) = '1FF00F212';
>     -- 2 rows
>     "id" "patternmatrix"
>     1 ? ?"1FF00F212"
>     2 ? ?"1FF00F212"
> 
>     Could someone give me an explanation of such a difference ?
> 
> 


From anvalanz at gmail.com  Wed Oct 15 11:25:42 2025
From: anvalanz at gmail.com (Antonio Valanzano)
Date: Wed, 15 Oct 2025 20:25:42 +0200
Subject: different results for ST_Relate with 3 parameters compared to
 those for ST_Relate with 2 parameters
In-Reply-To: <CACowWR0QR5LiwjYmud-A1wHoJAdGNsrJu0836Rsco6Ro7NFaFw@mail.gmail.com>
References: <CANV1FQYH0T9im=NTOUEYic+V2VLkyet-L3ZvCADVkLf0n+DtqQ@mail.gmail.com>
 <CACowWR0QR5LiwjYmud-A1wHoJAdGNsrJu0836Rsco6Ro7NFaFw@mail.gmail.com>
Message-ID: <CANV1FQZXc0k_aeiKjjGBOJ2OLEmBeyaOc60vv6taEEstKTN5Og@mail.gmail.com>

Here is the details of my installation:

"postgis_full_version"
"POSTGIS=""3.5.2 3.5.2"" [EXTENSION] PGSQL=""170""
GEOS=""3.13.0-CAPI-1.19.0"" PROJ=""8.2.1 NETWORK_ENABLED=OFF URL_ENDPOINT=
https://cdn.proj.org
USER_WRITABLE_DIRECTORY=C:\Windows\ServiceProfiles\NetworkService\AppData\Local/proj
DATABASE_PATH=C:\Program
Files\PostgreSQL\17\share\contrib\postgis-3.5\proj\proj.db"" (compiled
against PROJ 8.2.1) LIBXML=""2.12.5"" LIBJSON=""0.12""
LIBPROTOBUF=""1.2.1"" WAGYU=""0.5.0 (Internal)"""

Antonio



Il giorno mer 15 ott 2025 alle ore 19:28 Paul Ramsey <
pramsey at cleverelephant.ca> ha scritto:

> Maybe you have found an old bug? Running exactly the same SQL as you, I
> get two rows from each query.
>
> postgis=# SELECT
>
>             d.id,
>
>                        ST_Relate(d.geom, l.geom) as patternMatrix
>
>                               FROM docks as d, lakes as l
>
>                                        WHERE ST_Relate(d.geom, l.geom,
> '1FF00F212');
>  id | patternmatrix
> ----+---------------
>   1 | 1FF00F212
>   2 | 1FF00F212
> (2 rows)
>
> postgis=# SELECT
> postgis-#   d.id,
> postgis-#   ST_Relate(d.geom, l.geom) as patternMatrix
> postgis-# FROM docks as d, lakes as l
> postgis-# WHERE ST_Relate(d.geom, l.geom) = '1FF00F212';
>  id | patternmatrix
> ----+---------------
>   1 | 1FF00F212
>   2 | 1FF00F212
> (2 rows)
>
> postgis=#
> postgis=# select postgis_full_version();
>
>
>
> postgis_full_version
>
>
>
>
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>  POSTGIS="3.7.0dev 3.6.0rc2-134-g5dc95f1bc" [EXTENSION] PGSQL="180"
> GEOS="3.15.0dev-CAPI-1.21.0" PROJ="9.6.2 NETWORK_ENABLED=ON URL_ENDPOINT=
> https://cdn.proj.org
> USER_WRITABLE_DIRECTORY=/Users/pramsey/Library/Application Support/proj
> DATABASE_PATH=/opt/homebrew/Cellar/proj/9.6.2/share/proj/proj.db" (compiled
> against PROJ 9.6.2) LIBXML="2.9.13" LIBJSON="0.18" LIBPROTOBUF="1.5.2"
> WAGYU="0.5.0 (Internal)" (core procs from "3.7.0dev
> 3.6.0rc2-125-g747d7732b" need upgrade)
>
> On Wed, Oct 15, 2025 at 9:22?AM Antonio Valanzano <anvalanz at gmail.com>
> wrote:
>
>> I am following the "Introduction to PostGIS " tutorial  at
>> https://postgis.net/workshops/postgis-intro/
>> and for chapter 26 "Dimensionally Extended 9-Intersection Model"  I am
>> trying to replicate the examples.
>>
>> If I use the two different versions of ST_Relate I do not obtain the same
>> result
>>
>> SELECT
>>   d.id,
>>   ST_Relate(d.geom, l.geom) as patternMatrix
>> FROM docks as d, lakes as l
>> WHERE ST_Relate(d.geom, l.geom, '1FF00F212') = true;
>> -- 1 row
>> "id" "patternmatrix"
>> 1    "1FF00F212"
>>
>>
>>
>> SELECT
>>   d.id,
>>   ST_Relate(d.geom, l.geom) as patternMatrix
>> FROM docks as d, lakes as l
>> WHERE ST_Relate(d.geom, l.geom) = '1FF00F212';
>> -- 2 rows
>> "id" "patternmatrix"
>> 1    "1FF00F212"
>> 2    "1FF00F212"
>>
>> Could someone give me an explanation of such a difference ?
>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20251015/9bc334b8/attachment.htm>

From pramsey at cleverelephant.ca  Wed Oct 15 11:59:21 2025
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Wed, 15 Oct 2025 11:59:21 -0700
Subject: different results for ST_Relate with 3 parameters compared to
 those for ST_Relate with 2 parameters
In-Reply-To: <CANV1FQZXc0k_aeiKjjGBOJ2OLEmBeyaOc60vv6taEEstKTN5Og@mail.gmail.com>
References: <CANV1FQYH0T9im=NTOUEYic+V2VLkyet-L3ZvCADVkLf0n+DtqQ@mail.gmail.com>
 <CACowWR0QR5LiwjYmud-A1wHoJAdGNsrJu0836Rsco6Ro7NFaFw@mail.gmail.com>
 <CANV1FQZXc0k_aeiKjjGBOJ2OLEmBeyaOc60vv6taEEstKTN5Og@mail.gmail.com>
Message-ID: <CACowWR2PhX5Z2a9gKNc6o28RhPoxroUPsSKEBNeO72uq+V5cvA@mail.gmail.com>

Sorry, I still cannot replicate. My 3.5 build still returns both results.
Maybe update to PostGIS 3.5.4 and GEOS 3.13.1 ?
P.

On Wed, Oct 15, 2025 at 11:25?AM Antonio Valanzano <anvalanz at gmail.com>
wrote:

> Here is the details of my installation:
>
> "postgis_full_version"
> "POSTGIS=""3.5.2 3.5.2"" [EXTENSION] PGSQL=""170""
> GEOS=""3.13.0-CAPI-1.19.0"" PROJ=""8.2.1 NETWORK_ENABLED=OFF URL_ENDPOINT=
> https://cdn.proj.org
> USER_WRITABLE_DIRECTORY=C:\Windows\ServiceProfiles\NetworkService\AppData\Local/proj
> DATABASE_PATH=C:\Program
> Files\PostgreSQL\17\share\contrib\postgis-3.5\proj\proj.db"" (compiled
> against PROJ 8.2.1) LIBXML=""2.12.5"" LIBJSON=""0.12""
> LIBPROTOBUF=""1.2.1"" WAGYU=""0.5.0 (Internal)"""
>
> Antonio
>
>
>
> Il giorno mer 15 ott 2025 alle ore 19:28 Paul Ramsey <
> pramsey at cleverelephant.ca> ha scritto:
>
>> Maybe you have found an old bug? Running exactly the same SQL as you, I
>> get two rows from each query.
>>
>> postgis=# SELECT
>>
>>               d.id,
>>
>>                            ST_Relate(d.geom, l.geom) as patternMatrix
>>
>>                                   FROM docks as d, lakes as l
>>
>>                                            WHERE ST_Relate(d.geom, l.geom,
>> '1FF00F212');
>>  id | patternmatrix
>> ----+---------------
>>   1 | 1FF00F212
>>   2 | 1FF00F212
>> (2 rows)
>>
>> postgis=# SELECT
>> postgis-#   d.id,
>> postgis-#   ST_Relate(d.geom, l.geom) as patternMatrix
>> postgis-# FROM docks as d, lakes as l
>> postgis-# WHERE ST_Relate(d.geom, l.geom) = '1FF00F212';
>>  id | patternmatrix
>> ----+---------------
>>   1 | 1FF00F212
>>   2 | 1FF00F212
>> (2 rows)
>>
>> postgis=#
>> postgis=# select postgis_full_version();
>>
>>
>>
>> postgis_full_version
>>
>>
>>
>>
>> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>  POSTGIS="3.7.0dev 3.6.0rc2-134-g5dc95f1bc" [EXTENSION] PGSQL="180"
>> GEOS="3.15.0dev-CAPI-1.21.0" PROJ="9.6.2 NETWORK_ENABLED=ON URL_ENDPOINT=
>> https://cdn.proj.org
>> USER_WRITABLE_DIRECTORY=/Users/pramsey/Library/Application Support/proj
>> DATABASE_PATH=/opt/homebrew/Cellar/proj/9.6.2/share/proj/proj.db" (compiled
>> against PROJ 9.6.2) LIBXML="2.9.13" LIBJSON="0.18" LIBPROTOBUF="1.5.2"
>> WAGYU="0.5.0 (Internal)" (core procs from "3.7.0dev
>> 3.6.0rc2-125-g747d7732b" need upgrade)
>>
>> On Wed, Oct 15, 2025 at 9:22?AM Antonio Valanzano <anvalanz at gmail.com>
>> wrote:
>>
>>> I am following the "Introduction to PostGIS " tutorial  at
>>> https://postgis.net/workshops/postgis-intro/
>>> and for chapter 26 "Dimensionally Extended 9-Intersection Model"  I am
>>> trying to replicate the examples.
>>>
>>> If I use the two different versions of ST_Relate I do not obtain the
>>> same result
>>>
>>> SELECT
>>>   d.id,
>>>   ST_Relate(d.geom, l.geom) as patternMatrix
>>> FROM docks as d, lakes as l
>>> WHERE ST_Relate(d.geom, l.geom, '1FF00F212') = true;
>>> -- 1 row
>>> "id" "patternmatrix"
>>> 1    "1FF00F212"
>>>
>>>
>>>
>>> SELECT
>>>   d.id,
>>>   ST_Relate(d.geom, l.geom) as patternMatrix
>>> FROM docks as d, lakes as l
>>> WHERE ST_Relate(d.geom, l.geom) = '1FF00F212';
>>> -- 2 rows
>>> "id" "patternmatrix"
>>> 1    "1FF00F212"
>>> 2    "1FF00F212"
>>>
>>> Could someone give me an explanation of such a difference ?
>>>
>>>
>>>
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20251015/eb481557/attachment.htm>

From anvalanz at gmail.com  Wed Oct 15 12:53:35 2025
From: anvalanz at gmail.com (Antonio Valanzano)
Date: Wed, 15 Oct 2025 21:53:35 +0200
Subject: different results for ST_Relate with 3 parameters compared to
 those for ST_Relate with 2 parameters
In-Reply-To: <CACowWR2PhX5Z2a9gKNc6o28RhPoxroUPsSKEBNeO72uq+V5cvA@mail.gmail.com>
References: <CANV1FQYH0T9im=NTOUEYic+V2VLkyet-L3ZvCADVkLf0n+DtqQ@mail.gmail.com>
 <CACowWR0QR5LiwjYmud-A1wHoJAdGNsrJu0836Rsco6Ro7NFaFw@mail.gmail.com>
 <CANV1FQZXc0k_aeiKjjGBOJ2OLEmBeyaOc60vv6taEEstKTN5Og@mail.gmail.com>
 <CACowWR2PhX5Z2a9gKNc6o28RhPoxroUPsSKEBNeO72uq+V5cvA@mail.gmail.com>
Message-ID: <CANV1FQZk5q_uRpU8LvQZJrexyRaQa7RW87fzx5eLw0ufv7XYHw@mail.gmail.com>

Hi Paul
I have upgraded to PosGIS 3.5.3 and GEOS  3.13.1 as you can see from the
following output

"postgis_full_version"
"POSTGIS=""3.5.3 3.5.3"" [EXTENSION] PGSQL=""170""
GEOS=""3.13.1-CAPI-1.19.2"" PROJ=""8.2.1 NETWORK_ENABLED=OFF URL_ENDPOINT=
https://cdn.proj.org
USER_WRITABLE_DIRECTORY=C:\Windows\ServiceProfiles\NetworkService\AppData\Local/proj
DATABASE_PATH=C:\Program
Files\PostgreSQL\17\share\contrib\postgis-3.5\proj\proj.db"" (compiled
against PROJ 8.2.1) LIBXML=""2.12.5"" LIBJSON=""0.12""
LIBPROTOBUF=""1.2.1"" WAGYU=""0.5.0 (Internal)"" (core procs from ""3.5.2
3.5.2"" need upgrade)"

but the results are the same with one row for a query and 2 rows for the
other query.

Is this a known bug or no other user has already reported this behaviour ?

Antonio




Il giorno mer 15 ott 2025 alle ore 20:59 Paul Ramsey <
pramsey at cleverelephant.ca> ha scritto:

> Sorry, I still cannot replicate. My 3.5 build still returns both results.
> Maybe update to PostGIS 3.5.4 and GEOS 3.13.1 ?
> P.
>
> On Wed, Oct 15, 2025 at 11:25?AM Antonio Valanzano <anvalanz at gmail.com>
> wrote:
>
>> Here is the details of my installation:
>>
>> "postgis_full_version"
>> "POSTGIS=""3.5.2 3.5.2"" [EXTENSION] PGSQL=""170""
>> GEOS=""3.13.0-CAPI-1.19.0"" PROJ=""8.2.1 NETWORK_ENABLED=OFF URL_ENDPOINT=
>> https://cdn.proj.org
>> USER_WRITABLE_DIRECTORY=C:\Windows\ServiceProfiles\NetworkService\AppData\Local/proj
>> DATABASE_PATH=C:\Program
>> Files\PostgreSQL\17\share\contrib\postgis-3.5\proj\proj.db"" (compiled
>> against PROJ 8.2.1) LIBXML=""2.12.5"" LIBJSON=""0.12""
>> LIBPROTOBUF=""1.2.1"" WAGYU=""0.5.0 (Internal)"""
>>
>> Antonio
>>
>>
>>
>> Il giorno mer 15 ott 2025 alle ore 19:28 Paul Ramsey <
>> pramsey at cleverelephant.ca> ha scritto:
>>
>>> Maybe you have found an old bug? Running exactly the same SQL as you, I
>>> get two rows from each query.
>>>
>>> postgis=# SELECT
>>>
>>>               d.id,
>>>
>>>                            ST_Relate(d.geom, l.geom) as patternMatrix
>>>
>>>                                   FROM docks as d, lakes as l
>>>
>>>                                            WHERE ST_Relate(d.geom, l.geom,
>>> '1FF00F212');
>>>  id | patternmatrix
>>> ----+---------------
>>>   1 | 1FF00F212
>>>   2 | 1FF00F212
>>> (2 rows)
>>>
>>> postgis=# SELECT
>>> postgis-#   d.id,
>>> postgis-#   ST_Relate(d.geom, l.geom) as patternMatrix
>>> postgis-# FROM docks as d, lakes as l
>>> postgis-# WHERE ST_Relate(d.geom, l.geom) = '1FF00F212';
>>>  id | patternmatrix
>>> ----+---------------
>>>   1 | 1FF00F212
>>>   2 | 1FF00F212
>>> (2 rows)
>>>
>>> postgis=#
>>> postgis=# select postgis_full_version();
>>>
>>>
>>>
>>>   postgis_full_version
>>>
>>>
>>>
>>>
>>> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>>  POSTGIS="3.7.0dev 3.6.0rc2-134-g5dc95f1bc" [EXTENSION] PGSQL="180"
>>> GEOS="3.15.0dev-CAPI-1.21.0" PROJ="9.6.2 NETWORK_ENABLED=ON URL_ENDPOINT=
>>> https://cdn.proj.org
>>> USER_WRITABLE_DIRECTORY=/Users/pramsey/Library/Application Support/proj
>>> DATABASE_PATH=/opt/homebrew/Cellar/proj/9.6.2/share/proj/proj.db" (compiled
>>> against PROJ 9.6.2) LIBXML="2.9.13" LIBJSON="0.18" LIBPROTOBUF="1.5.2"
>>> WAGYU="0.5.0 (Internal)" (core procs from "3.7.0dev
>>> 3.6.0rc2-125-g747d7732b" need upgrade)
>>>
>>> On Wed, Oct 15, 2025 at 9:22?AM Antonio Valanzano <anvalanz at gmail.com>
>>> wrote:
>>>
>>>> I am following the "Introduction to PostGIS " tutorial  at
>>>> https://postgis.net/workshops/postgis-intro/
>>>> and for chapter 26 "Dimensionally Extended 9-Intersection Model"  I am
>>>> trying to replicate the examples.
>>>>
>>>> If I use the two different versions of ST_Relate I do not obtain the
>>>> same result
>>>>
>>>> SELECT
>>>>   d.id,
>>>>   ST_Relate(d.geom, l.geom) as patternMatrix
>>>> FROM docks as d, lakes as l
>>>> WHERE ST_Relate(d.geom, l.geom, '1FF00F212') = true;
>>>> -- 1 row
>>>> "id" "patternmatrix"
>>>> 1    "1FF00F212"
>>>>
>>>>
>>>>
>>>> SELECT
>>>>   d.id,
>>>>   ST_Relate(d.geom, l.geom) as patternMatrix
>>>> FROM docks as d, lakes as l
>>>> WHERE ST_Relate(d.geom, l.geom) = '1FF00F212';
>>>> -- 2 rows
>>>> "id" "patternmatrix"
>>>> 1    "1FF00F212"
>>>> 2    "1FF00F212"
>>>>
>>>> Could someone give me an explanation of such a difference ?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20251015/dcc3a6e9/attachment.htm>

From pramsey at cleverelephant.ca  Wed Oct 15 13:03:33 2025
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Wed, 15 Oct 2025 13:03:33 -0700
Subject: different results for ST_Relate with 3 parameters compared to
 those for ST_Relate with 2 parameters
In-Reply-To: <CANV1FQZk5q_uRpU8LvQZJrexyRaQa7RW87fzx5eLw0ufv7XYHw@mail.gmail.com>
References: <CANV1FQYH0T9im=NTOUEYic+V2VLkyet-L3ZvCADVkLf0n+DtqQ@mail.gmail.com>
 <CACowWR0QR5LiwjYmud-A1wHoJAdGNsrJu0836Rsco6Ro7NFaFw@mail.gmail.com>
 <CANV1FQZXc0k_aeiKjjGBOJ2OLEmBeyaOc60vv6taEEstKTN5Og@mail.gmail.com>
 <CACowWR2PhX5Z2a9gKNc6o28RhPoxroUPsSKEBNeO72uq+V5cvA@mail.gmail.com>
 <CANV1FQZk5q_uRpU8LvQZJrexyRaQa7RW87fzx5eLw0ufv7XYHw@mail.gmail.com>
Message-ID: <CACowWR0Wou-TvT3Moc4Pj2hNP6GVYoF7LYp=pQ=zXNMovKwhxw@mail.gmail.com>

On Wed, Oct 15, 2025 at 12:53?PM Antonio Valanzano <anvalanz at gmail.com>
wrote:

> Hi Paul
> I have upgraded to PosGIS 3.5.3 and GEOS  3.13.1 as you can see from the
> following output
>
> "postgis_full_version"
> "POSTGIS=""3.5.3 3.5.3"" [EXTENSION] PGSQL=""170""
> GEOS=""3.13.1-CAPI-1.19.2"" PROJ=""8.2.1 NETWORK_ENABLED=OFF URL_ENDPOINT=
> https://cdn.proj.org
> USER_WRITABLE_DIRECTORY=C:\Windows\ServiceProfiles\NetworkService\AppData\Local/proj
> DATABASE_PATH=C:\Program
> Files\PostgreSQL\17\share\contrib\postgis-3.5\proj\proj.db"" (compiled
> against PROJ 8.2.1) LIBXML=""2.12.5"" LIBJSON=""0.12""
> LIBPROTOBUF=""1.2.1"" WAGYU=""0.5.0 (Internal)"" (core procs from ""3.5.2
> 3.5.2"" need upgrade)"
>
> but the results are the same with one row for a query and 2 rows for the
> other query.
>
> Is this a known bug or no other user has already reported this behaviour ?
>

Not reported, and I'm afraid not solvable unless you can figure out the
specific thing about your install vs mine that is giving you a different
answer. (Windows is one possibility, though not one I particularly like,
platform differences are incredibly hard to isolate.)

Seeing if the problem is ordering based and number of entries based might
be interesting.

DELETE FROM docsk;
INSERT INTO docks ( geom, good )
  VALUES
        ('LINESTRING (170 290, 205 272)',true),
        ('LINESTRING (120 215, 176 197)',true),
        ('LINESTRING (290 260, 340 250)',false),
        ('LINESTRING (350 300, 400 320)',false),
        ('LINESTRING (370 230, 420 240)',false),
        ('LINESTRING (170 290, 205 272)',true),
        ('LINESTRING (120 215, 176 197)',true),
        ('LINESTRING (370 180, 390 160)',false);

P


> Antonio
>
>
>
>
> Il giorno mer 15 ott 2025 alle ore 20:59 Paul Ramsey <
> pramsey at cleverelephant.ca> ha scritto:
>
>> Sorry, I still cannot replicate. My 3.5 build still returns both results.
>> Maybe update to PostGIS 3.5.4 and GEOS 3.13.1 ?
>> P.
>>
>> On Wed, Oct 15, 2025 at 11:25?AM Antonio Valanzano <anvalanz at gmail.com>
>> wrote:
>>
>>> Here is the details of my installation:
>>>
>>> "postgis_full_version"
>>> "POSTGIS=""3.5.2 3.5.2"" [EXTENSION] PGSQL=""170""
>>> GEOS=""3.13.0-CAPI-1.19.0"" PROJ=""8.2.1 NETWORK_ENABLED=OFF URL_ENDPOINT=
>>> https://cdn.proj.org
>>> USER_WRITABLE_DIRECTORY=C:\Windows\ServiceProfiles\NetworkService\AppData\Local/proj
>>> DATABASE_PATH=C:\Program
>>> Files\PostgreSQL\17\share\contrib\postgis-3.5\proj\proj.db"" (compiled
>>> against PROJ 8.2.1) LIBXML=""2.12.5"" LIBJSON=""0.12""
>>> LIBPROTOBUF=""1.2.1"" WAGYU=""0.5.0 (Internal)"""
>>>
>>> Antonio
>>>
>>>
>>>
>>> Il giorno mer 15 ott 2025 alle ore 19:28 Paul Ramsey <
>>> pramsey at cleverelephant.ca> ha scritto:
>>>
>>>> Maybe you have found an old bug? Running exactly the same SQL as you, I
>>>> get two rows from each query.
>>>>
>>>> postgis=# SELECT
>>>>
>>>>                 d.id,
>>>>
>>>>                                ST_Relate(d.geom, l.geom) as patternMatrix
>>>>
>>>>                                       FROM docks as d, lakes as l
>>>>
>>>>                                                WHERE ST_Relate(d.geom,
>>>> l.geom, '1FF00F212');
>>>>  id | patternmatrix
>>>> ----+---------------
>>>>   1 | 1FF00F212
>>>>   2 | 1FF00F212
>>>> (2 rows)
>>>>
>>>> postgis=# SELECT
>>>> postgis-#   d.id,
>>>> postgis-#   ST_Relate(d.geom, l.geom) as patternMatrix
>>>> postgis-# FROM docks as d, lakes as l
>>>> postgis-# WHERE ST_Relate(d.geom, l.geom) = '1FF00F212';
>>>>  id | patternmatrix
>>>> ----+---------------
>>>>   1 | 1FF00F212
>>>>   2 | 1FF00F212
>>>> (2 rows)
>>>>
>>>> postgis=#
>>>> postgis=# select postgis_full_version();
>>>>
>>>>
>>>>
>>>>   postgis_full_version
>>>>
>>>>
>>>>
>>>>
>>>> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>>>  POSTGIS="3.7.0dev 3.6.0rc2-134-g5dc95f1bc" [EXTENSION] PGSQL="180"
>>>> GEOS="3.15.0dev-CAPI-1.21.0" PROJ="9.6.2 NETWORK_ENABLED=ON URL_ENDPOINT=
>>>> https://cdn.proj.org
>>>> USER_WRITABLE_DIRECTORY=/Users/pramsey/Library/Application Support/proj
>>>> DATABASE_PATH=/opt/homebrew/Cellar/proj/9.6.2/share/proj/proj.db" (compiled
>>>> against PROJ 9.6.2) LIBXML="2.9.13" LIBJSON="0.18" LIBPROTOBUF="1.5.2"
>>>> WAGYU="0.5.0 (Internal)" (core procs from "3.7.0dev
>>>> 3.6.0rc2-125-g747d7732b" need upgrade)
>>>>
>>>> On Wed, Oct 15, 2025 at 9:22?AM Antonio Valanzano <anvalanz at gmail.com>
>>>> wrote:
>>>>
>>>>> I am following the "Introduction to PostGIS " tutorial  at
>>>>> https://postgis.net/workshops/postgis-intro/
>>>>> and for chapter 26 "Dimensionally Extended 9-Intersection Model"  I
>>>>> am trying to replicate the examples.
>>>>>
>>>>> If I use the two different versions of ST_Relate I do not obtain the
>>>>> same result
>>>>>
>>>>> SELECT
>>>>>   d.id,
>>>>>   ST_Relate(d.geom, l.geom) as patternMatrix
>>>>> FROM docks as d, lakes as l
>>>>> WHERE ST_Relate(d.geom, l.geom, '1FF00F212') = true;
>>>>> -- 1 row
>>>>> "id" "patternmatrix"
>>>>> 1    "1FF00F212"
>>>>>
>>>>>
>>>>>
>>>>> SELECT
>>>>>   d.id,
>>>>>   ST_Relate(d.geom, l.geom) as patternMatrix
>>>>> FROM docks as d, lakes as l
>>>>> WHERE ST_Relate(d.geom, l.geom) = '1FF00F212';
>>>>> -- 2 rows
>>>>> "id" "patternmatrix"
>>>>> 1    "1FF00F212"
>>>>> 2    "1FF00F212"
>>>>>
>>>>> Could someone give me an explanation of such a difference ?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20251015/c55aa8be/attachment.htm>

From anvalanz at gmail.com  Wed Oct 15 13:29:20 2025
From: anvalanz at gmail.com (Antonio Valanzano)
Date: Wed, 15 Oct 2025 22:29:20 +0200
Subject: different results for ST_Relate with 3 parameters compared to
 those for ST_Relate with 2 parameters
In-Reply-To: <CACowWR0Wou-TvT3Moc4Pj2hNP6GVYoF7LYp=pQ=zXNMovKwhxw@mail.gmail.com>
References: <CANV1FQYH0T9im=NTOUEYic+V2VLkyet-L3ZvCADVkLf0n+DtqQ@mail.gmail.com>
 <CACowWR0QR5LiwjYmud-A1wHoJAdGNsrJu0836Rsco6Ro7NFaFw@mail.gmail.com>
 <CANV1FQZXc0k_aeiKjjGBOJ2OLEmBeyaOc60vv6taEEstKTN5Og@mail.gmail.com>
 <CACowWR2PhX5Z2a9gKNc6o28RhPoxroUPsSKEBNeO72uq+V5cvA@mail.gmail.com>
 <CANV1FQZk5q_uRpU8LvQZJrexyRaQa7RW87fzx5eLw0ufv7XYHw@mail.gmail.com>
 <CACowWR0Wou-TvT3Moc4Pj2hNP6GVYoF7LYp=pQ=zXNMovKwhxw@mail.gmail.com>
Message-ID: <CANV1FQZJHgs4D3y6pu7r2Zw3CikBYS+tuC8cT5hgWcmK4F13ag@mail.gmail.com>

Dear Paul
here are the results with the new linestrings as you suggested

SELECT
  d.id,
  ST_Relate(d.geom, l.geom) as patternMatrix
FROM docks as d, lakes as l
WHERE ST_Relate(d.geom, l.geom, '1FF00F212') = true;
-- 1 row

"id" "patternmatrix"
7 "1FF00F212"

SELECT
  d.id,
  ST_Relate(d.geom, l.geom) as patternMatrix
FROM docks as d, lakes as l
WHERE ST_Relate(d.geom, l.geom) = '1FF00F212';
-- 4 rows
"id" "patternmatrix"
7 "1FF00F212"
8 "1FF00F212"
12 "1FF00F212"
13 "1FF00F212"

As you can see nothing has changed.

I was wondering which version of PostGIS (and on which platform)  has been
used for producing the material reported into the tutorial (which shows 2
rows as a correct result).

I understand that it is difficult to find the reason for different results
on different platforms but this shouldn't happen otherwise users are
confused.. and not sure about the correct results.

When in the near future I will upgrade to PostgreSQL 18  and PostGIS 3.6.0
I will try again the same two queries  and let you know if the results will
be the same or not.
Thanks for the time you have spent on this matter.

Antonio


Il giorno mer 15 ott 2025 alle ore 22:03 Paul Ramsey <
pramsey at cleverelephant.ca> ha scritto:

>
>
> On Wed, Oct 15, 2025 at 12:53?PM Antonio Valanzano <anvalanz at gmail.com>
> wrote:
>
>> Hi Paul
>> I have upgraded to PosGIS 3.5.3 and GEOS  3.13.1 as you can see from the
>> following output
>>
>> "postgis_full_version"
>> "POSTGIS=""3.5.3 3.5.3"" [EXTENSION] PGSQL=""170""
>> GEOS=""3.13.1-CAPI-1.19.2"" PROJ=""8.2.1 NETWORK_ENABLED=OFF URL_ENDPOINT=
>> https://cdn.proj.org
>> USER_WRITABLE_DIRECTORY=C:\Windows\ServiceProfiles\NetworkService\AppData\Local/proj
>> DATABASE_PATH=C:\Program
>> Files\PostgreSQL\17\share\contrib\postgis-3.5\proj\proj.db"" (compiled
>> against PROJ 8.2.1) LIBXML=""2.12.5"" LIBJSON=""0.12""
>> LIBPROTOBUF=""1.2.1"" WAGYU=""0.5.0 (Internal)"" (core procs from ""3.5.2
>> 3.5.2"" need upgrade)"
>>
>> but the results are the same with one row for a query and 2 rows for the
>> other query.
>>
>> Is this a known bug or no other user has already reported this behaviour ?
>>
>
> Not reported, and I'm afraid not solvable unless you can figure out the
> specific thing about your install vs mine that is giving you a different
> answer. (Windows is one possibility, though not one I particularly like,
> platform differences are incredibly hard to isolate.)
>
> Seeing if the problem is ordering based and number of entries based might
> be interesting.
>
> DELETE FROM docsk;
> INSERT INTO docks ( geom, good )
>   VALUES
>         ('LINESTRING (170 290, 205 272)',true),
>         ('LINESTRING (120 215, 176 197)',true),
>         ('LINESTRING (290 260, 340 250)',false),
>         ('LINESTRING (350 300, 400 320)',false),
>         ('LINESTRING (370 230, 420 240)',false),
>         ('LINESTRING (170 290, 205 272)',true),
>         ('LINESTRING (120 215, 176 197)',true),
>         ('LINESTRING (370 180, 390 160)',false);
>
> P
>
>
>> Antonio
>>
>>
>>
>>
>> Il giorno mer 15 ott 2025 alle ore 20:59 Paul Ramsey <
>> pramsey at cleverelephant.ca> ha scritto:
>>
>>> Sorry, I still cannot replicate. My 3.5 build still returns both
>>> results. Maybe update to PostGIS 3.5.4 and GEOS 3.13.1 ?
>>> P.
>>>
>>> On Wed, Oct 15, 2025 at 11:25?AM Antonio Valanzano <anvalanz at gmail.com>
>>> wrote:
>>>
>>>> Here is the details of my installation:
>>>>
>>>> "postgis_full_version"
>>>> "POSTGIS=""3.5.2 3.5.2"" [EXTENSION] PGSQL=""170""
>>>> GEOS=""3.13.0-CAPI-1.19.0"" PROJ=""8.2.1 NETWORK_ENABLED=OFF URL_ENDPOINT=
>>>> https://cdn.proj.org
>>>> USER_WRITABLE_DIRECTORY=C:\Windows\ServiceProfiles\NetworkService\AppData\Local/proj
>>>> DATABASE_PATH=C:\Program
>>>> Files\PostgreSQL\17\share\contrib\postgis-3.5\proj\proj.db"" (compiled
>>>> against PROJ 8.2.1) LIBXML=""2.12.5"" LIBJSON=""0.12""
>>>> LIBPROTOBUF=""1.2.1"" WAGYU=""0.5.0 (Internal)"""
>>>>
>>>> Antonio
>>>>
>>>>
>>>>
>>>> Il giorno mer 15 ott 2025 alle ore 19:28 Paul Ramsey <
>>>> pramsey at cleverelephant.ca> ha scritto:
>>>>
>>>>> Maybe you have found an old bug? Running exactly the same SQL as you,
>>>>> I get two rows from each query.
>>>>>
>>>>> postgis=# SELECT
>>>>>
>>>>>                 d.id,
>>>>>
>>>>>                                ST_Relate(d.geom, l.geom) as patternMatrix
>>>>>
>>>>>                                       FROM docks as d, lakes as l
>>>>>
>>>>>                                                WHERE ST_Relate(d.geom,
>>>>> l.geom, '1FF00F212');
>>>>>  id | patternmatrix
>>>>> ----+---------------
>>>>>   1 | 1FF00F212
>>>>>   2 | 1FF00F212
>>>>> (2 rows)
>>>>>
>>>>> postgis=# SELECT
>>>>> postgis-#   d.id,
>>>>> postgis-#   ST_Relate(d.geom, l.geom) as patternMatrix
>>>>> postgis-# FROM docks as d, lakes as l
>>>>> postgis-# WHERE ST_Relate(d.geom, l.geom) = '1FF00F212';
>>>>>  id | patternmatrix
>>>>> ----+---------------
>>>>>   1 | 1FF00F212
>>>>>   2 | 1FF00F212
>>>>> (2 rows)
>>>>>
>>>>> postgis=#
>>>>> postgis=# select postgis_full_version();
>>>>>
>>>>>
>>>>>
>>>>>     postgis_full_version
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>>>>  POSTGIS="3.7.0dev 3.6.0rc2-134-g5dc95f1bc" [EXTENSION] PGSQL="180"
>>>>> GEOS="3.15.0dev-CAPI-1.21.0" PROJ="9.6.2 NETWORK_ENABLED=ON URL_ENDPOINT=
>>>>> https://cdn.proj.org
>>>>> USER_WRITABLE_DIRECTORY=/Users/pramsey/Library/Application Support/proj
>>>>> DATABASE_PATH=/opt/homebrew/Cellar/proj/9.6.2/share/proj/proj.db" (compiled
>>>>> against PROJ 9.6.2) LIBXML="2.9.13" LIBJSON="0.18" LIBPROTOBUF="1.5.2"
>>>>> WAGYU="0.5.0 (Internal)" (core procs from "3.7.0dev
>>>>> 3.6.0rc2-125-g747d7732b" need upgrade)
>>>>>
>>>>> On Wed, Oct 15, 2025 at 9:22?AM Antonio Valanzano <anvalanz at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> I am following the "Introduction to PostGIS " tutorial  at
>>>>>> https://postgis.net/workshops/postgis-intro/
>>>>>> and for chapter 26 "Dimensionally Extended 9-Intersection Model"  I
>>>>>> am trying to replicate the examples.
>>>>>>
>>>>>> If I use the two different versions of ST_Relate I do not obtain the
>>>>>> same result
>>>>>>
>>>>>> SELECT
>>>>>>   d.id,
>>>>>>   ST_Relate(d.geom, l.geom) as patternMatrix
>>>>>> FROM docks as d, lakes as l
>>>>>> WHERE ST_Relate(d.geom, l.geom, '1FF00F212') = true;
>>>>>> -- 1 row
>>>>>> "id" "patternmatrix"
>>>>>> 1    "1FF00F212"
>>>>>>
>>>>>>
>>>>>>
>>>>>> SELECT
>>>>>>   d.id,
>>>>>>   ST_Relate(d.geom, l.geom) as patternMatrix
>>>>>> FROM docks as d, lakes as l
>>>>>> WHERE ST_Relate(d.geom, l.geom) = '1FF00F212';
>>>>>> -- 2 rows
>>>>>> "id" "patternmatrix"
>>>>>> 1    "1FF00F212"
>>>>>> 2    "1FF00F212"
>>>>>>
>>>>>> Could someone give me an explanation of such a difference ?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20251015/7fb85d7d/attachment.htm>

From pramsey at cleverelephant.ca  Wed Oct 15 14:22:03 2025
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Wed, 15 Oct 2025 14:22:03 -0700
Subject: different results for ST_Relate with 3 parameters compared to
 those for ST_Relate with 2 parameters
In-Reply-To: <CANV1FQZJHgs4D3y6pu7r2Zw3CikBYS+tuC8cT5hgWcmK4F13ag@mail.gmail.com>
References: <CANV1FQYH0T9im=NTOUEYic+V2VLkyet-L3ZvCADVkLf0n+DtqQ@mail.gmail.com>
 <CACowWR0QR5LiwjYmud-A1wHoJAdGNsrJu0836Rsco6Ro7NFaFw@mail.gmail.com>
 <CANV1FQZXc0k_aeiKjjGBOJ2OLEmBeyaOc60vv6taEEstKTN5Og@mail.gmail.com>
 <CACowWR2PhX5Z2a9gKNc6o28RhPoxroUPsSKEBNeO72uq+V5cvA@mail.gmail.com>
 <CANV1FQZk5q_uRpU8LvQZJrexyRaQa7RW87fzx5eLw0ufv7XYHw@mail.gmail.com>
 <CACowWR0Wou-TvT3Moc4Pj2hNP6GVYoF7LYp=pQ=zXNMovKwhxw@mail.gmail.com>
 <CANV1FQZJHgs4D3y6pu7r2Zw3CikBYS+tuC8cT5hgWcmK4F13ag@mail.gmail.com>
Message-ID: <CACowWR0+XZgSXSbQv7t5bi+AQ8TraLD8M7c6OQT78gHo3N3C3w@mail.gmail.com>

Thanks for continuing to try stuff. What does this example return?

SELECT
ST_Relate(a.geom, b.geom), ST_Relate(a.geom, b.geom, '1FF00F212')
FROM
(VALUES ('LINESTRING (170 290, 205 272)'),('LINESTRING (120 215, 176
197)')) AS a(geom),
(VALUES ('POLYGON ((100 200, 140 230, 180 310, 280 310, 390 270, 400 210,
320 140, 215 141, 150 170, 100 200))')) AS b(geom);


On Wed, Oct 15, 2025 at 1:29?PM Antonio Valanzano <anvalanz at gmail.com>
wrote:

> Dear Paul
> here are the results with the new linestrings as you suggested
>
> SELECT
>   d.id,
>   ST_Relate(d.geom, l.geom) as patternMatrix
> FROM docks as d, lakes as l
> WHERE ST_Relate(d.geom, l.geom, '1FF00F212') = true;
> -- 1 row
>
> "id" "patternmatrix"
> 7 "1FF00F212"
>
> SELECT
>   d.id,
>   ST_Relate(d.geom, l.geom) as patternMatrix
> FROM docks as d, lakes as l
> WHERE ST_Relate(d.geom, l.geom) = '1FF00F212';
> -- 4 rows
> "id" "patternmatrix"
> 7 "1FF00F212"
> 8 "1FF00F212"
> 12 "1FF00F212"
> 13 "1FF00F212"
>
> As you can see nothing has changed.
>
> I was wondering which version of PostGIS (and on which platform)  has been
> used for producing the material reported into the tutorial (which shows 2
> rows as a correct result).
>
> I understand that it is difficult to find the reason for different results
> on different platforms but this shouldn't happen otherwise users are
> confused.. and not sure about the correct results.
>
> When in the near future I will upgrade to PostgreSQL 18  and PostGIS 3.6.0
> I will try again the same two queries  and let you know if the results will
> be the same or not.
> Thanks for the time you have spent on this matter.
>
> Antonio
>
>
> Il giorno mer 15 ott 2025 alle ore 22:03 Paul Ramsey <
> pramsey at cleverelephant.ca> ha scritto:
>
>>
>>
>> On Wed, Oct 15, 2025 at 12:53?PM Antonio Valanzano <anvalanz at gmail.com>
>> wrote:
>>
>>> Hi Paul
>>> I have upgraded to PosGIS 3.5.3 and GEOS  3.13.1 as you can see from the
>>> following output
>>>
>>> "postgis_full_version"
>>> "POSTGIS=""3.5.3 3.5.3"" [EXTENSION] PGSQL=""170""
>>> GEOS=""3.13.1-CAPI-1.19.2"" PROJ=""8.2.1 NETWORK_ENABLED=OFF URL_ENDPOINT=
>>> https://cdn.proj.org
>>> USER_WRITABLE_DIRECTORY=C:\Windows\ServiceProfiles\NetworkService\AppData\Local/proj
>>> DATABASE_PATH=C:\Program
>>> Files\PostgreSQL\17\share\contrib\postgis-3.5\proj\proj.db"" (compiled
>>> against PROJ 8.2.1) LIBXML=""2.12.5"" LIBJSON=""0.12""
>>> LIBPROTOBUF=""1.2.1"" WAGYU=""0.5.0 (Internal)"" (core procs from ""3.5.2
>>> 3.5.2"" need upgrade)"
>>>
>>> but the results are the same with one row for a query and 2 rows for the
>>> other query.
>>>
>>> Is this a known bug or no other user has already reported this behaviour
>>> ?
>>>
>>
>> Not reported, and I'm afraid not solvable unless you can figure out the
>> specific thing about your install vs mine that is giving you a different
>> answer. (Windows is one possibility, though not one I particularly like,
>> platform differences are incredibly hard to isolate.)
>>
>> Seeing if the problem is ordering based and number of entries based might
>> be interesting.
>>
>> DELETE FROM docsk;
>> INSERT INTO docks ( geom, good )
>>   VALUES
>>         ('LINESTRING (170 290, 205 272)',true),
>>         ('LINESTRING (120 215, 176 197)',true),
>>         ('LINESTRING (290 260, 340 250)',false),
>>         ('LINESTRING (350 300, 400 320)',false),
>>         ('LINESTRING (370 230, 420 240)',false),
>>         ('LINESTRING (170 290, 205 272)',true),
>>         ('LINESTRING (120 215, 176 197)',true),
>>         ('LINESTRING (370 180, 390 160)',false);
>>
>> P
>>
>>
>>> Antonio
>>>
>>>
>>>
>>>
>>> Il giorno mer 15 ott 2025 alle ore 20:59 Paul Ramsey <
>>> pramsey at cleverelephant.ca> ha scritto:
>>>
>>>> Sorry, I still cannot replicate. My 3.5 build still returns both
>>>> results. Maybe update to PostGIS 3.5.4 and GEOS 3.13.1 ?
>>>> P.
>>>>
>>>> On Wed, Oct 15, 2025 at 11:25?AM Antonio Valanzano <anvalanz at gmail.com>
>>>> wrote:
>>>>
>>>>> Here is the details of my installation:
>>>>>
>>>>> "postgis_full_version"
>>>>> "POSTGIS=""3.5.2 3.5.2"" [EXTENSION] PGSQL=""170""
>>>>> GEOS=""3.13.0-CAPI-1.19.0"" PROJ=""8.2.1 NETWORK_ENABLED=OFF URL_ENDPOINT=
>>>>> https://cdn.proj.org
>>>>> USER_WRITABLE_DIRECTORY=C:\Windows\ServiceProfiles\NetworkService\AppData\Local/proj
>>>>> DATABASE_PATH=C:\Program
>>>>> Files\PostgreSQL\17\share\contrib\postgis-3.5\proj\proj.db"" (compiled
>>>>> against PROJ 8.2.1) LIBXML=""2.12.5"" LIBJSON=""0.12""
>>>>> LIBPROTOBUF=""1.2.1"" WAGYU=""0.5.0 (Internal)"""
>>>>>
>>>>> Antonio
>>>>>
>>>>>
>>>>>
>>>>> Il giorno mer 15 ott 2025 alle ore 19:28 Paul Ramsey <
>>>>> pramsey at cleverelephant.ca> ha scritto:
>>>>>
>>>>>> Maybe you have found an old bug? Running exactly the same SQL as you,
>>>>>> I get two rows from each query.
>>>>>>
>>>>>> postgis=# SELECT
>>>>>>
>>>>>>                   d.id,
>>>>>>
>>>>>>                                    ST_Relate(d.geom, l.geom) as
>>>>>> patternMatrix
>>>>>>                                                       FROM docks as d,
>>>>>> lakes as l
>>>>>>                                                                      WHERE
>>>>>> ST_Relate(d.geom, l.geom, '1FF00F212');
>>>>>>  id | patternmatrix
>>>>>> ----+---------------
>>>>>>   1 | 1FF00F212
>>>>>>   2 | 1FF00F212
>>>>>> (2 rows)
>>>>>>
>>>>>> postgis=# SELECT
>>>>>> postgis-#   d.id,
>>>>>> postgis-#   ST_Relate(d.geom, l.geom) as patternMatrix
>>>>>> postgis-# FROM docks as d, lakes as l
>>>>>> postgis-# WHERE ST_Relate(d.geom, l.geom) = '1FF00F212';
>>>>>>  id | patternmatrix
>>>>>> ----+---------------
>>>>>>   1 | 1FF00F212
>>>>>>   2 | 1FF00F212
>>>>>> (2 rows)
>>>>>>
>>>>>> postgis=#
>>>>>> postgis=# select postgis_full_version();
>>>>>>
>>>>>>
>>>>>>
>>>>>>     postgis_full_version
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>>>>>  POSTGIS="3.7.0dev 3.6.0rc2-134-g5dc95f1bc" [EXTENSION] PGSQL="180"
>>>>>> GEOS="3.15.0dev-CAPI-1.21.0" PROJ="9.6.2 NETWORK_ENABLED=ON URL_ENDPOINT=
>>>>>> https://cdn.proj.org
>>>>>> USER_WRITABLE_DIRECTORY=/Users/pramsey/Library/Application Support/proj
>>>>>> DATABASE_PATH=/opt/homebrew/Cellar/proj/9.6.2/share/proj/proj.db" (compiled
>>>>>> against PROJ 9.6.2) LIBXML="2.9.13" LIBJSON="0.18" LIBPROTOBUF="1.5.2"
>>>>>> WAGYU="0.5.0 (Internal)" (core procs from "3.7.0dev
>>>>>> 3.6.0rc2-125-g747d7732b" need upgrade)
>>>>>>
>>>>>> On Wed, Oct 15, 2025 at 9:22?AM Antonio Valanzano <anvalanz at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I am following the "Introduction to PostGIS " tutorial  at
>>>>>>> https://postgis.net/workshops/postgis-intro/
>>>>>>> and for chapter 26 "Dimensionally Extended 9-Intersection Model"  I
>>>>>>> am trying to replicate the examples.
>>>>>>>
>>>>>>> If I use the two different versions of ST_Relate I do not obtain the
>>>>>>> same result
>>>>>>>
>>>>>>> SELECT
>>>>>>>   d.id,
>>>>>>>   ST_Relate(d.geom, l.geom) as patternMatrix
>>>>>>> FROM docks as d, lakes as l
>>>>>>> WHERE ST_Relate(d.geom, l.geom, '1FF00F212') = true;
>>>>>>> -- 1 row
>>>>>>> "id" "patternmatrix"
>>>>>>> 1    "1FF00F212"
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> SELECT
>>>>>>>   d.id,
>>>>>>>   ST_Relate(d.geom, l.geom) as patternMatrix
>>>>>>> FROM docks as d, lakes as l
>>>>>>> WHERE ST_Relate(d.geom, l.geom) = '1FF00F212';
>>>>>>> -- 2 rows
>>>>>>> "id" "patternmatrix"
>>>>>>> 1    "1FF00F212"
>>>>>>> 2    "1FF00F212"
>>>>>>>
>>>>>>> Could someone give me an explanation of such a difference ?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20251015/6c7dc0e1/attachment.htm>

From anvalanz at gmail.com  Wed Oct 15 15:11:11 2025
From: anvalanz at gmail.com (Antonio Valanzano)
Date: Thu, 16 Oct 2025 00:11:11 +0200
Subject: different results for ST_Relate with 3 parameters compared to
 those for ST_Relate with 2 parameters
In-Reply-To: <CACowWR0+XZgSXSbQv7t5bi+AQ8TraLD8M7c6OQT78gHo3N3C3w@mail.gmail.com>
References: <CANV1FQYH0T9im=NTOUEYic+V2VLkyet-L3ZvCADVkLf0n+DtqQ@mail.gmail.com>
 <CACowWR0QR5LiwjYmud-A1wHoJAdGNsrJu0836Rsco6Ro7NFaFw@mail.gmail.com>
 <CANV1FQZXc0k_aeiKjjGBOJ2OLEmBeyaOc60vv6taEEstKTN5Og@mail.gmail.com>
 <CACowWR2PhX5Z2a9gKNc6o28RhPoxroUPsSKEBNeO72uq+V5cvA@mail.gmail.com>
 <CANV1FQZk5q_uRpU8LvQZJrexyRaQa7RW87fzx5eLw0ufv7XYHw@mail.gmail.com>
 <CACowWR0Wou-TvT3Moc4Pj2hNP6GVYoF7LYp=pQ=zXNMovKwhxw@mail.gmail.com>
 <CANV1FQZJHgs4D3y6pu7r2Zw3CikBYS+tuC8cT5hgWcmK4F13ag@mail.gmail.com>
 <CACowWR0+XZgSXSbQv7t5bi+AQ8TraLD8M7c6OQT78gHo3N3C3w@mail.gmail.com>
Message-ID: <CANV1FQZ_NG0ZFft5oGwjV5rW0=oqJFPLgPnpACaEtmyX2TqXWA@mail.gmail.com>

Here are the results

SELECT
  ST_Relate(a.geom, b.geom),
  ST_Relate(a.geom, b.geom, '1FF00F212')
FROM
(VALUES ('LINESTRING (170 290, 205 272)'),('LINESTRING (120 215, 176
197)')) AS a(geom),
(VALUES ('POLYGON ((100 200, 140 230, 180 310, 280 310, 390 270, 400 210,
320 140, 215 141, 150 170, 100 200))')) AS b(geom);
-- 2 rows
"st_relate" "st_relate-2"
"1FF00F212" true
"1FF00F212" false

Il giorno mer 15 ott 2025 alle ore 23:22 Paul Ramsey <
pramsey at cleverelephant.ca> ha scritto:

> Thanks for continuing to try stuff. What does this example return?
>
> SELECT
> ST_Relate(a.geom, b.geom), ST_Relate(a.geom, b.geom, '1FF00F212')
> FROM
> (VALUES ('LINESTRING (170 290, 205 272)'),('LINESTRING (120 215, 176
> 197)')) AS a(geom),
> (VALUES ('POLYGON ((100 200, 140 230, 180 310, 280 310, 390 270, 400 210,
> 320 140, 215 141, 150 170, 100 200))')) AS b(geom);
>
>
> On Wed, Oct 15, 2025 at 1:29?PM Antonio Valanzano <anvalanz at gmail.com>
> wrote:
>
>> Dear Paul
>> here are the results with the new linestrings as you suggested
>>
>> SELECT
>>   d.id,
>>   ST_Relate(d.geom, l.geom) as patternMatrix
>> FROM docks as d, lakes as l
>> WHERE ST_Relate(d.geom, l.geom, '1FF00F212') = true;
>> -- 1 row
>>
>> "id" "patternmatrix"
>> 7 "1FF00F212"
>>
>> SELECT
>>   d.id,
>>   ST_Relate(d.geom, l.geom) as patternMatrix
>> FROM docks as d, lakes as l
>> WHERE ST_Relate(d.geom, l.geom) = '1FF00F212';
>> -- 4 rows
>> "id" "patternmatrix"
>> 7 "1FF00F212"
>> 8 "1FF00F212"
>> 12 "1FF00F212"
>> 13 "1FF00F212"
>>
>> As you can see nothing has changed.
>>
>> I was wondering which version of PostGIS (and on which platform)  has
>> been used for producing the material reported into the tutorial (which
>> shows 2 rows as a correct result).
>>
>> I understand that it is difficult to find the reason for different
>> results on different platforms but this shouldn't happen otherwise users
>> are confused.. and not sure about the correct results.
>>
>> When in the near future I will upgrade to PostgreSQL 18  and PostGIS
>> 3.6.0 I will try again the same two queries  and let you know if the
>> results will be the same or not.
>> Thanks for the time you have spent on this matter.
>>
>> Antonio
>>
>>
>> Il giorno mer 15 ott 2025 alle ore 22:03 Paul Ramsey <
>> pramsey at cleverelephant.ca> ha scritto:
>>
>>>
>>>
>>> On Wed, Oct 15, 2025 at 12:53?PM Antonio Valanzano <anvalanz at gmail.com>
>>> wrote:
>>>
>>>> Hi Paul
>>>> I have upgraded to PosGIS 3.5.3 and GEOS  3.13.1 as you can see from
>>>> the following output
>>>>
>>>> "postgis_full_version"
>>>> "POSTGIS=""3.5.3 3.5.3"" [EXTENSION] PGSQL=""170""
>>>> GEOS=""3.13.1-CAPI-1.19.2"" PROJ=""8.2.1 NETWORK_ENABLED=OFF URL_ENDPOINT=
>>>> https://cdn.proj.org
>>>> USER_WRITABLE_DIRECTORY=C:\Windows\ServiceProfiles\NetworkService\AppData\Local/proj
>>>> DATABASE_PATH=C:\Program
>>>> Files\PostgreSQL\17\share\contrib\postgis-3.5\proj\proj.db"" (compiled
>>>> against PROJ 8.2.1) LIBXML=""2.12.5"" LIBJSON=""0.12""
>>>> LIBPROTOBUF=""1.2.1"" WAGYU=""0.5.0 (Internal)"" (core procs from ""3.5.2
>>>> 3.5.2"" need upgrade)"
>>>>
>>>> but the results are the same with one row for a query and 2 rows for
>>>> the other query.
>>>>
>>>> Is this a known bug or no other user has already reported this
>>>> behaviour ?
>>>>
>>>
>>> Not reported, and I'm afraid not solvable unless you can figure out the
>>> specific thing about your install vs mine that is giving you a different
>>> answer. (Windows is one possibility, though not one I particularly like,
>>> platform differences are incredibly hard to isolate.)
>>>
>>> Seeing if the problem is ordering based and number of entries based
>>> might be interesting.
>>>
>>> DELETE FROM docsk;
>>> INSERT INTO docks ( geom, good )
>>>   VALUES
>>>         ('LINESTRING (170 290, 205 272)',true),
>>>         ('LINESTRING (120 215, 176 197)',true),
>>>         ('LINESTRING (290 260, 340 250)',false),
>>>         ('LINESTRING (350 300, 400 320)',false),
>>>         ('LINESTRING (370 230, 420 240)',false),
>>>         ('LINESTRING (170 290, 205 272)',true),
>>>         ('LINESTRING (120 215, 176 197)',true),
>>>         ('LINESTRING (370 180, 390 160)',false);
>>>
>>> P
>>>
>>>
>>>> Antonio
>>>>
>>>>
>>>>
>>>>
>>>> Il giorno mer 15 ott 2025 alle ore 20:59 Paul Ramsey <
>>>> pramsey at cleverelephant.ca> ha scritto:
>>>>
>>>>> Sorry, I still cannot replicate. My 3.5 build still returns both
>>>>> results. Maybe update to PostGIS 3.5.4 and GEOS 3.13.1 ?
>>>>> P.
>>>>>
>>>>> On Wed, Oct 15, 2025 at 11:25?AM Antonio Valanzano <anvalanz at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Here is the details of my installation:
>>>>>>
>>>>>> "postgis_full_version"
>>>>>> "POSTGIS=""3.5.2 3.5.2"" [EXTENSION] PGSQL=""170""
>>>>>> GEOS=""3.13.0-CAPI-1.19.0"" PROJ=""8.2.1 NETWORK_ENABLED=OFF URL_ENDPOINT=
>>>>>> https://cdn.proj.org
>>>>>> USER_WRITABLE_DIRECTORY=C:\Windows\ServiceProfiles\NetworkService\AppData\Local/proj
>>>>>> DATABASE_PATH=C:\Program
>>>>>> Files\PostgreSQL\17\share\contrib\postgis-3.5\proj\proj.db"" (compiled
>>>>>> against PROJ 8.2.1) LIBXML=""2.12.5"" LIBJSON=""0.12""
>>>>>> LIBPROTOBUF=""1.2.1"" WAGYU=""0.5.0 (Internal)"""
>>>>>>
>>>>>> Antonio
>>>>>>
>>>>>>
>>>>>>
>>>>>> Il giorno mer 15 ott 2025 alle ore 19:28 Paul Ramsey <
>>>>>> pramsey at cleverelephant.ca> ha scritto:
>>>>>>
>>>>>>> Maybe you have found an old bug? Running exactly the same SQL as
>>>>>>> you, I get two rows from each query.
>>>>>>>
>>>>>>> postgis=# SELECT
>>>>>>>
>>>>>>>                   d.id,
>>>>>>>
>>>>>>>                                    ST_Relate(d.geom, l.geom) as
>>>>>>> patternMatrix
>>>>>>>                                                       FROM docks as d,
>>>>>>> lakes as l
>>>>>>>                                                                      WHERE
>>>>>>> ST_Relate(d.geom, l.geom, '1FF00F212');
>>>>>>>  id | patternmatrix
>>>>>>> ----+---------------
>>>>>>>   1 | 1FF00F212
>>>>>>>   2 | 1FF00F212
>>>>>>> (2 rows)
>>>>>>>
>>>>>>> postgis=# SELECT
>>>>>>> postgis-#   d.id,
>>>>>>> postgis-#   ST_Relate(d.geom, l.geom) as patternMatrix
>>>>>>> postgis-# FROM docks as d, lakes as l
>>>>>>> postgis-# WHERE ST_Relate(d.geom, l.geom) = '1FF00F212';
>>>>>>>  id | patternmatrix
>>>>>>> ----+---------------
>>>>>>>   1 | 1FF00F212
>>>>>>>   2 | 1FF00F212
>>>>>>> (2 rows)
>>>>>>>
>>>>>>> postgis=#
>>>>>>> postgis=# select postgis_full_version();
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>       postgis_full_version
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>>>>>>  POSTGIS="3.7.0dev 3.6.0rc2-134-g5dc95f1bc" [EXTENSION] PGSQL="180"
>>>>>>> GEOS="3.15.0dev-CAPI-1.21.0" PROJ="9.6.2 NETWORK_ENABLED=ON URL_ENDPOINT=
>>>>>>> https://cdn.proj.org
>>>>>>> USER_WRITABLE_DIRECTORY=/Users/pramsey/Library/Application Support/proj
>>>>>>> DATABASE_PATH=/opt/homebrew/Cellar/proj/9.6.2/share/proj/proj.db" (compiled
>>>>>>> against PROJ 9.6.2) LIBXML="2.9.13" LIBJSON="0.18" LIBPROTOBUF="1.5.2"
>>>>>>> WAGYU="0.5.0 (Internal)" (core procs from "3.7.0dev
>>>>>>> 3.6.0rc2-125-g747d7732b" need upgrade)
>>>>>>>
>>>>>>> On Wed, Oct 15, 2025 at 9:22?AM Antonio Valanzano <
>>>>>>> anvalanz at gmail.com> wrote:
>>>>>>>
>>>>>>>> I am following the "Introduction to PostGIS " tutorial  at
>>>>>>>> https://postgis.net/workshops/postgis-intro/
>>>>>>>> and for chapter 26 "Dimensionally Extended 9-Intersection Model"
>>>>>>>> I am trying to replicate the examples.
>>>>>>>>
>>>>>>>> If I use the two different versions of ST_Relate I do not obtain
>>>>>>>> the same result
>>>>>>>>
>>>>>>>> SELECT
>>>>>>>>   d.id,
>>>>>>>>   ST_Relate(d.geom, l.geom) as patternMatrix
>>>>>>>> FROM docks as d, lakes as l
>>>>>>>> WHERE ST_Relate(d.geom, l.geom, '1FF00F212') = true;
>>>>>>>> -- 1 row
>>>>>>>> "id" "patternmatrix"
>>>>>>>> 1    "1FF00F212"
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> SELECT
>>>>>>>>   d.id,
>>>>>>>>   ST_Relate(d.geom, l.geom) as patternMatrix
>>>>>>>> FROM docks as d, lakes as l
>>>>>>>> WHERE ST_Relate(d.geom, l.geom) = '1FF00F212';
>>>>>>>> -- 2 rows
>>>>>>>> "id" "patternmatrix"
>>>>>>>> 1    "1FF00F212"
>>>>>>>> 2    "1FF00F212"
>>>>>>>>
>>>>>>>> Could someone give me an explanation of such a difference ?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20251016/92a5ee6a/attachment.htm>

From pramsey at cleverelephant.ca  Wed Oct 15 15:31:36 2025
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Wed, 15 Oct 2025 15:31:36 -0700
Subject: different results for ST_Relate with 3 parameters compared to
 those for ST_Relate with 2 parameters
In-Reply-To: <CANV1FQZ_NG0ZFft5oGwjV5rW0=oqJFPLgPnpACaEtmyX2TqXWA@mail.gmail.com>
References: <CANV1FQYH0T9im=NTOUEYic+V2VLkyet-L3ZvCADVkLf0n+DtqQ@mail.gmail.com>
 <CACowWR0QR5LiwjYmud-A1wHoJAdGNsrJu0836Rsco6Ro7NFaFw@mail.gmail.com>
 <CANV1FQZXc0k_aeiKjjGBOJ2OLEmBeyaOc60vv6taEEstKTN5Og@mail.gmail.com>
 <CACowWR2PhX5Z2a9gKNc6o28RhPoxroUPsSKEBNeO72uq+V5cvA@mail.gmail.com>
 <CANV1FQZk5q_uRpU8LvQZJrexyRaQa7RW87fzx5eLw0ufv7XYHw@mail.gmail.com>
 <CACowWR0Wou-TvT3Moc4Pj2hNP6GVYoF7LYp=pQ=zXNMovKwhxw@mail.gmail.com>
 <CANV1FQZJHgs4D3y6pu7r2Zw3CikBYS+tuC8cT5hgWcmK4F13ag@mail.gmail.com>
 <CACowWR0+XZgSXSbQv7t5bi+AQ8TraLD8M7c6OQT78gHo3N3C3w@mail.gmail.com>
 <CANV1FQZ_NG0ZFft5oGwjV5rW0=oqJFPLgPnpACaEtmyX2TqXWA@mail.gmail.com>
Message-ID: <CACowWR0ix64TnRLSwKutd==AW429S5tKmCu9a9NkKYbzWDe0pw@mail.gmail.com>

One more sorry!

SELECT
ST_Relate(a.geom, b.geom), ST_Relate(a.geom, b.geom, '1FF00F212')
FROM
(VALUES
  ('LINESTRING (170 290, 205 272)'),
  ('LINESTRING (120 215, 176 197)'),
  ('LINESTRING (170 290, 205 272)'),
  ('LINESTRING (120 215, 176 197)')) AS a(geom),
(VALUES ('POLYGON ((100 200, 140 230, 180 310, 280 310, 390 270, 400 210,
320 140, 215 141, 150 170, 100 200))')) AS b(geom);

On Wed, Oct 15, 2025 at 3:11?PM Antonio Valanzano <anvalanz at gmail.com>
wrote:

> Here are the results
>
> SELECT
>   ST_Relate(a.geom, b.geom),
>   ST_Relate(a.geom, b.geom, '1FF00F212')
> FROM
> (VALUES ('LINESTRING (170 290, 205 272)'),('LINESTRING (120 215, 176
> 197)')) AS a(geom),
> (VALUES ('POLYGON ((100 200, 140 230, 180 310, 280 310, 390 270, 400 210,
> 320 140, 215 141, 150 170, 100 200))')) AS b(geom);
> -- 2 rows
> "st_relate" "st_relate-2"
> "1FF00F212" true
> "1FF00F212" false
>
> Il giorno mer 15 ott 2025 alle ore 23:22 Paul Ramsey <
> pramsey at cleverelephant.ca> ha scritto:
>
>> Thanks for continuing to try stuff. What does this example return?
>>
>> SELECT
>> ST_Relate(a.geom, b.geom), ST_Relate(a.geom, b.geom, '1FF00F212')
>> FROM
>> (VALUES ('LINESTRING (170 290, 205 272)'),('LINESTRING (120 215, 176
>> 197)')) AS a(geom),
>> (VALUES ('POLYGON ((100 200, 140 230, 180 310, 280 310, 390 270, 400 210,
>> 320 140, 215 141, 150 170, 100 200))')) AS b(geom);
>>
>>
>> On Wed, Oct 15, 2025 at 1:29?PM Antonio Valanzano <anvalanz at gmail.com>
>> wrote:
>>
>>> Dear Paul
>>> here are the results with the new linestrings as you suggested
>>>
>>> SELECT
>>>   d.id,
>>>   ST_Relate(d.geom, l.geom) as patternMatrix
>>> FROM docks as d, lakes as l
>>> WHERE ST_Relate(d.geom, l.geom, '1FF00F212') = true;
>>> -- 1 row
>>>
>>> "id" "patternmatrix"
>>> 7 "1FF00F212"
>>>
>>> SELECT
>>>   d.id,
>>>   ST_Relate(d.geom, l.geom) as patternMatrix
>>> FROM docks as d, lakes as l
>>> WHERE ST_Relate(d.geom, l.geom) = '1FF00F212';
>>> -- 4 rows
>>> "id" "patternmatrix"
>>> 7 "1FF00F212"
>>> 8 "1FF00F212"
>>> 12 "1FF00F212"
>>> 13 "1FF00F212"
>>>
>>> As you can see nothing has changed.
>>>
>>> I was wondering which version of PostGIS (and on which platform)  has
>>> been used for producing the material reported into the tutorial (which
>>> shows 2 rows as a correct result).
>>>
>>> I understand that it is difficult to find the reason for different
>>> results on different platforms but this shouldn't happen otherwise users
>>> are confused.. and not sure about the correct results.
>>>
>>> When in the near future I will upgrade to PostgreSQL 18  and PostGIS
>>> 3.6.0 I will try again the same two queries  and let you know if the
>>> results will be the same or not.
>>> Thanks for the time you have spent on this matter.
>>>
>>> Antonio
>>>
>>>
>>> Il giorno mer 15 ott 2025 alle ore 22:03 Paul Ramsey <
>>> pramsey at cleverelephant.ca> ha scritto:
>>>
>>>>
>>>>
>>>> On Wed, Oct 15, 2025 at 12:53?PM Antonio Valanzano <anvalanz at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Paul
>>>>> I have upgraded to PosGIS 3.5.3 and GEOS  3.13.1 as you can see from
>>>>> the following output
>>>>>
>>>>> "postgis_full_version"
>>>>> "POSTGIS=""3.5.3 3.5.3"" [EXTENSION] PGSQL=""170""
>>>>> GEOS=""3.13.1-CAPI-1.19.2"" PROJ=""8.2.1 NETWORK_ENABLED=OFF URL_ENDPOINT=
>>>>> https://cdn.proj.org
>>>>> USER_WRITABLE_DIRECTORY=C:\Windows\ServiceProfiles\NetworkService\AppData\Local/proj
>>>>> DATABASE_PATH=C:\Program
>>>>> Files\PostgreSQL\17\share\contrib\postgis-3.5\proj\proj.db"" (compiled
>>>>> against PROJ 8.2.1) LIBXML=""2.12.5"" LIBJSON=""0.12""
>>>>> LIBPROTOBUF=""1.2.1"" WAGYU=""0.5.0 (Internal)"" (core procs from ""3.5.2
>>>>> 3.5.2"" need upgrade)"
>>>>>
>>>>> but the results are the same with one row for a query and 2 rows for
>>>>> the other query.
>>>>>
>>>>> Is this a known bug or no other user has already reported this
>>>>> behaviour ?
>>>>>
>>>>
>>>> Not reported, and I'm afraid not solvable unless you can figure out the
>>>> specific thing about your install vs mine that is giving you a different
>>>> answer. (Windows is one possibility, though not one I particularly like,
>>>> platform differences are incredibly hard to isolate.)
>>>>
>>>> Seeing if the problem is ordering based and number of entries based
>>>> might be interesting.
>>>>
>>>> DELETE FROM docsk;
>>>> INSERT INTO docks ( geom, good )
>>>>   VALUES
>>>>         ('LINESTRING (170 290, 205 272)',true),
>>>>         ('LINESTRING (120 215, 176 197)',true),
>>>>         ('LINESTRING (290 260, 340 250)',false),
>>>>         ('LINESTRING (350 300, 400 320)',false),
>>>>         ('LINESTRING (370 230, 420 240)',false),
>>>>         ('LINESTRING (170 290, 205 272)',true),
>>>>         ('LINESTRING (120 215, 176 197)',true),
>>>>         ('LINESTRING (370 180, 390 160)',false);
>>>>
>>>> P
>>>>
>>>>
>>>>> Antonio
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Il giorno mer 15 ott 2025 alle ore 20:59 Paul Ramsey <
>>>>> pramsey at cleverelephant.ca> ha scritto:
>>>>>
>>>>>> Sorry, I still cannot replicate. My 3.5 build still returns both
>>>>>> results. Maybe update to PostGIS 3.5.4 and GEOS 3.13.1 ?
>>>>>> P.
>>>>>>
>>>>>> On Wed, Oct 15, 2025 at 11:25?AM Antonio Valanzano <
>>>>>> anvalanz at gmail.com> wrote:
>>>>>>
>>>>>>> Here is the details of my installation:
>>>>>>>
>>>>>>> "postgis_full_version"
>>>>>>> "POSTGIS=""3.5.2 3.5.2"" [EXTENSION] PGSQL=""170""
>>>>>>> GEOS=""3.13.0-CAPI-1.19.0"" PROJ=""8.2.1 NETWORK_ENABLED=OFF URL_ENDPOINT=
>>>>>>> https://cdn.proj.org
>>>>>>> USER_WRITABLE_DIRECTORY=C:\Windows\ServiceProfiles\NetworkService\AppData\Local/proj
>>>>>>> DATABASE_PATH=C:\Program
>>>>>>> Files\PostgreSQL\17\share\contrib\postgis-3.5\proj\proj.db"" (compiled
>>>>>>> against PROJ 8.2.1) LIBXML=""2.12.5"" LIBJSON=""0.12""
>>>>>>> LIBPROTOBUF=""1.2.1"" WAGYU=""0.5.0 (Internal)"""
>>>>>>>
>>>>>>> Antonio
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Il giorno mer 15 ott 2025 alle ore 19:28 Paul Ramsey <
>>>>>>> pramsey at cleverelephant.ca> ha scritto:
>>>>>>>
>>>>>>>> Maybe you have found an old bug? Running exactly the same SQL as
>>>>>>>> you, I get two rows from each query.
>>>>>>>>
>>>>>>>> postgis=# SELECT
>>>>>>>>
>>>>>>>>                     d.id,
>>>>>>>>
>>>>>>>>                                        ST_Relate(d.geom, l.geom) as
>>>>>>>> patternMatrix
>>>>>>>>                                                       FROM docks as d,
>>>>>>>> lakes as l
>>>>>>>>                                                                      WHERE
>>>>>>>> ST_Relate(d.geom, l.geom, '1FF00F212');
>>>>>>>>  id | patternmatrix
>>>>>>>> ----+---------------
>>>>>>>>   1 | 1FF00F212
>>>>>>>>   2 | 1FF00F212
>>>>>>>> (2 rows)
>>>>>>>>
>>>>>>>> postgis=# SELECT
>>>>>>>> postgis-#   d.id,
>>>>>>>> postgis-#   ST_Relate(d.geom, l.geom) as patternMatrix
>>>>>>>> postgis-# FROM docks as d, lakes as l
>>>>>>>> postgis-# WHERE ST_Relate(d.geom, l.geom) = '1FF00F212';
>>>>>>>>  id | patternmatrix
>>>>>>>> ----+---------------
>>>>>>>>   1 | 1FF00F212
>>>>>>>>   2 | 1FF00F212
>>>>>>>> (2 rows)
>>>>>>>>
>>>>>>>> postgis=#
>>>>>>>> postgis=# select postgis_full_version();
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>       postgis_full_version
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>>>>>>>  POSTGIS="3.7.0dev 3.6.0rc2-134-g5dc95f1bc" [EXTENSION] PGSQL="180"
>>>>>>>> GEOS="3.15.0dev-CAPI-1.21.0" PROJ="9.6.2 NETWORK_ENABLED=ON URL_ENDPOINT=
>>>>>>>> https://cdn.proj.org
>>>>>>>> USER_WRITABLE_DIRECTORY=/Users/pramsey/Library/Application Support/proj
>>>>>>>> DATABASE_PATH=/opt/homebrew/Cellar/proj/9.6.2/share/proj/proj.db" (compiled
>>>>>>>> against PROJ 9.6.2) LIBXML="2.9.13" LIBJSON="0.18" LIBPROTOBUF="1.5.2"
>>>>>>>> WAGYU="0.5.0 (Internal)" (core procs from "3.7.0dev
>>>>>>>> 3.6.0rc2-125-g747d7732b" need upgrade)
>>>>>>>>
>>>>>>>> On Wed, Oct 15, 2025 at 9:22?AM Antonio Valanzano <
>>>>>>>> anvalanz at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> I am following the "Introduction to PostGIS " tutorial  at
>>>>>>>>> https://postgis.net/workshops/postgis-intro/
>>>>>>>>> and for chapter 26 "Dimensionally Extended 9-Intersection Model"
>>>>>>>>> I am trying to replicate the examples.
>>>>>>>>>
>>>>>>>>> If I use the two different versions of ST_Relate I do not obtain
>>>>>>>>> the same result
>>>>>>>>>
>>>>>>>>> SELECT
>>>>>>>>>   d.id,
>>>>>>>>>   ST_Relate(d.geom, l.geom) as patternMatrix
>>>>>>>>> FROM docks as d, lakes as l
>>>>>>>>> WHERE ST_Relate(d.geom, l.geom, '1FF00F212') = true;
>>>>>>>>> -- 1 row
>>>>>>>>> "id" "patternmatrix"
>>>>>>>>> 1    "1FF00F212"
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> SELECT
>>>>>>>>>   d.id,
>>>>>>>>>   ST_Relate(d.geom, l.geom) as patternMatrix
>>>>>>>>> FROM docks as d, lakes as l
>>>>>>>>> WHERE ST_Relate(d.geom, l.geom) = '1FF00F212';
>>>>>>>>> -- 2 rows
>>>>>>>>> "id" "patternmatrix"
>>>>>>>>> 1    "1FF00F212"
>>>>>>>>> 2    "1FF00F212"
>>>>>>>>>
>>>>>>>>> Could someone give me an explanation of such a difference ?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20251015/40e68f70/attachment.htm>

From anvalanz at gmail.com  Wed Oct 15 15:43:27 2025
From: anvalanz at gmail.com (Antonio Valanzano)
Date: Thu, 16 Oct 2025 00:43:27 +0200
Subject: different results for ST_Relate with 3 parameters compared to
 those for ST_Relate with 2 parameters
In-Reply-To: <CACowWR0ix64TnRLSwKutd==AW429S5tKmCu9a9NkKYbzWDe0pw@mail.gmail.com>
References: <CANV1FQYH0T9im=NTOUEYic+V2VLkyet-L3ZvCADVkLf0n+DtqQ@mail.gmail.com>
 <CACowWR0QR5LiwjYmud-A1wHoJAdGNsrJu0836Rsco6Ro7NFaFw@mail.gmail.com>
 <CANV1FQZXc0k_aeiKjjGBOJ2OLEmBeyaOc60vv6taEEstKTN5Og@mail.gmail.com>
 <CACowWR2PhX5Z2a9gKNc6o28RhPoxroUPsSKEBNeO72uq+V5cvA@mail.gmail.com>
 <CANV1FQZk5q_uRpU8LvQZJrexyRaQa7RW87fzx5eLw0ufv7XYHw@mail.gmail.com>
 <CACowWR0Wou-TvT3Moc4Pj2hNP6GVYoF7LYp=pQ=zXNMovKwhxw@mail.gmail.com>
 <CANV1FQZJHgs4D3y6pu7r2Zw3CikBYS+tuC8cT5hgWcmK4F13ag@mail.gmail.com>
 <CACowWR0+XZgSXSbQv7t5bi+AQ8TraLD8M7c6OQT78gHo3N3C3w@mail.gmail.com>
 <CANV1FQZ_NG0ZFft5oGwjV5rW0=oqJFPLgPnpACaEtmyX2TqXWA@mail.gmail.com>
 <CACowWR0ix64TnRLSwKutd==AW429S5tKmCu9a9NkKYbzWDe0pw@mail.gmail.com>
Message-ID: <CANV1FQYPXKUxOXwUsMjiccLa_oCSF01M=0_iec_gMKGD1WkZ8Q@mail.gmail.com>

SELECT
ST_Relate(a.geom, b.geom), ST_Relate(a.geom, b.geom, '1FF00F212')
FROM
(VALUES
  ('LINESTRING (170 290, 205 272)'),
  ('LINESTRING (120 215, 176 197)'),
  ('LINESTRING (170 290, 205 272)'),
  ('LINESTRING (120 215, 176 197)')) AS a(geom),
(VALUES ('POLYGON ((100 200, 140 230, 180 310, 280 310, 390 270, 400 210,
320 140, 215 141, 150 170, 100 200))')) AS b(geom);
-- 4 rows
"1FF00F212" true
"1FF00F212" false
"1FF00F212" false
"1FF00F212" false

Il giorno gio 16 ott 2025 alle ore 00:31 Paul Ramsey <
pramsey at cleverelephant.ca> ha scritto:

> One more sorry!
>
> SELECT
> ST_Relate(a.geom, b.geom), ST_Relate(a.geom, b.geom, '1FF00F212')
> FROM
> (VALUES
>   ('LINESTRING (170 290, 205 272)'),
>   ('LINESTRING (120 215, 176 197)'),
>   ('LINESTRING (170 290, 205 272)'),
>   ('LINESTRING (120 215, 176 197)')) AS a(geom),
> (VALUES ('POLYGON ((100 200, 140 230, 180 310, 280 310, 390 270, 400 210,
> 320 140, 215 141, 150 170, 100 200))')) AS b(geom);
>
> On Wed, Oct 15, 2025 at 3:11?PM Antonio Valanzano <anvalanz at gmail.com>
> wrote:
>
>> Here are the results
>>
>> SELECT
>>   ST_Relate(a.geom, b.geom),
>>   ST_Relate(a.geom, b.geom, '1FF00F212')
>> FROM
>> (VALUES ('LINESTRING (170 290, 205 272)'),('LINESTRING (120 215, 176
>> 197)')) AS a(geom),
>> (VALUES ('POLYGON ((100 200, 140 230, 180 310, 280 310, 390 270, 400 210,
>> 320 140, 215 141, 150 170, 100 200))')) AS b(geom);
>> -- 2 rows
>> "st_relate" "st_relate-2"
>> "1FF00F212" true
>> "1FF00F212" false
>>
>> Il giorno mer 15 ott 2025 alle ore 23:22 Paul Ramsey <
>> pramsey at cleverelephant.ca> ha scritto:
>>
>>> Thanks for continuing to try stuff. What does this example return?
>>>
>>> SELECT
>>> ST_Relate(a.geom, b.geom), ST_Relate(a.geom, b.geom, '1FF00F212')
>>> FROM
>>> (VALUES ('LINESTRING (170 290, 205 272)'),('LINESTRING (120 215, 176
>>> 197)')) AS a(geom),
>>> (VALUES ('POLYGON ((100 200, 140 230, 180 310, 280 310, 390 270, 400
>>> 210, 320 140, 215 141, 150 170, 100 200))')) AS b(geom);
>>>
>>>
>>> On Wed, Oct 15, 2025 at 1:29?PM Antonio Valanzano <anvalanz at gmail.com>
>>> wrote:
>>>
>>>> Dear Paul
>>>> here are the results with the new linestrings as you suggested
>>>>
>>>> SELECT
>>>>   d.id,
>>>>   ST_Relate(d.geom, l.geom) as patternMatrix
>>>> FROM docks as d, lakes as l
>>>> WHERE ST_Relate(d.geom, l.geom, '1FF00F212') = true;
>>>> -- 1 row
>>>>
>>>> "id" "patternmatrix"
>>>> 7 "1FF00F212"
>>>>
>>>> SELECT
>>>>   d.id,
>>>>   ST_Relate(d.geom, l.geom) as patternMatrix
>>>> FROM docks as d, lakes as l
>>>> WHERE ST_Relate(d.geom, l.geom) = '1FF00F212';
>>>> -- 4 rows
>>>> "id" "patternmatrix"
>>>> 7 "1FF00F212"
>>>> 8 "1FF00F212"
>>>> 12 "1FF00F212"
>>>> 13 "1FF00F212"
>>>>
>>>> As you can see nothing has changed.
>>>>
>>>> I was wondering which version of PostGIS (and on which platform)  has
>>>> been used for producing the material reported into the tutorial (which
>>>> shows 2 rows as a correct result).
>>>>
>>>> I understand that it is difficult to find the reason for different
>>>> results on different platforms but this shouldn't happen otherwise users
>>>> are confused.. and not sure about the correct results.
>>>>
>>>> When in the near future I will upgrade to PostgreSQL 18  and PostGIS
>>>> 3.6.0 I will try again the same two queries  and let you know if the
>>>> results will be the same or not.
>>>> Thanks for the time you have spent on this matter.
>>>>
>>>> Antonio
>>>>
>>>>
>>>> Il giorno mer 15 ott 2025 alle ore 22:03 Paul Ramsey <
>>>> pramsey at cleverelephant.ca> ha scritto:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Oct 15, 2025 at 12:53?PM Antonio Valanzano <anvalanz at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Paul
>>>>>> I have upgraded to PosGIS 3.5.3 and GEOS  3.13.1 as you can see from
>>>>>> the following output
>>>>>>
>>>>>> "postgis_full_version"
>>>>>> "POSTGIS=""3.5.3 3.5.3"" [EXTENSION] PGSQL=""170""
>>>>>> GEOS=""3.13.1-CAPI-1.19.2"" PROJ=""8.2.1 NETWORK_ENABLED=OFF URL_ENDPOINT=
>>>>>> https://cdn.proj.org
>>>>>> USER_WRITABLE_DIRECTORY=C:\Windows\ServiceProfiles\NetworkService\AppData\Local/proj
>>>>>> DATABASE_PATH=C:\Program
>>>>>> Files\PostgreSQL\17\share\contrib\postgis-3.5\proj\proj.db"" (compiled
>>>>>> against PROJ 8.2.1) LIBXML=""2.12.5"" LIBJSON=""0.12""
>>>>>> LIBPROTOBUF=""1.2.1"" WAGYU=""0.5.0 (Internal)"" (core procs from ""3.5.2
>>>>>> 3.5.2"" need upgrade)"
>>>>>>
>>>>>> but the results are the same with one row for a query and 2 rows for
>>>>>> the other query.
>>>>>>
>>>>>> Is this a known bug or no other user has already reported this
>>>>>> behaviour ?
>>>>>>
>>>>>
>>>>> Not reported, and I'm afraid not solvable unless you can figure out
>>>>> the specific thing about your install vs mine that is giving you a
>>>>> different answer. (Windows is one possibility, though not one I
>>>>> particularly like, platform differences are incredibly hard to isolate.)
>>>>>
>>>>> Seeing if the problem is ordering based and number of entries based
>>>>> might be interesting.
>>>>>
>>>>> DELETE FROM docsk;
>>>>> INSERT INTO docks ( geom, good )
>>>>>   VALUES
>>>>>         ('LINESTRING (170 290, 205 272)',true),
>>>>>         ('LINESTRING (120 215, 176 197)',true),
>>>>>         ('LINESTRING (290 260, 340 250)',false),
>>>>>         ('LINESTRING (350 300, 400 320)',false),
>>>>>         ('LINESTRING (370 230, 420 240)',false),
>>>>>         ('LINESTRING (170 290, 205 272)',true),
>>>>>         ('LINESTRING (120 215, 176 197)',true),
>>>>>         ('LINESTRING (370 180, 390 160)',false);
>>>>>
>>>>> P
>>>>>
>>>>>
>>>>>> Antonio
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Il giorno mer 15 ott 2025 alle ore 20:59 Paul Ramsey <
>>>>>> pramsey at cleverelephant.ca> ha scritto:
>>>>>>
>>>>>>> Sorry, I still cannot replicate. My 3.5 build still returns both
>>>>>>> results. Maybe update to PostGIS 3.5.4 and GEOS 3.13.1 ?
>>>>>>> P.
>>>>>>>
>>>>>>> On Wed, Oct 15, 2025 at 11:25?AM Antonio Valanzano <
>>>>>>> anvalanz at gmail.com> wrote:
>>>>>>>
>>>>>>>> Here is the details of my installation:
>>>>>>>>
>>>>>>>> "postgis_full_version"
>>>>>>>> "POSTGIS=""3.5.2 3.5.2"" [EXTENSION] PGSQL=""170""
>>>>>>>> GEOS=""3.13.0-CAPI-1.19.0"" PROJ=""8.2.1 NETWORK_ENABLED=OFF URL_ENDPOINT=
>>>>>>>> https://cdn.proj.org
>>>>>>>> USER_WRITABLE_DIRECTORY=C:\Windows\ServiceProfiles\NetworkService\AppData\Local/proj
>>>>>>>> DATABASE_PATH=C:\Program
>>>>>>>> Files\PostgreSQL\17\share\contrib\postgis-3.5\proj\proj.db"" (compiled
>>>>>>>> against PROJ 8.2.1) LIBXML=""2.12.5"" LIBJSON=""0.12""
>>>>>>>> LIBPROTOBUF=""1.2.1"" WAGYU=""0.5.0 (Internal)"""
>>>>>>>>
>>>>>>>> Antonio
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Il giorno mer 15 ott 2025 alle ore 19:28 Paul Ramsey <
>>>>>>>> pramsey at cleverelephant.ca> ha scritto:
>>>>>>>>
>>>>>>>>> Maybe you have found an old bug? Running exactly the same SQL as
>>>>>>>>> you, I get two rows from each query.
>>>>>>>>>
>>>>>>>>> postgis=# SELECT
>>>>>>>>>
>>>>>>>>>                     d.id,
>>>>>>>>>
>>>>>>>>>                                        ST_Relate(d.geom, l.geom) as
>>>>>>>>> patternMatrix
>>>>>>>>>                                                       FROM docks as d,
>>>>>>>>> lakes as l
>>>>>>>>>                                                                      WHERE
>>>>>>>>> ST_Relate(d.geom, l.geom, '1FF00F212');
>>>>>>>>>  id | patternmatrix
>>>>>>>>> ----+---------------
>>>>>>>>>   1 | 1FF00F212
>>>>>>>>>   2 | 1FF00F212
>>>>>>>>> (2 rows)
>>>>>>>>>
>>>>>>>>> postgis=# SELECT
>>>>>>>>> postgis-#   d.id,
>>>>>>>>> postgis-#   ST_Relate(d.geom, l.geom) as patternMatrix
>>>>>>>>> postgis-# FROM docks as d, lakes as l
>>>>>>>>> postgis-# WHERE ST_Relate(d.geom, l.geom) = '1FF00F212';
>>>>>>>>>  id | patternmatrix
>>>>>>>>> ----+---------------
>>>>>>>>>   1 | 1FF00F212
>>>>>>>>>   2 | 1FF00F212
>>>>>>>>> (2 rows)
>>>>>>>>>
>>>>>>>>> postgis=#
>>>>>>>>> postgis=# select postgis_full_version();
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>         postgis_full_version
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>>>>>>>>  POSTGIS="3.7.0dev 3.6.0rc2-134-g5dc95f1bc" [EXTENSION]
>>>>>>>>> PGSQL="180" GEOS="3.15.0dev-CAPI-1.21.0" PROJ="9.6.2 NETWORK_ENABLED=ON
>>>>>>>>> URL_ENDPOINT=https://cdn.proj.org
>>>>>>>>> USER_WRITABLE_DIRECTORY=/Users/pramsey/Library/Application Support/proj
>>>>>>>>> DATABASE_PATH=/opt/homebrew/Cellar/proj/9.6.2/share/proj/proj.db" (compiled
>>>>>>>>> against PROJ 9.6.2) LIBXML="2.9.13" LIBJSON="0.18" LIBPROTOBUF="1.5.2"
>>>>>>>>> WAGYU="0.5.0 (Internal)" (core procs from "3.7.0dev
>>>>>>>>> 3.6.0rc2-125-g747d7732b" need upgrade)
>>>>>>>>>
>>>>>>>>> On Wed, Oct 15, 2025 at 9:22?AM Antonio Valanzano <
>>>>>>>>> anvalanz at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> I am following the "Introduction to PostGIS " tutorial  at
>>>>>>>>>> https://postgis.net/workshops/postgis-intro/
>>>>>>>>>> and for chapter 26 "Dimensionally Extended 9-Intersection Model"
>>>>>>>>>> I am trying to replicate the examples.
>>>>>>>>>>
>>>>>>>>>> If I use the two different versions of ST_Relate I do not obtain
>>>>>>>>>> the same result
>>>>>>>>>>
>>>>>>>>>> SELECT
>>>>>>>>>>   d.id,
>>>>>>>>>>   ST_Relate(d.geom, l.geom) as patternMatrix
>>>>>>>>>> FROM docks as d, lakes as l
>>>>>>>>>> WHERE ST_Relate(d.geom, l.geom, '1FF00F212') = true;
>>>>>>>>>> -- 1 row
>>>>>>>>>> "id" "patternmatrix"
>>>>>>>>>> 1    "1FF00F212"
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> SELECT
>>>>>>>>>>   d.id,
>>>>>>>>>>   ST_Relate(d.geom, l.geom) as patternMatrix
>>>>>>>>>> FROM docks as d, lakes as l
>>>>>>>>>> WHERE ST_Relate(d.geom, l.geom) = '1FF00F212';
>>>>>>>>>> -- 2 rows
>>>>>>>>>> "id" "patternmatrix"
>>>>>>>>>> 1    "1FF00F212"
>>>>>>>>>> 2    "1FF00F212"
>>>>>>>>>>
>>>>>>>>>> Could someone give me an explanation of such a difference ?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20251016/173ad937/attachment.htm>

From lr at pcorp.us  Wed Oct 15 20:25:18 2025
From: lr at pcorp.us (Regina Obe)
Date: Wed, 15 Oct 2025 23:25:18 -0400
Subject: different results for ST_Relate with 3 parameters compared to
 those for ST_Relate with 2 parameters
In-Reply-To: <CACowWR0ix64TnRLSwKutd==AW429S5tKmCu9a9NkKYbzWDe0pw@mail.gmail.com>
References: <CANV1FQYH0T9im=NTOUEYic+V2VLkyet-L3ZvCADVkLf0n+DtqQ@mail.gmail.com>
 <CACowWR0QR5LiwjYmud-A1wHoJAdGNsrJu0836Rsco6Ro7NFaFw@mail.gmail.com>
 <CANV1FQZXc0k_aeiKjjGBOJ2OLEmBeyaOc60vv6taEEstKTN5Og@mail.gmail.com>
 <CACowWR2PhX5Z2a9gKNc6o28RhPoxroUPsSKEBNeO72uq+V5cvA@mail.gmail.com>
 <CANV1FQZk5q_uRpU8LvQZJrexyRaQa7RW87fzx5eLw0ufv7XYHw@mail.gmail.com>
 <CACowWR0Wou-TvT3Moc4Pj2hNP6GVYoF7LYp=pQ=zXNMovKwhxw@mail.gmail.com>
 <CANV1FQZJHgs4D3y6pu7r2Zw3CikBYS+tuC8cT5hgWcmK4F13ag@mail.gmail.com>
 <CACowWR0+XZgSXSbQv7t5bi+AQ8TraLD8M7c6OQT78gHo3N3C3w@mail.gmail.com>
 <CANV1FQZ_NG0ZFft5oGwjV5rW0=oqJFPLgPnpACaEtmyX2TqXWA@mail.gmail.com>
 <CACowWR0ix64TnRLSwKutd==AW429S5tKmCu9a9NkKYbzWDe0pw@mail.gmail.com>
Message-ID: <002201dc3e4c$7f5696d0$7e03c470$@pcorp.us>

Antonio,

 

I can replicate your issue with PG17 on windows

 

--------------------------------------------------------------

POSTGIS="3.5.3 3.5.3" [EXTENSION] PGSQL="170" GEOS="3.13.1-CAPI-1.19.2" PROJ="8.2.1 NETWORK_ENABLED=OFF URL_ENDPOINT= USER_WRITABLE_DIRECTORY=C:\Windows\ServiceProfiles\NetworkService\AppData\Local/proj" (compiled against PROJ 8.2.1) LIBXML="2.12.5

" LIBJSON="0.12" LIBPROTOBUF="1.2.1" WAGYU="0.5.0 (Internal)"

 

However the PG18 3.6.0 windows package behaves correctly:

 

PG18 3.6.0 -  POSTGIS="3.6.0 3.6.0" [EXTENSION] PGSQL="180" GEOS="3.14.0-CAPI-1.20.4" SFCGAL="SFCGAL 2.2.0, CGAL 6.0.1, BOOST 1.88.0" PROJ="8.2.1 NETWORK_ENABLED=OFF URL_ENDPOINT= USER_WRITABLE_DIRECTORY=C:\Users\Administrator\AppData\Local/proj" (compiled again
st PROJ 8.2.1) GDAL="GDAL 3.9.2, released 2024/08/13 GDAL_DATA not found" LIBXML="2.12.5" LIBJSON="0.12" LIBPROTOBUF="1.2.1" WAGYU="0.5.0 (Internal)" TOPOLOGY RASTER

 

There are many things changed between the building of the windows 3.5.3 and the 3.6.0 packages

 

e.g. the GEOS was upgraded, I?m compiling with a newer GCC version , and of course PostGIS is newer.

 

I?m planning to release PostGIS 3.6.1 for PostgreSQL 17, but skipping PostGIS 3.6.0 since I have some minor packaging issues to address first and PostGIS 3.6.1 is probably less than a month away.

 

But we?ll try to figure out what piece is the culprit here.

 

From: Paul Ramsey via postgis-users <postgis-users at lists.osgeo.org> 
Sent: Wednesday, October 15, 2025 6:32 PM
To: Antonio Valanzano <anvalanz at gmail.com>
Cc: postgis-users at lists.osgeo.org
Subject: Re: different results for ST_Relate with 3 parameters compared to those for ST_Relate with 2 parameters

 

One more sorry!

 

SELECT 
ST_Relate(a.geom, b.geom), ST_Relate(a.geom, b.geom, '1FF00F212')
FROM 
(VALUES 
  ('LINESTRING (170 290, 205 272)'),
  ('LINESTRING (120 215, 176 197)'),
  ('LINESTRING (170 290, 205 272)'),
  ('LINESTRING (120 215, 176 197)')) AS a(geom),
(VALUES ('POLYGON ((100 200, 140 230, 180 310, 280 310, 390 270, 400 210, 320 140, 215 141, 150 170, 100 200))')) AS b(geom);

 

On Wed, Oct 15, 2025 at 3:11?PM Antonio Valanzano <anvalanz at gmail.com <mailto:anvalanz at gmail.com> > wrote:

Here are the results 

 

SELECT
  ST_Relate(a.geom, b.geom), 
  ST_Relate(a.geom, b.geom, '1FF00F212')
FROM
(VALUES ('LINESTRING (170 290, 205 272)'),('LINESTRING (120 215, 176 197)')) AS a(geom),
(VALUES ('POLYGON ((100 200, 140 230, 180 310, 280 310, 390 270, 400 210, 320 140, 215 141, 150 170, 100 200))')) AS b(geom);
-- 2 rows
"st_relate" "st_relate-2"
"1FF00F212" true
"1FF00F212" false

 

Il giorno mer 15 ott 2025 alle ore 23:22 Paul Ramsey <pramsey at cleverelephant.ca <mailto:pramsey at cleverelephant.ca> > ha scritto:

Thanks for continuing to try stuff. What does this example return?

 

SELECT 
ST_Relate(a.geom, b.geom), ST_Relate(a.geom, b.geom, '1FF00F212')
FROM 
(VALUES ('LINESTRING (170 290, 205 272)'),('LINESTRING (120 215, 176 197)')) AS a(geom),
(VALUES ('POLYGON ((100 200, 140 230, 180 310, 280 310, 390 270, 400 210, 320 140, 215 141, 150 170, 100 200))')) AS b(geom);

 

 

On Wed, Oct 15, 2025 at 1:29?PM Antonio Valanzano <anvalanz at gmail.com <mailto:anvalanz at gmail.com> > wrote:

Dear Paul

here are the results with the new linestrings as you suggested

 

SELECT
  d.id <http://d.id> , 
  ST_Relate(d.geom, l.geom) as patternMatrix
FROM docks as d, lakes as l
WHERE ST_Relate(d.geom, l.geom, '1FF00F212') = true;

-- 1 row

 

"id" "patternmatrix"
7 "1FF00F212"

 

SELECT
  d.id <http://d.id> , 
  ST_Relate(d.geom, l.geom) as patternMatrix
FROM docks as d, lakes as l
WHERE ST_Relate(d.geom, l.geom) = '1FF00F212';

-- 4 rows

"id" "patternmatrix"
7 "1FF00F212"
8 "1FF00F212"
12 "1FF00F212"
13 "1FF00F212"

 

As you can see nothing has changed.

 

I was wondering which version of PostGIS (and on which platform)  has been used for producing the material reported into the tutorial (which shows 2 rows as a correct result).

 

I understand that it is difficult to find the reason for different results on different platforms but this shouldn't happen otherwise users are confused.. and not sure about the correct results.

 

When in the near future I will upgrade to PostgreSQL 18  and PostGIS 3.6.0 I will try again the same two queries  and let you know if the results will be the same or not.

Thanks for the time you have spent on this matter.

 

Antonio

 

 

Il giorno mer 15 ott 2025 alle ore 22:03 Paul Ramsey <pramsey at cleverelephant.ca <mailto:pramsey at cleverelephant.ca> > ha scritto:

 

 

On Wed, Oct 15, 2025 at 12:53?PM Antonio Valanzano <anvalanz at gmail.com <mailto:anvalanz at gmail.com> > wrote:

Hi Paul

I have upgraded to PosGIS 3.5.3 and GEOS  3.13.1 as you can see from the following output 

 

"postgis_full_version"
"POSTGIS=""3.5.3 3.5.3"" [EXTENSION] PGSQL=""170"" GEOS=""3.13.1-CAPI-1.19.2"" PROJ=""8.2.1 NETWORK_ENABLED=OFF URL_ENDPOINT=https://cdn.proj.org USER_WRITABLE_DIRECTORY=C:\Windows\ServiceProfiles\NetworkService\AppData\Local/proj DATABASE_PATH=C:\Program Files\PostgreSQL\17\share\contrib\postgis-3.5\proj\proj.db"" (compiled against PROJ 8.2.1) LIBXML=""2.12.5"" LIBJSON=""0.12"" LIBPROTOBUF=""1.2.1"" WAGYU=""0.5.0 (Internal)"" (core procs from ""3.5.2 3.5.2"" need upgrade)"

but the results are the same with one row for a query and 2 rows for the other query.

 

Is this a known bug or no other user has already reported this behaviour ?

 

Not reported, and I'm afraid not solvable unless you can figure out the specific thing about your install vs mine that is giving you a different answer. (Windows is one possibility, though not one I particularly like, platform differences are incredibly hard to isolate.) 

 

Seeing if the problem is ordering based and number of entries based might be interesting. 

 

DELETE FROM docsk;

INSERT INTO docks ( geom, good )
  VALUES
        ('LINESTRING (170 290, 205 272)',true),
        ('LINESTRING (120 215, 176 197)',true),
        ('LINESTRING (290 260, 340 250)',false),
        ('LINESTRING (350 300, 400 320)',false),
        ('LINESTRING (370 230, 420 240)',false),
        ('LINESTRING (170 290, 205 272)',true),
        ('LINESTRING (120 215, 176 197)',true),
        ('LINESTRING (370 180, 390 160)',false);

 

P 

 

 

Antonio

 

 

 

 

Il giorno mer 15 ott 2025 alle ore 20:59 Paul Ramsey <pramsey at cleverelephant.ca <mailto:pramsey at cleverelephant.ca> > ha scritto:

Sorry, I still cannot replicate. My 3.5 build still returns both results. Maybe update to PostGIS 3.5.4 and GEOS 3.13.1 ?

P.

 

On Wed, Oct 15, 2025 at 11:25?AM Antonio Valanzano <anvalanz at gmail.com <mailto:anvalanz at gmail.com> > wrote:

Here is the details of my installation:

 

"postgis_full_version"
"POSTGIS=""3.5.2 3.5.2"" [EXTENSION] PGSQL=""170"" GEOS=""3.13.0-CAPI-1.19.0"" PROJ=""8.2.1 NETWORK_ENABLED=OFF URL_ENDPOINT=https://cdn.proj.org USER_WRITABLE_DIRECTORY=C:\Windows\ServiceProfiles\NetworkService\AppData\Local/proj DATABASE_PATH=C:\Program Files\PostgreSQL\17\share\contrib\postgis-3.5\proj\proj.db"" (compiled against PROJ 8.2.1) LIBXML=""2.12.5"" LIBJSON=""0.12"" LIBPROTOBUF=""1.2.1"" WAGYU=""0.5.0 (Internal)"""

 

Antonio

 

 

 

Il giorno mer 15 ott 2025 alle ore 19:28 Paul Ramsey <pramsey at cleverelephant.ca <mailto:pramsey at cleverelephant.ca> > ha scritto:

Maybe you have found an old bug? Running exactly the same SQL as you, I get two rows from each query.

 

postgis=# SELECT                                                                                                                                                   d.id <http://d.id> ,                                                                                                                                                            ST_Relate(d.geom, l.geom) as patternMatrix                                                                                                                     FROM docks as d, lakes as l                                                                                                                                      WHERE ST_Relate(d.geom, l.geom, '1FF00F212');
 id | patternmatrix 
----+---------------
  1 | 1FF00F212
  2 | 1FF00F212
(2 rows)

postgis=# SELECT
postgis-#   d.id <http://d.id> ,
postgis-#   ST_Relate(d.geom, l.geom) as patternMatrix
postgis-# FROM docks as d, lakes as l
postgis-# WHERE ST_Relate(d.geom, l.geom) = '1FF00F212';
 id | patternmatrix 
----+---------------
  1 | 1FF00F212
  2 | 1FF00F212
(2 rows)

postgis=# 
postgis=# select postgis_full_version();
                                                                                                                                                                                                                                  postgis_full_version                                                                                                                                                                                                                                  
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 POSTGIS="3.7.0dev 3.6.0rc2-134-g5dc95f1bc" [EXTENSION] PGSQL="180" GEOS="3.15.0dev-CAPI-1.21.0" PROJ="9.6.2 NETWORK_ENABLED=ON URL_ENDPOINT=https://cdn.proj.org USER_WRITABLE_DIRECTORY=/Users/pramsey/Library/Application Support/proj DATABASE_PATH=/opt/homebrew/Cellar/proj/9.6.2/share/proj/proj.db" (compiled against PROJ 9.6.2) LIBXML="2.9.13" LIBJSON="0.18" LIBPROTOBUF="1.5.2" WAGYU="0.5.0 (Internal)" (core procs from "3.7.0dev 3.6.0rc2-125-g747d7732b" need upgrade)

 

On Wed, Oct 15, 2025 at 9:22?AM Antonio Valanzano <anvalanz at gmail.com <mailto:anvalanz at gmail.com> > wrote:

I am following the "Introduction to PostGIS " tutorial  at https://postgis.net/workshops/postgis-intro/

and for chapter 26 "Dimensionally Extended 9-Intersection Model"  I am trying to replicate the examples.

 

If I use the two different versions of ST_Relate I do not obtain the same result

 

SELECT
  d.id <http://d.id> , 
  ST_Relate(d.geom, l.geom) as patternMatrix
FROM docks as d, lakes as l
WHERE ST_Relate(d.geom, l.geom, '1FF00F212') = true;
-- 1 row
"id" "patternmatrix"
1    "1FF00F212"



SELECT
  d.id <http://d.id> , 
  ST_Relate(d.geom, l.geom) as patternMatrix
FROM docks as d, lakes as l
WHERE ST_Relate(d.geom, l.geom) = '1FF00F212';
-- 2 rows
"id" "patternmatrix"
1    "1FF00F212"
2    "1FF00F212"

 

Could someone give me an explanation of such a difference ?

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20251015/fa0ad136/attachment.htm>

From pramsey at cleverelephant.ca  Thu Oct 16 09:25:41 2025
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Thu, 16 Oct 2025 09:25:41 -0700
Subject: different results for ST_Relate with 3 parameters compared to
 those for ST_Relate with 2 parameters
In-Reply-To: <002201dc3e4c$7f5696d0$7e03c470$@pcorp.us>
References: <CANV1FQYH0T9im=NTOUEYic+V2VLkyet-L3ZvCADVkLf0n+DtqQ@mail.gmail.com>
 <CACowWR0QR5LiwjYmud-A1wHoJAdGNsrJu0836Rsco6Ro7NFaFw@mail.gmail.com>
 <CANV1FQZXc0k_aeiKjjGBOJ2OLEmBeyaOc60vv6taEEstKTN5Og@mail.gmail.com>
 <CACowWR2PhX5Z2a9gKNc6o28RhPoxroUPsSKEBNeO72uq+V5cvA@mail.gmail.com>
 <CANV1FQZk5q_uRpU8LvQZJrexyRaQa7RW87fzx5eLw0ufv7XYHw@mail.gmail.com>
 <CACowWR0Wou-TvT3Moc4Pj2hNP6GVYoF7LYp=pQ=zXNMovKwhxw@mail.gmail.com>
 <CANV1FQZJHgs4D3y6pu7r2Zw3CikBYS+tuC8cT5hgWcmK4F13ag@mail.gmail.com>
 <CACowWR0+XZgSXSbQv7t5bi+AQ8TraLD8M7c6OQT78gHo3N3C3w@mail.gmail.com>
 <CANV1FQZ_NG0ZFft5oGwjV5rW0=oqJFPLgPnpACaEtmyX2TqXWA@mail.gmail.com>
 <CACowWR0ix64TnRLSwKutd==AW429S5tKmCu9a9NkKYbzWDe0pw@mail.gmail.com>
 <002201dc3e4c$7f5696d0$7e03c470$@pcorp.us>
Message-ID: <CACowWR1BOne3+ohmZ4wmARQ_JtsS1RPHBNfYHg+PdGxzCYk-iA@mail.gmail.com>

Arg, found it. How old am I? Old enough not to remember this fix from, not
YEARS ago, but only months ago.

https://trac.osgeo.org/postgis/ticket/5938

The interaction between the new "cacheable relate" code and the need for
stable operand order for the relate pattern match function generates these
issues, and it's not platform specific, just version specific.
Unfortunately the version of PostGIS 3.5 that fixes this issue... is not
yet released. 3.5.4 will include this fix. As will 3.6.1. My habit of
running and testing off the latest stable branch bit me here, if I was
testing your exact release I would have seen the error immediately.

P.

On Wed, Oct 15, 2025 at 8:25?PM Regina Obe <lr at pcorp.us> wrote:

> Antonio,
>
>
>
> I can replicate your issue with PG17 on windows
>
>
>
> --------------------------------------------------------------
>
> POSTGIS="3.5.3 3.5.3" [EXTENSION] PGSQL="170" GEOS="3.13.1-CAPI-1.19.2"
> PROJ="8.2.1 NETWORK_ENABLED=OFF URL_ENDPOINT=
> USER_WRITABLE_DIRECTORY=C:\Windows\ServiceProfiles\NetworkService\AppData\Local/proj"
> (compiled against PROJ 8.2.1) LIBXML="2.12.5
>
> " LIBJSON="0.12" LIBPROTOBUF="1.2.1" WAGYU="0.5.0 (Internal)"
>
>
>
> However the PG18 3.6.0 windows package behaves correctly:
>
>
>
> PG18 3.6.0 -  POSTGIS="3.6.0 3.6.0" [EXTENSION] PGSQL="180"
> GEOS="3.14.0-CAPI-1.20.4" SFCGAL="SFCGAL 2.2.0, CGAL 6.0.1, BOOST 1.88.0"
> PROJ="8.2.1 NETWORK_ENABLED=OFF URL_ENDPOINT=
> USER_WRITABLE_DIRECTORY=C:\Users\Administrator\AppData\Local/proj"
> (compiled again
> st PROJ 8.2.1) GDAL="GDAL 3.9.2, released 2024/08/13 GDAL_DATA not found"
> LIBXML="2.12.5" LIBJSON="0.12" LIBPROTOBUF="1.2.1" WAGYU="0.5.0 (Internal)"
> TOPOLOGY RASTER
>
>
>
> There are many things changed between the building of the windows 3.5.3
> and the 3.6.0 packages
>
>
>
> e.g. the GEOS was upgraded, I?m compiling with a newer GCC version , and
> of course PostGIS is newer.
>
>
>
> I?m planning to release PostGIS 3.6.1 for PostgreSQL 17, but skipping
> PostGIS 3.6.0 since I have some minor packaging issues to address first and
> PostGIS 3.6.1 is probably less than a month away.
>
>
>
> But we?ll try to figure out what piece is the culprit here.
>
>
>
> *From:* Paul Ramsey via postgis-users <postgis-users at lists.osgeo.org>
> *Sent:* Wednesday, October 15, 2025 6:32 PM
> *To:* Antonio Valanzano <anvalanz at gmail.com>
> *Cc:* postgis-users at lists.osgeo.org
> *Subject:* Re: different results for ST_Relate with 3 parameters compared
> to those for ST_Relate with 2 parameters
>
>
>
> One more sorry!
>
>
>
> SELECT
> ST_Relate(a.geom, b.geom), ST_Relate(a.geom, b.geom, '1FF00F212')
> FROM
> (VALUES
>   ('LINESTRING (170 290, 205 272)'),
>   ('LINESTRING (120 215, 176 197)'),
>   ('LINESTRING (170 290, 205 272)'),
>   ('LINESTRING (120 215, 176 197)')) AS a(geom),
> (VALUES ('POLYGON ((100 200, 140 230, 180 310, 280 310, 390 270, 400 210,
> 320 140, 215 141, 150 170, 100 200))')) AS b(geom);
>
>
>
> On Wed, Oct 15, 2025 at 3:11?PM Antonio Valanzano <anvalanz at gmail.com>
> wrote:
>
> Here are the results
>
>
>
> SELECT
>   ST_Relate(a.geom, b.geom),
>   ST_Relate(a.geom, b.geom, '1FF00F212')
> FROM
> (VALUES ('LINESTRING (170 290, 205 272)'),('LINESTRING (120 215, 176
> 197)')) AS a(geom),
> (VALUES ('POLYGON ((100 200, 140 230, 180 310, 280 310, 390 270, 400 210,
> 320 140, 215 141, 150 170, 100 200))')) AS b(geom);
> -- 2 rows
> "st_relate" "st_relate-2"
> "1FF00F212" true
> "1FF00F212" false
>
>
>
> Il giorno mer 15 ott 2025 alle ore 23:22 Paul Ramsey <
> pramsey at cleverelephant.ca> ha scritto:
>
> Thanks for continuing to try stuff. What does this example return?
>
>
>
> SELECT
> ST_Relate(a.geom, b.geom), ST_Relate(a.geom, b.geom, '1FF00F212')
> FROM
> (VALUES ('LINESTRING (170 290, 205 272)'),('LINESTRING (120 215, 176
> 197)')) AS a(geom),
> (VALUES ('POLYGON ((100 200, 140 230, 180 310, 280 310, 390 270, 400 210,
> 320 140, 215 141, 150 170, 100 200))')) AS b(geom);
>
>
>
>
>
> On Wed, Oct 15, 2025 at 1:29?PM Antonio Valanzano <anvalanz at gmail.com>
> wrote:
>
> Dear Paul
>
> here are the results with the new linestrings as you suggested
>
>
>
> SELECT
>   d.id,
>   ST_Relate(d.geom, l.geom) as patternMatrix
> FROM docks as d, lakes as l
> WHERE ST_Relate(d.geom, l.geom, '1FF00F212') = true;
>
> -- 1 row
>
>
>
> "id" "patternmatrix"
> 7 "1FF00F212"
>
>
>
> SELECT
>   d.id,
>   ST_Relate(d.geom, l.geom) as patternMatrix
> FROM docks as d, lakes as l
> WHERE ST_Relate(d.geom, l.geom) = '1FF00F212';
>
> -- 4 rows
>
> "id" "patternmatrix"
> 7 "1FF00F212"
> 8 "1FF00F212"
> 12 "1FF00F212"
> 13 "1FF00F212"
>
>
>
> As you can see nothing has changed.
>
>
>
> I was wondering which version of PostGIS (and on which platform)  has been
> used for producing the material reported into the tutorial (which shows 2
> rows as a correct result).
>
>
>
> I understand that it is difficult to find the reason for different results
> on different platforms but this shouldn't happen otherwise users are
> confused.. and not sure about the correct results.
>
>
>
> When in the near future I will upgrade to PostgreSQL 18  and PostGIS 3.6.0
> I will try again the same two queries  and let you know if the results will
> be the same or not.
>
> Thanks for the time you have spent on this matter.
>
>
>
> Antonio
>
>
>
>
>
> Il giorno mer 15 ott 2025 alle ore 22:03 Paul Ramsey <
> pramsey at cleverelephant.ca> ha scritto:
>
>
>
>
>
> On Wed, Oct 15, 2025 at 12:53?PM Antonio Valanzano <anvalanz at gmail.com>
> wrote:
>
> Hi Paul
>
> I have upgraded to PosGIS 3.5.3 and GEOS  3.13.1 as you can see from the
> following output
>
>
>
> "postgis_full_version"
> "POSTGIS=""3.5.3 3.5.3"" [EXTENSION] PGSQL=""170""
> GEOS=""3.13.1-CAPI-1.19.2"" PROJ=""8.2.1 NETWORK_ENABLED=OFF URL_ENDPOINT=
> https://cdn.proj.org
> USER_WRITABLE_DIRECTORY=C:\Windows\ServiceProfiles\NetworkService\AppData\Local/proj
> DATABASE_PATH=C:\Program
> Files\PostgreSQL\17\share\contrib\postgis-3.5\proj\proj.db"" (compiled
> against PROJ 8.2.1) LIBXML=""2.12.5"" LIBJSON=""0.12""
> LIBPROTOBUF=""1.2.1"" WAGYU=""0.5.0 (Internal)"" (core procs from ""3.5.2
> 3.5.2"" need upgrade)"
>
> but the results are the same with one row for a query and 2 rows for the
> other query.
>
>
>
> Is this a known bug or no other user has already reported this behaviour ?
>
>
>
> Not reported, and I'm afraid not solvable unless you can figure out the
> specific thing about your install vs mine that is giving you a different
> answer. (Windows is one possibility, though not one I particularly like,
> platform differences are incredibly hard to isolate.)
>
>
>
> Seeing if the problem is ordering based and number of entries based might
> be interesting.
>
>
>
> DELETE FROM docsk;
>
> INSERT INTO docks ( geom, good )
>   VALUES
>         ('LINESTRING (170 290, 205 272)',true),
>         ('LINESTRING (120 215, 176 197)',true),
>         ('LINESTRING (290 260, 340 250)',false),
>         ('LINESTRING (350 300, 400 320)',false),
>         ('LINESTRING (370 230, 420 240)',false),
>         ('LINESTRING (170 290, 205 272)',true),
>         ('LINESTRING (120 215, 176 197)',true),
>         ('LINESTRING (370 180, 390 160)',false);
>
>
>
> P
>
>
>
>
>
> Antonio
>
>
>
>
>
>
>
>
>
> Il giorno mer 15 ott 2025 alle ore 20:59 Paul Ramsey <
> pramsey at cleverelephant.ca> ha scritto:
>
> Sorry, I still cannot replicate. My 3.5 build still returns both results.
> Maybe update to PostGIS 3.5.4 and GEOS 3.13.1 ?
>
> P.
>
>
>
> On Wed, Oct 15, 2025 at 11:25?AM Antonio Valanzano <anvalanz at gmail.com>
> wrote:
>
> Here is the details of my installation:
>
>
>
> "postgis_full_version"
> "POSTGIS=""3.5.2 3.5.2"" [EXTENSION] PGSQL=""170""
> GEOS=""3.13.0-CAPI-1.19.0"" PROJ=""8.2.1 NETWORK_ENABLED=OFF URL_ENDPOINT=
> https://cdn.proj.org
> USER_WRITABLE_DIRECTORY=C:\Windows\ServiceProfiles\NetworkService\AppData\Local/proj
> DATABASE_PATH=C:\Program
> Files\PostgreSQL\17\share\contrib\postgis-3.5\proj\proj.db"" (compiled
> against PROJ 8.2.1) LIBXML=""2.12.5"" LIBJSON=""0.12""
> LIBPROTOBUF=""1.2.1"" WAGYU=""0.5.0 (Internal)"""
>
>
>
> Antonio
>
>
>
>
>
>
>
> Il giorno mer 15 ott 2025 alle ore 19:28 Paul Ramsey <
> pramsey at cleverelephant.ca> ha scritto:
>
> Maybe you have found an old bug? Running exactly the same SQL as you, I
> get two rows from each query.
>
>
>
> postgis=# SELECT
>
>             d.id,
>
>                        ST_Relate(d.geom, l.geom) as patternMatrix
>
>                               FROM docks as d, lakes as l
>
>                                        WHERE ST_Relate(d.geom, l.geom,
> '1FF00F212');
>  id | patternmatrix
> ----+---------------
>   1 | 1FF00F212
>   2 | 1FF00F212
> (2 rows)
>
> postgis=# SELECT
> postgis-#   d.id,
> postgis-#   ST_Relate(d.geom, l.geom) as patternMatrix
> postgis-# FROM docks as d, lakes as l
> postgis-# WHERE ST_Relate(d.geom, l.geom) = '1FF00F212';
>  id | patternmatrix
> ----+---------------
>   1 | 1FF00F212
>   2 | 1FF00F212
> (2 rows)
>
> postgis=#
> postgis=# select postgis_full_version();
>
>
>
> postgis_full_version
>
>
>
>
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>  POSTGIS="3.7.0dev 3.6.0rc2-134-g5dc95f1bc" [EXTENSION] PGSQL="180"
> GEOS="3.15.0dev-CAPI-1.21.0" PROJ="9.6.2 NETWORK_ENABLED=ON URL_ENDPOINT=
> https://cdn.proj.org
> USER_WRITABLE_DIRECTORY=/Users/pramsey/Library/Application Support/proj
> DATABASE_PATH=/opt/homebrew/Cellar/proj/9.6.2/share/proj/proj.db" (compiled
> against PROJ 9.6.2) LIBXML="2.9.13" LIBJSON="0.18" LIBPROTOBUF="1.5.2"
> WAGYU="0.5.0 (Internal)" (core procs from "3.7.0dev
> 3.6.0rc2-125-g747d7732b" need upgrade)
>
>
>
> On Wed, Oct 15, 2025 at 9:22?AM Antonio Valanzano <anvalanz at gmail.com>
> wrote:
>
> I am following the "Introduction to PostGIS " tutorial  at
> https://postgis.net/workshops/postgis-intro/
>
> and for chapter 26 "Dimensionally Extended 9-Intersection Model"  I am
> trying to replicate the examples.
>
>
>
> If I use the two different versions of ST_Relate I do not obtain the same
> result
>
>
>
> SELECT
>   d.id,
>   ST_Relate(d.geom, l.geom) as patternMatrix
> FROM docks as d, lakes as l
> WHERE ST_Relate(d.geom, l.geom, '1FF00F212') = true;
> -- 1 row
> "id" "patternmatrix"
> 1    "1FF00F212"
>
>
>
> SELECT
>   d.id,
>   ST_Relate(d.geom, l.geom) as patternMatrix
> FROM docks as d, lakes as l
> WHERE ST_Relate(d.geom, l.geom) = '1FF00F212';
> -- 2 rows
> "id" "patternmatrix"
> 1    "1FF00F212"
> 2    "1FF00F212"
>
>
>
> Could someone give me an explanation of such a difference ?
>
>
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20251016/c8497b64/attachment.htm>

From pramsey at cleverelephant.ca  Thu Oct 16 09:47:43 2025
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Thu, 16 Oct 2025 09:47:43 -0700
Subject: different results for ST_Relate with 3 parameters compared to
 those for ST_Relate with 2 parameters
In-Reply-To: <CACowWR1BOne3+ohmZ4wmARQ_JtsS1RPHBNfYHg+PdGxzCYk-iA@mail.gmail.com>
References: <CANV1FQYH0T9im=NTOUEYic+V2VLkyet-L3ZvCADVkLf0n+DtqQ@mail.gmail.com>
 <CACowWR0QR5LiwjYmud-A1wHoJAdGNsrJu0836Rsco6Ro7NFaFw@mail.gmail.com>
 <CANV1FQZXc0k_aeiKjjGBOJ2OLEmBeyaOc60vv6taEEstKTN5Og@mail.gmail.com>
 <CACowWR2PhX5Z2a9gKNc6o28RhPoxroUPsSKEBNeO72uq+V5cvA@mail.gmail.com>
 <CANV1FQZk5q_uRpU8LvQZJrexyRaQa7RW87fzx5eLw0ufv7XYHw@mail.gmail.com>
 <CACowWR0Wou-TvT3Moc4Pj2hNP6GVYoF7LYp=pQ=zXNMovKwhxw@mail.gmail.com>
 <CANV1FQZJHgs4D3y6pu7r2Zw3CikBYS+tuC8cT5hgWcmK4F13ag@mail.gmail.com>
 <CACowWR0+XZgSXSbQv7t5bi+AQ8TraLD8M7c6OQT78gHo3N3C3w@mail.gmail.com>
 <CANV1FQZ_NG0ZFft5oGwjV5rW0=oqJFPLgPnpACaEtmyX2TqXWA@mail.gmail.com>
 <CACowWR0ix64TnRLSwKutd==AW429S5tKmCu9a9NkKYbzWDe0pw@mail.gmail.com>
 <002201dc3e4c$7f5696d0$7e03c470$@pcorp.us>
 <CACowWR1BOne3+ohmZ4wmARQ_JtsS1RPHBNfYHg+PdGxzCYk-iA@mail.gmail.com>
Message-ID: <CACowWR32bq8eu+XNxQOjVEFrA+U2-LnoPhQSuiPMXAivz9vCOA@mail.gmail.com>

Actually 3.6.0 already has the fix, so only the stable 3.5 branch in
conjunction with GEOS 3.13+ with display the issue.

P.

On Thu, Oct 16, 2025 at 9:25?AM Paul Ramsey <pramsey at cleverelephant.ca>
wrote:

> Arg, found it. How old am I? Old enough not to remember this fix from, not
> YEARS ago, but only months ago.
>
> https://trac.osgeo.org/postgis/ticket/5938
>
> The interaction between the new "cacheable relate" code and the need for
> stable operand order for the relate pattern match function generates these
> issues, and it's not platform specific, just version specific.
> Unfortunately the version of PostGIS 3.5 that fixes this issue... is not
> yet released. 3.5.4 will include this fix. As will 3.6.1. My habit of
> running and testing off the latest stable branch bit me here, if I was
> testing your exact release I would have seen the error immediately.
>
> P.
>
> On Wed, Oct 15, 2025 at 8:25?PM Regina Obe <lr at pcorp.us> wrote:
>
>> Antonio,
>>
>>
>>
>> I can replicate your issue with PG17 on windows
>>
>>
>>
>> --------------------------------------------------------------
>>
>> POSTGIS="3.5.3 3.5.3" [EXTENSION] PGSQL="170" GEOS="3.13.1-CAPI-1.19.2"
>> PROJ="8.2.1 NETWORK_ENABLED=OFF URL_ENDPOINT=
>> USER_WRITABLE_DIRECTORY=C:\Windows\ServiceProfiles\NetworkService\AppData\Local/proj"
>> (compiled against PROJ 8.2.1) LIBXML="2.12.5
>>
>> " LIBJSON="0.12" LIBPROTOBUF="1.2.1" WAGYU="0.5.0 (Internal)"
>>
>>
>>
>> However the PG18 3.6.0 windows package behaves correctly:
>>
>>
>>
>> PG18 3.6.0 -  POSTGIS="3.6.0 3.6.0" [EXTENSION] PGSQL="180"
>> GEOS="3.14.0-CAPI-1.20.4" SFCGAL="SFCGAL 2.2.0, CGAL 6.0.1, BOOST 1.88.0"
>> PROJ="8.2.1 NETWORK_ENABLED=OFF URL_ENDPOINT=
>> USER_WRITABLE_DIRECTORY=C:\Users\Administrator\AppData\Local/proj"
>> (compiled again
>> st PROJ 8.2.1) GDAL="GDAL 3.9.2, released 2024/08/13 GDAL_DATA not found"
>> LIBXML="2.12.5" LIBJSON="0.12" LIBPROTOBUF="1.2.1" WAGYU="0.5.0 (Internal)"
>> TOPOLOGY RASTER
>>
>>
>>
>> There are many things changed between the building of the windows 3.5.3
>> and the 3.6.0 packages
>>
>>
>>
>> e.g. the GEOS was upgraded, I?m compiling with a newer GCC version , and
>> of course PostGIS is newer.
>>
>>
>>
>> I?m planning to release PostGIS 3.6.1 for PostgreSQL 17, but skipping
>> PostGIS 3.6.0 since I have some minor packaging issues to address first and
>> PostGIS 3.6.1 is probably less than a month away.
>>
>>
>>
>> But we?ll try to figure out what piece is the culprit here.
>>
>>
>>
>> *From:* Paul Ramsey via postgis-users <postgis-users at lists.osgeo.org>
>> *Sent:* Wednesday, October 15, 2025 6:32 PM
>> *To:* Antonio Valanzano <anvalanz at gmail.com>
>> *Cc:* postgis-users at lists.osgeo.org
>> *Subject:* Re: different results for ST_Relate with 3 parameters
>> compared to those for ST_Relate with 2 parameters
>>
>>
>>
>> One more sorry!
>>
>>
>>
>> SELECT
>> ST_Relate(a.geom, b.geom), ST_Relate(a.geom, b.geom, '1FF00F212')
>> FROM
>> (VALUES
>>   ('LINESTRING (170 290, 205 272)'),
>>   ('LINESTRING (120 215, 176 197)'),
>>   ('LINESTRING (170 290, 205 272)'),
>>   ('LINESTRING (120 215, 176 197)')) AS a(geom),
>> (VALUES ('POLYGON ((100 200, 140 230, 180 310, 280 310, 390 270, 400 210,
>> 320 140, 215 141, 150 170, 100 200))')) AS b(geom);
>>
>>
>>
>> On Wed, Oct 15, 2025 at 3:11?PM Antonio Valanzano <anvalanz at gmail.com>
>> wrote:
>>
>> Here are the results
>>
>>
>>
>> SELECT
>>   ST_Relate(a.geom, b.geom),
>>   ST_Relate(a.geom, b.geom, '1FF00F212')
>> FROM
>> (VALUES ('LINESTRING (170 290, 205 272)'),('LINESTRING (120 215, 176
>> 197)')) AS a(geom),
>> (VALUES ('POLYGON ((100 200, 140 230, 180 310, 280 310, 390 270, 400 210,
>> 320 140, 215 141, 150 170, 100 200))')) AS b(geom);
>> -- 2 rows
>> "st_relate" "st_relate-2"
>> "1FF00F212" true
>> "1FF00F212" false
>>
>>
>>
>> Il giorno mer 15 ott 2025 alle ore 23:22 Paul Ramsey <
>> pramsey at cleverelephant.ca> ha scritto:
>>
>> Thanks for continuing to try stuff. What does this example return?
>>
>>
>>
>> SELECT
>> ST_Relate(a.geom, b.geom), ST_Relate(a.geom, b.geom, '1FF00F212')
>> FROM
>> (VALUES ('LINESTRING (170 290, 205 272)'),('LINESTRING (120 215, 176
>> 197)')) AS a(geom),
>> (VALUES ('POLYGON ((100 200, 140 230, 180 310, 280 310, 390 270, 400 210,
>> 320 140, 215 141, 150 170, 100 200))')) AS b(geom);
>>
>>
>>
>>
>>
>> On Wed, Oct 15, 2025 at 1:29?PM Antonio Valanzano <anvalanz at gmail.com>
>> wrote:
>>
>> Dear Paul
>>
>> here are the results with the new linestrings as you suggested
>>
>>
>>
>> SELECT
>>   d.id,
>>   ST_Relate(d.geom, l.geom) as patternMatrix
>> FROM docks as d, lakes as l
>> WHERE ST_Relate(d.geom, l.geom, '1FF00F212') = true;
>>
>> -- 1 row
>>
>>
>>
>> "id" "patternmatrix"
>> 7 "1FF00F212"
>>
>>
>>
>> SELECT
>>   d.id,
>>   ST_Relate(d.geom, l.geom) as patternMatrix
>> FROM docks as d, lakes as l
>> WHERE ST_Relate(d.geom, l.geom) = '1FF00F212';
>>
>> -- 4 rows
>>
>> "id" "patternmatrix"
>> 7 "1FF00F212"
>> 8 "1FF00F212"
>> 12 "1FF00F212"
>> 13 "1FF00F212"
>>
>>
>>
>> As you can see nothing has changed.
>>
>>
>>
>> I was wondering which version of PostGIS (and on which platform)  has
>> been used for producing the material reported into the tutorial (which
>> shows 2 rows as a correct result).
>>
>>
>>
>> I understand that it is difficult to find the reason for different
>> results on different platforms but this shouldn't happen otherwise users
>> are confused.. and not sure about the correct results.
>>
>>
>>
>> When in the near future I will upgrade to PostgreSQL 18  and PostGIS
>> 3.6.0 I will try again the same two queries  and let you know if the
>> results will be the same or not.
>>
>> Thanks for the time you have spent on this matter.
>>
>>
>>
>> Antonio
>>
>>
>>
>>
>>
>> Il giorno mer 15 ott 2025 alle ore 22:03 Paul Ramsey <
>> pramsey at cleverelephant.ca> ha scritto:
>>
>>
>>
>>
>>
>> On Wed, Oct 15, 2025 at 12:53?PM Antonio Valanzano <anvalanz at gmail.com>
>> wrote:
>>
>> Hi Paul
>>
>> I have upgraded to PosGIS 3.5.3 and GEOS  3.13.1 as you can see from the
>> following output
>>
>>
>>
>> "postgis_full_version"
>> "POSTGIS=""3.5.3 3.5.3"" [EXTENSION] PGSQL=""170""
>> GEOS=""3.13.1-CAPI-1.19.2"" PROJ=""8.2.1 NETWORK_ENABLED=OFF URL_ENDPOINT=
>> https://cdn.proj.org
>> USER_WRITABLE_DIRECTORY=C:\Windows\ServiceProfiles\NetworkService\AppData\Local/proj
>> DATABASE_PATH=C:\Program
>> Files\PostgreSQL\17\share\contrib\postgis-3.5\proj\proj.db"" (compiled
>> against PROJ 8.2.1) LIBXML=""2.12.5"" LIBJSON=""0.12""
>> LIBPROTOBUF=""1.2.1"" WAGYU=""0.5.0 (Internal)"" (core procs from ""3.5.2
>> 3.5.2"" need upgrade)"
>>
>> but the results are the same with one row for a query and 2 rows for the
>> other query.
>>
>>
>>
>> Is this a known bug or no other user has already reported this behaviour ?
>>
>>
>>
>> Not reported, and I'm afraid not solvable unless you can figure out the
>> specific thing about your install vs mine that is giving you a different
>> answer. (Windows is one possibility, though not one I particularly like,
>> platform differences are incredibly hard to isolate.)
>>
>>
>>
>> Seeing if the problem is ordering based and number of entries based might
>> be interesting.
>>
>>
>>
>> DELETE FROM docsk;
>>
>> INSERT INTO docks ( geom, good )
>>   VALUES
>>         ('LINESTRING (170 290, 205 272)',true),
>>         ('LINESTRING (120 215, 176 197)',true),
>>         ('LINESTRING (290 260, 340 250)',false),
>>         ('LINESTRING (350 300, 400 320)',false),
>>         ('LINESTRING (370 230, 420 240)',false),
>>         ('LINESTRING (170 290, 205 272)',true),
>>         ('LINESTRING (120 215, 176 197)',true),
>>         ('LINESTRING (370 180, 390 160)',false);
>>
>>
>>
>> P
>>
>>
>>
>>
>>
>> Antonio
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Il giorno mer 15 ott 2025 alle ore 20:59 Paul Ramsey <
>> pramsey at cleverelephant.ca> ha scritto:
>>
>> Sorry, I still cannot replicate. My 3.5 build still returns both results.
>> Maybe update to PostGIS 3.5.4 and GEOS 3.13.1 ?
>>
>> P.
>>
>>
>>
>> On Wed, Oct 15, 2025 at 11:25?AM Antonio Valanzano <anvalanz at gmail.com>
>> wrote:
>>
>> Here is the details of my installation:
>>
>>
>>
>> "postgis_full_version"
>> "POSTGIS=""3.5.2 3.5.2"" [EXTENSION] PGSQL=""170""
>> GEOS=""3.13.0-CAPI-1.19.0"" PROJ=""8.2.1 NETWORK_ENABLED=OFF URL_ENDPOINT=
>> https://cdn.proj.org
>> USER_WRITABLE_DIRECTORY=C:\Windows\ServiceProfiles\NetworkService\AppData\Local/proj
>> DATABASE_PATH=C:\Program
>> Files\PostgreSQL\17\share\contrib\postgis-3.5\proj\proj.db"" (compiled
>> against PROJ 8.2.1) LIBXML=""2.12.5"" LIBJSON=""0.12""
>> LIBPROTOBUF=""1.2.1"" WAGYU=""0.5.0 (Internal)"""
>>
>>
>>
>> Antonio
>>
>>
>>
>>
>>
>>
>>
>> Il giorno mer 15 ott 2025 alle ore 19:28 Paul Ramsey <
>> pramsey at cleverelephant.ca> ha scritto:
>>
>> Maybe you have found an old bug? Running exactly the same SQL as you, I
>> get two rows from each query.
>>
>>
>>
>> postgis=# SELECT
>>
>>               d.id,
>>
>>                            ST_Relate(d.geom, l.geom) as patternMatrix
>>
>>                                   FROM docks as d, lakes as l
>>
>>                                            WHERE ST_Relate(d.geom, l.geom,
>> '1FF00F212');
>>  id | patternmatrix
>> ----+---------------
>>   1 | 1FF00F212
>>   2 | 1FF00F212
>> (2 rows)
>>
>> postgis=# SELECT
>> postgis-#   d.id,
>> postgis-#   ST_Relate(d.geom, l.geom) as patternMatrix
>> postgis-# FROM docks as d, lakes as l
>> postgis-# WHERE ST_Relate(d.geom, l.geom) = '1FF00F212';
>>  id | patternmatrix
>> ----+---------------
>>   1 | 1FF00F212
>>   2 | 1FF00F212
>> (2 rows)
>>
>> postgis=#
>> postgis=# select postgis_full_version();
>>
>>
>>
>> postgis_full_version
>>
>>
>>
>>
>> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>  POSTGIS="3.7.0dev 3.6.0rc2-134-g5dc95f1bc" [EXTENSION] PGSQL="180"
>> GEOS="3.15.0dev-CAPI-1.21.0" PROJ="9.6.2 NETWORK_ENABLED=ON URL_ENDPOINT=
>> https://cdn.proj.org
>> USER_WRITABLE_DIRECTORY=/Users/pramsey/Library/Application Support/proj
>> DATABASE_PATH=/opt/homebrew/Cellar/proj/9.6.2/share/proj/proj.db" (compiled
>> against PROJ 9.6.2) LIBXML="2.9.13" LIBJSON="0.18" LIBPROTOBUF="1.5.2"
>> WAGYU="0.5.0 (Internal)" (core procs from "3.7.0dev
>> 3.6.0rc2-125-g747d7732b" need upgrade)
>>
>>
>>
>> On Wed, Oct 15, 2025 at 9:22?AM Antonio Valanzano <anvalanz at gmail.com>
>> wrote:
>>
>> I am following the "Introduction to PostGIS " tutorial  at
>> https://postgis.net/workshops/postgis-intro/
>>
>> and for chapter 26 "Dimensionally Extended 9-Intersection Model"  I am
>> trying to replicate the examples.
>>
>>
>>
>> If I use the two different versions of ST_Relate I do not obtain the same
>> result
>>
>>
>>
>> SELECT
>>   d.id,
>>   ST_Relate(d.geom, l.geom) as patternMatrix
>> FROM docks as d, lakes as l
>> WHERE ST_Relate(d.geom, l.geom, '1FF00F212') = true;
>> -- 1 row
>> "id" "patternmatrix"
>> 1    "1FF00F212"
>>
>>
>>
>> SELECT
>>   d.id,
>>   ST_Relate(d.geom, l.geom) as patternMatrix
>> FROM docks as d, lakes as l
>> WHERE ST_Relate(d.geom, l.geom) = '1FF00F212';
>> -- 2 rows
>> "id" "patternmatrix"
>> 1    "1FF00F212"
>> 2    "1FF00F212"
>>
>>
>>
>> Could someone give me an explanation of such a difference ?
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20251016/6bb2258d/attachment.htm>

From pramsey at cleverelephant.ca  Thu Oct 16 16:12:04 2025
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Thu, 16 Oct 2025 16:12:04 -0700
Subject: PostGIS 3.5.4 Released
Message-ID: <730931F3-BF25-4CEB-AFC0-91D649EFA6C6@cleverelephant.ca>


The PostGIS Team is pleased to announce the release of PostGIS 3.5.4.

https://postgis.net/2025/10/PostGIS-3.5.4/

This bug fix release addresses a number of issues that have been identified in the six months since version 3.5.3.

  - #5977, Fix downgrade protection with standard conforming strings off (Sandro Santilli)
  - #5951, Fix crash in ST_GetFaceEdges with corrupted topology (Sandro Santilli)
  - #5947, [topology] Fix crash in ST_ModEdgeHeal (Sandro Santilli)
  - #5925, #5946, [topology] Have GetFaceContainingPoint survive EMPTY edges (Sandro Santilli)
  - #5936, [topology] Do script-based upgrade in a single transaction (Sandro Santilli)
  - #5908, [topology] Fix crash in GetFaceContainingPoint (Sandro Santilli)
  - #5907, [topology] Fix crash in TopoGeo_AddPolygon with EMPTY input (Sandro Santilli)
  - #5922, [topology] Fix crash in TopoGeo_AddLinestring with EMPTY input (Sandro Santilli)
  - #5921, Crash freeing uninitialized pointer (Arsenii Mukhin)
  - #5912, Crash on GML with xlink and no prefix (Paul Ramsey)
  - #5905, Crash on deeply nested geometries (Paul Ramsey)
  - #5909, ST_ValueCount crashes on empty table (Paul Ramsey)
  - #5917, ST_Relate becomes unresponsive (Paul Ramsey)
  - #5923, CG_ExtrudeStraightSkeleton crashes on empty polygon (Lo?c Bartoletti)
  - #5935, Require GDAL 2.4 for postgis_raster
           and switch to GDALGetDataTypeSizeBytes (Lauren?iu Nicola)
  - GT-257, fix issue with xsltproc with path has spaces (Lauren?iu Nicola)
  - #5938, incorrect parameter order in ST_Relate caching (Paul Ramsey)
  - #5927, ST_IsCollection throwing exception (Paul Ramsey)
  - #5902, ST_PointFromText cannot create geometries with M (Paul Ramsey)
  - #5943, Memory leak in handling GEOS GeometryFactory (Megan Ma)
  - #5407, Use memset in place of bzero (Paul Ramsey)
  - #5082, LRS proportions clamped to [0,1] (Pawel Ostrowski)
  - #5985, Fix configure issue with Debian 12 and 13 (Regina Obe, Sandro Santilli)
  - #5991, CircularString distance error (Paul Ramsey)
  - #5994, Null pointer in ST_AsGeoJsonRow (Alexander Kukushkin)
  - #5989, ST_Distance error on CurvePolygon (Paul Ramsey)
  - #5962, Consistent clipping of MULTI/POINT (Paul Ramsey)
  - #5754, ST_ForcePolygonCCW reverses lines (Paul Ramsey)









From devrim at gunduz.org  Sat Oct 18 13:08:51 2025
From: devrim at gunduz.org (Devrim =?ISO-8859-1?Q?G=FCnd=FCz?=)
Date: Sat, 18 Oct 2025 23:08:51 +0300
Subject: PostGIS 3.5.4 Released
In-Reply-To: <730931F3-BF25-4CEB-AFC0-91D649EFA6C6@cleverelephant.ca>
References: <730931F3-BF25-4CEB-AFC0-91D649EFA6C6@cleverelephant.ca>
Message-ID: <ddbc70518bc4ad2b582535cef4b5326168515d65.camel@gunduz.org>

Hi,

On Thu, 2025-10-16 at 16:12 -0700, Paul Ramsey via postgis-users wrote:
> The PostGIS Team is pleased to announce the release of PostGIS 3.5.4.

Can you please upload the docs pdf file so that I can build the RPMs?
I'm actually looking for:

https://download.osgeo.org/postgis/docs/postgis-3.5.4-en.pdf

Thanks!

Regards,
-- 
Devrim G?nd?z
Open Source Solution Architect, PostgreSQL Major Contributor
BlueSky: @devrim.gunduz.org , @gunduz.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 858 bytes
Desc: This is a digitally signed message part
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20251018/872117d0/attachment.sig>

From lr at pcorp.us  Sat Oct 18 18:55:49 2025
From: lr at pcorp.us (Paragon Corporation)
Date: Sat, 18 Oct 2025 21:55:49 -0400
Subject: PostGIS 3.5.4 Released
In-Reply-To: <ddbc70518bc4ad2b582535cef4b5326168515d65.camel@gunduz.org>
References: <730931F3-BF25-4CEB-AFC0-91D649EFA6C6@cleverelephant.ca>
 <ddbc70518bc4ad2b582535cef4b5326168515d65.camel@gunduz.org>
Message-ID: <CAG29aDuTKcSQxxAEj44yHEaYSC+jHCM6zvNO3yEuHBQL4x=YwA@mail.gmail.com>

Done

On Sat, Oct 18, 2025 at 4:16?PM Devrim G?nd?z <devrim at gunduz.org> wrote:

> Hi,
>
> On Thu, 2025-10-16 at 16:12 -0700, Paul Ramsey via postgis-users wrote:
> > The PostGIS Team is pleased to announce the release of PostGIS 3.5.4.
>
> Can you please upload the docs pdf file so that I can build the RPMs?
> I'm actually looking for:
>
> https://download.osgeo.org/postgis/docs/postgis-3.5.4-en.pdf
>
> Thanks!
>
> Regards,
> --
> Devrim G?nd?z
> Open Source Solution Architect, PostgreSQL Major Contributor
> BlueSky: @devrim.gunduz.org , @gunduz.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20251018/b86b0794/attachment.htm>

From raine at gispo.fi  Mon Oct 20 00:11:21 2025
From: raine at gispo.fi (Raine Ekman)
Date: Mon, 20 Oct 2025 10:11:21 +0300
Subject: PostGIS 3.5.4 in PGDG packages?
Message-ID: <CAOgDZs71nu-Qnz6EAHg=kJY3Rr4vwL8oftMvto-P=riMumNWXQ@mail.gmail.com>

Hello,
it looks like the PGDG Debian/Ubuntu packages don't yet include
PostGIS 3.5.4 and from a look  at earlier versions it probably should
have appeared around Friday.
Is this a known issue in some part of the packaging pipeline or maybe
a misunderstanding on my end?

I tried digging in both PostGIS and PostgreSQL issue trackers, but I
don't think I found anything relevant.


Raine Ekman, raine at gispo.fi, 040 1825 903
Gispo?Suomi Oy, www.gispo.fi

From pramsey at cleverelephant.ca  Mon Oct 20 07:32:45 2025
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Mon, 20 Oct 2025 07:32:45 -0700
Subject: PostGIS 3.5.4 in PGDG packages?
In-Reply-To: <CAOgDZs71nu-Qnz6EAHg=kJY3Rr4vwL8oftMvto-P=riMumNWXQ@mail.gmail.com>
References: <CAOgDZs71nu-Qnz6EAHg=kJY3Rr4vwL8oftMvto-P=riMumNWXQ@mail.gmail.com>
Message-ID: <4B572E1F-8E8B-49A5-A783-6F01A196C156@cleverelephant.ca>

OS packaging and source releases are separate processes, not an automated pipeline. I assume the maintainer will turn the crack on their process in their own time.

P.

> On Oct 20, 2025, at 12:11?AM, Raine Ekman via postgis-users <postgis-users at lists.osgeo.org> wrote:
> 
> Hello,
> it looks like the PGDG Debian/Ubuntu packages don't yet include
> PostGIS 3.5.4 and from a look  at earlier versions it probably should
> have appeared around Friday.
> Is this a known issue in some part of the packaging pipeline or maybe
> a misunderstanding on my end?
> 
> I tried digging in both PostGIS and PostgreSQL issue trackers, but I
> don't think I found anything relevant.
> 
> 
> Raine Ekman, raine at gispo.fi, 040 1825 903
> Gispo?Suomi Oy, www.gispo.fi


From lr at pcorp.us  Mon Oct 20 07:40:10 2025
From: lr at pcorp.us (Regina Obe)
Date: Mon, 20 Oct 2025 10:40:10 -0400
Subject: PostGIS 3.5.4 in PGDG packages?
In-Reply-To: <CAOgDZs71nu-Qnz6EAHg=kJY3Rr4vwL8oftMvto-P=riMumNWXQ@mail.gmail.com>
References: <CAOgDZs71nu-Qnz6EAHg=kJY3Rr4vwL8oftMvto-P=riMumNWXQ@mail.gmail.com>
Message-ID: <001d01dc41cf$70ccadd0$52660970$@pcorp.us>

> Hello,
> it looks like the PGDG Debian/Ubuntu packages don't yet include PostGIS
> 3.5.4 and from a look  at earlier versions it probably should have appeared
> around Friday.
> Is this a known issue in some part of the packaging pipeline or maybe a
> misunderstanding on my end?
> 
> I tried digging in both PostGIS and PostgreSQL issue trackers, but I don't think I
> found anything relevant.
> 
> 
> Raine Ekman, raine at gispo.fi, 040 1825 903 Gispo?Suomi Oy, www.gispo.fi

Best to ask this question on  https://www.postgresql.org/list/pgsql-pkg-debian/




From giohappy at gmail.com  Mon Oct 27 02:46:26 2025
From: giohappy at gmail.com (G. Allegri)
Date: Mon, 27 Oct 2025 10:46:26 +0100
Subject: Why PostGIS sets a max value for SRID IDs?
Message-ID: <CAB4g1=xPdy8p2=tAm9LyO5V+4XXKzBqya1PXkUcVsR8Fe-kwbQ@mail.gmail.com>

Hello list,

I'm working on two projects where custom CRSs, with custom authorities and
IDs are provided.
Both projects use IDs with numbers beyond SRID_USR_MAX=998999 [1], which is
hardcoded in PostGIS for the spatial_ref_sys id field values.
I can use the auth_id, of course, but having to reassign an id < 998999 is
a bit problematic for two reasons:

- I have custom transformation pipelines defined inside the proj.db, where
the custom IDs are defined for CRSs.
- other softwares (QGIS, Geoserver) can use the custom IDs but they cannot
match the geometries SRIDs returned PostGIS

I wonder if there's a technical reason for the SRID_USR_MAX constant, and
if there's any change to remove it in the future.
And I wonder if others have faced the problems I'm having due to this, and
what are the solutions they came up with.

Thanks,
Giovanni

[1]
https://github.com/postgis/postgis/blob/5dc95f1bc3047b048128616d4543b603b8bbdca7/configure.ac#L1554
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20251027/520a9bcc/attachment.htm>

From me at komzpa.net  Mon Oct 27 05:17:38 2025
From: me at komzpa.net (=?UTF-8?Q?Darafei_=22Kom=D1=8Fpa=22_Praliaskouski?=)
Date: Mon, 27 Oct 2025 16:17:38 +0400
Subject: Why PostGIS sets a max value for SRID IDs?
In-Reply-To: <CAB4g1=xPdy8p2=tAm9LyO5V+4XXKzBqya1PXkUcVsR8Fe-kwbQ@mail.gmail.com>
References: <CAB4g1=xPdy8p2=tAm9LyO5V+4XXKzBqya1PXkUcVsR8Fe-kwbQ@mail.gmail.com>
Message-ID: <CAC8Q8t+vw8h_-X9T6a1M6v0nknYBQHOdSGh7dcpYK7G2Zfd-hA@mail.gmail.com>

Hi,

The technical reason is that SRID gets packed into geometry headers and
there's only 21 bits there for it.
PostGIS reserves the values above 998999 for internal transformation
pipelines that support geography data type
A change to this will require significant redesign in the way PostGIS
handles SRIDs.
If you need this, sharing more information about the actual usage scenarios
will be helpful so a new design can be created.

On Mon, Oct 27, 2025 at 1:46?PM G. Allegri <giohappy at gmail.com> wrote:

> Hello list,
>
> I'm working on two projects where custom CRSs, with custom authorities and
> IDs are provided.
> Both projects use IDs with numbers beyond SRID_USR_MAX=998999 [1], which
> is hardcoded in PostGIS for the spatial_ref_sys id field values.
> I can use the auth_id, of course, but having to reassign an id < 998999 is
> a bit problematic for two reasons:
>
> - I have custom transformation pipelines defined inside the proj.db, where
> the custom IDs are defined for CRSs.
> - other softwares (QGIS, Geoserver) can use the custom IDs but they cannot
> match the geometries SRIDs returned PostGIS
>
> I wonder if there's a technical reason for the SRID_USR_MAX constant, and
> if there's any change to remove it in the future.
> And I wonder if others have faced the problems I'm having due to this, and
> what are the solutions they came up with.
>
> Thanks,
> Giovanni
>
> [1]
> https://github.com/postgis/postgis/blob/5dc95f1bc3047b048128616d4543b603b8bbdca7/configure.ac#L1554
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20251027/c16c2616/attachment.htm>

From lr at pcorp.us  Mon Oct 27 06:11:54 2025
From: lr at pcorp.us (Regina Obe)
Date: Mon, 27 Oct 2025 09:11:54 -0400
Subject: Why PostGIS sets a max value for SRID IDs?
In-Reply-To: <CAB4g1=xPdy8p2=tAm9LyO5V+4XXKzBqya1PXkUcVsR8Fe-kwbQ@mail.gmail.com>
References: <CAB4g1=xPdy8p2=tAm9LyO5V+4XXKzBqya1PXkUcVsR8Fe-kwbQ@mail.gmail.com>
Message-ID: <000e01dc4743$446653d0$cd32fb70$@pcorp.us>

I vaguely recall someone complaining about this 15 years ago, but not since then.

 

Paul can better speak for the reason, but I think it was because we needed to fit it into the header of the geometry and still have enough bits left for the geometry type etc and 2 bits extra for growth.

 

So I would say it?s very unlikely we?d lift this restriction.

 

From: G. Allegri <giohappy at gmail.com> 
Sent: Monday, October 27, 2025 5:46 AM
To: postgis-users at lists.osgeo.org
Subject: Why PostGIS sets a max value for SRID IDs?

 

Hello list,

 

I'm working on two projects where custom CRSs, with custom authorities and IDs are provided.

Both projects use IDs with numbers beyond SRID_USR_MAX=998999 [1], which is hardcoded in PostGIS for the spatial_ref_sys id field values.

I can use the auth_id, of course, but having to reassign an id < 998999 is a bit problematic for two reasons:

 

- I have custom transformation pipelines defined inside the proj.db, where the custom IDs are defined for CRSs. 

- other softwares (QGIS, Geoserver) can use the custom IDs but they cannot match the geometries SRIDs returned PostGIS

 

I wonder if there's a technical reason for the SRID_USR_MAX constant, and if there's any change to remove it in the future.

And I wonder if others have faced the problems I'm having due to this, and what are the solutions they came up with.

 

Thanks,

Giovanni

 

[1] https://github.com/postgis/postgis/blob/5dc95f1bc3047b048128616d4543b603b8bbdca7/configure.ac#L1554

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20251027/4800cc53/attachment.htm>

From giohappy at gmail.com  Mon Oct 27 06:15:31 2025
From: giohappy at gmail.com (G. Allegri)
Date: Mon, 27 Oct 2025 14:15:31 +0100
Subject: Why PostGIS sets a max value for SRID IDs?
In-Reply-To: <CAC8Q8t+vw8h_-X9T6a1M6v0nknYBQHOdSGh7dcpYK7G2Zfd-hA@mail.gmail.com>
References: <CAB4g1=xPdy8p2=tAm9LyO5V+4XXKzBqya1PXkUcVsR8Fe-kwbQ@mail.gmail.com>
 <CAC8Q8t+vw8h_-X9T6a1M6v0nknYBQHOdSGh7dcpYK7G2Zfd-hA@mail.gmail.com>
Message-ID: <CAB4g1=zaSsegDBTFyfu-oYBaZ9ibEr2VZcAAo6rhpO=M5p2mQw@mail.gmail.com>

Thanks Darafei,

The scenario is the following.

I have a custom proj.db which contains custom CRSs and transformations
defined with auth ids beyond the PostGIS limit.
This proj.db is employed in several contexts, including GDAL scripts, QGIS,
and Geoserver, with the Proj lib and Geotools handling the custom CRSs as
expected.

The problem happens when I need to handle the data with PostGIS. I must
configure the custom CRSs (it's still not totally clear to me the
relationship between the spatial_ref_sys and the proj.db in PostGIS by the
way) and assign them to my data.

The various softwares write and read data to/from PostGIS and when it comes
to setting/reading the SRIDs, the problems with the mismatched IDs arise.

Giovanni


Il lun 27 ott 2025, 13:17 Darafei "Kom?pa" Praliaskouski <me at komzpa.net> ha
scritto:

> Hi,
>
> The technical reason is that SRID gets packed into geometry headers and
> there's only 21 bits there for it.
> PostGIS reserves the values above 998999 for internal transformation
> pipelines that support geography data type
> A change to this will require significant redesign in the way PostGIS
> handles SRIDs.
> If you need this, sharing more information about the actual usage
> scenarios will be helpful so a new design can be created.
>
> On Mon, Oct 27, 2025 at 1:46?PM G. Allegri <giohappy at gmail.com> wrote:
>
>> Hello list,
>>
>> I'm working on two projects where custom CRSs, with custom authorities
>> and IDs are provided.
>> Both projects use IDs with numbers beyond SRID_USR_MAX=998999 [1], which
>> is hardcoded in PostGIS for the spatial_ref_sys id field values.
>> I can use the auth_id, of course, but having to reassign an id < 998999
>> is a bit problematic for two reasons:
>>
>> - I have custom transformation pipelines defined inside the proj.db,
>> where the custom IDs are defined for CRSs.
>> - other softwares (QGIS, Geoserver) can use the custom IDs but they
>> cannot match the geometries SRIDs returned PostGIS
>>
>> I wonder if there's a technical reason for the SRID_USR_MAX constant, and
>> if there's any change to remove it in the future.
>> And I wonder if others have faced the problems I'm having due to this,
>> and what are the solutions they came up with.
>>
>> Thanks,
>> Giovanni
>>
>> [1]
>> https://github.com/postgis/postgis/blob/5dc95f1bc3047b048128616d4543b603b8bbdca7/configure.ac#L1554
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20251027/5aca488a/attachment.htm>

From vincent.ml at oslandia.com  Mon Oct 27 06:34:29 2025
From: vincent.ml at oslandia.com (Vincent Picavet)
Date: Mon, 27 Oct 2025 14:34:29 +0100
Subject: Why PostGIS sets a max value for SRID IDs?
In-Reply-To: <000e01dc4743$446653d0$cd32fb70$@pcorp.us>
References: <CAB4g1=xPdy8p2=tAm9LyO5V+4XXKzBqya1PXkUcVsR8Fe-kwbQ@mail.gmail.com>
 <000e01dc4743$446653d0$cd32fb70$@pcorp.us>
Message-ID: <ae5bd64c-4848-4f7c-970c-d1aa92fe3e6e@oslandia.com>

Hi,

On 27/10/2025 14:11, Regina Obe wrote:
>
> I vaguely recall someone complaining about this 15 years ago, but not since then.
>
I guess the ones complaining at the time was because French IGN defined their own SRS and chose for very unknown reasons to allocate their own reeeeaaaaaally long SRID, therefore not compatible with PostGIS limitations.

And in the end there was a lot more complaints against IGN for doing that, than against PostGIS for its limitations.

I do not know who your authority is, but there is a good chance that it is easier for them to change their ID than PostGIS to lift the constraint, given the consequences. Good luck with that though.

Vincent


> Paul can better speak for the reason, but I think it was because we needed to fit it into the header of the geometry and still have enough bits left for the geometry type etc and 2 bits extra for growth.
>
> So I would say it?s very unlikely we?d lift this restriction.
>
> *From:*G. Allegri <giohappy at gmail.com>
> *Sent:* Monday, October 27, 2025 5:46 AM
> *To:* postgis-users at lists.osgeo.org
> *Subject:* Why PostGIS sets a max value for SRID IDs?
>
> Hello list,
>
> I'm working on two projects where custom CRSs, with custom authorities and IDs are provided.
>
> Both projects use IDs with numbers beyond SRID_USR_MAX=998999 [1], which is hardcoded?in PostGIS for the spatial_ref_sys id field values.
>
> I can use the auth_id, of course, but having to reassign an id < 998999 is a bit problematic for two reasons:
>
> - I have custom transformation pipelines defined inside the proj.db, where the custom IDs are defined for CRSs.
>
> - other softwares (QGIS, Geoserver) can use the custom IDs but they cannot match the geometries SRIDs returned PostGIS
>
> I wonder if there's a technical?reason for the SRID_USR_MAX constant, and if there's any change to remove it in the future.
>
> And I wonder if others have faced the problems I'm having due to this, and what are the solutions they came?up with.
>
> Thanks,
>
> Giovanni
>
> [1] https://github.com/postgis/postgis/blob/5dc95f1bc3047b048128616d4543b603b8bbdca7/configure.ac#L1554
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20251027/143c6b08/attachment.htm>

From klassen.js at gmail.com  Mon Oct 27 11:37:00 2025
From: klassen.js at gmail.com (Jim Klassen)
Date: Mon, 27 Oct 2025 13:37:00 -0500
Subject: Why PostGIS sets a max value for SRID IDs?
In-Reply-To: <CAB4g1=zaSsegDBTFyfu-oYBaZ9ibEr2VZcAAo6rhpO=M5p2mQw@mail.gmail.com>
References: <CAB4g1=xPdy8p2=tAm9LyO5V+4XXKzBqya1PXkUcVsR8Fe-kwbQ@mail.gmail.com>
 <CAC8Q8t+vw8h_-X9T6a1M6v0nknYBQHOdSGh7dcpYK7G2Zfd-hA@mail.gmail.com>
 <CAB4g1=zaSsegDBTFyfu-oYBaZ9ibEr2VZcAAo6rhpO=M5p2mQw@mail.gmail.com>
Message-ID: <0b3a653a-c668-4b97-9da9-1c18afebf4ab@gmail.com>

How does the "srid" column in spatial_ref_sys relate to the CODE in Proj?

I had always assumed that the PostGIS "srid" was independent of the ("auth_name", "auth_srid") tuple ("AUTH_NAME", "CODE" in proj.db) on account of them being separate columns in spatial_ref_sys, and that in most cases "srid" and "auth_srid" just happened to match for the convenience of humans who might happen to recognize a EPSG code.

Back in the proj4 days when I was regularly dealing with a CRS that didn't have an assigned EPSG code, OGR would create a new spatial_ref_sys row with a "srid" (usually starting at 900914) that didn't match anything else in the row (auth_name, auth_srid, srtext, proj4text).

I would also expect a 1-to-1 mapping between PostGIS "srid" and "auth_srid" to be impossible because the different authorities can have overlapping codes.? There doesn't appear to be any duplicate "auth_srid"s in my spatial_ref_sys table.? However, looking at my installed proj.db database, this happens a few times (for 10820, 30165, 30170, and 30175).? 10820 looks like ESRI and EPSG separately define essentially the same CRS for that code.? And the 30xxx codes are all EPSG, IAU_2015 conflicts (Moon) so unlikely to be mistaken in practice.

psql:
 ? ? select auth_srid from spatial_ref_sys group by auth_srid having count(auth_srid) > 1;

sqlite3 proj.db:
 ? ? select code, count(*) c from projected_crs group by code having c > 1;
 ? ? select * from projected_crs where code in (10820,30165,30170,30175) order by code, auth_name;

On 10/27/25 8:15 AM, G. Allegri wrote:
> Thanks Darafei,
>
> The scenario is the following.
>
> I have a custom proj.db which contains custom CRSs and transformations defined with auth ids beyond the PostGIS limit.
> This proj.db is employed in several contexts, including GDAL scripts, QGIS, and Geoserver, with the Proj lib and Geotools handling the custom CRSs as expected.
>
> The problem happens when I need to handle the data with PostGIS. I must configure the custom CRSs (it's still not totally clear to me the relationship between the spatial_ref_sys and the proj.db in PostGIS by the way) and assign them to my data.
>
> The various softwares write and read data to/from PostGIS and when it comes to setting/reading the SRIDs, the problems with the mismatched IDs arise.
>
> Giovanni
>
>
> Il lun 27 ott 2025, 13:17 Darafei "Kom?pa" Praliaskouski <me at komzpa.net> ha scritto:
>
>     Hi,
>
>     The technical reason is that SRID gets packed into geometry headers and there's only 21 bits there for it.
>     PostGIS reserves the values above 998999 for internal transformation pipelines that support geography data type
>     A change to this will require significant?redesign in the way PostGIS handles SRIDs.
>     If you need this, sharing more information about the actual usage scenarios will be helpful so?a new?design can be created.
>
>     On Mon, Oct 27, 2025 at 1:46?PM G. Allegri <giohappy at gmail.com> wrote:
>
>         Hello list,
>
>         I'm working on two projects where custom CRSs, with custom authorities and IDs are provided.
>         Both projects use IDs with numbers beyond SRID_USR_MAX=998999 [1], which is hardcoded?in PostGIS for the spatial_ref_sys id field values.
>         I can use the auth_id, of course, but having to reassign an id < 998999 is a bit problematic for two reasons:
>
>         - I have custom transformation pipelines defined inside the proj.db, where the custom IDs are defined for CRSs.
>         - other softwares (QGIS, Geoserver) can use the custom IDs but they cannot match the geometries SRIDs returned PostGIS
>
>         I wonder if there's a technical?reason for the SRID_USR_MAX constant, and if there's any change to remove it in the future.
>         And I wonder if others have faced the problems I'm having due to this, and what are the solutions they came?up with.
>
>         Thanks,
>         Giovanni
>
>         [1] https://github.com/postgis/postgis/blob/5dc95f1bc3047b048128616d4543b603b8bbdca7/configure.ac#L1554
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20251027/17843808/attachment.htm>

From pramsey at cleverelephant.ca  Mon Oct 27 11:45:34 2025
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Mon, 27 Oct 2025 11:45:34 -0700
Subject: Why PostGIS sets a max value for SRID IDs?
In-Reply-To: <0b3a653a-c668-4b97-9da9-1c18afebf4ab@gmail.com>
References: <CAB4g1=xPdy8p2=tAm9LyO5V+4XXKzBqya1PXkUcVsR8Fe-kwbQ@mail.gmail.com>
 <CAC8Q8t+vw8h_-X9T6a1M6v0nknYBQHOdSGh7dcpYK7G2Zfd-hA@mail.gmail.com>
 <CAB4g1=zaSsegDBTFyfu-oYBaZ9ibEr2VZcAAo6rhpO=M5p2mQw@mail.gmail.com>
 <0b3a653a-c668-4b97-9da9-1c18afebf4ab@gmail.com>
Message-ID: <CACowWR29s+a=TGenQ6ZUXGCSd-QpTV9zTLMLDCuZqaJFasDWUQ@mail.gmail.com>

On Mon, Oct 27, 2025 at 11:37?AM Jim Klassen <klassen.js at gmail.com> wrote:

> How does the "srid" column in spatial_ref_sys relate to the CODE in Proj?
>
> I had always assumed that the PostGIS "srid" was independent of the
> ("auth_name", "auth_srid") tuple ("AUTH_NAME", "CODE" in proj.db) on
> account of them being separate columns in spatial_ref_sys, and that in most
> cases "srid" and "auth_srid" just happened to match for the convenience of
> humans who might happen to recognize a EPSG code.
>

This assumption is correct. The PostGIS SRID is a number internal to the
PostGIS instance, while the AUTH_NAME/AUTH_SRID pair provide the external
code. The fact that they are almost always 1:1 the same is a helpful
affordance, but not indicative of any requirement that the SRID in PostGIS
be the same as an SRID from outside. (For a dramatic example of this, the
handling of Oracle Spatial of SRID numbers unlinked the internal SRID
number from the external number.)


> I would also expect a 1-to-1 mapping between PostGIS "srid" and
> "auth_srid" to be impossible because the different authorities can have
> overlapping codes.  There doesn't appear to be any duplicate "auth_srid"s
> in my spatial_ref_sys table.  However, looking at my installed proj.db
> database, this happens a few times (for 10820, 30165, 30170, and 30175).
> 10820 looks like ESRI and EPSG separately define essentially the same CRS
> for that code.  And the 30xxx codes are all EPSG, IAU_2015 conflicts (Moon)
> so unlikely to be mistaken in practice.
>

Mostly the external ids don't conflict, but that is not a guarantee, as you
note, and the AUTH_NAME/AUTH_SRID pairing along with the independence of
the internal SRID is how we deal with that.

P.


>
> psql:
>     select auth_srid from spatial_ref_sys group by auth_srid having
> count(auth_srid) > 1;
>
> sqlite3 proj.db:
>     select code, count(*) c from projected_crs group by code having c > 1;
>     select * from projected_crs where code in (10820,30165,30170,30175)
> order by code, auth_name;
>
> On 10/27/25 8:15 AM, G. Allegri wrote:
>
> Thanks Darafei,
>
> The scenario is the following.
>
> I have a custom proj.db which contains custom CRSs and transformations
> defined with auth ids beyond the PostGIS limit.
> This proj.db is employed in several contexts, including GDAL scripts,
> QGIS, and Geoserver, with the Proj lib and Geotools handling the custom
> CRSs as expected.
>
> The problem happens when I need to handle the data with PostGIS. I must
> configure the custom CRSs (it's still not totally clear to me the
> relationship between the spatial_ref_sys and the proj.db in PostGIS by the
> way) and assign them to my data.
>
> The various softwares write and read data to/from PostGIS and when it
> comes to setting/reading the SRIDs, the problems with the mismatched IDs
> arise.
>
> Giovanni
>
>
> Il lun 27 ott 2025, 13:17 Darafei "Kom?pa" Praliaskouski <me at komzpa.net>
> ha scritto:
>
>> Hi,
>>
>> The technical reason is that SRID gets packed into geometry headers and
>> there's only 21 bits there for it.
>> PostGIS reserves the values above 998999 for internal transformation
>> pipelines that support geography data type
>> A change to this will require significant redesign in the way PostGIS
>> handles SRIDs.
>> If you need this, sharing more information about the actual usage
>> scenarios will be helpful so a new design can be created.
>>
>> On Mon, Oct 27, 2025 at 1:46?PM G. Allegri <giohappy at gmail.com> wrote:
>>
>>> Hello list,
>>>
>>> I'm working on two projects where custom CRSs, with custom authorities
>>> and IDs are provided.
>>> Both projects use IDs with numbers beyond SRID_USR_MAX=998999 [1], which
>>> is hardcoded in PostGIS for the spatial_ref_sys id field values.
>>> I can use the auth_id, of course, but having to reassign an id < 998999
>>> is a bit problematic for two reasons:
>>>
>>> - I have custom transformation pipelines defined inside the proj.db,
>>> where the custom IDs are defined for CRSs.
>>> - other softwares (QGIS, Geoserver) can use the custom IDs but they
>>> cannot match the geometries SRIDs returned PostGIS
>>>
>>> I wonder if there's a technical reason for the SRID_USR_MAX constant,
>>> and if there's any change to remove it in the future.
>>> And I wonder if others have faced the problems I'm having due to this,
>>> and what are the solutions they came up with.
>>>
>>> Thanks,
>>> Giovanni
>>>
>>> [1]
>>> https://github.com/postgis/postgis/blob/5dc95f1bc3047b048128616d4543b603b8bbdca7/configure.ac#L1554
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20251027/43be481c/attachment.htm>

From shishaozhong at gmail.com  Wed Oct 29 07:10:18 2025
From: shishaozhong at gmail.com (Shaozhong SHI)
Date: Wed, 29 Oct 2025 14:10:18 +0000
Subject: Spatial join issues
Message-ID: <CA+i5JwbhzorZkLjkdDVkmCr4QX=Ufn8i=AqCG-PM7aHkGHwxWQ@mail.gmail.com>

  Visually, there appears some matching polygons.  Even if two geometries
represent the same shape visually, they might not be considered equal due
to tiny differences in precision or metadata.  Have you encountered
problems of failure of spatial join?  How did you overcome the problems?
Regards, David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20251029/dccfd9fa/attachment.htm>

From gdt at lexort.com  Wed Oct 29 07:36:43 2025
From: gdt at lexort.com (Greg Troxel)
Date: Wed, 29 Oct 2025 10:36:43 -0400
Subject: Spatial join issues
In-Reply-To: <CA+i5JwbhzorZkLjkdDVkmCr4QX=Ufn8i=AqCG-PM7aHkGHwxWQ@mail.gmail.com>
 (Shaozhong SHI's message of "Wed, 29 Oct 2025 14:10:18 +0000")
References: <CA+i5JwbhzorZkLjkdDVkmCr4QX=Ufn8i=AqCG-PM7aHkGHwxWQ@mail.gmail.com>
Message-ID: <rmiecql7p1g.fsf@s1.lexort.com>

Shaozhong SHI <shishaozhong at gmail.com> writes:

>   Visually, there appears some matching polygons.  Even if two geometries
> represent the same shape visually, they might not be considered equal due
> to tiny differences in precision or metadata.  Have you encountered
> problems of failure of spatial join?  How did you overcome the problems?
> Regards, David

Could you post your example polygons, and the queries you are using?
Your question is much too open ended.  It even sounds like it might be a
request for help with GIS homework, but it's hard to tell :-)


From shishaozhong at gmail.com  Wed Oct 29 10:00:03 2025
From: shishaozhong at gmail.com (Shaozhong SHI)
Date: Wed, 29 Oct 2025 17:00:03 +0000
Subject: Spatial join issues
In-Reply-To: <rmiecql7p1g.fsf@s1.lexort.com>
References: <CA+i5JwbhzorZkLjkdDVkmCr4QX=Ufn8i=AqCG-PM7aHkGHwxWQ@mail.gmail.com>
 <rmiecql7p1g.fsf@s1.lexort.com>
Message-ID: <CA+i5JwYiNtAcw2AE=gw_Fd-PrXO-3JbYSp3-gNEkg4eZp2BdUg@mail.gmail.com>

This is very challenging.  Take my words for it.  Try on any polygons you
created and modified.

On Wed, 29 Oct 2025 at 14:36, Greg Troxel <gdt at lexort.com> wrote:

> Shaozhong SHI <shishaozhong at gmail.com> writes:
>
> >   Visually, there appears some matching polygons.  Even if two geometries
> > represent the same shape visually, they might not be considered equal due
> > to tiny differences in precision or metadata.  Have you encountered
> > problems of failure of spatial join?  How did you overcome the problems?
> > Regards, David
>
> Could you post your example polygons, and the queries you are using?
> Your question is much too open ended.  It even sounds like it might be a
> request for help with GIS homework, but it's hard to tell :-)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20251029/73a994eb/attachment.htm>

From pramsey at cleverelephant.ca  Wed Oct 29 10:17:02 2025
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Wed, 29 Oct 2025 10:17:02 -0700
Subject: Spatial join issues
In-Reply-To: <CA+i5JwYiNtAcw2AE=gw_Fd-PrXO-3JbYSp3-gNEkg4eZp2BdUg@mail.gmail.com>
References: <CA+i5JwbhzorZkLjkdDVkmCr4QX=Ufn8i=AqCG-PM7aHkGHwxWQ@mail.gmail.com>
 <rmiecql7p1g.fsf@s1.lexort.com>
 <CA+i5JwYiNtAcw2AE=gw_Fd-PrXO-3JbYSp3-gNEkg4eZp2BdUg@mail.gmail.com>
Message-ID: <CACowWR2r6ZUfonhqzd7DOBKUWGpbsfjAviAOVgExihy8FstiOg@mail.gmail.com>

Greg isn't passing judgement on how hard your problem is, he's saying you
haven't explained it particularly well. Pictures help. Taking a guess at
what you mean, here's some SQL that creates two polygons, with slightly
different structure, and slightly different coordinates, that describe the
same general space in the universe, and then massages them until they pass
an equals test.

WITH p AS (
  SELECT 'POLYGON((0 0, 10 0, 10 10, 0 10, 0 0))'::geometry AS p1,
         'POLYGON((0 0, 10 0, 10 5, 10 10, 0 10, 0 0))'::geometry AS p2
),
shifted AS (
  SELECT p1, ST_Translate(p2, 0.0001, 0.0001) AS p2
  FROM p
),
rp AS (
  SELECT ST_ReducePrecision(p1,0.1) AS p1,
         ST_ReducePrecision(p2,0.1) AS p2
  FROM shifted
),
snap AS (
  SELECT ST_Snap(p1,p2,0.1) AS p1,
         ST_Snap(p2,p1,0.1) AS p2
  FROM rp
)
SELECT ST_AsText(shifted.p1) AS p1_orig,
       ST_AsText(shifted.p2) AS p2_orig,
       ST_AsText(snap.p1) AS p1_snap,
       ST_AsText(snap.p2) AS p2_snap,
       ST_Equals(snap.p1, snap.p2)
FROM snap, shifted;

-[ RECORD 1
]--------------------------------------------------------------------------------------------------
p1_orig   | POLYGON((0 0,10 0,10 10,0 10,0 0))
p2_orig   | POLYGON((0.0001 0.0001,10.0001 0.0001,10.0001 5.0001,10.0001
10.0001,0.0001 10.0001,0.0001 0.0001))
p1_snap   | POLYGON((0 10,10 10,10 5,10 0,0 0,0 10))
p2_snap   | POLYGON((0 10,10 10,10 5,10 0,0 0,0 10))
st_equals | t

On Wed, Oct 29, 2025 at 10:00?AM Shaozhong SHI <shishaozhong at gmail.com>
wrote:

> This is very challenging.  Take my words for it.  Try on any polygons you
> created and modified.
>
> On Wed, 29 Oct 2025 at 14:36, Greg Troxel <gdt at lexort.com> wrote:
>
>> Shaozhong SHI <shishaozhong at gmail.com> writes:
>>
>> >   Visually, there appears some matching polygons.  Even if two
>> geometries
>> > represent the same shape visually, they might not be considered equal
>> due
>> > to tiny differences in precision or metadata.  Have you encountered
>> > problems of failure of spatial join?  How did you overcome the problems?
>> > Regards, David
>>
>> Could you post your example polygons, and the queries you are using?
>> Your question is much too open ended.  It even sounds like it might be a
>> request for help with GIS homework, but it's hard to tell :-)
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20251029/c6c9b856/attachment.htm>

From pramsey at cleverelephant.ca  Wed Oct 29 10:25:08 2025
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Wed, 29 Oct 2025 10:25:08 -0700
Subject: Spatial join issues
In-Reply-To: <CACowWR2r6ZUfonhqzd7DOBKUWGpbsfjAviAOVgExihy8FstiOg@mail.gmail.com>
References: <CA+i5JwbhzorZkLjkdDVkmCr4QX=Ufn8i=AqCG-PM7aHkGHwxWQ@mail.gmail.com>
 <rmiecql7p1g.fsf@s1.lexort.com>
 <CA+i5JwYiNtAcw2AE=gw_Fd-PrXO-3JbYSp3-gNEkg4eZp2BdUg@mail.gmail.com>
 <CACowWR2r6ZUfonhqzd7DOBKUWGpbsfjAviAOVgExihy8FstiOg@mail.gmail.com>
Message-ID: <CACowWR3MDzQcsMLKpa4CdB6mOONggS6K3mj7xV=Eywwr_9mmbQ@mail.gmail.com>

I would imagine that my little example is a bit error prone, but the
classic solution to "do these differently structured things with slightly
different coordinates cover basically the same space" is to inspect the
ratio  "area(intersection(a, b)) / area(union(a, b))". You can see
intuitively how the more the same two polygons are, the closer that ratio
will be to 1.0.

WITH p AS (
  SELECT 'POLYGON((0 0, 10 0, 10 10, 0 10, 0 0))'::geometry AS p1,
         'POLYGON((0 0, 10 0, 10 5, 10 10, 0 10, 0 0))'::geometry AS p2,
         0.001 AS shift
),
shifted AS (
  SELECT p1, ST_Translate(p2, shift, shift) AS p2, shift
  FROM p
),
areas AS (
  SELECT ST_Area(ST_Union(p1, p2, shift/10)) AS area_union,
         ST_Area(ST_Intersection(p1, p2, shift/10)) AS area_inter
  FROM shifted
)
SELECT ST_AsText(shifted.p1) AS p1_orig,
       ST_AsText(shifted.p2) AS p2_orig,
       area_inter/area_union AS ratio
FROM areas, shifted;

On Wed, Oct 29, 2025 at 10:17?AM Paul Ramsey <pramsey at cleverelephant.ca>
wrote:

> Greg isn't passing judgement on how hard your problem is, he's saying you
> haven't explained it particularly well. Pictures help. Taking a guess at
> what you mean, here's some SQL that creates two polygons, with slightly
> different structure, and slightly different coordinates, that describe the
> same general space in the universe, and then massages them until they pass
> an equals test.
>
> WITH p AS (
>   SELECT 'POLYGON((0 0, 10 0, 10 10, 0 10, 0 0))'::geometry AS p1,
>          'POLYGON((0 0, 10 0, 10 5, 10 10, 0 10, 0 0))'::geometry AS p2
> ),
> shifted AS (
>   SELECT p1, ST_Translate(p2, 0.0001, 0.0001) AS p2
>   FROM p
> ),
> rp AS (
>   SELECT ST_ReducePrecision(p1,0.1) AS p1,
>          ST_ReducePrecision(p2,0.1) AS p2
>   FROM shifted
> ),
> snap AS (
>   SELECT ST_Snap(p1,p2,0.1) AS p1,
>          ST_Snap(p2,p1,0.1) AS p2
>   FROM rp
> )
> SELECT ST_AsText(shifted.p1) AS p1_orig,
>        ST_AsText(shifted.p2) AS p2_orig,
>        ST_AsText(snap.p1) AS p1_snap,
>        ST_AsText(snap.p2) AS p2_snap,
>        ST_Equals(snap.p1, snap.p2)
> FROM snap, shifted;
>
> -[ RECORD 1
> ]--------------------------------------------------------------------------------------------------
> p1_orig   | POLYGON((0 0,10 0,10 10,0 10,0 0))
> p2_orig   | POLYGON((0.0001 0.0001,10.0001 0.0001,10.0001 5.0001,10.0001
> 10.0001,0.0001 10.0001,0.0001 0.0001))
> p1_snap   | POLYGON((0 10,10 10,10 5,10 0,0 0,0 10))
> p2_snap   | POLYGON((0 10,10 10,10 5,10 0,0 0,0 10))
> st_equals | t
>
> On Wed, Oct 29, 2025 at 10:00?AM Shaozhong SHI <shishaozhong at gmail.com>
> wrote:
>
>> This is very challenging.  Take my words for it.  Try on any polygons you
>> created and modified.
>>
>> On Wed, 29 Oct 2025 at 14:36, Greg Troxel <gdt at lexort.com> wrote:
>>
>>> Shaozhong SHI <shishaozhong at gmail.com> writes:
>>>
>>> >   Visually, there appears some matching polygons.  Even if two
>>> geometries
>>> > represent the same shape visually, they might not be considered equal
>>> due
>>> > to tiny differences in precision or metadata.  Have you encountered
>>> > problems of failure of spatial join?  How did you overcome the
>>> problems?
>>> > Regards, David
>>>
>>> Could you post your example polygons, and the queries you are using?
>>> Your question is much too open ended.  It even sounds like it might be a
>>> request for help with GIS homework, but it's hard to tell :-)
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20251029/603b805a/attachment.htm>

From shishaozhong at gmail.com  Wed Oct 29 10:39:32 2025
From: shishaozhong at gmail.com (Shaozhong SHI)
Date: Wed, 29 Oct 2025 17:39:32 +0000
Subject: Spatial join issues
In-Reply-To: <CACowWR3MDzQcsMLKpa4CdB6mOONggS6K3mj7xV=Eywwr_9mmbQ@mail.gmail.com>
References: <CA+i5JwbhzorZkLjkdDVkmCr4QX=Ufn8i=AqCG-PM7aHkGHwxWQ@mail.gmail.com>
 <rmiecql7p1g.fsf@s1.lexort.com>
 <CA+i5JwYiNtAcw2AE=gw_Fd-PrXO-3JbYSp3-gNEkg4eZp2BdUg@mail.gmail.com>
 <CACowWR2r6ZUfonhqzd7DOBKUWGpbsfjAviAOVgExihy8FstiOg@mail.gmail.com>
 <CACowWR3MDzQcsMLKpa4CdB6mOONggS6K3mj7xV=Eywwr_9mmbQ@mail.gmail.com>
Message-ID: <CA+i5JwZU5tny-w=PqCGptOOxNe_g+p42RFGPa7OGgdoR8fO3pQ@mail.gmail.com>

Very clever.  I will spend time to understand.  Approximate equal sounds
very interesting.   I just did intersection.  Expecting a polygon but got
partial lines.  Suspect only part of lines of two seemingly the same
polygons intersect. Thanks.

On Wed, 29 Oct 2025, 17:25 Paul Ramsey, <pramsey at cleverelephant.ca> wrote:

> I would imagine that my little example is a bit error prone, but the
> classic solution to "do these differently structured things with slightly
> different coordinates cover basically the same space" is to inspect the
> ratio  "area(intersection(a, b)) / area(union(a, b))". You can see
> intuitively how the more the same two polygons are, the closer that ratio
> will be to 1.0.
>
> WITH p AS (
>   SELECT 'POLYGON((0 0, 10 0, 10 10, 0 10, 0 0))'::geometry AS p1,
>          'POLYGON((0 0, 10 0, 10 5, 10 10, 0 10, 0 0))'::geometry AS p2,
>          0.001 AS shift
> ),
> shifted AS (
>   SELECT p1, ST_Translate(p2, shift, shift) AS p2, shift
>   FROM p
> ),
> areas AS (
>   SELECT ST_Area(ST_Union(p1, p2, shift/10)) AS area_union,
>          ST_Area(ST_Intersection(p1, p2, shift/10)) AS area_inter
>   FROM shifted
> )
> SELECT ST_AsText(shifted.p1) AS p1_orig,
>        ST_AsText(shifted.p2) AS p2_orig,
>        area_inter/area_union AS ratio
> FROM areas, shifted;
>
> On Wed, Oct 29, 2025 at 10:17?AM Paul Ramsey <pramsey at cleverelephant.ca>
> wrote:
>
>> Greg isn't passing judgement on how hard your problem is, he's saying you
>> haven't explained it particularly well. Pictures help. Taking a guess at
>> what you mean, here's some SQL that creates two polygons, with slightly
>> different structure, and slightly different coordinates, that describe the
>> same general space in the universe, and then massages them until they pass
>> an equals test.
>>
>> WITH p AS (
>>   SELECT 'POLYGON((0 0, 10 0, 10 10, 0 10, 0 0))'::geometry AS p1,
>>          'POLYGON((0 0, 10 0, 10 5, 10 10, 0 10, 0 0))'::geometry AS p2
>> ),
>> shifted AS (
>>   SELECT p1, ST_Translate(p2, 0.0001, 0.0001) AS p2
>>   FROM p
>> ),
>> rp AS (
>>   SELECT ST_ReducePrecision(p1,0.1) AS p1,
>>          ST_ReducePrecision(p2,0.1) AS p2
>>   FROM shifted
>> ),
>> snap AS (
>>   SELECT ST_Snap(p1,p2,0.1) AS p1,
>>          ST_Snap(p2,p1,0.1) AS p2
>>   FROM rp
>> )
>> SELECT ST_AsText(shifted.p1) AS p1_orig,
>>        ST_AsText(shifted.p2) AS p2_orig,
>>        ST_AsText(snap.p1) AS p1_snap,
>>        ST_AsText(snap.p2) AS p2_snap,
>>        ST_Equals(snap.p1, snap.p2)
>> FROM snap, shifted;
>>
>> -[ RECORD 1
>> ]--------------------------------------------------------------------------------------------------
>> p1_orig   | POLYGON((0 0,10 0,10 10,0 10,0 0))
>> p2_orig   | POLYGON((0.0001 0.0001,10.0001 0.0001,10.0001 5.0001,10.0001
>> 10.0001,0.0001 10.0001,0.0001 0.0001))
>> p1_snap   | POLYGON((0 10,10 10,10 5,10 0,0 0,0 10))
>> p2_snap   | POLYGON((0 10,10 10,10 5,10 0,0 0,0 10))
>> st_equals | t
>>
>> On Wed, Oct 29, 2025 at 10:00?AM Shaozhong SHI <shishaozhong at gmail.com>
>> wrote:
>>
>>> This is very challenging.  Take my words for it.  Try on any polygons
>>> you created and modified.
>>>
>>> On Wed, 29 Oct 2025 at 14:36, Greg Troxel <gdt at lexort.com> wrote:
>>>
>>>> Shaozhong SHI <shishaozhong at gmail.com> writes:
>>>>
>>>> >   Visually, there appears some matching polygons.  Even if two
>>>> geometries
>>>> > represent the same shape visually, they might not be considered equal
>>>> due
>>>> > to tiny differences in precision or metadata.  Have you encountered
>>>> > problems of failure of spatial join?  How did you overcome the
>>>> problems?
>>>> > Regards, David
>>>>
>>>> Could you post your example polygons, and the queries you are using?
>>>> Your question is much too open ended.  It even sounds like it might be a
>>>> request for help with GIS homework, but it's hard to tell :-)
>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20251029/47ca0483/attachment.htm>

From shishaozhong at gmail.com  Wed Oct 29 10:58:07 2025
From: shishaozhong at gmail.com (Shaozhong SHI)
Date: Wed, 29 Oct 2025 17:58:07 +0000
Subject: Spatial join issues
In-Reply-To: <CA+i5JwZU5tny-w=PqCGptOOxNe_g+p42RFGPa7OGgdoR8fO3pQ@mail.gmail.com>
References: <CA+i5JwbhzorZkLjkdDVkmCr4QX=Ufn8i=AqCG-PM7aHkGHwxWQ@mail.gmail.com>
 <rmiecql7p1g.fsf@s1.lexort.com>
 <CA+i5JwYiNtAcw2AE=gw_Fd-PrXO-3JbYSp3-gNEkg4eZp2BdUg@mail.gmail.com>
 <CACowWR2r6ZUfonhqzd7DOBKUWGpbsfjAviAOVgExihy8FstiOg@mail.gmail.com>
 <CACowWR3MDzQcsMLKpa4CdB6mOONggS6K3mj7xV=Eywwr_9mmbQ@mail.gmail.com>
 <CA+i5JwZU5tny-w=PqCGptOOxNe_g+p42RFGPa7OGgdoR8fO3pQ@mail.gmail.com>
Message-ID: <CA+i5JwY6qQBw8bYDreuJveCed2APX+6cS2f9zm70CKLEGO-RvA@mail.gmail.com>

Basically, is these a robust way to test approximate equal when spatial
fidelity exists.

On Wed, 29 Oct 2025, 17:39 Shaozhong SHI, <shishaozhong at gmail.com> wrote:

> Very clever.  I will spend time to understand.  Approximate equal sounds
> very interesting.   I just did intersection.  Expecting a polygon but got
> partial lines.  Suspect only part of lines of two seemingly the same
> polygons intersect. Thanks.
>
> On Wed, 29 Oct 2025, 17:25 Paul Ramsey, <pramsey at cleverelephant.ca> wrote:
>
>> I would imagine that my little example is a bit error prone, but the
>> classic solution to "do these differently structured things with slightly
>> different coordinates cover basically the same space" is to inspect the
>> ratio  "area(intersection(a, b)) / area(union(a, b))". You can see
>> intuitively how the more the same two polygons are, the closer that ratio
>> will be to 1.0.
>>
>> WITH p AS (
>>   SELECT 'POLYGON((0 0, 10 0, 10 10, 0 10, 0 0))'::geometry AS p1,
>>          'POLYGON((0 0, 10 0, 10 5, 10 10, 0 10, 0 0))'::geometry AS p2,
>>          0.001 AS shift
>> ),
>> shifted AS (
>>   SELECT p1, ST_Translate(p2, shift, shift) AS p2, shift
>>   FROM p
>> ),
>> areas AS (
>>   SELECT ST_Area(ST_Union(p1, p2, shift/10)) AS area_union,
>>          ST_Area(ST_Intersection(p1, p2, shift/10)) AS area_inter
>>   FROM shifted
>> )
>> SELECT ST_AsText(shifted.p1) AS p1_orig,
>>        ST_AsText(shifted.p2) AS p2_orig,
>>        area_inter/area_union AS ratio
>> FROM areas, shifted;
>>
>> On Wed, Oct 29, 2025 at 10:17?AM Paul Ramsey <pramsey at cleverelephant.ca>
>> wrote:
>>
>>> Greg isn't passing judgement on how hard your problem is, he's saying
>>> you haven't explained it particularly well. Pictures help. Taking a guess
>>> at what you mean, here's some SQL that creates two polygons, with slightly
>>> different structure, and slightly different coordinates, that describe the
>>> same general space in the universe, and then massages them until they pass
>>> an equals test.
>>>
>>> WITH p AS (
>>>   SELECT 'POLYGON((0 0, 10 0, 10 10, 0 10, 0 0))'::geometry AS p1,
>>>          'POLYGON((0 0, 10 0, 10 5, 10 10, 0 10, 0 0))'::geometry AS p2
>>> ),
>>> shifted AS (
>>>   SELECT p1, ST_Translate(p2, 0.0001, 0.0001) AS p2
>>>   FROM p
>>> ),
>>> rp AS (
>>>   SELECT ST_ReducePrecision(p1,0.1) AS p1,
>>>          ST_ReducePrecision(p2,0.1) AS p2
>>>   FROM shifted
>>> ),
>>> snap AS (
>>>   SELECT ST_Snap(p1,p2,0.1) AS p1,
>>>          ST_Snap(p2,p1,0.1) AS p2
>>>   FROM rp
>>> )
>>> SELECT ST_AsText(shifted.p1) AS p1_orig,
>>>        ST_AsText(shifted.p2) AS p2_orig,
>>>        ST_AsText(snap.p1) AS p1_snap,
>>>        ST_AsText(snap.p2) AS p2_snap,
>>>        ST_Equals(snap.p1, snap.p2)
>>> FROM snap, shifted;
>>>
>>> -[ RECORD 1
>>> ]--------------------------------------------------------------------------------------------------
>>> p1_orig   | POLYGON((0 0,10 0,10 10,0 10,0 0))
>>> p2_orig   | POLYGON((0.0001 0.0001,10.0001 0.0001,10.0001 5.0001,10.0001
>>> 10.0001,0.0001 10.0001,0.0001 0.0001))
>>> p1_snap   | POLYGON((0 10,10 10,10 5,10 0,0 0,0 10))
>>> p2_snap   | POLYGON((0 10,10 10,10 5,10 0,0 0,0 10))
>>> st_equals | t
>>>
>>> On Wed, Oct 29, 2025 at 10:00?AM Shaozhong SHI <shishaozhong at gmail.com>
>>> wrote:
>>>
>>>> This is very challenging.  Take my words for it.  Try on any polygons
>>>> you created and modified.
>>>>
>>>> On Wed, 29 Oct 2025 at 14:36, Greg Troxel <gdt at lexort.com> wrote:
>>>>
>>>>> Shaozhong SHI <shishaozhong at gmail.com> writes:
>>>>>
>>>>> >   Visually, there appears some matching polygons.  Even if two
>>>>> geometries
>>>>> > represent the same shape visually, they might not be considered
>>>>> equal due
>>>>> > to tiny differences in precision or metadata.  Have you encountered
>>>>> > problems of failure of spatial join?  How did you overcome the
>>>>> problems?
>>>>> > Regards, David
>>>>>
>>>>> Could you post your example polygons, and the queries you are using?
>>>>> Your question is much too open ended.  It even sounds like it might be
>>>>> a
>>>>> request for help with GIS homework, but it's hard to tell :-)
>>>>>
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20251029/62e4323e/attachment.htm>

From pramsey at cleverelephant.ca  Wed Oct 29 11:52:52 2025
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Wed, 29 Oct 2025 11:52:52 -0700
Subject: Spatial join issues
In-Reply-To: <CA+i5JwY6qQBw8bYDreuJveCed2APX+6cS2f9zm70CKLEGO-RvA@mail.gmail.com>
References: <CA+i5JwbhzorZkLjkdDVkmCr4QX=Ufn8i=AqCG-PM7aHkGHwxWQ@mail.gmail.com>
 <rmiecql7p1g.fsf@s1.lexort.com>
 <CA+i5JwYiNtAcw2AE=gw_Fd-PrXO-3JbYSp3-gNEkg4eZp2BdUg@mail.gmail.com>
 <CACowWR2r6ZUfonhqzd7DOBKUWGpbsfjAviAOVgExihy8FstiOg@mail.gmail.com>
 <CACowWR3MDzQcsMLKpa4CdB6mOONggS6K3mj7xV=Eywwr_9mmbQ@mail.gmail.com>
 <CA+i5JwZU5tny-w=PqCGptOOxNe_g+p42RFGPa7OGgdoR8fO3pQ@mail.gmail.com>
 <CA+i5JwY6qQBw8bYDreuJveCed2APX+6cS2f9zm70CKLEGO-RvA@mail.gmail.com>
Message-ID: <CACowWR132zdWkhZNoME16VofBJ=pDbrr1v1hnM8D93UtNxW6WA@mail.gmail.com>

It's quite robust, but of course it has a big magic number in the middle,
in that you have to choose what area ratio value you will use as your "they
are the same, as far as I am concerned" threshold.

P.

On Wed, Oct 29, 2025 at 10:58?AM Shaozhong SHI <shishaozhong at gmail.com>
wrote:

> Basically, is these a robust way to test approximate equal when spatial
> fidelity exists.
>
> On Wed, 29 Oct 2025, 17:39 Shaozhong SHI, <shishaozhong at gmail.com> wrote:
>
>> Very clever.  I will spend time to understand.  Approximate equal sounds
>> very interesting.   I just did intersection.  Expecting a polygon but got
>> partial lines.  Suspect only part of lines of two seemingly the same
>> polygons intersect. Thanks.
>>
>> On Wed, 29 Oct 2025, 17:25 Paul Ramsey, <pramsey at cleverelephant.ca>
>> wrote:
>>
>>> I would imagine that my little example is a bit error prone, but the
>>> classic solution to "do these differently structured things with slightly
>>> different coordinates cover basically the same space" is to inspect the
>>> ratio  "area(intersection(a, b)) / area(union(a, b))". You can see
>>> intuitively how the more the same two polygons are, the closer that ratio
>>> will be to 1.0.
>>>
>>> WITH p AS (
>>>   SELECT 'POLYGON((0 0, 10 0, 10 10, 0 10, 0 0))'::geometry AS p1,
>>>          'POLYGON((0 0, 10 0, 10 5, 10 10, 0 10, 0 0))'::geometry AS p2,
>>>          0.001 AS shift
>>> ),
>>> shifted AS (
>>>   SELECT p1, ST_Translate(p2, shift, shift) AS p2, shift
>>>   FROM p
>>> ),
>>> areas AS (
>>>   SELECT ST_Area(ST_Union(p1, p2, shift/10)) AS area_union,
>>>          ST_Area(ST_Intersection(p1, p2, shift/10)) AS area_inter
>>>   FROM shifted
>>> )
>>> SELECT ST_AsText(shifted.p1) AS p1_orig,
>>>        ST_AsText(shifted.p2) AS p2_orig,
>>>        area_inter/area_union AS ratio
>>> FROM areas, shifted;
>>>
>>> On Wed, Oct 29, 2025 at 10:17?AM Paul Ramsey <pramsey at cleverelephant.ca>
>>> wrote:
>>>
>>>> Greg isn't passing judgement on how hard your problem is, he's saying
>>>> you haven't explained it particularly well. Pictures help. Taking a guess
>>>> at what you mean, here's some SQL that creates two polygons, with slightly
>>>> different structure, and slightly different coordinates, that describe the
>>>> same general space in the universe, and then massages them until they pass
>>>> an equals test.
>>>>
>>>> WITH p AS (
>>>>   SELECT 'POLYGON((0 0, 10 0, 10 10, 0 10, 0 0))'::geometry AS p1,
>>>>          'POLYGON((0 0, 10 0, 10 5, 10 10, 0 10, 0 0))'::geometry AS p2
>>>> ),
>>>> shifted AS (
>>>>   SELECT p1, ST_Translate(p2, 0.0001, 0.0001) AS p2
>>>>   FROM p
>>>> ),
>>>> rp AS (
>>>>   SELECT ST_ReducePrecision(p1,0.1) AS p1,
>>>>          ST_ReducePrecision(p2,0.1) AS p2
>>>>   FROM shifted
>>>> ),
>>>> snap AS (
>>>>   SELECT ST_Snap(p1,p2,0.1) AS p1,
>>>>          ST_Snap(p2,p1,0.1) AS p2
>>>>   FROM rp
>>>> )
>>>> SELECT ST_AsText(shifted.p1) AS p1_orig,
>>>>        ST_AsText(shifted.p2) AS p2_orig,
>>>>        ST_AsText(snap.p1) AS p1_snap,
>>>>        ST_AsText(snap.p2) AS p2_snap,
>>>>        ST_Equals(snap.p1, snap.p2)
>>>> FROM snap, shifted;
>>>>
>>>> -[ RECORD 1
>>>> ]--------------------------------------------------------------------------------------------------
>>>> p1_orig   | POLYGON((0 0,10 0,10 10,0 10,0 0))
>>>> p2_orig   | POLYGON((0.0001 0.0001,10.0001 0.0001,10.0001
>>>> 5.0001,10.0001 10.0001,0.0001 10.0001,0.0001 0.0001))
>>>> p1_snap   | POLYGON((0 10,10 10,10 5,10 0,0 0,0 10))
>>>> p2_snap   | POLYGON((0 10,10 10,10 5,10 0,0 0,0 10))
>>>> st_equals | t
>>>>
>>>> On Wed, Oct 29, 2025 at 10:00?AM Shaozhong SHI <shishaozhong at gmail.com>
>>>> wrote:
>>>>
>>>>> This is very challenging.  Take my words for it.  Try on any polygons
>>>>> you created and modified.
>>>>>
>>>>> On Wed, 29 Oct 2025 at 14:36, Greg Troxel <gdt at lexort.com> wrote:
>>>>>
>>>>>> Shaozhong SHI <shishaozhong at gmail.com> writes:
>>>>>>
>>>>>> >   Visually, there appears some matching polygons.  Even if two
>>>>>> geometries
>>>>>> > represent the same shape visually, they might not be considered
>>>>>> equal due
>>>>>> > to tiny differences in precision or metadata.  Have you encountered
>>>>>> > problems of failure of spatial join?  How did you overcome the
>>>>>> problems?
>>>>>> > Regards, David
>>>>>>
>>>>>> Could you post your example polygons, and the queries you are using?
>>>>>> Your question is much too open ended.  It even sounds like it might
>>>>>> be a
>>>>>> request for help with GIS homework, but it's hard to tell :-)
>>>>>>
>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20251029/ba843278/attachment.htm>