Imagico.de | blog

September 25, 2026
by chris
4 Comments

The OSMF board elections 2026

As i indicated before i want to write a bit about the situation of the OpenStreetMap Foundation before this year’s board election, which is going to happen from October 10 to October 17.

This is not going to be substantially about OSMF policy and operational decisions but about the overall situation of the organization and the long term trends.

The background

What we have seen over the course of approximately the past 10 years as a long term trend is a roll-back of transparency and public interaction of the OSMF board with the OSMF membership and the OSM community at large. When exactly this had begun is a bit hard to tell – we have had the transparency initiative from the 2015 board substantially expanding the interaction of the board with the community and the involvement of the OSMF membership. The first major roll-backs of transparency happened under the 2019 board. Most notable being the first non-public board meeting since 2015 in May 2020 – framed mid month board chat back then, but meanwhile clearly the more significant meetings in terms of actual deliberation of the board taking place than the public ones. Most of the transparency rollbacks were subtle and came in small steps difficult to individually recognize if you are not familiar with how the OSMF used to work before. Contracts for long term paid work, for example, used to be public, so the community could transparently see what exactly those doing paid work for community money were contractually obliged to do and if these were fair and balanced terms. Martin Raifer’s contracting in 2021, as far as i remember, has been the first contract for long term paid work since the 2015 transparency improvements that was not made available to the OSMF members. Grant Slater’s hiring in 2022 was the first paid work contract that was done without a formal board decision. These days none of the contract terms for paid work are known to the OSMF members any more. So the OSMF membership and the OSM community do not know what those people who receive community money for their work are contractually obliged to do for that money.

