nearestPointOnLine unexpectedly sums up lengths of multiLineStrings for location property

[EmilJunker]

turf 7.1.0

Consider the following example:

const multiLineString = turf.multiLineString([
  [[-122.3125, 47.6632], [-122.3102, 47.6646]],
  [[-122.3116, 47.6623], [-122.3091, 47.6636]]
]);

const pointA = turf.point([-122.3106, 47.6638], {name: 'A'});
const pointB = turf.point([-122.3102, 47.6634], {name: 'B'});

const nearestToA = turf.nearestPointOnLine(multiLineString, pointA, { units: "meters" });
const nearestToB = turf.nearestPointOnLine(multiLineString, pointB, { units: "meters" });

console.log(nearestToA.properties.location); // 150.293316294307
console.log(nearestToB.properties.location); // 389.9028953092881

Expand for GeoJSON FeatureCollection of all the above

{
    "type": "FeatureCollection",
    "features": [
        {
            "type": "Feature",
            "properties": {},
            "geometry": {
                "type": "MultiLineString",
                "coordinates": [
                    [
                        [
                            -122.3125,
                            47.6632
                        ],
                        [
                            -122.3102,
                            47.6646
                        ]
                    ],
                    [
                        [
                            -122.3116,
                            47.6623
                        ],
                        [
                            -122.3091,
                            47.6636
                        ]
                    ]
                ]
            }
        },
        {
            "type": "Feature",
            "properties": {
                "name": "A"
            },
            "geometry": {
                "type": "Point",
                "coordinates": [
                    -122.3106,
                    47.6638
                ]
            }
        },
        {
            "type": "Feature",
            "properties": {
                "name": "B"
            },
            "geometry": {
                "type": "Point",
                "coordinates": [
                    -122.3102,
                    47.6634
                ]
            }
        },
        {
            "type": "Feature",
            "properties": {
                "dist": 45.90981630012612,
                "multiFeatureIndex": 0,
                "location": 150.293316294307,
                "index": 0
            },
            "geometry": {
                "type": "Point",
                "coordinates": [
                    -122.31101109378298,
                    47.6641062907408
                ]
            }
        },
        {
            "type": "Feature",
            "properties": {
                "dist": 32.74106993655739,
                "multiFeatureIndex": 1,
                "location": 389.9028953092881,
                "index": 0
            },
            "geometry": {
                "type": "Point",
                "coordinates": [
                    -122.30993283032643,
                    47.66316692823026
                ]
            }
        }
    ]
}

pointA gets snapped onto a point on the northern line while pointB gets snapped onto a point on the southern line of the multiLineString. Both snapped points are located approximately 150 meters from the respective line start. However, while the location property of nearestToA has the expected value (150.293316294307), the location property of nearestToB is unexpectedly big (389.9028953092881). Apparently, turf has added the full length of the northern line to it which is not what I want.

With the current behavior, there is no easy way to know the location of the nearestToB point along the southern line (which should be a value around 150). Please consider to add an extra property for this (maybe you could call it multiFeatureLocation) or add an option that allows the user to choose which behavior they want.

[smallsaucepan]

Thanks @EmilJunker. multiFeatureLocation seems most consistent. Let's do that.