Open dabreegster opened 1 year ago
How should we implement this? Now we use https://github.com/georust/rstar to find the closest node to the cursor. Maybe a two-phase approach, first find the closest node, then look at all the incident edges and use https://docs.rs/geo/latest/geo/algorithm/closest_point/trait.ClosestPoint.html?
This sounds hard!
CC @tordans
Random thought after getting a notification on this: based on a parameter snap_distance
break any straight lines longer than that into n
pieces where n
ensures that there are 'virtual vertices' every snap_distance
meters or less and then snap to those?
I imagine you've already thought of that, didn't put that out there before as it seems like a brute force approach that involves a lot of largely unnecessary processing. Could that 'virtual vertex' creation on the fly?
Virtual nodes introduced every few meters would be one approach, definitely. Depending how it's done, it might bloat memory usage and make the final output much more verbose on curved roads. Reasoning how to do this is not so bad for the simple A-to-B routing case, but with draggable intermediate waypoints and also the area snapping, it'll take some focus to figure it out properly. Not likely to prioritize soon, but contributions welcome
Some thoughts on how to compensate:
In an earlier UX study, Will expected to be able to start snapping in the middle of a road