While working on the rendering of parking features that i discussed in the previous post i also came to implement some features and address some problems that are not strictly about parking but design wise related. And those i want to discuss here a bit.

More implicitly mapped features on roads

The introduction of rendering for street side parking required substantial modifications to the rendering of implicitly mapped sidewalks and cycleway tracks (originally discussed here) and embankments (here). Sidewalks and cycleway tracks are shown outside street side parkings so need to be shaped around those. And the embankments are now separately molded around the roads and their sidewalks and parkings on both sides of the road.

The difficulty is that all of this needs to work in combination with all the different road types and at junctions between different roads

The on-street parking lane rendering also called for rendering cycle and bus lanes on roads in a similar fashion. This is similarly tricky to make work reliably in different road topology contexts – and for the lanes there is still quite a bit of room for improvements in that regard – the code is already quite complex as is though.

In addition, tagging practice for cycle and bus lanes in some cases requires knowledge of the driving side of the roads – when cycleway=lane/busway=lane or cycleway=opposite_lane/busway=opposite_lane is tagged on a oneway road the side on which the lane in question is going to be located depends on the general driving side of the location in question.

Overall, in the AC-Style we now have the following variants of mapping dedicated cycling and bus infrastructure explicitly visualized:

Because all of this gets pretty colorful if you include the different types of access restriction dashing i have been contemplating to remove the colored rendering of the different non-pysical road classes at z18+. At the high zoom level this type of semantic differentiation becomes much less significant so it is worth considering not to apply it any more. I have not made a decision on that yet.

More regional differentiation

The driving side problem was solved using the same technique i previously introduced for name label rendering to determine the default language of an area. The polygons used to do that were supplemented with additional attributes for the driving side and for the locally used currency. I updated the shapefiles i produced accordingly. The information about currency is so far incomplete – as are currency symbol SVGs. But quite a lot of countries are covered.

The question if regional differentiation is advisable to have in a map style meant for global use and for mapper feedback has been a subject of discussion for a long time. For languages i think i have amply demonstrated the necessity when i discussed name labels some time ago. I think the situation for the driving side is obvious as well – if mappers have adopted a tagging system that depends on knowledge of the driving side for interpretation (and i see no good reason why mappers should not do so) it is natural that map styles need to source this information somehow to interpret this data accurately.

As for the currency symbols – this is obviously a design choice. But for visualizing the concept of money in a compact form an intuitively readable currency symbol is very useful. Some purists w.r.t. the idea of a globally uniform map might object to the idea that the same data will show up differently in the map depending on where the data is located. But this is already the case not only with the driving side and the language and script of labels but also simply because of the variable scale Mercator projection. Web maps in Mercator projection are fundamentally already regionally differentiated.

In my opinion establishing and using the ability to regionally differentiate map rendering rules is important to honor the idea of OpenStreetMap to value local knowledge. But it is of fundamental importance that such differentiations reflect well defined and clearly spatially delineated differences in the geographic reality. It is important not to use it to pave over and disguise regional differences in mapping practice because that would sabotage the goal of OpenStreetMap to collect local knowledge into a single database.

For the same reason i see the trend in maps available today to differentiate map styling not by region but by individual map viewer fairly critically. While this has been common practice in commercial maps for a long time, it is a whole other story when it comes to maps with a significant role in providing mapper feedback. The fact that all mappers – when evaluating their own and others’ work by looking at a real time updated map – see exactly the same thing when looking at the same map at the same location is pretty fundamental for the social cohesion in the OSM community. And the nonchalance with which some people contemplate throwing this completely out of the window is quite remarkable.

Extensions of Mapnik anchors

While working on the rendering of add-on symbols for parkings (see previous post) i noticed that when dealing with multiple add-on symbols it is useful to extend the feature of anchors i implemented in Mapnik (see here) to allow lists of anchors not only in anchor-cond, but also in allow-overlap-anchor and anchor-set. This extension is also available now.

Improvements of symbol and pattern processing

I also made some improvements to the scripts for symbol and pattern processing.

In the script for generating the unpaved road structure patterns i removed the dependency of the now unmaintained colormath python module. I also moved configuration to a separate yaml file.

In addition i extended the generation of contact sheets to the unpaved patterns and the add-on symbols – you can see those in the symbols readme.

Finally: I also introduced rendering of highway=street_lamp at z18+ in a design derived from the french style.

This subtle small footprint design allows precisely locating the lamp and can – like bollards – be rendered in a non-blocking fashion.

That wraps up this three post series on the world of parking in OpenStreetMap and automatically rendered maps.