It would be really great if the route suggestion feature has the option to save the route as a gpx-file, so I can load it onto my watch.
It might be even cooler if it talked to the Garmin Connect app/web site you didnāt need to import anything.
Iām not sure what the Garmin Connect API looks like, or even if they publish it.
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
(see also Chinese Postman Solver discussion)
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
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.
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?
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.
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.