In the previous post i introduced the basic concepts of how parking infrastructure is mapped in OpenStreetMap and how this is so far shown in most maps. I also discussed that there is an extensive spectrum of secondary tags used by mappers to characterize parking infrastructure in more detail. Here i want to introduce some new rendering concepts to visualize some of these.

The attributes i chose to interpret are generally among the more widely used secondary tags for parking features in OSM. But of course there is also some subjective choice in that.

So let us get started…

General design concept

I maintained the principal design concept from OSM-Carto to show large parking polygons from early zoom levels depending on size while showing all parkings from z16. But i reduced the symbol sizes at the lower zoom levels, in particular reducing the visual weight of amenity=bicycle_parking/motorcycle_parking at z16 and lower. Here is the full zoom level sequence illustrating that:

Surface depiction

As you can see in these already, there is a fill pattern shown on polygons at the highest zoom levels (z18+). I use a subtle structure pattern to visualize the surface – in a similar fashion as it is already done for roads. And i introduced a distinct pattern to depict parkings with unspecified surface – which is what you see in the previous illustration. This results in a system of three design variations shown below.

The lack of a third unknown variant in surface tag depiction on roads has been a point of critique on OSM-Carto in the past. I have not tested if the pattern shown here is also viable for use on roads. It might be for the highest zoom levels on roads with a wider line signature. It works reasonably well on parkings i think.

Parking space details and garages

I ported rendering of amenity=parking_space from OSM-Carto and in addition also illustrate various secondary tags on those at z19+ with a subtle single symbol non-blocking pattern.

Single symbol patterns i introduced on leisure=pitch in a previous post. These are implemented using raster compositioning. Like with pitches i increase the size of the symbol shown if the polygon is larger for better readability – though for normal sized parking spaces at low to moderate latitudes this will only be practically used at z20+. And the same technique is used also to indicate buildings of the types building=garage/garages/carport – with building=carport in addition using the dashed outline that is already in use for building=roof.

If surface is tagged on amenity=parking_space this is rendered distinctly if tagged. If surface is not tagged the parking space inherits the surface from the amenity=parking it is located within.

The combination of single symbol pattern and inherited fill pattern needs to use an explicit query to determine the surface of the surrounding parking because it is not possible to render the single symbol pattern without a background fill color, i.e. transparently. Hence i need to re-fill it explicitly with the fill pattern of the parking area in those cases.

Note a color neutral casing is drawn around the symbols to improve readability in combination with the structure patterns. Practically the combination of an unpaved parking space with a specific function is, however, probably quite rare.

Implicitly mapped parking lanes and street-side parking

As i have shown in the first part of this blog post series the implicit mapping of parkings at the side of or on the side of roads through secondary tags on roads is not that widespread in numbers in OpenStreetMap so far. But this style of parking is very widespread in reality. In many parts of the world, urban residential areas make extensive use of parking on the side of roads and a large percentage of the overall urban parking space for cars is made up from this kind of parking along the side of roads. While in theory this could all be mapped explicitly with amenity=parking, using secondary tagging on roads is often a much more efficient and maintenance friendly way to map this. While it would be important for map styles with a mapper feedback function to support this style of mapping, only very few specialized maps do so.

I have now added support in the AC-Style for both implicit mapping variants. How this looks like in principle can be seen here.

The parking:*=street_side visualization is done together with the rendering of implicitly mapped sidewalks. Both can be used in combination and this also can be combined with implicitly mapped embankments.

Secondary attributes on parkings

The most significant enhancement in rendering of parkings i want to introduce here is the visualization of secondary tags on amenity=parking, amenity=bicycle_parking and amenity=motorcycle_parking. As mentioned in the first part these secondary attributes on parkings constitute one of the most extensive and most widely applied schemes of secondary tags in OpenStreetMap – and that despite these tags being only interpreted by very few maps so far.

The difficulty is that there are a lot of different tags for documenting different aspects of a parking area. The approach i took is using the technique of symbol augmentation that i discussed already in a previous blog post. In the previous use cases, symbol augmentation was used to visualize a single additional property in a flexible and context dependent way. Here i am taking this technique a step further to visualize a whole bunch of secondary attributes.

But before i get to the details of that i want to mention that i completely removed the rendering of name labels for amenity=parking. Name tags are only used on about 6 percent of all parkings and are rarely used for proper names, they typically contain either descriptions, reference numbers or names of other features the parking belongs to. And not rendering name labels for parkings makes space for showing more meaningful and more diligently and consistently applied tags.

I will start with an extension of the rendering of access restrictions on parkings. As shown in the first part, depicting access restricted parkings with a lighter symbol and label has been done in OSM-Carto for a long time. But it has also been bothersome that aggregating access=no/private and access=customers into a common styling is fairly non-ideal and you could even argue that in many cases a parking with access=customers is closer in meaning for the map user to a unrestricted access parking than to a private parking. I now tried to resolve this issue by visualizing customer parkings with an add-on symbol (a shopping basket) and not with a changed symbol and label color.

In addition i show a bunch of other commonly applied secondary tags.

So far, so simple – this is how a single add-on tag is shown. It gets more interesting if you combine several of these

