Imagico.de | blog

December 10, 2025
by chris
0 comments

Styleinfo update and AC-Style in Taginfo

As indicated in my Hack weekend report i updated the Styleinfo analysis of my Alternative Colors style. This includes some changes in the style i have not yet discussed here on the blog.

Styleinfo analysis of the Alternative Colors style

What is interesting to look at is the overall numbers of the old analysis and the current one. Previously, based on the style from late 2022, the analysis contained:

408 primary tags
211 secondary tags
1997 tag combinations
14831 renderings

Now it has:

473 primary tags
398 secondary tags
3038 tag combinations
22846 renderings

While not all of this difference is actual styling changes – there have been adjustment to the analysis heuristics that allow identifying stylings that were previously missed – roughly speaking the style has grown by 50 percent in terms of the taggings it interprets. But note that most of this is secondary tags. Nearly twice as many of those are interpreted now, most of them not as synonyms to other tags, but with distinct designs. The number of primary tags interpreted has grown less than 20 percent, which is primarily new POIs for human infrastructure and barriers.

This distribution reflects my overall approach in recent years to focus on depth rather than breadth and to add subtle differentiation to common base designs to keep the map intuitively readable even with a large number of features. Think of the augmentation of parking symbols, the viewpoint rendering or the various extensions of road rendering – none of which involve any additional primary tags.

Keep in mind that the Styleinfo tagging model does not cover all the variants how tags are interpreted in a complex map style. That includes all tertiary tags (like offshore wind generators or the differentiation of bell tower symbols by roof type shown here), combinations of several secondary tags leading to a distinct design, but also things like the improvements of POI labeling or the multilingual name labeling with language dependent fonts.

And there are, of course, also plenty of changes in the style that do not turn up in the overall numbers at all, while they are documented in the rendering samples – like the differentiation of barriers previously rendered in a uniform design.

With this update the Alternative Colors style is now also available in Taginfo.

In addition to the Alternative Colors style update i also updated the Styleinfo analysis of OSM-Carto – which indirectly likewise updates the Taginfo data that has been available since November.

Summary of the Styleinfo analysis of the AC-Style (all tags and all tag combinations for all feature types at all zoom levels) in the form of 16×16 pixel images.

November 25, 2025
by chris
0 comments

WeeklyOSM, volunteer appreciation and motivation

There has been an interesting remark by Ilya on Mastodon recently that i want to comment a bit about.

First the part about WeeklyOSM: Practically almost everyone in the OSM community reads it and it is a true institution in its function to disrupt the various filter bubbles in the OSM community and giving people an opportunity to widen their horizon on what goes on in and around OpenStreetMap.

At the same time it is a real role model for community projects in OpenStreetMap in its openness to contributors with diverse backgrounds. It demonstrates how this can be a true win-win-situation with low entrance hurdles for contributors and the quality of the results evidently profiting from a diverse contributor base. And this is combined with a fierce independence of the project.

So why does WeeklyOSM still struggle with recruitment? Ilya cites burn-out and lack of appreciation. The latter aligns with my recent observation on OSM community member typology, where i noted – among other things – that intrinsically motivated volunteers in the OSM community these days feel grossly under-appreciated.

WeeklyOSM editors are almost universally intrinsically motivated volunteers. They contribute to the project because they are attracted by its mission and its social function in the OSM community – and probably in most cases also by the fact that it is not guided by specific economic interests – as it is the case for many other projects within the OSM community that invite volunteers. That same thing also makes WeeklyOSM rather unattractive to contribute to for people who pursue specific economic interests in OpenStreetMap.

Ilya suggests there is a volunteers recruitment ratio between software development and communication work of 5-7 (with both terms being only vaguely defined of course, but lets ignore that for the moment). But when looking at things like that you already implicitly treat it like a pure numbers game and essentially ignore that if there is one thing turning off intrinsically motivated volunteers, it is projects where you are just a replaceable worker to burn through and replace after some time.

In terms of the actual reservoir of talent and intrinsic motivation in the OSM community (that is people who like and are fond of OpenStreetMap to a level that they – in principle – would like to get involved in their free time for that reason) i would estimate the ratio between people with non-technical skills and talent compared to technical people to be like 3:1 in the opposite direction. If that is true and the numbers from Ilya are approximately right that would mean the OSM currently demotivates non-technical volunteers 15-20 times more efficiently than technical volunteers.

What to do about it? Well, the OSM community would need to become more appreciative of non-technical and non-management work. Much more appreciative. And before you get any ideas – pretense won’t help here, i am talking about actual appreciation. I know i have said this many times in the context of intellectual work and map design in the past but it applies equally to non-managerial social tasks – including communication.

Ilya is a good example for that – he develops software but is also a talented communicator about non-technical matters. And despite being fairly extrovert, and therefore at an advantage compared to many others with social and intellectual talents and interests, it is my impression that he receives much more appreciation from the mainstream OSM community for his software development work than for communication (and even that quite sparsely – due to cultural biases and prejudices).

