Imagico.de

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.

In this post i am going to introduce what i have been working on at the last Karlsruhe Hack Weekend in terms of map design and some further work i did continuing that work in the weeks afterwards.

What i worked on is improving the depiction of addresses and entrance nodes.

Entrances

With entrance nodes OpenStreetMap documents the location of entrances in buildings and their function. A node is placed on the outline of a building polygon and tagged entrance=*, potentially in addition with access tags and address information.

Entrance nodes have been used for quite some time in OpenStreetMap (since around 2012). They are an element of in-detail mapping of builtup areas and naturally come after the mapping of buildings. But in contrast to buildings – where data imports and automated mapping are fairly widespread in OpenStreetmap – entrances are almost exclusively the domain of on-the-ground mapping based on local knowledge so far.

OpenStreetMap Carto has shown entrance nodes since 2018 with small square symbols. entrance=main and entrance=service are rendered with different symbols, entrance=home and entrance=staircase identical to entrance=yes.

Entrances in OSM-Carto at z18 and z19 – link goes to double resolution version

Addresses

Addresses are among the three most widely mapped things in OpenStreetMap – after buildings and roads/paths.

A lot has been written on address mapping in OpenStreetMap by others, in particular on their importance for the usefulness and success of the project and on the matter how to determine valid addresses of features in OpenStreetMap from the data with the variety of address systems used in different parts of the world.

The peculiar thing is that – while there is broad agreement what tags to use for the different components of addresses, including various regional particularities – there is no agreement on the question if an address is a feature (a distinct data object that has meaning on its own – and that abides by the One feature, one OSM element principle) or if it is a set of secondary attributes to be applied to other features.

This lack of consensus on one of the most widely mapped things in OpenStreetMap has quite substantial consequences on map rendering – which will be a significant part of what this blog post deals with.

Of the address data in OpenStreetMap, OSM-Carto primarily renders housenumbers (addr:housenumber). It meanwhile also shows (in addition to addr:housenumber if that is tagged):

• addr:housename (used when there is no housenumber and an individual address is identified by a locally unique name of the building)
• addr:flats
• addr:unit (only if there is no addr:flats)

All of these are shown in one single uniformly formatted labeling string when tagged on either a node or a building polygon without any consideration of context. They are shown with lower priority than most other labels and symbols.

Address label rendering in OSM-Carto at z19

Rendering issues

There are a number of issues with the current rendering of addresses and entrances in OSM-Carto:

• The rendering scheme for addresses incentivizes mappers to map addresses with separate address nodes – a mapping practice that is common, but not universally followed – and to position these addresses as labeling nodes where, between the other features in the map, there is space for an address label.
• Combining several different address tags into a single labeling string leads to confusing labels with unclear meaning. See 3568.
• The address labels start with low priority – but at z17, meaning that POI symbols/labels starting later will hide the address. See 3904.
• More generally: Address labels are shown with lower priority than POI symbols/labels, but at the same location. This means that an address tagged on a POI that is rendered is not typically shown.
• If a housenumber is tagged on multiple features – like on a building polygon, an entrance node and a separate address node – it is potentially shown several times. While this can be considered useful feedback to indicate the duplicate tagging, it does not actually point out most of the duplicates because they are on POIs – where the housenumber is usually not shown (see previous points).
• Long addr:housenumber/addr:flats/addr:unit values containing lists of several numbers lead to large labels. See 4155, 4160.
• Addresses tagged on entrance nodes (which is a common practice) lead to address labels drawn over the entrance symbol. See 3038.
• Additional address information on entrance nodes is not shown. See 4687.
• Some well defined values for entrance=* (entrance=garage, entrance=shop) are not shown.

Some of the issues with OSM-Carto address and entrance rendering. From left to right: Ambiguous semantics of compound address labels, overlapping entrance symbol and address label, housenumber shown in duplicate when tagged on entrance and building/address node, housenumber not shown for POI, manual address labeling with separate address node

Improved entrance node symbology

The square symbol for entrance nodes has proven to be a simple but effective method to show entrances that well integrates into the style overall. I have extended this concept to differentiate more entrance types than OSM-Carto and use enlarged symbols at z20+ for better readability.

The different entrance types and their visualizations at z19 and z20 – link goes to double resolution rendering

The symbols for entrance=entrance, entrance=exit and entrance=staircase are context dependent, adjusted to the orientation of the building edge they are placed on. How this works can be seen below. For the staircase variant the symbol is selected from two horizontally mirrored variants so the stairs symbol crosses the building outline at an angle that leads to best readability

Context adjusted entrance symbols for entrance=entrance, entrance=exit and entrance=staircase at z20

New address labeling concept

