Imagico.de

blog

State of the Map 2026 in Paris

September 2, 2026
by chris
0 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

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

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

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

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

É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

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

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

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

Colonne de Juillet

State of the Map talk and poster

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).

Taking OpenStreetMap map design to the next level - SotM 2026 poster

OpenStreetMap, business interests and capitalism

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.

Mapping of populated places in OpenStreetMap

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 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

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:

  1. It is clearly the most common approach used by mappers in OpenStreetMap.
  2. It is most widely supported by data users.
  3. It is the easiest to map if you just want to add a place that is unmapped so far.
  4. 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.
  5. 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:

  1. 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.
  2. 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.
  3. There are some (rare) cases where a populated place lacks any kind of functional center but has a clear perimeter.
  4. 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

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

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

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

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

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

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.

Putting animals on the map

May 24, 2026
by chris
1 Comment

Putting animals on the map

OpenStreetMap aims to collect world wide local geographic knowledge and create a map by the people for the people. Practically there is, however, a substantial gap between that lofty ideal and the practical reality of mapping.

A very good example to illustrate this mismatch between the ideal and reality of OpenStreetMap is animal related infrastructure. Animal husbandry is of enormous economic and social importance in huge parts of the world and accounts for a substantial portion of landuse world wide and wild animals and structures they create form a significant part of ecosystems. This is, however, not reflected in practical mapping in OpenStreetMap. Mapping of animal related infrastructure and landuse is quite marginal and most mapping and tagging concepts in that domain are quite shallow semantically compared to other fields of mapping. More than that, mapping of animal related infrastructure is dominated by infrastructure related to pets.

This reflects the massive over-representation of urban populations among mappers in OpenStreetMap. Since animal husbandry and livestock management are primarily pursued in rural areas, many mappers are essentially out of touch with this whole domain.

And this bias is also reflected in maps produced from OpenStreetMap data of course. Even the differentiated depiction of agriculture in general (where mapping is somewhat more widespread and more in depth than for animal husbandry) is rare in OSM based maps while non-pet animal related elements are almost completely absent.

OSM-Carto, as a very rich map that depicts and differentiates a lot of things, currently shows the following features at least partly animal related in a wider sense:

Retrospect on agricultural landuses

Before i go to discuss new map design concepts i want to take a look back on the extensions of rendering agricultural landuses and animal related infrastructure i had introduced previously. This primarily amounted to differentiating landuse=farmland and landuse=orchard by crop and trees.

landuse=farmland and landuse=orchard differentiated by crop/trees in the AC-Style

landuse=farmland and landuse=orchard differentiated by crop/trees in the AC-Style – link goes to double resolution rendering

In addition i recently introduced rendering of acquacultures:

Rendering of landuse=acquaculture in the AC-Style

Rendering of landuse=acquaculture in the AC-Style

Meadow types

The first and most obvious component in depicting elements in the map that are related to animal husbandry is showing land being used for grazing animals and for growing food for animals. There is no general landuse=pasture tag in OpenStreetMap though. And it would make only limited sense since the types of landcover and vegetation used for grazing animals varies a lot world wide. What is well established (due to the focus of mapping in OSM on temperate zone regions) is meadow=pasture as a secondary tag to landuse=meadow for indicating grass covered areas used as lifestock pasture. It is, unfortunately, not common to differentiate the type of animal grazing there. There is, however, a similar tag in the form of meadow=paddock that essentially means pasture for horses. In addition there is meadow=agricultural – which indicates grass being grown for hay production – not necessarily, but practically predominantly for being fed to animals.

New rendering of landuse=meadow + meadow=pasture at different polygon sizes

New rendering of landuse=meadow + meadow=pasture at different polygon sizes

landuse=meadow + meadow=paddock

landuse=meadow + meadow=paddock

landuse=meadow + meadow=agricultural

landuse=meadow + meadow=agricultural

At large polygons sizes this adds a regular pattern to the grass-green color fill background. But note that at small polygon sizes for meadow=pasture and meadow=paddock i switch to a single symbol pattern (which i first introduced for sport pitches). This reduces the likeliness that at small polygon sizes all symbols are cut off at the edges and are therefore not well readable.