Normal OSM community members tend to appreciate non-technical work – like news review and aggregation as WeeklyOSM does, social and intellectual reflection and commentary, good map design etc. – as much as technical work. But people with power and influence in the OSM community almost universally have a technical, often software development background and it is my observation that an astonishing percentage of them essentially look down on people doing non-technical work. But it is even worse than that – because of the numbers i mentioned above it is a widespread belief that you can fill the undeniable needs in non-technical work cheaply and ad hoc from a near infinite pool of human capital. The problem with that view is that non-technical skills cannot be created ad hoc, in most non-technical fields, training and experience are essential for good work – as is a supportive work environment.

Which brings me to the other side of the problem: In non-technical fields it is often much harder for outsiders to distinguish between skilled and competent and unskilled/incompetent work than in technical fields. If an unskilled software developer writes bad software that is fairly clearly noticeable even by someone without a technical background, because the software sucks and that usually has immediate negative consequences even outside the technical domain. In non-technical fields, it is often much harder for a non-expert to distinguish between truly competent work and work of people who either pretend competence or who are unskilled and unaware of it. This might contribute substantially to the negative opinion many technical people have of non-technical work.

WeeklyOSM as a whole does excellent work in total, even if details (like the way individual links are framed in the text) are frequently somewhat off. But i am not too sure how many of the readers of WeeklyOSM would recognize it if WeeklyOSM was replaced by a less independent project under the influence of concrete economic interests that would more frequently report on matters in line with those interests, while silently dropping stuff that could damage those.

When i write about map design here, how many of the casual readers can actually determine if those posts provide meaningful insights into important developments in cartography or if they describe mindless and pointless playing around with toys that is of no interest for anyone serious?

And while this problem of recognizing skilled and competent work as such is more severe with non-technical work, it is not absent in technical fields. You can see truly mediocre software projects being drowned in money and praised over the moon in public communication because they fill a niche fashionable at the moment, while there are exceptionally skilled and talented developers working with a long term vision on truly innovative technologies that struggle with earning a modest living doing that.

What would be needed is a vivid, critical and independent intellectual discourse in the OSM community on both technical and non-technical matters, because that is the only way to develop true appreciation in the community for people’s contributions. Because giving everyone a pat on the shoulder – no matter how good their work is – is not really appreciation.

In societies at large it is, in particular, academic and cultural institutions that fuel and support the independent intellectual discourse on matters of importance for society. I have some hope that in the long term the OSM community might also develop some level of institutional support for this kind of work. But this is unlikely, as long as this is economically seen as a zero-sum-game (i.e. that any money invested in these things is viewed to be missing somewhere else).

OpenStreetMap Carto in Taginfo based on Styleinfo analysis

November 19, 2025
by chris
0 comments

Contemplations from the Karlsruhe Hack Weekend

Two weeks ago i participated in the OpenStreetMap Hack Weekend in Karlsruhe. I was not able to take part in many OpenStreetMap related in-person meetings in recent years due to a mixture of lack of budget and scheduling conflicts. So it was nice to meet various people there i had not seen in years. I also managed to get some actual work completed during the weekend, which i will introduce in the following. Historically, i have rarely managed to do so at hack weekends because i have mostly been working on map design – where work is frequently difficult to fit into a limited time frame. I also made progress on some map design tasks this time. These are going to require some more work though and likely will be presented at a later date.

What i managed to complete at the Hack Weekend is generating a taginfo.json file from Styleinfo data and this way get OpenStreetMap Carto into Taginfo projects. This had been on my todo list since creating Styleinfo in 2022 but so far i had never gotten around implementing that.

OSM-Carto in Taginfo

Styleinfo analyzes map styles without much a-priori information on the map style in question. It does so by systematically rendering samples of features with different tag combinations at different zoom levels and checking what the map style actually displays then. I explained this in more detail back then in a blog post. This is expensive to do, analyzing a complex map style like this can take days and it is not a hundred percent complete – some tags and tag combinations tend to be missed by the heuristics. But it produces very detailed data on how the map style actually renders things.

Taginfo includes information of data users (like map styles and various software) on how they interpret OpenStreetMap data based on structured information on the data use provided by the project through taginfo.json files.

Apart from general information on the project, that JSON file mainly contains a large array listing the tags the project interprets with optional data on how that tag is interpreted in the form of a description text, a small illustration image or a link to further information (or all of these). Originally, i had assumed that this allows for exactly one array entry per tag + feature type combination (feature type being node, linear way, polygon or relation). This would have been somewhat difficult for secondary tags like access=*, which a map style tends to interpret very differently in different contexts.

Interestingly though, Taginfo accepts an arbitrary number of entries for the same tag, documenting different interpretations of that tag. At this time i used that possibility to provide information not only on the >600 individual tags OSM-Carto interprets, but on each of the >2500 tag+feature type combinations. I could have further differentiated out the zoom levels (which would have meant ~15k different rendering variants) – but decided against it. If you want this detailed information on the map style, you should use Styleinfo.

