When discussing the rendering of roads in detail 3.5 years ago i showed how OpenStreetMap-Carto uses the different options offered by CartoCSS and Mapnik to draw the road network in a consistent fashion but, ultimately, still falls short of this in some aspects. I also showed the new system of rendering the roads in a single layer, used now in the AC-Style, and how this can help overcome some of these limitations.

All of this was done by defining a consistent drawing order of the different features, in many cases in several instances – casing, background, fill, centerline etc. This fully relies on every aspect of the physical vertical ordering being explicitly represented in the data (splitting the geometries as required for that during mapping and, where necessary, using the well known layer=* tag). That works relatively well since mappers in OpenStreetMap often quite diligently record the relevant information on the roads network explicitly. As an additional bonus, it provides clear direct feedback to mappers on how things have been mapped – which helps maintain this high quality mapping.

There are, however, still fundamental issues with this approach that can be pretty severe in the concrete cartographic reality. Most notably regarding the road polygons, where we have two big (and related) problems that i am going to explain below.

Contradicting mapping conventions

Both problems are related to the fact that road polygons (that is for example highway=pedestrian or highway=service polygons – which are used to map pedestrian or vehicle use areas where no single direction of navigation is dominant) are treated exactly like linear roads in terms of drawing order and this is strictly based on the physical vertical order in reality. Although this logic is easy to understand and leads to a clear and easy to interpret rendering (see above), it is also somewhat unexpected in some cases for mappers – which creates the first problem:

It is common that mappers expect features intersecting a highway=pedestrian polygon to be shown above the pedestrian area – like for example a small pond around a fountain or a kiosk building. They would not have the same expectation for a linear pedestrian road intersecting such features, but for highway=pedestrian polygons this is quite common. Sometimes, mappers add layer tags to such features to explicitly indicate the kiosk/pond is located on the pedestrian area. Semantically, this is questionable though, since a surface water area or a ground level building overlapping a non-bridge, non-tunnel highway=pedestrian polygon is incompatible with the established meanings of these tags – independent of the presence of a layer tag. Or in other words: These things are not actually overlapping. In short: It is quite clear consensus among mappers that road polygons should be limited to the area of actual navigation with no implicit (or explicit – through layer=*) resolution of ambiguous overlaps with other polygons.

The situation is different though for overlaps of road polygons with other linear features like waterways or barriers. The overarching convention in OpenStreetMap for linear and polygon elements in general is that overlaps are acceptable in mapping, at least in most cases, even if they are semantically contradicting. A highway=track crossing a landuse=orchard or a landuse=farmland polygon is considered correct mapping. Same for a waterway crossing a natural=scrub or natural=bare_rock. Although no crops are grown on the highway=track and no scrub grows within the river, the mapping convention here is that the linear mapping of the track/waterway implicitly supersedes the polygon landcover/landuse mapping. Data users have to interpret the data accordingly – which, in map rendering, is typically accomplished by drawing the line signatures of the linear map elements on top of the polygon elements.

And here you probably notice the dilemma in map rendering since we have two conventions clashing:

• That linear mapping (of features like barriers, waterways, roads and paths) supersede polygon mapping (like landcover polygons) in cases of overlaps between the two for the area implicitly belonging to the linear feature for where there would be semantic contradictions.
• That in road layering both polygon and linear mapping are together ordered based on physical vertical location relative to each other according to the explicit tagging with bridge=*, tunnel=* and layer=*.

So far, the AC-Style for the roads has been following exclusively the latter principle, which is – as mentioned – frequently irritating for mappers with regard to the road polygons because of the former principle. And giving up on the former principle and cutting out even linear features from the road polygons in mapping does not help practically either, because the gap in the road polygon mapping based on actual ground width of the linear feature does not provide enough space for the line signature of the linear feature to be rendered. You will see something on the map (like in the sample 3 above) but not the recognizable line signature of the feature in question.

You could now get the idea of rendering all line features of the style after rendering the road layers. That would, however, not work well, because the road network would become difficult to read since it gets frequently overlapped by other line features, especially at the lower zoom levels. The other commonly mentioned idea is to sort everything in rendering according to the layer=* tagged – essentially giving mappers control over the drawing order. That is also not a good idea, because it would effectively sabotage OpenStreetMap as a collection of semantically meaningful information about the geography. Right now layer=* has a fairly well defined meaning regarding the relative physical ordering of close-by or overlapping elements. If mappers instead would start using the layer tag instead to define the drawing order of a map or to define override rules in semantically contradicting mapping that would create a lot of damage to OpenStreetMap as a whole.

Hidden tunnels

The other unresolved aspect of the road layering stems from the fact that defining the drawing order strictly after the vertical ordering in the geographic reality does not universally produce the best readable map – even when you only look at the road features. A drawing order following strictly the vertical ordering in reality means that tunnels are universally covered by surface features. For the linear road features this is rarely an issue (at least for the roads themselves – the road labels and oneway arrows are a different matter). For the road polygons, however, if you have a larger pedestrian (or other road type) polygon, that essentially covers all the underground road infrastructure underneath.

Bottom line: For a well readable map you ideally do not stick to strictly defining the drawing order by vertical ordering for the roads. For elements that would otherwise be fully hidden by what is drawn above them the better approach is to try visualizing them out of order in some form. This avoids creating substantial gaps in the depiction of the road system.

Solutions

Tackling this second issue is not possible with the methods so far deployed in road rendering in either OSM-Carto or the AC-Style. As mentioned above, so far these styles base the drawing order and styling decisions fully on information explicitly stored in the data per feature. What is necessary here is interpreting the context – a tunnel feature needs to be drawn differently (in either order of drawing or styling or both) depending on if they are underneath a road polygon or not. This can be done either by

• Intersecting the geometries in SQL. That is computationally expensive and would require adding substantial code complexity to the already complex road layers.
• Using raster compositioning. This seems the more elegant approach here. But it is beyond the limited compositioning abilities of current Mapnik.

The good news is that both approaches will equally allow addressing the first problem of properly displaying non-road line signatures on road polygons – dealing with those differently within road polygons is not much different from the dedicated display of tunnel features within road polygons.

In the next part i am going to demonstrate and explain an implementation of the second method offering a partial solution to the problem discussed.