Author here. Trail Router is a running route planner that prefers greenery and nature in the routes it generates, and biases against busy roads. It can generate round-trip routes that meet a specified distance, as well as point-to-point routes.
I developed this because I am (or was...) a frequent traveller for work, and I like to run wherever I visit. But I don't enjoy running on busy main roads, and I found that without careful and time consuming route planning that is often what would end up happening if I didn't know the area. Trail Router is my solution to this problem.
After a previous discussion (https://news.ycombinator.com/item?id=23177351) received quite a lot of attention, dang reached out to suggest I post a Show HN to reach a wider audience. I've addressed some of the original feedback too - for example, you can now prefer hills in your routes, as well as avoid them.
Thanks! Cycling is on the to-do list. But I'm conscious it probably wouldn't just be a single category - there would need to be separation for road cycling and mountain biking.
The routing algorithm does already prefer roads with low speed limits, but there is definitely more that could be done in this space (e.g. a slider to set a preference to avoid higher speed roads). It also depends on the availability of speed limit data (I use the OpenStreetMap database).
I am curious why you think this. I run https://ridewithgps.com and always love constructive feedback to improve. There’s always improvements to make, but I wouldn’t quite go as far as calling things abysmal!
One of the main reasons for this is a lack of data. The Strava Heatmap (crowdsourced data, based on past frequency of use) is pretty much the best. OSM tagging is insufficient for real good routing, and it doesn't take traffic patterns into account.
Thus, a lot of route creation is dependent on hyperlocal knowledge. Strava Route Builder, with the heatmap, goes fairly far on this, but it too isn't the best.
Thanks for the recommendation - cycle.travel’s my site!
I’d like to do a dirt/gravel profile. Main reason I haven’t so far is that it’s very hardware-intensive (as in tipping over into renting another Hetzner box).
Man thanks so much for your work! Been using it for some time now especially for planning long distance routes. That's where cycle.travel really shines (plus I really love the 3D altitude visualization ;-)).
I usually tend to export routes and navigate with komoot. Komoot for long distance planning is terribly slow as soon as you hit ~200km+.
I just wanted to reply this cannot be as Komoot is also using CH (fast routing algorithm using GraphHopper) but yes, they are relative slow for fast routes. The reason seems that they create a very big response (5MB) in these cases and then it takes more seconds to visualize this. For current & original GraphHopper the response is highly optimized and so it is much smaller (20x) even with comparable road data (like elevation, surface, bridges/tunnels and road class)
btw: in general Komoot is a nicely polished app. I can only recommend it :)
I absolutely agree. Routing using a phone is loads of fun. I do have the paid version and I highly appreciate their open source-ish character.
Besides large response data and a slaggish planning interface @ komoot: try routing from northern Italy to Sicily: Komoot doesn't seem to know the ferry departing in Villa s. Giovanni to Messina. Komoot will always - no matter how may vias you place - route you back north and send you on a ferry in Salerno. Yes, I know, I could split my route and such. Yet, I love the idea of my planning tool to show me the complete route - including official transportation ;-)
How funny, Trail Router also happens to be hosted with Hetzner. Right now in their auction there's a E5-1650v3, with 256GB RAM and 2x 480GB SSD for 73 EUR/mo (including VAT) - which is exactly what Trail Router runs on. That's incredibly good value for money. Lots of RAM is crucial for applications like this.
I think Doctor_Fegg means that he needs one new server per vehicle profile (?) as OSRM is used for cycle.travel and it does not allow multiple vehicle profiles unlike GraphHopper ;)
I didn't know that. I've been spoiled by the always wonderful GraphHopper. Thank you for your tireless work on GraphHopper! Trail Router and many other projects would not be possible without it.
Well, kind of. cycle.travel runs on my fork of OSRM which does allow multiple profiles. But it still needs a separate hierarchy for each one, which would be another 14GB RAM.
Mountain biker here. Google used to have a great app that was able to record the trails I went to. After that, I could share with my friends and they could do the same circuit just following the directions given by the app. That was a great way to discover and explore new routes. Like everything that works, google canceled the project. If you add this option, I can guarantee at least 20 news users to your platform.
This is actually a wonderful product - thanks for making it! I've looked for a website that did this for a long time, and this works surprisingly well. It actually produced a route that is very similar to one I found myself.
The blog post provides a lot of insights. Good read. Some questions.
Do you plan to support area routing?
And you write: "However, the good news ended there: Openrouteservice does not publish the code for calculating this green index". Is your code publicly available and allows "the news to end good" ;) and maybe even integrated elsewhere?
Good point RE the green index calculation. The very least I could do would be to upstream a reference implementation and documentation back to Openrouteservice. I will take care of that.
Wow, great project. I was working on exactly this in 2015 using Grasshopper but never finished it. I like how much time you invested to solve all the tiny details around the edge cases. Like prefering certain streets, no-hills and trying not to run the same street twice. It wasn’t clear to me from the blog article, does prefer “green” also prefer water areas?
Hey Sam, I run ridewithgps.com and have been reaching into the guts of graphhopper to do interesting routing stuff as well. We just silently rolled out popularity based routing, where we used our database of 50mm rides to build a popularity graph which is used to add a popularity weight in routing decisions. Got a long pipeline of other projects coming out in the same space. Drop me a line if you ever want to yack about these things! cullen@ridewithgps.com
Are you guys considering adding in more social features to compete with Strava? It’s seems an excellent opportunity right now with so many people upset with them. A simple UI update showing a feed, add a kudos system... you’re halfway there.
That's actually one of our main focuses over the next two months, along with mapping and routing improvements. We've seen a decent uptick in people migrating, and they are asking for more social stuff. We've always been shy about becoming a social network, so our focus is on making it much easier to connect with people you know, see what they are doing, while making it optional and not pushing it too hard to our existing users.
I certainly will, thanks! And congratulations on all your success with Ride with GPS. I'm not really a cyclist, so I only used it for the first time last night, but it looked and worked great for me.
Have you considered creating an option to generate the closest all-nature route (not factoring in walking distance to the running route which you could use as a warm-up)?
For years I've contributed trail data to OpenStreetMap, mostly to support mountain biking, but this is the exact kind of other project it benefits. It was really neat being able to try this on local trails and see just what happens.
One question: What tags does it give priority to?
I ask because I tried it on a local trail system, and it seemed to prefer the wide paved and dirt path as opposed to the mountain bike trail. It was weird in that sometimes it'd use the single track, but in others it'd do sort of an awkward thing through the parking lot / service road (highway=service, service=parking_aisle) then use some of the single track (eg markers 1-2) before jumping on the paved path and pretty much ignoring the single track. The single track is really popular with trail runners in this park, so it got me wondering.
Looking at your area (https://www.openstreetmap.org/way/191828180#map=15/42.6423/-...), all of the trails are given equal preference. As a result, it then falls back to whichever gives the shortest path. It's choosing the asphalt one (linked above) just because it's the shortest path. In the future, I may add a surface preference option - so you could give additional preference to non-paved paths.
Thank you very much for explaining that. That makes a lot of sense. I really wish there was a better way for tagging things like narrow/twisty natural surface trails vs. wide flat ones, but that seems all balled up in US vs. EU hiking things, MTB tagging... It's a mess.
(Making it worse, someone naively editing a mountain bike trail in iD will end up inadvertently flagging it as highway=cycleway. And then people using OSM for cycling directions get routed down an MTB trail... Yay.)
I know for a fact that the second one is about right, because I ran it already. The first one however is somehow showing "shorter" kilometers, by the end it should be about 2.5km. Did I do something wrong?
There's no easy way to see it at the moment, other than looking at the waypoint list (the box at the top left). One idea I'm looking at is putting arrows on the line - so in this case you'd see arrows going both ways on the line.
And yes, the numbers do not represent km, they represent the numbered waypoints listed in the top left box. Any usability suggestions are very much welcome!
I actually have. Watch this space - there should be direct route syncing to Garmin and Suunto before terribly long. In the meantime, you can export routes to GPX/KML files already.
Wow, I'm actually impressed by how good the results were, I was not honestly expecting it! Lots of kudos! From the clean map interface and Strava heatmaps to defaulting to metric units, this is something I would even pay for!
Quick anecdote... It defaulted to metric units globally when I first launched it ~8 months ago. But that quickly resulted in complaints from North American users, so it now defaults to imperial units in North America and metric everywhere else. Users can change it in the settings menu, of course.
Yes, I was very impressed with the quality of the routes it generates. I live near Muir Woods (north of San Francisco), and it picked some great ones for me.
Nice job, the algorithm is really effective! I tried this in multiple cities where it ended up recommending very similar routes to some of my established running routes, and even some new combinations :)
Love that your algorithm tries to exclude out-and-backs, I think that goes a long way to make the routes feel organic and appeal to runners. This is really polished and I wish you the best!
One feature suggestion: I wonder if you could have a flag to generate routes starting in parking lots/park entrances in a radius around the starting location. This could go a long way to recommend some common long-run routes where you need to travel a brief distance via car or public transportation but then can get 10-20 miles entirely in the woods.
Thanks! The avoidance of out-and-backs was a must-have for me. It can definitely be improved though. For example, right now the algorithm tries to avoid traversing the same path twice, but it will happily use a path that is only a few metres away! So adding some buffer around that (to penalise paths that are close to one already taken, if not the same) is a future bit of work.
Your suggestion is a nice one. Here in the UK, where it's common to have trains connecting most towns and larger areas, I have thought about adding the ability to say "I want to run 20 miles, and finish at a train station that can get me home in under an hour". Assuming the user is using a car makes it more easily achievable though. Consider it on the todo list!
wait, it avoids out-and-backs? could have fooled me, all the routes it showed for my house were out and backs, some had multiple points of out and back(like a letter Y or E)... i guess thats why i hate running near home, everything is an out and back and even the computer cant find an alternative. :)
It tries to! But if there's no good way to avoid them, then it will end up taking them anyway.
More specifically, when 'avoid repetition' is enabled (it is by default), then the routing algorithm has a very significant penalty weight applied to any existing path already taken.
this is AMAZING! very fast and planned some interesting routes in Portland that I hadn't thought of. I think i'll start using this over my premium strava route planner
This is really well done, congrats. I love the level of automation to make it so easy to use. Also the attention to UX, not just in the narrow UI sense but the actual experience of the trail.
Some thoughts:
- Create a community out of it so that people can rate the routes, and therefore provide feedback for the algo?
- Use some google streetview or alternative for landmarks along the way so people remember what they should be seeing and don't get lost?
UI/UX is most definitely not my forte, so I appreciate the kind words!
Your suggestion RE landmarks tallies with an issue I've been grappling with: how does a user actually run with the route that they've just planned? Yes, you can export the route to a GPX file, and some users will use that on watches/apps to guide them, but it's a bit clunky and isn't the kind of thing you'd necessarily do for a short 5km run in a new area.
I'd rather avoid building full run tracking functionality, as it'd just be repeating what so many other apps do (and often very well). Perhaps the answer is to enable easy syncing of the route to your other apps. Strangely, Strava (the most popular) don't allow importing of routes via their API.
I was think the same thing. The routes generated are really great, but how would I actually use the routes. As some of the routes are pretty complicated. I use an Apple Watch and it would be great to use that.
My preference would be to use Apple Map directions. But it isn’t possible to specify waypoints.
But the official Google Maps URL spec supports specifying waypoints. It would be awesome to click on a link to open the route in Google Maps for turn-by-turn directions.
Garmin have an import API (I’m just setting it up with cycle.travel). I’ve suggested an “open this URL to get a polyline” intent to the Osmand devs and they’ve built it but I’m not convinced it’s live yet.
Thanks for the tip about Osmand, I'll check that out. If you're referring to the Garmin Connect Courses API (https://www.garmin.com/en-GB/blog/garmin-announces-garmin-co...), that's exactly what I've just got access to and plan to integrate with fairly soon...
Hi Sam, instead of syncing you could hook up the GraphHopper Android navigation demo. Although "app development" is not our focus I really like it to test the routing in real life. And for 2.0 it will be possible to directly have this in the server without a further dependency (see the recent pull request). I've mostly found minor OSM problems in my neighbourhood but also some bugs in GH.
The mobile apps are really just full screen web views, with a few enhancements on top. I will definitely check out the GraphHopper Android project and the recent pull request. An improved native mobile app (possibly even with some offline routing, maybe without some features) would be my ideal endgame.
The Android demo is basically a fork from Mapbox and last year or so they even introduced offline routing (probably via valhalla), but only as a binary blob with a closed source license attached (we forked before so this does not affect us).
btw: are you using CH, LM or plain A* for your setup?
I just had a proper look at GraphHopper Navigation - I can't believe I hadn't seen it before - that looks pretty much perfect for my use case! I will certainly be giving that a try.
I'm using plain A* currently. I understood from the Openrouteservice documentation & code that any time dynamic weights were being used, everything fell back to A* anyway. And I'm using dynamic weights heavily! My understanding could be flawed though, and I appreciate I am going to be a few GraphHopper releases behind now. The speed is okay for now - there's certainly bigger items on my todo list first.
I'm excited to try out GH 1.0 properly. Now that I've got much more familiarity with what I'm doing, I'm keen to switch to using GH directly and somehow try to avoid patching it (or try to get any patches merged back into the open source version).
Ha, it makes the same route planning mistake I did years ago when I was in Rome.
I was staying near the Colosseum and for one of my runs, thought I’d run on the Appia Antica, because oldest road in the world, into Parco della Caffarella because it looked like a really nice park with lots of trails.
Well, next thing I know I’m running down a one-way cobblestone road with cars coming toward me and there’s no entrance into the park because there’s a huge wall between the road and the park. The road had walls on both sides in fact. I didn't want to turn around because I’d have the cars to my back. So I hugged that wall as close as I could and trusted the shit out of Roman drivers. Eventually I found a way into the park.
I know you're at the mercy of map data. I don't know how unique this situation is. I always appreciate a new route planning tool. I usually use a combination of Footpath Route Planner, the heat maps from Strava, and Google Maps street view and satellite view. It's definitely a pain to do that for every trip. Maps are definitely not optimized for pedestrian safety, and things like sidewalks and shoulder-width are often inaccurate or just not there on the maps short of bringing up street view.
One item for consideration in the future is allowing users to flag unsafe portions of a route and then having that visible to other users (and also influence the algorithm).
Allowing users to flag unsafe portions sounds like a good work-around.
FWIW, I'm looking at the routes it's planning from my home and they aren't safe. It's sending me down heavily trafficked country roads with little to no shoulder. I'll email you some screenshots.
For anyone else experiencing something similar, try the 'Avoid potentially unsafe roads' option in the settings menu. This tells the routing algorithm to always avoid 'secondary' and 'tertiary' roads without explicit sidewalks (these are OpenStreetMap road classifications).
This isn't on by default because in some countries/regions, such roads are very reasonable to run on.
Clearly there's a better middle ground though, which might involve highlighting potentially problematic parts of the route in the UI.
Thanks again js2 for your email and all your feedback!
It seems to work well for my location. I have been living in my current home for six months and I’ve made an effort to plan out greener routes around me for various distances. Trail Router comes up with similar routes when I put those distances in. It’s not perfect – it seems to prefer joining up parks that are long distances away from one another as long as there’s a river along the route instead of joining up parks that are closer together. But it’s a lot better than I expected.
I live in a small town that is getting grown over by suburbia. The routes ignore all the nice open farm fields to the east of me, and runs me down the busiest streets through some of the most dangerous intersections in my entire state, just to skim by the edge of a park in the city.
In that same 6 mile distance, in addition to running past the farms, it could have run me up to the base of the mountains, down the nice bike trail that goes through groves of trees and open field, then back home.
This is one reason I love testing apps like this - my town almost always messes them up.
Would you mind sharing the name of your town? Feel free to email me directly if you wish, contact details are in my profile. It could be that OpenStreetMap data (which I use extensively in the algorithm) isn't very detailed for your area, but I'm keen to investigate further.
I don't mind sharing the town - Spanish Fork, UT 84660
Especially check out the east side of town, it seems like it wants to go into town for anything short of a 15 mile loop, whereas going east is far more natural.
It's not finding any green 'features' in the vicinity (I know, the mountain range off to the east would beg to differ...), so it's falling back to guessing a direction in which to head. I can see that the Uinta-Wasatch-Cache National Forest is tagged properly in OpenStreetMap though (https://www.openstreetmap.org/relation/3502235), so this should be something I'm able to improve on. Thanks again for your feedback!
Major fail, I live like two blocks from one of the most beautiful and popular lush and quiet rail trails in the country and is perfect for running and even has mile markers for runners and instead of taking me there it took me through an incredibly busy shopping complex and over an interstate to a nearby park that's not running friendly
I wondered how long it’d take for a snarky, overly critical comment. So you tried one route and by this anecdotal evidence you’ve deemed it a “Major fail”. No constructive criticism on how to improve the app, no positive comments on anything at all.
Please don't respond to a bad comment with an even worse one. That just makes things even worse, and is exactly what the site guidelines ask you not to do: https://news.ycombinator.com/newsguidelines.html
It's great to give helpful feedback about bugs, but please edit out swipes like "Major fail" when doing so. They're especially noxious when someone's presenting their own work. We want people do to that freely on HN, and get helpful feedback, not internet nastiness.
Whoa, sorry I think you added more emotional personal attack meaning to major fail than I intended. I major fail all the time, it's part of life and getting better.
Yes - click on the little up arrow in the mile/km distance box at the bottom of the screen. It will show you elevation, as well as the type of paths taken.
Looks very nice! Just started out running and especially the feature that it outputs multiple routes of similar lengths (which I can slowly increase) to have some variation is very appealing! From what I can see the routes all look very runnable with a lot of greenery.
This is great. I move around a lot, and one of the big headaches I always have is figuring out a decent route to run. The only thing I would request is having an option to have completely circular routes, rather then having routes that require running back the way you came.
This is cool! Strava has a new feature where they'll plan a route for you: give a mileage range and a starting spot. When you tell Strava to prioritize trails vs paved, you get good results. Interesting very similar to yours, so that's really impressive given they're a large company with a big budget, or perhaps it says more about my location.
One suggestion: Have changes to the route push state to the history. That way you can use the back button on the browser if you make a mistake. Right now it'll totally take you off of the page.
Thanks very much! Personally I find it a little annoying if a site pushes state to the history very frequently. If I genuinely want to get off the site I end up clicking back loads, and then go too far!
I tried to solve this in Trail Router by putting an undo button on the screen (bottom right).
I would just follow how Google Maps works. I think that's how my brain was expecting Trail Router to work, since it visually and functionally is very similar to using the "Directions" feature of GMaps.
This is awesome! I've tried it on a few areas that I know well, and it really did a good job.
I really love running in new places as a way to explore my area as well as when I travel. I find there is something profoundly good about connecting with my surroundings that way. I use Strava Route Planner with the heatmap extensively, and now I think I'll be consulting this a lot.
My only suggestion is to show an elevation profile. There is already a hill preference slider in the settings, but the elevation profile would really make it great to look at.
You're in luck, both of those things are already supported!
For viewing the elevation profile, click on the little up arrow on the miles/km distance box at the bottom of the screen.
You can configure a hills preference (either to prefer them or to avoid them) in the settings screen. Click on the cog icon to get there. More details are available at https://trailrouter.com/blog/greenery-and-hills-sliders/
I am looking at the route it is generating from my place in New Orleans and comparing it against my own mental route generator for cycling and it’s not doing so well. It’s got me running parallel to Jeff Davis Parkway instead of taking the trail along the very green parkway, then up the side of Bayou St. John with the least greenery (one side has a lot, the other has next to none). Maybe in part because the unofficial desire trails up the green side of the bayou that I regularly see joggers on don’t seem to exist on the map. Going though City Park makes sense; coming back I guess Cortez isn’t too bad a choice if “avoid repetition” is on, but avoiding Jeff Davis just seems super weird.
134 comments
[ 8.4 ms ] story [ 222 ms ] threadI've written a detailed blog post about how Trail Router works here: https://trailrouter.com/blog/how-trail-router-works/
I developed this because I am (or was...) a frequent traveller for work, and I like to run wherever I visit. But I don't enjoy running on busy main roads, and I found that without careful and time consuming route planning that is often what would end up happening if I didn't know the area. Trail Router is my solution to this problem.
After a previous discussion (https://news.ycombinator.com/item?id=23177351) received quite a lot of attention, dang reached out to suggest I post a Show HN to reach a wider audience. I've addressed some of the original feedback too - for example, you can now prefer hills in your routes, as well as avoid them.
This is awesome!
EDIT: In addition to optimizing for green routes, optimizing for low speed car zones would be a killer feature.
The routing algorithm does already prefer roads with low speed limits, but there is definitely more that could be done in this space (e.g. a slider to set a preference to avoid higher speed roads). It also depends on the availability of speed limit data (I use the OpenStreetMap database).
Thus, a lot of route creation is dependent on hyperlocal knowledge. Strava Route Builder, with the heatmap, goes fairly far on this, but it too isn't the best.
This is a really hard problem to solve.
I tested it with your app and the route is near identical to what I've figured (over the course of several thousand km's of trial an error).
I'm amazed!
Edit: I'm usually on a mountain bike.
I’d like to do a dirt/gravel profile. Main reason I haven’t so far is that it’s very hardware-intensive (as in tipping over into renting another Hetzner box).
I usually tend to export routes and navigate with komoot. Komoot for long distance planning is terribly slow as soon as you hit ~200km+.
btw: in general Komoot is a nicely polished app. I can only recommend it :)
Besides large response data and a slaggish planning interface @ komoot: try routing from northern Italy to Sicily: Komoot doesn't seem to know the ferry departing in Villa s. Giovanni to Messina. Komoot will always - no matter how may vias you place - route you back north and send you on a ferry in Salerno. Yes, I know, I could split my route and such. Yet, I love the idea of my planning tool to show me the complete route - including official transportation ;-)
And thanks for building on top of it and making a useful app :)
Do you plan to support area routing?
And you write: "However, the good news ended there: Openrouteservice does not publish the code for calculating this green index". Is your code publicly available and allows "the news to end good" ;) and maybe even integrated elsewhere?
Good point RE the green index calculation. The very least I could do would be to upstream a reference implementation and documentation back to Openrouteservice. I will take care of that.
Very neat app.
For years I've contributed trail data to OpenStreetMap, mostly to support mountain biking, but this is the exact kind of other project it benefits. It was really neat being able to try this on local trails and see just what happens.
One question: What tags does it give priority to?
I ask because I tried it on a local trail system, and it seemed to prefer the wide paved and dirt path as opposed to the mountain bike trail. It was weird in that sometimes it'd use the single track, but in others it'd do sort of an awkward thing through the parking lot / service road (highway=service, service=parking_aisle) then use some of the single track (eg markers 1-2) before jumping on the paved path and pretty much ignoring the single track. The single track is really popular with trail runners in this park, so it got me wondering.
An example of that is here:
https://trailrouter.com/#wps=42.65195,-83.05484%7C42.65088,-...
foot=designated route=root, hiking highway=footway, path, track, bridleway, pedestrian, living_street, residential, service, unclassified maxspeed < 20km/h
Looking at your area (https://www.openstreetmap.org/way/191828180#map=15/42.6423/-...), all of the trails are given equal preference. As a result, it then falls back to whichever gives the shortest path. It's choosing the asphalt one (linked above) just because it's the shortest path. In the future, I may add a surface preference option - so you could give additional preference to non-paved paths.
(Making it worse, someone naively editing a mountain bike trail in iD will end up inadvertently flagging it as highway=cycleway. And then people using OSM for cycling directions get routed down an MTB trail... Yay.)
I know for a fact that the second one is about right, because I ran it already. The first one however is somehow showing "shorter" kilometers, by the end it should be about 2.5km. Did I do something wrong?
Also the first kilometer seems way too short in comparison to the second
Edit: Wait, the numbers are not every kilometer, right?
And yes, the numbers do not represent km, they represent the numbered waypoints listed in the top left box. Any usability suggestions are very much welcome!
And then you can toggle distance measurements.
And for the direction problem, maybe a change of color every kilometer or a gradient? Although that might also be confusing.
Since people were interested, we invited Sam to repost it.
Thanks for the kind words!
Love that your algorithm tries to exclude out-and-backs, I think that goes a long way to make the routes feel organic and appeal to runners. This is really polished and I wish you the best!
One feature suggestion: I wonder if you could have a flag to generate routes starting in parking lots/park entrances in a radius around the starting location. This could go a long way to recommend some common long-run routes where you need to travel a brief distance via car or public transportation but then can get 10-20 miles entirely in the woods.
Your suggestion is a nice one. Here in the UK, where it's common to have trains connecting most towns and larger areas, I have thought about adding the ability to say "I want to run 20 miles, and finish at a train station that can get me home in under an hour". Assuming the user is using a car makes it more easily achievable though. Consider it on the todo list!
More specifically, when 'avoid repetition' is enabled (it is by default), then the routing algorithm has a very significant penalty weight applied to any existing path already taken.
Some thoughts: - Create a community out of it so that people can rate the routes, and therefore provide feedback for the algo? - Use some google streetview or alternative for landmarks along the way so people remember what they should be seeing and don't get lost?
Your suggestion RE landmarks tallies with an issue I've been grappling with: how does a user actually run with the route that they've just planned? Yes, you can export the route to a GPX file, and some users will use that on watches/apps to guide them, but it's a bit clunky and isn't the kind of thing you'd necessarily do for a short 5km run in a new area.
I'd rather avoid building full run tracking functionality, as it'd just be repeating what so many other apps do (and often very well). Perhaps the answer is to enable easy syncing of the route to your other apps. Strangely, Strava (the most popular) don't allow importing of routes via their API.
My preference would be to use Apple Map directions. But it isn’t possible to specify waypoints.
But the official Google Maps URL spec supports specifying waypoints. It would be awesome to click on a link to open the route in Google Maps for turn-by-turn directions.
https://developers.google.com/maps/documentation/urls/guide#...
btw: are you using CH, LM or plain A* for your setup?
I'm using plain A* currently. I understood from the Openrouteservice documentation & code that any time dynamic weights were being used, everything fell back to A* anyway. And I'm using dynamic weights heavily! My understanding could be flawed though, and I appreciate I am going to be a few GraphHopper releases behind now. The speed is okay for now - there's certainly bigger items on my todo list first.
I'm excited to try out GH 1.0 properly. Now that I've got much more familiarity with what I'm doing, I'm keen to switch to using GH directly and somehow try to avoid patching it (or try to get any patches merged back into the open source version).
I was staying near the Colosseum and for one of my runs, thought I’d run on the Appia Antica, because oldest road in the world, into Parco della Caffarella because it looked like a really nice park with lots of trails.
Well, next thing I know I’m running down a one-way cobblestone road with cars coming toward me and there’s no entrance into the park because there’s a huge wall between the road and the park. The road had walls on both sides in fact. I didn't want to turn around because I’d have the cars to my back. So I hugged that wall as close as I could and trusted the shit out of Roman drivers. Eventually I found a way into the park.
Here’s the route Trail Router gave me:
• https://ibb.co/k8m18xq
Here's the run I did that day:
• https://ibb.co/pK6xqMX
The road starts out looking great:
• https://ibb.co/998GQk3 (my picture)
• https://ibb.co/DYXkBt5 (google maps)
But very soon you're on this:
• https://ibb.co/vJcCSXr (google maps)
Well, it was all worth it because eventually I got into the park and I'm still alive:
• https://ibb.co/52VgT1W
• https://ibb.co/dbvG6f5
• https://ibb.co/ZTPknP3
• https://ibb.co/VWxrwnB
I know you're at the mercy of map data. I don't know how unique this situation is. I always appreciate a new route planning tool. I usually use a combination of Footpath Route Planner, the heat maps from Strava, and Google Maps street view and satellite view. It's definitely a pain to do that for every trip. Maps are definitely not optimized for pedestrian safety, and things like sidewalks and shoulder-width are often inaccurate or just not there on the maps short of bringing up street view.
One item for consideration in the future is allowing users to flag unsafe portions of a route and then having that visible to other users (and also influence the algorithm).
FWIW, I'm looking at the routes it's planning from my home and they aren't safe. It's sending me down heavily trafficked country roads with little to no shoulder. I'll email you some screenshots.
Thanks for the new app regardless!
This isn't on by default because in some countries/regions, such roads are very reasonable to run on.
Clearly there's a better middle ground though, which might involve highlighting potentially problematic parts of the route in the UI.
Thanks again js2 for your email and all your feedback!
In that same 6 mile distance, in addition to running past the farms, it could have run me up to the base of the mountains, down the nice bike trail that goes through groves of trees and open field, then back home.
This is one reason I love testing apps like this - my town almost always messes them up.
Especially check out the east side of town, it seems like it wants to go into town for anything short of a 15 mile loop, whereas going east is far more natural.
In other words, you’re a dick
It's great to give helpful feedback about bugs, but please edit out swipes like "Major fail" when doing so. They're especially noxious when someone's presenting their own work. We want people do to that freely on HN, and get helpful feedback, not internet nastiness.
One suggestion: Have changes to the route push state to the history. That way you can use the back button on the browser if you make a mistake. Right now it'll totally take you off of the page.
I tried to solve this in Trail Router by putting an undo button on the screen (bottom right).
I really love running in new places as a way to explore my area as well as when I travel. I find there is something profoundly good about connecting with my surroundings that way. I use Strava Route Planner with the heatmap extensively, and now I think I'll be consulting this a lot.
My only suggestion is to show an elevation profile. There is already a hill preference slider in the settings, but the elevation profile would really make it great to look at.
For viewing the elevation profile, click on the little up arrow on the miles/km distance box at the bottom of the screen.
You can configure a hills preference (either to prefer them or to avoid them) in the settings screen. Click on the cog icon to get there. More details are available at https://trailrouter.com/blog/greenery-and-hills-sliders/