The other interesting thing about how Taginfo deals with the projects is that it does not cache the small images illustrating the tag use, but includes them directly from the URLs specified in the taginfo.json file. That was fairly unexpected, considering nothing about this is mentioned in the privacy policy – the OSMF has some homework to do here. So, when you browse information on projects in Taginfo be aware that the images shown in the table there are directly requested by your web browser from wherever the project provides them from.

The bottom line for you as a Taginfo user is that you now have the information on what tags are interpreted by OSM-Carto, and how they are interpreted, available in Taginfo – including small rendering thumbnails and links to Styleinfo. I also provide links to the taginfo.json files for the other styles featured in Styleinfo, but i have not submitted them for integration in Taginfo. This is up to the maintainers of these projects. For my own alternative colors style i plan to do that, but first i want to update the analysis in Styleinfo since a lot of things have changed since 2022 – much more so than in OSM-Carto.

OpenStreetMap Carto in Taginfo based on Styleinfo analysis

Why so late?

Why did it take almost three years to make this available? As mentioned, this had been on my todo list since i created Styleinfo. But my free time is limited and this did not have high priority. I developed Styleinfo for my personal education and as a strategic investment into systematic testing in map design. I made the results of this available for everyone else to study and use as reference to the map styles analyzed. But i had fairly little personal interest in also making this information available in Taginfo – hence the low priority to do this in my free time.

But don’t make the mistake to conclude now that nothing could have been done to expedite this. Because i was talking only about what i do in my free time. Paid time is a different matter. It ultimately took me about one work day to implement this. If you had asked me for an offer to do this in 2022/2023 i would probably have calculated a bit more (and to be accurate: I had already read up on the taginfo.json specs before the Hack Weekend). The bottom line is: You could have gotten this already in 2022/2023 simply by moving it from my limited free time todo list to my paid time schedule – with a rather minimal budget.

Why am i pointing this out here? Because i think it well illustrates a larger issue the OSM-Community currently struggles with. It is beyond doubt that money and economic aspects play an increasing role in OpenStreetMap. You can criticize that because you wish back the good old days when OSM was fully under control of hobbyists. Alternatively, you can dismiss that criticism as naive and backwards. But both of these perspectives miss some really important aspects.

Money is neither inherently good or bad for OpenStreetMap, it depends on how you use it. And one of the things people in positions with influence on budgeting decisions (both in private businesses and in organizations like the OSMF and FOSSGIS) seem to almost universally fail to see is that a huge part of the human potential (available time and competencies) in the OSM community exists in the form of the following two groups of people:

Pure hobbyists who invest their free time into the project, but who exclusively do this out of intrinsic motivation. It is almost impossible to positively motivate those with money but very easy to de-motivate them with it. Some of these will be open to being offered economic benefits (like travel cost coverage, paid assistance), but very few will be willing to ask for such. Attempts to try to influence their decisions on how they invest their free time with money – either directly or indirectly – will usually have a highly negative effect on motivation.
People who have some level of professional connection to OpenStreetMap, but who are also investing their free time into the project separately from their professional time and who – like the pure hobbyists – spend their free time in the project purely out of intrinsic motivation. For these people, time spend on OpenStreetMap can either be professional time or personal time and they separate between the two. In their decisions on how to make use of their free time, these people tend to act like the pure hobbyists, while on their professional time they adjust to market demands.

For symmetry you can define two other groups of OSM community members:

People who – like the second group – spend both paid and unpaid time on the project, but who do not really separate between the two. These often come from one of two backgrounds: (1) Idealist professionals who took a job related to OSM out of idealism and who, therefore, get involved into their work beyond the time they are actually paid for and (2) Former pure hobbyists who have turned their hobby into a profession. In contrast to the second group, this group is open to adjust also their free time involvement to economic forces and tends to be much more willing to proactively ask and lobby for funding for their free time work than the second group.
Pure professionals who are involved in OpenStreetMap in their paid work, but who are not involved beyond that.

You can easily see that these four groups are not inherently discrete, they form a continuous spectrum. And, as you can probably imagine, i belong into the second group.

My point here is that the vast majority of money spent in the OSM community (both by private businesses and non-profit organizations, both directly in the form of paid time and indirectly in the form of subsidies and investments) is targeted at the third group. But what people often don’t realize is that this focus on the third group is

interpreted by members of the first and second group as a sign of lack of appreciation for their intrinsically motivated volunteer work.
leading members of the second group to orient themselves professionally away from OpenStreetMap, because of the lack of demand for their work compared to that of the third group.
incentivizing members of the second group to change towards working more like the third group and let their free time involvement be more influenced by economic forces.
putting pressure on members of the fourth group to get involved in OpenStreetMap beyond their paid time.

Some of these effects might be considered desirable. But keep in mind what i said earlier: That a huge part of the human potential in the OSM community exists in the form of the first two groups. It is also my observation that the third group tends to be the most homogeneous of all four groups – most male dominated, least culturally diverse.

At the Karlsruhe Hack Weekend there are people from the first three groups present (the fourth rarely so – due to the nature of the event) and because of that it can function as a forum of exchange between these groups. But you can also feel the economic and social dominance of the third group, which sometimes makes a balanced exchange of views and ideas difficult.

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.