Imagico.de | blog

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.

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:

leisure=dog_park – awkwardly with the same base color as playgrounds
landuse=meadow – only shown rudimentarily in the same way as all other grassy landcovers
amenity=veterinary – point symbol and name label, with symbol implying this to be pets related
barrier=cattle_grid/barrier=kissing_gate/barrier=stile – point barrier typically used to block animals but let pedestrians pass through, shown with a point symbol
shop=pet – point symbol and name label
amenity=hunting_stand – point symbol
leisure=bird_hide – point symbol

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 – link goes to double resolution rendering

In addition i recently introduced rendering of acquacultures:

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

landuse=meadow + meadow=paddock

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

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

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

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

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

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

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

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=*)

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

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

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

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 in Provence, France at z17

meadow=paddock in Provence, France at z18

meadow=meadow_orchard and orchard=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 Heidelberg, Germany at z18

amenity=animal_breeding near Lake Garda, Italy at z17

amenity=animal_breeding near Umkirch, Germany at z17

amenity=animal_boarding near Ihringen, Germany at z18

amenity=animal_shelter near Lahr, Germany at z17

leisure=dog_park near Kappel, Germany at z17

landuse=apiary with beehives near Strasbourg, France at z19

man_made=beehive near Lake Garda, Italy at z19

man_made=insect_hotel at the Tuniberg, Germany az z19

amenity=watering_place in the Black Forest, Germany at z18

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.

May 1, 2026
by chris
1 Comment

Follow-up on FOSSGIS

English version based on an automatic translation with deepl.

Following the discussion about my post on FOSSGIS membership fees, it has become clear to me that my account – and especially the suggestions I made – are somewhat incomplete.

I have quite clearly criticized the fact that, since becoming a local representative of OpenStreetMap in Germany in 2017, the FOSSGIS association has failed to resolve the latent conflict between its role as an advocate for professional developers and users of free and open-source software in the GIS sector and its role as a representative of the German hobbyist mapping community. And I have made suggestions regarding membership fees and the association’s cultural openness to address this problem. However, these too – as should be clear to most – would not truly resolve the conflict.

Therefore, I would like to outline here, as a supplement, how the conflict could be addressed at the strategic level and, hopefully, resolved in a sustainable manner.

The problem with the association’s current organizational structure is that opening it up substantially to the hobby mapper community will only work if a large number of hobby mappers join the association and become active within it – bringing with them their own ideas about working methods and their culture of cooperation. The result would be a takeover of the association by the OSM community. Compared to the current situation, the problem would essentially just be reversed. The reason for this lies in the association’s structure, which is centralized at both the board and member levels and based on majority decisions.

The obvious solution would be to split FOSSGIS into two associations. And if FOSSGIS were actually taken over by the OSM community (which – as already indicated – would be hardly realistic due to the widespread lack of interest in the German hobby-mapping community, even under favorable conditions), this would be the most likely outcome, as FOSS developers and users would then presumably organize themselves elsewhere.

However, this solution would undermine the opportunities and synergies mentioned in the previous post, which exist precisely in the connection between Free and Open Source Software and OpenStreetMap.

A federal structure would be the strategy for sustainably balancing professional advocacy and representation with the organization of the hobbyist mapping community within an association. The two major segments in the association’s goals and its operations would largely coexist autonomously, could utilize shared structures, but would not be required to do so. Members could freely participate in the systematic pursuit of the respective goals of the two autonomous parts of the association, based on their own distinct formal and informal rules, without having to submit to the rules of the other segment.

It is important that this (internal) autonomy is actually formalized – in other words, that we don’t just say: “Yes, you can act freely in your working group, but in case of doubt, the board or the general assembly can shut you down at any time by a simple majority vote”.

To ensure that the whole thing remains an association not only formally but also de facto, a supervisory body would need to be created to mediate between the autonomous structures and the necessary and sensible central decisions (for example, regarding budget issues). This body would need to be composed of equal representation, ensuring that one part of the association does not dominate the other.