The symbol used for meadow=pasture is showing a generic quadruped animal – the same symbol shape is also used in other designs shown in the following. The symbol used for meadow=paddock depicts a horse.

Meadow orchards

As a not strictly animal related change, but more an extension for agricultural landuse depiction, i also added distinct rendering for meadow orchards. There are two variants of mapping those – either with landuse=meadow and meadow=meadow_orchard or landuse=orchard and orchard=meadow_orchard. For the former the natural design approach is to combine a grass-green base color fill with a tree symbol pattern. For the latter this is more tricky, because tree symbols alone point towards (and are used for – see above) landuse=orchard + trees=apple_trees or similar. I chose a two-symbol pattern consisting of darker trees mixed with brighter grass symbols. This is somewhat more noisy in the results, but should transport the meaning. The single symbol version either uses one of each of these symbols (at very small polygon sizes) or a tree symbol between two grass symbols (at somewhat larger polygon sizes).

Design for meadow orchards mapped with landuse=meadow + meadow=meadow_orchard

Design for meadow orchards mapped with landuse=meadow + meadow=meadow_orchard

Design for meadow orchards mapped with landuse=orchard + orchard=meadow_orchard

Design for meadow orchards mapped with landuse=orchard + orchard=meadow_orchard

Where animals are kept

There are also a number of primary tags to map places where animals are kept and managed that have some (though rather limited) adoption in OpenStreetMap. I render four of these with a traditional point symbol and name label and with a polygon fill in the same color as landuse=farmyard when mapped with a polygon.

Features for keeping animals with symbol and name label (rendered for nodes and polygons) and polygon fill

Features for keeping animals with symbol and name label (rendered for nodes and polygons) and polygon fill

Those tags are:

  • landuse=animal_keeping – which is used for infrastructure where animals are kept for use, for example as work animals or for riding, but not for breeding and growing them. This is primarily used for horses.
  • amenity=animal_breeding – which is used for places where animals are kept either for breeding/growing or for producing secondary products like milk.
  • amenity=animal_boarding – which is used for places that take care of pets temporarily while their owner has not time to do so.
  • amenity=animal_shelter – which is used for all kind of infrastructure sheltering animals, including, but not limited to facilities taking care of abandoned pets and injured wild animals. It is also used for structures sheltering animals from the weather like dog houses.

All of these are differentiated by type of animal if that is tagged using animal_keeping=*/animal_breeding=*/amenity=animal_boarding=*/animal_shelter=*. The animal types shown in the following are the ones for which i designed symbols. These are the most common ones currently tagged.

keeping animals differentiated by type of animal

keeping animals differentiated by type of animal

All combinations shown are supported. As indicated amenity=animal_boarding is really only applicable for pets, you can tag amenity=animal_boarding + animal_boarding=cow, but it is going to be shown with the generic amenity=animal_boarding symbol.

In addition to varying the design of the symbol the type of animal also influences the starting zoom levels at which symbol and label get shown. Facilities for large animals like horses and cows get shown earlier than others.

Starting zoom levels of features for keeping animals (mapped with nodes on top and with polygons on bottom) as they differ between large and small animals

Starting zoom levels of features for keeping animals (mapped with nodes on top and with polygons on bottom) as they differ between large and small animals

Revisiting dogs

I also took the opportunity to address a sore spot in the style that had be left open since the AC-Style was started in 2017 – dog parks.

One of the main initial goals of the AC-Style was to move to a more systematic design of the color scheme for landcover fill colors – a goal that i consider largely accomplished in the first few years of the project – see various blog posts discussing this. Rendering of leisure=dog_park, however – which, in OSM-Carto, is using the same base color as leisure=playground – was left unchanged so far (though i changed the playground color – hence this weird color match was resolved).

I have now decided to include this in the design framework for animal infrastructure with the farmyard color as base and a pattern showing a dog profile view – which is more specific than the generic paw symbol using in OSM-Carto, which could refer to any animals with paws.

New design for leisure=dog_park

New design for leisure=dog_park

Small animals

Not all animals for which humans build infrastructure are large – i also included some insect related features. There is landuse=apiary for areas where beehives are placed:

Rendering for landuse=apiary

