3 ms·

Anything moving on a screen will call attention to itself. A bunch of road labels "flowing" around at once turns into a huge mess. The real problem here is wi

by panic 8y ago

Anything moving on a screen will call attention to itself. A bunch of road labels "flowing" around at once turns into a huge mess. The real problem here is with label conflicts. Say you have an important point of interest in the center of the screen already. If a road label happens to be placed underneath the point of interest label, it will look like the road is unlabeled. There are clever ways of moving labels around, but: 1. it has to run in realtime on the client, and 2. it has to look good in motion and in all possible situations you can think of (since you have no control over what the data will end up being). This is why older raster maps often have better labeling than newer vector maps -- you can do a lot of precomputation on the server to make sure the labels look nice.

ethbro 8y ago
The purpose of flow layouts is to resolve exactly this problem at map movement time (e.g. user zoom or pan). Google Maps already does some flowing, it's just not very good at it once you zoom all the way in. If you have an important point of interest center-screen, then the lower priority labels flow away, or are priority pruned if overly numerous. This allows users to resolve invisible labels simply by zooming in. I'm absolutely in agreement on the performance challenges, which are likely the real reason precomputed labels seem to be used on Google Maps.
ryandrake 8y ago
Yes, you got it. Not only does it have to both look good motionless and in motion, but it has to look good at different speeds, and at smoothly changing zoom levels. Back in the olden days, there was no smooth zoom and pan, so you'd pre-compute labels at each discrete (logarithmic scale) zoom level and they'd remain fixed while panning around. And since panning happened in discrete steps, you wouldn't really notice labels repositioning themselves for each scene. Now, we have moving maps that scroll at whatever speed you're driving or moving, and arbitrary, smooth zooming, so you can't just let an algorithm take hold or you get labels popping in and out as the logic decides in real time where to put them. Users will find it distracting and weird, and most designers will say "no way". So you need to add things like debounce and hysteresis. You have to have resolve label conflicts in a way that doesn't always let (for example) POI names always take precedence. You have to determine whether/when to display street numbers vs street names. Do the locals call it I-880 or "Nimitz Freeway"? You have to keep labels right side up at arbitrary map rotations and along twisty road geometry (easy but yet more code). It adds up and requires these fiddly thresholds and scaling factors that are usually hidden from the user. As someone else pointed out, having sliders and preferences for every little tuning knob is always a no-go with the designers, who want everything to just magically work without configuration. As a programmer, I've always thought that "design minimalism" is cancer, but on the other hand, it provides constraints and makes the problem interesting to solve.
- crazygringo 8y ago
  This still doesn't explain why when you zoom in enough so there are no conflicts and items are sparse, every road can't be labeled somewhere along its length.

by panic 8y ago

ethbro 8y ago

The purpose of flow layouts is to resolve exactly this problem at map movement time (e.g. user zoom or pan). Google Maps already does some flowing, it's just not very good at it once you zoom all the way in. If you have an important point of interest center-screen, then the lower priority labels flow away, or are priority pruned if overly numerous. This allows users to resolve invisible labels simply by zooming in. I'm absolutely in agreement on the performance challenges, which are likely the real reason precomputed labels seem to be used on Google Maps.

ryandrake 8y ago

Yes, you got it. Not only does it have to both look good motionless and in motion, but it has to look good at different speeds, and at smoothly changing zoom levels. Back in the olden days, there was no smooth zoom and pan, so you'd pre-compute labels at each discrete (logarithmic scale) zoom level and they'd remain fixed while panning around. And since panning happened in discrete steps, you wouldn't really notice labels repositioning themselves for each scene. Now, we have moving maps that scroll at whatever speed you're driving or moving, and arbitrary, smooth zooming, so you can't just let an algorithm take hold or you get labels popping in and out as the logic decides in real time where to put them. Users will find it distracting and weird, and most designers will say "no way". So you need to add things like debounce and hysteresis. You have to have resolve label conflicts in a way that doesn't always let (for example) POI names always take precedence. You have to determine whether/when to display street numbers vs street names. Do the locals call it I-880 or "Nimitz Freeway"? You have to keep labels right side up at arbitrary map rotations and along twisty road geometry (easy but yet more code). It adds up and requires these fiddly thresholds and scaling factors that are usually hidden from the user. As someone else pointed out, having sliders and preferences for every little tuning knob is always a no-go with the designers, who want everything to just magically work without configuration. As a programmer, I've always thought that "design minimalism" is cancer, but on the other hand, it provides constraints and makes the problem interesting to solve.

crazygringo 8y ago
This still doesn't explain why when you zoom in enough so there are no conflicts and items are sparse, every road can't be labeled somewhere along its length.