-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reduce density for labels based on distance from camera #5086
Comments
Great write-up, @nickidlugash! I think there's one more issue that would still be a problem with either of the approaches above. Part of the reason the background looks so dense is because the foreground is relatively sparse. In the DC example above, the sparseness isn't really caused by collisions -- it's just that the near tiles are effectively over-zoomed and the tile doesn't have any labels to show in all the space that gets opened up. Solving that problem would either require increasing the density of labels in our tiles (adding expense to tile creation time, bandwidth, and client side rendering), or loading higher zoom level tiles for the near field (but that would introduce weird discontinuities between the different zoom levels). |
@ChrisLoer that's a good point that I glossed over in my write-up. When I used the term "foreground", I roughly meant "foreground and mid-ground" (where mid-ground would be the center of the viewport, i.e. the part of the map that is the same scale as a non-pitched map). To me this is still an open UX question, but my sense is that the mid-ground is actually the most important part of the map. This is where mobile users generally focus their eyes most. E.g., most navigation apps snap the user's location to roughly the center of the viewport (sometimes slightly below, but the user would typically be looking slightly ahead anyway). So I don't think we should be increasing density in the near field, but it's a question worth spending more time thinking about 🤔 |
Continuing the discussion from #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:
Attenuating label size scaling with distance (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 #4704 (comment).
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, which look promising:
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
The text was updated successfully, but these errors were encountered: