Imagico.de

blog

A note on OSM-Carto

| 3 Comments

I like to make another note on OSM-Carto here. Background is that there is another wave of negativity (aiming to find a relatively neutral, yet at least a bit descriptive term here) being expressed by some people from the OSM community on some channels regarding the project.

It is not the first such articulation and it was pretty much to be expected that this would become a recurring pattern. The background i already explained at length back in May 2022. Back around that time i made the decision (and i indicated that in the text) that i would continue trying to do my best to support the idea of OSM-Carto, to be an openly cooperative map design project, governed by consensus of a diverse group of maintainers.

What i do is I provide guidance to contributors how to make changes to the style in a way that complies with the documented goals of the project as i understand them and with the unwritten conventions of the style. I explain the historic context how OSM-Carto came to render things the way it does today, explain how things connect design wise creating a harmonic overall result and provide ideas what possibilities exist to resolve the various technical and design problems the style is faced with. And i listen to arguments that challenge the views i articulate and, when arguments are convincing, re-evaluate these views. At the same time i explicitly avoid standing in the way of consensus forming among the other maintainers even if i disagree with those ideas. And i merge changes when they are suitable for the style in my opinion. What i don’t do is approving changes that i don’t stand behind merely because of pressure from others to have them in the style.

I took this approach despite knowing that the chances of OSM-Carto finding its way back to a sustainable strategic consensus among the maintainers would be very small. The alternative would have been to try essentially staging a coup and to attempt single-handedly reshaping the governance of the project in a way that i would consider more sustainable. Or i could have abandoned the project. This would either have killed the project or it would at least have lead to an end of the diversity in governance. And i was not willing to do either of these things because that would have clearly betrayed the idea of OSM-Carto as described. What i did instead was summarizing some of the lessons learned in terms of governance and social dynamics and some key points that should – from my perspective – be taken into account in case someone would want to bootstrap a new cooperative map design project with a similar paradigm as OSM-Carto. It was unclear if something along these line was going to happen of course (and it still is) or if the OSM-Community is going abandon the idea of consensus based cooperative map design and move back to the more common, more traditional single benevolent dictator paradigm or to something governed by a homogeneous group of like-minded people with common interests. But from today’s perspective i stand firmly by my decision to continue holding up the ideals of OSM-Carto but decidedly not trying to actively shape where OSM community map design is going beyond OSM-Carto while continuing to share my experience and thoughts on the matter with everyone willing to listen – both within OSM-Carto development discussion and on this blog.

The recent wave of negativity towards OSM-Carto is remarkable in the level of resentment that is articulated towards the values of the project, its maintainers and me specifically as the person most outspoken about the project and its problems. I have read quite a bit about and also have seen the effects of people radicalizing themselves in closed groups, reaffirming each other in their preconceptions and simplified friend-foe images. But i had previously never seen this process in a setting that is on public record (mostly – at least one of the most vile comments has been silently removed – not before the author received cheers from his peers though).

The whole thing is also telling in context of the bold claims of the OSMF that the channel in question is moderated with the aim that everyone feels safe and confident to take part. I criticized that idea on ethical grounds in the past but it is visible here that this claim also simply fails to live up to its promise. The level of resentment, bad faith insinuations as well as evidently and ostentatiously false claims (including the title of the topic) is remarkable. Personally i don’t really care – it is not the first time people have articulated this kind of spiteful thoughts about me. But it well demonstrates that the whole top-down moderation idea of the OSMF is an empty promise. And there are plenty of people who – when seeing this kind of conversation happening unchallenged in the OSM community – will think twice before they engage actively in this kind of social context. Note this is not me projecting, other people have articulated that very sentiment to me on quite a few occasions. And the problem here is not the lack of moderators sanctioning people breaking the rules (or weaseling around them as it is also openly done here – mit Ansage as we say in German). The problem is that there is apparently no one left on that channel having the courage to push back and calling out the insults, disrespect and plainly false claims, leading to the mentioned radicalization and reaffirmation of preconceptions in a closed group.

