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.

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.

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.

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

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.

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.

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:

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

Real world examples

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

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.