Match @turf/line-overlap based on proximity distance

[DenisCarriere]

Match @turf/line-overlap based on proximity distance

Primarily a fix for issue #901.

@turf/line-overlap can now match lines within a proximity distance (in kilometers).

JSDocs

/**
 * Takes any LineString or Polygon and returns the overlapping lines between both features.
 *
 * @name lineOverlap
 * @param {Geometry|Feature<LineString|MultiLineString|Polygon|MultiPolygon>} line1 any LineString or Polygon
 * @param {Geometry|Feature<LineString|MultiLineString|Polygon|MultiPolygon>} line2 any LineString or Polygon
 * @param {number} [proximity=0] Proximity distance to match overlapping line segments (in kilometers)
 * @returns {FeatureCollection<LineString>} lines(s) that are overlapping between both features
 * @example
 * var line1 = turf.lineString([[115, -35], [125, -30], [135, -30], [145, -35]]);
 * var line2 = turf.lineString([[115, -25], [125, -30], [135, -30], [145, -25]]);
 *
 * var overlapping = turf.lineOverlap(line1, line2);
 *
 * //addToMap
 * var addToMap = [line1, line2, overlapping]
 */
module.exports = function (line1, line2, proximity) {

To-Do's

• Add test case for Issue lineOverlap on two polygons giving no output #901
• Support line segments which overlap which don't exactly share nodes.
• Add segmentEach to iterate over line segments
• Add unary-union to both source & target temporary fix using point-on-line has been added until unary-union is completed

Simplified example (no sharing nodes)

• Red: Source Line
• Blue: Target Line
• Green: Overlapping lines (Results)

[DenisCarriere]

@rowanwins @tremby Have a look at this PR, this seem to have solved both the simplified & the initial issue.

Since the line segments might not be exactly on the target line, I added a proximity parameter (in kilometers) used to improve/reduce the matches.

@tremby I used proximity=0.05 (50 meters) for yours and it seems to have worked very well.

Green: Results => overlapping lines

[DenisCarriere]

@rowanwins Tried to use @turf/boolean-point-on-line, it worked for the simplified test case, however it wasn't able to match the other since it has to be exactly on the line to return true.

Is there anyway to add a distance parameter in your boolean module? Is that even possible? Nothing too complicated but having this would help a lot for this type of scenario.

👍

[tremby]

Looks like it does the trick; thank you! Lovely fast progress.

[DenisCarriere]

Lovely fast progress.

You caught me at a "bored" moment, usually it's not this fast.

Strange that the Travis CI keeps failing... 🤔 works fine locally.

[tremby]

Questions about this fix:

• With proximity at 0 does it work on the simplified test case?
• By extension, is the reason it does not work on my sample data something to do with floating point error? As explained in the issue, the red shape (in your last screenshot) is the result of an intersection with the blue, so barring floating point error or a bug in either this method or intersect I don't see why they wouldn't still be on exactly the same path.

[DenisCarriere]

With proximity at 0 does it work on the simplified test case?

Yes with 0 it does work on the simplified case (added @turf/boolean-point-on-line).

is the reason it does not work on my sample data something to do with floating point error

Pretty sure it's something like that, floating points, and when you dive down real close you can see that the points don't actually overlap but they cross each other, hence why we needed to add the proximity parameter to make that work.

It's a great example, I'm glad you brought it up!

Strange that the Travis CI keeps failing... 🤔 works fine locally.

Ops, this broke something in @turf/boolean-point-on-line (fixed now, the default proximity wasn't set to 0).
@rowanwins Might worth removing dependencies in your boolean modules, that way we don't have any circling dependencies (dependencies that depend on each other).

[rowanwins]

Gday @DenisCarriere

Yep we should be able to add some sort of proximity parameter (I'd perhaps call it tolerance) similar to any of the other distance style params that we offer for other modules.

point-on-line doesn't have any dependencies, although some of the other boolean ones were probably calling line-overlaps I think.

Will see if I can bash it out quickly this evening.

[DenisCarriere]

@rowanwins 👍

tolerance is a better param name.

point-on-line doesn't have any dependencies, although some of the other boolean ones were probably calling line-overlaps I think.

Most of the "core" functionality can be copy-pasted from the internal methods, they aren't very big modules. Close to zero dependencies for the boolean modules would be ideal, obviously there's some that can't which is fine.