OpenStreetMap-Carto – a look back at the last year


About nine months ago i became co-maintainer of OpenStreetMap-Carto, the map style featured on and in many ways the public face of the OpenStreetMap project.

During this time there have been a number of fairly big changes in the project but most of them are actually not that visible to the map user. I here want to take a look at these changes, the state of the project and its past and future as well as looking back at my own personal goals in it during the least year and what i could and could not accomplish.

I have made a lot more contributions to the project before becoming a maintainer than afterwards – which makes sense in light of my view of the role of a maintainer more as someone advising and supervising than actually making changes. My primary goal when becoming a maintainer has been to develop and establish a clearer set of goals and guidelines. Historically there have been next to no documented cartographic guidelines in OpenStreetMap-Carto and as a new contributor most people will struggle understanding when a change to the map is considered desirable and when it is not.

What i managed to do is establish a set of purposes and goals for the style. This is fairly important because what the purpose of a map is is nothing trivial, especially for a map with such a large number of uses like OSM-Carto. What i however was not able to do is establishing a more specific and more practical set of styling guidelines meant to support contributors in practical decisions. My suggestions for such guidelines did not find general approval and there were no alternatives suggested so we ultimately could not agree on something specific here.

This brings me to one of the big organizational changes in OSM-Carto in the last year. With the appointment of three additional maintainers and the group of maintainers therefore becoming both larger and much less homogeneous in terms of backgrounds, interests and viewpoints the aim of making all major decisions based on consensus proved to become increasingly difficult. The decision was made to depart from the strictly consensus based decision making basis and allow each maintainer more autonomy.

Essentially this means each maintainer can make changes and merge changes of non-maintainers even if there are objections from other maintainers. This change in procedure prevents stalling changes where no consensus can be accomplished (which happened quite frequently before) but it also significantly reduced pressure on maintainers to develop and maintain a common strategy and a common vision of the overall direction of the style.

This kind of makes sense in a project that is part of OpenStreetMap which is largely built on do-ocratic principles. But only time can tell if this is actually going to work for a map design project. The whole thing has a lot to do with how methods of cooperation scale and maintain quality. OSM-Carto is a very large project as far as map styles are concerned. At the same time design work is inherently hard to compartmentalize because of the strong inter-dependencies in the visual results. In my eyes a project of this size and complexity can only work in one of the following ways:

  1. There is one central authority that ultimately makes all important decisions. This was the case with OSM-Carto a few years back when Andy was the only maintainer.
  2. Those in positions of making decisions work together not only towards a common goal but also with a common vision how to accomplish this goal. This requires a high degree of compatibility and mutuality between these people.
  3. There is a set of fundamental guiding principles that applies to all work and that is ultimately enforced by the project to ensure a minimum level of homogeneity and consistency of the results and a reliable work environment for contributors. This is for example the case for mapping in OpenStreetMap. The guiding principles are essentially what is described on How We Map and Good practice. And these are ultimately enforced by the DWG in case the community cannot solve issues on their own.

The thing is that the first and second way have problems to scale if the project becomes very large, this is why mapping in OSM with hundreds of thousands of regular contributors does not work this way and which is why OSM-Carto has departed from the consensus principle during the last year. For a map style project like OSM-Carto it would still be possible to use these ways but this would require a fairly stringent hierarchy in the project and having different people with specific roles and tasks and this might not really be workable for a community project. Large commercial design projects (think of architecture, industrial design and fashion for example) generally use the first or second approach although many of them in addition also have extensive documented design guidelines. The question no one can answer so far is if the third way can work in the long term for a cartographic design project like a map style, especially if there are no clear practical rules for design decisions everyone adheres to and by which the quality of changes and the resulting map is measured.

One principal problem with do-ocracies – even more than with other form of governance – is that they are constantly under the risk degrading into an oligarchy by those in a position of power (because they do things – hence do-ocracy) caring more for their own ability to continue doing things than for the project being open and inclusive and fulfilling its purposes. There is no inherent mechanism in do-ocracy that makes people involved serve or even care for the common good or that rewards such actions. In case of OSM as a whole and as a mapping project in particular the most important regulating factor is that no one can map and keep up-to-date the whole world or even just a city on their own. Working together with other mappers – and not just a hand full of them with similar views but a whole lot of them from all over the world – is an inherent necessity of mapping in OSM so do-ocracy works in a mostly self regulating fashion here. But designing a map style, even a complex one like OSM-Carto, is different. It does not require a lot of people and it it will likely run more smoothly on an operational level if there are fewer people involved in decision making. Of course in the past OSM-Carto has essentially already been an aristocratic/meritocratic system which is also a form of oligarchy.

The other and more technical big changes that has happened in OSM-Carto during the last year is the database reload and the move to using a hstore database which finally lifts the restrictions on what tags can be used in the style and which also got rid of old style tagging of multipolygon relations. This change had essentially been in the works for several years already and i did not contribute much to it. While not having much visual impact on its own it is an important basis for future improvements.

In a similar way the earlier move (from the end of 2016) to Mapnik 3 and to newer CartoCSS versions allowed using some new features which were not usable before. Still design wise the style is largely limited by the rather conservative function set of Mapnik and CartoCSS that makes a lot of things that would be nice to have awfully complicated.

So far the look back at the developments of the past year. In the next post i am going to try looking into the future of OSM-Carto a bit.

Leave a Reply

Required fields are marked *.