Imagico.de

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

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

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

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

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

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

Real world examples

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

Prague at z18 – double resolution version, previous rendering, in OSM-Carto

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:

Freiburg at z19 – double resolution version, previous rendering, in OSM-Carto

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:

Lyon at z19 – double resolution version, previous rendering, in OSM-Carto

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:

Marseille at z19 – double resolution version, previous rendering, in OSM-Carto

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:

Prague at z19 – double resolution version, previous rendering, in OSM-Carto

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.

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

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 (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 – 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.

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

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 – 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: (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 – 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

Provence, France at z17

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.