I like to emphasize that the sentiment of people, that when things develop in a bad direction they are trying to identify the reason and who is responsible for it, is understandable and often helpful – but also misguided here as far as assigning blame is concerned. And i think i made it clear back in May 2022 already and i will do so again here: The OSM-Carto maintainers having failed to find back to a consensus direction back in 2018 and the years after – that is our failure and we have to collectively accept responsibility for that. Now you could try to assign individual blame to individual maintainers based on how you assess their efforts to achieve consensus within the group, if you like their ideas and preferences regarding map design work or whether you approve of their style of communication or simply who you can relate to better on a personal level. I would not do that. Keep in mind that the OSM-Carto maintainer team was deliberately put together as a heterogeneous group of people, selected not by like-mindedness and common interests but because of their abilities and the diverse viewpoints and ideas they are able to contribute. This diverse composition of the maintainer team is the very essence of the project that made it unique and was largely responsible for its success. Everyone within this heterogeneous group did what they could within their unique abilities for the success of the project. So we own this collective failure as a group.

What is getting lost – and that is the key point – is that the ultimate problem is not OSM-Carto, it is the lack of anything other than OSM-Carto in the field of openly cooperative map design with an ambition of a balanced global representation. I have been pointing out that this is a problem for many years, practically every time i write about OSM-Carto. I have also pointed out that strategically investing in development of software that facilitates openly cooperative map design on that level is imperative for the OSM community. The most recent plans of the OSMF in the context of map rendering are highly disappointing in that regard. Not a single word, let alone a single cent, is invested there into the question what the needs and requirements of community map design are regarding tools.

