Recently, I've been working on code to draw metro maps procedurally. I'm not the first to do this, but detailed documentation is sparse on the ground.
I've found the journey fascinating but difficult, and even if my thoughts and approach aren't original, I figured I'd try to smooth the path for the next person tackling this problem.
I'm not a graphic designer, even though creating these maps is a very design heavy task. I apologize in advance if my names for things are wrong, or if I miss the obvious.
Also, my first exposure to a metro system was in Boston, so forgive me if I overuse the T as a reference in this series.
This first post is going to be observational, because in order for a procedural system to be effective, it must understand the systems it's implementing. Later posts will discuss the technical approach.
What makes a Metro Map?
Visually, metro maps are immediately recognizable. Some of this visual style is simply convention, but much is also shaped by practical concerns.
Maps are generally artifacts with a purpose. They are not just an artistic representation of the world, they are designed to store and communicate information to the reader.
Metro maps in particular are designed for a very challenging design environment. Many of the readers of a metro map have never seen it before, or have only seen it a few times. They are goal focused ("How do I get to Station X"), possibly quite stressed and in a hurry. They may lack even general familiarity with the layout of the city, and they are very probably spatially disoriented by being underground.
All of this leads to extreme minimalism in these maps. They need to avoid overwhelming the reader with information that is not critical. They cannot risk confusion between nearby lines and stations. Spatial relationships and directions are generally unhelpful. Most geographic features, like rivers, bridges, tunnels and parks, are only useful as high level ways to orient the reader. A metro rider doesn't need to figure out where they will cross a barrier like a river, they need to find the right train and get on it, and the train will handle the crossing.
As such, trains are typically represented with bright easy to differentiate colors (although many systems are not particularly friendly for colorblind users) and/or letters -- "the Red Line" or "the M train".
In fact, many metro systems fully abstract away direction altogether -- instead of heading "north" on the Red line in Boston, you go "Inbound" or "Outbound" relative to the city center, or take the train "to Alewife" at the end of the line. A user might think about the number of stops they have to take before getting off, rather than thinking in distance or time.
In short, metro maps do not respect either relative distances or relative directions, except in a very loose sense. They generally also do not attempt to encode travel time as distance. They do not have any meaningful "projection" from geographic coordinates onto the coordinates of the map.
Observations on the Visual Language of Metro Maps
For this section I want to note the excellent blog Transit Maps which contains a large collection of different transit and metro maps and visualizations.
Consistent Line Widths (and Striking Colors)
Most Metro Maps pick a single line width to represent almost all paths. The line width is large, often such that the width of a line is similar to the diameter of a station circle. The end effect is a collection of thick, colorful "worms".
Some maps include secondary transit systems, like buses, ferries, or light rail as a smaller stroke width, and often with desaturated colors (or even greyscale). Most maps use only a few line widths.
Rounded Features are Prefered
While far from universal, most maps round every feature as much as practical. Stations are generally represented as circles. Lines take turns with a minimum radius. Background features typically do not feature sharp edges. There are exceptions. Stations may be indicated as squares, or as sharp ticks on the line. Some man-made features, like piers may retain corners.
Octolinear Layout
Most metro maps choose to present paths as snapped to eight directions, with rounded corners. There are often small exceptions to this rule (e.g. circular lines, special lines like the Capital Airport Express in Beijing), but snapping the lines and stations to produce this effect is arguably the defining feature of a metro map.
There are also exceptions to this approach. For instance I found a fascinating unofficial map for the Paris Metro which uses hexalinear layout.
Welded Lines
When different lines run through the same set of stations, or exit the station in the same direction before departing, or run alongside each other for a long time, the lines are generally offset from each other to appear side by side. The result is a sort of "cable bundle" of different lines.
Notably is that these bundles tend to curve together -- the outer lines on a curve have a much larger radius of curvature than the inner lines.
Sometimes this bundle in annotated with additional information. For instance, the NYC subway map bundles rush-hour and non rush-hour trains together as different lines, and indicates the local stations on only one line.
Abstract Representations of Local Geography
Many maps include local features, particularly water features like bays, rivers, and coastlines. These features are typically redrawn with octolinear boundaries for visual consistency, and are therefore simplified. They are generally intended to crudely orient the viewer, especially if the entire map has been rotated away from up mapping to geographic north. Background geography is typically desaturated and pale -- it is not the focus of the map.
Closing Thoughts
Metro Maps aren't just a visual style that can be applied to geographic data. They're a type of data visualization, where the layout of the data is selected to minimize the potential confusion of the reader. That means repositioning stations to keep lines straight, or to enable clean offsets and bundling. It means selectively choosing which spatial relationships to keep, because the orient the reader, and which to eschew because they might confuse or disorient.
A human designer handles these problems through iteration (here's a fascinating video showing some of the process). A procedural system will have much less ability to iterate in a productive way.
Viewed from the perspective of creating a procedural generation system, I think my immediate takeaway is that it will be difficult to handle the spatial layout of a metro map, and will probably require iteration during graph layout or highly interconnected constraint systems. Even given a rough layout, producing a visually pleasing final position for all the different elements of a map that interact with each other will challenging.