Imagico.de

blog

More map symbols

November 1, 2024
by chris
0 comments

More map symbols

In addition to the point barrier symbols i also re-designed and extended quite a few of the existing symbols in the style for human built structures of all kinds.

Starting point was that i wanted to port back some of the changes in OSM-Carto that happened after i created the AC-Style. But i did not want to use these designs as is. Instead i wanted to re-evaluate the design decisions made in the process.

Waste and recycling

First part is the display of waste/recycling related features. OSM-Carto uses three different symbols here – for amenity=recycling, amenity=waste_disposal and amenity=waste_basket:

Waste and recycling related symbols in OSM-Carto - link goes to double resolution rendering

Waste and recycling related symbols in OSM-Carto – link goes to double resolution rendering

This approach has a number of issues:

  • amenity=recycling is used for a large number of different recycling related facilities of very different size and scope. Showing them all with the same symbol is not a very good approach.
  • Differentiating amenity=waste_disposal and amenity=waste_basket through generic waste bucket symbols of different size is not very intuitive. Map users will often not see both together and when seeing just one of them you don’t have the necessary context to interpret the size of the symbol as it is meant.
  • The recycling symbol is poorly readable at normal resolution
  • The lid of the waste_disposal symbol is oddly far from the bucket
  • The choice of different colors for recycling and waste_disposal/waste_basket is not intuitively understandable
  • The display of access restricted variants is not very consistent

Here is the new design schema i have developed now:

New design schema for waste and recycling related features in the AC-Style

New design schema for waste and recycling related features in the AC-Style

Concrete changes are in particular:

  • uniform color for all symbols
  • new design for amenity=waste_disposal and amenity=recycling + recycling_type=container. This depicts a classic movable waste container with wheels and hinged/sliding cover. Of course design of recycling containers varies but the basic wheeled waste container is probably known very widely and facilitates a clear intuitive distinction form amenity=waste_basket.
  • re-designed recycling symbol for better readability at small sizes
  • distinct symbols for generic amenity=recycling and amenity=recycling + recycling_type=centre
  • more harmonic lid gap size on amenity=waste_disposal and amenity=waste_basket

Towers and masts

Towers and masts in OSM-Carto already use a systematic symbol design to visualize the different variants of construction and purpose. But this set of designs has substantial gaps. More advanced in that regard is the Röntgen icon set by Sergey Vartanov – which partly served as inspiration for the work presented here.

For better understanding: The difference between man_made=mast and man_made=tower is not completely agreed on in OpenStreetMap. As a rule of thumb: A structure that qualifies as a building (i.e. that has a human walk-able inside) is generally a tower. So is a structure that has integrated steps to walk up. Something that can only be climbed up tends to be a mast.

Here is the set of designs i use for man_made=mast:

Rendering variants of man_made=mast based on tower:type and tower:construction

Rendering variants of man_made=mast based on tower:type and tower:construction

In terms of construction that includes the four main variants (with guyed_tube being the least common). In terms of function i added designs for radar and siren.

For man_made=tower the set of symbols is more extensive:

Rendering variants of man_made=tower based on tower:type and tower:construction

Rendering variants of man_made=tower based on tower:type and tower:construction

For the main functional types (observation, communication, lighting, radar and siren) there are now distinct variants for all the main construction types – as far as they are sensible combinations. And i added rendering of tower:type=minaret.

As additional detail i introduced depiction of roof:shape to bell towers. This might be considered too detailed semantically – but it is a good demonstration how subtle design differences can be used to transport additional information.

roof:shape based variants of bell tower depiction - with lattice construction on bottom and other constructions (including none specified) on top

roof:shape based variants of bell tower depiction – with lattice construction on bottom and other constructions (including none specified) on top

Symbol abstraction levels

With the tower symbols you can also see that i moved the design of some of the symbols away from the solid color paradigm in OSM-Carto to a shaded depiction. Original motivation was that the OSM-Carto symbols are too variable in visual weight – leading to the heavier symbol appearing as more important in the map than the lighter ones (without there being a good reason for that).

Substantially different visual weights of symbols in OSM-Carto

Substantially different visual weights of symbols in OSM-Carto

The other reason is that the symbol design paradigm of OSM-Carto currently puts a strong emphasis on geometric clarity and simplicity of shape – up to the point that the level of abstraction severely affects intuitive understanding. Adding shading to the symbol design, limiting the level of abstraction and allowing sub-pixel details to be used where helpful can aid substantially in resolving visual ambiguities and communicating additional information in very limited space. This of course increases the demands on symbol design work.

Shading is implemented without transparency using half-toning techniques.

Half-toning patterns to implement shading effects in single color symbols

Half-toning patterns to implement shading effects in single color symbols

Other engineered structures

Here are a number of further new symbol design either newly added or as replacement for existing symbols:

Various re-designed and added symbols for engineered structures

Various re-designed and added symbols for engineered structures

The non-solid, shaded symbol designs also give room to illustrate substances stored/processed by a feature through the use of color. This has to be done carefully because color is already used for differentiating different broader categories of symbol so adding more use of color in point symbols can severely reduce map readability.

Storage infrastructure symbols with different substances indicated by color

Storage infrastructure symbols with different substances/content indicated by color (with industrial background color)

Cranes are shown in different designs depending on crane:type:

Symbol variants for different crane types

And lighthouses are, by default, rendered without the light visualization – that is only shown with the appropriate seamark tags. And for non-continuous lights a subtle variation is used.

Variation of lighthouse rendering depending on seamark tagging

Variation of lighthouse rendering depending on seamark tagging

Petroleum wells

I also added display of petroleum wells (man_made=petroleum_well) in a design derived from that of water wells. Wells tagged with pump=yes are shown with a traditional oil pump symbol. Disused wells get a symbol variation and substance (oil or gas) is differentiated by use of color.

Petroleum wells - how they are shown depending on different secondary attributes

Petroleum wells – how they are shown depending on different secondary attributes

Planters

In terms of less technical features i added rendering of man_made=planter for both nodes and polygons:

Rendering of man_made=planter - mapped with node or polygon

Rendering of man_made=planter – mapped with node or polygon

The design for polygon is derived from that of retaining walls and is simplified for small geometries. In addition, i show a hint of a shadow towards the bottom right to show the elevated nature of the feature.

Benches

I am going to close this list of new symbol designs with another one i had already developed some time ago – a new design for benches.

Benches are rendered in OSM-Carto at z19 with a uniform symbol. I extended this both in terms of zoom levels and in terms of differentiation based on additional attributes – and with support for amenity=lounger in addition.

Rendering of benches at z20 - link goes to double resolution version

Rendering of benches at z20 – link goes to double resolution version – z19, z18

At z18 the benches are all shown with a uniform symbol just like on OSM-Carto – but significantly smaller. This is recognizable – yet small enough to not overcrowd the map at z18 in most cases. At z19, benches with backrest get differentiated – as well as loungers. They are still shown with a smaller symbol than in OSM-Carto. At z20 and above i then show the full size symbol with

  • three different symbols based on backrest=yes/no/unknown – the unknown design being inspired by Röntgen again.
  • heavier and less heavy symbols based on the material – stone, concrete and metal get the heavy design, wood and plastic the lighter one. This difference is very subtle to not limit the recognizability of the symbols to be the same type of feature in principle.

Real world examples

That were a lot of different symbols so i am not going to be able to demonstrate all of them in a real world context. So just a few select examples:

Planters and benches in Heidelberg, Germany at z18

Planters and benches in Heidelberg, Germany at z18

Water tanks on a farm in northern Italy at z18

Water tanks on a farm in northern Italy at z18

Cranes at the shore of Lago di Garda, northern Italy at z18

Cranes at the shore of Lago di Garda, northern Italy at z18

Harbor crane in Strasbourg, France at z17

Harbor crane in Strasbourg, France at z17

Water mill near Freiburg, Germany at z18

Water mill near Freiburg, Germany at z18

Benches in Lyon, France at z20

Benches in Lyon, France at z20

Silos in northern Italy at z19

Silos in northern Italy at z19

Petroleum well near Strasbourg at z18

Petroleum well near Strasbourg at z18

Discussion

I have presented here a large number of symbol design changes and additions. Many of them are not really revolutionary but rather simple. None the less i want – in summary – point out a number of patterns in those changes and lessons to be learned here.

Designing maps for a global audience is hard because many elements that are common in some part of the world are rare or even completely unknown in others. The most obvious example from what i presented above is the minarets. But there are other things where this applies as well – siren towers/masts or petroleum wells for example. Even something like a lighthouse will be familiar to people in coastal settings while fairly unknown for those living far away from the coast. Developing a good design for those depends on real world familiarity with the various settings where these things occur. That is why a map design project with global scope heavily depends on designers with diverse geographic and cultural backgrounds and familiarity with the global geography. While OSM-Carto aims in that direction i think i have demonstrated here a bit – in the past as well as in this post – how much the choices in OSM-Carto still reflect an urban/near urban European/North American perspective. This is of course not fully the fault of OSM-Carto – mapping and tagging in OSM itself still has a similar bias.

OSM-Carto has struggled not only technically with handling a huge number of different point symbol classes. The approach to add – one by one – new primary feature classes, each with an independently developed design, had reached its limit quite some time ago. I had already shown a number of techniques that can be used to overcome this problem in the past (see links above). Methods demonstrated here are in particular:

  • Aiming for depth instead of breath in terms of feature classes shown. Having recognizable base designs for broader categories of features and using subtle variations of symbols to differentiate further helps a lot in keeping symbology intuitively readable.
  • Using smaller and simplified symbols at the lower zoom levels can help to avoid having too much noise in the map while maintaining the in depth differentiation at the higher zoom levels.
  • Carefully using color for secondary differentiation (here: substance/content in storage structures) can help transporting additional information.
  • Shading and sub-pixel design in symbols can improve readability and allows additional differentiation of symbols with limited space.

All the changes presented here can be found in the AC-Style now.

October 25, 2024
by chris
0 comments

