Sparse road labels in dense road networks

[1ec5]

The hallmark of a traditional map is dense labeling, so a transportation map is characterized by dense road name labeling. Even though this map supports interactive zooming, making it technically unnecessary to label comprhensively until the highest zoom levels, it’s still jarring to see an area full of roads but bereft of road labels, as if the map is hiding something. While sparse labeling can contribute to a “clean” look, the user will find it frustrating to have to zoom in and out constantly to get information that could be represented more succinctly at lower zoom levels. It’s also difficult to infer any logic to which roads get labeled and which don’t. Sparse labeling is counterproductive when there’s a lack of balance.

In a typical American metropolitan area such as Cincinnati or Indianapolis, many inner-city and inner-surburban neighborhoods have a dense street grid with lots of intersections at right angles, while many outer-surburban and exurban neighborhoods have a slightly less dense, “dendritic” pattern of winding roads and cul-de-sacs. The style seems to think these places are boring enough to leave unlabeled. I disagree; we should try to at least bring a measure of balance to the label density in these places.

Normal	showCollisionBoxes

[1ec5]

There are many contributing factors to the suboptimal labeling.

As seen above, some of the missing labels are merely the result of label collision on overdrive. The label layer currently uses the default symbol-spacing of 250 pixels. While it makes sense to keep the labels along a given road this far apart, there’s no reason the labels of two parallel streets need to be this far apart. Unfortunately, symbol-spacing doesn’t seem to distinguish between spacing along a line and spacing globally: mapbox/mapbox-gl-js#4839. It would also be nice to vary the spacing depending on the road classification, but this would currently require multiple layers because the collision-related properties don’t support data-driven styling: mapbox/mapbox-gl-js#8454.

A minor related factor is that GL JS isn’t offsetting the labels’ collision boxes away from the road geometry (based on text-offset): maplibre/maplibre-gl-js#2171. At a T-intersection, GL JS expects a collision between a label running across the intersection and another beginning at the intersection. But visually, the label running across is offset away from the intersection, avoiding a conflict.

In some of these examples, the showCollisionBoxes option shows that there aren’t even candidate symbols to collide out. This happens especially often in suburban areas with winding roads. A text-max-angle property keeps GL JS from even attempting to place a label along a road near an angle of more than 20 degrees. In a low-speed residential area, a standard curve will consist of a series of angles that exceed this threshold. Unfortunately, increasing the text-max-angle any further would easily exacerbate visual artifacts (maplibre/maplibre-gl-js#2170) and overzealous collision detection (maplibre/maplibre-gl-js#2171).

Even with straight roads at right angles, the labels themselves are often too verbose. Planetiler currently doesn’t abbreviate common words in road names, even when it knows the name’s language: onthegomap/planetiler#14. But there are plenty of situations where even an abbreviated street name would be too much information. When you zoom in all the way, the user expects to see the road’s full name, but at lower zoom levels like z14, it’s OK to drop some common words like directionals and street types when there isn’t enough room. English-language maps in the U.S. commonly drop the words “Street” and “Road” before dropping anything else.¹

It’s possible to drop words either on the server side or the client side, but the client side has much less context. For example, North Bend Road is a road that goes to North Bend, not the portion of Bend Road in the northern quadrant of a street grid. On the server side, it would be possible to distinguish these cases using name:etymology or perhaps short_name.

So far, we’re labeling the literal road geometries, but maps conventionally extrapolate a label’s path to give it the necessary room. Fortunately, OpenMapTiles already puts the road geometries and their label geometries in separate layers, so it should be possible to extend the label geometries by a bit, as long as there’s some indication that the label should be left- or right-aligned along it.

A lot of the strategies above depend on upstream changes or at least would be a lot less hacky that way. But the style specification already supports some typographical features that we can use to shorten the text label to fit, such as line wrapping and tightening. We can employ these strategies to generate candidate symbols and rely on the normal collision code to weed them out if they’re redundant to a preferred label or would cause their own collisions with other symbols.

Footnotes

1. There are analogues in other languages, such as dropping “Rue” in French and “Calle” in Spanish. The convention to drop “Đường” in Vietnamese is so strong that a HOT-sponsored mapping guide for Vietnam recommends omitting it from name entirely. ↩

[1ec5]

Back in April, I pushed a 1ec5-label-density-793 branch that experiments with solutions to some of the road labeling problems identified above. Unfortunately I got massively sidetracked and haven’t had a chance to pick it back up, but anyone else is welcome to run with it.