Rendering for landuse=apiary

and related to that there is also a tag for individual beehives (man_made=beehive) – which i depict at z19+ together with man_made=insect_hotel.

Rendering of man_made=beehive and man_made=insect_hotel

Rendering of man_made=beehive and man_made=insect_hotel

Feeding and watering

Finally, there is infrastructure for animals to feed and drink. amenity=feeding_place i already showed above to be differentiated according to the type of animal. Like with the larger animal related features rendered with a point symbol i vary the starting zoom level depending on the size of the animal (and indirectly the size of the feeding place) – places for horses, cows etc. start at z18 while places for cats, dogs and birds only at z19. amenity=game_feeding – since predominantly mapped in areas with otherwise low feature density – is shown even earlier.

Rendering of animal feeding and water supply

Rendering of animal feeding and water supply

In addition i tried a subtle differentiation by the type of food – showing hay, grain and salt in different colors, similar to what i previously did for silos and mines – though with a much smaller color accent. For salt this is poorly visible in front of the standard background color, but much better on most vegetation related landcovers.

amenity=feeding_place and amenity=game_feeding differentiated by type of animal (feeding:for=*) and type of food (feeding:fodder=*)

amenity=feeding_place and amenity=game_feeding differentiated by type of animal (feeding:for=*) and type of food (feeding:fodder=*)

And amenity=watering_place is shown with the same symbol shape as amenity=feeding_place – just in the blue color of water related features. In addition to the plain static symbol rendering i also depict combinations with other water related tags using symbol augmentation.

Symbol augmentation for combinations of amenity=watering_place with other water related primary and secondary tags

Symbol augmentation for combinations of amenity=watering_place with other water related primary and secondary tags

As with previously introduced symbol augmentation for water related features this dynamically adjusts to context:

Symbol augmentation for amenity=watering_place and natural=spring adjusted to connecting waterway and nearby other symbols

Symbol augmentation for amenity=watering_place and natural=spring adjusted to connecting waterway and nearby other symbols

Conclusions

I have shown here how limited current established mapping practice in OpenStreetMap is regarding animal related infrastructure and landuse, but also how the somewhat established tags can be depicted in maps. And how a domain of animal related cartography can this way be introduced into OSM based digital maps.

In summary i would like to explain a bit the reasoning behind using certain designs and design techniques for some feature types while using other methods for other classes of features.

The different landcover renderings introduced here

The different landcover renderings introduced here

The animal related meadow variants use a coarse animal symbol pattern. This reflects that such areas are often larger and frequently contain other features the readability of which might be negatively affected by a dense pattern. Because of the coarse pattern, switching to a single symbol pattern at small polygon sizes is very helpful here to ensure the design stays clearly readable at those polygon sizes. meadow=agricultural, on the other hand, indicates a usually fairly homogeneous plantation of grass for mowing, which is represented by a much more dense pattern, even at small polygon sizes.

The features for keeping animals are rendered with a traditional point symbol and name label underneath. This reflects the use of the tag on both nodes and polygons – and in case of polygons often also in combination with a building tag. So a fill pattern is not a viable way to visualize these. leisure=dog_park and landuse=apiary, on the other hand, use patterns again.

Animal symbols used to indicate the type of animal a feature is for

Animal symbols used to indicate the type of animal a feature is for

The animal symbols used to indicate the type of animal a feature is used for almost universally feature a profile view – only the cat and wildlife symbols use a rotated head for being better recognizable. Not all of them strictly fit into the 14×14 pixel frame and they are obviously not to scale. But most of them should be fairly recognizable for what they are meant to represent. The only class of animal that is somewhat problematic to depict is the wildlife/game class because a deer as a type taxon for wildlife is not universally fitting world wide. This would be something that could be differentiated regionally. This could, however, also mislead the map user to assume the symbol indicates a more specific animal species, while the feature in question is tagged non-specifically for all kind of local wildlife.

Regarding the design techniques – in addition to various techniques i used and discussed previously i introduced a number of new techniques as part of this project, specifically:

  • use of regular patterns with several different pictorial symbols in different colors at different grid positions
  • use of single symbol patterns for small polygon features in a way that harmonically transits to a regular pattern at larger polygon sizes