Is the OSMF not overly fond of OpenStreetMap?

Just wanted to share an observation about public communication of the OpenStreetMap Foundation from the last year:

OSMF vector tiles visualization

OpenStreetMap Foundation Membership Campaign map 1

OpenStreetMap Foundation Membership Campaign map 2

OpenStreetMap Foundation Membership Campaign map 3

What do these all have in common? That they are not based on OpenStreetMap data.

I have written about the practical problems of creating high quality small scale maps from OpenStreetMap data in the past – see for example here, here and here.

And i want to make clear that the fact that the techniques to use OSM data in such use cases are not in the repertoire of the OSMF is of course not the fault of those who take on the concrete task of producing these maps. What this demonstrates to me is yet another angle on the problem that map design and the needs map designers have to produce high quality maps from OSM data are essentially not on the radar of the Foundation (other angles discussed here and here). The main takeaway should be that this – among other things – leads to what can be observed here, that the OSMF as the organization whose self declared goal is to promote OpenStreetMap is not able to produce decent quality small scale maps using OpenStreetMap data for their public communication.

Rendering of point barriers

October 23, 2024
by chris
1 Comment

Point barriers

I recently worked on a number of map design matters in my OSM-Carto derivative, which i have not discussed here on the blog yet. Much of this is related to point symbols, with – so far – a thematic focus on human physical constructions of various kinds.

In OSM-Carto point symbol rendering got kind of stuck several years ago because we could not reach a consensus strategy on how to deal with a number of fundamental challenges we were faced with – both technically and design wise. I have shown here new methods to overcome these challenges. And i have demonstrated how these methods can be used to expand the differentiation of point features displayed while remaining intuitively understandable. In this post i want to further build on that.

The class of features i am going to look at is point barriers. I have worked on line barriers before – with more differentiated display and ground unit rendering and i have also shown visualization one specific point barrier feature (barrier=entrance) by modifying the display of line barriers and cutting out the entrance from those – showing the point feature purely through the modification of its context. In a similar fashion i have shown contextualized rendering of fords and mountain passes through local modification of the line signature of the road they are located on. And i have shown, among other things, use of symbol variations and context based adjustments for entrance nodes of buildings.

Point barrier rendering through pictorial symbols has been a feature of OSM-Carto since the beginning. The original implementation featured distinct symbols for barrier=gate and barrier=lift_gate:

Rendering of barrier=gate and barrier=lift_gate in OSM-Carto v1 (left) and in current version (right) - links to double resolution rendering

Rendering of barrier=gate and barrier=lift_gate in OSM-Carto v1 (left) and in current version (right) – links to double resolution rendering

These symbols have – with slight modifications – remained trademark features of OSM-Carto. And they have, over the years, been extended with additional symbols, mostly ad hoc and non-systematically, for other point barriers. This created several problems:

  • symbols are very inconsistent in size, sometimes in a counter-intuitive way so that larger symbols are used to depict physically smaller features than those represented by smaller symbols.
  • some symbols have an integrated white halo while others are plain color – leading to very different appearances on backgrounds of different color.
  • some symbols are hard to recognize in situations where it is not clear from context what they mean. This in particular applies to the cycle barrier symbol.
Various point barriers in OSM-Carto with counter-intuitive symbol sizes, inconsistent halos and frequently hard to recognize symbology

Various point barriers in OSM-Carto with counter-intuitive symbol sizes, inconsistent halos and frequently hard to recognize symbology

The lack in stylistic consistency is the main thing i intended to address. Beyond that i added more differentiation in terms of different barrier variants. I also introduced differentiation between restricted access barriers and those that everyone can cross freely for some barrier types.

I maintain the duality in symbol styles with some symbols depicting the barrier in question from top while others showing a profile view. This is hard to avoid since some types of barrier do not have a discernible visual footprint from top while others are most unique in appearance from top (like turnstile, kissing_gate). For the symbols showing the barrier from top i show the symbol rotated by 90 degrees depending on the context of line barriers and roads/paths at the barrier node. For small, pixel aligned symbols like these a free rotation is not possible without largely sacrificing readability. But a 90 degree rotation makes it often much easier to intuitively understand the symbol.

90 degree rotation of symbols according to geometric context, either barrier lines (left) or road/path (right)

90 degree rotation of symbols according to geometric context, either barrier lines (left) or road/path (right)

Here is the full set of new point barrier depictions at the different zoom levels.

New symbols for various point barriers in the AC-Style

New symbols for various point barriers in the AC-Style

The second symbol shown is either the variant for restricted access barriers (top part of the table) or the 90 degree rotated variant.

Many of the symbols have a slightly smaller variant used for the lower zoom levels and a slightly larger version shown on the higher levels

All symbols except those for bollards are consistently shown with a thin white halo that is dynamically generated during rendering.

Three real world examples for the new rendering:

Near Kenzingen, southern Germany at z17

Near Kenzingen, southern Germany at z17

Freiburg, southern Germany at z18

Freiburg, southern Germany at z18

Lago di Garda, northern Italy at z20

Lago di Garda, northern Italy at z20

Conclusions

I showed here how a consistent design paradigm (which builds on the original design concepts of early barrier rendering in OSM-Carto from more than 10 years ago) allows rendering a large variety of different point features with differentiated symbols while remaining largely intuitively readable. I demonstrated 20 different base classes of point barriers with 4 access restricted variants and 7 context dependent 90 degree rotated variants. Nearly all of these symbols, in addition, have a simplified lower zoom level design, in some cases aggregating several similar barrier types into one design.

Technically, this relies on the symbol and label rendering framework i had introduced in the AC-Style previously and that scales much better with a larger number of design variants than hand writing lengthy MSS as it is used in OSM-Carto so far.

October 17, 2024
by chris
1 Comment

A few additional comments on the new OSM-Carto release

We have made a new OSM-Carto release that finally includes a solution for one of our oldest issues – the access restriction rendering on roads. And i want to make a few additional comments here beyond what i wrote in the release announcement.

The issue in question had been open for 11 years and i already presented the timeline of that process in the development discussion:

So what can we learn from this and why did it take that long?

What takes time in map design?

First this timeline as i see it approximately reflects the relative amounts of work required for different tasks in practical map design that tries to be innovative and not just copies ideas and methods developed elsewhere:

  1. 50 percent of work is conceptual design work – a viable and well thought through principal idea how to show something and a conceptual sketch of how the rules need to look like to get from the data to that visualization is already half the way.
  2. 25 percent of the work is developing an initial concrete implementation of the conceptual design. Depending on the problem this consists mostly of algorithm development, symbol and color design.
  3. another 25 percent of the work is spend on refining and adjusting this initial implementation to the practical constraints of the concrete map. This includes technical optimization work, design adjustments based on user feedback and practical testing of the design in its cartographic context.

These percentages are under the assumption that the conceptual design work is of high quality. If it is not you will often end up not being able to finish the second step and need to go back and repeat the conceptual design work with the lessons learned from the unsuccessful first attempt. This is normal, even for experienced map designers. But it makes the whole process take much longer of course and you still end up with similar relative percentages.

The problem is of course that this is hard to sell. And this is not much easier in a volunteer community project like OSM-Carto than in a commercial project. I can’t count how many times i have seen comments on OSM-Carto of someone essentially saying: Just render it in some form, does not matter how.

So to be clear on that: Yes, you can follow that approach. You can essentially cut step 1, reduce step 2 to copying things from elsewhere and making random choices in colors. You will end up with something you might feel fine calling a map. But that is essentially just map design parasitism. Economically, this might even be lucrative because of the time saved. But intellectually and artistically this would be highly dissatisfying. Which is why i don’t think this would be viable as a guiding principle for a volunteer community project.

Attracting talented and skilled contributors

But all of that of course does not explain why it took 11 years for OSM-Carto to address this specific issue. In particular in light of the fact that, in contrast to other problems, this one was technically not particularly challenging.

The vast majority of these 11 years was of course not spend on actual work, most of this was essentially waiting for someone with the necessary skills and the interest in the project finding the time to work on this.

The bottom line is: The resources bottleneck of a community map design project like OSM-Carto is qualified map designers with the capacity and the interest to invest their time into the project. OSM-Carto has been better at this than many other map design projects in the OSM-Community because being the main map for the OSM-Community is a huge incentive for contributors.

But – as i have pointed out in the past – we, the OSM-Carto maintainers, have over many years failed to provide talented and skilled map designers an attractive environment to contribute. The ability to do conceptual design work on concrete cartographic problems depends on there being a clear overall strategy for the map as a whole and we have not been able to agree on such a strategy for OSM-Carto for a long time now.

The other factor is the social context of the project. How non-technical work (which – as outlined above – is more than half of map design) is valued and appreciated in the larger OSM-Community has a huge effect on how much talent and skill in map design OpenStreetMap can muster overall. I have pointed out in the past as well that the OSM-Community is severely lacking here. We have a lot of contributors who show significant latent interest and often also talent in that field but do not find a nurturing environment to develop those.

Conclusions

The bottom line is: There is immense (i would go as far as saying globally unique) potential in the OSM community for talent, skill and interest in high quality map design with a broad range of cultural backgrounds. That potential is currently largely unused because:

  1. Community map design in OpenStreetMap, above all OSM-Carto, lacks the ability (in terms of the human ressources capacity, in terms of the technical tools and – in case of OSM-Carto – also in the form of a common strategy and vision within the project) to provide those people the supportive environment they need to develop their abilities.
  2. The OSM community collectively under-values map design and under-estimates the significance of the ability of OpenStreetMap to be innovative and actively shape the state of the art in that field for the long term future of the project. As a result people do not have the impression that investing in community map design in OpenStreetMap is worthwhile either socially or in terms of their own cartographic ambitions.
OSMF board elections 2024 - delving into the post-truth era?

September 29, 2024
by chris
4 Comments

OSMF board elections 2024 – delving into the post-truth era?

