You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Polyline(A,E) + Polyline(E,M) = Polyline(A,M)
reversed(Polyline(M,A) = Polyline(A,M)
Polyline(A,M) - Polyline(A,E) = Polyline(E,M)
# point I is the intersection point between Polyline(A,E) and Polyline(X,Y)
Polyline.intersects(Polyline(A,E), Polyline(X,Y)) = True, (Polyline(A,I), Polyline(I,E), Polyline(I,X), Polyline(I,Y)]
# no intersection point
Polyline.intersects(Polyline(A,E), Polyline(X,Y)) = False, ((ClosestPointOnPolyline1,ClosestPointOnPolyline2 ), distance)
Polyline.intersects(Polyline(A,E), Polyline(X,Y), fetch=True) = Polyline(A, Z).. and the other possible polylines....# via missing link between ClosestPointOnPolyline1 and ClosestPointOnPolyline2 fetched from the API
The text was updated successfully, but these errors were encountered:
I suppose if a task wanted to force a particular destination, it could send only that one - those that want to let the walker decides will send multiple requests
We had a chat on gitter.im and the driving force behind the purpose of this change is so that we can prioritise cell_worker tasks and precompute a walking route... in the coordinating class #5367
For this to work the best I would need to modify the Polyline class to support the operations mentioned above in order to be able to re-use Polyline objects as line segments that we can put together or split as we'd want, we could even store them and load them from a file. #5379
Details:
The text was updated successfully, but these errors were encountered: