Drawing the lines


After doing what i had originally planned for the last OSM Hack Weekend in Karlsruhe before the actual weekend what i actually worked on there was something different – though not unrelated.

Rendering lines in a map is something that at the first glance seems the simplest thing to do but in reality there are quite a number of things that need to be considered for lines in a map to be well readable. One thing in particular is that if you render a dashed or dotted line this is much more difficult to get right than a solid line.

The OSM standard style uses dashing to differentiate tracks by tracktype and footways/cycleways by surface. This works reasonably well at the high zoom levels but it degrades to the point of being completely unreadable as you zoom out in areas with a dense network of paths. Like in these examples:

Now you can try to vary the styling like by adding bright halos, increasing contrast or varying the line width but ultimately a dashed or dotted line always makes it more difficult to identify the paths as continuous lines in areas with a lot of detail. A fundamentally different and possibly better approach would be to only draw the most important ways at these scales. But for that you’d need an assessment of importance, which is not really something you can readily find in the data and which ultimately is quite subjective and likely would not be very intuitive in many situations. Some map users for example might find it helpful if only those paths are shown that are part of a long distance trail. A local map user might on the other hand consider a different path more important because it is the shortest, easiest and most frequently used connection between two villages in the area.

One solution for tracks and paths at z13/14 i had already quickly tested some time ago is to drop the dashing and use continuous lines at these scales. This severely limits the possibilities to distinguish between different classes of paths – you can essentially only use the line width and color to differentiate and at narrow line widths it becomes more and more difficult to distinguish different colors because all pixels contain a mixture of background and line color.

One thing that prevented implementing this approach was the fact that cycleways in the standard style are traditionally rendered in blue color and a solid blue line looks just too much like a water feature intuitively. The use of blue color for cycleways has always been a sore spot but attempts to change that in the past were always hampered by the lack of other options. In particular the use of purple for boundaries creates severe limitations. Since i got rid of the purple boundaries i have some more freedom in that matter now.

Finding the right balance in colors, line widths and – at the higher zoom levels – the dashing patterns is difficult but i think the results are quite agreeable. This modification puts a stronger emphasis on footways and cycleways in the map but that in my eyes is mainly compensation for the under-representation they have in the standard style at the moment.

At z13 all lines are solid, the tracks vary in width slightly to indicate the tracktype but this variation is not large enough to reliably identify the individual track types although you can usually distinguish grade1 from grade4. Footways and cycleways are the same color (red) which can be distinguished from the track brown in nearly all situations.

(same areas in the standard style: here, here and here)

Overall the map image is much clearer and less noisy. You can better identify individual tracks and paths and their routes and connections, in particular in densely mapped areas although you loose the ability to differentiate between different types in not so densely mapped areas.

At z14 styling is very similar, the line width variation for tracks is somewhat stronger and i start using dashing for tracks without tracktype indicating to the mapper that important information is missing here.

(same areas in the standard style: here, here and here)

At z15 a white casing is added like it is also done in the standard style. Tracks are the same as in the standard style but cycleways are purple now and both cycleways and footways are stronger and differentiate clearly by surface type with long dashing for paved, short dashing for unpaved and alternating long/short for unspecified surface.

(same areas in the standard style: here and here)

I also considered differentiating out a third class of paths. The standard style some time ago removed that but this leads to the somewhat peculiar situation that highway=path + foot=designated + bicycle=designated is shown in cycleway color while highway=path without foot or bicycle tags is shown in footway color. But unfortunately mapping is often very inconsistent in this matter so this would not necessarily improve usability that much. The meaning of the colors essentially is:

  • purple: usable by bike, usually also on foot
  • red: usable on foot, maybe also by bike

At higher zoom levels the line width is slowly increased just like for tracks and the dashing is also slightly enlarged for better readability.

The style modifications for this can be found here.

I hope this description gives a tiny bit of insight into how map style design works when you systematically analyze and address problems. The actual coding is not that much work but analyzing the map rendering and identifying the problems on the one hand and adjusting and testing the various parameters, observing how the results affect the map viewing experience and how the different colors interact with each other in different geographic settings at different latitudes and resulting scales on the other hand are those things that are hard work.

In case you wonder what you can do as a mapper to allow for better readable rendering of tracks/footways/cycleways:

  • tag tracktype and surface where you know it.
  • tag access restrictions, in particular foot=* and bicycle=* as they apply.
  • although not currently rendered further information, in particular width=*, smoothness=* and sac_scale=* could be used to better differentiate rendering.

Tracks, footways and cycleways are not the only place where the standard style uses dashing and also not the only place where this leads to problems. Other situations where this leads to problems are administrative boundaries and intermittent waterways. There are already some improvement in these areas as well in the alternative-colors style. Maybe i will write about this in a future post.


  1. “Since i got rid of the purple boundaries” Is it discussed somewhere? This quote is a link that leads to page with an interesting article – but unfortunately without any mention of administrative border styling.

    There is “preprocessed boundary data” but it is almost completely unrelated to colour of admin borders.

  2. In general, some time ago I was irritated by purple borders and I experimented a bit with alternatives. None turned out to be promising so I abandoned the issue.

    I will certainly look at how this style works with new border styling, but if you wrote anything about that I am really interested in reading that.

Leave a Reply

Required fields are marked *.

By submitting your comment you agree to the privacy policy and agree to the information you provide (except for the email address) to be published on this blog.