In terms of bigger anti-transparency measures the board committees are also noteworthy. In 2020 the OSMF articles of association had been amended to allow non-board-members on board committees. We now have two committees in the OSMF under these terms. They recruit their non-board members autonomously and apparently with neither a formal process nor formal documentation of the appointment (so to understand who became a member of these committees at what time we have to trust that the documentation on the OSMF website is always updated in a timely fashion. There is effectively no oversight of the OSMF membership over these committees or consultation of the OSMF membership about the work of these committees. Legally, the committees are obliged to produce minutes of their meetings, but neither of these committees seems to actually have meetings (the personell committee not at all, the finance committee not since 2024). The personell committee publishes yearly PR style reports but nothing that allows any meaningful level of scrutiny by the membership on their work and their role in the OSMF.

In parallel to the transparency rollbacks we also saw a massive decrease in bidirectional communication of the board with the OSMF membership at large. The most noticeable event in that decline was the introduction of the moderation regime on osmf-talk in 2022 which was around the same time when open discussion among the OSMF membership about OSMF matters and board decisions died off. It is not that the introduction of formal moderation is clearly the sole reason for the decline in engagement between the OSMF board and the OSMF membership, but it definitely was a factor.

The bottom line is: These days there is practically zero eye level communication between the OSMF board and the OSMF membership and the OSM community. I already pointed this out more or less when i contemplated about who the actual members of the OpenStreetMap Foundation are. The OSMF board has since then even further retreated into the bubble of the de facto membership of the OSMF as sketched in that post and is practically – as board members – hardly having any direct interaction with the OSM community outside that bubble any more – and indirect interaction mostly in the form of asymmetric top down corporate style PR.

This complete unfamiliarity with actually openly talking to the OSM community on OSMF matters often becomes obvious in a rather funny way during the public board meetings when board members try to explain things to their audience with shallow PR statements while the non-board members present are usually me and a few other long term OSM community members who often are more familiar with the subject at hand than the board member talking.

I will leave out the considerations on why all of that is happening – partly because that feels too much like giving advice to an organization that has no interest in or appreciation for said advice, partly because – due to my rather limited insight into what is happening behind the scenes in the OSMF outside the scrutiny of the OSMF members – there would necessarily be quite a bit of speculation in that.

What i think can be said without much speculation – and what i hinted at in my contemplations on the actual members of the OSMF – is, that the OSMF board seems to be increasingly weakening in its influence on the organization. That the OSMF is under democratic control of its formal members who elect a board to represent them, which then governs the organization, is increasingly an illusion, because

the OSMF members lack the ability to make competent decisions to elect the most qualified people to the board to lead the OSMF in a way that serves the needs of the OSM community, in particular because:
- thanks to the transparency rollback and the failure of the board to communicate with the members in a meaningful way the members lack basic information on what is going on in the OSMF.
- due to the managed pre-election interaction between the members and the board candidates the members can neither assess the candidates’ ability and willingness in engaging in meaningful open discourse with the community nor can they ask critical questions assessing the candidates’ views and positions on matters of importance.
As a result people are elected to the board without a meaningful assessment if they have the skills necessary to substantially lead the organization.

If you observe the board and their decisions these days it is clear that their understanding of the background and competency on matters they are involved in is not only way behind that of domain experts in the wider OSM community (which is a problem since the board fails to openly seek input from those domain experts outside the OSMF’s inner circles), the board seems also highly unfamiliar with both the formal and informal procedural rules of the organization. You get the clear impression that the board is increasingly living in the moment and makes decisions largely ad hoc and context free without a long term strategy – exactly what Allan Mustard criticized as muddling through.

But you can’t expect to effectively lead an organization if a large portion of your decisions ostentatiously ignore the rules you (or your predecessors on the board) have created.

And the resulting absence of actual leadership from the board does not – as some might hope – lead to an absence of hierarchical structure in the organization, it leads to a shift of de facto influence and power towards informal structures and compartmentalized cooperations behind the scenes – structures and processes that are not only opaque and impervious to outsiders (which includes the OSMF membership), but also increasingly to the board.

This year’s board elections

All of these developments roughly sketched above seem to have culminated in the farce of this year’s board elections.

There are four seats (of seven in total) open for election this year. It had been established since many years that to motivate qualified people to volunteer for running for the board it is important for existing board members whose seats are up for election declare their intent to either re-run or not to re-run early – ideally before, but latest at the beginning of the nomination period. The board has never codified this principle in the board rules of order, but it has been a known community recommendation for many years and frankly i would consider it even an obvious principle of fairness.

Now here is the timeline of this year’s nominations:

Timeline of this year’s self nomination of board candidates for the OSMF board

Bottom line: None of the board members declared their intention before the nomination period and only one of them nominated themselves at the beginning of the nomination period. Even the one board member who ultimately did not re-run, first nominated herself late, and then withdrew. There might be good reasons for doing that, but nothing in that direction was communicated at any point in the process. The irony of the whole thing is that the board member who withdrew could well have been the most qualified person currently on the board (a bit hard for me to tell based on the limited insight we have based on just the public board meetings and their minutes – but a lot of things point in that direction for me).

As a result we have a meaningless election this year with four candidates for four seats. And the main reason for that is – i clearly want to state that here – the failure of the current OSMF board to meaningfully communicate with the OSMF membership about their work during the past years – essentially discouraging any interest from the OSMF membership at large in the OSMF. But i also want to clearly state: The individual board members of the OSMF are just people who have volunteered to take on a thankless and time consuming task to try to lead the organization together with six other individuals who they had almost no say in picking. So it is ultimately we, the OSMF members, who are to blame for having picked the wrong people for the job, or more accurately – due to the low participation of members in the election – for being completely indifferent about the OSMF. That lack of interest is, of course, to a large extent the result of years of the OSMF practically changing to become about as uninteresting to its members as possible – kind of: nothing to see here, move along.

What can be said for sure already now is that this election is going to seriously damage the legitimacy of the OSMF board as a democratically elected representation of the OSMF membership. None of the four board members elected this year will be able to claim to have prevailed in the election process against alternatives. They are not even the least bad of all the bad options (as some might have framed the choice in past board elections) – they are simply the only options available.

You might ask if there is anything the board could do at this point to mitigate this disaster? Yes, there is. The four “elected” board members could step down after the election and either the board or the membership could call for a new election. If the board is worried that operating with only three board members until the new election is difficult they could temporarily re-appoint the board members who stepped down (the board is allowed to do that, the seats of ad-hoc appointed board members are automatically up for election at the next general meeting).

But, of course, without any substantial change in communication of the OSMF board with the membership just re-doing the election is nearly pointless. A fundamental restart of the social contract of the OSMF as an organization with its formal membership would be necessary.

My recommendation to those OSMF members who are dissatisfied with this year’s election and how the OSMF board handled it and who care about the OSMF strategically pursuing the interests of the OSM community at large and supporting its values instead of serving goals informally negotiated within a small inner circle of the organization: Cast an empty ballot in this year’s election as a vote of non-confidence to the board as a whole. This won’t have any practical effect on the election results (and neither will any other voting decision). But it will be a clear statement visible in public.

September 24, 2026
by chris
0 comments

Communication is hard

The title of this post is making a connection to my previous post titled Group communication is hard. Like in that post i am discussing a current matter of conversation in the OSM community.

There is a discussion happening at the moment in the English speaking parts of the OSM community that is well suited as an example for two topics that have been dear to me for a long time – that is documentation of tagging practice and cross cultural communication.

How to propose

The current discussion is not directly about tagging but about the suggestion of a change to the formal procedure for tagging proposals.

Tagging proposals have existed in the OSM community for a long time. They have been slightly modified in the procedure over time but largely remain the same. And the recent suggestion is essentially another idea how to further adjust these procedures.

The OSM community has very diverging views of what tagging proposals actually mean. My own view is that they are a means for people who want to develop new tagging concepts to gather critical feedback on those ideas in a structured form, helping them to refine their ideas. The proposal vote in that understanding is merely a way for the proposer to get an idea if that endeavor was successful, i.e. if the process helped them to improve their concepts to the level that there is consensus among those who have shown an interest in the proposal to approve it. This view is shared more or less by quite a few long term OSM community members, but it is – by far – not the only interpretation. There are many in the OSM community who give the proposal process much more weight, for example

some consider approved proposals to be essentially binding in some form, like for mappers, in the sense that free form tagging is only acceptable if it does not contradict any approved tagging proposals, or for software or map style developers, in the sense that they have to interpret tags from an approved proposal in the sense they are defined in it.
some consider an approved proposal as a mandate to change tagging en bulk. It is general consensus in the community that automated bulk changes must follow the documented procedure for such (which is independent of the proposal process). But bulk changes by mappers in their area of mapping without renewed surveying are still quite common.

I don’t want to go into further details on this matter – the key for my discussion here is that there is clearly a very wide spectrum of understandings in the OSM community of what tagging proposals mean. My impression is that this has led in the discussion on the mentioned suggestion to change the procedure of the proposal process to a largely dysfunctional communication because the participants come in with divergent premises on the fundamental nature (in the sense of social meaning) of the proposal process. If you don’t resolve such differences before engaging in a discussion about the suggestion at hand in most cases you won’t have a meaningful discussion providing additional insights because you will be constantly talking past each other.

To be clear: There is no correct answer to the question what the proposal process currently means. The participants of the mentioned discussion – like the members of the world wide mapper community – have no common understanding of this. And these different views cannot be split into right and wrong views because the proposal process actually has different meanings in different parts of the community.

My main point – and i realize this is a bit tricky to communicate, because it is kind of a meta-argument on a meta-proposal – is that the same problem tends to frequently apply to tagging discussions. If you start a tagging discussion (about how tags ought to be used) without the participants having a common understanding about what the status quo is (in terms of how the tags de facto are used so far – which is often not accurately documented on the wiki) the discussion is often dysfunctional. And so is the understanding of any reason provided for an oppose in a proposal vote.

In other words: The proposal under discussion seems to be based on the premise that an oppose vote with a meaningful reason provided by the voter is objectively more helpful to the proposer than a plain oppose vote without reason and therefore it is legitimate (in an utilitarian sense) to require from people who want to have an influence on the vote outcome to provide such a reason while not requiring the same from those who approve. But since the proposer and the voters (both those who oppose and those who approve) in general do not have a common understanding of the context of the proposal any interpretation of votes beyond the pure sentiment approve/oppose likely amounts to a highly dysfunctional communication.

Bottom line: In my experience to meaningfully interpret the vote of a proposal beyond the mere statistical counting of sentiments (for which the reason provided is unnecessary) you need to have some idea of the understanding of the voter of the nature of the status quo (meaning: you would need to require more elaborate communication from both the oppose voters and the approve voters beyond a brief reason).

Conclusions

From these considerations i can also derive an advice to anyone making tagging proposals: The most meaningful reaction in a proposal vote to consider are the oppose votes that do not make sense to you. Because those are providing a hint that there might be substantial parts of the OSM community that have an understanding of the context of your proposal so fundamentally different from yours that they do not only disagree with your proposal, but they do so for reasons that you are currently unable to understand.

My conclusion for this post is – and here i am connecting again to the two topics mentioned in the beginning is that:

a shared understanding of the status quo in tagging, i.e. a common understanding on how tags are used so far, is an essential precondition of practically any meaningful nontrivial discussion on how to improve said tagging. And the OSM community currently has no meaningful platform or social mechanisms to produce and maintain such a shared understanding on a larger scale. I made a sketch on how such a system could look like some time ago, but with very little reaction.
having meaningful conversation on matters of significance for the whole OSM community (including, but not limited to, tagging questions) is harder than many think because of the diverse and diverging views people have on these matters. It is prudent to always consider that if you don’t understand the reasoning of someone else that this might be because you lack the ability to understand their perspective on the matter rather than a flawed reasoning or irrationality on their side. To check on that it often helps to take a step back and verify if you start with common premises on the topic.

September 2, 2026
by chris
2 Comments

State of the Map 2026 impressions

I have been at the State of the Map 2026 conference in Paris, France for the past few days and want to share a few impressions here. I plan to make a separate post about my talk, this is more general commentary.

Jardin des Tuileries

The OpenStreetMap Foundation

I also don’t want to write much about the OpenStreetMap Foundation here. This is partly because i am probably going to make another post about the upcoming OSMF board elections. But also because that part would have been fairly sad and that would overshadow the otherwise rather positive impression i had. The conference gave a good opportunity to observe the social interaction of the OSMF board and the rest of the inner circle of the OSMF with the other community members at the conference, which allowed me to refine my understanding of the social dynamics of the organization. Summarized in one sentence: I regard this as a huge missed opportunity for the OSMF in-crowd to engage in eye-level exchange with people from the larger OSM community they otherwise do not practically communicate with beyond the casual level. Of course, the cross section of the visitors at a SotM conference is much more narrow than the OSM community at large. But it is still massively larger and more diverse than the group of people the OSMF as an organization practically engages with in deliberation on decisions they make these days – which means a substantial unused resource of knowledge and competency.

Palais du Louvre

Social exchange

I had not been at a SotM conference since pre-COVID (and i am not counting FOSSGIS conferences here, since they are not comparable at all) so i was able to meet again quite a few people who i had not met in person for many years, but whose perspective on OpenStreetMap i value. The much higher bandwidth and additional modes of communication available in an in-person exchange are truly enjoyable in such cases and can help to a more nuanced understanding of each others ideas and thoughts.

The other part of social interaction at the conference i found particularly valuable was getting to know and engaging in communication with people i did not know beforehand – or only vaguely recall them from their online activity. I think i had an approximately 50:50 ratio in this field between people approaching me and me approaching others – which is naturally how it should be, although i only achieved that ratio probably because i presented a talk and a poster so people had a good basis to engage in a conversation with me.

For this part, however, i don’t think the in-person conversation is inherently so important. It is more that the opportunity for a casual first contact one-on-one is much more difficult to find in digital communication. That is more an issue with established communication culture and technical frameworks of communication used and not a limitation of digital communication per se.

And naturally there is the third major part of social interactions that involves developing the social relationships with people i already knew better and who i have usually seen at least occasionally in person since 2019. I have to say i kind of neglected that part a bit probably and i want to apologize to those who i have either not talked to at all or that i have only exchanged a few words with and who might have expected more. I observed (and this aligns with observations at previous SotMs) that many people at the conference spend the main part of their time in socializing with a relatively small and close social circle of theirs. While this is understandable it also misses out on the chance to widen your horizon. In many cases those you observe being strongly tied to a crowd of familiar people are actually grateful of being approached by others, especially if they are relative newcomers who struggle with the unfamiliar environment. On the negative side i distinctly noticed that there are quite a few of the OSM old-timers who seemed to be almost exclusively pursuing networking for their personal and career interests at the conference and expressing at least disinterest – if not contempt, regarding people approaching them with ideas and views outside their specific interests. Please note i distinctly make this observation not only from my own experience because i am aware that i am a controversial figure in the OSM community and if people express disinterest and contempt at my views that is not something you can necessarily extrapolate further.

Main building of the conference at Université Gustave Eiffel

The location

Having SotM in France has been long overdue – the French OSM community is one of the most active world wide and one of the best integrated in local society at large. They have made bids for hosting SotM several times in the past but never succeeded before.

It is natural for the French community to pick Paris as the place to host the conference and it is a convenient location for the international audience to travel to. The public transport system in Paris seems very well managed (in actual operation – the ticketing is another story, but i will skip that here). I was also impressed by the free public toilets and free drinking water dispensers throughout the city center – in particular in contrast to the saddening pictures German cities present in that regard.

The location, however, has been non-ideal for the purpose of maximizing accessibility for large parts of the OSM community economically. Paris is an expensive city and the conference venue was not located in an area with abundant affordable accommodations. The only hotel in walking distance to the venue was a medium priced ibis hotel and the contingent of rooms at reduced price the conference organizer negotiated with the hotel apparently was already booked out when it was publicly announced. In retrospect, my recommendation would have been to pick a cheap accommodation away from the conference venue and to commute to the conference via public transport – which is fairly affordable in Paris.

The venue itself was a very good choice, providing a lot of space, including outdoors. The only minor practical issue was that the different rooms for the talks were in separate buildings and required a walk outside, and Friday and Saturday there was occasionally heavy rain – for which many of the visitors were unprepared after a long dry summer in most of Europe.

Speaking of the Summer – because the conference took place at the end of a warm summer many of the conference rooms were fairly warm and stuffy on the first day. This became better on Saturday and Sunday as the weather substantially cooled down.

The catering at the conference was excellent, lunch was provided in the university canteen and was really good quality with two main meals (vegan and meat based), a salad bar and a broad selection of deserts.

Memorial Aux compagnons de la Libération at the conference venue

The social event

I am generally not a fan of social events so my perspective might be considered somewhat biased here up front. The French community tried to provide a special experience here and organized the evening event on Saturday in a museum (Musée des Arts et Métiers) in central Paris. The event took place in a former church that is part of the museum.

Due to the previously mentioned fact that the conference took place at the end of a warm summer it was – similar to the conference venue – somewhat warm and stuffy. But more importantly – inside a church building filled with several hundred people talking it gets really loud. At some point i was tempted to put on my ear plugs.

The rest of the museum was also open to those conference visitors who had pre-registered and paid an additional EUR 10 fee and the museum visit provided a nice time-out from the noise at the main gathering. Also the outdoor space in front of the museum was open to us, providing additional quieter space. But this was not communicated well beforehand to the conference visitors so they could not make best use of the available options.

In general, finding a suitable venue for a social event of a conference like this is hard, especially for more than 500 people like in this case. Based on my observations in this SotM and also at previous conferences i would give the following recommendations:

Good acoustic design of the rooms where the visitors gather is of very high importance. Sadly this is lacking in the vast majority of places. Humans have the unfortunate tendency to – if they have trouble understanding each other – speak louder – which is silly, of course, in places where the trouble in understanding is caused by others talking to each other. But this is a problem that can be solved through technical means by properly dampening sound propagation in the rooms.
If the climate at the conference location permits event visitors to spend time outside having space outside well accessible from the inside parts of the venue is of high value. In many cases it will not be possible to trust the event can take place fully outside, but ideally you’d then have sufficient space inside for everyone and also sufficient space outside for most of the people where it is less loud and conversations are easier, especially with a larger number of participants.
There should ideally be both enough space for most people to sit down and enough space for people to gather standing without standing in the way of others. If the place is designed for most people to sit most of the time (i.e. tables and sitting with only narrow space in between for walking) this will hamper people freely mingling while if sitting opportunities are rare it will be exhausting for people and prevent more intense and longer conversations.

Église Saint-Eustache

The talks

As in past SotM conferences i actually listened to relatively few talks live – partly because it is exhausting to switch between different topics in rapid succession, partly because the other functions of the conference, in particular talking to other visitors directly, seem much more important to me in light of the talks being also available for viewing afterwards.

None the less, here a few recommendations of talks i found interesting. Note this is grossly incomplete since i have not seen a lot of the talks so far.

Making maps with Ultra by Daniel Schep (Video, Description). In my own talk i point out the significance of traditional maps for the social cohesion of the OSM community, but i also point out that this is not meant to demonize the interactive, individualized visualization approaches. This talk gives a bit of a glimpse into what might be possible in that field and how meaningful use cases of individualized visualization can look like beyond the dabbling with mostly meaningless technical gimmicks approaches that some of the other map production talks take.
Sourdough and Layercake: removing technical barriers to using OSM data for cartography and analysis by Jake Low (Video, Description). While this talk – like practically all the other talks on map production at the conference – has a selectively technical focus and ignores many of the fundamental inner contradictions the whole client side map rendering paradigm contains, this is the first presentation i saw that is actually reflecting critically on the division of design decisions between tile schema development and style development. The sourdough part of the talk (first nine minutes) presents the idea of creating a style agnostic vector tile schema, minimizing the level to which map design decisions are already predetermined in the tiles – in a similar way to OSM-Carto currently using a style independent database schema. Now the significance of this is IMO not the practical value of such a tile schema, but that this might help people realizing the inherent limitations of the client side map rendering paradigm.
Making a living on OSM by nurturing the commons: inside the French Federation of OSM professionals by Marina Petkova and Florian Lainez (Video, Description). This talk introduces the French Association of OSM related businesses and how this has organized itself separately from the hobbyists in OpenStreetMap France. This is highly recommended to watch for anyone who is involved somewhere in the world in organizing the local OSM community as a potential role model. I recently discussed the conflicts arising from the German community having not chosen such a path and the FOSSGIS as originally an association representing professional interests taking on the mantle of representing the German OSM hobbyist community in addition. Incidentally the base membership fee in FPOSM for a single person business and the future membership fee of FOSSGIS for an individual mapper starting next year are the same (EUR 60 per year).
Here be Rainbows: LGBTQ mapping in OSM by Amanda McCann and Erica ‘spughetti’ Temp (Video, Description). Don’t let the specialized subject make you dismiss this talk. There were very few really mapping focused talks at this conference and this one i found in particular noteworthy because it discussed the problem of developing tagging that is recording social aspects (in this case: if a certain public place is welcoming or friendly to certain people) in a meaningful and critical way. Many people developing such tagging put expected usefulness of certain information over verifiability – ignoring the fact that the expected usefulness is usually an illusion without verifiability. This talk is a nice counter-example by acknowledging the difficulty.
Wonders of OSM by CapitaineMoustache (Video, Description). This is a fun talk at the end of the conference with various anecdotal examples for weird and unusual, but nice mapping around the world, celebrating the diversity of mapping in OpenStreetMap. Incidentally, this is also a great demonstration of the advantages of OSM-Carto and traditional map rendering techniques over the widely hyped ‘modern’ client side approaches. I invite everyone to follow the links from the presentation and then switch to the Shortbread and Maptiler OMT layers for comparison.

Note that this year – in contrast to most previous years – the talk videos are already available immediately after the conference. The SotM organizers have contracted a small French video production company for the videos, and they seem to have done a very good job – including automatic transcription and translation of the talks.

Square Louis-XIII

The questions after the talk

One thing that has significantly changed compared to the time i was previously at a SotM conference is the questions after the talks. In an effort to better open the conference to remote participants, questions are meant to be primarily asked digitally now. There are many visitors who struggle with that. In my eyes, the idea to better include remote participants is commendable, but the implementation is highly non-ideal. First of all – while the live streams of the conference were open to everyone, the questioning seemed to have been behind a paywall – you had to purchase an online participation ticket for access. The reasoning behind this eludes me (beyond the we use a paid platform for the questions where we pay for every visitor, so we need to limit access – which is not really a convincing reason IMO).

Be that as it may – practical handling of the Q&A differed. Some of the session hosts only allowed online questions, some first went through the online questions and allowed spontaneous questions from the room if there was time afterwards, while others alternated between in-room spoken questions and online questions.

For the presenter of a talk, answering online questions is often more difficult because the people asking are usually not aware of the previous discussion – because the questions tend to be asked already during the talk. So there is less of a conversation developing. For me, when i answer more difficult questions i tend to re-state the question in my own words before answering and maintain eye contact with the person asking to assess if i understood it correctly.

Overall i think if you have the talks in front of a live audience it makes sense to also accept questions directly asked by the live audience. The remote participation is not really helped by not doing so and the live audience is more likely to evade the constraint by approaching the speaker after the talk in person – which is much more damaging to the inclusion of remote participants.

I have previously presented how i would imagine talks at a mixed in-person/remote conference to be organized and i have refined that concept based on the experience at this SotM. I might discuss that in a separate blog post.

Hôtel de Sully garden

On SotM organization

One notable thing happening at this year’s SotM was bidding farewell to Christine as head of the SotM organizing committee of the OSMF. I discussed the significance of achieving generational turnover in projects of the OSM community in the past. The OSMF has so far been notoriously bad at this and this might be the first really positive example of managing a generational turnover in the OSMF.

In the European OSM communities we tend to have a strong aversion against the discussion of what the Americans casually call leadership. We tend to equate leadership with authoritarian leadership and hierarchy – and we often are critical of both. I think Christine’s involvement in the SotM organizing committee demonstrates many of the aspects of leadership important in a fundamentally egalitarian community like OpenStreetMap – like providing guidance and advice, encouraging and putting trust in people and moderating conflicts, cooperating with rather than managing people – aspects which we tend to ignore if we equate leadership with people exercising power over other people.

And these in return are supportive of a successful generational turnover – so the SotM organizing committee is in a fairly good position of accomplishing that.

I am reluctant to declare that the SotM organizing committee has already demonstrated a successful generational turnover though, because that is not tied to a single person, but to the group overall.

Pont Notre-Dame

Exclusivity and Inclusivity at SotM

In previous discussions of State of the Map i critically commented on the exclusivity of these events and the fact that – despite the claims from the OSMF that these are meetings of the global OSM community they are not. There are traditionally mostly three groups of people present at the SotM conference:

People professionally involved with OSM or OSM data in some form
The wealthy global OSM jet set
Members of the local community from near the place where the conference takes place

This was the same back in previous SotMs i visited as well as this year. The main differences i observed were that

The intercontinental presence seemed substantially shifted and reduced – both on the professional and the jet set sector. There were quite a few people present from Africa and South East Asia but very few from South America and Japan. This might be related to the local conferences (SotM Asia, SotM LatAm) taking place – which might be more popular than the OSMF SotM meanwhile. The presence of big US tech companies was substantially reduced.
There seems to be an increase of non-commercial professional visitors (students, people working for government institutions or NGOs).

I don’t really have a solid basis to assess if the number of pure hobby mappers at the conference relative to the other participants has increased or not.

What remains the same is that the State of the Map is clearly inaccessible for in person visits for the vast majority of the OSM community. And no scholarship program is going to really change that in substance. Attempts are made to allow remote participation and this way reduce the barrier – which is commendable. Still anyone reflecting on the State of the Map conference should always keep in mind that the people present there are not in any way representative for the OSM community at large.

Colonne de Juillet

August 24, 2026
by chris
0 comments

State of the Map talk and poster

Next weekend is going to be the State of the Map 2026 conference in Paris and i am going to present a talk and a poster there.

Do maps have a future in OpenStreetMap?

The talk is going to be about if maps have a future in OpenStreetMap. If you think that question is silly, first consider what exactly you have in mind when you think about the term map.

The talk is going to look at the social history of maps as a means of communication and the central role maps play as a communication platform in OpenStreetMap. I am going to discuss how maps that are able to serve that function are in decline in OpenStreetMap and what that means for the OSM community and its future.

I am going to make the slides of the talk available afterwards.

Update: Slides of the talk are now available here, video here.

Taking OpenStreetMap map design to the next level

The poster is featuring two samples from my experimental OSM-Carto alternative colors map style from Paris, demonstrating various map design innovations from that style in an urban context. The poster is already available on the State of the Map website – as is the interactive guide i offer with it. That guide is meant to be used on a mobile device together with the printed poster, but you can also browse it separately or with the poster on screen in a PDF viewer.

The urban context of Paris, of course, only demonstrates a subset of the OSM-Carto alternative colors features – my focus is traditionally more on map design for rural environments. For a more comprehensive selection of rendering samples see the style sample gallery.

In the text on the poster i try, in particular, to highlight how much the OSM community is squandering its potential by not investing substantially in innovation and excellence in map design – as i have previously discussed in blog posts in the past (like here, here, here, here and here).

August 6, 2026
by chris
1 Comment

OpenStreetMap, business interests and capitalism

Another interesting recent topic of discussion in the OSM community has been on corporate influence on the project.

The concern about corporate influence on OpenStreetMap is fairly old. For some time there had been substantial concern about a direct takeover of the OpenStreetMap Foundation by large US tech corporations. I had commented on this in the past.

But i realize that the focus of that discussion had been somewhat one sided, looking mostly at the influence of individual business interests. I would like to illustrate that with two quotes from the current discussion.

adreamy writes:

I don’t believe OSM’s identity has ever been about being anti-business or anti-capitalist. Rather, I believed it was about remaining independent of any single commercial interest, and about building a project where individuals could participate on equal footing in a genuinely open community.

Simon Poole writes:

It used to be that a majority of board members worked in companies in the geo data business, it used to be that major tagging schemes were supported and proposed by corporate entities, it used to be that people were employed to do marketing for OSM by outside companies, it used to be that major bits of “core” OSM software was written and maintained by employees of companies interested in OSM.

The last has been replaced by the OSMF employing staff and naturally this could give donors some leverage, particularly if the donations are earmarked, but it is less influence than if they were employees of third parties that could move them to different projects at a drop of the hat.

I agree with adreamy about the first part, but i would put into the question the duality he seems to present – that business interests collectively are a non-issue while the dominance of large individual business interests are.

OpenStreetMap started out as a non-capitalist endeavor in a capitalist world. Meaning it is not anti-capitalist, but it has positioned itself outside the domain that capitalism and anti-capitalism are concerned with. You can compare it to how people manage their family life – which is equally outside the world of capitalism for most. As OpenStreetMap grows the pressure to integrate into the capitalist logic of society grows, which creates conflicts where social mechanisms traditionally strong in OSM, based on intrinsic motivation of its contributors, clash with economic mechanisms and extrinsic motivation through money. In the sector of mapping this remains a limited issue, but in other sectors (organizational, technical and creative work) we see a long term trend of replacing intrinsically motivated volunteer work with extrinsically motivated paid work.

Simon Poole accurately described that the direct influence of business interests on OpenStreetMap had been stronger in the past. But it had been fairly separate from the intrinsically motivated volunteer community. This is what made this influence being widely perceived as a threat.

But what Simon also hints at is that while the direct, confrontational attempts at influencing the project from individual business interests have diminished, capitalism is increasingly entering into the core of the intrinsically motivated volunteer community. There is not much active resistance to this since OpenStreetMap – as pointed out – is not anti-capitalist. But it changes OpenStreetMap on a very fundamental level. I have written about some of the mechanisms of this in the past.

The real question – and i am not going to write about this in detail here, just point out the issue – is if OpenStreetMap is viable in the long term as capitalist project (meaning it does not only exist within a capitalist world, but embraces capitalism to define social interactions within the project) and would an OpenStreetMap along these lines be any different from other crowd sourced data collection projects?

I hinted at one important aspect of this problem back when i critically commented on the OSMF diversity statement, pointing out it actively ignores the discrimination inherent to capitalism.

July 29, 2026
by chris
5 Comments

Group communication is hard

There is an interesting discussion going on in the OSMF run discourse instance on community.osm.org regarding regulation of use of LLMs in communcation there.

First a bit of background

The OSMF in 2021 introduced a new behavior control framework for the forum and some mailing lists – which i criticized for its vagueness (and resulting subjectivity in implementation – giving space to cultural bias) and its intolerance towards behavior diversity, both culturally and as a result of neurodiversity.

Later in 2025 the OSMF introduced an AI policy supplement to those behavior rules which essentially extents the vagueness of the original framework to the field of use of LLMs.

These policy documents and their practical application reflect the idea of behavior control as a system of authority where the decision on what behavior is considered acceptable is determined centrally by a group of people (the moderators) and the users of the channels need to trust that these perform their work in a well meaning and competent way (which in my eyes is mostly the case) and universally avoid their cultural and personal predisposition creating an unfair bias in how they judge different styles of communication.

Within the context of the discourse forum the idea to trust the integrity and objectivity of the moderators also stands in conflict with the technocratic paradigm of the underlying software, which is based on a strong faith in technology and firmly delegates all kinds of social functions to technical automatisms. This manifests most clearly in communication participants being structured in an social hierarchy defined through some intransparent scoring. This practically also means communication is sometimes hidden from users without this being transparently communicated to either the moderators or users.

This technocratic management is partly defined by the developers of the software the OSMF uses, partly by the self appointed technical management of the forum – which works completely separately from the official moderation.

Many of these things i have individually criticized in the past already, but i thought it is important for the matter at hand to summarize them together.

On the matter of technically generated communication

I won’t bore you with yet another of those my personal view on AI use comments you can find endlessly around the internet. If you are interested in some perspective on this from me i can point you to what i wrote about this in the context of mapping many years ago – which essentially still applies today.

What i want to comment on here is that the whole issue with using LLMs in discussion is a problem to a large extent resulting from the focus on the two described methods of regulating group communication – the moderator authority you need to trust and the technocratic management based on faith in technological management of social relations on a collective level. The combined application of these two principles has deprived people on the forum of both the technical ability and the practical experience with managing their social interactions on that platform themselves.

I probably need to explain this a bit further. Back in the days of Usenet one of the most significant and defining elements for the social interaction in these groups was the feature of having a so called killfile in practically all NNTP readers used by serious participants in those groups.

A killfile represents the ability of the individual communication participant to specify criteria for communication they want to not read, most commonly communication from certain participants. See the Jargon File for details. While this feature was rarely really used the fact that it was readily available to nearly everyone participating in those group communications on Usenet had a substantial effect on the communication culture. I will go out on a limb here and claim that if Usenet still was widely used these days use of LLMs in Usenet communication by human participants (in contrast to LLM generated spam – which is a completely different matter) would not be a problem.

Bottom line: I think the whole problem of LLM use in communication on the OSMF forum in the form discussed under the link on top is the result of the ill-advised attempt to collectively manage group communication of the participants (telling people what of the communication to read and how to read it, what to write and how to write it) instead of giving them the ability and the freedom to manage that for themselves individually.

June 28, 2026
by chris
1 Comment

Mapping of populated places in OpenStreetMap

Populated places are probably among elements of human geography those you can most widely find represented in maps in general. I here want to discuss a bit the somewhat peculiar situation of their mapping in OpenStreetMap.

Populated places on small scale map – Carte de l’Afrique à l’echelle de 1/5M, 1929

Populated places on larger scale map – Survey of India 1:126k Sheet 72C/SW, 1937

First: What is a populated place? Humans throughout history, when developing a non-nomadic lifestyle, have had the tendency to settle in a highly non-uniform pattern across the land they live on. They tend to settle in local concentrations colloquially called settlements. In the context of geographic data and cartography the term populated place is usually used more often, which is not exactly a synonym for settlement, but closely related, i am going to explain that relationship in the following.

Settlements in general should not be understood to be strictly discrete. The non-uniform patterns of human settlement are dynamic and change over time by new settlements forming, existing ones being abandoned, settlements merging etc. What can be said almost universally is that settlements develop some form of identity and get identified with names. And these identities and names – in contrast to those of unpopulated places – even detach themselves from the physical structures the settlement manifests in. For example a place under environmental pressure (changing water levels of a waterbody close-by, moving sand dunes etc.) might change its location while retaining its identity. In more recent history we even have settlements that get explicitly and deliberately moved as a whole, for example when a reservoir or an open pit mine are built.

So – to get back to the original question: A populated place is essentially that non-physical identity of a human settlement, detached from the physical structure (like the sum of all the buildings in that settlement) or the legal delineation, representing the collective understanding of the people living in and around that settlement about its identity.

In OpenStreetMap populated places are classified in a hierarchy according to their number of inhabitants. I discussed this already in the past. These classes are somewhat loosely defined individually, but very broad consensus exists about the hierarchy itself.

Nodes and Polygons

Populated places are mapped mostly with nodes but there is some not insignificant use of polygons for mapping populated places as well. This is the source of frequent discussions in the OSM community, and i want to analyze this in a bit more detail here.

First the plain numbers:

place	`city`	`town`	`village`	`hamlet`	`isolated_dwelling`
count	15k	118k	1.8M	2.1M	858k
polygons	23%	12%	7%	6%	2%

The mapping of larger settlement classes (city, town) has reached a level of near-completeness in many parts of the world, their numbers do not increase substantially any more. The smaller ones, however, continue to grow in numbers as mapping gets more detailed.

Reasons for mapping with nodes instead of polygons are:

It is clearly the most common approach used by mappers in OpenStreetMap.
It is most widely supported by data users.
It is the easiest to map if you just want to add a place that is unmapped so far.
Most standalone populated places have a verifiable location in the form of a functional center (where you can place a node in a verifiable fashion), but most populated places do not have a verifiable perimeter.
Even if there is a verifiable perimeter, mapping that with a polygon as a representation of the populated place fails to record information on the functional center.

The fourth point probably requires a bit more explanation since the concept of verifiability in OpenStreetMap is typically only discussed w.r.t. tagging but rarely w.r.t. geometries. Concretely, my statement means that if you’d do an experiment and ask a thousand people familiar with a place to specify its location on a map the locations selected by these thousand people will usually converge to a single position, which you can see as the verifiable location of the place. If you’d ask the same people to draw the outline of the populated place the different drawings will usually not converge to a single perimeter, but will reflect fundamentally different ideas of what is part of the populated place and what is not.

Reasons for mapping with polygons instead of nodes are:

Polygon superiority beliefs – there is a widespread belief in the OSM community that mapping things with a polygon is inherently better than mapping them with a node – either in general or just specifically for populated places.
The concept of a populated place as an identity detached from the physical or legal structures of the settlement can be difficult to deal with so people have a tendency to conflate it with other concepts easier to grasp – like the builtup area of the populated place or an administrative division the place is (fully or predominantly) part of. These concepts often seem more tangible and therefore mappers are more confident in mapping them. Also there is substantial influence of Wikipedia/Wikidata, which does not make the distinction between the different concepts of a human settlement and therefore substantially pushes towards such conflations.
There are some (rare) cases where a populated place lacks any kind of functional center but has a clear perimeter.
Concrete use cases where you want the information about a populated place together with a polygon representation of it.

All of these considerations are overshadowed by one of the core rules of OpenStreetMap – One feature, one OSM element. This rule is largely agreed on by mappers mapping populated places with nodes and mappers mapping them with polygons alike.

But, of course, those mappers who conflate the concepts of populated places and administrative division or builtup areas are going to have a different view of what one feature is than those mappers who separate these.

All of these factors together have led to the following practical approaches to mapping populated places:

Node with place=city/town/village/hamlet/isolated_dwelling, mapping of builtup areas and administrative boundaries completely independent of that. This is the clearly dominant form of mapping.
Polygon with place=city/town/village/hamlet/isolated_dwelling representing an aggregate of builtup areas considered by the mapper to belong to the populated place, double tagged place=* and landuse=residential (or sometimes landuse=farmyard for place=isolated_dwelling).
Polygon with place=city/town/village/hamlet/isolated_dwelling forming an abstract hull around the buildings that the mapper considers to belong to the populated place but not representing a verifiably builtup area, usually double tagged place=* and landuse=residential.
Polygon with place=city/town/village/hamlet/isolated_dwelling representing the boundary of an administrative unit the place is conflated with, double tagged place=* and boundary=administrative.
Polygon in the form of a boundary relation with place=city/town/village/hamlet/isolated_dwelling representing the boundary of an administrative unit the place is conflated with, double tagged place=* and boundary=administrative and with a node as additional member of the relation with the role=label or role=admin_centre placed at the functional center of the populated place. Note this approach is indiscernible from the use of boundary relation members with role=label for hand placing labels of administrative units – as it is supported by some maps – and use of members with role=admin_centre for the feature from which the place or parts of it is administered, which is not necessarily at the functional centre of the place.

Rare case of three different representations all tagged with place=village: Place node, aggregate of builtup areas and administrative unit

These different approaches vary quite substantially in how common they are between the different place types:

place	`city`	`town`	`village`	`hamlet`	`isolated_dwelling`
way+boundary	22%	5%	1.5%	1.9%	0%
rel+boundary	90%	77%	60%	71%	43%
way+landuse	0%	35%	41%	42%	32%
rel+landuse	0%	2.7%	9.5%	8.5%	5.7%

Further discussion i will do in the form of questions and answers:

What variants of mapping would you recommend to data users to support and mappers to use in mapping?

At the moment quite clearly the node with place=city/town/village/hamlet/isolated_dwelling – and only that. This is most broadly used by mappers and data users alike and limiting interpretation to those will save you from a lot of nasty problems and would support mappers in a consistent practice.

Do i need to expect any problems if i interpret node and polygon mapping alike (assuming that the differences in meaning of the different polygon mapping variants do not bother me)?

Yes. Although there is consensus that double mapping is not correct, there are still plenty of places, in particular of the higher levels like place=city, that are mapped both with a node and a polygon. As a result most data users that interpret both perform some form of de-duplication and, as a result of that, the duplicates often remain in the database for a long time, sometimes even permanently as a compromise in editing disputes.

Wouldn’t it make sense to have a concerted effort in OSM to move mapping universally to nodes since that is clearly the dominant form of mapping already?

It is unlikely that such an endeavor would be successful in the long term because removing the polygon mappings from the database would not remove the reasons why mappers use polygons to map populated places.

How about unifying to polygon mapping?

Not unless you want to add millions of completely made up polygons to the OSM database. Not to mention that – as explained – there are multiple conflicting variants of polygon mapping.

Wouldn’t the best solution be to unify the different variants of polygon mapping to the last (with the boundary relation and a role=label/admin_centre member)?

That is the technical solution to a social problem approach.

A relation would indeed be a way to allow mappers to

abide by the one feature, one OSM element paradigm independent of their mental concept of a populated place.
specify a single location as geometry, or a perimeter, or both.

and it would allow data users also to easily obtain and interpret the information they need.

But there are also a number of problems with that idea. The existing boundary relations are not suitable for this approach because:

They are established only for boundary mapping, mapping landuse polygons with boundary relations or adding role=label/role=admin_centre members to multipolygon relations representing builtup areas has no broad support.
Boundary relation members with role=label are already widely used for non-verifiable manual label placement, hence overloading that with an additional use would dilute data quality and be prone to disagreements among mappers about what is the right use. Boundary relations members with role=admin_centre are also widely used in a different meaning.
There is poor support for editing relations in editors and accordingly quite widespread aversion among mappers to using them in mapping.

The idea of creating a new relation type and creating a dedicated and well usable interface for it in editors would be hampered by the following:

A lot of influential developers in the OSM community are strictly opposed to the introduction of any new relation types that cannot be mapped 1:1 to simple features – which would apply to any relations where interpretation of roles is essential.
Even with consensus support from mappers getting all tools and data users to support a new relation type is a lot of work.

Note, however, one feature, one OSM element works both ways. Those mappers who distinguish between the abstract concept of the populated place, the builtup area and the administrative units (and those seem to be in the majority) will often not be comfortable with mapping these together in a single relation. It might also create semantic conflicts, for example if the administrative unit and the populated place have different names.

Wouldn’t it be prudent to use different taggings for the different forms of mapping listed above?

Yes, that would make the semantics much clearer and would make data interpretation easier. But it would not solve the problem that mappers who conflate the concept of populated places with either administrative units or builtup areas will be opposed to mapping a place node and polygons representing administrative divisions or builtup area separately. Also the widespread support of place=* on both nodes and polygons among data users will make mappers reluctant to stop using that tag for any of the approaches listed.

Conclusions

As you can see the situation is quite severely stuck. And the reasons that motivate people to follow the minority approach of mapping populated places with polygons are not all so fringy that they can simply be dismissed.

I discussed a number of potential approaches to untangle the situation above already. Overall these can be classified into

Attempting to put pressure on mappers to change their mapping practice at large. As indicated this is unlikely to work, but that does not mean we are not going to see attempts in that direction.
Attempting to create and push through a technical solution.
Improving education of mappers about the different concepts involved in the mapping of settlements (populated places, legal and administrative delineations, builtup area classifications) and widening meaningful discourse on mapping of these so the mapper community is better able to make informed decisions on how they want to further develop mapping of these in OpenStreetMap.

I hope this post serves as a small contribution to the last point.

June 23, 2026
by chris
1 Comment

FOSSGIS Membership Dues – The End of the Story

English version based on an automatic translation with Deepl.

My (almost certainly) final post on the issue of FOSSGIS membership dues.

As expected, yesterday’s virtual general meeting of the association approved the increase in dues. The only change adopted compared to the board’s proposal regarding individual memberships is that the reduced fee is no longer intended for members who are not employed, but rather for members whose financial situation requires a reduced membership fee. The specific wording is:

The member decides on their own responsibility whether their financial situation requires a reduced membership fee. To do so, an informal notification to the board is sufficient.

The on their own responsibility part – which I had discussed – was already the case until now, but previously one had to claim to not receive a work income in order to qualify for the reduced membership fee. Now, one must claim that their own financial situation requires it.

As far as I know, FOSSGIS is thus the only local chapter of the OSMF that makes the membership fee dependent on financial need. Whether that’s a good idea is certainly open to debate.

Although there were certainly some expressions of support for the proposals I made, ultimately there was no substantial interest among the members present to actually turn them into a resolution or to vote against the increase. The vote on the membership fee regulations that were adopted ended with 52 votes in favor, 3 against, and 7 abstentions.

I had already outlined my assessment in the first discussion of the OSMF membership dues saga that FOSSGIS is at a decisive point in its development. And I had underscored this once again in another comment by pointing out the path dependence. I believe this decision on the direction to take has now been made, even though it has essentially been looming since at least 2020.

I think the overall concern with this direction is very clearly illustrated by how volunteer work is viewed from within the club. The central argument for raising membership dues continues to be that there is a perceived lack of willingness to volunteer, and therefore the belief that the club’s goals can only be pursued sustainably through paid work. At the same time, however, the idea of structuring membership fees in a way that demonstrates appreciation for precisely this kind of volunteer work- as I proposed in my draft – is rejected. This is essentially textbook path dependence. This is particularly noteworthy when one considers how much volunteer work is done in the OSM community as a whole – completely separate and independent of FOSSGIS and other organizations – which clearly shows that there is no general lack of willingness to volunteer within the OSM community.

In any case, the association has set the course, and we have to deal with it. For my part, I have decided to let my FOSSGIS membership expire at the end of the year. However, I want to emphasize that this is my personal decision and does not constitute a recommendation to others. Everyone must decide for themselves. I can completely understand if others see FOSSGIS as a useful platform for pursuing their interests. And as I explained in my response to Frederik’s comment on the first post in this series, I can also understand if FOSSGIS, as an organization, deems it necessary for its members to submit to the organization’s collective decisions and rules. For me, this simply doesn’t fit with the image I have of OpenStreetMap as an open social project in which I volunteer.

When I first outlined my idea for a significantly different approach to membership dues in April, it was clear to me that – in the unlikely event that FOSSGIS were to actually implement something like this – I would be compelled to become a supporting member, because anything else would have been rather hypocritical. Interestingly, in the discussion about this aspect of my proposal, the central argument – which no one but me seriously contested – was that members would not voluntarily pay more than necessary, and that pressure, or at least a nudge, is necessary to get them to make higher financial contributions. This view, of course, fits well with FOSSGIS’s role as an advocate for its members’ interests, where everyone is ultimately concerned first and foremost with their own individual interests. The idea that FOSSGIS could also develop a different self-concept – one in which people come together and organize not primarily on the basis of shared interests, but on the basis of shared ideals and values, and where members are free to decide whether to support these ideals and values through volunteer work or financial contributions – this idea did not seem to be on anyone’s radar among those present.

And despite all the criticism I repeatedly voice about the OSMF – when it comes to the structure of membership dues, the OSMF presents itself quite differently to its (current and potential future) members.

Incidentally, it has also become clear to me that in OpenStreetMap, we are by no means required to become members of the local chapter that is, so to speak, geographically responsible for us. Like FOSSGIS, most OSMF local chapters do not require that you come from or live within the local chapter’s geographical area of responsibility. So we are all free to become members wherever we feel the organization is the best fit for us.

June 18, 2026
by chris
0 comments

FOSSGIS membership fees – Update #3

English version based on an automatic translation with deepl.

Another update on the topic of FOSSGIS membership dues – see my previous posts on this topic here, here, and here.

The virtual general meeting at which FOSSGIS is going to decide on future membership dues is – as previously reported – scheduled for next Monday. Anyone who is a FOSSGIS member should have received an invitation and login information for the meeting.

I have turned my informally outlined proposal into a draft resolution and would like to document it here transparently for all who are not FOSSGIS members as well.

The structure and the sections on payment deadlines and membership fees for legal entities are based on the board’s draft, which largely corresponds to what was already discussed in March (so the internal discussion within the association has not yet led to any substantial changes). I have merely modified a few details and, of course, adjusted the individual membership rules in accordance with my proposal from April. In doing so, I have expanded the idea of reduced membership for active OSM contributors to include anyone who volunteers to a significant extent toward the FOSSGIS association’s goals. This therefore includes not only active OSM contributors but also anyone working unpaid in the FOSS sector.

Here the draft resolution (note again: This is a machine translation with no claim of accuracy):

The General Assembly is requested to adopt the following membership fee regulations in accordance with §5 of the Bylaws:

Payment Due Date

Membership fees are always charged for a full calendar year, regardless of when a member joins or leaves the association. For members joining in December, no fees are due for the year of joining.

Membership fees are due in advance upon receipt of an invoice from the association. Invoices are issued after the start of the year for which the membership fee is charged. For new members, the invoice for the first year of membership is issued within six months of joining.

Membership Fees for Individuals

There are three different membership fee rates for individuals:

the standard rate of 30 EUR per year.
the reduced rate of 10 EUR per year.
the supporting member rate of 90 EUR per year.

The reduced membership fee applies to members who perform a significant amount of volunteer work in support of the association’s goals. The reference period for this is the calendar year preceding the year for which the membership fee is due. The Board of Directors determines eligibility based on information provided by the member regarding their volunteer activities. For volunteers active in OpenStreetMap, the benchmark for a significant amount of volunteer work is defined as documented mapping work on 42 days of the reference year. For members who volunteer in other ways to further the association’s goals, the scope of volunteer work required for classification under the reduced rate should be at a comparable level.

The supporting membership rate applies to members who voluntarily opt for supporting membership. The decision to opt for a supporting membership must be indicated on the membership application and can only be changed in advance for the following calendar year. Supporting membership is recommended for all members who, as part of their professional work, routinely and to a significant extent deal with the development or use of free GIS software or with the use of open geodata, or who are engaged in business activities in these areas.

For all other individuals, the standard rate applies.

Contributions for Legal Entities

For legal entities, the contribution amount generally depends on the number of employees, converted to full-time equivalents (FTEs). The contribution tier is then determined by the number of FTEs:

Tier J1: up to 5 FTEs: 500 EUR
Tier J2: up to 15 FTEs: 1,200 EUR
Tier J3: up to 30 FTEs: 3,000 EUR
Tier J4: more than 30 FTEs: 5,000 EUR

Changes in the number of employees that affect the contribution tier must be reported to the association immediately. Starting the following year, the contribution will be calculated according to the new tier.

For FTE purposes, all employees in a dependent employment relationship who are subject to supervision are counted; however, freelancers are not included.

Non-profit institutions (such as public-law entities, non-profit companies, or associations) are classified two tiers lower than their actual number of employees.

Legal entities may request reclassification into a different contribution tier if classification based on FTE would result in undue hardship for them – for example, because they have a very large number of employees, most of whom do not work in the GIS field or with open geodata, or because, as an international company, they are also members of other local chapters of OSGeo or OSMF. It is also possible to voluntarily opt for a higher classification, for example, in the case of high-revenue companies with a small number of employees. A request for reclassification must be submitted to the Board of Directors, stating the reasons, and the Board will decide on the reclassification. The decision of the Board of Directors may be appealed to the General Assembly.

Transparency and Recognition

The Board of Directors regularly publishes a list of the legal entities that are members of the association, including their membership tier.

A list of Supporting Members is also published regularly, provided they wish to have their Supporting Membership publicly recognized.

And here the reasoning i provided to the members:

This proposal is a further elaboration of the concept presented at https://imagico.de/blog/de/die-saga-der-fossgis-mitgliedsbeitraege/. Detailed explanations and justifications can be found there. This proposal places membership dues in the mid-range of dues charged by local chapters of the OSMF, whereas the Board’s proposal would position FOSSGIS above all OSMF local chapters in terms of the dues amount for active OSMers and at a multiple of the average dues amount charged by local chapters in Western industrialized nations (less than EUR 20). In addition, this proposal explicitly recognizes volunteer commitment to FOSSGIS’s goals as well as voluntary financial support, without linking a member’s right to have a say in the association to their willingness or ability to provide financial support.

If members follow the recommendations for supporting membership, this proposal would likely be at least cost-neutral compared to the Board’s proposal with regard to individual dues.

The provisions regarding the payment due date and legal entities are largely based on the Board’s proposal, but have been slightly modified, expanded, and clarified in some respects, and include specific numerical values from the motion presented at the previous General Assembly.

Note: Not every company is a legal entity; therefore, provisions regarding legal entities do not apply to all companies, but only to certain legal forms. In this case, it would make sense to amend the bylaws (replacing membership with voting rights for legal entities with a corporate/institutional membership without voting rights, which is independent of the legal form). However, that is a separate issue.

Pipeline rendering consistent across tile edges

June 6, 2026
by chris
1 Comment

Holding the line – non-locality in map rendering part 2

I had written about non-locality in tiled rule based map rendering in general some time ago and that post gathered quite a bit of interest – including renewed interest in OSM-Carto development for problems where non-locality is a long known issue. Here i want to continue more in depth on a specific aspect of this.

The difficulty of aggregation

The specific issue this post is about is the aggregation or merging of geometries in map rendering. As i mentioned in the previous post in the section on explicit non-localities in map design:

Since geometries in OpenStreetMap are frequently split in a relatively fine grained fashion to differentiate attributes locally, it is often a problem to render the individual components separately, because it disrupts the rendering. For example, when a road is rendered based on relatively short segments in mapping, dashing patterns and labeling are going to be affected by this. So it might seem a good idea to simply merge all road elements within a tile that are going to be rendered in a common styling. This will, however, lead to different geometries in different tiles and therefore dashing and labeling will be discontinuous across tile edges if you do that – unless you take further measures to avoid that.

To make the problem more clear here the situation in a simple form:

The problem of aggregating geometries across tile boundaries in the most simple form

You have a line split into three ways here extending across several tiles. To achieve the desired rendering results you want these splits to be dissolved before rendering and you want to show these three ways as a continuous line. The way you’d do that in tiled rendering is to gather all the ways intersecting the bounds of the tile and aggregate them with ST_LineMerge(). The problem is that if you’d do so on the tile highlighted in gray you would merge way 1 and way 2. When rendering the other tile to the left, however, you would merge way 2 and way 3. Bottom line – rendering the two tiles would be based on different geometries and therefore in many cases (like when you use line patterns or when you place labels on the lines) the results would be inconsistent across the tile boundary. And the rendering buffer routinely used in tiled rendering does not really help with that in general.

There are a number of obvious approaches you could think of to avoid this kind of problem while still merging geometries:

exclude any ways from merging that are not fully within the tile boundaries. That would often exclude quite a lot of ways so the aim of dissolving splits would be only partially accomplished that way. And any non-localities in rendering of these elements that require a rendering buffer to be handled correctly would lead to problems.
when the resulting geometries are exclusively for labeling: Avoid any labels crossing the tile boundaries. This avoids any hard inconsistencies in the form of cut off labels, but it massively interfers with label placement in general and will still indirectly affect other blocking elements.
clip the merged geometries at the tile boundaries. That would formally avoid inconsistencies at the tile boundaries, but it would introduce new artifical splits that are not in the source data. This is often highly undesirable.
recursively include additional geometries outside the tile connected to those you want to merge. This is practically expensive to do in all cases and often is not feasible at all when it might lead to merging of thousands of ways across hundreds of tiles until the connectivity ends.

As you can see none of the obvious approaches that come to mind how to handle the issue are really an overall solution that will work in most cases. So we have to look for a different approach.

Aggregating in a tile independent fashion

As already indicated the ultimate source of the inconsistency between rendering results in different neighboring tiles is that the rendering is based on different merged geometries. You merge ways within the area of the tile and that set of ways merged is not the same for different tiles and hence the merged geometries are different as well. So what you need to do is to aggregate in sets that are identical between neighboring tiles. You could, for example, aggregate based on administrative units of a certain level. Practically such an approach of aggregation using spatial units derived from geographic data is usually not going to be viable, especially not on a global map. A more suitable approach is to use abstract geometric units, specifically of the size and shape of the metatiles being rendered.

Here is how this practically looks like:

The concept of aggregating based on a global grid of aggregation sectors

In the center in gray color is the tile we are going to render and in dark pink around the rendering buffer for that tile. In blue you can see the grid of aggregation sectors, one of them further highlighted with a light blue fill. The key here is that the aggregation sectors form a space filling pattern that is the same no matter from which tile you look at it. What you now need to do is assign each and every one of the ways you would like to merge non-ambiguously to one of the sectors. Easiest way to do that is to determine the sector in which the center of the bounding box of the way is located in and to assign the way to that sector. This is shown in pink. Now all you need to do is to aggregate the ways per sector. The resulting geometries will then be identical between neighboring tiles since the aggregation sectors are identical.

The reason why the sector grid is offset by half a metatile size relative to the rendering grid is to minimize the number of sectors that need to be processed per tile to four. If the sector grid was identical to the tile grid you would have to process nine sectors to accurately cover the rendering extent with the buffer.

There is one important caveat here: We also need to exclude any very large geometries from aggregation. Any geometry that would be assigned to a sector other than the four ones meeting in the tile center and that extends into the rendering area of the tile would need to stay out of the aggregation in all tiles. The correct size limit would be the grid sector size (which here is the same as the metatile size) minus the buffer size (or whatever inherent non-locality that specific feature type is subject to – if that is less).

The main limitation that comes with this approach is that there are obviously residual unmerged splits. You can reduce those by enlarging the aggregation sector size. If you do that the aggregation grid no more looks identical from every metatile rendered, therefore some metatiles need to be handled differently than others, which complicates things. And the computational overhead increases.

Can this also be done in preprocessing

The next question obviously is if this procedure could also be done in pre-processing rather than at render time. Since we aggregate in sectors that are shared between four metatiles each and the aggregation is repeated for each of those, there is quite some inefficiency in doing this on the fly.

The answer is yes, you can do this. But especially if you want to do this with regular (like minutely) updates it gets quite a bit more complicated. And the criteria for a preprocessed solution are quite a bit different so the sketched approach is not necessarily the best for that. I will not discuss preprocessing strategies in more detail here, i just wanted to mention the principal possibility.

Practical application

I don’t want to demonstrate a labeling application here since that inevitably involves other non-locality problems due to blocking. Instead i want to follow-up on a design project i presented some time ago where i used geometry aggregation but did not really discuss the non-locality issues resulting from that. This example is the rendering of pipelines.

This project was demonstrating context adjusted dashing patterns and how they can be used to improve the rendering of pipelines with a line signature showing flanges. As i implemented it back then this showed rendering inconsistencies at tile edges due to the basic use of ST_LineMerge() on a tile basis.

The graphical samples shown here use single tile rendering with a buffer size of 64 pixel. This highlights problems at tile edges. In practical rendering most commonly 8×8 metatiles with at least 128 pixel buffer are used so tile edge issues less common in production maps.

Previous rendering with inconsistencies at tile edges

Since this specific project involved both merging ans splitting the pipeline ways an alternative solution here would be to just universally split all pipelines at the metatile edges in addition to the splits performed for design reasons. How this looks like you can see here

With additional splits at the tile edges to hide the inconsistencies

The sector based solution i discussed above can likewise be used to address this problem though:

With the sector based merging ensuring true continuity across tile edges

This second solution is the more sophisticated one and can be considered better in the results as well since it does not introduce any arbitrary splits not justified by the data.

The implementation relies on a modification of Mapnik that makes the unbuffered bounding box available on the query level.

Conclusion

I tried to demonstrate here in more detail a specific practical non-locality problem in map design that designers frequently are confronted with and which i only mentioned in passing in my more general discussion of the subject in January. I am not aware of the solution i present here being discussed in the context of map rendering elsewhere before, but it is not unlikely that others have used the same approach before independent of me. I hope the discussion here helps others better understand the problem of geometry aggregation in tiled map rendering and how this can be dealt with and maybe even find more efficient solutions for variations of this problem. Pointers to such work are very welcome.