samcrawford

Thanks for all your contributions to OSM! If you ignore all of the greenery preference then it gives priority to tags:

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.

The first one is an "out-and-back" (so it goes out 2>3>4>5, and then back 5>4>3>2).

Thanks! My suggestion would to start out by checking out your area on openstreetmap.org for two things: Firstly to check to see if the trail you refer to is shown (it should show up as a yellow dashed line if it's a trail). Secondly to see if the woods are shown (this should show in a light green shaded area). Trail Router uses the presence of woods as a hint to prefer paths. Both of these items are surprisingly easy to edit on OSM.

Thanks, I'll consider breaking those two things out separately.

Fully agreed - the amount of data openly available is astounding. I think many people would be surprised at the richness of the tagging information within OpenStreetMap. Without OpenStreetMap, this project and countless others would not be possible.

Mapping costs would be by far the biggest one. However, I'm very lucky that after the last big spike in traffic, Mapbox very generously admitted me to their community programme. You can read more about that here: https://trailrouter.com/blog/mapbox-community-programme/

The server costs are quite modest at the moment (under $200/mo), which I'm lucky enough to be able to self-fund through my other work. If usage were to massively increase then maybe I'd need to find a way recoup costs. But even all of the hits from HN have barely put a dent in the server utilisation, so there's plenty of headroom for the foreseeable future.

Area routing is definitely a topic of interest. It looks like it's still a topic of discussion too: https://github.com/graphhopper/graphhopper/issues/82. Maybe it's something I can help with in the future.

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.

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).

That's very fair, thanks. In cities I wouldn't consider this to be much of an issue as an occasional dead end (e.g. road works) is easily manually avoided. But in more rural locations it can be frustrating. If you're seeing it in your area, then you could consider submitting a correction to OpenStreetMap. It's surprisingly easy to do. I update Trail Router with the latest OSM data roughly once per month.

Steps are supported in OSM, but I don't know if your ones in particular are tagged. Either way, Trail Router doesn't consider them by default. If there is a lot of elevation gain/loss when using the stairs, you can adjust the Hill Preference slider (in the settings screen) to indicate whether you prefer hills or would rather avoid them. You can read more about that here: https://trailrouter.com/blog/greenery-and-hills-sliders/

Nice idea - consider it added to the potential todo list for the future. Thanks!

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.

It uses geoIP data from Maxmind to approximately locate users even before they provide location information. It's not usually _that_ accurate though. It's just intended to get a user to the rough location that they're based in.

Thanks! Yes, the "greenery" preference also prefers water.

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.

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.

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/

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).

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.

It may be that the trail near you isn't on OpenStreetMap (https://openstreetmap.org). If you're interested in fixing that (and thus the myriad of tools that rely on OpenStreetMap data), head to https://wiki.openstreetmap.org/wiki/Getting_Involved

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...

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!

Sorry to hear that. If you could share your approximate location, then I'll gladly investigate.

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!

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.

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.

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.

Thanks for the feedback, appreciated. The reason it suggested that route was (1) the park, as you found, and (2) the Via Francigena hiking route (https://www.viefrancigene.org/en/ & https://www.openstreetmap.org/relation/6201614) follows this road.

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).

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.

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.

Thanks for the kind words!

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!