[JTS works] GEOSOffsetCurve: IllegalArgumentException: RobustDeterminant encountered non-finite numbers

[strk]

Bug report origin: ​http://trac.osgeo.org/postgis/ticket/2099 Offending input (hexwkb): 010200000004000000B788150E6FB162407FABDE5E1D453AC00FB54CBB6EB162409E19426B1B453AC00FB54CBB6EB162409E19426B1B453AC033FBDBB16EB16240F24ABC1F1B453AC0 Operation: GEOSOffsetCurve(geom1_, 0, 0, GEOSBUF_JOIN_ROUND, 2);

[strk]

For the record: the line has a computed length of 5.58135564343909e-05 units. Here's how the WKT looks like:

LINESTRING(
 149.544806520518 -26.2699794095638,
 149.544767045802 -26.2699496303918,
 149.544767045802 -26.2699496303918,
 149.544762544299 -26.269945128889)

[strk]

Possibly related: #591

[strk]

NOTE: the same error occurs when passing a zero-length line to the function. Taking 5.6e-05 the same as zero may or may not be a solvable bug. I wonder if JTS survives this one.

[mdavis]

This works in JTS as near as I can tell. A zero-length line works as well.

[strk]

MArtin: what does JTS return as an OffsetCurve from a zero-length line ?

[mdavis]

The same result as if the zero-length line was a point.

[strk]

The problem seems to originate in an attempt by OffsetegmentGenerator to compute the offset of a zero or close-to-zero length segment, which results in a NaN ordinate offset. I guess it could be worked around this by omitting the zero or too-short segment from the list (I'm surprised this isn't done already by the simplification step).

[strk]

This is even worst, crashes the lib: LINESTRING(140 -26,149 -26.,149 -26.,149 -26)

[strk]

To recap, this one throws an exception:

LINESTRING(0 1,0 2,0 2,0 0)

And this one aborts:

LINESTRING(0 1,0 2,0 2)

Pretty stable functionality ! :P

[strk]

All cases fixed with r3845 and r3846 (collapsed line) in trunk, backported as r11693 in 3.3 branch

[strk]

Sorry, the backport is r3847