Along doesn't work with MultiLineString

Please provide the following when reporting an issue:

• GeoJSON data as a gist file or geojson.io (filename extension must be .geojson).
• Snippet of source code or for complex examples use jsfiddle.

Hi guys, thx for your awesome work!

I’d like to ask if you are planning to add MultiLineString support to turf.along()?

Currently, it doesn’t work, I’m getting error messages like: angular.js:14961 TypeError: Cannot read property '1' of undefined

Uncaught Error: Coordinate is not a valid Point

This would be important to implement, since currently turf.along() fails with antimeridian cases. GeoJSON standard says antimeridian geometries should be MultiLineString type: https://tools.ietf.org/html/rfc7946#section-3.1.9

Reproduced:

https://jsfiddle.net/8h16u93j/

https://raw.githubusercontent.com/Turfjs/turf/master/packages/turf-length/test/in/multi-linestring.geojson

[dpmcmlxxvi]

@csimpi morganherlocker said it well. The multi-parts are in an array so, yes, they have an order but not necessarily a meaningful order across users and data sets.

However, even if this feature request doesn’t make it in Turf, think of this as an opportunity. There may be a user appetite for a new library with advanced geospatial processing built on top of Turf that allows for more complex algorithms. A turf-toolbox if you will. There are a few packages currently in Turf that would probably qualify but they are already in.

[morganherlocker]

I don’t get this part: order is not guaranteed. The coordinates of the different lines are in an array with indexes, so the order is static, one line comes after the previous, what part that I don’t understand?

I stand corrected! I had mixed up the fact that JSON does not guarantee Object key order, but it does, in fact maintain array order as you say.

I am still skeptical of this design though, since there is nothing about MultiLineString that suggests the data has a logical order or connection between parts. We would need to carefully define how the coordinates would be traversed, and we generally avoid algorithms that are non-obvious given the inputs and operation with very few exceptions. Should this algorithm ignore gaps between lines? Should it add the distance between linestrings to the running total? I can see reasonable reasons for both, which suggests to me that it may be a thing for users to decide in a helper function. I’m a little on the fence here to be honest, but I am always hesitant to introduce more complexity.