I thought it’d be helpful to use this thread to share interesting ways popular outdoor mapping apps handle rendering.
We’ve been chatting a lot about new ideas for tagging paths and trails, but honestly, getting better rendering support for existing tags might be a smarter move. It could even help improve current tagging practices and open the door to more collaboration with the teams behind these apps.
If you spot any cool examples of how these apps render existing tags, share them here!
I’ll kick things off. Check out GaiaGPS—it gives roads (like highway=unclassified) an off-road look when smoothness>=very_bad.
Next, LocusMap draws a straight, continuous line for a highway=track with tracktype=grade2.
At first, I thought this dashed line was for trail_visibility=horrible or smoothness=impassable, but it turns out Komoot uses it for sac_scale=mountain_hiking. Feels a bit odd, especially since most continuous path lines often have no specific data.
As far as I know, Komoot doesn’t use trail_visibility at all, which is a shame. There are some trails that are not very difficult to hike (and have a low sac_scale), but have very poor trail visibility and therefore hikers could potentially get lost.
How could this be done from the OSM side?
Of course, apart from what has been done so far.
I would not like to see a dictatorship of a conglomerate of apps (Outside Inc) dictating to me how I should label routes and paths in my region.
I don’t understand what you mean by rendering compatibility. It is strange that it is believed that this will depend on the tagging itself and not on the syntax of the json styles used by each of the mentioned apps.
Well, simply we could spend more efforts submitting feature requests and design proposals. e.g. “could you please display paths differently based on trail_visibility tag value, this could be achieved for example this way or that way.”
I don’t think much has been done in that direction yet.
These outdoor apps use OSM data, but a major problem is that most of them ignore useful secondary tags like surface, smoothness, trail_visibility, sac_scale, and so on. This post highlights the few apps that actually make use of these tags. The goal is to raise awareness and encourage better tag support in more apps.
It is fabulous when developers implement user suggestions for their products, but the vast majority do not; they follow their own considerations.
I am one of those who believe there is a balance between raw OSM data and what is ultimately displayed in a cartographic style. This is partly influenced by the target audience these products aim at, which is usually not OSM mappers. Additionally, there is the capacity of people to remember what each line, point, or color in a cartographic style represents. Essentially, there is a simplification to avoid overwhelming the user with too much information. This is why the teams behind the design of a style are typically designers, not cartographers. For them, visual balance often takes precedence over the data itself.
I belong to the group of OSM mappers who use what they map. Like others, I find it frustrating that most apps do not display all OSM data. So, I decided to turn the situation around and, as I map, I also design how I want that data to appear. I do this through MapsForge and its RenderThemes or JSON styles.
A good suggestion for a developer is to allow users to add their own JSON styles to the app (be it their own, third-party styles, or modified ones). I believe Gaia allows linking JSON styles. If it’s ultimately just about changing how the data is displayed in each app, I would approach it with a visual example rather than words. That is, take each style and modify it to show how it can be improved. A request for change via email is unhelpful if it does not specifically detail the changes in the lines of code.
I am not criticizing this post at all; on the contrary, I would like it to be expanded and for more people in the OSM community to participate and share their opinions. However, instead of using it to send suggestions to an app about how their map should look, I would focus more on gathering the opinions and experiences of each participant to design our own style. We should be the ones to decide how it should look and set an example for apps with respect to an outdoor style.
I don’t think this would be a wasted effort. Soon, we will be enjoying OSM vector tiles updated every minute, and an outdoor style created by OSM contributors (not by apps or companies) would be a great success.
Here’s my own example on the Opensnowmap background map.
Organic Maps:
Quoting from the PR:
- “expert” is dotted black (sac_scale T4+ or “horrible / no” visibility).
- “difficult” is dotted brown (sac_scale T3 or “bad” visibility).
- “normal” is brown dashed.
One downside to this approach is that you can’t disambiguate difficulty from visibility, and a trail with no visibility could potentially be very easy (e.g. if it traverses sand or grass).
Still great to see this information visualised though!
This is from the Oruxmaps app, using OpenAndroMaps with the Elevate theme.
The colours reflect sac_scale, with blue, red, and black for T2, T3, and T4 or higher respectively. There is also yellow for T1 (none in this area). The different dash and space patterns reflect trail_visibility.
The style is described in detail here:
https://www.openandromaps.org/en/legend/elevate-mountain-hike-theme
That description also covers track grades (tracktype tag), MTB scales, road surfaces, access restrictions…
Great to see such a detailed and well-documented map legend!
Trailmap is primarily for mountain biking, but it also functions as a general outdoors mapper, tracker and cycling router in Finland. Most OSM-rendering features revolve around highway=path and associated tags.
Uncommon renderer features include
mtb:scale values as color codingobstacle=fallen_treeaccess=private (the angry red dots on both sides of a road, this is Finland so walking or cycling is by default ok. This renderer makes it very explicit if one or both are forbidden.obstacle=vegetation (the green dots by the orange trail in lower right corner)Not shown in the image but Trailmap also has renderings for surface=mud and different trail_visibility values (only considered for narrow paths). The width tag is obviously used as well. Other surface values are used for routing (as are possibly multiple other tags), but I don’t think they’re rendered.
Trailmap has a number of options in what it renders, and it can pull in additional data from Finnish government sources to increase the usability for it’s target audience, e.g. accurate elevation data and buildings. (Private residences are one of the few exceptions to freedom to roam and OSM mapping in rural Finland often isn’t that thorough.)
cycle.travel parses a lot of path/track tags (and derives various assumptions from the highway tag in the absence of explicit tagging), but boils them all down to one of four renderings for traffic-free ways:
An example showing all four:
I did a comparison of different apps when I did an internship at a national park.
Unfortunately most apps don’t even come close to utilizing the amount of detail tagged in OSM. Here is my comparison. Couldn’t cover all possible tags in one image so my main focus was whether informal paths and closed paths are getting shown on the map in a recognizable way.
And Komoot has one of the worst. It unfortunately is one of the most popular apps in Germany and can cause quite some issues in sensitive areas and also trouble for hikers not knowing how rough the terrain can get.
I think the US Trail Stewardship initiative has been doing well there. I think the tagging standards established there should be used across all of OSM and would help getting tagging a bit more consistent in some areas. Alltrails seem to have been cooperating nicely as far as I have seen.
Outdooractive seems to be doing quite well, too. They are also actively cooperating with the national parks to display additional (temporary) restrictions.
OsmAnd has the highest amount of detail and customization as far as I can tell. But some important things are not turned on by default (access restrictions). Locus maps also has some great and detailed render themes from openandromaps.org
Very interesting. Thank you for the comparison!
In my opinion only AllTrails has a reasonable and understandable rendering for the closed ways. Which is kind of sad 
A few more examples for closed (access=no) ways. I couldn’t use the same location as above as the path has reopened, so I chose somewhere near me - not a hiking destination but it doesn’t really matter for this purpose.
AllTrails, as already mentioned, is very clear. It correctly reflects that approaching from the south, the path is open up to a gate and closed to the north of that.
CyclOSM layer from the main OSM website:
Tracestrack Topo from the main OSM website:
OSMAnd with “access restrictions” switched on (not the default I think):
OruxMaps / OpenAndroMaps / Elevate theme:
Great comparison, thanks for sharing! Are these (NO ACCESS) ways based only on access=no/private tags, or do they include activity-specific restrictions like foot=no?
Komoot offers their Hiking layer as part of their (pricey) premium plan, which simply adds a T1-T6 label on top of the basic dashed rendering. The MTB layer includes extra colors but remains quite basic, and I haven’t noticed any updates in the past two years.
I agree that Alltrails has the clearest rendering for access=no
OsmAnd is doing great with access=* or specifics like foot=* because it switches when profile is switch to a specific mode of transportation.
As people have mentioned and shown, the unfortunate part is that access=no is not shown by default.
Unfortunately I’m short on time atm or I would dig a it more into it’s code base and see if I can make a pull request.
