Imagico.de | blog

June 28, 2026
by chris
0 comments

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

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.

April 10, 2026
by chris
4 Comments

The ways of the water in OpenStreetMap

Mapping of surface water is evidently a huge part of recording the physical geography in OpenStreetMap. Water covers two thirds of the planet and is one of the most important resources for human life.

I have written quite a bit about mapping practice of the edge of the ocean in OpenStreetMap. Here i now want to discuss a bit the mapping of flowing water using – in OpenStreetMap terminology – waterways.

The purpose of waterways in OpenStreetMap is to map the flow of surface water as well as – in some cases – the routes for human navigation on those waterways using ships or boats. There are five tags widely used for this purpose and all five of them originate from the very early days of OpenStreetMap. They were tags of the first hour so to speak and were never supplemented by any new tags that come close to these five regarding the scope of use.

Of course, this choice of primary classification of waterways was heavily shaped by the UK geography and could not easily be applied in other parts of the world – hence the meaning of these tags changed quite a bit as the scope of OpenStreetMap widened. This change and what the five waterway tags are de facto used for these days is what i want to discuss here.

Use of different waterway tags in mapping around Yakutsk, Russia. This is fairly patchy regarding smaller watercourses, which is quite typical for many parts of the world.

The local mapping of waterways

What the waterway tags have all in common is that they are meant to be used and are used to map flowing water locally. That means the mapper sees a body of flowing water on the ground and maps it with a waterway, tagging the local characteristics. This then, of course, connects to the waterway equally mapped locally by the next mapper in the next village. But the tagging of these can be completely different based on different locally observable properties in the two places. The name, for example, might differ – or even the primary waterway tag. This paradigm of local mapping is important to keep in mind in this analysis and when practically mapping waterways. In practical conversation about watercourses in everyday life people often view, for example, a river less as a local element of geography and more as a feature of possibly thousands of kilometers size extending across several countries. There are attempts at mapping this paradigm of watercourses in OpenStreetMap as well- using waterway relations, but this has severe issues with verifiability and has therefore not gained much traction. In this discussion i am focusing fully on the local mapping using individual waterway ways.

The legacy waterway tags

These are the five waterway tags and their approximate original meaning based on the UK understanding of geography.

waterway=stream represents smaller naturally formed watercourses.
waterway=river represents larger naturally formed watercourses. A large river in the UK is, of course, quite puny by global standards.
waterway=canal represents artificial watercourses built for the purpose of transportation, waterpower or irrigation. In the UK this practically mostly means transportation. The UK has a fairly large network of canals originally built for commercial transportation, which are relatively small compared to many canals in other countries and which are today often mainly used for recreational purposes.
waterway=ditch represents an artificial ditch dug for draining of adjacent land through either surface waterflow, percolation of water in the soil or through drainage pipes ending in the ditch.
waterway=drain represents an artificially constructed watercourse with a lined surface for transporting away excess surface water or wastewater.

The delineation between waterway=stream and waterway=river is interesting. The original idea apparently was that the really wide rivers (which, in the UK, are essentially only the estuarial sections of large rivers like the Thames) are to be mapped exclusively with polygons, the medium width watercourses with a linear way tagged waterway=river and the most narrow natural watercourses with waterway=stream. And since, in the UK, fast flowing larger rivers are rare and most watercourses of the waterway=river class occur in relatively flat terrain with moderate to slow flow rates, the width of the river is a fairly good proxy for the size of a river in terms of water volume per time transported. And – in the same fashion – it is rare for a river in the UK to substantially widen first and then become more narrow again, unless there is a lake – so the situation that a waterway=river would in downstream direction connect to a waterway=stream based on a width based delineation is rare. As a result in the UK this tagging practice directly represented the traditional cartographic paradigm of single line depiction (waterway=stream), double line depiction (waterway=river) and depiction of actual surface water extent (polygon mapping) in moderate to large scale maps.

Water features in the legend of Ordnance Survey map 1:50k

The artificial waterway classes have no explicit size constraints, their actual range in watercourse sizes derives from the practical sizes these features have in reality – originally in the UK and later worldwide. I will discuss this more in detail later.

So essentially – the five waterway tags as originally devised can be alternatively classified by two binary delineations: natural vs. artificial and narrow vs. wide. How the five tags map to these can be seen in the following table:

	narrow	wide
natural	waterway=stream	waterway=river
artificial	waterway=canal
	waterway=ditch
	waterway=drain

Together these tags are currently used more than 35 million times in OpenStreetMap – which makes it one of the top feature classes in OSM – after buildings, roads, addresses and landcovers.

The meaning of waterway tags today

Of course, this classification has developed since it was originally devised. Even within the geographic context of the UK there were gaps in this classification system and more so in other parts of the world.

But let’s first cover what stayed mostly as originally devised. The classification into natural and artificial waterways remains unchanged to this date. But it is important to understand that natural waterway does not mean it is in a pristine natural state. It essentially only means that the water flow represented by the waterway is of natural origin. The Rhine in the upper Rhine valley at the border between France and Germany, for example, has been extensively modified by humans, yet it remains classified as a natural=river, because the water drainage at large is not modified by the human intervention. An artificial canal, on the other hand, might divert water from a river along the side of a valley where water naturally would not flow.

Plan of the historic straightening of the Rhine in the 19th century

Strictly speaking, the classification into natural and artificial waterways is not a local characteristic, looking at a watercourse locally will not always allow you to make that distinction reliably. Still, this classification has been applied fairly diligently and consistently by mappers and the idea that canal/ditch/drain are artificial and stream/river are natural in origin, though not necessarily in their current shape, is not widely challenged.

What has become more of an issue is the distinction among the artificial – and to some extent also the natural waterway types. It is already visible in the original definition of the five classes above that the system for artificial waterways is incomplete. waterway=canal is narrowly defined regarding function (transportation, waterpower, irrigation) while both waterway=ditch and waterway=drain are both even more narrowly meant to represent specific role in drainage of excess water in a temperate and humid environment.

While originally, none of the artificial waterway types had an explicit size restriction in the UK context, they were all customarily limited in the scope of sizes and also depicted in maps accordingly, which further re-affirmed the established size constraints even outside the UK. Since transportation use is dominant in the early use of waterway=canal, this was, in early years, understood to be a large waterway, at least the size of a waterway=river, often even larger (a smaller waterway=river are usually not navigable). And due to the function of drainage of adjacent land, waterway=ditch tended to be used nearly exclusively for very small waterways, sometimes located in a fairly deep ditch, but the waterway itself rarely more than 1.5m wide. waterway=drain – since meant primarily for lined watercourses – also tends to apply primarily to relatively small watercourses in the UK context.

But these size constraints, of course, clashed with the geographic reality in many parts of the world, for example:

In less universally humid climates artificial watercourses for irrigation and general water supply exist in all sizes. For these, mappers saw themselves confronted with the choice of either using waterway=canal and this way clashing with the size expectations of data users for those, or extending the use of waterway=ditch/waterway=drain to freshwater infrastructure. Both practically take place. For example, the qanats in North Africa and the Middle East are often mapped with waterway=canal while the levadas on Madeira and galerías on the Canary Islands are usually tagged with waterway=ditch/waterway=drain.
In regions prone to extreme rainfall events there are often lined artificial drains in urban environments of substantial size, exceeding, by far, the dimensions waterway=drain is traditionally used for.

Levada on Madeira – does not fit into the traditional waterway classification system in OpenStreetMap, Image by JOEXX – CC-BY-SA

For natural watercourses the main developments have been that

waterway=river mapping has been extended to also include very large rivers, which originally were envisioned to be mapped only with polygons. That happened because mappers realized that with only polygon mapping important information on the direction of waterflow is lost.
The classification into river/stream is usually made in a way that enforces that a river will not turn into a stream in downstream direction, even if it narrows substantially along its course. Abiding by this principle is, by most mappers, put above applying a consistent width classification.

The issue of width

So what are de facto the size ranges the different waterway tags are used for? We don’t know for sure, but we can try to analyze those waterways that have a width explicitly tagged. These are not necessarily representative for all waterways in general and the percentage of waterways with a width tag is small. Still it will give us some idea.

Mappers have the tendency to estimate and round width values so there is no continuous coverage of the number range, but peaks at rounded values. This is strongly visible in the histograms i show in the following.

Distribution of tagged width values of waterway=stream ways

waterway=stream is expected to be limited in the range of width values because it is clearly understood to be used only for smaller natural waterways. And the distribution of width values mostly reflects that. Values less than 2.5 meters exceed those above by a factor of more than ten. There are still quite a few much larger values tagged in substantial numbers, which has a number of reasons:

Mappers preferring to tag a waterway as stream to achieve a more desirable result in rendering, especially for smaller rivers and sidearms next to a big river, or to ensure the above mentioned principle that a waterway=river does not connect downstream to a waterway=stream.
Local naming conventions indicating a smaller type of waterway (like Bach in German) leading mappers to base their classification on this rather than physical characteristics.
Waterways with highly variable water levels being width tagged according to the river bed width but classified according to lower water levels that don’t fill the river bed.
Mis-tagging of width expecting a different default unit than meters.

Distribution of tagged width values of waterway=river ways

waterway=river mirrors this – rivers with a width less than two meters tagged are just a few percent of all the width tagged waterway=river. But only above four meters the number of width tagged waterway=river exceed those of width tagged waterway=stream. So the bottom line for the two natural waterway classes is: They are quite clearly mostly used as a width distinction although the transit between them is quite a bit higher than the established rule of thumb of the OSM community (if it is practically feasible to jump over it, it is a stream) would indicate. Practically, jumping across a two meter wide watercourse is already a stretch even for a fit person on flat terrain.

Distribution of tagged width values of waterway=canal ways

With waterway=canal we can observe the problem that i already described above. The majority of features with a width tag have a width of at least 3m – which is about the smallest width of canals build for the purpose of transportation. But there is also a substantial volume of features (>10 percent) with a width of just one meter or less specified – In Europe, width=1 is even the most commonly tagged single value of width for waterway=canal.

Distribution of tagged width values of waterway=ditch ways

waterway=ditch is very similar in the distribution of values to waterway=stream – including the long tail of high width values. An additional reason for this for waterway=ditch could be that width tagging sometimes measures the ditch as a topography feature and not the actual water cover in the ditch.

width values of less than 1m are somewhat more common, relatively speaking, for waterway=ditch than for waterway=stream. But this is likely at least partly due to a general mapping bias. Ditches in their real world distribution are concentrated in relatively densely populated and hence relatively well mapped areas while small natural watercourses exist everywhere. Hence the latter are probably more severely under-mapped for small sizes than the former.

Distribution of tagged width values of waterway=drain ways

waterway=drain has a stronger weight of both the very small and the very large values in the distribution of width values. It also features a larger number of values with units other than meters specified than the other waterway types. That makes it likely that at least some of the very large values are mis-tagged assuming a different default unit. The strong dominance of very small values could, at least to some extent, result from this being the preferred tag for lined artificial watercourses – but clearly meanwhile also for such carrying fresh water for irrigation or other purposes (usage=irrigation has 3200 uses on waterway=drain). But the tag is clearly not limited to lined features. There are many areas where it is practically used interchangeably with waterway=ditch. The original idea of delineation between waterway=ditch and waterway=drain was for the former to be for features to collect excess water and the latter for carrying away excess water. This is not very consistently followed these days any more.

Other waterway types

There is the obvious question, of course, if there are any new waterway types in addition to the traditional five than have been introduced since then. Apart from waterway values that do not represent watercourses (waterway=dam, waterway=weir etc.) there are a number of specialty values that have gained some adoption and also some failed attempts at separating out things from the traditional five tags. Here a quick summary:

waterway=tidal_channel has been introduced in 2019 as a means to map the water flow at a tidal coast, especially in vegetated settings (salt marches, mangrove). This differs from the tidal sections of rivers/streams, because here the water flow fully reverses with the tides, while in a tidal river, the water level changes with tides while there is a continuous downstream water flow. It has gained some adoption but with 29k uses it is still very far away from becoming one of the main waterway tags.
waterway=pressurized has been introduced in 2018 and was originally intended as a blanket tag for any enclosed conduits of water that are fully filled with water, either pipelines or underground tunnels, and both natural and artificial. Practically, the tag is almost exclusively used for pipelines and artificial underground tunnels carrying water, >90 percent of these are double tagged with man_made=pipeline. 12k uses.
waterway=flowline is a recent introduction from 2024 as a tag for mapping the drainage network within waterbodies mapped as standing water (lakes, reservoirs). This has traditionally been done using the main waterway tags – and it still is. However, there has long been disagreement among mappers if this kind of mapping is desirable, i.e. if a river ends where it enters a lake and begins again at the other side or if the river goes through the lake. This tag is an attempt to resolve that disagreement. It does, however, have the disadvantage that it does not differentiate between the different waterway types – those you would need to infer from the other waterways it connects to. 47k uses.
waterway=wadi has – for some time – been an attempt to expand the idea of the original five waterway classes as climate and region specific classifications to arid and semi-arid parts of the world. This has not been successful though and the tag never developed a well defined meaning globally, largely because it was widely applied independent of the verifiable presence of water flow. It is now hardly used in active mapping any more and has just above 3000 remaining uses.
waterway=drystream is a rather odd idea for a waterway type that gained some limited popularity from 2015 on. In essence, it is an attempt to map relief structures that seem like to have originated from waterflow without verifiable waterflow being a condition for using the tag as waterway. But, in contrast to tags explicitly mapping relief structures like natural=gully and natural=earth_bank, an actual relief form is not considered a defining element for this type of waterway either. So, in essence, this is a tag for something that a mapper considered to have originated from waterflow but that does not qualify either as an actual waterway or a relief form. The tag currently has 17k uses, mostly in Russia.
waterway=derelict_canal has actually been around for about as long as the five main waterway tags so you could consider it a sixth legacy waterway type. It is used for what today would most likely be tagged with disused:waterway=canal or abandoned:waterway=canal. It has minimal use with just about 2600 applications, but is more established than the lifecycle prefixes in this case.
waterway=fish_pass is a tag for a very specific and narrow use case with just 3200 uses, but is quite well established for that specific purpose.
waterway=link is an outlier in the waterway tags because it is not used to map a watercourse, but for connecting boating infrastructure at the edge of a waterbody to the waterway line. It essentially constitutes preemptive mapping for the router, it is based on the assumption that this kind of data is necessary for routers to route for navigation on waterways. Since it is almost exclusively used in cases where the water covered area is mapped with polygons, it does not actually convey any additional information in most cases. 12k uses, most in the US and central Europe.
waterway=artificial is essentially an imports-only tag that has been introduced for importing waterway data where the import source differentiates natural and artificial waterways, but does not provide enough information to classify into the three established artificial waterway tags in OpenStreetMap. It has not been in active use for many years and more than half of the features originally imported with that tag have meanwhile either been re-tagged or removed. About 14k features are remaining.
waterway=brook was an attempt to separate out the very small watercourses from the traditional waterway tags. This endeavor did not succeed though, and there are only 1600 uses of the tag now. The tag notably did not maintain the distinction into natural and artificial waterways in primary tagging, it was meant to be used for both of these. And it lacked a clear criterion to delineate it from the established waterway tags.

