Hey everyone, I’m Li the founder of Mud Map. We develop recreational navigation apps and have been experimenting with OSM data for a while now.
One of the challenges is in rendering a useful map for recreational use is displaying roads, tracks, trails and to some degree water lines at appropriate zoom levels in more remote regions where the density is lower compared with urban regions.
In our opinion, most map service online services or offline vector engine experience the same issue. Here are some illustrations of the issue, by comparing Google / OSM / Raster map of the same region:
Google
OSM
Raster map
As you can clearly see, at that zoom level, there’s no detail on either OSM or Google maps, where as the raster map is useful. Yes, you can zoom in on Google or OSM, but with a smaller viewing porting, orientation is more difficult and you loose that nice overview which is very handy for trip planning purposes.
By using a tag specific for rendering purposes, this issue can be overcome. Rendering engines can take advantage of these tags to “optimise” for various regions.
The tags are fairly self explanatory. By tagging a road with render_as:trunk, this feature can be rendered at the same zoom level as a trunk road. Each class of road will have it’s own tag so if a highway:teritery should be rendered at the same zoom level as a primary, then tag render_as:tertiary.
Before a proposal is submitted, can anyone think of downsides to this approach?
You touch an interesting topic here. Traditional maps tend to be highly useful for their intended audience, despite being limited to a single resolution. As I see it, this has less to do with the fact that they are raster maps. Instead, the distinction is that of automated cartography, where a computer program converts a collection of facts into a map, versus manual cartography, where a human performs this task using knowledge and making decisions that are hard to automate.
It’s of course possible to do manual cartography based on OSM: Just take OSM data as a starting point, place a human designer in front of it, and have them optimise the map based on the facts from OSM. But it is clear that you are trying to combine advantages of automated cartography (such as easy updates and crowdsourcing) with the results expected from well-designed maps - hence your suggestion.
I would like to point out that your suggestion is very different from what we usually do in OSM today. The OSM database is mostly application-agnostic. It isn’t intended to be optimised for a particular program or render style, but instead mostly limited to factual information. Unlike that existing data, the tags you suggest aren’t facts, but instead represent design decisions. These cannot reasonably be made without a specific use case in mind, which is problematic in a database that tries to be neutral with regards to potential uses. We are also somewhat cautious when it comes to subjective decisions as there is no single designer who has the authority to make that decision and conflicts of opinions are hard to resolve when it comes to subjective decisions - our “on the ground” rule doesn’t work for that. In the past, we have avoided ratings or personal route recommendations for similar reasons.
With that in mind, a less controversial approach would be to think about why you want these paths to be emphasized: What criteria would mappers use to choose a render_as tag? If you can answer this clearly - i.e. name the underlying facts which this classification would be based on - then you could just ask mappers to collect these facts and avoid the entire issue.
If you cannot clearly name underlying facts, then there is no easy answer. It could be done and some experienced community members have expressed sympathy for similar ideas in the past. But as I tried to explain, manual rendering hints would be fundamentally different from most existing OSM content and are likely to encounter a lot of resistance. Be prepared for that if you try to propose your concept to the wider community.
Thanks for the feedback, i wasn’t sure on how to approach this one. What you said about OSM been a factual database where as a render_as tag as a subjective tag is a good point.
Also appreciate the heads up about the likely resistance, you post has made me realise why the community tries to avoid this.
You also mention that similar ideas have been put forward previously. What were the outcomes and are any of these discussion on going presently?
i would see this as a feature of the renderer and not the database.
i.e. the renderer should determine whether it makes sense to render a track at a certain zoom level in a certain region or not.
for example, if you program a vector renderer, you could let it render objects according to priority until you have a certain number of objects or a certain length of roads in your view. in that way, your map always has a similar “density” but you don’t couple road types with zoom-levels.
From what I remember, the idea was not explored much further beyond initial talk. The discussions usually fizzled out unconclusively (this tends to happen a lot when there is no one who actually intends to invest a significant amount of time into implementing a particular idea). One of the reasons is probably that our rendering technology still isn’t that advanced for the most part, so there are lower-hanging fruit to pluck. There probably will be a point where everything that can be automated is already being done, and the only way to improve the map further would be to add manual rendering hints, but we aren’t really at that point yet.
Interestingly, the Osmarender software even used to support some render hints (http://wiki.openstreetmap.org/wiki/Osmarender/Tags), but that always was a bit of a grey area. I tried to dig up some more links, but even though I remember some conversations about the issue, I wasn’t able to find much in the years’ worth of forum posts, mailing list archives and chat logs.
I’m not aware of ongoing discussions right now, I don’t think this topic came up in the last few months at all. If you indeed want to probe the wider community’s opinion on this, then asking on a mailing list might yield more responses.