The elections for the board of the OpenStreetMap Foundations are upcoming and the most interesting part of this for the OSMF members has traditionally started with the publications of the self-presentations of the candidates, which happened during the last days.

My impression after the first reading of these is that the OSMF seems to have arrived in the post-truth era. Some might claim this has already happened years ago, but to me – and i have been a keen observer of the OSMF for many years now – it became obvious with this year’s election.

The concept of post-truth does not mean the communication of lies or untrue statements, it refers to the trend of defactualization, where the distinction between false and true becomes meaningless in communication and discourse in a certain social context.

There is an euphemism for this style of defactualized presentation commonly used in corporate PR and marketing these days, that is storytelling. The aim here is to create a certain impression or emotional reaction from the recipient of the communication largely sidestepping the facts surrounding the topic. Or in a nutshell: If the story is compelling it does not matter if it is convincing.

The irony is that originally, the term storytelling referred to something rather different: The development and communication of fictional stories either for the purpose of transporting abstract philosophical ideas and moral values in a practically robust fashion in a culture without writing or for the purpose of communicating ideas and thoughts that are subject to social taboos or otherwise not socially accepted in a non-fictionalized form.

My suggestion to the OSMF members for this year’s board election is therefore: Read the self-presentations of the candidates as fictional stories – like fairytales, mythology etc. And do not regard what you read there as propositions in the philosophical sense. If you do so i think you will be able to derive much more of value from your reading. If that is then helpful for your voting decision is a different matter of course. But you will definitely spare yourself some of the pain i had in my first reading of these.

I had considered analyzing this year’s board candidates’ self-presentations for examples of post-truth era communication techniques. But that does not seem right to me. After all it is not the candidates that are to primarily blame here. It is the OSMF members who are – collectively – too passive to set a higher bar for the candidates they elect for the board. But more than that: I also have the impression that quite a few OSMF members have fully accepted the end of history and simply can’t imagine a different kind of candidate. To use an old metaphor: They drink the sand because they don’t know the difference.

For those i will try here – in the tradition of storytelling in the original sense – to tell the story of a fictional board candidate who stands in contrast with the largely defactualized self-presentations we are seeing in this year’s election.

Manifesto

Dear OSMF members,

i am not actually a candidate in this year’s OSMF board election. Nor am i actually a real person that exists outside the mind of my creator, the author of this blog post, and the minds of you, esteemed readers of these lines. None the less i hope that my fictional candidacy in this year’s election inspires you to imagine the idea that some actual candidates might articulate and pursue some of the thoughts i present here in my fictional candidacy with the same clarity and determination as i do.

Feel free to customize the image that my creator has produced in these lines to your cultural or personal preferences and expectations.

Motivation and Objectives

What i hope to accomplish during my time on the OSMF board i am going to outline in the answers to the questions provided. The reason why i make these things my objectives is because, after years of observation and contemplation, i have come to the conclusion that these are crucial for a sustainable development of the OSMF under the goal of supporting the OpenStreetMap project. I am aware that the practical pursuit of many of these objectives is likely going to see opposition from substantial economic interests around the OpenStreetMap project. If i succeed in pursuit of these will depend on your support and that of the rest of the OSM community. I am going to do my best to accomplish these objectives within the OSMF board, but especially in the long term i will only be successful in that if i have active support for that from the OSMF members and the OSM community.

Conflict of Interest Management

First of all i reject the premise of the question that Conflicts of Interest are something that can be universally managed or mitigated without actually addressing the Conflict of Interest itself.

My personal situation allows me more than many others to pursue the interests of the OSM community even if they are in conflict with weighty economic interests around the project. I am not rich by any measure but my livelihood, my professional career and my personal goals are out of reach for even the most influential financiers of the OSMF or of economic interests around OpenStreetMap. So, even if those would want to put pressure on me personally to put their interests above those of the OSM community, the possibilities for that are very limited.

That being said there are, of course, going to be situations where i am going to have Conflicts of Interest in my work as a board member. I hope that i am going to be able to identify such situations myself in most cases. But i am aware that i cannot expect this to work reliably in all cases, so i will need to resort to other mechanisms as backups, which i will discuss in a second. Before that i am going to outline the three measures i expect to consider when i have become aware of a Conflict of Interest as a board member:

  • Selectively removing myself from the part of my work as a board member where i have the conflict. This only works in cases when the work in question, as well as the Conflict of Interest, are tightly limited in scope. In case of any kind of decision making, removing myself would mean both from the actual formal decision and the complete deliberation process leading up to the decision.
  • Temporarily suspending my work as a board member altogether. This only works in cases where the Conflict of Interest in question is inherently limited in duration.
  • Resigning my position as board member. This is always the ultimate fallback option in cases of Conflicts of Interest where no other measure can reliably ensure that the secondary interest does not affect my work as a board member.

All of these three options are going to be on the table whenever i become aware of a Conflict of Interest as a board member. I am going to transparently and publicly document the reasoning behind my decision of what measure to choose in any such case, so that the OSMF members have the opportunity to check on that reasoning and – if necessary – take the appropriate steps to insist on a different option.

