Imagico.de | blog

November 5, 2025
by chris
0 comments

The Musaicum East Asia

I am happy to introduce the fourth large regional high resolution mosaic from my Musaicum satellite image mosaic series.

The Musaicum images are a series of regional satellite image mosaics based on Sentinel-2 data started in 2023 that are produced to a high quality standard. They offer unsurpassed quality in visual color depiction of Earth at this resolution range (10m) with a high degree of color consistency and an exceptionally low incidence of clouds.

After the initial Europe mosaic and subsequent images of West Asia and the United States as well as various smaller images of islands this is the fourth big image. And it is a special one in a number of ways.

The Musaicum East Asia

First, the region offers specific technical challenges that were not present in the previously covered regions. No part of East Asia poses a significant difficulty in image assembly due to clouds in absolute terms. For most of the area it is outright easy to find cloud free images. But in many parts these images are going to be outside the plant growth season and far away from the vegetation maximum and snow minimum, which i aim to depict. The vegetation maximum during the northern hemisphere summer in large parts features very high cloud incidence due to the influence of the summer Monsoon. For the same reason in many mountain areas in China there are two snow minima (one during summer and a second one after the end of Monsoon season).

As a result of this the volume of useful Sentinel-2 imagery available in the most difficult areas in the Eastern Himalaya is too small to allow for precise depiction of vegetation maximum and snow minimum. Even in the Green Marble (which uses many hundred source images) this is challenging.

So there is necessarily some use of off-season images (either too early and therefore with seasonal snow or too late and therefore with too little vegetation). But the extent of this non-ideal choice of source data is vastly less than in competing imagery products from other suppliers. Bottom line: This new mosaic is most certainly the most consistent depiction of that area you have seen and gives you a uniquely accurate impression of the distribution of vegetation and permanent snow and ice.

The eastern Himalaya with the Tsangpo Gorge in the Musaicum East Asia

Another regional challenge is that agriculture in the region has a strong focus on rice growth. And rice plantations change their color quite rapidly during the growth season. This makes assembling a consistent image of agricultural areas difficult.

Harbin, Northeast China in the Musaicum East Asia

Honghe Hani Rice Terraces, Yunnan, China in the Musaicum East Asia

The second aspect that makes this mosaic special is the high diversity of the region in terms of land forms, climate and vegetation, but also in terms of human geography. The region features the highest mountains on Earth, extensive high altitude mountain regions and steep gorges but also deserts and steppes, a huge variety of forests, both on the mainland and on the islands and agriculture across many climate zones.

South China Karst forms near Jingxi, Guangxi, China in Musaicum East Asia

Badain Jaran Desert, Northern China in Musaicum East Asia

Yuan River floodplain near Yuanjiang, China in Musaicum East Asia

Xuelian Feng, Tian Shan, Xinjiang, China in Musaicum East Asia

The contrasts in human geography are best illustrated by the inner Korean border, which is well visible on the Musaicum East Asia.

Korea North/South border in Musaicum East Asia

And finally the third aspect that made this mosaic special for me is that i learned a lot about the geography of the region, in particular of China, in the process. Chinese geography is historically very much neglected in Western education. The most significant white spots in Western knowledge of the planet in the early 20th century outside of the polar regions were in China. And huge parts of our knowledge and traditional geography education in the West about China still date back to the spotty insights obtained by European exploration of the region in the 19th and early 20th century. Having a reliable, consistent and representative color image of the whole country helps immensely to better understand it.

You can take a look at the product page of the new mosaic for more information and for a large number of samples.

Aso Caldera, Kyushu, Japan

Gwangyang Steel Works, South Korea (the largest steel production plant in the world)

Bayan Obo Mining District, Inner Mongolia, China (largest source of rare earth metals worldwide)

Jade Dragon Snow Mountain and Tiger Leaping Gorge, Yunnan, China

Center of Beijing, China

September 17, 2025
by chris
7 Comments

Who are the members of the OpenStreetMap Foundation?

This blog post is not about what you likely think it is about based on the title. I am not going to analyze the structure of the formal membership of the OSMF with its (based on the latest numbers) 2696 members.

I want to discuss things more from a perspective of organizational sociology here. With the given premise that the OpenStreetMap Foundation is an organization (which it quite evidently is – although i will discuss later quickly also the possibility that it is not) – one of the basic aspects of an organization is that it has members. Members of an organization tend to be people who

are involved in the organized and planned pursuit of the goals of the organization in a sustained form.
follow the formal and informal rules of the organization in doing that.

A clear distinction between members and non-members is a fairly fundamental aspect for an organization to be – well – an organization.

Now the OSMF has – as mentioned – a formal membership as required by British law. What i want to put into question here is that this membership actually constitutes the members of the organization in a functional, sociological sense.

Because there is hardly any indication these days any more that the formal members of the OSMF are more involved in the work of the OSMF than the OSM community in general. And there is also no indication that the formal members at large in any way feel bound by the formal and informal rules that apply to those more deeply involved in the OSMF.

This has not always been that way. Back in the earlier days of the OSMF (5-10 years ago) the formal members were much more involved in the organization. There was frequent open discussion of OSMF matters like policy development on the osmf-talk mailing list and on open community channels – which has almost completely vanished today. In terms of participation of the formal membership in formal processes this downward trend is also clearly visible in the participation in the board elections.

Development of the number of members eligible to vote in board elections (blue dashed), the number of votes (blue) and the relative participation as a percentage (red) in OSMF board elections.

But of course, if the formal members of the OSMF are not actually the members of the organization any more, then who is?

The most well defined group of people that could be seen as actual members of the organization are those involved in the work of the organization somewhat more long term. These are essentially

The board members (elected by the formal membership for 2-6 years)
The members of the working groups (self-recruited by the working groups)
The members of appointed bodies/positions like board commitees or other panels/committees (in most cases de facto life time appointments by the board)
The employees and long term/recurring contractors of the OSMF

Does it make sense to see these (and only these) as the members of the OSMF rather than the formal membership? In my opinion it does. Some might see this as a pointless academic distinction, but for me this re-thinking of the structure of the OSMF made it much clearer why certain things in the OSMF work the way they do.

My impression is that the development towards this more narrowly defined de facto membership of the OSMF coincides with the board significantly weakening in its de facto influence on the organization. That is partly due to the board, in recent years, being fairly dysfunctional and being unable to make meaningful policy decisions and develop binding strategic guidance for the organization. But partly this is also because within the de facto membership the board lacks legitimacy since it is elected by the formal membership, who are predominantly de facto outsiders of the organization and who had no say in selecting the de facto members.

At the same time it seems the OSMF board is increasingly reluctant to source expertise in and consult with the larger formal membership and the OSM community, likely either because they feel this would be an affront to the de facto membership (which they largely recruited) and would make them and the organization look weak, or because they, themselves, consider these essentially outsiders of the organization.