Practical examples

Because of the low importance animal related features have in mapping in OpenStreetMap it is not that easy to show a broad spectrum of practical examples. For quite a few of the features i introduce rendering for here i had to search in my test database quite a bit to find some good real world examples. Here they are.

meadow=pasture and meadow orchard near Dudenheim, Germany at z17

meadow=pasture and meadow orchard near Dudenheim, Germany at z17

meadow=pasture in Provence, France at z17

meadow=pasture in Provence, France at z17

meadow=paddock in Provence, France at z18

meadow=paddock in Provence, France at z18

meadow=meadow_orchard and orchard=meadow_orchard near Ringsheim, Germany at z17

meadow=meadow_orchard and orchard=meadow_orchard near Ringsheim, Germany at z17

meadow=meadow_orchard near Ringsheim, Germany at z17

meadow=meadow_orchard near Ringsheim, Germany at z17

landuse=animal_keeping near Kork, Germany at z18

landuse=animal_keeping near Kork, Germany at z18

landuse=animal_keeping near Heidelberg, Germany at z18

landuse=animal_keeping near Heidelberg, Germany at z18

amenity=animal_breeding near Lake Garda, Italy at z17

amenity=animal_breeding near Lake Garda, Italy at z17

amenity=animal_breeding near Umkirch, Germany at z17

amenity=animal_breeding near Umkirch, Germany at z17

amenity=animal_boarding near Ihringen, Germany at z18

amenity=animal_boarding near Ihringen, Germany at z18

amenity=animal_shelter near Lahr, Germany at z17

amenity=animal_shelter near Lahr, Germany at z17

leisure=dog_park near Kappel, Germany at z17

leisure=dog_park near Kappel, Germany at z17

landuse=apiary with beehives near Strasbourg, France at z19

landuse=apiary with beehives near Strasbourg, France at z19

man_made=beehive near Lake Garda, Italy at z19

man_made=beehive near Lake Garda, Italy at z19

man_made=insect_hotel at the Tuniberg, Germany az z19

man_made=insect_hotel at the Tuniberg, Germany az z19

amenity=watering_place in the Black Forest, Germany at z18

amenity=watering_place in the Black Forest, Germany at z18

amenity=game_feeding near Heidelberg, Germany at z17

amenity=game_feeding near Heidelberg, Germany at z17

May 22, 2026
by chris
1 Comment

Update #2 on FOSSGIS membership fees.

English version based on an automatic translation with deepl.

I would like to supplement my previous discussion of FOSSGIS membership fees and, in a follow-up post, the association’s structure with an update on developments within FOSSGIS.

As I had previously written, the general meeting in March decided to postpone the decision on membership fees to an extraordinary general meeting, which is scheduled to take place online later this year for the first time on a regular basis (i.e., not as a pandemic exception), and it was announced that an informal internal association meeting would be held beforehand for discussion.

The extraordinary general meeting has now been scheduled for June 22, and the internal discussion session took place on May 6. Minutes of the meeting are available. In addition, a discussion in a smaller group apparently took place at a working meeting of the association (which occurs regularly), and this is also publicly documented.

My primary goal here is to share these references – which reflect what is visible to the outside world regarding the association and its internal discussions – with the entire OSM community. These minutes provide some insight into the association’s own perspective on the issue. Although they are apparently aware of my comments on the topic, the internal association discussions seem to revolve primarily around aspects quite different from those I have discussed. This is entirely understandable, because, as I have explained, in addition to its role as the local representative for OpenStreetMap in Germany, FOSSGIS also serves as an advocacy group for professional FOSS developers and users in the GIS sector. However, it is certainly interesting to see how the association internally perceives the various aspects I have discussed – both regarding the membership fee increase itself and the distinction between employed and unemployed members – and how the association justifies these plans internally.

I don’t want to go into detail about this again here, since I have already covered it quite thoroughly, and the linked transcripts don’t really offer any new arguments regarding the topics I have raised. However, I would like to encourage my readers – regardless of whether their perspective is that of a member of the hobbyist mapping community or that of a representative of professional interests – to view this development and the linked documents in particular also in the context of path dependence.