UnaryUnion of an line collapsed to a point returns EMPTY

[strk]

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))

[robe]

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

[robe]

still collapses to empty as of 3.5

[strk]

Ticket retargeted after milestone closed

[pramsey]

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).

[dbaston]

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

[mdavis]

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.

[mdavis]

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.