In my previous blog post on road rendering in OpenStreetMap based maps i focused on better and more consistent layering of road feature and depiction of additional physical characteristics of roads, in particular the ground unit with rendering, visualization of the number of lanes, differentiation of paved and unpaved roads as well as implicitly mapped sidewalks. I did not much look at the basic classification system for roads and other non-physical characteristics of roads depicted in the map.

Traditionally in OSM-Carto and derivative map styles roads rendering depicts roads primarily according to the road classes, that is the highway=* values assigned by mappers. This system of road classes is mostly a classification system based on primary mode of transport and intensity and purpose of road use.

In addition OSM-Carto traditionally depicts another non-physical aspect of roads – the access restrictions. Access restrictions are traditionally rendered in OSM-Carto in a very basic form – access=no and access=private are depicted with a broad and rounded gray dashing on top of the road line while access=destination is shown with a similarly styled dotting. For the narrow road classes (track, path, footway etc.) only access=no/access=private is depicted with a lighter/de-saturated line color.

Towards an intuitive interpretation of access restriction tags

This system is widely (and for a long time) considered a too simplistic interpretation of access restriction tagging, which is one of the strong points of OpenStreetMap since it allows for a very differentiated mapping of all kinds of access conditions a road might have. Picking just three very undifferentiated types of access restriction tagging to depict sends the wrong message to mappers wrongly incentivizing them to simplify a complex and differentiated reality to just these values already on the tagging level. And it is also of fairly little value for the map user because they really cannot tell much from this simplistic depiction regarding if a certain road can be factually used for a certain purpose in a lot of cases.

The starting point for my work on access restrictions rendering i am going to talk about here was that after introducing differentiation of paved and unpaved roads for all major road classes (see the previous road rendering post for that) readability of access restrictions rendering was kind of poor in some cases. This has led to considerations in OSM-Carto that it might be difficult to depict access restrictions rendering and paved/unpaved differentiation at the same time and considering the problems described in the previous paragraph it might be worth considering to simply drop the access restriction rendering in favor of the paved/unpaved differentiation. I reviewed the colors adjusting the gray tone used for the unpaved dashing individually for the different road backgrounds for a uniform contrast and readability and i think the results are fairly decent.

The main step towards an intuitive interpretation of access restriction tags in a map is in my eyes to focus on what restrictions actually apply to the main mode of transport of the road class in question. That requires interpreting a lot of different tags because of the way access restriction tagging in OpenStreetMap works.

Traditionally in OSM-Carto we try to have a relatively simple and easy to understand relationship between tagging and rendering results. We believe that this is essential for mappers to be able to use the map as a feedback instrument for mapping. If the mapper does not understand how their tagging results in a certain appearance in the map they cannot derive any hints from the map if they mapped things correctly or not. However for access restriction tagging a basic understanding of how the system of tags in OSM for that works is a fundamental prerequisite for correctly mapping things. The UI of editors can help with that of course. The map style however cannot. And once we as style designers accept that such basic understanding of access tagging on the side of the mapper is a prerequisite for us providing useful mapper feedback it quickly becomes clear that we can best support mappers and non-mapping users by interpreting the tagging in total for what it means regarding the primary transport mode of the road class in question.

The primary transport modes i assume as well as hierarchy fall-backs are as follows:

road class	primary transport mode	fallback access tags
main road classes	motorcar	motor_vehicle, vehicle, access
highway=track	motorcar	motor_vehicle, vehicle, access
highway=cycleway	bicycle	vehicle, access
highway=bridleway	horse	access
highway=path	foot	access
highway=footway	foot	access
highway=steps	foot	access

In terms of access values i interpret

• destination, customers and delivery as light (previously destination)
• no and private as no
• yes, designated and permissive as yes – for highway=track also agricultural, forestry and agricultural;forestry
• all other values are ignored

This logic is implemented in a Postgresql function you can find in roads.sql. Here is how this looks like in principle.

So far we have been treating access restriction as a simple binary yes/no or ternary yes/no/light classification regarding a single mode of transport considered the primary one. This is often insufficient to decently depict the practical reality of the road use and its restrictions and permissions. This is why i also looked into situations with something like access=no, but… – in other words: Roads that are closed to all forms of use with a single exception. The practically most relevant cases of this type for the normal road classes are access=no + bus=yes for bus only roads and access=no + bicycle=yes for cycling roads. These i tried to indicate by coloring the access restriction dashing in a pale version of the colors of the respective roads.

Implicit access restrictions

Experienced mappers among the readers will probably have noticed that so far i have left out two pretty common road classes in my discussion and illustrations. Those are highway=pedestrian and highway=living_street. In contrast to most of the other major or wide road classes (those drawn with a fill and casing as opposed to the narrow classes drawn with a single line and a bright halo) these are defined mostly by implicit access restrictions. highway=pedestrian is for roads that could be used with a car but that are not allowed to be used with a car and reserved for pedestrians. They essentially have the implied access tags access=no + foot=yes. The exact meaning of highway=living_street regarding use permissions is a bit more vague and varies from country to country – mostly it means pedestrians have precedence over vehicle traffic here while vehicles are still allowed, often with some restrictions.

There are other road classes with similar implicit access restrictions suggested and partly used by mappers in OSM, specifically highway=busway and highway=bus_guideway. The suggestion to add support for highway=busway to OSM-Carto and the difficulty to do so in a consistent way was one of the factors that inspired me to work on this topic here.

