In the previous blog post i introduced a bit the idea of systematic testing in map design and how my work on that has led – as a byproduct if you want to say so – to the rendering illustrations you can find on TagDoc.
But there is another problem most automated rule based map rendering projects are faced with that can be solved with systematic testing. Map styles, in particular more complex ones like OSM Carto, face the problem that it is very hard to determine what the style actually renders (meaning which attribute combinations are rendered in a distinct fashion at what zoom levels) by looking at or by analyzing the code. The only reliable way to do that is by actually rendering things. The only meaningful index or map key of OSM Carto that exists so far is a hand curated wiki page produced by people based on their knowledge of the style.
The way systematic testing can be used to help with that is by feeding the style with various combinations of data and checking which of them results in a distinct rendering. As you can probably imagine this would require a prohibitive number of tests if you’d do that in a dump fashion. But by using heuristics to narrow this down, the effort required can be reduced to manageable level – even if you still end up with more than 100k tests in case of a map style like OSM Carto.
And this is what i want to introduce here – StyleInfo is a new tool that i created that allows you to view how various map styles depict OpenStreetMap data – based on an analysis of the style that uses heuristic systematic testing to determine what the style renders and in what form without requiring substantial up-front information about the style.
StyleInfo is structured a bit like Taginfo, it allows you to look at the different keys and tags of the OSM tagging system – but instead of showing how these tags are used in the database it shows how these tags are depicted by the selected style.
In addition you can also look at how the style depicts tags only on a specific zoom level.
All of this is cross referenced with links so you can move between the different views quite easily. A few examples:
- Tags shop=* and how they are rendered in OSM Carto.
- Rendering variants of highway=motorway as primary tag in OSM Carto v1.
- Rendering variants of highway=steps as primary tag on linear ways at zoom level 20 in OpenStreetMap FR Carto.
- Rendering variants of natural=spring as primary tag in OSM-Carto-alternative-colors.
The information about the map style this gives you is somewhat limited particularly in two ways:
- For principal reasons the results cannot be guaranteed to be complete. I have already identified a few tag combinations that are missing in some styles in the analysis and will need to make adjustments to the heuristics because of that. None the less this is still the most comprehensive documentation of OSM Carto and derivative map styles available so far.
- StyleInfo so far shows renderings of primary tags and combinations of primary tags with one secondary tag. Neither combinations of several primary or secondary tags nor tertiary tags are covered so far. What this means exactly i will explain in more detail in the following.
The underlying tagging model
In principle OpenStreetMap uses a free form tagging system – i have discussed that in more depth in context of TagDoc. Practically, all OSM based map styles interpret this tagging in a somewhat more constrained fashion and because of that, mappers also tend to use tags under this somewhat more constrained tagging model.
In this model (as documented on TagDoc) tags are roughly divided into
- primary tags – those are tags that provide semantic meaning to a feature even if they are applied alone.
- secondary tags – those are tags that only have a well defined meaning when applied in combination with a primary tag.
In the context of map rendering and therefore StyleInfo, primary tags are tags that alone – when applied to some geometry – influence the rendering result. That would be tags like
natural=water on polygon geometries,
highway=motorway on linear ways or
amenity=pub on nodes. Secondary tags are tags that modify the rendering of a primary tag. Examples are
name=* on any of the previously mentioned primary tags or
Practically, there are some cases in styles that do not follow that model. For example administrative boundaries are rendered by most map styles only if they are tagged with both the primary tag (
boundary=administrative) and with an
admin_level=* tag (in case of OSM Carto with
admin_level between 2 and 10). That requires introducing a third type of tags into the tagging model:
- qualifier tags – those are secondary tags without which the primary tag is not interpreted by the style.
In addition to the mentioned example of administrative boundaries, the most common qualifier tag is the
name tag on features a map style renders with only a name label.
Note different map styles make different assumptions on what are primary and what are secondary tags – which poses additional difficulties on the analysis. OSM Bright and also OSM Carto in early versions interpret
name=* as a primary tag and render name labels for anything with a name tag even in the absence of any other tags.
And as said – what StyleInfo so far does not cover is combinations of several different primary and secondary tags – which is interesting to look at because sometimes styles distinctly render such combinations (like a road with a bridge tag and access restrictions) while in other cases one tag shadows another (like most cases with several primary tags). What is also not covered is tertiary tags – that is cases where a three tag combination leads to a distinct rendering result – like in OSM Carto certain values of denomination=* in combination with religion=christian on amenity=place_of_worship changing the symbol used.
The principal limitations
Some might have already wondered about the selection of styles featured currently on StyleInfo. As you can see with the Map Machine style the analysis is not limited to CartoCSS/Mapnik styles. However, because of the large number of tests that needs to be run it is necessary that integration tests of the full rendering chain can be run efficiently on general purpose hardware in a headless configuration. And that is difficult for all of the postmodern client side rendered styles popular these days. If anyone can point me to a toolchain that renders Maplibre/Mapbox JSON styles into plain image files on headless general purpose hardware without depending on esoteric bloat like npm or docker i might give it a try.
For OSM Carto and other styles with a rendering database that directly reflects OSM tagging without any fancy tag reinterpretations on import, the map style analysis can be made quite a bit faster by excluding the database import step from testing. This underlines my past observation that the idea of performing tag interpretations on data import instead of during rendering – a consideration that has gained quite some popularity recently in the OSM community – is a bad idea from the perspective of map design. You gain nothing of substance (because tag interpretation is cheap) and it requires the map designer to either integrate the database import into their design work and testing (just like i need to do for the StyleInfo analysis) or to develop their style not for OSM data but for an intermediate data model out of their control (which is what most of the postmodern client side rendered style development tends to do – hence probably the popularity of that idea).
A viable map key?
What StyleInfo documents is how a map style translates OpenStreetMap data and tagging into a visual depiction. While this is evidently a key element of producing a usable map key or legend it lacks the translation between the OpenStreetMap tagging and real world semantics to qualify as such. This is – as some readers might remember – what TagDoc is aiming at. StyleInfo and TagDoc are projects complementing each other and the idea is that those two together could be key components to provide a much better understanding of the semantics of OpenStreetMap data and of OpenStreetMap based map styles to a wider audience.