Now back to the problem of reliably identifying Conflicts of Interest. The history of the OSMF board has shown beyond doubt that self-identification does not reliably work and even cross-checking among the board members does not, because the other board members are either equally unable to see the conflict or feel socially inhibited to openly point out the conflict of another board member (see here, here and here.

Therefore, other mandatory mechanisms will need to be introduced and this is going to be one of the things i am going to pursue as a board member. Transparency in decision making processes is going to be a key element of that (see next question). Beyond that, i concretely envision to suggest the following measures to the OSMF membership as binding to the board in their work:

  • Creating a mechanism by which decisions in which a Conflict of Interest has been overlooked are automatically nullified.
  • Introducing mandatory formal reporting of any Conflict of Interest identified as such by a board member to the OSMF membership.
  • Creating a mechanism by which Conflicts of Interest can be reported anonymously by any OSMF member.
  • Creating an oversight mechanism (ethics council) formed by the local chapters that oversees the board’s work with regards to Conflicts of Interest and that reports their findings to the OSMF membership as an additional control mechanism.

Transparency and Accountability

Transparency and Auditability of the work of the OSMF have seen a massive decline during the past years relative to the state after the transparency initiative of the 2015 board:

  • While originally all of the board meetings were public, the meetings are now split into private mid month meetings were actual deliberation of decisions seems to take place and the public meetings where formal decisions are still made but in depth discussion does not typically take place any more.
  • Policy document drafts are now routinely published only in the last minute before the formal decision (either during the meeting or in the day before the meeting) depriving the OSMF members from the possibility to review them and provide input before the decision. This communicates substantial disrespect from the board for the OSMF membership.
  • While some years ago the OSMF board routinely discussed policy development with the OSMF membership at an early stage (both on the board and on members’ initiative) this has almost completely stopped. And if the membership is consulted at all, it is usually about approval of a final draft as a done deal after the main deliberation has already happened in private.
  • The board does not seem to be bound by their own policy – for example the commitment to open channels is rather loosely interpreted – see here.
  • The board’s main method of internal communication and deliberation seems to have moved from channels with a permanent record (email) to volatile channels (IRC/Matrix) preventing both independent auditing of the board’s decision making and the board’s own ability to look up the genesis of past decisions.

This is a highly problematic trend on multiple fronts – in terms of oversight and dealing with Conflicts of Interest (see previous question), in terms of recruitment of competent volunteers (if no information is visible from the outside that massively steepens the learning curve for everyone who wants to get involved because they can only access pertinent information after they have become part of the inner circle) and in terms of public communication (transparency by default spares a lot of work in explicitly and selectively communicating only what is meant to be known to the public). Also the compartmentalized information management in the current OSMF stands in sharp contrast with the way the OSM community communicates otherwise, which creates a substantial culture gap between the two.

As a board member i am going to

  • make sure the OSMF board moves back to channels with a permanent immutable record for internal deliberation by refusing to participate in non-public inner-board communication on channels without such record. The need to be able to look up and refer to past communication in deliberation of the board is so obvious that i feel forcing the hand of the rest of the board this way is warranted.
  • start publicly reporting on developments in the board as soon as they happen even if they would otherwise not be known to the public at that time. I am not going to disclose content of communication without agreement in the board of doing so, but i believe that the OSMF membership and the OSM community as a whole – who the board is meant to serve – have the right to know for example when the board starts to draft policy affecting the OSM community or starts discussing to contract someone to do certain work for the OSMF and i don’t think, as an elected board member, i would be infringing on anyone’s moral or legal rights by reporting in a timely fashion about such things happening as they do.
  • present and argue for the advantages of a public-by-default approach to board work with the other board members and attempt to roll back the roll back of the transparency of board work of recent years. I am aware that this might be an uphill battle against an existing organizational culture of compartmentalization. But the benefits of a more open work culture are difficult to ignore.

Strategic Vision and Sustainability

The strategic planning initiated by Allan Mustard in the OSMF was a significant step and it could have been a good starting point for further work in that direction despite some shortcomings. But what the board then made out of this ambitious start, by essentially removing all the clarity and stringency in the original document and replacing it with soft and vague expressions of wishes, amounted to nothing less than moving back to the muddling through the plan originally aimed to overcome.

As a board member i would aim to re-initiate the strategic planning process, starting with the original work of Allan Mustard. I would aim to

  • Fill the thematic gaps and omissions in the original plan.
  • Move the discussion of further development to a public venue, giving all interested community members the opportunity to read and provide feedback and inviting people with experience in specific fields to provide advice (in public to provide checks and balances against lobbying for special interests).

But i would in particular aim to introduce a strict subsidiarity principle into the strategic planning of the Foundation. The OSMF should not pursue tasks that can be equally or better handled on a local level or by thematically more specialized organizations. The OSMF needs to focus itself on its core functions as outlined by the OSMF mission. This is more than enough of a challenge with the continued growth of the project.

I also consider a move of the OSMF to the EU a strategic necessity, as well as a chance to restructure the organization in a more robust and more scalable way. The necessity stems from the legal protection of the OSM database under the ODbL, which is based on European database rights. And the move would provide the chance to design a new organization with proper formalized checks and balances, because it would not be subject to the tight constraints of UK corporate law. I envision a structure where the operational management of the organization and policy development are separated and where the local chapters have a formal role of oversight over key aspects of the organization (like decisions about the rights to the OSM database, trademarks and the mapper accounts).

The steps taken by the OSMF board so far regarding a move to the EU seem to suffer from a lack of transparency in decision making. In particular the choice of countries to consider moving to seems to be based on behind the scenes lobbying of special interests, rather than an open and transparent selection process. And it also suffers from the lack of ambition with regards to restructuring the organization. As is it seems likely that the board would try to copy the highly disadvantageous structure of the existing OSMF as required by UK corporate law into the EU and this way miss a huge opportunity that is likely never to come again. Bottom line: I think the whole process needs a restart with a more transparent process and a broader discussion how the new organization should be structured.

Decision-Making and Collaboration

I do not plan to collaborate with anyone during my time on the board, but I hope to cooperate successfully with my fellow board members, with the working groups, with the OSMF membership and with the OSM community as a whole. The key to successful cooperation is a basis of shared goals and values to start from. In the case of OpenStreetMap, this cannot be shared cultural values but has to be the basic ideas and values of cooperative collection of local geographic knowledge. Everything else (like the traditional OSMF mission and its interpretation) needs to derive from that. If there are disagreements in the OSMF about how to practically pursue the OSMF mission, i would try to solve that through arguments and reasoning with regards to the basic ideas and values of OpenStreetMap. In other words: I would ask others to try to convince me that what they suggest is in support of these and i would try to convince them that what i suggest is beneficial in that regard.

As far as the organizational structures within the OSMF are concerned – i think the original idea of largely independent working groups is very good. But the board has, in recent years, substantially crippled their development by frequently interfering ad hoc with their independence and by creating board committees with non-board members as a competing, less independent but much more favorably treated organizational structure. This whole concept needs to be re-considered together with reducing the scope of the OSMF’s own activities in favor of the local chapters.

What would definitely end with me on the board is the current practice of keeping inner-board conflicts and disagreements under cover and the attempts to hide such from the membership. This is not a good way of dealing with disagreement and such pretense damages the credibility of the board as a whole to the outside.

Fundraising and Resource Development

According to the self-presentation of the current OSMF in public, fundraising seems to increasingly turn into a goal on its own. That is not a good development. The expenses of the OSMF have quite significantly increased over the past years but the level of actual internal organization of the Foundation has not kept up with that. And that is not a problem caused by the lack of money, it is caused by the lack of determination in ending the muddling through that Allan Mustard has rightfully criticized in his sketch for a strategic plan. If the OSMF would try to address this by raising and spending additional money (or in other words: try to outgrow the problems through financial expansion) the result would be an organizational automaton the de-facto primary goal of which would be to sustain itself and grow as an organization, meaning raising funds for the main purpose of continuing to raise funds.

As a board member i would aim to follow a different approach. I would try to consolidate or even reduce (based on the subsidiarity principle, by ending the OSMFs involvement in activities that are outside its core functions) the current operational scope of the organization and focus on putting that scope on a more solid and robust basis. That involves in particular

  • developing, consolidating and publishing internal policy that is binding for everyone regarding the routine operational activities of the organization. In other words: Writing a comprehensive OSMF handbook covering the current operational scope of the organization.
  • detailing the strategic planning to the level that it provides clear guidance to all the operational activities.
  • opening up to the wider OSM community in operational activities and strategic planning and making supporting the OSMF through volunteer work attractive again for intrinsically motivated grassroots volunteers without a professional motive.

Of course, even with this approach followed with determination, the OSMF will need continuous fundraising to sustain itself. The goal here needs to be IMO to better diversify the funding. I would try to establish the following goals:

  • No more than 10% of the OSMF’s income should at any point of time come from a single source (and indirect funding via proxy would need to be considered here of course)
  • No more than 30% of the OSMF’s income should at any point of time come from a single country (again with indirect funding through dependent organizations in other coutries considered)
  • No more than 30% of the OSMF’s income should at any point of time come from a single thematic class of financiers (currently for example digital technology companies could be a class where this is potentially an issue)

Accomplishing these will likely require cooperation with local chapters around the world. The OSMF therefore needs to find a sustainable way to handle the competitive situation with the local chapters with regards to funding. The idea currently pursued to incentivize a funding dependency of the local chapters on the OSMF by trying to take a proxy and gatekeeper role between big corporate financiers and the local chapters is a very bad one in my opinion. The opposite approach would, in my opinion, be better with the local chapters being the direct contact with local financiers of OpenStreetMap and handling the local financial bureaucracy. This would also conform with the subsidiarity principle i dicussed above, while the current approach does not.

Handling Legal and Political Challenges

A thorough assessment of legal risks faced by the OSMF is quite clearly long overdue. This should be combined with the development of mitigation strategies that avoid the possibility of core assets of the OSMF (the database rights, trademarks and mapper database) to be at risk in case of serious legal challenges. Ideas for that can be implemented in the course of a move to the EU as sketched above.

On the political front, the OSMF still has a lot to do to repair the damage incurred by the infamous Crimea decision in 2018 (where the board overruled standing OSMF policy, community consensus and the data working group in an attempt to pacify some loud voices articulated in the OSM community and political pressure). The board needs to actively reaffirm standing behind the core principles of OpenStreetMap in documenting the observable reality on the ground – even in cases where this is politically not fashionable. A consistent stance based on clear and broadly supported principles in the long term is a much better defensible position than opportunistic adjustment to the wind direction of the day.

State of the Map

The operational planning of the State of the Map conference should remain at the discretion of the SotM working group and i would, as board member, oppose any attempt of ad hoc interference with that as it happened in the past. Strategically, i would encourage the SotM working group to develop the concept of the State of the Map conference in the following directions:

  • supporting predominantly regional conferences in a rotating fashion rather than moving an international conference around the world. This would IMO be more suitable to celebrate the cultural diversity of the OSM community world wide.
  • developing concepts of a decentralized conference with different local meetings of people connecting digitally to the event.
  • developing asynchronous formats where people can watch presentations at a daytime of their chosing and asynchronous discussion afterwards takes place between presenter and audience.

And to be clear: The OSMF cannot and should not aim to ensure that the conference is safe and accessible for all members of the global community. That idea would be completely impractical if global community really means global community – and it would be morally highly questionable if global community means only the wealthy international OSM jet set. The OSMF should be open to support an international conference in any part of the world where there is an active local OSM community willing and able to organize such an event. If, in some years, that happens to be in places which most people from Europe and North America practically won’t want to or are not able to visit, that is to be accepted.

Your Community Contributions

I have contributed to OpenStreetMap on various levels – in mapping, in tagging discussions, in software development, in map design and in public communication to name the most important. But i have no strong focus on any of these fields in particular that would put me at risk of aiming to cater the specific interests of that field.

I have also followed the development of the OpenStreetMap Foundation for many years as far as this is possible from the outside as a normal member who is not part of the inner circles. And i have frequently talked to board members during that time about the OSMF. But i have never been involved in the OSMF myself beyond being a member – hence it is safe to say i have never been socialized in the organizational culture of the OSMF. This gives me a relatively well informed outside perspective.

I am not a native English speaker and besides my native language and English i also have basic knowledge of another language with wider use across different countries (like French, Spanish, Russian, Arabic, Chinese – pick whatever you like most). This helps me realize that by limiting your horizon to English language only (like the OSMF mostly does at the moment) you miss out on significant cultural diversity and loose immense opportunities. This is why the OSMF urgently needs to start embracing more diversity in languages in its organization. That is a challenge practically, but IMO also a strategic necessity.

Promoting Community and Attracting Volunteers

Recruitment of qualified and intrinsically motivated volunteers has become a big problem for the OSMF during the past years. The OSMF has alienated a lot of highly qualified long term volunteers from the OSM community over the past years through the principle of people whose work we know and enjoy as a recruitment paradigm for both paid and unpaid work in the OSMF assigned by the board. This not only urgently needs to end, the OSMF board needs to take substantial steps to win back credibility with the larger OSM community where the do-ocratic principle is highly valued.

The OSMF also has a lot of homework to do with regards to inclusivity. Getting involved in the OSMF without substantial English language communication ability and without embracing the OSMF organizational work culture is next to impossible. And people usually don’t even have the chance to get a good idea of these requirements before actually taking the step to get formally involved because most of the OSMFs activities happen behind closed doors and are only accessible to those who have decided to get formally involved. That is literally the opposite of being welcoming.

Due to the independence of the Working Groups (which is important to hold up) the board has only limited ability to directly top-down change this situation. But we can lead by example and provide helpful recommendations and organizational support for the working groups to reduce the barrier to get involved as volunteers.

There are a number of concrete steps i would like to pursue in that regard as board member.

  • Set up a place where work for the OSMF that can be independently pursued by volunteers is openly advertised for community members to take on without a formal barrier. This of course will require more real time transparency in the work of the OSMF in general (so people understand the context of these tasks). Initially that would be for tasks created by the board but the idea would be that this approach could also be adopted by the working groups.
  • Move more active work from the OSMF website (with top-down control of editing rights) and elsewhere to the OSM wiki (where all OSM community members can get actively involved)
  • Being more transparent in all practical board work as this reduces the barrier and increases the incentive to get involved.
  • When consulting the larger community in a formal or informal way specifically inviting and valuing critical and inconvenient comments and reactions.

The real challenge is going to be breaking the English language dominance. I have no definitive approach how to tackle this at this time. But not accepting the currently dominant paradigm that the English language dominance is inevitable is a start. Revising the so called diversity statement in that matter would be a symbolic first step.

Technology and Innovation

OpenStreetMap relies heavily on technology but is not a technology project itself. That is important to keep in mind for the OSMF. So technology for the OSMF always needs to be a means to the end of supporting the cooperative mapping efforts of the OSM community, not a goal on its own.

The OSMF needs to keep a close eye on the technologies OpenStreetMap relies on in its core functions and their development. But in doing so we also need to keep in mind the basic principle to support, but not to control the project. It is highly doubtful if the OSMF taking over the development of some core tool in operation of OpenStreetMap by paying a professional developer would be of long term benefit for the project. OpenStreetMap has, over its history, so far been able to attract and motivate the developers of the technology it relies on on the operational level and the OSMF’s role here should be to ensure it continues to do so, not to become a substitute motivator.

Beyond these fundamental operational needs lies the field of strategic investment into technologies needed in the long term by the OSM community. The focus of the OSMF board here should lie in supervising and guiding the strategic planning in that regard to provide the necessary guidance for the Engineering Working Group in practical implementation of these strategic investments.

Since strategic investments in technology typically have a significant size, there is going to be a necessity for the OSMF to pursue cooperation with other organizations – like OSGeo, or academic institutions as far as fundamental technological innovations are concerned, or other potential users with overlap in strategic needs.

My own first focus as a board member in this domain would be to keep a careful eye on how technological decisions affect the OSM community on the social level. The important thing here is that technology should have the function to support the OSM community in their needs and their consensus decisions. The technology should not be used to steer the OSM community in a certain direction and it is the board’s task to ensure that this does not happen under the aegis of the OSMF.

My second focus would be to ensure that the decision of where to strategically invest the limited means of the OSMF is not primarily guided by lobbying interests of parties who want to profit from the investment, but by a careful and neutral look at the actual strategic needs of the OSM community for its work. Doing the strategic planning in that regard publicly is going to be key to accomplish that.

Data Quality and Protection

We have here the two fairly separate fields of vandalism (i.e. malicious actions) and quality assurance (i.e. the concern about the quality of well intended edits of the data). The first field is handled on the operational level by the working groups, the board should not get involved here. It would be important to give this point substantial consideration in the strategic planning and to involve the concerned working groups in strategy development there.

Regarding quality assurance – this is primarily a matter for the mapper community and the OSMF should not get involved here beyond this potentially being part of the strategic investment in technology (see previous section). One exception: If quality issues are directly or indirectly caused by organized mapping activities. Here adjustments of existing regulation or new regulation could be required in the future.

I see no acute need for adjustments in policy here, but the current organized editing rules have been in place for quite some time now without changes. So one thing i would do as a board member is to initiate a comprehensive review of the organized editing policy and evaluate the need for adjustments. Quite a bit of research has been published during the past years on organized editing in OSM so there is a substantial data basis for such a review. This data should be supplemented by direct input from local mappers regarding the effects of organized activities on their work.

Perspective on Open Source

The fundamental idea of OpenStreetMap is directly tied to the idea and the philosophy of open data, which in turn is closely related to the idea of free open source software and open technology in general. So, as far as the technology the OpenStreetMap Community relies on in its basic work is concerned, the need for this technology to be open is pretty much a given (although, to be accurate, that principle currently largely ends when it comes to hardware technology).

How the OSMF manages its membership database is fairly unrelated to that so you could argue the same principle does not apply here. But the OSMF has a FOSS policy and that derives not only from the philosophical connection between open data and free open source software, but from practical considerations as well. It is practically beneficial for the OSMF to use FOSS rather than proprietary software for multiple reasons

  • it is less costly because you avoid license costs.
  • it avoids creating a dependency on a proprietary software provider.
  • it has security benefits since you don’t need to run code that you can’t inspect (in particular relevant for use cases involving sensitive personal data).
  • it massively lowers the barrier for volunteer involvement because volunteers can use the same software independently without a license cost hurdle.
  • it creates an additional incentive for volunteer involvement because volunteers can get practice in using software that they can then also use otherwise without additional license costs.

In the specific case of the task of managing the OSMF membership database the following additional argument applies:

As far as i understand it the incident that triggered the recent discussion was caused by a change in the membership signup process being deployed without proper testing – which would have revealed the problem. Such testing is much easier to organize in a volunteer based project if no proprietary software is involved because any volunteer could perform the testing on their own infrastructure independently while with proprietary software licenses the testing would either need to happen on OSMF infrastructure or the tester would need to be contracted by the OSMF (depending on the terms of the license). In other words: FOSS solutions are much better compatible to the openly cooperative and decentralized work culture of the OSM community than proprietary solutions.

The bottom line is: I see plenty of arguments that speak for continuing to use FOSS solutions in managing the OSMF membership database and none that speak for a proprietary solution.

Perspective on Overture Maps

Overture Maps is essentially an OSM data user like anyone else. What distinguishes them from other data users is that their aim is to re-distribute OSM data in a modified form on a large scale – something that is rare among commercial OSM data users so far.

For the OSMF it is important to treat them like any other data users. That means watching over their compliance with the ODbL. Since they distribute combinations of OSM data with other data this in particular concerns the share-alike rules of the ODbL. These have been neglected in the guidelines regarding the ODbL developed by the OSMF so far and it might be advisable to fill that gap.

And we should communicate to them clearly and openly that we expect them to support the project the data of which they use extensively by the Linux foundation becoming a corporate member of the OSMF. Similarly, we should of course look into contacting large scale data users who use OSM data through Overture and equally suggest them to support OpenStreetMap as the original source of the data they use.

Conclusion

That ends the presentation of my fictional candidacy for the OSMF board election. If you like what you have read then don’t vote for me – because you can’t. Instead you should get out of your mapping armchair and start working towards what you like in what i presented above. The truth is that the OSMF will not change for the benefit of the OSM community unless the OSMF members push it with determination to do so. So if you find my analysis of the situation of the OSMF and the suggestions i derive from it convincing on any of the topics discussed, then it is up to you to pursue these ideas. Because no one else will.

Weaving roads #3 – discussion

September 17, 2024
by chris
1 Comment

Weaving roads #3 – discussion

Since the previous two blog posts are already quite lengthy as is, i am going to do the overall discussion in a separate post here.

I discussed the situation of road rendering in OSM based maps in general already in earlier texts so here as a brief summary only:

  • OSM-Carto uses – among dynamically rendered OSM data based maps in practical operation – the most sophisticated system of road display and still substantially falls short currently of consistently displaying the road layering.
  • What i introduced 3.5 years ago goes significantly beyond that, but neither this concept nor anything else implementing a comparable functionality has made it into operational maps.
  • What i showed in the previous post here takes a step further by offering options to do selective styling and drawing order adjustment, based on geometric context rather than only feature attributes.

Rendering with the changes shown here

Rendering the AC-Style so far

Rendering in OSM-Carto

The bottom line is: While i further expand the design options available in road rendering with this demonstration, we are certainly pretty far away from such sophistication making it into mainstream maps. And, as hinted at already in the previous post, the lack of meaningful visual feedback on the mapping practice in layered road networks, including polygon features, has a significant impact on mapping. It is clear from the data that mappers have a strong interest in recording relevant information in this domain, but the complexity of this in multi-layered structures, like subway stations, makes this very hard to do well without good visual feedback. And QA tools and specialized indoor map apps allowing per-layer display of such structures (which exist) cannot fully replace this.

Or in other words: The lack of progress in improving road rendering in mainstream maps during the past 5 years seems to be significantly holding back also improvements in mapping in that field.

One important question is, of course, if there are other viable approaches for implementing the kind of rendering i show here. And the answer is yes. I already hinted at that in the first part. You can split the linear road geometries into those parts within and those outside of road polygons and render them differently based on this differentiation. You will then, however, have a serious problem at the edges to ensure the roads stay continuous where they are artificially split despite both parts being treated differently in terms of drawing order. Ultimately, you would be substantially constrained in your design options for drawing the roads – which you are not with the approach i showed.

The other important thing i want to mention is that the additional sophistication in styling, modifying the rules in areas of road polygons, can also make the map more difficult to read. The mere fact that underground structures are shown that are otherwise hidden, the deviation from the physical drawing order and additional styling variations – like i show for road polygons overlapping road polygons – can all contribute to that. The challenge for map design here is to avoid this leading to a negative net benefit for the map reader.

Outlook

As already mentioned, what i showed here is essentially just a proof-of-concept. So far it only deals with surface level road polygons. I also have not looked much at the styling of underground roads – this is definitely a field that requires a closer look since many of the tunnel road signatures are too heavy for a well readable display in areas with a dense underground network. Especially also ground unit rendering needs to be considered again in that context. Not to forget the labeling – which is working quite badly at the moment.

And of course the Mapnik extension of per-layer post processing with GMIC has a lot of potential applications beyond what i showed here. It implements point 7 on my list of features rule based map design requires from the tools it uses on the layer level. Offering the same functionality on the feature level would be very nice and useful (for example to extend what i have shown here to non-surface level road polygons). But it is much harder to implement, because it requires delving into the details of AGG. And it also would likely have much stronger performance implications.

Weaving roads #2 – creative compositioning

September 15, 2024
by chris
1 Comment

Weaving roads #2 – creative compositioning

In the previous post i explained one of the main design issues of road depiction in OpenStreetMap based maps and identified the most viable approach to address this. Here i want to demonstrate and explain how this can be practically done.

Just like in the case of viewpoint rendering i discussed earlier, this requires extending the functionality of Mapnik. If you want to re-produce what i show here you will, therefore, need to build Mapnik yourself using the modifications i have published.

To recapitulate – the problem i intend to address here is that in normal road rendering, the roads (including road polygons, like pedestrian areas) are rendered above linear features like waterways. Therefore, those line features do not render properly, even if they are diligently cut out in mapping from the road polygon (which – according to broadly established mapping conventions – is not strictly necessary). Also, road tunnels are fully covered underneath larger road polygons, which hides important information on underground road and path connections from the map user.

Current layering of pedestrian road lines and polygons relative to other road and line features

Current layering of pedestrian road lines and polygons relative to other road and line features

We want to address these issues without actually changing the road drawing order overall. Linear road tunnels are still supposed to be rendered below linear surface roads and linear road bridges above them. And surface roads, as well as tunnels and bridges of the same layer, should remain visually connected to one another to correctly communicate the connectivity in the roads system.

Impossible waterfalls

Working this problem is a bit like drawing an impossible waterfall like the one in the famous drawing by M.C. Escher.

M.C. Escher: Waterfall, 1961

M.C. Escher: Waterfall, 1961

This kind of drawing is consistent in the 2d depiction sketched and locally consistent also in three dimensions. It, however, becomes self contradicting and physically absurd in total. Therefore you cannot create this kind of drawing strictly from physical principles alone, you have to explicitly break with these principles. The challenge is to do so in a way that remains locally consistent.

The map rendering task at hand is similar, what we need to explicitly break with is the strict adherence to the vertical order of features in drawing and the rule that the styling of a feature is only defined by its own attributes. And we want to – as much as possible – maintain local consistency in drawing, giving the correct impression about connectivity and vertical order of features in reality.

This is a fairly complex task so i limited my proof-of-concept here to just the surface level road polygons. For the bridges and tunnels the setup presented here would essentially need to be duplicated once more for every layer (because for each of them a separate set of linear road features will need to be treated specially). Since bridge and tunnel road polygons are rare and large ones substantially covering other roadwork are even less common this limitation is practically not very big.

What we will need to do is rendering some road features (specifically road tunnels and linear features otherwise drawn before the road layers) differently when and for the area where they would normally be covered by a surface level road polygon. The procedure to do that is:

  • Render the road layer as usual with the drawing order chosen according to the vertical oder of elements in reality as tagged, including the surface level road polygons.
  • Render separately a second version of the road layers without the surface level road polygons.

    the linear features that are visible in this version because they are not hidden by the road polygons need to be drawn here in the design in which they should ultimately show up above the road polygons. The layer implementing this is called roads_noareas.

  • Render a mask of the line features that are to be shown like in roads_noareas in the area where they are normally covered by the surface level road polygons. The layer implementing this is called roads-line-mask.
  • Render a mask of the surface level road polygons visible in the standard road display. That is essentially the surface level road polygon footprints minus the bridge road polygons. The layer implementing this is called roads-area-mask.
  • Combine these four renderings by composing roads_noareas over roads only in areas covered by both roads-area-mask and roads-line-mask.

Advanced compositioning with GMIC

This is currently not possible to do with the rather limited compositioning capabilities of Mapnik. The only thing Mapnik can do out-of-the-box is composing what is newly drawn (either on the feature or on the layer level) with what has been previously drawn in a two component compositioning operation. The kind of multi-component compositioning operation described here is not available.

To overcome this i added support for raster post processing of the rendering using the GMIC image processing framework to Mapnik. GMIC is doing image processing using a dedicated scripting language. This framework can be invoked for every layer of the map style in addition to Mapnik’s internal per-style compositioning operation, either before or after. GMIC perfoms its processing based on an image buffer stack. The way i integrated this framework into Mapnik this stack is retained between layers with the current layer (either before or after Mapnik’s internal compositioning) being added to that stack for further processing.

To understand how to make use of that feature it is useful to understand how Mapnik does its own per-style compositioning. If you don’t use either style level opacity or comp-op (meaning no opacity or comp-op being set for the whole layer in Carto-CSS) Mapnik plainly renders everything into a single rendering buffer one element after the other. If opacity or comp-op is used Mapnik renders the layer into an empty (i.e. originally fully transparent) buffer and then composes this into the buffer retained from the previous layers using the chosen opacity and comp-op. If you use the new gmic style property the compositioning is automatically activated as well, the layer is rendered into a new, empty buffer and that buffer is then added to the GMIC image buffer stack. Afterwards the script specified in the gmic property is run.

But by default nothing is composed into the main rendering buffer. For that to happen the script has to assign the name use to the last image buffer in the stack. Then Mapnik uses this buffer as the source for drawing the layer (potentially using the specified comp-op/opacity) and removes it from the GMIC image buffer stack for the next layer. In other words: the no-op GMIC command is (in CartoCSS syntax)

gmic: '-name. use';

To store the rendering of this layer for use in processing one of the next layers in addition to using it as is you can use

gmic: '+to_rgba. -name. use';

which duplicates the last image on the stack (the current layer rendering) into another rgba buffer and then sets that up to be used. Since only the buffer used will get removed from the stack by Mapnik, the second version of the current buffer will remain for later re-use. Finally, if you just want to store what has been rendered for future use and not directly use the current layer at all, use something like:

gmic: '-to_rgba.';

This converts the last buffer in the stack to rgba – which it already is, hence: it essentially does nothing. Since the name of the buffer is unchanged, Mapnik will neither remove not use it and will simply move on to the next layer.

The other important thing to know is the naming of the buffers. All buffers added by Mapnik are named after the layer they are generated from – with any dash (-) in the layer name being replaced by an underscore (_) since dashes are special characters in the GMIC scripting language.

This whole principle of operation is just designed as i saw it fit for the moment – it is highly probable this is not ideal and needs adjustment in the future.

Back to the actual problem: The normal road layer (roads) and the second variant without the surface level road polygons (roads_noareas) are rendered from the same SQL code and share most of the CartoCSS code. The roads layer is rendered normally, for reference: here is how the rendering looks like after that layer:

Starting base before the roads-area-mask layer - after rendering the roads in classical ordering

Starting base before the roads-area-mask layer – after rendering the roads in classical ordering

After that comes the roads_noareas in addition has the GMIC parameter

#roads-noareas { gmic: '-to_rgba.'; }

The roads-line-mask uses the same, i.e. stores the rendering rather than using it. The actual compositioning happens in roads-area-mask where we use the following GMIC script, written here – for clarity – with one command per line:

+channels[roads_noareas] 3
-name. roads_noareas_mask
-channels[roads_line_mask] 3
-channels[roads_area_mask] 3
-min[roads_area_mask] [roads_noareas_mask]
-min[roads_area_mask] [roads_line_mask]
-to_rgb[roads_noareas]
-append[roads_noareas] [roads_area_mask],c
-keep[roads_noareas]
-name. use

This is explained step by step in the following. I link to the resulting images of the different processing steps. These you can generate yourself by adding suitable -output commands in the script. When you invoke the rendering via Nik4 or similar means, this will generate snapshots of the processing – which is useful for debugging purposes.

  • duplicate the alpha channel of roads_noareas into a new buffer (result)
  • name that buffer roads_noareas_mask
  • reduce roads_line_mask to its alpha channel (result)
  • reduce roads_area_mask to its alpha channel (result)
  • calculate the minimum of roads_area_mask and roads_noareas_mask and store it into roads_area_mask (result)
  • calculate the minimum of roads_area_mask and roads_line_mask and store it into roads_area_mask (result)
  • strip the alpha channel from roads_noareas
  • append roads_area_mask as new alpha channel to roads_noareas (result – with transparent parts rendered as dark gray)
  • remove all buffers except for roads_noareas
  • use the remaining buffer for composing this layer

The final results on the sample is here:

Final results of rendering the sample setup

Final results of rendering the sample setup – link goes to double resolution version

This, of course, not only works for pedestrian areas, but also for all the other polygon features rendered in the road layers:


highway=pedestrian/service/platform


highway=residential/aeroway=taxiway/highway=track

Note that highway=steps lines are rendered above highway polygons, just like barriers and tunnels, in disregard of the z-order because open air steps starting from within a pedestrian area, like at a subway entrance, are often just drawn onto the polygons. This is not a very descriptive mapping practice though – despite the convention that linear features supersede polygons (see previous post). Better options for mapping are sketched below.

Subway entrance on a pedestrian area: (1) plainly mapped onto the pedestrian polygon, (2) cut out and tagged with width, (3) in addition mapping of barrier=wall around the edge

Subway entrance on a pedestrian area: (1) plainly mapped onto the pedestrian polygon, (2) cut out and tagged with width, (3) in addition mapping of barrier=wall around the edge

That’s it essentially. This probably sounds much easier than it was though. The design of the roads_line_mask and roads_area_mask is pretty delicate to ensure the results are free of artefacts.

The whole exercise was about the display of line features overlapping with surface level road polygons. One remaining question in light of this is how to treat tunnel road polygons. They could reasonably stay hidden by the surface level rendering in line with the general principle of rendering according to the vertical ordering in reality. I decided instead to render them with outline only. My thought is in particular about subway platforms mapped with polygons – which are useful to be shown underneath pedestrian areas. A bit problematic is the strong difference between the outline rendering of the polygon version and the filled rendering of the linear version, making recognition as the same type of feature unlikely.

Outline rendering of tunnel road polygons overlapping surface level road polygons

Outline rendering of tunnel road polygons overlapping surface level road polygons

Real world examples

A few practical examples of how this looks like with real world data. First a case featuring barrier lines:

Note that the new approach not only shows barriers within the pedestrian area, the fence in this case, but also better shows the walls and retaining walls at the edge of the pedestrian area. The next example features waterways in Freiburg – the famous Bächle:

This well demonstrates that the drawing order change only applies to the road polygons and not to the linear roads – which here leads to partially visible waterway line signature within the pedestrian gray. That is somewhat confusing, but ultimately is caused by the inconsistent mixing of polygon and linear mapping of the pedestrian roads in this case. Another example from Lyon shows a partially mapped subway station:

You can see the underground platform and the subway lines as well as the entrances to the subway. Not mapped so far are the connecting footways in between. A similar case in Marseille:

Mapping is, likewise, incomplete here. And the underground platforms are mapped with linear ways so they are rendered with a fill color. Finally the example from Prague i already showed in the first post of this series:

As far as the tunnel rendering is concerned – more elaborate examples of subway stations or other underground structures underneath pedestrian areas are a bit difficult, because mapping consistency is often not that good. While mappers tend to try to apply tagging with layer diligently, the lack of good visual feedback combined with the counterproductive incentive, that existing mainstream map rendering often has, tends to lead to issues in the data. Common examples are:

  • location=underground/tunnel=yes/covered=yes not being applied consistently to underground platforms.
  • roads underneath pedestrian areas being deliberately not tagged tunnel=yes/covered=yes to make them show up.

An overall discussion of the rendering technique demonstrated here will follow in the next and last part of this series.

Weaving roads #1 - polygons and lines

September 13, 2024
by chris
1 Comment

Weaving roads #1 – polygons and lines

When discussing the rendering of roads in detail 3.5 years ago i showed how OpenStreetMap-Carto uses the different options offered by CartoCSS and Mapnik to draw the road network in a consistent fashion but, ultimately, still falls short of this in some aspects. I also showed the new system of rendering the roads in a single layer, used now in the AC-Style, and how this can help overcome some of these limitations.

Road layering in OSM-Carto with inconsistencies

Road layering with tunnel, ground level and bridge elements represented by linear ways and polygons – as shown in OSM-Carto with inconsistencies – link goes to double resolution version

Improved road rendering as used in the AC-Style so far

Improved road rendering as used in the AC-Style so far – link goes to double resolution version

All of this was done by defining a consistent drawing order of the different features, in many cases in several instances – casing, background, fill, centerline etc. This fully relies on every aspect of the physical vertical ordering being explicitly represented in the data (splitting the geometries as required for that during mapping and, where necessary, using the well known layer=* tag). That works relatively well since mappers in OpenStreetMap often quite diligently record the relevant information on the roads network explicitly. As an additional bonus, it provides clear direct feedback to mappers on how things have been mapped – which helps maintain this high quality mapping.

There are, however, still fundamental issues with this approach that can be pretty severe in the concrete cartographic reality. Most notably regarding the road polygons, where we have two big (and related) problems that i am going to explain below.

Contradicting mapping conventions

Both problems are related to the fact that road polygons (that is for example highway=pedestrian or highway=service polygons – which are used to map pedestrian or vehicle use areas where no single direction of navigation is dominant) are treated exactly like linear roads in terms of drawing order and this is strictly based on the physical vertical order in reality. Although this logic is easy to understand and leads to a clear and easy to interpret rendering (see above), it is also somewhat unexpected in some cases for mappers – which creates the first problem:

It is common that mappers expect features intersecting a highway=pedestrian polygon to be shown above the pedestrian area – like for example a small pond around a fountain or a kiosk building. They would not have the same expectation for a linear pedestrian road intersecting such features, but for highway=pedestrian polygons this is quite common. Sometimes, mappers add layer tags to such features to explicitly indicate the kiosk/pond is located on the pedestrian area. Semantically, this is questionable though, since a surface water area or a ground level building overlapping a non-bridge, non-tunnel highway=pedestrian polygon is incompatible with the established meanings of these tags – independent of the presence of a layer tag. Or in other words: These things are not actually overlapping. In short: It is quite clear consensus among mappers that road polygons should be limited to the area of actual navigation with no implicit (or explicit – through layer=*) resolution of ambiguous overlaps with other polygons.

Pedestrian areas with non-walkable parts (like flowerbeds, fountain ponds) being excluded from mapping as highway=pedestrian.

Pedestrian areas with non-walkable parts (like flowerbeds, fountain ponds) being excluded from mapping as highway=pedestrian. Not universally though – see here

The situation is different though for overlaps of road polygons with other linear features like waterways or barriers. The overarching convention in OpenStreetMap for linear and polygon elements in general is that overlaps are acceptable in mapping, at least in most cases, even if they are semantically contradicting. A highway=track crossing a landuse=orchard or a landuse=farmland polygon is considered correct mapping. Same for a waterway crossing a natural=scrub or natural=bare_rock. Although no crops are grown on the highway=track and no scrub grows within the river, the mapping convention here is that the linear mapping of the track/waterway implicitly supersedes the polygon landcover/landuse mapping. Data users have to interpret the data accordingly – which, in map rendering, is typically accomplished by drawing the line signatures of the linear map elements on top of the polygon elements.

Variants of mapping pedestrian polygons: (1) gross area including non-walkable polygons 'within' (2) only effective pedestrian area but covering linear features and (3) cutting out both polygon and linear features within

Variants of mapping pedestrian polygons: (1) gross area including non-walkable polygons ‘within’ (2) only effective pedestrian area but covering linear features and (3) cutting out both polygon and linear features within

And here you probably notice the dilemma in map rendering since we have two conventions clashing:

  • That linear mapping (of features like barriers, waterways, roads and paths) supersede polygon mapping (like landcover polygons) in cases of overlaps between the two for the area implicitly belonging to the linear feature for where there would be semantic contradictions.
  • That in road layering both polygon and linear mapping are together ordered based on physical vertical location relative to each other according to the explicit tagging with bridge=*, tunnel=* and layer=*.

So far, the AC-Style for the roads has been following exclusively the latter principle, which is – as mentioned – frequently irritating for mappers with regard to the road polygons because of the former principle. And giving up on the former principle and cutting out even linear features from the road polygons in mapping does not help practically either, because the gap in the road polygon mapping based on actual ground width of the linear feature does not provide enough space for the line signature of the linear feature to be rendered. You will see something on the map (like in the sample 3 above) but not the recognizable line signature of the feature in question.

Rendering so far of overlaps between ground level highway=pedestrian features and line features

Rendering so far of overlaps between ground level highway=pedestrian features and line features (barrier=wall on top, waterway=stream on bottom) – (1) linear road with plain intersections, (2) linear road with explicited intersections (barrier=entrance, ford=yes), (3) road polygon

You could now get the idea of rendering all line features of the style after rendering the road layers. That would, however, not work well, because the road network would become difficult to read since it gets frequently overlapped by other line features, especially at the lower zoom levels. The other commonly mentioned idea is to sort everything in rendering according to the layer=* tagged – essentially giving mappers control over the drawing order. That is also not a good idea, because it would effectively sabotage OpenStreetMap as a collection of semantically meaningful information about the geography. Right now layer=* has a fairly well defined meaning regarding the relative physical ordering of close-by or overlapping elements. If mappers instead would start using the layer tag instead to define the drawing order of a map or to define override rules in semantically contradicting mapping that would create a lot of damage to OpenStreetMap as a whole.

Hidden tunnels

The other unresolved aspect of the road layering stems from the fact that defining the drawing order strictly after the vertical ordering in the geographic reality does not universally produce the best readable map – even when you only look at the road features. A drawing order following strictly the vertical ordering in reality means that tunnels are universally covered by surface features. For the linear road features this is rarely an issue (at least for the roads themselves – the road labels and oneway arrows are a different matter). For the road polygons, however, if you have a larger pedestrian (or other road type) polygon, that essentially covers all the underground road infrastructure underneath.

Underground infrastructure hidden by pedestrian area

Underground infrastructure hidden by pedestrian area – links to same area in OSM-Carto.

Bottom line: For a well readable map you ideally do not stick to strictly defining the drawing order by vertical ordering for the roads. For elements that would otherwise be fully hidden by what is drawn above them the better approach is to try visualizing them out of order in some form. This avoids creating substantial gaps in the depiction of the road system.

Solutions

Tackling this second issue is not possible with the methods so far deployed in road rendering in either OSM-Carto or the AC-Style. As mentioned above, so far these styles base the drawing order and styling decisions fully on information explicitly stored in the data per feature. What is necessary here is interpreting the context – a tunnel feature needs to be drawn differently (in either order of drawing or styling or both) depending on if they are underneath a road polygon or not. This can be done either by

  • Intersecting the geometries in SQL. That is computationally expensive and would require adding substantial code complexity to the already complex road layers.
  • Using raster compositioning. This seems the more elegant approach here. But it is beyond the limited compositioning abilities of current Mapnik.

The good news is that both approaches will equally allow addressing the first problem of properly displaying non-road line signatures on road polygons – dealing with those differently within road polygons is not much different from the dedicated display of tunnel features within road polygons.

In the next part i am going to demonstrate and explain an implementation of the second method offering a partial solution to the problem discussed.

September 10, 2024
by chris
1 Comment

A short State of the Map 2024 comment

State of the Map 2024 took place in Nairobi last weekend. I did not attend, although i tried to get an idea by watching some of the video streams. With tried being the operative word here – the streaming infrastructure did not seem to be quite up to the task. That was clearly not the fault of the local team though (with the exception of the microphoning and audio levels – which was severely challenging for the viewer).

Not going to write an in depth commentary here. To recapitulate the background: The year before (2023) State of the Map was meant to take place in Cameroon but the OSMF board threatened to intervene for political reasons so the SotM working group scuttled their plan – meaning no SotM in 2023. Bottom line: A lot of people were pissed, but for very different reasons.

When, for 2024, the SotM working group selected Nairobi, the opposition was less severe and the OSMF board kept quiet – so the conference went ahead. It was nice to see the African communities got some broader recognition. And given the severe lack of more substantial communication of the OSMF with the larger OSM community otherwise, the program items from the OSMF gave valuable insights into the inner-OSMF mindset that are otherwise not available to the ordinary OSM community member.

Beyond that i want to point interested readers to the commentary and impressions from Severin and Ilya from the conference. If you compare the official public communication from the OSMF to Ilya’s comments, that is truly a night-and-day difference – predominantly PR phrases and random pointers to communications of others vs. thoughtful personal impressions and critical commentary based on concrete individual experiences.

The OSMF has now for quite a few years tried to organize some streamlined synthetic corporate PR style communication (with fairly limited results even by corporate standards). At the same time they are essentially ignoring the substantial grassroots efforts and talents the OSM community has developed in the field of public communication because they do not fit into the OSMF corporate culture. The people who try to help the OSMF writing mastodon and twitter posts or entries on the official OSMF blog are surely well meaning and enthusiastic. But the idea to compete through engineered PR style communication with people freely and independently writing about the topics they are involved and experienced in is simply not a winning proposition. And, as a side effect, it alienates everyone in the wider OSM community who publicly shares their thoughts on OpenStreetMap topics with a wider audience and who has the ambition to do so independently and in a reflected way without being affected by organizational interests.

Ironically, this year’s SotM also showed how much talent and eagerness there is also in the African OSM communities in public communication, which is sadly not going to find the support from the OSMF to thrive and to develop the experience and self confidence to write and talk independently and critically about matters of interest for the global OSM community with a distinctly African perspective. My hope is that such support will at least to some extent come from the broader OSM community outside the OSMF.

Next year’s conference is announced to be in Manila, Philippines – from former British colony to former US colony i might critically add. But i am happy for the Philippine OSM community. They are a very active local community in OpenStreetMap with a very dynamic development of the map in the area. It is unlikely i am going to be there though. I might reconsider that if someone was interested enough in me talking there about map design, generalization, open data satellite imagery or any other topic of interest to finance me visiting the conference. But as is, there is neither enough use for my business in such a visit nor am i interested in becoming part of the international OSM jet set.

A short final remark regarding diversity of locations of SotM conferences. It has occurred to me that up to and including Manila 2025 all SotM conferences with the exception of Japan (2012 and 2017) will always have taken place in predominantly Christian countries. Coincidence?

Viewpoints in Provence, France

September 6, 2024
by chris
1 Comment

More dynamic symbols: Viewpoints

Two years ago i showed a new design concept for rendering trees in maps. This used a combination of hand designed components with automatic geometry processing to depict different types of trees of different sizes in a way the symbols naturally overlap in a well readable way when the trees are close to each other.

Non-blocking dynamic tree symbols

Non-blocking dynamic tree symbols – click for the blog post discussing these in more depth

Technically, this was done by rendering the symbols from a polygon representation in the rendering database. This facilitates both the construction of the symbols from their hand drawn design elements, the dynamic scaling according to the tree diameter, and the cutting of intersecting tree symbols for the natural display of overlapping symbols.

One thing you might have noticed with the tree symbols is that they are non-blocking. Other symbols and labels overlap with the tree symbols freely. This matches the tree display in OpenStreetMap-Carto and is a prudent choice for tree display. But it also was a practical necessity, since polygons rendered from the database in Mapnik are inherently non-blocking. Collision detection and blocking in Mapnik is traditionally only available for point, marker and text symbolizers. The technique i demonstrated for the trees was therefore limited in its application to situations where non-blocking symbols are the goal.

I have since then extended the capabilities of Mapnik to customize dependencies between symbols drawn using the concept of anchors. I here want to show how that feature can be further extended to allow the use of symbols drawn from the database for blocking applications.

Displaying viewpoints

Viewpoints are locations that offer an extraordinary view of the environment and are therefore often a popular destination to visit. Such are tagged in OpenStreetMap with tourism=viewpoint. A significant percentage of those (>12 percent) are also tagged with a direction tag, indicating the direction in which the viewpoint offers a good view.

OSM-Carto has rendered viewpoints with a static point symbol for a long time, but is not taking into account the direction tag. Depiction of viewpoint directions has been pioneered by the OpenTopoMap style.

I am using SQL functions to calculate azimuth direction and viewing angle from the direction tag. Then i use those to pick and suitably rotate the best fitting symbol from a pre-generated table of symbols in the rendering database. Here is how this looks like for different variants of the direction tag:

Viewpoint display with direction visualization

Viewpoint display with direction visualization – click to see the corresponding direction values as label

And here are the pre-generated symbols from the symbols table these are rendered from:

Pre-generated symbols stored in the rendering database

Pre-generated symbols stored in the rendering database

There are a number of aspects about this rendering of the individual viewpoint symbols i want to point out. First: Viewpoints without a direction tag remain shown with the generic traditional symbol to distinguish them clearly from the direction=0-360 viewpoints. Second: The size of the symbols is slightly increased as you zoom in – to not take too much space at the lower zoom levels and be more clearly readable at the higher ones.

Symbol size change with zoom level

Symbol size change with zoom level – click for double resolution version

But also note that the size of the symbol varies depending on the angle depicted – for the narrow angles this is increased while for the 360 degree it is decreased. This makes the weight of the symbols of viewpoints with different angles more similar. Finally, also note the positioning of the name labels is adjusted to the symbol bounds so there is no excessive gap between symbol and label for the northward looking viewpoints.

In contrast to most other point symbols in the style, the viewpoints are rendered with a relatively subtle bright halo. This ensures a good readability of the fairly fine grained symbol design above strongly structured backgrounds – which are common near viewpoints with elements like natural=cliff, barrier=retaining_wall or natural=bare_rock polygons.

Cutting and blocking

The real innovation, however, comes from the way symbols are cut and interacting with other symbols. Like in case of trees, close-by viewpoints are cut away in their overlaps, ensuring a clean display without fully dropping the display of some of the symbols. At the same time, symbols that have priority over the viewpoints (because they are displayed at earlier zoom levels) are blocking the display of close-by viewpoints. Also viewpoints are blocking the display of lower priority symbols close-by. Mountain peaks (natural=peak) are treated differently, because they are commonly close to viewpoints or mapped in combination on a single node. Here symbols do not block each other, but the peak symbol is cut out from the viewpoint depiction to allow both to be displayed together. More on that later.

Interaction of viewpoints with other symbols

Interaction of viewpoints with other symbols: (1) non-overlapping close-by viewpoints, (2) overlapping viewpoint symbols being cut out from each others, (3) with peaks overlapping as well, either mapped separately or both tagged on the same node, (4) viewpoint symbol being blocked by a higher priority symbol and (5) viewpoint symbols blocking other lower priority symbols – click for double resolution version

There are two modifications of Mapnik necessary to accomplish this:

  • To support blocking between viewpoints and other symbols, support for anchor-cond was added for polygon symbolizers. This allows implementation of simple blocking by rendering a zero opacity marker symbolizer for the viewpoint like you’d do for an SVG symbol and then tie the rendering of the actual symbols to that via anchor-cond. That, however, does not work in combination with the cutting of the viewpoint symbols with one another, because even symbols that are blocked by other non-viewpoint symbols are getting included in the cutting operation – which they should not. To fix that we need to
  • add a way to access the list of anchors (the identifiers of symbols rendered successfully so far) from within SQL, where we are doing the cutting of the symbols.

While the first of these was fairly straightforward to implement, the second was a bit more tricky. This was mainly because of the way Mapnik handles database queries and rendering. Instead of running the query of each of the layers of the map style and then rendering its results before moving on to the next layer, Mapnik has the ability to asynchronously start all the queries up-front and then start rendering the map as soon as the queries return with the data. But this procedure, of course, does not work when the query of a layer depends on the rendering results of the layers rendered before. So, to use this feature of allowing access to the anchors from within SQL, we have to move to a strictly synchronous query and rendering procedure.

Practically the whole process looks as follows:

  • The main POI (amenity-points) layer is rendered with the viewpoints being represented by zero opacity placeholder markers, that have a suitable anchor-set parameter to document successful symbol placement.
  • A second layer (viewpoints) is set up to display the actual viewpoint symbols. It also performs the intersection with the other viewpoints. This layer is rendered after the POI layer and has an additional parameter in the Datasource: anchors_table: carto_anchors. This tells Mapnik to make available the list of anchors previously set in a temporary table in the database with the specified name. That table is then used in the SQL query of the layer in the form of an additional WHERE condition like AND EXISTS (SELECT 1 FROM carto_anchors WHERE "name" = 'viewpoint_' || osm_id::text).

Viewpoints and peaks

The combined rendering of viewpoints and peaks required some further modifications to the point symbol and label rendering system. The peak symbols are cut out from the viewpoint symbols just like the other viewpoints. In addition, the label position is adjusted as necessary to avoid overlap/blocking with either the peak or the viewpoint symbol in all the different direction variants.

Viewpoints and peaks tagged on the same node

Viewpoints and peaks tagged on the same node – click for double resolution version

Real world examples

While there are quite a lot of viewpoints mapped with direction tags, this tagging is usually patchy – not many regions have all or even most viewpoints tagged this way. None the less, here are a few examples of how viewpoints with specified direction look like in real world contexts. A double resolution version is linked from the images.

Reunion, Indian Ocean at z16

Reunion, Indian Ocean at z16

Provence, France at z17

Provence, France at z17

Kaiserstuhl, Germany at z18

Kaiserstuhl, Germany at z18

Conclusions

What i showed here is how dynamic symbol design can be implemented in maps with various forms of collision and overlap handling. In the presented case of viewpoints, this entails in particular the following components:

  • The different viewpoint symbols are not blocking each other, but instead their symbols are cut out to avoid overlaps in a manner similar to what i have demonstrated for trees in the past. Symbol priorities in cutting are based on elevation (when tagged) and view angle.
  • The viewpoint symbols are blocking and get blocked by other point symbols based on their priorities. Except for
  • peak symbols, which do not block viewpoints, but have their symbols cut out from the viewpoint depiction like viewpoints are cut out from each other. This includes cases where a node is tagged both as a viewpoint and a peak.
  • Labels are shown under the symbol with an offset dynamically adjusted to the geometry of the viewpoint visualization used.

To accomplish these things additional functions were added to Mapnik and Carto. One allows conditional rendering of polygon symbolizers, depending on the successful placement of other symbolizers, which are subject to collision detection. The other provides access to information on what symbolizers were rendered successfully in previous layers from within SQL via temporary tables. Combined with the use of zero opacity placeholder symbolizers this allows the implementation of the design features described.

The Mapnik modifications are available on Github. To build Carto with support for these new features you also need the modified mapnik-reference.

The modifications of the Alternative-colors style implementing the dynamic viewpoint rendering have been published as well.

The map design concepts demonstrated here and the modifications of Mapnik that enable these further contribute to implementing point 5 on my list of critical features map design work requires from the tools it uses. But keep in mind i am not a software developer, i do not aim for these features to be usable more generally, they are just a proof-of-concept.