If this trend continues (and i see very little reason why it would not) that likely means that de facto power within the OSMF will increasingly shift towards individuals or informal interest groups within the sketched de facto membership. Ultimately, it is likely that the board itself in a way becomes an outsider within the organization – being formally in control (and, in particular, also carrying the responsibility), but de facto being dependent on the true insiders of the organization in everything they do.

Now the other, more radical, way to look at this is to consider the OSMF might not be an organization at all, but a project in which independent actors loosely cooperate in pursuit of their respective goals. And the formal structure of the OSMF with formal membership and board would just be a front for that. I do not consider this a suitable model though. Not because i see a high degree of organized pursuit of distinct goals within the OSMF as a whole, but because of the fairly distinct organizational culture within the OSMF that i have also criticized in the past. The carriers of that culture are not the formal members though (who are much more diverse) – which likewise supports my suggestion to re-define the de facto membership as sketched.

I don’t think there are any specific conclusions that necessarily derive from this perspective on the OpenStreetMap Foundation. But – as indicated above already – i think looking at the OSMF this way helps quite a bit understanding the social dynamics within the organization and between it and the larger OSM community.

July 23, 2025
by chris
3 Comments

New map layers on osm.org

The OSMF has recently extended the set of map layers on the OpenStreetMap website. And since none of the map designs of the two new layers has been discussed in my review of the state of map design in OpenStreetMap last year, i feel i need to put that a bit in context for my readers. The OSMF’s announcement in its post truth US PR style wording is fairly non-helpful in that regard.

Here a tabular display of the current set of map layers:

Map layers on osm.org as of late July 2025

Footnotes:

Active development of the Humanitarian style has ended, the style is archived now
Maptiler uses non-OSM (Natural Earth) data at the low zoom levels (up to z6) for physical geography (coastlines, waterbodies, glaciers) – which is largely based on >50 years old information.

Some explanation of the columns:

OSM Website label is the label used on the OSM website for the map layer in question.
Style is the actual name of the style used to produce the map. Note for client side rendered maps the style has only limited control over what is displayed on the map – as discussed previously.
Commercial/Community – indicates if the map style is developed commercially or if its development happens by volunteers in a community project. In principle this is not strictly a binary classification – there are, for example, also quite a lot of map styles developed by an individual designer without commercial background. But for the map layers on the OSM website this binary classification works – these all clearly belong into one of the two categories.
Open Source – whether the style definition is available in full for others to use under an open license.
Hosting – who does the hosting of the server side infrastructure of this map layer.
Data Update Frequency – the frequency with which the data shown is updated, specified separately for low/high zooms where applicable
Tech Stack – the software stack behind the map layer. CartoCSS+Mapnik means the map style is written in CartoCSS (usually to be processed by Carto into Mapnik XML) and rendered with Mapnik. Maplibre means the style is written in Maplibre JSON (or a YAML representation of the same data structure).

Beyond the information on the table another important thing to realize is, of course, that three layers are specialty maps (public transport, cycling), while the rest can be classified as general purpose maps without a narrow thematic focus.

I don’t want to discuss either the new layers added, or the overall selection of layers featured in more depth in this post. But i think it is clear why none of the newly added styles was discussed in my analysis of the state of map design in OpenStreetMap last year – one of them is one of the countless basic commercial Google/Mapbox look-alikes that i mentioned in passing there. One that is open source, of course, but otherwise not really remarkable.

The other one is one of the OSM-Carto look-alikes which try to imitate the OSM-Carto design appearance-wise to some extent. Those i also mentioned last year in passing. What is noteworthy here, in addition, is what i mentioned in the footnote above – that this uses very low quality non-OSM data at z0-z6.

So, in terms of the development of map design in the OSM community, there is nothing really new here. None the less, it will be interesting to watch how this further develops. It is very clear meanwhile, that within the OSMF there is a broad (though publicly not explicitly articulated) consensus in the desire to get rid of OSM-Carto. But there is also quite clearly no strategy on how to accomplish that.

In a way, the situation with community map design in OpenStreetMap is the opposite of that with various core software projects that i discussed a bit in a recent post. With those, the prevalent interest within the OSMF seems to be conservative in nature – to maintain the status quo and to invest as needed (with money and human resources) to ensure the legacy tools remain viable – at least in the short term. With map design, the prevalent interest seems to be to get rid of the status quo without there being a clear picture of what is supposed to replace it.

The main benefit for the OSM community at the moment is that they have an easy-to-access interface now to compare classical server side rendered maps and client side rendered maps directly. This will likely raise awareness to some extent of the effects of lossy data compression that is inherent to all client side rendered tiled maps. If this results in a more fact based perspective on the technical aspects of map rendering, that is certainly an advantage.

Update: I fixed typo in the table (Maptiler -> MapTiler OMT)

Musaicum Macaronesia - Canary Islands Detail

July 10, 2025
by chris
0 comments

More Atlantic Islands imagery

After introducing the European Arctic Islands in May i am now extending the Musaicum satellite image coverage to the other larger islands and island groups of the Atlantic Ocean.

The newly available data covers Macaronesia (that is the Azores, Canary Islands, Madeira and Cabo Verde) and the remote Southern Atlantic Ocean Islands (Saint Helena, Ascension, Tristan da Cunha, the Falkland Islands, South Georgia and the South Sandwich Islands).

Musaicum Macaronesia – Azores

Musaicum Macaronesia – Cabo Verde

Musaicum South Atlantic Islands – Falkland Islands

Musaicum South Atlantic Islands – South Georgia

You might have noticed that Bouvet Island is missing. That is due to Sentinel-2 recordings only recently having started to routinely include that remote island. Therefore there is not yet enough good quality data available to produce an image of better quality than my older Landsat based mosaic. Therefore i decided to not include that yet.

Musaicum South Atlantic Islands – South Georgia Detail

As usual you can find more information on the product pages of the new mosaics – for Macaronesia and the Southern Atlantic Ocean Islands.

Musaicum South Atlantic Islands – Falkland Islands Detail

Musaicum Macaronesia – Canary Islands Detail

June 22, 2025
by chris
1 Comment

The OpenStreetMap summer storm

We have summer starting on the northern hemisphere these days – and with that comes, in many parts of Europe and North America, the season of frequent thunderstorms.

In OpenStreetMap there currently is a different kind of storm brewing of a more social nature that is probably hard to accurately understand and interpret for many outsiders and that also touches a few topics i have recently been writing about so i want to make a few comments.

The dispute/conflict i am talking about is centered around the framework that powers the main OpenStreetMap website but it expands into the matter of governance of community projects in OpenStreetMap in general and the question of generational turnover, which i have recently written about as well.

Components of these discussions can be found on:

Microgrant Proposal: Atlas Design System & Modernization of OSM.org – github discussion
Why are we creating a design system for OSM? – diary entry
Why are we creating a design system for OSM? – forum discussion
How is “Core Software” governance managed in OpenStreetMap, and who decides which projects are included? – forum discussion

