turf icon indicating copy to clipboard operation
turf copied to clipboard

lineOverlap on two polygons giving no output

Open tremby opened this issue 6 years ago • 10 comments

I'm trying to run lineOverlap on the two polygons shown in the following geojson:

https://gist.github.com/anonymous/da2c20dc9f6cf1e6e384f1c05e93a3e6

The source data is the larger polygon, which describes an area of a longer pipe. I use intersect with the longer pipe and that area to produce the pipe polygon shown in the gist.

What I then want is the two end caps where the intersection actually took place, since I want to extend them and then draw some lines here. It looks from the documentation like lineOverlap is the method I want.

I expect that if I run that on the two polygons in the gist that I'll get out two short lines, one on each end, since the lines here are shared between both polygons.

lineOverlap(areaPolygon, pipePolygon)

However, I am returned an empty FeatureCollection.

Am I doing something wrong, or is this a bug?

I also tried running lineOverlap over the original longer pipe and the area, and I get an empty feature set here too. It's not clear to me from the documentation if this is expected -- I can't tell if it's only supposed to give me lines which are shared between the two (I would expect it to be empty in this case) or lines wherever there are "cuts" (this is what I want).

I also tried lineIntersect. This does give four points, but then I don't know how to tell which of the four to pair up to get my two little lines, unless I compare distances between them, but this seems like a mess.

I also tried converting the area shape to a polyline first with polygonToLinestring, just in case this made a difference. It didn't.

tremby avatar Aug 14 '17 23:08 tremby

Thanks for the feedback @tremby, you are not doing anything wrong and this would be considered a "bug". The current implementation of this module requires to have each line segment share nodes together, since the edges "do" intersect but the outer ring doesn't share nodes with those intersections it currently won't be considered as overlapping (even though it should).

I've updated the test cases for this issue https://github.com/Turfjs/turf/pull/902, however it does require a bit more work to figure out how to tackle this problem.

I'm pretty sure this would be great scenario for unary-union (currently in development by @NickCis) would be great to apply to both source & target before splitting the lineSegments.

Image below: Markers indicate the lines do in fact intersect, however no line segments share nodes together so they are not added to the overlapping results.

image

DenisCarriere avatar Aug 15 '17 03:08 DenisCarriere

Gday @DenisCarriere

You could possibly use @turf/pointOnLine to do something in this space (he says without having actually looked at the source for the lineOverlap module)

rowanwins avatar Aug 15 '17 03:08 rowanwins

Thanks, @DenisCarriere; sounds like it's a difficult problem to solve. I guess you'd have to decide how much error to allow along the line when deciding whether two lines are following the same path or not.

But for my particular use case, let me rephrase what I said originally, since on reading it back I don't think it's totally clear. Maybe I got distracted half way through writing it.

The yellow shape in your screenshot is part of the source data, and so is a shape which is not displayed. It's the black thin pipe, but longer on both ends. I intersect these two to make the black shape shown. I want additionally to get ahold of the lines where the "cuts" of the intersection took place.

Is it possible for me to get this, at present, either from the original two shapes I've described, or from the two in the dataset in this ticket? I would imagine it would be easy to find as part of the operation of intersect, perhaps.

tremby avatar Aug 15 '17 03:08 tremby

@rowanwins @tremby Quick feedbacks 👍

@rowanwins I'll try to use point-on-line, maybe put a distance threshold to match segments which are "close" enough instead of exact matches.

There's definitely an issue with this module, I've simplified the test scenario.

Here are two lines which clearly overlaps each other, however since they don't share nodes this module doesn't pick it up the red line.

The goal would be to match each line segments (lines with 2 vertex) which contain both start & end points on line, if one of the vertex in the line segment doesn't intersect then it would not be considered overlapping.

image

{
	"type": "FeatureCollection",
	"features": [
		{
			"type": "Feature",
			"properties": {
				"stroke": "#F00",
				"stroke-width": 10,
				"stroke-opacity": 1
			},
			"geometry": {
				"type": "LineString",
				"coordinates": [[2, 2], [4, 4]]
			}
		},
		{
			"type": "Feature",
			"properties": {
				"stroke": "#00F",
				"stroke-width": 3,
				"stroke-opacity": 1
			},
			"geometry": {
				"type": "LineString",
				"coordinates": [[0, 0], [6, 6]]
			}
		}
	]
}

DenisCarriere avatar Aug 15 '17 03:08 DenisCarriere

I knew those boolean modules would eventually come in handy!

rowanwins avatar Aug 15 '17 04:08 rowanwins

In the mean time I've realized I can actually just use intersect for what I want to do, with the original area polygon and the full-length pipe polygon. I think all I need to do is intersect(polygonToLineString(areaPolygon), fullPipePolygon) and I'll be given back a MultiLineString containing LineStrings where the cuts take place. I'm going to try this when I get back to the office.

Meanwhile, @DenisCarriere: thanks. I agree that that certainly looks like a bug, especially with your simplified test case.

tremby avatar Aug 15 '17 04:08 tremby

👍 @tremby updated my initial comment https://github.com/Turfjs/turf/pull/902#issue-250209048 on my PR.

Keep me posted on what your findings are.

DenisCarriere avatar Aug 15 '17 05:08 DenisCarriere

intersect ended up doing just what I wanted, when cut with a polyline rather than polygon as described above, so that's what I'm now doing.

Still good a bug was uncovered and fixed! Thanks for your help. Go ahead and close this if you deem the bug fixed.

tremby avatar Aug 15 '17 19:08 tremby

👍

DenisCarriere avatar Aug 15 '17 20:08 DenisCarriere

I noticed, that the test case issue-#901.geojson is a false positive due to the generous tolerance of 50 meters. The current implementation couldn't detect partial overlaps.

The iteration visualized in the image, is recognized as an overlap because the second point far outside the line is within the tolerance of 50m. The bug should probably be fixed if partial overlap works.

image

jsiedentop avatar Feb 26 '24 13:02 jsiedentop