Imagico.de

blog

OpenStreetMap-Carto – a look into the future

| 0 comments

This is a continuation of my previous post where i looked back at the developments during the last year of OpenStreetMap-Carto, the map style featured on openstreetmap.org. In the first part i looked at recent changes in the project and here i want to try looking a bit into what the future might bring.

So what do all the recent developments mean for the future of OSM-Carto? I don’t really know. What concrete changes are made depends on what developers are interested in which is hard to predict. But it is likely that the changes in procedure i discussed in the first part are going to influence the incentives and motivations for contributions. What i think i can observe when looking at more recent changes in comparison to earlier changes from the last years from an esthetic point of view is a move towards a more naïve art like direction. This is a very interesting outlook which you could consider kind of matching the way mapping is performed in OpenStreetMap. However mapping in OSM – while not being usually based on specialized cartographic or geo-science knowledge and education – in most cases shows a high degree of sophistication and knowledge and cannot really be considered a cartographic equivalent of naïve art.

Should OSM-Carto indeed move more into a naïve art like direction it will certainly struggle with the high degree of complexity and sophistication both of its own legacy and in the OpenStreetMap data itself. How this can work out is an interesting question. On a more technical level this also relates to a problem i pointed out about a year ago.

In the past OSM-Carto has often been vanguard with respect to design in interactive digital maps. Paul Norman recently pointed out several examples for this in his SotM talk on OSM-Carto (second half of the video), in particular polygon size based label scaling, systematic and automated color selection based on perceptual color spaces and multilingual labels. From my own work i could add to that the introduction of program generated randomized periodic patterns which was essentially non-existent in digital cartography before being introduced in OSM-Carto. I predict this kind of innovation will be seen less in the future because development is becoming more focused on localized changes with a relatively low level of innovation and coordination combined with trial-and-error changes like (metaphorically) moving stuff around to test if it looks better that way without a deeper understanding why certain things work and others don’t. This could also lead to the map focus moving more towards the mainstream of OSM based maps as offered by many commercial providers. If the project can continue to attract contributors with the background and vision to develop innovative solutions to the big problems and provide them a supportive environment is something that will remain to be seen.

The most critical point i see with the future development of OSM-Carto is if it can still positively fulfill its function as a feedback tool for mappers encouraging correct and accurate mapping. Anticipating how mappers will react to their data being rendered in a certain way in the map is one of the most difficult tasks for an OSM-Carto developer and getting this wrong can in the long term produce a lot of damage. No matter in what direction the style will steer design wise this is the thing to keep a close eye on. Although useful and constructive feedback for mappers is one of the documented goals of the style now there is no policy or procedural mechanism that ensures changes do not mess with this.

My recommendations for those who care about the public face of OSM and OSM-Carto is to

  • As a mapper resist the urge to adjust your mapping work for its use in the map – either directly as mapping for the renderer or indirectly by mapping or tagging things in a way you believe will make it easier to produce a good looking map for the style developers as i wrote about recently. Instead base your mapping on verifiable observations on the ground. If how OSM-Carto renders certain things you map looks strange or seems to suggest to map things differently also take a look at other map styles and how they render this.
  • Contribute to style development by making pull requests with actual changes. As a non-maintainer you cannot directly make changes but you now only need to convince one maintainer of your change to get it into the map.
  • Hold your maintainers accountable for their work. As explained the style maintainers now have more autonomy in making decisions but this also means resposibility for the changes made. This only works though if map users also provide feedback on changes made. Keep in mind however that just stating you do not like a certain change is not very helpful and convincing. If you see problems with a change in the style that are not a clear technical bug it is usually best to try explaining the problem in light of the documented goals of the style.
  • Develop alternative map styles. From my perspective this is the most important point of all. If OSM-Carto is without alternatives there is much less incentive to substantially improve it than if there are other styles with similar goals but with different design approaches. While there are of course countless general purpose OSM based map styles (only few of them under an open license of course) and also a number of derivatives of OSM-Carto from local communities like the French and German OSM styles most of these concentrate on goals that are fundamentally different from those of OSM-Carto. There are also some style variants being developed as personal projects by OSM community members – like here. What i would really like to see in the next few years is at least about a handful of independent map styles being offered on openstreetmap.org for display each being an honest attempt in providing a good map to the OSM community even if with less manpower than OSM-Carto. Considering how much maps influence the image of OpenStreetMap both from the outside and from the inside through the mappers i think such a development would be most productive and enabling for the OSM-Community.

Leave a Reply

Required fields are marked *.



By submitting your comment you agree to the privacy policy and agree to the information you provide (except for the email address) to be published on this blog.