Now there is a bit of wider context that is very useful to know in that regard, namely that the OpenStreetMap Foundation recently started the economically largest externally financed project in its history in direct relation to the OpenStreetMap website. The OSMF has been and is fairly opaque about the details of this – we only know the very limited communication in public that has been made by the OSMF. No details on the contractual terms under which the money is given to the OSMF are publicly known. What we do know is that the overall financial volume of this project is 384k.

In parallel to that the Engineering Working group is these days taking submissions for their microgrants programme with a maximum volume per project (as announced) of 6k. One of the links above goes to the discussion on one of the submissions for that.

A lot could be discussed about the details of both of these financial endeavors – and the problematic effects this kind of money spending has on intrinsically motivated volunteers in the OSM community – but this is not my topic today. The mentioned economic developments are the main reason why these discussions develop right now and why they are centered around the OpenStreetMap website. And there is of course also the different diverging interests different parts of the OSMF are pursuing in that context. What i want to focus on here, however, are more the underlying issues behind the mentioned discussions.

The point i want to mainly make here is that this illustrates exactly the kind of generational turnover problem that i have discussed recently. Like any other community, the OSM community needs to manage a generational turnover to function in the long term. And to do that it needs to find a balance between giving new generations of community members the room and the resources to develop beyond the horizon of the previous generations and – at the same time – maintaining and valuing the wisdom and experience of the older and more experienced community members.

Normally, in the larger intrinsically motivated OSM community, this process would be facilitated primarily by different projects existing in parallel (think: different editors for editing OSM data, different QA tools, different map styles), controlled by different generations of community members, respecting and supporting each other and this way ensuring a smooth transfer of knowledge and a fair distribution of resources between different generations.

This mechanism will already get in serious peril once you mix in a substantial amount of extrinsic motivation (i.e. money, or even the vague promise of money). But we are, furthermore, talking about those parts of the OSM ecosystem here where – either inherently or by choice – there are not multiple independent projects existing in parallel but where there is a monopoly – or at least a massive market concentration and a very small oligopoly.

And most of these cases are somehow under the aegis of the OSMF. Even if the projects are formally independent, it is the OSMF that de facto gives exactly one project its endorsement and selects it for its purposes. Whether that was a conscious choice or it just happened to be how things turned out does not matter.

So it would be the OSMF’s responsibility to facilitate the generational turnover in those cases. But that is, of course, not really realistic, since the OSMF already struggles massively with the generational turnover in its own organizational structure.

What can the OSM community do here? Try to create diversity in methods and tools based on your own initiative. And this is what is happening with the website to some extent of course (see also here). But a true generational turnover will still be difficult because the mentioned balance is hard to achieve with OSMF sticking firmly to the existing monopoly without any strategic vision being communicated how this would develop in the long term. And also because these alternative projects might have more the primary aim to displace the existing website project rather than serving as an instrument to facilitate the generational succession.

In the absence of an OSMF embracing and living up to their responsibility it is primarily up to the old-timers in the various projects that have the privilege and the burden to play key roles in the OSMF portfolio to create the conditions under which a true generational turnover can happen. Try to be supportive to those who want and need to learn from you, especially if they want to do it with approaches that are different from your own. Try to embrace diversity in methods and tools and don’t see newcomers primarily as competition. You should see the younger generation as partners in the effort to bring OpenStreetMap forward in the long term. Don’t expect them to work for you or to align with your ideas how things should be done. And keep in mind that educating younger people is not only about communicating your knowledge and experience and teaching them the practical ropes, but also about sharing ideas of quality and excellency.

But the initiative needs to ultimately come from the aspirational young generation to reach out to the old-timers managing the incumbent projects. You should see them as the carriers of knowledge and experience you can learn a lot from rather than the obstacles in your way to your individual goals. You depend on them for successfully shaping the future of OpenStreetMap, just as much as they depend on you to do so. Don’t expect to be handed things on a silver platter, if you want to go new paths and pursue new ideas be ready and willing to do the necessary ground work. You should be able to expect the older generation to share their wisdom and experience with you, but not to do the work for you.

And finally to both sides: Be mindful of the economic context. If you are getting paid in some way in context of your OSM related work or if you are aiming to start a professional career related to OpenStreetMap your interaction with an intrinsically motivated volunteer needs to take that difference into consideration. The OSMF is treating this as a zero sum game and is handing out money according to the Matthew principle in the hope to have a single clear market leader that is tied to them through economic dependencies and personal relationships. Don’t make the mistake of buying into that system, even if you seem to profit from it at the moment.

And most importantly: While i have provided some analysis on why things are the way they are and what approaches might be viable to deal with the need for generational succession under these somewhat adverse conditions, i do not have all the answers. I encourage you to develop your own thoughts how to facilitate a generational turnover and present and discuss these thoughts openly.

I also want to acknowledge that the OpenStreetMap website project is, in addition, putting a lot of effort into facilitating a generational turnover within the project. That is commendable. But it is not a substitute for giving new generations the space to explore and develop completely new approaches independently within the overall community.

The other thing the OSM community can and should do is to put serious pressure on the OSMF to pull their heads out of the sand, so to speak, to stop ignoring the problem and start accepting responsibility. And that does not mean for the OSMF to start to boss people around or to simply get rid of the independent projects (which seems to be the direction where things are currently going – either by existing projects becoming more dependent or by replacing them with projects more inherently aligned with the OSMF). It means starting to think strategically and beginning to value and nurture competency and experience in the larger community rather than people whose work we know and enjoy. No one expects the OSMF to actually come up with solutions here (this would be fairly unrealistic, see above). But acknowledging responsibility for the choices made would be an important first step.

And since some will likely wonder: Yes, i also have OSM-Carto in mind here – although this is neither software nor ‘core’. As regular readers of this blog know, i have invested quite a lot of time the last years to proactively share quite a bit of my map design experience. And i have repeatedly called to develop true alternatives to OSM-Carto with comparable goals and ambitions for many years and encouraged people to start such projects. But, as i have also discussed in the past, talent and experience are only one factor here deciding if a true generational turnover is possible in the field of map design – the other is the availability of suitable tools and a supportive social environment for design work.

June 3, 2025
by chris
1 Comment

Maritime farming – displaying aquacultures

Going further from what i wrote about in the previous post regarding map design for coastal constructions and harbor features, i here want to look into rendering aquaculture installations.

Those have been mapped in OpenStreetMap for a long time with landuse=aquaculture and that tag is meanwhile used nearly 90k times and we have had an open request in OSM-Carto to render those since 2015 when the tag was only used less than 10 percent of what it is used today.

Several ideas for rendering were discussed back then but nothing was developed to a state were it was really suitable for integration into the style. The main difficulties are:

Aquacultures produce a wide range of things – like fish and mussels, but also seaweed. Designing a pictorial symbol for generic landuse=aquaculture that covers this full range and is still intuitively understandable is hard.
The design needs to reflect that it represents a physical, artificial structure and neither a natural feature (like a reef or tidalflat) nor an abstract area reserved for certain purposes (like a fishing ground)
The design needs to ensure that the background is not fully obscured (it needs to be clear that it is water, possibly tidal, in the AC-Style also possibly different types of water), but at the same time overlaps between landuse=aquaculture and natural=reef or wetland=tidalflat need to render in a readable way.

I have now developed a design that in my eyes mostly satisfies these requirements, that i want to show and discuss here now. The basic rendering concept looks fairly unspectacular:

Basic rendering concept for landuse=aquaculture on different water color backgrounds – link goes to double resolution rendering

Now, it probably seems that the design is too noisy for the lower zoom levels (z9-z10). But keep in mind that aquacultures are typically rather limited in size. And the rendering is size dependent, as you can see in the following illustration.

Design variation based on polygon size

This basic design is varied according to the produce cultivated in the aquaculture. Unfortunately, tagging practice here is not very consistent – both aquaculture=* and produce=* are used. The visualization of these variants is done with a single symbol pattern similar to what is used for sport pitches. And, like for pitches, the symbol size is increased if there is sufficient space. While, in case of sport pitches, this was implemented using standard Mapnik compositioning operations, i use GMIC here (because that is used anyway – see below).

Visualization of the cultivated produce using a single symbol pattern

So, overall, i use the following design elements:

A dotted outline in dark blue to clearly mark the extent as mapped.
A regular structure pattern to indicate an artificial structure.
A single non-blocking symbol in a size adjusted to the polygon size and – if necessary – clipped by the polygon extent. This part is only done if the feature is sufficiently large in display.

This seems relatively plain and simple to implement at first. The difficulty, however, is in the details. If you look closely, you can see, that the structure pattern does not extend to either the outline or the center symbol, it leaves a small gap to those. This is important for readability of both the outline as a perimeter of the geometry and the symbol. If the structure pattern did cover the whole polygon, its dots would reduce the clarity of the rendering of those.

You could try to implement this with standard means in CartoCSS/Mapnik by painting over the pattern with a polygon outline and an outlined version of the symbol in water color. That would, however, defeat the very purpose of why we render this with a partial coverage overlay pattern and a dotted outline: The differentiated display of the water underneath – in particular that different types of waterbody and tidal features remain clearly visible.

Aquaculture rendering in front of differentiated water areas

What i did instead is using again GMIC for composing the different layers with the help of morphological processing of the alpha masks. Like with the quay rendering discussed in the previous post the GMIC scripts are wrapped in a conditional, so, if no aquacultures are rendered and the raw rendering buffer of that layer is therefore empty at the beginning of processing, the potentially expensive operations are skipped.

What is different here from the previously explained GMIC scripts is that the buffers that are not needed any more are individually discarded while otherwise i used -keep[name] to keep only the buffer to be used and discard everything else. The reason is that at this stage in rendering there are other buffers on the stack that are still needed later (specifically the water masks used for the quay processing – see the previous blog post).

So far, so good. But you might remember the last difficulty described at the beginning of this post – if the aquaculture is mapped over a reef or a tidalflat, the result would essentially be unreadable because two strongly structured patterns would overlap. The solution here is to cut out the area covered by the aquaculture from the pattern rendering of the reefs and wetlands – again with a small buffer so the outline remains clearly visible. To do this i left the original polygon mask from the aquaculture layer on the GMIC stack (named aquaculture_mask) after rendering the aquaculture layer. The reef and wetland patterns are rendered in the landcover-area-symbols layer, which is rendered after the aquaculture layer. There, the mask is used in the following way:

zoom={round(log2(559082264.028/$_mapnik_scale_denominator))} -if $zoom>=9 -if $_mapnik_render_trivial -remove[aquaculture_mask] -else +channels[landcover_area_symbols_water] 3 -name. las_mask -dilate_circ[aquaculture_mask] {5.0*$_mapnik_scale_factor} -sub[las_mask] [aquaculture_mask] -to_rgb[landcover_area_symbols_water] -append[landcover_area_symbols_water] [las_mask],c -remove[las_mask] -remove[aquaculture_mask] -fi -fi -name. use

This is not very complex – apart from the wrapping conditional that limits the actual use of the GMIC script to z>=9. This is necessary since the landcover-area-symbols layer is also rendered at z<9 and the GMIC script cannot - as explained in the previous blog post - be made conditional through a CartoCSS selector. The actual processing of interest at z>=9 in the non-trivial case happens after the -else and does the following:

duplicate the alpha channel of the landcover overlay pattern rendering as las_mask (image 1).
dilate (expand) the alpha channel of the plain color rendering of the aquaculture layer (the mask as retained from the aquaculture rendering: image 2, after expansion: image 3)
subtract the expanded aquaculture polygon mask from the landcover overlay pattern mask (image 4).
replace the alpha channel of the original landcover overlay pattern rendering (image 5) with the the modified alpha mask from the previous step (image 6).
remove all the buffers not needed any more.
use the modified rendering for composing this layer – the final rendering result is shown in image 7.

The different buffers at the different steps in the GMIC sequence with the numbers referenced above – rendered in double resolution and with bright gray indicating transparent background

Design wise this seems to work reasonably well in the different contexts. The dotted outline of the aquacultures is clearly visible – thanks to the buffered cut-outs of the patterns. And the different patterns do not interfere with each other while the edges between tidal and non-tidal areas and ocean, inland water and rivers remain visible.

landuse=aquaculture on different water color backgrounds, tidal flats and reefs

landuse=aquaculture of different types on wetland=tidalflat background

landuse=aquaculture of different types on natural=reef background

Conclusions

What i have shown here are examples how more complex raster processing using morphological operations can be used to render different design elements in a map with cut-outs relative to each other. This facilitated solving a long standing problem in OSM based map design with well readable results.

It also shows that, as a map style grows more and more complex, both technically and design wise – with different elements being carefully adjusted in relation to each other, it becomes increasingly complex to add new features without creating a mess at least in some situations. A solid and capable technical framework and means of systematic testing are key to tackling these challenges.

As usual the changes shown here can be found in the AC-Style.

At the waterline - depiction of coastal constructions and harbour features

May 29, 2025
by chris
3 Comments

At the waterline – depiction of coastal constructions and harbor features

OpenStreetMap has – despite its British origin – not a very strong maritime focus. Reason for that is probably that only a small percentage of mappers in OpenStreetMap live in a coastal setting. And even for those who live in a coastal city, everyday life rarely focuses on this aspect.

As a result, tagging of human infrastructure specific to coastal settings is relatively under-developed in OSM. And a lot of tags that have been invented and established over time are not widely interpreted by data users – and when they are, this is often done in a rather undifferentiated way.

I wrote about natural coastal features in OpenStreetMap quite extensively – as well as their depiction in maps. This blog post is going to focus on human constructions in coastal settings and features related to human activities.

Most of the design work i present here was already developed last year. But there were some details that i only found the time to finish recently.

Symbols

Starting point for me is one of the big symbology mistakes in OSM-Carto – the choice of symbol for amenity=ferry_terminal.

amenity=ferry_terminal in OpenStreetMap is used to map a place at the coast where ferries take on or offload passengers. And the term ferry is used very widely in OSM for any kind of water vehicle regularly transporting people between specific locations over water.

amenity=ferry_terminal is OSM-Carto (link goes to double resolution version)

In OSM-Carto amenity=ferry_terminal is displayed with an anchor symbol. This is a poor and misleading choice in my opinion since the anchor symbol in cartography in most cases is used for places where ships or boats can anchor or moor – not necessarily regularly and not necessarily for on- and off-loading passengers. The anchor symbol to many map user therefore will imply a certain meaning while de facto it indicates something rather different.

The more intuitive choice of symbol would be that of a moored passenger ship – which is the concept i chose for the AC-Style now.

New amenity=ferry_terminal design is the AC-Style

This is going to appear somewhat off in case of smaller boats serving as ferry. This will, however, not be as grossly misleading semantically as the anchor symbol.

Note there is a subtle difference between the symbol for polygon features and the symbol for nodes: Nodes are rendered with a symbol where the ship has a fill color while the symbol used for polygons is outlines only so the background color shines through – normally in the transportation fill color that is also used for the symbol fill.

Filled symbol for nodes and unfilled symbol for polygons (double resolution rendering)

The reason is that the ferry terminal node is often located at locations where several line features meet (coastline, ferry route and whatever road or path leads there). Hence the background is often fairly noisy and the symbol would be poorly readable without a fill. This is less of a problem when the ferry terminal is mapped with a polygon and the symbol is placed somewhere within the polygon.

The other symbol change i implemented is the addition of a symbol for emergency=life_ring. This has been a request in the past in OSM-Carto but the difficulty is to design a symbol that, at z19 and in terms of visual weight – relates well to the other small point features shown at that scale (like amenity=bench, amenity=waste_basket). Creating a small enough symbol that is not out of balance with those and that is still recognizable as a life ring is somewhat difficult.

New emergency=life_ring rendering

Life ring at z19 in context of other small point symbols

Coastal Constructions

The three types of coastal constructions rendered in OSM-Carto

Piers

Piers as mapped in OpenStreetMap with man_made=pier are walk-able constructions over water, often used to access boats moored to the pier. They can be either swimming or erected on poles above the water. These are traditionally rendered in OSM-Carto in land color – i.e. they appear like land, but with no further indication that they are a constructed feature. That works reasonably well and avoids map users having to understand a separate design element. But it also does not differentiate the display of piers in any way.

The most common additional differentiations of piers in tagging in OpenStreetMap are (a) if the pier is floating (floating=yes) or mounted on poles or other support structures (floating=no) and if the pier is used for mooring boats or ships (mooring=*, most common values being yes and private). I have developed a design to show these with a distinct rendering now:

New rendering of piers differentiated by secondary tags floating=* and mooring=*

Floating piers are indicated with a dark blue edge line on the water side – which is only shown where the pier is mapped over water. This is relatively straight away to implement with the existing framework to differentiate rendering over water and over land.

Explicitly non-floating piers (floating=no) are indicated with a dark shadow towards the lower right – similar to the one used for planters – and a very thin outline.

mooring=* is indicated with subtle anchor symbols on the pier – adjusted in size to the display size of the pier. This is shown with a single symbol pattern for polygons and with repeating symbols along the line for piers mapped with linear ways – as illustrated here:

Mooring symbols on piers of different length mapped with linear ways

Also visible in that is that the line width is adjusted based on width=* tagging. Note that if the pier is double tagged as a road or path the name is displayed only for the road and not the pier. In OSM-Carto this is labeled twice.

I also integrated the piers into the road layer so a non-floating pier will be shown above a footway on the beach underneath with the appropriate additional tags applied.

Layering of piers in OSM-Carto (left) and in the AC-Style (right)

Breakwaters

The second water edge construction rendered in OSM-Carto is man_made=breakwater. The tag is used in OpenStreetMap to map coastal constructions meant to protect coasts and harbors from the sea. These are rendered in OSM-Carto as shown above in plain dark gray color in a common design with man_made=groyne (which is discussed in the next section). I made the following changes here:

introduced ground unit rendering of linear ways based on width=* tagging.
added differentiation in rendering for material=stone (the most commonly used material tag on man_made=breakwater) using a structure pattern – both on polygons and on linear ways of sufficient size for the pattern to be readable.

New rendering of man_made=breakwater

Groynes

The third and last water edge construction currently shown in OSM-Carto is man_made=groyne. This tag is used for constructions that are meant to reduce movement of sediment and thereby counteract coastal erosion. It is also used for similar constructions along rivers serving the same purpose.

As mentioned this tag is rendered the same as man_made=breakwater in OSM-Carto. Practically a much higher percentage of these features are mapped with linear ways than for man_made=breakwater – so i am focusing on those.

Like with man_made=breakwater i do ground unit rendering of these at the high zoom levels. And i am differentiating by material – with the most common value here being wood rather than stone – hence i developed a special rendering for that starting at z17.

New rendering of man_made=groyne with material=wood

compared to material=stone:

New rendering of man_made=groyne with material=stone

The rendering for material=wood is meant to depict a dense line of wooden posts – which is a common design for groynes made from wood. To be clear – as far as practically rendering groynes as mapped in OpenStreetMap is concerned, this rendering is a bit academic at the moment because there are currently no occurrences in the OSM database of man_made=groyne with material=wood and width=*. Also wooden groynes generally have a very small width so they will rarely be rendered above the minimum drawing width even at z20. In the above example i manually set the width to 0.75 to make the line width progression to show in a meaningful way at 40 degrees latitude. So you should take this primarily as a demonstration case for a map design technique.

The most suitable method to implement this kind of design in Mapnik would seem to be a line pattern – as i have discussed it in the past. The challenge here is to not have a cut symbol at the start or end of the line, but to start and end with a full symbol. I demonstrated how this can be done with dashing patterns in a previous post. But SVG based line patterns are a bit more limited in that regard. While Mapnik and CartoCSS in principle offer a line-pattern-transform function to scale the pattern, that approach neither offers the rendering quality nor the precision necessary here.

So in the end i chose to render the individual symbols of the line pattern using a similar technique as i had introduced with trees and tree rows. But i do not cut the individual symbols against each other like i did for tree rows. Most groynes are much longer than wide and tend to be fairly straight and – unlike for tree rows – the design does not require the cutting of symbols. So just rendering the static symbols works fine and this means a significantly better rendering efficiency than with the trees.

Individual symbol placement for the rendering of wooden groynes

Line width progression for visualizing width at very large scales

Note the dark linework of the symbols is rendered from symbol data stored in the rendering database and transformed as needed – a technique i discussed in more detail with trees. The brighter background fill of the symbols, on the other hand, is rendered using marker symbolizers.

Quays

What is – so far – not rendered in OSM-Carto is man_made=quay. This tagging is used to map solid coastal constructions where ships moor in harbors – unlike piers, which are either floating or above the water. A quay in OpenStreetmap is essentially a retaining wall directly at the waterline erected as a place where ships can be fastened to in a port and can be boarded or loaded.

Given how widespread quays are in harbors world wide it is remarkable how little the tag is used (less than 7000 times). This is of course partly because it is not much interpreted by data users.

Part of the reason for the lack of use of the tag in maps is that mapping conventions are much less defined than for many other features:

man_made=quay can be and is used both on linear ways and on polygons (with there not being a clear definition of the landward extent of a quay).
when man_made=quay is used on linear ways there is no established convention for the mapping direction. This contrasts with other oriented linear features like barrier=retaining_wall, natural=coastline or natural=cliff.

The second point of course makes sense because man_made=quay is, by definition, always directly at the edge of a waterbody. Hence its orientation clearly derives from the geometric context and having a defined orientation of the feature is – strictly speaking – redundant information. This makes rendering these in a map a bit more challenging though, because you cannot fully derive the design from the feature tagged man_made=quay alone.

The most natural approach to rendering in a Mapnik/Carto based map style would be to perform a compound query of the quay and any intersecting waterbodies. But there is not necessarily a 1:1 relationship between quays and water polygons. And you have to gracefully deal with mapping errors and ambiguous situations with waterbodies being present on both sides of the quay line. Bottom line: While this is perfectly doable it is definitely non-trivial.

I decided to take a different approach and to do the rendering of quays with the help of raster post processing using the GMIC interface i developed for Mapnik some time ago. Here is how this looks like design wise:

New rendering of man_made=quay

On the landward side the quay is rendered like a retaining wall with a solid line at the edge and – at the higher zoom level – a dashed line behind. Towards the sea this is supplemented by a dark blue line like the one drawn around floating piers (see above). For polygon features this drawing is done at the water line and slightly beyond where the polygon continues over land – this way hinting at the fact that the geometry continues without drawing a line where there is no semantically meaningful delineation.

Here is how this is done:

The blue outlining over water is rendered together with that of piers by treating quay features like man_made=pier + floating=yes in the piers-casing layer. The piers-casing layer is rendered together with the landcover-water layer in a way that only shows up over water using classic Mapnik compositioning techniques.

The landward retaining wall style rendering first requires retaining the rendering of the water features in the ocean and water-areas layers in the GMIC image buffer stack – a technique i explained in a previous blog post. As described there the way to do that, which is used on the ocean layer without further changes is

#ocean { gmic: '+to_rgba. -name. use'; }

As already explained in the linked to earlier blog post this is independent of the ocean layer using comp-op: dst-out; – which is an operation performed in Mapnik after the GMIC processing.

For the water-areas layer things are not quite as easy because water-areas also renders intermittent water areas, which are shown with a partly transparent pattern. And we don’t want that pattern to be part of the water mask to use for the quays. So we need to render the water areas separately – which can most efficiently be accomplished with attachments:

#water-areas::mask { polygon-fill: @water-color; gmic: '-to_rgba.'; }

This essentially means: render the water areas layer in plain color, store it in the GMIC buffer stack and otherwise don’t use it (since we have no -name. use). Now we have two buffers on the GMIC stack named ocean and water_areas_mask (attachments get named using the attachment name in addition to the layer name, separated by an underscore).

What we then do in the actual quays layer is first rendering the retaining wall signature on the quay features and doing so symmetrically on both sides of the line for linear ways and then applying the following GMIC script (line breaks added for readability):

-if !$_mapnik_render_trivial zoom={round(log2(559082264.028/$_mapnik_scale_denominator))} +channels[quays] 3 -name. quays_mask -channels[ocean] 3 -channels[water_areas_mask] 3 -max[ocean] [water_areas_mask] +dilate_circ[ocean] {1.0+if($zoom>=17,8.0,2.0)*$_mapnik_scale_factor} -name. water_mask_buffer -sub[water_mask_buffer] [ocean] -min[quays_mask] [water_mask_buffer] -to_rgb[quays] -append[quays] [quays_mask],c -keep[quays] -name. use -fi

What this does is:

since the whole process involves slightly more expensive steps than just trivial mask compositioning, it is wrapped in a conditional based on the variable $_mapnik_render_trivial predefined by Mapnik to indicate if the buffer of this layer is trivial (i.e. uniform color) – then the GMIC processing is skipped and the layer not rendered.
define a named variable zoom representing the zoom level that is calculated in the same way as the z() SQL function does in PostGIS with the help of $_mapnik_scale_denominator – which is made available to the GMIC script in a similar fashion as !scale_denominator! in PostGIS.
duplicate the alpha channel of the quays layer (which was just rendered – image 1 below) as quays_mask (image 2).
reduce the previously stored ocean buffer to its alpha channel (image 3).
reduce the previously stored water_areas_mask buffer to its alpha channel (image 4).
combine the water_areas_mask buffer into the ocean buffer so that what is opaque on one of them is opaque on the combination (image 5).
create a new buffer by dilating (in the sense of expanding the opaque areas) the ocean buffer (now containing the combined water mask) with a circular filter kernel, the size of which depends on the zoom level – larger for z17+, smaller for lower zoom levels. Name the new buffer water_mask_buffer (image 6).
subtract the ocean buffer (containing the original combined water mask) from the dilated buffer (water_mask_buffer). The result is a mask that is opaque in the dilated areas, i.e. what is close to the water but not within the water (image 7).
combine the result of that into the quays_mask buffer (the alpha channel of the newly drawn quay line signatures) so that only what is opaque in both is opaque in the combination (image 8).
replace the alpha channel of the original quays buffer with the modified quays_mask buffer from the previous step (image 9).
remove all buffers except quays.
use the remaining buffer for composing this layer – the final rendering result is shown in image 10.

Here the corresponding images based on a test data set with a simple quay polygon on top and a linear quay on the bottom next to water and ocean polygons on the right.

The different buffers at the different steps in the GMIC sequence with the numbers referenced above – rendered in double resolution and with bright gray indicating transparent background

You might think the logic of using a different dilation kernel size for different zoom levels could also have been implemented on the CartoCSS level by using different GMIC sequences for different zoom levels – but that is not possible. The GMIC integration in Mapnik is implemented as a parameter to the style in a similar fashion as layer level opacity. Hence it cannot be made conditional to CartoCSS selectors. $_mapnik_scale_factor is necessary to account for rendering at different resolutions.

Conclusions

I have shown a number of design concepts here for more differentiated depiction of coastal infrastructure based on OpenStreetMap data. In doing so i have, in particular, demonstrated a number of techniques:

how careful selection and design of pictorial symbols, in the right size, with a fitting motive and use of subtle design variations – like adding a bright fill to a dark outline drawing to block noisy backgrounds – can help achieving a balanced and well readable map appearance (amenity=ferry_terminal and emergency=life_ring).
use of various combinations of outline drawing to differentiate features otherwise rendered with a plain fill (floating=* on man_made=pier, man_made=quay).
use of repeated non-blocking symbols along a linear way in a similar fashion as single symbol patterns on polygons (mooring=* on man_made=pier).
further applications of ground unit rendering of linear features according to width=*.
showing precisely length-adjusted line patterns of a data defined width (with the line starting and ending with a whole symbol) by drawing individual symbols from a database representation (man_made=groyne with material=wood).
use of raster processing using GMIC to render a directed line signature based on undirected mapping and context adjusted display of polygon features only adjacent to other elements (man_made=quay next to water).
in contrast to previous uses of the GMIC integration, which were based exclusively on compositioning using multiple alpha masks, this also relies on morphological operations.

The different designs of coastal structures introduced here in context at z19

As usual the changes shown here can be found in the AC-Style. If you want to test the changes yourself you need to make sure you also have the latest version of my Mapnik extensions.

Practical examples

Here a few examples based on real world data:

Breakwaters with different materials on Reunion at z18

Breakwaters and floating piers near Sankt Petersburg, Russia at z16

Industrial quay in Sankt Petersburg, Russia at z16

Floating piers on the Rhine River, Germany at z18

Ferry terminals and life ring on Langeoog, Germany at z19

Quay line (obscured by boundary), ferry terminals and piers in Spiekeroog, Germany at z17

Floating piers and ferry terminals in Marseille, France z18

Floating piers and ferry terminals in Marseille, France at z18

May 24, 2025
by chris
1 Comment

The Musaicum European Arctic Islands

I am pleased to announce that another extension of my Musaicum satellite image mosaic coverage is available now.

The new regional mosaic covers the European Arctic Islands. That means Svalbard, Franz Josef Land and Novaya Zemlya. In terms of surface area covered this is the smallest of the Musaicum images published so far – but also one of the most interesting ones.

Svalbard on the Musaicum European Arctic Islands

Svalbard, for example, is one of the most colorful regions on Earth, thanks to a highly diverse geology. These islands also take me back to the earliest local satellite image mosaics i introduced on this blog:

A lot of progress has been made during the past ten years in terms of available data – we have several orders of magnitude more data available now – and in much better quality. While back in 2013 it was barely possible to assemble a full cloud free coverage of Franz Josef Land roughly at snow minimum – and this required going back to data from the 1980s, the new mosaic is almost fully based on data from just three years.

Franz Josef Land on the Musaicum European Arctic Islands

Accurate atmosphere compensation is still a big problem at high polar latitudes and astonishingly little progress has happened on that front during the past decade in techniques readily available – despite the raw image quality having improved so much. High polar latitudes are scarce in suitable reference surfaces to calibrate atmosphere compensation and, in addition, surface colors are highly variable over time. Further difficulty comes from the low sun position that you have during the late summer snow minimum. A substantial part of the development work that went into the newest version of the Musaicum process is related to dealing with these difficulties.

There is still room for improvement, but i can say without hesitation that this is most certainly the most consistent depiction of surface color of this region you have seen so far.

Novaya Zemlya on the Musaicum European Arctic Islands

One thing you might notice is the mismatch in ocean color between the Musaicum image and the Green Marble ocean background you can observe at many of the non-glaciated coasts (like here). The reason for this is that the Green Marble ocean color is based on an average of all seasons with open, ice free water while the Musaicum data base is exclusively from late summer near the snow minimum. During snow melt, when the ocean is ice free already, the ocean color is often significantly brighter because of particles carried by the meltwater into the sea – causing the observed mismatch.

Nagurskoye Base, Alexandra Land, Franz Josef Land

You can take a look at the product page of the new mosaic for more information and samples.

If – as i suspect it to be the case for most readers – the European Arctic Islands are not a region of high practical interest for you: There is of course also going to be additional Musaicum image coverage in other, more populated parts of the world. Where this is going to be also depends on you. Production planning is based on customer needs. So if you have an area where you need high quality imagery for and no Musaicum coverage is available yet i encourage you to get in touch.

Holmstrom Glacier, Svalbard

Bell Island, Franz Josef Land

Matochkin Strait, Novaya Zemlya

May 22, 2025
by chris
2 Comments

Individualism vs. Collectivism and Anarchy vs. Authority in OpenStreetMap

An interesting comment has recently been made by dreamy, a Korean OpenStreetMap contributor, on cultural differences in OpenStreetMap. The topic of how different cultures cooperate in OSM and what challenges this creates has interested me for a long time, so i wanted to point my readers to these comments and share a few thoughts of my own.

We in the cultural West have often very limited insight into Eastern (and also Southern) views on OpenStreetMap and often, when we get a glimpse into those cultures in OSM, we do so through people largely assimilated into a western culture – because they are the ones who often can best communicate in western languages.

Side note (and recommendation) to German speaking readers: For more background on the political/cultural concept of the West i can recommend a recent podcast by Mick Klöcker.

As you probably know, the broad agreement seems to be that Western cultures perceive themselves to be more individualist, while Eastern cultures think of themselves as more collectivist. The linked comment seems to frame this slightly differently in the OSM context as Anarchy vs. Authority (with authority not being primarily the authority of individual humans but of values and order principles) – with the de-facto state of the moment being that of anarchy.

I see substantial elements of anarchy in the way OSM works these days but i would like to suggest that this is less something that is inherent to how OSM works in the context of the cultural West. A few examples:

While not of much practical weight these days, the fundamental values of OSM form a fairly clear framework of values that could serve as a guiding principle and value system. The question is more how it came that these values have so little practical significance these days (for some discussion see here).
The origin of consensus based decision making in western cultures is not at all tied to anarchy but stems from strongly collectivist communities (like the Quaker movement and other religious communities).

Could it be that the anarchy you can widely observe these days in OSM is more related to the struggles of the more individualist parts of the western culture with the inherently collectivist aspects of OSM?

What i would be very interested to hear is ideas from the cultural East of how to practically counter the anarchy in OSM without ending up with dominance of special interests rather than harmony, universally beneficial order, moderation and collective responsibility. Especially with a huge percentage of community members having grown up in the west, in societies where individual advancement is largely put above the collective good.

March 30, 2025
by chris
2 Comments

FOSSGIS 2025 – Impressions

English version based on automatic translation with deepl.

The last few days I was at the FOSSGIS conference again for the first time since many years. And I would like to share a few impressions on various topics here.

Talk

I presented a talk on satellite image processing at the conference. You can watch the recording at CCC.

The association will probably publish the slides soon.

Satellite image topics that go beyond more or less standardized analytics (we extract some semantic information from the image and then work with it) are always quite exotic at FOSSGIS. I therefore tried to make the whole thing sufficiently easy to understand, which of course means that you can’t go into depth in 20 minutes. The presentation was well attended on site, but most of the feedback was initially – as you can expect at FOSSGIS – about the gaps in the capabilities of FOSS tools that I mentioned.

What is particularly interesting in this context is that it became clear in discussions as well as in various other presentations how much the funding of FOSS development is geared towards short-term immediate needs and how – especially in the area of basic tools such as GDAL – strategic investments are practically non-existent. I have often remarked on this in the context of OpenStreetMap in relation to map design. However, until now I had not realized how widespread this phenomenon is in the FOSS sector in general. But it is quite understandable. When Esri, for example, invests in the development of GDAL, it is not doing so in order to compete with its own products. The aim is more likely to be the same as with other sponsors: to cover immediate needs for its own products and services in the short term.

Against this background, my idea that there might be potential here for an economically viable cooperation between method development (what I do) and professional open source software development that makes these methods available to other users is perhaps somewhat naive. Because such a cooperation would of course only work economically in context of a strategic investment.

Cartography

I also attended a number of events at the conference on map design with QGIS and gained interesting insights into this world of interactive map design.

To understand the background: All of my map design work is based on a non-interactive work paradigm. I develop the rules for the design and the associated data processing in the form of rule descriptions in suitable languages (CartoCSS, PostgreSQL, various general scripting languages and structured file formats). Interactive work steps play a role practically exclusively in the design of image symbols. These design rules are then applied to generic geodata (in most cases OpenStreetMap data).

However, users of QGIS and similar tools work in a completely different way. The usual working paradigm there is based on the first-generation digitization approach that has taken place in many areas of work – including cartography: You transfer the pre-digital workflows one-to-one into interactive digital steps. In the field of cartography, this approach has now been further developed to the extent that – at least partially – rule-based work is also possible, i.e. the processing steps carried out interactively can be automatically applied to changed source data. However, rule development is still done completely interactively via a graphical user interface, so you have to click together your map design with the mouse (or alternatively: control the whole thing completely via a programming interface). There still does not seem to be a representation of the design rules in text form designed for human reading and writing.

But of course there is a lot of overlap in problems and solutions between the two approaches. And it was interesting to see where the focus is currently being placed in the QGIS area.

What I found remarkable was how great the desire seems to be among QGIS users to have all solutions within QGIS. For example, a big topic seemed to be displaying charts in maps and what chart types and display forms are available within QGIS. For me, as a firm believer in the Unix philosophy, this seems rather absurd. There are already a lot of good and powerful tools for creating diagrams – also as open source. So why do you need such a function within QGIS? I have the impression that the focus on interactive operation plays a major role here. The user really wants to design the diagrams interactively – just like the rest of the map – and wants to do this with a user interface that is consistent with the rest of QGIS. Of course, this could also be implemented with external tools for creating diagrams, but would largely negate the benefits of modularization in line with the Unix philosophy.

Annual general meeting of the association

I would also like to mention the annual general meeting of the FOSSGIS association. The most important point here was that FOSSGIS wanted to obtain (and received) approval from its members to raise funds from OSM data users on behalf of OpenStreetMap Deutschland – planned in the form of so-called sponsoring memberships in the association without voting rights.

I don’t want to discuss the topic itself in depth here – that might be something for a separate blog post. However, it was interesting to note that I was the only one who did not vote in favor of the motion. This was despite the fact that there were critical questions about the idea at the meeting. I was approached very positively by several people after the meeting – partly in the form of them explaining their own critical perspective on the topic, partly out of active interest in the reasons for my cautious stance. Of course, the fact that I have not received any negative comments on this may simply be ghosting, but I would like to mention it explicitly here anyway, in case this helps others to develop the courage to openly not align with the dominant majority opinion in such cases.

The development and organization of the German-speaking and international OSM communities was, of course, a frequent topic of the conversations I had. And i noticed a relatively strong contrast in those exchanges. On the one hand, there were conversations based on an active interest in diverse perspectives on the OSM community – especially with various active members of FOSSGIS from the non-OSM sector who are interested in further developing the social structures in the association for better integration of the entire diversity of people that the association wants to represent.

On the other hand, I have also had conversations in which a critical perspective on existing structures was either generally rejected out of hand or I was denied the justification and qualification for a critical perspective as an outside observer.

So far, this is not really surprising and basically to be expected. What I find a pity, however, is that there hardly seems to be any nuance between the two. The value of a productive discourse arises precisely from the fact that different points of view and arguments are received sympathetically and then critically examined.

I do not have the impression that the benevolently open and tolerant attitude is being lost across the board in FOSSGIS – I think I have shown that with the descriptions of my discussions at this conference. But I do see the danger that, especially where short-term economic interests come to dominate, closed interest groups emerge that increasingly develop a categorical rejection of views and ideas that are perceived as jeopardize these interests.

Talk recommendations

I’ve only seen a selection of presentations on site – because at FOSSGIS there is always the very practical and reliable option of watching the presentations later on video. From this selection and from various conversations with other visitors, here is a selection of recommendations:

Harald Hartmann: Wie können OpenStreetMap und QGIS einen Wegewart unterstützen? (How can OpenStreetMap and QGIS support a route maintainer?)

The title may not sound so appealing, but it was one of the few OSM presentations at the conference that dealt with practical questions of the social benefits and social integration of OpenStreetMap without focusing on technical or economic aspects.

Roland Olbricht: Kinder, Karten, Open Source (Children, maps, open source)

Just like Harald’s presentation, refreshingly non-technical. And deals with a really important and interesting topic: how to introduce children to concepts of maps and geodata (and geography) and their practical use. What the talk lacks is a consideration of the wealth of experience of child-friendly cartography and geography didactics for children from even pre-digital times. But highly recommended for a first insight into the topic and to raise awareness.

Frederik Ramm: Overpass Turbo goes PostGIS

Not only practically appealing, but also a nice demonstration of how a small FOSS project can be started with practical benefits. Of course, it should also be critically noted that you first have to be able to afford the infrastructure for such a demo.

Falk Zscheile: Text und Data Mining in der OpenStreetMap-Datenbank aus rechtlicher Sicht (Text and data mining in the OpenStreetMap database from a legal perspective)

I haven’t seen this presentation myself yet, but I spoke to Falk about the topic. About a sub-topic from the spectrum of copyright and database law that many people don’t have on their radar.