None of these tags comes anywhere near the big five in terms of numbers in use though.

Conclusions

I hope my analysis made it a bit clearer how watercourses are mapped in OpenStreetMap and how this system of mapping came to be the way it is.

Many readers are probably going to think that this system of classification is not very good and some might outright suggest to replace it with a different system. That is not likely to happen of course. But the question, none the less, is: Did the free form tagging system of OpenStreetMap work well here or did it fail – and in case of the latter: why did it.

As i like to say: The tagging system in OpenStreetMap is like the geographic reality: Organically grown, full of weirdness and inconsistencies – yet largely functional. And i think this mostly applies to the waterway classification as well. The fact that we have not abolished or substantially modified any of the five main original waterway classes does not mean OpenStreetMap is limited to those to characterize waterways. We have plenty of secondary tags that provide additional information. I mentioned just a few of them here (width, usage).

But waterways also demonstrate in my opinion what i see as a substantial deficit in the way tagging consensus is developed these days – that the community largely shies away from discussing clear delineations of tags. In the large and diverse OpenStreetMap community of today views on supposed tag delineation unavoidably differ. But instead of facing these differences, engaging in discussion and arguments and working towards consensus, people often choose the superficially easier way to leave such things unresolved and to deliberately stay vague in delineation of tags. The waterway=stream/waterway=river delineation is a good example here. For more than a decade this has been tied to the deliberately vague idea of the jump test (if you can jump over it, it is a stream). That is not bad as a rule of thumb, for example for a mapper crossing the watercourse in a car and casually assessing the size from the window. But it would have been of much benefit for both data quality and the ease of mapping if this rule of thumb had been concretized with a numerical value at some point.

Northern Greenland in Musaicum Greenland

April 1, 2026
by chris
1 Comment

The Musaicum Greenland

There is another extension available for my Musaicum satellite image product – covering the island of Greenland.

Greenland has been in the political news quite a bit in recent months, so it is probably a fitting time to introduce the new image.

As long time readers of my blog know, Greenland is also – contrary to marketing claims – not fully covered by Sentinel-2 image data. Creating a Musaicum extension for all of Greenland, therefore, required changing the Musaicum process to allow use of Landsat image data. Some subtle color differences between the Sentinel-2 and Landsat based parts of the mosaic are inevitable due to the different characteristics of the sensors, but it still is in essence a seamless transit. This also makes the Musaicum Greenland the first visual color image at this resolution class that is produced to a common quality standard for the whole area of Greenland.

Ilulissat Icefjord

The Musaicum Greenland replaces my previous regional image product of Greenland from 2015 – the Landsat mosaic of Greenland. A bit more than 10 years ago this was a milestone in high quality mosaics of more remote regions, and to this date it remains the most uniformly consistent image product of Greenland at higher resolution available – with exception of the Musaicum image introduced here now.

For better comparison i produced samples of many of the same spots where i also showed samples of the Landsat mosaic – in different projections though.

I also offer the option to provide the image with local contrast adjustment – a method i originally introduced for my Antarctic mosaic and that is useful in areas with strong brightness contrast – like in Greenland with the bright ice sheet and glaciers and dark bare ground on the other hand.

Comparison of normal tone mapping with local contrast enhancement – larger: normal, local contrast enhanced

~~I have not updated the Mercator image tiles yet, that should follow in the near future.~~ – See below for update.

If you are interested in using this new image product you should have a look at the product page.

Rivers at the coast in Hagen Fjord, Northern Greenland

Eastern Greenland glaciers

Sermilik Fjord, Eastern Greenland

Update: The Mercator map is now also updated with the Greenland tiles.