The OSMF has recently extended the set of map layers on the OpenStreetMap website. And since none of the map designs of the two new layers has been discussed in my review of the state of map design in OpenStreetMap last year, i feel i need to put that a bit in context for my readers. The OSMF’s announcement in its post truth US PR style wording is fairly non-helpful in that regard.

Here a tabular display of the current set of map layers:

Footnotes:

1. Active development of the Humanitarian style has ended, the style is archived now
2. Maptiler uses non-OSM (Natural Earth) data at the low zoom levels (up to z6) for physical geography (coastlines, waterbodies, glaciers) – which is largely based on >50 years old information.

Some explanation of the columns:

• OSM Website label is the label used on the OSM website for the map layer in question.
• Style is the actual name of the style used to produce the map. Note for client side rendered maps the style has only limited control over what is displayed on the map – as discussed previously.
• Commercial/Community – indicates if the map style is developed commercially or if its development happens by volunteers in a community project. In principle this is not strictly a binary classification – there are, for example, also quite a lot of map styles developed by an individual designer without commercial background. But for the map layers on the OSM website this binary classification works – these all clearly belong into one of the two categories.
• Open Source – whether the style definition is available in full for others to use under an open license.
• Hosting – who does the hosting of the server side infrastructure of this map layer.
• Data Update Frequency – the frequency with which the data shown is updated, specified separately for low/high zooms where applicable
• Tech Stack – the software stack behind the map layer. CartoCSS+Mapnik means the map style is written in CartoCSS (usually to be processed by Carto into Mapnik XML) and rendered with Mapnik. Maplibre means the style is written in Maplibre JSON (or a YAML representation of the same data structure).

Beyond the information on the table another important thing to realize is, of course, that three layers are specialty maps (public transport, cycling), while the rest can be classified as general purpose maps without a narrow thematic focus.

I don’t want to discuss either the new layers added, or the overall selection of layers featured in more depth in this post. But i think it is clear why none of the newly added styles was discussed in my analysis of the state of map design in OpenStreetMap last year – one of them is one of the countless basic commercial Google/Mapbox look-alikes that i mentioned in passing there. One that is open source, of course, but otherwise not really remarkable.

The other one is one of the OSM-Carto look-alikes which try to imitate the OSM-Carto design appearance-wise to some extent. Those i also mentioned last year in passing. What is noteworthy here, in addition, is what i mentioned in the footnote above – that this uses very low quality non-OSM data at z0-z6.

So, in terms of the development of map design in the OSM community, there is nothing really new here. None the less, it will be interesting to watch how this further develops. It is very clear meanwhile, that within the OSMF there is a broad (though publicly not explicitly articulated) consensus in the desire to get rid of OSM-Carto. But there is also quite clearly no strategy on how to accomplish that.

In a way, the situation with community map design in OpenStreetMap is the opposite of that with various core software projects that i discussed a bit in a recent post. With those, the prevalent interest within the OSMF seems to be conservative in nature – to maintain the status quo and to invest as needed (with money and human resources) to ensure the legacy tools remain viable – at least in the short term. With map design, the prevalent interest seems to be to get rid of the status quo without there being a clear picture of what is supposed to replace it.

The main benefit for the OSM community at the moment is that they have an easy-to-access interface now to compare classical server side rendered maps and client side rendered maps directly. This will likely raise awareness to some extent of the effects of lossy data compression that is inherent to all client side rendered tiled maps. If this results in a more fact based perspective on the technical aspects of map rendering, that is certainly an advantage.

Update: I fixed typo in the table (Maptiler -> MapTiler OMT)