Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LineSliceAlong fails when start and end are 0 #1577

Open
stevage opened this issue Feb 3, 2019 · 8 comments
Open

LineSliceAlong fails when start and end are 0 #1577

stevage opened this issue Feb 3, 2019 · 8 comments

Comments

@stevage
Copy link
Collaborator

stevage commented Feb 3, 2019

const turf = require('@turf/turf');
const line = turf.lineString([[145,-37], [150, -37]]);
turf.lineSliceAlong(line, 0, 0);

Throws error Error: coordinates must be an array of two or more positions

https://runkit.com/stevebennett/turf-lineslicealong-line-0-0-fails

Maybe it's trivial, but my use case was progressively extending a line from 0% to 100% of an existing line feature. It blew up on the 0%.

@morganherlocker
Copy link
Member

@stevage Thanks for reporting. This is a tricky case, but I believe it is working as intended. A zero length linestring is not a valid simple feature geometry.

@stevage
Copy link
Collaborator Author

stevage commented Feb 5, 2019

Hmm, I don't see anything in the GeoJSON spec prohibiting LineStrings consisting of the same position twice. Or maybe I misunderstood your meaning.

@rowanwins
Copy link
Member

I think our lineSliceAlong implementation is only passing in a single coord in to turf.lineString() rather than a duplicate set of coords which is where the problem is. @stevage is correct in that I think a linestring with 2 duplicate points is valid, although the reality is that such a geometry is probably likely to cause issues in subsequent operations on it...

@morganherlocker
Copy link
Member

Turf additionally requires geometry to be simple feature compliant, which is more than the GeoJSON spec currently requires. This is due to limitations in some of the downstream geometry engines (JSTS), which do not support self intersections or overlapping ring vertices.

@rowanwins
Copy link
Member

I did look at the OGC simple feature spec and was surprised when I didn't see anything about duplicate coords on a linestring. But yep take that a line with 0 length is likely to cause issues in a range of places.

@stevage
Copy link
Collaborator Author

stevage commented Feb 5, 2019

I'm not sure that's a strong argument against ever returning a zero-length linestring. It's just up to the user to not pass that result to other places where it might cause problems. Just like any function that sometimes returns undefined, you could run into problems if you passed that undefined to some other function.

@morganherlocker
Copy link
Member

note: Reopening issue for debate.

We should look into how JSTS will handle this data. My original argument was:

which do not support self intersections or overlapping ring vertices.

... which I have given some more thought and realized that this would not apply to this case, since:

  1. LineStrings do allow self intersections.
  2. This is not about linear rings, and overlapping vertices are needed in cases, such as representing a traffic circle or a winding GPS path.

Throws error Error: coordinates must be an array of two or more positions

The error message is correct, however, this points to abnormal behavior under the hood. This function should return a linestring with two duplicate coordinates.

@morganherlocker
Copy link
Member

Related reading:

locationtech/jts#346

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants