Initial Release of the Route Builder tool: Updates on February 15, 2021
It’s now possible to manually build your own routes by drawing on the map. This works best from your city view page - start at your profile, click the link for the city you’re working on, and start building Routes in there. You can search & show/hide streets while you build the Route, along with show/hide of your LifeMap.
I had been using an Android app to plot a route and have it tell me when to turn (since Runkeeper routes apparently don’t have any such feature), but it quickly got too clunky when I missed turns or wasn’t sure due to GPS issues.
Now I plan using Runkeeper’s routes feature, but don’t actually use the route in the app. Rather I print a map on physical paper and run with that. It’s been great, and saved me when my phone died. Note I would have done this in plain Google Maps, but it only supports a certain number of destinations or manually changed points, and it’s very frustrating when the points get reset.
Of course an automatically generated route would be cool! I’ve made a lot of headway with the printed maps though!
There is no automatic way to generate a route at the moment, but James seems to be really interested by the algorithm.
But it is possible to build a route following all the connected streets of an area.
To generate a gpx file, you have to download your city streets in an GIS editor, opensource QGIS submitting an OSM query like citystrides do.
After that, you select the area you want to run and call a plugin called CPP solver that solves the route optimization problem.
Then upload the gpx route to your watch app like I do
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.
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?
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.
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?
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.
Manually build a route by drawing on the map
I merged your post into the ongoing thread … there’s also 
In my tests, it was fairly easy to get a poorly-snapped map.
