Yeah, this is me not coming up with good terminology. āEdit modeā is the time between placing your final point and before clicking the Save button (well, technically, you can click Save & change the route & click Save again - itāll update that Route).
After you place the final point, the entire route becomes changeable - you can click points, then drag them around however you like.
Iād love to include snap-to-map, and I have some code in place for this that I havenāt released yet. The main hurdle is that I need to smooth out my use of the Map Matching service that Mapbox provides (this is the service that provides the map UI as well). The version I have now snaps the route to streets on save - so thereās no interactive approve/disapprove capability, you just save the route and then view it and hope it snapped correctly. In my tests, it was fairly easy to get a poorly-snapped map.
It also adds to my costs based on how much usage it gets.
Some questions re: snapping to streets:
When, in the process of building a route, would you expect it to snap to the street? ā¦ While youāre dragging the line for the next point ā¦ After dropping each point ā¦ After dropping the last point
Would you expect it to always snap to the street or only if you click a āSnapā button? (which inherently pushes the snap action to after dropping the last point)
Would you expect to be able to āunsnapā your route?
Following that, would you expect that āunsnappingā a route would unsnap the whole route or just a section?
More descriptively, it would snap after dropping each point (except for first cause itās a dot at that point; not a line). Basing this on usage of other similar tools like Stravaās route builder.
As I select points on valid streets, it snaps to streets to create route. If I select a point on map that no street exists (ex: end of above gif), it tries to get me there as close as possible while still adhering to staying on valid streets. By snapping as you go, it allows user to catch any weird or non-desired snaps and fix at that point. Ex: Since our goal is to mark off every street, this means we have to run cul-de-sacs and repeat some streets that involve a loop. If a user waited until the end to click a āsnapā button, it may skip some of the street coverage that it finds redundant (which in an efficient system it is) but we still want it cause we are node hunting fiends.
Stravaās route builder does have āmanual modeā which behaviors similarly to current CS route builder where you run like a crow flies; no boundaries. I donāt personally use that mode unless Iām going on trails the builder canāt detect. Since CS users are looking to complete streets, I canāt think of a reason you would want it not to automatically snap to streets.
Ah, ok. Thanks for that gif, itās really helpful to see it in action. Iād have to totally rebuild the interactive bits of the route builder.
The existing ādrawā version was fairly easy to get released because of the Mapbox draw tool. It does so much of the heavy lifting.
Also, this demo is a great example of what the snapping would look like within this existing ādrawā interface.
I like this idea, though, especially since each click can be undone (a major drawback to the draw tool Iām using). Iāll keep thinking about it, and how I can make it CityStrides-specific ā¦ highlighting incomplete streets/nodes while hovering over the map, or some kind of node-completion-weighted snapping where (in your gif) if you hadnāt completed those two dead-end streets along the first path it would send you down those streets as well. I can imagine the code behind all this can get really complicated really quickly.
Update: Thereās also this demo of the Mapbox Directions API, which Iāve been toying with as well - something to provide turn-by-turn directions or help you get back on track while youāre out on your run.
In total agreement with Marty, the snapping must be immediate. Great GIF!
Having the ability to turn off snapping in between clicks is helpful for times when routing algorithms wonāt let me get across something. There may be shortcut across a field or parking lot or something that the user needs the ability to override snapping and āforceā a line from here to there.
It looks like Iām too late to join the testing fun, but Iād like to +1 the points Marty and Wes make re snapping, and the ability to override it.
Iām commenting blind, so maybe you have this covered already, but some form of gradient or other way to tell direction on the route would be very helpful. My routes often look like a tangle of string with multiple touching points, so being able to tell place along the route would be great.
Example:
I really want to add gradients to the Routes as well as to Activities, but I have to be very careful not to completely ruin the site for some people ( Gradient activity lines )
I love that I have this forum to discuss things with everyone. It helps so much to keep me from building the wrong stuff. Thereās so much nuance, sometimes, that anything outside of a full conversation can be actively harmful. This snap-to-map idea has taken a ride so far, and is a great example of how multiple competing points of view can all be correctā¦
A: It must always snap to the map.
B: Yes. Always. But sometimes not.
C: I agree with both of them.
Iām not knocking on anyone or disagreeing - itās a totally valid conversation, in its own special nuanced way.
When I was first using citystrides, I used onthegomap web site to plan my routes; Iāve now switched to the EasyRoute app because it has apple watch integration. Both of those tools allow you to toggle āsnap to roadā - so if, for example, I know thereās an unofficial shortcut from one cul-de-sac to the nearby road, I turn off the āfollow roadsā snapping, draw a segment, then turn it back on.
Personally Iām not a fan of gradients. Too 2010-y for my liking Too each their own though.
Throwing out another idea to see what sticks to the wall. Adding directional arrows/icons along the route.
Reference: Run Go - Another platform for route building. Its main appeal is turn by turn navigation audio cues. Iāve used it a couple times but found it bit lacking when I made a mistake and needed to undo or edit in the middle of a route. What I think it does well is add turn icons at intersections where a turn was made. This would help with issue Just_one_more_street mentions above.
My crude alternative interpretation of adding directional V arrows on route line.
The purple arrows could be at designated distances (ex: every tenth of mile) and/or when you make a turn to go from one street to another. Initially thought doing at nodes would be easiest but that could be messy when there are curves which have a lot of nodes or long, straight streets that only have a node every half mile.
What a nice perspective on the divergent opinions of humans.
For me personally, snap-to-road is a must-have feature before I would choose to use your implementation over onthegomap. My preferred would be being able to pop in-and-out of snap-to, because of the occasional need to traverse a non-road shortcut.
Also crucial for me is that I can create the next waypoint to be very far away from the prior one, and it will automatically snap to the shortest road-route between the points (rather than āas the crow fliesā). The reason this is so important is that my closest non-capture node is 3 miles away from my home, and it saves me a huge amount of time to just click once at my home, and once near the nodes I want to capture, and onthegomap gives me the shortest route there.
I love this thread because it shows my pre run planning is WAY different from everyone else. Or so it seems from this thread. Think Iāll start āall the planning is in my headā thread
I did the āHave it all planned in my head. No need for planned route on my phone. I can remember the 47 turns easy-peasyā a couple times. Stopped doing it when I forgot one small block each time and I had to return another day; especially if it was area far from home. Never again!
Marty- Iāve been using arrows on my hand drawn route in the same way as you show above - but I also draw my line just to the left of the road, so when I turn around, Iām running back the other way. With so many turns and crosses itās difficult to know where you are! I have been using easy route to measure - but when it comes to my final map, I have been printing a screen shot of a section of citystrides - as it shows where Iāve been alreadyā¦
Thanks for that link to https://onthegomap.com - the route building in that site such a nice experience! Being able to click at the end of a few dead ends to route those streets is way nicer than having to manually draw out the meticulous route.
I like the mile markers, but they donāt completely sort out the trouble of which direction to head in, especially if you have small overlapping routes.
Ah, I just figured out itās possible toggle between the walking directions and the line tool - that would allow the switch back & forth between snapping & manual drawing.
I like this experience way more & it seems worthwhile to put in the effort to move away from the current draw tool Iām using over to something more like this UX.
I agree that gradients look a bit meh, but they do have the advantage that km4 looks different from km5, making it easy to tell which way to turn when there is a crossing in the route. Besides the direction arrows you suggest, Iāve also seen animated blobs āwalkingā the route to indicate direction, but that also gets a bit messy with crossed routesā¦
@richwarne2003 I also started out just planning in my head, but I realized fairly soon that Iām terrible at estimating the mileage required to cover a particular section
I just did a quick test route on my iPad and wow, itās much improved over what was there a couple days ago! I initially had trouble finding the āundoā because I was expecting it to be on the left side of the screen, since thatās where I had initiated the route creation. But once I saw the widget in the upper right I was set.
I really appreciate the āStreets this route will complete nodes forā feature, especially the ability to then show where nodes are on various streets. (Quite helpful for dead end streets.)
One thing I couldnāt figure out: how to edit my route. For example, after I saw the āstreets this will complete nodes forā feature I realized I should add an out-and-back block of a certain street in the middle of the route, but couldnāt figure out how.
FYI, on my machine (Chrome on MacOS Big Sur), the Route Builder controls lie on top of the map zoom in/out buttons, which are therefore inaccessible, as shown in the attached image.
And, since I am here mentioning the zoom in/out buttons ā I would love it if those were a little bit lower on the interface. When I move my mouse to those controls, I find that I often accidentally move over my profile pic, triggering the menu with Lifemap, Profile, etc. (But maybe thatās just me.)
Yeah, I noticed that. Odd - locally it doesnāt do this for me. Iāve got some minor changes I plan to release soon & Iām hoping thatāll take care of it.
I meanā¦ I guess the new version is slightly better than the previous version. If you are in to new, sleeker functionality and all.
If you want nitpick things, may want to differentiate the hover / alt text for the route type toggle. If you hadnāt mentioned in release notes that we could switch between road snapping and straight lines, I wouldnāt have looked for it and clicked on that icon. āToggle router to snap to streetsā and āToggle router to straight linesā or something.
In my tests, it was fairly easy to get a poorly-snapped map.
ā¦ Iām still trying to figure out why it works locally but not on the server
If you are in to new, sleeker functionality and all.