Consider the following statement:
SELECT ST_Within(a1, a2), ST_Within(a1, a3)
FROM ST_GeomFromText('POINT(0 0)') As a1
, ST_GeomFromText('GEOMETRYCOLLECTION(POINT(0 0), LINESTRING(0 0, 1 0))') As a2
, ST_GeomFromText('GEOMETRYCOLLECTION(LINESTRING(0 0, 1 0), POINT(0 0))') As a3;
--expected{t, t}, actual{f, t}According to the definition of ST_Within and interior of POINT, geometry a1 is within a2
ST_Within(A, B) ⇔ (A ⋂ B = A) ∧ (Int(A) ⋂ Int(B) ≠ ∅) For POINTs, the interior is the point itself.
If the POINT(0 0) is behind LINESTRING(0 0, 1 0) (such as a3), Postgis gives the correct answer for ST_Within(a1, a3).
When the POINT(0 0) is in front of LINESTRING(0 0, 1 0) that is shown in a2, Postgis doesn't consider the 'Within' relationship.
ST_With(a1,a2) and ST_Within (a1, a2) give different results while the only difference between a2 and a3 is the order of the linestring and the point. It makes me believe it is a functional issue.
The version is the lastest: POSTGIS="3.5.0dev 3.4.0rc1-705-g5c3ec8392" [EXTENSION] PGSQL="170" GEOS="3.13.0dev-CAPI-1.18.0" PROJ="8.2.1 NETWORK_ENABLED=OFF URL_ENDPOINT=https://cdn.proj.org USER_WRITABLE_DIRECTORY=/tmp/proj DATABASE_PATH=/usr/share/proj/proj.db" LIBXML="2.9.13"