Snap to existing waypoints

[Pete-Y-CS]

Many LCWIPs walking and cycling routes are in different sections of the document. However there may be some overlap in the underlying path taken. Here is an example from West of England Combined Authority. The orange walking route in the first image runs along the same path as the alternative cycle route in the second image:

This example would be fine but when there is a shared section which couldn't be drawn with route snapper then we would have nearly-but-not-aligned routes. My proposed solution to this is add a third snapping mode: route snapper, freehand, and snap-to-existing-waypoint, so that we can ensure exact alignment in situations like this.

[dabreegster]

This looks like a useful feature, if it indeed happens enough to justify the implementation complexity. UX-wise, I would not expect to choose a third mode to snap to special new waypoints. I would instead expect to toggle an option to include freehand waypoints from other routes. It could be useful when that option is checked to draw the dots and lines on the map, so the user can see what those new points are.

Implementation-wise, there could be a new routine in ATIP that scans existing routes looking for freehand segments, and a way to draw it. Then a new API in route-snapper that takes this info and updates the graph. The complexity arises when:

1) A user draws route 1 using some freehand points 2) They draw route 2, using some of those same new points 3) They edit route 1 or route 2, moving the freehand points around

Upon commit for step 3, we'd need to update the geometry for the other routes. To identify shared freehand points, either we could look for freehand waypoins with the same geometry (with the floating point trimming that should already be happening) or start assigning UUIDs to all freehand points. The UUID option would require a backfill when loading old files. This approach is like the data model in OSM, with nodes and ways.

If the complexity of this sounds substantial, it'd be good to know how much this is happening -- in an earlier call, the estimate was less than 10%? And is the lack of exactly-the-same freehand segments a UX problem for the mapper? If not, is it possible to later correct the data in post-processing?

[Pete-Y-CS]

I think it is definitely something we can fix in post-processing, I didn't get the impression this was a blocker for drawing, they were more concerned as to whether it mattered to us for precision/accuracy and/or for double counting. I figured snap to existing waypoint without using route-snapper would be simple and might have other utility (e.g. you're drawing some new junction and want multiple routes to attach to it).

I wouldn't be as comfortable trying to add stuff to route-snapper in the short term myself. I'll try to get some more feedback from Sustrans on the extent/utility of this.