Opened 10 years ago

Closed 3 years ago

Last modified 3 years ago

#531 closed defect (wontfix)

UnaryUnion of an line collapsed to a point returns EMPTY

Reported by: strk Owned by: geos-devel@…
Priority: major Milestone: 3.8.0
Component: Default Version: 3.3.3
Severity: Unassigned Keywords:
Cc:

Description

If you pass a collapsed line to UnaryUnion it becomes EMPTY. I would expect it to become a point instead.

Example input: MULTILINESTRING((0 1,0 1,0 1,0 1))

Change History (9)

comment:1 by strk, 10 years ago

Milestone: 3.3.43.4.0

comment:2 by robe, 9 years ago

Milestone: 3.4.03.5.0

still a problem but doesn't seem that important to me -- the linestring is flawed - push

comment:3 by robe, 7 years ago

Milestone: 3.5.03.6.0

still collapses to empty as of 3.5

comment:4 by strk, 6 years ago

Milestone: 3.6.03.7.0

Ticket retargeted after milestone closed

comment:5 by robe, 5 years ago

Milestone: 3.7.03.8.0

comment:6 by pramsey, 3 years ago

Resolution: wontfix
Status: newclosed

JTS does this too. Philosophically you can swing either way. Taken in isolation, returning a point makes perfect sense. But if I union a collection of linestrings, I probably want the not-a-line entries to just disappear (think, zero-length lines at the nodes of other real lines). I'm going to 'wontfix' this as it is long-standing behaviour and not obviously wrong, nor different from our reference base (JTS).

comment:7 by dbaston, 3 years ago

That strikes me as a bit philosophically inconsistent with https://github.com/locationtech/jts/issues/476#issuecomment-533116542

comment:8 by mdavis, 3 years ago

Yes, perhaps it is inconsistent. Tricky to know what the right semantic should be.

The fact that collapsed LineStrings are actually invalid muddies the water even more, since returning a single-point LineString would violate the principle of always returning a valid geometry. This is actually one difference to the JTS 476 issue, since in that case the inputs are valid. Although the invalidity of single-point LineStrings has always struck me as overly-limiting.

There's an appeal to returning *something* non-empty, to indicate that there are actual vertices in the input, which should not just disappear. So then should a POINT be returned, or hold our nose and return a single-point LINESTRING?

I'm not sure there is a single answer which address all requirements. Providing a strict mode in addition to full mode might satisfy more people. But that's a lot more complexity.

comment:9 by mdavis, 3 years ago

A further piece of information - the reason the result is EMPTY is that the overlay algorithm simply ignores zero-length linestrings, on the basis that they are invalid.

I guess another consistent behaviour would be to error out if zero-length lines are detected (in the same way that invalid polygons usually cause an error. That's sort of dodging the issue though.

Note: See TracTickets for help on using tickets.