More extensive than the entrance node symbology improvements are the changes made to address labeling. Here is the basic scheme of the new labeling.

New labeling scheme for addresses an address nodes and entrance nodes in various contexts at z19 – link goes to z20 version

What is changed compared to OSM-Carto is in particular the following:

• Address labels on entrance nodes are not centered any more but drawn next to the address node.
• addr:housename labels are not shown on entrance nodes (where they don’t really make sense).
• addr:unit and addr:flats are shown with separate labels at different directions relative to the labeling location (top right, bottom right) and with somewhat different label style. If there is no housenumber to be tagged then a small dot is shown as reference point.
• On entrance nodes in addition ref is shown.
• Multiple identical housenumbers on or within the same building polygon are de-duplicated.
• addr:housename modifies the label arrangement to ensure sufficient space for a longer name.
• Label sizes and arrangement are adjusted for z20+ for better readability.

In addition, housenumbers are now also shown when there is a different symbol or label preventing an address label to be shown at the usual location. This is achieved by trying different offsets of the label in different directions with the help of mapnik anchors, which i discussed in previous posts already.

As currently implemented the de-duplication of housenumbers is only active between the building polygon, entrance nodes on and POIs within the building. Several POIs with the same housenumber within a building without an identical housenumber get separately labeled if space permits. This ensures that in buildings with no unique housenumber it is shown which POIs have which housenumber – since some might share one number while others have a different number.

Display of housenumbers on POIs with de-duplication (z19)

From left to right we have here:

1. Building with addr:housenumber and entrance node with same addr:housenumber – the housenumber is only shown once on the building.
2. With name tag on the building in addition – building name is displayed, as well as housenumber above.
3. Generic shop type (shop=*) tagged on building in addition – shop gets shown with symbol and name label, housenumber left of symbol.
4. Same with shop=supermarket – housenumber location gets adjusted for the larger symbol.
5. shop=supermarket as a separate node instead (also with same addr:housenumber) – housenumber gets displayed for the building only, moved because of the symbol.
6. same with a different housenumber on the shop – both housenumbers are shown.

The logic to display building names is modified to avoid name labels being shown in case the name tag is ambiguous. If a shop or office is tagged on a building, then it is not clear if the name tag is the name of the building or the shop/office. You can see that in case of offices, where OSM-Carto at z17 shows the name as the building name – while on the higher zoom level the same name is shown as the office name. My change avoids this:

Same as above, but for offices and at z17, z18 and z19 – showing how names on buildings are only labeled if they non-ambiguously indicate a building name

And long lists in addr:housenumber, addr:unit and addr:flats are reformatted and shortened as needed:

Abbreviation and re-formatting of long lists of numbers in addr:housenumber, addr:unit and addr:flats

Real world examples

Here a few practical examples based on actual real world data, links go to OSM-Carto rendering at osm.org.

Spiekeroog, Germany at z18

St. Petersburg, Russia at z18

Verona, Italy at z19

Portland, US at z19

Freiburg, Germany at z19

Conclusions

What i have shown here are two things:

The first is the entrance symbol modifications, where i demonstrated how a relatively compact symbol can be modified in subtle ways to transport more differentiated classifications, including context dependent designs based on the orientation of the building wall the symbol is placed on.

The second is the improvement of address labeling in various aspects that i discussed above in more detail. This relies substantially on the use of mapnik anchors – which i discussed and used previously – for conditional rendering of labels. Techniques used here are in particular

• De-duplication of multiple identical housenumbers on the same building.
• Adaptive arrangement of different address label components depending on which tags are present (address tags and entrance tag).
• Trying alternative placements of housenumber labels in the presence of other blocking labels.
• Not interpreting name tags as building names when ambiguously tagged together with POI tags.
• Abbreviating long lists of numbers in address tags.

There is still a lot of room for improvement with the address labels, in particular the strategy for trying alternative placements to show housenumbers next to POIs is pretty basic and could be improved in particular in dense labeling situations at the lower zoom levels, where many housenumbers currently end up pretty far away from their mapping location to a point where it can be confusing.

The most controversial change might be the de-duplication. A point can be made that this paves over inconsistencies in tagging in violation of the One feature, one OSM element principle. But as i already discussed, the OSM community is divided on the matter. And even if there was agreement among mappers that addresses are features and not secondary tags – implementing such an agreement against the massive collective pressure and resources of the SEO crowd is likely not going to be successful. OpenStreetMap will most certainly have to live with the fact that different semantic concepts will be used in parallel for address mapping for the foreseeable future. De-duplication is needed to deal with that in map rendering. And in contrast to other de-duplication problems we here have the advantage that we have the building as a clear geometric frame of reference.

As usual the style modifications discussed here are available on the Alternative Colors style repository.