mapbox / mapbox/mapbox-gl-js

Reduce density for labels based on distance from camera

Open
#5,086 2 comments 0 reactions 0 assignees View on GitHub
cross-platform :tv:
Dominant language
TypeScript
Stars
12.4k
Forks
2.4k
PR merge metrics
No merged PRs in 30d

Description

Continuing the discussion from https://github.com/mapbox/mapbox-gl-js/issues/4704 and from chat:

In pitched maps, labels often appear denser in the background than in the foreground, because more vector tiles' worth of data is being shown in the background for the same number of pixels on the screen. This is the *opposite* of what would typically make sense from an information design perspective: generally, information in the foreground is more important and/or more in need of immediate attention by the viewer. Denser background labels distract from the higher-priority foreground labels:

E.g. Place labels in Mapbox Streets are often denser in the background than in the foreground:

screen shot 2017-08-02 at 4 44 42 pm

[Attenuating label size scaling with distance](https://github.com/mapbox/mapbox-gl-js/pull/4547) (i.e. halving the scale factor used to adjust label size based on distance) lessened this issue, because using proportionally larger labels/collision boxes in the background naturally reduces their density due to more labels being hidden through collisions (and conversely, using propertionally smaller labels in the foreground increases their density).

However, reducing density through collisions in this way is mainly helpful for a mid-range of label sizes and densities. If labels are very small and/or sparse (e.g. highway shields in Mapbox Streets, and other icons along lines), background labels don't necessarily face collisions. If labels are very large and/or dense (e.g. zoom level 16 POI labels in Mapbox Streets for very dense urban areas), there are already a lot of collisions in the foreground so the density ends up pretty even in the foreground and background.

So far we've discussed two approaches to improving the situation (that don't require redoing anchor placement when pitch changes):

## 1. For labels along line at a distance, remove every other anchor

See discussions starting from https://github.com/mapbox/mapbox-gl-js/issues/4704#issuecomment-319192573.

One advantage of pursuing the reduction of labels along a line specifically (instead or in addition to a more general approach) is that this just reduces density of *duplicate* labels, rather than hiding potentially useful labels that only appear once. (Of course this only helps with labels along lines, though).

Reposting @ChrisLoer's [first results into using this approach](https://github.com/mapbox/mapbox-gl-js/issues/4704#issuecomment-319485157), which look promising:

> Here's the status quo in a pitched view:

![screenshot 2017-08-01 13 09 35](https://user-images.githubusercontent.com/375121/28845157-ee1a3146-76bb-11e7-8904-eb747c27bd7e.png)

> And here's after removing every other anchor if the anchors have a "perspective ratio" > 1.1 (i.e. they're at least somewhat in the distance).

![screenshot 2017-08-01 13 09 15](https://user-images.githubusercontent.com/375121/28845158-ee1e375a-76bb-11e7-83d1-2d1b64ebc64a.png)

> This doesn't help at all for point-placed labels, which we use in Mapbox Streets below zoom level 11. We'd have to come up with some other solution to handle those in pitched views.

## 2. For all labels at a distance, make collision boxes larger than actual glyphs/icons

Perhaps we could try *not* scaling collision boxes in the background at all, or scaling them at a reduced factor, relative to the glyphs/icons?

/cc @ChrisLoer @mollymerp @ansis

Contributor guide

Open the contributing guide

Research direction

Start by reading the linked discussion in issue 4704 and the prior label-size work in pull request 4547, including the posted comparison results. The issue does not select an approach or name files or tests; completion would require an agreed implementation that reduces distant-label density without redoing anchor placement.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
frontend, web-dev
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.