This type of structure is nothing new; it already exists, for example, in associations that manage individual large FOSS projects. In such cases, there is usually a supervisory board composed of an equal number of developers and users.

I realize that the chances of the FOSSGIS association actually undergoing such a fundamental restructuring (i.e., the general assembly securing the necessary 3/4 majority) are significantly lower than the chances of my ideas regarding membership fees being implemented. My point is to make it clear that this is a problem that can be practically solved if the collective will is there, and not an unsolvable dilemma that we simply have to live with.

April 17, 2026
by chris
3 Comments

The Saga of FOSSGIS Membership Fees

English version based on an automatic translation with deepl.

I had actually already decided not to write this blog post – but recent developments have led me to reconsider that decision. However, I’d like to start from the beginning so everyone can follow along, including those who aren’t FOSSGIS members and therefore likely haven’t heard much about these issues until now.

Background

Historically, the FOSSGIS association essentially began as an advocacy group for professional developers and users of free and open-source software in the GIS sector. However, the association’s goals were defined much more broadly from the start, and during my time there, FOSSGIS has generally always demonstrated an openness to activities outside this core area, which I have always viewed as very positive. In the end, however, this only applied as long as the dominance of professional interests was not called into question. In other words: While the generally significant role of development and use in the non-professional, private sector within the FOSS field was accepted and acknowledged, it was clearly positioned within the association as subordinate to the professional sector – something that is not generally the case in the global FOSS community.

At the end of 2017, the FOSSGIS association became the local representative for OpenStreetMap in Germany. This immediately called into question the dominance of professional interests within the association, and there was actually an opportunity for the German OSM mapping community to take over the association. This did not happen, primarily for three reasons:

OpenStreetMap was already an important topic within the association, particularly among professional developers and users. So it wasn’t as though OpenStreetMap was completely new to the association and OSM activists found an untapped field there; rather, the topic was already established and integrated into the association’s professionally oriented structures.
The German mapping community was and remains – despite being one of the largest and most active local communities worldwide – highly individualistic and very loosely organized. The overwhelming majority of mappers in Germany are content to map on their own and, beyond occasional local meetups, feel no need to organize or get involved – especially not where there are no existing structures and something has to be built from scratch.
The hurdles for formal membership in the association were quite high, especially in early 2017 to 2018; one had to submit a written membership application (on paper) and pay a membership fee of EUR 30 per year, which was double the OSMF membership fee. As a result, the number of hobby mappers who joined the association in the early years due to FOSSGIS’s new role was likely significantly lower than the number of existing professional members with ties to OSM. In addition, having a say in the association’s formal decisions was (and still is) de facto tied to physical attendance at the annual general meeting. Online participation is not provided for (with the exception of the COVID years due to a special provision by law), and the delegation of votes is only possible to a very limited extent (a member present can only have one vote delegated to them).

Thus, not only was a takeover of the association by the OSM community practically ruled out, but de facto, hobby mappers have virtually no influence within the association.

In 2020, the general meeting decided to increase the membership fee for individuals from EUR 30 to EUR 40. At the same time, the membership fee for corporate members was doubled from EUR 100 to EUR 200, and a decision was made to create a permanent paid (part-time) position within the association for administrative work. I was not at the meeting at the time, so I cannot report on the discussion there beyond what is in the minutes (For those who remember: that was the legendary FOSSGIS conference held virtually on the eve of the first pandemic lockdown).

The paid positions within the association, which had previously been limited to internal administrative roles, were expanded in 2023 to include a so-called OSM Advisory Office (see here – the details of the job description appear to have been removed in the meantime). This, along with the ideas behind it and their practical development, would be a topic for a separate post; I’ll omit it here for the sake of brevity. Along with the announcement a month ago of the creation of another position for the development of OpenStreetMap training courses within the framework of FOSSGIS, it can be said that the association is increasingly active in the area of OpenStreetMap services, and is primarily focusing on paid work. Attempts to raise funds for this seem to have had mixed results – the idea of a funding program presented at the 2025 general meeting (I wrote about it here) does not seem to be going particularly well – instead, there appears to be a growing effort to seek public funding. This is particularly noteworthy given the wide range of unpaid consulting and lobbying work that has been carried out for many years by the hobby-mapping community, and which now, of course, stands in contrast to the paid activities within FOSSGIS.

