Since the previous two blog posts are already quite lengthy as is, i am going to do the overall discussion in a separate post here.

I discussed the situation of road rendering in OSM based maps in general already in earlier texts so here as a brief summary only:

• OSM-Carto uses – among dynamically rendered OSM data based maps in practical operation – the most sophisticated system of road display and still substantially falls short currently of consistently displaying the road layering.
• What i introduced 3.5 years ago goes significantly beyond that, but neither this concept nor anything else implementing a comparable functionality has made it into operational maps.
• What i showed in the previous post here takes a step further by offering options to do selective styling and drawing order adjustment, based on geometric context rather than only feature attributes.

The bottom line is: While i further expand the design options available in road rendering with this demonstration, we are certainly pretty far away from such sophistication making it into mainstream maps. And, as hinted at already in the previous post, the lack of meaningful visual feedback on the mapping practice in layered road networks, including polygon features, has a significant impact on mapping. It is clear from the data that mappers have a strong interest in recording relevant information in this domain, but the complexity of this in multi-layered structures, like subway stations, makes this very hard to do well without good visual feedback. And QA tools and specialized indoor map apps allowing per-layer display of such structures (which exist) cannot fully replace this.

Or in other words: The lack of progress in improving road rendering in mainstream maps during the past 5 years seems to be significantly holding back also improvements in mapping in that field.

One important question is, of course, if there are other viable approaches for implementing the kind of rendering i show here. And the answer is yes. I already hinted at that in the first part. You can split the linear road geometries into those parts within and those outside of road polygons and render them differently based on this differentiation. You will then, however, have a serious problem at the edges to ensure the roads stay continuous where they are artificially split despite both parts being treated differently in terms of drawing order. Ultimately, you would be substantially constrained in your design options for drawing the roads – which you are not with the approach i showed.

The other important thing i want to mention is that the additional sophistication in styling, modifying the rules in areas of road polygons, can also make the map more difficult to read. The mere fact that underground structures are shown that are otherwise hidden, the deviation from the physical drawing order and additional styling variations – like i show for road polygons overlapping road polygons – can all contribute to that. The challenge for map design here is to avoid this leading to a negative net benefit for the map reader.

Outlook

As already mentioned, what i showed here is essentially just a proof-of-concept. So far it only deals with surface level road polygons. I also have not looked much at the styling of underground roads – this is definitely a field that requires a closer look since many of the tunnel road signatures are too heavy for a well readable display in areas with a dense underground network. Especially also ground unit rendering needs to be considered again in that context. Not to forget the labeling – which is working quite badly at the moment.

And of course the Mapnik extension of per-layer post processing with GMIC has a lot of potential applications beyond what i showed here. It implements point 7 on my list of features rule based map design requires from the tools it uses on the layer level. Offering the same functionality on the feature level would be very nice and useful (for example to extend what i have shown here to non-surface level road polygons). But it is much harder to implement, because it requires delving into the details of AGG. And it also would likely have much stronger performance implications.