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).
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.
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 ;-)
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! [email protected]
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.
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?
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.)
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.
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.
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)?
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'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.