Lucky me! Thanks for the confirmation. Emily
On 2022-02-11 2:19 p.m., Paul Ramsey wrote:
This issue has been confirmed on both GEOS and JTS. You have magic geometry
that breaks the consistency between prepared and standard results.
https://github.com/libgeos/geos/pull/566
P.
On Feb 10,
It seems to be predicate robustness failure week! The geometries in this
recent post show the same problem (in JTS, and probably GEOS too).
https://lists.osgeo.org/pipermail/postgis-users/2022-February/045255.html
A: LINESTRING (-29796.696826656284 138522.76848210802, -29804.3911369969
This issue has been confirmed on both GEOS and JTS. You have magic geometry
that breaks the consistency between prepared and standard results.
https://github.com/libgeos/geos/pull/566
P.
> On Feb 10, 2022, at 6:43 PM, Emily Gouge wrote:
>
> Here you go. Thanks!
>
>
> SELECT ST_AsHEXEWKB
Here you go. Thanks!
SELECT ST_AsHEXEWKB (geometry) FROM test.eflowpath WHERE id =
'889105be-5782-43f1-b50c-5a5825c83875'
> On Feb 10, 2022, at 4:55 PM, Emily Gouge wrote:
>
> I have a linear dataset on which I was building a query to find edges that
> are “very close” but don’t touch. While working on this query I found some
> unexpected results with the st_intersects and st_disjoint functions. As
> outlined
I have a linear dataset on which I was building a query to find edges
that are “very close” but don’t touch. While working on this query I
found some unexpected results with the st_intersects and st_disjoint
functions. As outlined below, the query returned true for both
st_instersects and