It is interesting to note in this context that FOSSGIS is increasingly presenting itself as OpenStreetMap Germany, thereby implying a claim to represent the German OSM community. On the one hand, this is also emphasized in the association’s public communications, where it speaks of us, the community, but at the same time distances itself from the community and presents the association as a link to the community.

The Membership Fee

So much for the background. Prior to this year’s general meeting, the board sent a proposal to the members to increase the membership fee once again, this time to EUR 60 – meaning, combined with the previous increase, a doubling within seven years, which would position FOSSGIS at the very top among OSMF local chapters in terms of membership fees. I didn’t attend the FOSSGIS conference this year either, so I wasn’t at the general meeting, but apparently there was a discussion and the board’s proposal was not accepted; instead, the board was tasked with initiating an online general meeting to discuss the issue and reach a decision.

After the initial announcement and the anticipated approval by the general meeting, I had already decided to use this as an opportunity to terminate my membership in FOSSGIS, but I was pleasantly surprised to find that not only was there a critical discussion of the proposal, but that it was also decided to discuss the matter as broadly as possible, at least within the association. And with this post, I would like to try to open this discussion to the OSM community outside the association as well. Whether this will ultimately be heard, of course, remains to be seen. In internal association discussions over the past few years, active members of the association, including those on the board, have repeatedly made it clear that they want the association’s decisions to be made exclusively within the association – uninfluenced by outside discussions.

To put the membership fee amounts into context: The standard FOSSGIS membership fee, currently EUR 40 (proposed to be EUR 60 in the future), applies to working members. For non-working members, there is a reduced fee of currently EUR 10 (proposed to be EUR 15 in the future). The association does not define working member; it is entirely a self-declaration. This distinction, especially in Germany with its current demographics, is quite a slap in the face for people who have to work to make a living, while people who do not have to work due to substantial non-work income pay less – regardless of whether this income is higher or lower than the work income of those who are doing paid work.

If we compare the annual membership fee to other professional associations and interest groups in Germany, even EUR 60 isn’t particularly high. A more interesting comparison is within the OSM community. Here are the annual membership fees for individuals for various organizations:

OSMF: GBP 15, free for active OSM contributors
OSM France: EUR 20
OSM Switzerland: CHF 20
OSM Austria: free
OSM UK: GBP 5
OSM US: USD 20
OSGeo Oceania: free
OSM Belgium: free
Wikimedia Italia: EUR 25
Stowarzyszenie OpenStreetMap Polska: PLN 50 (EUR 12)
Asociación de Cartografía Colaborativa de Colombia: COP 350 (EUR 82), COP 175 (EUR 41) for active OSM contributors

In short: Even at the current rate of EUR 40, FOSSGIS is among the absolute top tier in the OSM sector; at EUR 60, it would be the most expensive OSMF local chapter for active OSM contributors. Among western countries with larger mapping communities, the gap would be enormous.

The most common argument I hear in favor of high individual membership fees is that the association does not want to become dependent on funding from external sources. However, this argument only holds water if an association makes a serious effort to manage its budget prudently, using only the limited contributions that individual members are able and willing to provide. This is clearly not the case with FOSSGIS. Even with a membership fee of EUR 60, the projected individual membership fees for FOSSGIS total less than EUR 20k. This is not even enough to finance the administrative position created in 2020. Personally, I find the idea of an OpenStreetMap Germany association that is financed by individual contributions and is not dependent on external interests for funding regular expenses quite appealing. But for that, it would be necessary to build the association almost entirely on volunteer work. FOSSGIS clearly decided against this many years ago, by 2020 at the latest. To now suggest that the membership fee increase somehow ensures financial independence does not align with the association’s economic reality.