3 Comments

  1. Hi Chris,

    I’ll be honest here, I really think the last paragraph here has most insightful information of the whole post. I understand that in most cases there is a lot of information to go through, however I think you would be better received by the community as a whole if you were able to abridge a lot of the replies you give to folks.

    Many people in the OSM community are not native speakers of English, and can be intimidated by wall of text replies. A lot of the time you make good points, however they are buried in a massive wall of text that folks just can’t easily or just don’t want to read and parse.

    I do have a couple of things I’d like to ask:

    1. As a maintainer of OSM-Carto, if folks want specific things to render on the map and a Carto maintainer (either you or anyone else) denies it, what would you suggest for us to do to get this rendered on osm.org? Whether you like it or not, Carto IS the standard map render on osm.org, so when folks map things on osm.org and what they map doesn’t show up on the site they just contributed to it can be quite discouraging to even bother mapping those features (even if they are extremely useful in life-critical situations, such as `emergency=defibrillator`). This can lead to these potentially life saving features not being mapped at all, which is bad for everyone.

    2. I agree with you that the OSMF should direct some amount of funding and attention towards renderers. OSMUS and ZeLonewolf (apologies if you are reading this, I do not know your name) have done some excellent work with the Americana map renderer, and I would love to see more projects like this pop-up and give more diversity to maps made using OSM data.

    (originally had these two in the same paragraph as above, but I think its easier to read with them split out like this)

    2a. In terms of funding new map rendering styles, what kind of requirements would you recommend that the OSMF put in place for developers to receive this funding to ensure it is being used in a useful way?

    2b. Would you have any recommendations for folks wanting to start their own rendering project? Would you say it would be better to start fresh and build it from the ground up, or do you think using the collective wisdom and expertise of previous map rendering projects such as Carto or Americana would be a better way to start such a project? Of course there are merits and drawbacks to both approaches, but I feel that I do not have the same insight as you would on such a matter and would love to know what you think.

    I also just want to thank you for developing on an awesome project, I completely understand how thankless open source maintainership can be at times.

    • Thanks for the comments.

      Regarding communication style: Communicating successfully in a culturally and intellectually diverse community is hard. What you describe, that only a small part of what i wrote here substantially resonates with your own thoughts – that is pretty normal in my experience. However, the problem is that what part of the text is successfully communicated and what is not differs from reader to reader depending on their background. The last paragraph here for example contains mostly expressions of thoughts and ideas i had communicated already before. Hence for many regular readers this will either merely be a reminder of things i have communicated before already or worse: An annoying repetition.

      What i can well imagine is that the last paragraph is the part of the text that the largest number of readers agree with. But bear in mind that the aim of me writing this is not to maximize agreement. Disagreement is good, it is what is ultimately the source of new insights for both sides in a conversation. What i try to do is express my thoughts on the matter and explain how they are connected. Not to aim to make others think the same way as i do but to allow people to understand how i think and to compare that to how they think. Ideally my writings incentivize others to write about how they see the matter differently (and what reasons they have for doing so) and we can have a conversation about it that is valuable for both sides.

      1. As a maintainer of OSM-Carto, if folks want specific things to render on the map and a Carto maintainer (either you or anyone else) denies it, what would you suggest for us to do to get this rendered on osm.org?

      Generally speaking – if you want a certain thing to be changed about rendering and you are not willing or able to work on the change yourself you need to convince someone to implement your change. The principal options once someone has implemented a change if it is not accepted are:

      • Accept that the change in question is not going to make it into OSM-Carto at this time. This is usually advisable if there is either a broad consensus among maintainers against the change or there are weighty arguments provided against it.
      • Adjust the change based on the reviews provided. If a maintainer thinks the change can be accepted if certain changes are made this is usually indicated in the review.
      • Try to convince the maintainers to change their mind. Usually reasons are provided for a negative review. You are welcome to present evidence and reasoning to counter the reasons provided against the change. But don’t repeat yourself. If a certain argument for a change was already made before the review it was likely taken into account already.
      • Ask. Maintainers do not always have a lot of time when writing a review so if it is unclear how to proceed based on the comments provided just ask for clarification.
      • Provide a review. Anyone can do that, not only maintainers. Note a review is not a +1/-1 on a pull request, it is a thorough critical assessment of the quality and suitability of a change.
      • Fork the style, add your change there and try to convince the OSMF to render the fork in addition to or instead of OSM-Carto.

      I always try to provide concrete suggestions how to address problems when getting involved in discussion on an OSM-Carto issue. This of course varies on a case by case basis but there are a few things that are common with feature addition requests:

      • Suggestion to work on consensus among mappers about the semantic delineation between tags in case of tags that strongly overlap in use with another tagging or that are umbrella tags for several more specific tags we already show or in case different mappers simply use the tag in very different ways.
      • Suggestion to improve documentation of tags on the wiki in case this is either lacking or where there are discrepancies between the de facto meaning and what is written there.
      • Suggestions what design concepts might work (and which are likely not to work) for the feature in question.
      • Pointers to existing designs in other maps for the feature in question.
      • Pointers to other design elements or technical underpinnings of OSM-Carto that might need work as a prerequisite.

      2. I agree with you that the OSMF should direct some amount of funding and attention towards renderers.

      Note this is not exactly what i am suggesting. I think it would be important for the OSM-Community (and accordingly also the OSMF) to strategically invest in tools needed for cooperative community map design. Strategic investment means decidedly not targeting acute operational requirements but long term strategic needs that are insufficiently served by tools financed by commercial map producers.

      I commented on what the OSMF could do here and here previously.

      2a. In terms of funding new map rendering styles, what kind of requirements would you recommend that the OSMF put in place for developers to receive this funding to ensure it is being used in a useful way?

      As i have indicated in the linked to comment i don’t think it is a good idea for the OSMF to try selectively financing certain map design projects. Quote from there: the OSMF becoming active here in a targeted form would likely do more harm than good.

      For providing infrastructure in a neutral fashion you of course also need to have certain requirements. I would limit those to what is absolutely necessary to prevent abuse though.

      2b. Would you have any recommendations for folks wanting to start their own rendering project? […]

      I commented on what i consider important factors for a cooperative community map design project with a similar scope as OSM-Carto to be successful in my May 2022 text (near the end). If it would be better to start with a clean slate or with an existing style is a difficult question. It depends on your short term and long term goals and what resources you are able to bring into the project. Starting a style as rich as OSM-Carto from scratch is an immense task. But also do not underestimate the amount of technical and design debt OSM-Carto has accumulated over the years that you would inherit if you would based a new style on that. But overall this is a fairly complex and multi-faceted topic so it is not really possible to answer that in a comprehensive way in a comment here.

  2. Pingback: weeklyOSM 685 – weekly – semanario – hebdo – 週刊 – týdeník – Wochennotiz – 주간 – tygodnik

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.