Intersection of Line/Polyon is EMPTY when line is zero-length

[pramsey]

From https://trac.osgeo.org/postgis/ticket/5376:

select st_astext(st_intersection(
   'LINESTRING(3 1, 3 1)',
   'POLYGON((2 0, 2 2, 4 2, 4 0, 2 0))'));

 LINESTRING EMPTY

On the one hand, we maybe want our intersections of lines and polygons to be linear, but on the other hand it's easy to think of cases (line touches polygon at end) where the output will not be linear. This case feels like one that should probably return POINT(3 1).

[dr-jts]

it's easy to think of cases (line touches polygon at end) where the output will not be linear.

Yes, and that case computes correctly. The nuance difference is that in that case two valid geometries are being intersected, rather than having an invalid geometry converted into a different type.

But I do see the appeal of this semantics.

What should be the result of an intersection with a zero-area polygon? Same thing - a Point?

[pramsey]

Yes, I think a zero-area polygon ends up as a point... I guess this is why invalid inputs are undesireable... :) the outputs become a matter of philosophical debate.

[dr-jts]

Yes, I think a zero-area polygon ends up as a point... I guess this is why invalid inputs are undesireable... :) the outputs become a matter of philosophical debate.

In this case extending the semantics to turn zero-length lines and zero-extent polygons into points seems relatively innocuous.

Possibly a bigger issue is how to handle Multi-geometries which contain valid elements along with fully-collapsed elements. Turning the collapses into Points will usually result in a mixed-type result, which is a bit of a pain to handle in client code.

It is looking like with some rework of the OverlayNG logic full collapses to Points can be handled reasonably well. It will be easiest if only geometries which contain all collapsed elements need to be handled, since this can be done by collapsing to points and then using the existing logic for overlay of Points.