Unexpected behaviour in ST_Relate with PostGIS 3.5 and GEOS 3.13

[Paul Ramsey]

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

I thought it was GEOS, but not increasingly thinking it's PostGIS
caching, so opening up a ticket there.

P

On Fri, Jul 4, 2025 at 7:43 AM Paul Ramsey <pramsey at cleverelephant.ca> wrote:
>
> This is reproducible, and almost certainly a symptom of something awry in RelateNG, which recently introduced the idea of prepared relate calculations. The polygon is valid, so it’s not an input error. The pattern is the usual one we see with prepared geometries where a subsequent call in a series of calls has a different result from a one-shot call of the same function. I will have to bang on this a bit to see if I can get a replicator purely in GEOS, but it would be a difference between the prepared and nonprepared versions of relate().
>
> On Jul 4, 2025, at 6:56 AM, David Smith <smithdc at gmail.com> wrote:
>
> Hi all,
>
> I was unsure how best to ask this question. If this is the wrong place I'd appreciate being pointed in the right direction.
>
> When trying to add support to Django's GeoDjango for PostGIS 3.5 and GEOS 3.13 there is one test failure. I managed to summarise it to this example in sql. I'm not an SQL expert, so I used Claude.ai to help me write this.
>
> Some of the values being input are quite long, so here's a gist:
>
> https://gist.github.com/smithdc1/e8429f70b74bc97cd2a0a3a6193d5949
>
> The first part is set up, which creates two tables and adds some data. The two SELECT statements at the end show the issue. `ST_Relate()`, when a pattern is provided, seems to only work for the first result.
>
> The first query returns `False` for Lawrence being within Kansas, but is `True` (the correct result) if it is the only row the function is applied to. `True` is also returned if Lawrence is the first row, rather than the second, in the table.
>
> I was wondering if this change in behaviour in PostGIS 3.5 / GEOS 3.13 is expected?
>
> Thanks
> David
>
>
>
>
>
>
>
>