There are two possible ways to integrate rendering of such road classes with implicit access restrictions into a map style. The first is to render them like a normal road with the implied restrictions tagged. That would – for highway=pedestrian and with the above scheme for rendering access restrictions – mean like highway=residential with red-orange access dashing. The advantage is that this would be intuitively readable for the map user who knows about the system of access restrictions rendering without learning specifically about the highway=pedestrian road class. The main disadvantage would be that highway=pedestrian roads often form fairly dense networks in town or city centers and all of the red dashing would create quite a lot of noise on the map. And by displaying the implicit access restriction you essentially have no room left to show any explicit tagging of access restrictions and permissions. The other – and commonly used way of rendering – is to treat them as a distinct road class. This is the approach OSM-Carto takes and that i took for the alternative colors style so far. And i unified highway=pedestrian and highway=living_street to avoid having too many distinct road colors. This was not quite satisfying though because the practical meaning of the two is quite different.

The situation with highway=busway is yet another difficulty because those mappers who introduced this tag want it to be used for some – but not for all – bus exclusive roads. Hence the aim would need to be to distinguish between highway=busway and normal roads tagged access=no + bus=yes in a meaningful and intuitive way or to unify them in design. And to not be confusing the approach would need to match that for highway=pedestrian of course. As an additional quirk we have in OSM-Carto for a long time rendering of highway=bus_guideway in a railway like fashion – which might make some sense from an engineering perspective but makes very little sense from the practical map user perspective.

To demonstrate how all of these issues can be addressed together i went for a base design as shown in the following with a violet color for highway=busway/highway=bus_guideway (which works better in the ac-style than in OSM-Carto because of the violet color for transport related symbols) and the previous light gray for highway=pedestrian and highway=living_street. In contrast to OSM-Carto which does not render access restrictions on highway=pedestrian (likely because that would clash with the implicit restrictions of this road type) i do so – based on the paradigm that the access dashing represents the de facto restrictions for the primary mode of transport. This is not that common practically for highway=pedestrian but there are cases where this applies – for example for pedestrian roads in military complexes or non-public parks.

But there remains a serious question with roads with implicit access restrictions: How to depict exceptions from the restrictions like i do with the colored dashes for explicitly access restricted roads? We can’t use the colored dashing because we have made the choice to not use that for the implicit restrictions. Yet this implicit restriction with exception situation is a fairly common case – in particular for pedestrian roads where bicycles are allowed. The solution that i chose and that i think works quite well is to use a continuous colored center-line for additional permissions compared to the primary mode of transport. This also nicely allows for a general differentiation between highway=pedestrian and highway=living_street – by indicating highway=living_street to be like a pedestrian road with additional permission for vehicles. How this looks like can be seen here:

Two final points – first: If you followed my previous post on roads rendering you might notice that the use of a solid center-line signature kind of interferes with using the same context to visualize lanes. Yes, it does, but the two still work decently together with some limitations to readability and also this is a rare combination – lanes tags on highway=pedestrian and highway=living_street are really rare. And second: Yes, on busways the center-line rendering is fairly poor in contrast and can be hard to reliably read, especially in the unpaved version. Again – this is a very unlikely combination practically and i included it here mostly to demonstrate the design and tag interpretation concept in principle, not because it is such a practically relevant combination. The colored center-line rendering could equally be dropped on the busways.

And i am not even sure if at this time a distinct rendering of highway=busway is advisable because there is not a clear and well established semantic difference between that tag and normal roads with access=no + bus=yes independent of local culture specific conventions. I included it here mostly as a demonstrator to have another type of implicitly access restricted roads in the mix and show that this rendering concept allows for such extensions.

Practical examples

Here a few practical examples of this new rendering using real world data.

Note in particular how – with the colored center-lines and colored access restriction dashing – you can pretty well spot continuous routes for cycling in a network of predominantly pedestrian or otherwise access restricted roads for example.

What these examples also show in some places is that both the changes introduced here and the previous road rendering related changes in the ac-style interpret a lot of tags that are not that frequently interpreted by maps elsewhere. This makes the map fairly difficult to read in some situations because of errors and inconsistencies in the data. Even just the mapping of certain aspects being incomplete and patchy can add a lot of noise to the map and make it rather difficult to read. But ultimately that mainly means that maps providing visual feedback on these features to mappers are badly needed.

Conclusions

So what did i show here? I presented a new system of interpreting and displaying access restrictions and permissions on roads that is close to the tagging system of OpenStreetMap by following the main road classification system but applies a considerably higher level of tag interpretation on the access tags to generate a meaningful and intuitive rendering.

Of course this adds quite a lot of design elements to the map that a map user needs to get acquainted with. In particular the added use of color makes the map fairly colorful in some settings – even though the color semantics are consistent across the whole domain of roads making it quite intuitive overall. Still it stretches the limits of what you can reasonably claim to be a map that can be understood without a map key.

Overall i think this is a viable demonstration how access restrictions like they are mapped in OpenStreetMap can be depicted in a manner that follows a consistent inner logic in terms of the symbology and presents the restrictions and permissions of roads in a meaningful way to the map user, significantly increasing the practical usefulness of the map compared to OSM-Carto. And as i discussed above i think this also significantly helps mapper feedback compared to the selective depiction of access=no/private/destination known from OSM-Carto. While the mapper cannot directly see the tagging in the map display any more with the new system and need to understand how the system of access restriction tagging in OSM works up front to make sense of the rendering, i think this practically is more useful and more valuable.

Most of the complexity of the tag interpretation logic is in two Postgresql functions which are generic in nature and not specific to the visual design used. Technically the same could be implemented with a lookup table for the different tag combinations which some developers might consider more suitable depending on individual preferences and taste.