Which are you using?
For most things (day trips, few km after work…) I use multiple of them.
- online and offline mobile app
- trip planner works pretty well
- you can check out places (photos, reviews…) when online
- well maped whole Europe
- not enough information about roads (asphalt, paved, gravel…)
- basically interactive version of KČT maps
- can’t find app
- basic planner, but better for drawing your route
- much more helpful info about roads
- it is just automatically scaled paper map, so you have to know how to read it
Osm clients - I tried multiple of them.
Paper maps - from the same company that makes the Cycloserver maps. You can get set of them for about 100€ (CZ not sure about SK). There is just something special about planning trip on paper maps.
It’s also based on OpenStreetMap. It doesn’t have all the bells and whistles of OsmAnd, but in return it offers a cleaner UI.
And then of course there’s no beating brouter for route planning so sometimes I plan the route on PC (or the mobile site!) and import the track to Organic Maps. Mostly I don’t bother though as OM routing is pretty good too.
And hey, since all of these tools rely on OpenStreetMap data, let’s not forget StreetComplete for contributing! E.g. there’s an easy overlay for marking cycleways.
And hey, since all of these tools rely on OpenStreetMap data,
By the way, I have in my area a road that is very dangerous for bicycles because it goes through several unlit tunnels. It’s a former single railway line turned into a one-lane, one-way road; most cars enter the tunnels way over the allowed max speed without seeing at all what is inside.
All routing tools based on OpenStreetMap insist on routing through this road, despite the fact that there is another (larger) road on the other bank of the river. They just go in parallel 25 yards away for each other.
A couple of years ago, I edited OpenStreetMap data to mark the tunnel with “lit=no”.
But that was in vain, routing tools don’t take this parameter into account and keep routing bicycles through the (smaller) dangerous road. They prefer to route through the smaller road, which is generally the right choice, but not at all in the present case.
Does someone know if/how I can mark this road as “non-suitable for bicycles although they are allowed there”?
There’s no one tag to do this but a combination of mapping the negative sides of the tunnel road and the positive sides of the bigger road should be enough.
Some ideas:
- cycleway=no for the tunnel road and perhaps something like cycleway=shoulder for the bigger road
- Maybe the bigger road has better asphalt? Tagging smoothness values of both can help.
- Are there official cycle routes going through? Many routers take these very seriously. Note that it may be that there’s an outdated route mapped through the tunnel road.
There’s no one tag to do this but a combination of mapping the negative sides of the tunnel road and the positive sides of the bigger road should be enough.
That’s what I feared: the routers can use anything with any weight, and we cannot know about it. It could be a good idea to reach people doing the routers and tell them that stuff like unlit tunnels should be weighted negatively.
Some ideas:
cycleway=no for the tunnel road and perhaps something like cycleway=shoulder for the bigger road
I can add “cycleway=no” for the tunnel road (cycleway is not set there), but the bigger road has “cycleway:both=no” already set, and well, that’s the reality.
Maybe the bigger road has better asphalt? Tagging smoothness values of both can help.
That depends on the year :-) But something is constant: the potholes inside the tunnels; so yes, I can at least set “smoothness=bad” under the tunnels.
Are there official cycle routes going through? Many routers take these very seriously. Note that it may be that there’s an outdated route mapped through the tunnel road.
I cant’ see such route on RideWithGPS’ “Cycle OSM” view (I guess I would if there was one), and I don’t see any of the tags present on the page you linked in OpenStreetMap objects data either.
I’ll perform the two small modifications I picked from your list, and see after a few weeks or months if something seems to have changed, or not.
Thanks for the pieces of information you gave me.
While we’re at it, I have another case in the area that always annoys me: Example on brouter.
I guess the case is rather common: the router routes through smaller roads/street while the bigger road is more convenient. The smaller street is super steep (>12%), while the bigger road was built much later with a rather smooth 7-8% gradient. There is very little traffic on the bigger road. The smaller street is not only a problem when going up: when you ride downwards, the brakes suffer a lot, yet you are supposed to make a full stop at the bottom crossroad, an you really need to (as there is zero visibility there), unless you want to be run over by vehicles from the main road 4 feet farther…
I thought that the smaller road/street being partially marked as “highway=residential” would have helped picking the bigger road, but nope.
Do you think setting “incline” would help routers to pick the main road? Or any other tag?
Yes I think that mapping the inclines would be the way to go here. Typically maps have some elevation data from other sources but this should be more precise.
Brouter is also super flexible! You can set the downhill and uphill costs in the profile tab. Increasing them to 90 made it prefer the bigger road in both directions in your example.
Yes I think that mapping the inclines would be the way to go here. Typically maps have some elevation data from other sources but this should be more precise.
OK, I’ve added the “incline” tag on the small street (I had to split several paths to do so, because they had been drawn as parts of other roads/streets).
Brouter is also super flexible!
I see. That’s very interesting.
You can set the downhill and uphill costs in the profile tab. Increasing them to 90 made it prefer the bigger road in both directions in your example.
Wait, by default they have a penalty on downhill, but not on uphill??? What the… I see 60 for “downhillcost”, and 0 for “uphillcost” for most predefined bike profiles… Do you see the same?
Yeah that seemed a bit odd to me too, but from a physics perspective it does make sense: https://github.com/abrensch/brouter/issues/309#issuecomment-855833481
Basically it aims for energy efficiency by avoiding excessive wind drag.
Yeah that seemed a bit odd to me too, but from a physics perspective it does make sense: https://github.com/abrensch/brouter/issues/309#issuecomment-855833481
It doesn’t make sense in practice, because one doesn’t ‘waste’ energy in a descent. One can ride it down with 0 Watt. Nobody ever avoided a route because there was a downhill on the way :-)
The problem is going up. And the steeper the uphill is, the worst the problem is.
In the example I had taken, if I take the 12% road, I need to take a rest on top of the section (in the best case, otherwise I may even need another break in the middle). And I am pretty dead after the common section, and I carry that in following sections again (recovery is not my strong point :-)). If I take the 8% road, I can ride it in one go, then I may or may not struggle in the following sections because I am a bit burnt. If there was an hypothetical twice-as-long road at 4%, I would start the following sections as fresh as a daisy.
Note that going up can be decorrelated from going down. I absolutely don’t care about which kind of gradient is exhibited by the descent that might come after.
In their logic, they also forget that even with a nice, flattish descent that they wouldn’t penalise, it is always both faster and easier on the legs to ride around the hill than climbing up and down through a pass, even though the detour is a bit longer. Because the climb is what kills it all, it rarely works as an investment as they call it; it rather hurts your legs and diminishes your abilities for the rest of the route.
Basically it aims for energy efficiency by avoiding excessive wind drag.
Yeah, and I don’t think that’s the right metrics in most cases :-)
Personally, if we set aside true winds, the only situation in which I sometimes care about wind drag is over long downhill false-flat sections (and only when I am in a shape, for that’s the only combination where the speed can have an impact on me). This situation is specifically the one case that they don’t penalise…
Anyway, as you said, that piece of software is highly configurable, so one can configure it as one likes when one disagrees with their logic.
Edit : would you happen to know which Brouter parameter should be set/tweaked to avoid/limit the occurrence of U-turns? By “U-turn”, I mean that when I set an intermediate waypoint, my intention is generally to go through it and then keep going on the same road or general direction, not turn back and come back the way I came.
See Example . You see how I engaged my intermediate waypoint on the D32 and D17, but the router goes to the waypoint, and then comes all the way backwards to take the D618.
Of course, in practice, I can move the waypoint or add new ones, that’s how I always did so far with other, non configurable, routers. It’s not a big deal.
Sherpa has been a helpful tool.
Looks nice.
Unfortunately for my location and usecase it is not that useful. Map overlays are main issue -there is just not enough info . G-maps are shit, and basic OSM cyclo map is still limited compared to my picks (some mobile OSM clients solve it by showing more layers).
Maybe for checking my planed route but not for planning. But for US or other locations this may be useful tool.
I use brouter for planning a route at home. I plot a route that i then use as an overlay in OsmAnd on my phone and then route my daily segments on the go (with the brouter as a routing engine for OsmAnd, offline routing). I only plan the big route, no daily segments, probably will have a plan for the first day though when i start.
There’s also the cycloroute render style for OsmAnd, i like the look of it, but i got so used to OsmAnd default rendering that i just keep using that.
In cities i use google maps for shops and stuff because osm data is kind of lacking in that regards i think.
I like having a paper map too, just to have a better feeling of where i am and what is where, i don’t think a phone screen is great for that. Especially when i’m making routes up on the go. Nice souvenir too, if you buy a map on the road. I’ve also been sending paper maps home when i rode out of its boundaries, so i don’t need to carry it along.
There’s also cycle.travel which many people seem to like. IGN must have a very good (paid) app for France. There’s an IGN layer in brouter too for France. Michelin has “scenic routes” and “dangerous roads” marked, i have used this sometimes but also really only good in France.
Yeah, nearly the same here. Brouter-web for planning + overpass queries to find infrastructure POIs (drinking_water, supermarket).
On the go: OSMand installed via F-Droid, following the gpx track or routing with brouter on my phone.
I’ve got a routing profile for following designated bike routes (luckily quite plentiful in Germany) and one that concentrates on good surface conditions for bad weather set up in brouter that are bound to two different profiles in OSMand.
I’m switching in and out of the cycloroute style on OSMand. It’s useful for planning, but on the bike I’m not used enough to it to interpret it at a glance.
I will give a brouter a try it looks more feature rich than openstreetmap.cz
I’ve been impressed with how well cyclers.app works in my part of the US. It does a great job routing me to avoid car traffic even in suburban Texas.
I’ve found Komoot and Organic Maps to be my favorites. The former for tour/long ride routing and the latter for everyday commuting. They’re both using OpenStreetMaps behind the scenes which, for the region I normally ride in, is fantastic. Google Maps lacks a lot of the paths/surface information that OSM has, meaning the routes that Komoot/Organic Maps come up with are generally the preferable options.