When all the different add-on symbols are used together it kind of drowns the main parking symbol. But keep in mind that a single parking will rarely feature all of the secondary tags in combination.

What i have shown so far is still in principle also feasible with symbol variations. You could generate a distinct SVG file for every combination of secondary tags and use that as symbol. This is what Andy Townsend for example does in his AJT style in a somewhat more abstract fashion for pubs.

The big advantage of symbol augmentations compared to that is that they are rendered independently from the base symbol. That means they can be blocked by other symbols with higher priority (which means all independent features in this case) individually. Furthermore, you can define fallback positions where add-on symbols can be placed when placing them at the preferred location fails.

I want to mention that this style of augmentation in a dense cluster of supplemental symbols around the base symbols is only one possible arrangement. Other, more structured configurations can be considered as well. Like a dynamic stack of symbols next to the base symbol.

The problem with any such non-compact arrangement is that if a different feature blocks parts of the secondary symbols the rest might not be intuitively readable as belonging to the base symbol they are meant for. And preventing such cases would require a relatively complex logic.

Keen observers will have noticed that the symbol for fee=yes is a coin shape with a currency symbol. The choice of currency symbol is subject to regional differentiation – the one shown here is the one for Yuan – which is due to the fact that my default location for abstract sample rendering is 100 degrees east, 40 degrees north – which is located in China. More details on this regional differentiation in the next post.

Real world examples

Here a few examples of how these changes look like with real world data. You can find further samples of the AC-Style in the sample gallery

Discussion and Conclusions

Based on a specific thematic domain (parking) i tried demonstrating here how you can improve the information depth available in a map. I like to point out that i did not introduce the rendering of any new features here that were not already shown in either the AC-Style or OSM-Carto before. This is purely based on visualization of secondary tags and differentiation of features previously rendered in a uniform design.

The design techniques used are not new but were previously shown in the AC-Style and OSM-Carto. In particular

• the use of structure patterns to differentiate rendering of polygons fills beyond what is possible with uniform colors.
• the use of pictorial single symbol patterns to visualize semantic differences between features of a similar size in a subtle way without blocking other design elements.
• the use of geometry processing to generate secondary linework around roads to visualize implicitly mapped properties in a way that automatically adjusts to the surrounding road network topology.
• varying the symbol size and weight with zoom level to better be able to gradually adjust the visual weight of a certain type of feature in the map.
• the use of Mapnik anchors to render aggregate symbols in a dynamic fashion.
• the use of lookup polygons to spatially differentiate design, in this case currency symbols.

I want to address an argument that is likely going to be brought up against this idea of specifically increasing the depth of information in a map (i.e. more differentiation of features shown and display of additional properties of these features) in contrast to increasing breadth (i.e. rendering additional features so far not shown).

That argument is that in digital maps such information can be better provided on explicit inquiry by the user through an interactive interface and should not be part of the map, which should focus on breadth (the existence of features and their basic classification) rather than depth.

Although i acknowledge the value of interactive extensions of maps, i very strongly disagree with the idea of restricting the sophistication in map design and the depth of information communicated in maps based on the idea that this is being replaced by information provided only on active request by the user. From an attention-economical standpoint this makes total sense of course. But i think it fails to recognize that one of the fundamental ideas of cartography and one of the main reasons why maps have fascinated and attracted so many people throughout human history is that they are a source of information on the geography that is fully accessible by passive observation. If you degrade the map to a UI background of an interactive geo-database query application you essentially remove this key aspect of maps that has historically been essentially universal to all general purpose maps ever produced.

Why is this aspect of maps – to be able to access the full information content of the map through passive visual observation – so important for the ergonomics of map use? Largely because it resembles the process how we learn about our environment in reality. We do not have to tap on a street sign to be able to see the name of the street. We do not normally have to knock on the door of a convenience store for it to reveal itself as such to us. And we do not typically have to enter a parking lot to be able to see that it has parking spaces reserved for disabled people. As humans, learning about and mentally mapping our environment through visual observation is an ability we develop and train from a very young age. The ability to permanently manifest such mental mapping in physical form and to share this with others and to allow them to acquire this geographic knowledge through equally passive visual observation but without the need to be at the place in question physically is what map making is ultimately all about.

Being able to visually access all the information of a rich map does not only provide an intuitive low effort way to this information, I also learn much more about the geography of the area i am observing in passing without specifically looking for it – including in particular learning about things i am not aware up front that they even exist. And this casual learning even taps substantially into the subconscious – when studying a map we tend to learn things about the geography without even being aware of seeing them.

You would be cut off from all of these things when geographic information is accessible only on explicit user action from an interactive application.

Of course selecting and filtering information, deciding on what to show and what not to show, is still fundamentally necessary when you design maps. And if the information i introduced visualization techniques for here is something good to include in a general purpose map is a valid topic of discussion. Personally, as someone who does not own a car and who relatively rarely drives a car these days, i do not put a strong emphasis on parking infrastructure. But i recognize (and the numbers of mapping in OSM i have shown support this) that this is a subject of substantial interest for many people in many parts of the world.

So much on my recent parking related work on the AC map style. In the third part of this series of blog posts i am going to discuss a few things not directly related to parking that came up during development of these changes.