ST_OffsetCurve returns wrong geometry

[rkolka]

ST_OffsetCurve sometimes returns wrong geometry. Seems to happen when source geometry has 2 vertices very close.

CREATE TABLE public.offsetcurve_bug
(
    id serial primary key,
	description text,
    geometry geometry(LineString)
)
;
CREATE INDEX offsetcurve_bug_geometry_x ON public.offsetcurve_bug USING gist (geometry);

INSERT INTO public.offsetcurve_bug(
	description, geometry)
	VALUES 
	('original', 'LINESTRING(544237.894288877 6588306.70972559,544226.9710250939 6588308.03375757,544220.8010926669 6588309.418844438)'::geometry(LineString))
	,
	('original', 'LINESTRING(544172.354706179 6588303.23414166,544174.671762133 6588304.55817364,544178.8093620511 6588306.2132136)'::geometry(LineString))
;

INSERT INTO public.offsetcurve_bug
	(description, geometry)
SELECT
	'substring' as description,
	ST_LineSubstring(geometry, 0.35, 0.65) as geometry
FROM
	public.offsetcurve_bug
WHERE
	description = 'original'
;


INSERT INTO public.offsetcurve_bug
	(description, geometry)
SELECT
	'offset 6m' as description,
	ST_OffsetCurve(geometry, -6, 'quad_segs=4 join=mitre mitre_limit=1.1') as geometry
FROM
	public.offsetcurve_bug
WHERE
	description = 'substring'
;

POSTGIS=3.4.2 GEOS=3.11.1-CAPI-1.17.1

[mdavis]

The example provided is quite complex. Can you provide a single example showing the questionable behaviour?

[mdavis]

In GEOS 3.11.3 this doesn't seem to have any issues (assuming I have the test case right).

[rkolka]

Yes, the simpler test case has the same questionable behaviour with POSTGIS=3.4.2 GEOS=3.11.1-CAPI-1.17.1.

I also tried POSTGIS=3.4.2 GEOS=3.12.2-CAPI-1.18.2 and it has the expected (good) behaviour.

[rkolka]

This can probably be closed.

I wanted to know if it were possible/easy to update libgeos on Debian 12 (bookworm). I was surprised to learn that most stable distros have not upgraded to the latest point release. ​https://repology.org/project/geos/versions

• 3.11.0 6
• 3.11.1 18
• 3.11.2 16
• 3.11.3 1
• 3.11.4 1