currently, I plan my routes with Strava by looking in citystrides which streets I have not yet made (red node). I export as a gpx file and then load it into my watch.
If the route could already be exportable from citystrides it would be perfect!
It would be great if there was a route creator you could use to map you route out on the map while you can see the street (purple lines) you’ve already completed. Now I toggle back in forth between Citystrides township map and mapmyrun or strava to set up my running route for that activity.
I merged your post into the ongoing thread … there’s also Chinese Postman Problem Solver that pairs well 
1 Like
Probably better luck with uploading to Strava with their API, Garmin is a pain
Is there specific info that needs to be included in the GPX file beyond the coordinates?
Cool idea. Personally I still like to have a route in my head and not be too precise with my planning. Still a neat idea though
The “learn more” link on the Routes page doesn’t seem to work
Thanks! I just fixed that.
2 Likes
Wow, This will be huge. I love the idea of no more side-by-side browsers as I build the route in one tool while referencing CS. When do you think following roads will be a part of the feature?
1 Like
Do the optional route names get displayed anywhere? I entered one but when going to view my routes, the routes have timestamp they were created at where I assume a name would be displayed.
I do really like that it identifies streets that the route touches nodes on. As @wes asked, getting this to snap to streets would likely replace a lot of us using another platform to build routes.
1 Like
I tested creating a route, seems fine, but as mentioned, the name does not show in the listing, and the download gpx only makes an xml file. Even if i rename it to .gpx, it can’t be imported to Garmin Connect. But it says in the help that you can modify a route in the Editing mode. Can’t find Edit mode?
As of Updates on February 16, 2021 they do. I had a bug in the code that wasn’t using the name during save. 
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?
IMO it should always be snappin’.
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.
1 Like
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.
1 Like
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.
1 Like
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.
Example of a route on Run Go
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.
1 Like
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.
1 Like