What is always at stake in this whole issue is the tension described in the background section regarding FOSSGIS: the conflict between representing the professional interests of FOSS users and developers – including those related to OSM – and the claim to represent the German community of hobbyist mappers. A high membership fee results – whether intended or not – in the number of members without professional interests in the association remaining low. While the association may indeed have the sincere intention of also representing the interests of the German OSM community, this is clearly not a case of democratic representation by representatives from within the community itself, but rather by individuals with their own professional interests, which do not necessarily align with the collective interests of the community, but at best act as benevolent trustees (but with inevitable conflicts of interest).

My Proposal

I think the FOSSGIS association is at a crossroads here. The underlying conflict – which began in late 2017 when FOSSGIS formally became the local representative for OpenStreetMap in Germany, and which the association did not really resolve for over eight years – could definitely come to a head here. Will the association substantially open itself up to the hobby mapper community in Germany – in the sense that mappers are not only welcome to assimilate into the existing association culture, but also in the sense that they actually expand and reshape the association with their own culture? Or will the association continue to fly the OpenStreetMap Germany banner, but exclusively as a label for its own professional activities and those of its members?

I have already mentioned that this question does not depend solely on decisions made within FOSSGIS, but also on whether the mapping community in Germany manages to organize itself sustainably, independent of professional interests. But FOSSGIS is making things too easy for itself when it claims to be open to anyone who wants to get involved. Because, as I said, that’s only true for those who are willing to adapt extensively to the existing association culture.

Against this backdrop, my proposal for membership fees would be:

Eliminate the distinction between employed and unemployed members.
Lower the standard membership fee, thereby sending a clear signal that the association is explicitly open to FOSS users/developers and mappers without commercial interests. Proposal: EUR 30.
Set a significantly reduced fee for active OSM contributors (the OSMF’s definitions could be adopted here). Proposal: EUR 10.
Create a support membership fee for individual members, intended for anyone who derives substantial income from FOSS development, FOSS use, or the use of OSM data, but also open to all members on a voluntary basis. Proposal: EUR 90.
Corporate memberships tiered according to number of employees/revenue. The proposal from the general meeting seems reasonable here, with the exception of the idea for solo self-employed individuals. The idea that an employee with a FOSS/OSM connection should generally pay a lower membership fee than self-employed individuals does not seem objectively justifiable to me. Nor does the alternative interpretation that solo self-employed individuals can or should have an independent corporate membership in addition to an individual membership. A supporting membership for all members with a professional connection to FOSS/OSM therefore seems more sensible to me.

In addition – and this is actually more important than membership dues – it would be of fundamental importance for FOSSGIS to be able to present itself credibly as the representative of OpenStreetMap in Germany that all of the association’s activities related to OSM be open to broad participation by the German OSM community, and not closed and reserved solely for association members. I consider this very important, but I also realize that this idea is likely to be very unpopular within the association. The way communication has often been handled in the past – treating things as internal association matters where outsiders have no say – speaks volumes. But truly substantial changes simply don’t happen without conflict.

In Conclusion

I hope that these remarks provide OSM activists in Germany who are not members of FOSSGIS with insight into the latest developments within the association, which also presents itself as their representative. And that, against this backdrop, my suggestions might find support or at least a positive response, encouraging others – especially hobby mappers – to articulate their own ideas.

Perhaps the fact that I’m discussing this publicly here will even generate some international interest. I’ve already outlined the unique position FOSSGIS would occupy within the global OSM community with an annual membership fee of 60 euros for regular mappers.

What I’d also like to note is that – and I’ve emphasized this several times in the past – I view the culture of open discussion within the FOSSGIS association as something very positive. However, so far it has been almost entirely limited to in-person events. If the association manages to open up this culture to digital channels and beyond the boundaries of its membership, this would have enormous potential for productive cooperation with the OSM community, especially beyond Germany. It is in this spirit that I would like this post to be understood – while I do see the conflicts as I have highlighted them here, I also see the enormous potential of this connection – provided there is a collective will within the association to adapt and open up, and to accept and support a truly new diversity within the association.

Update: Changed a formulation above based on comment – see the discussion of the German version.