I'm sure I'm missing something, but (1) flow labels along their roads to the center of the screen, (2) separate them with predefined padding, (3) drop labels if visible label count > maximum, smallest-to-largest road, until under the threshold.
If UXers want to bitch, hide it behind a layer filter. But honestly, #&@+ them. (Sorry, but we are talking about maps that don't show road names here)
That presumes that road names are an intrinsic part of a map. While they certainly were in the past, I think there's a paradigm shift happening that's become so common we don't notice it anymore. We don't tell people to meet us at "The intersection of Street X and Y" as much anymore, we tell them to meet us near a prominent landmark like a park, train station, or restaurant. We barely even need street names for navigation anymore; instead, our software tells us how many blocks to walk and when to turn (even automobile GPS tells us to expect turns in the next X miles). I feel this will be part of a larger revolution where we might start using alternative easy-to-shate GPS coordinates [0], and even completely new map styles like isochrone maps. [1]
[0]: See https://what3words.com/ and Google's https://plus.codes/
[1]: https://www.atlasobscura.com/articles/isochrone-maps-commute...
Citation needed. As a New Yorker, intersections of streets are how we do it all the time, when you want to meet on the street to walk somewhere together. "Meet me on 23rd and 8th."
> We barely even need street names for navigation anymore; instead, our software tells us how many blocks to walk and when to turn (even automobile GPS tells us to expect turns in the next X miles).
When streets are closely spaced, the name is absolutely necessary to know which one to turn onto -- you can pass a whole street in the time it takes the GPS to start and stop speaking and have no idea which street the "next street" refers to.
And plenty of people still walk or bike, where they check their phone only occasionally and memorize the name of the next street they need to stop at or turn on.
Sure there are new use cases, but the old ones aren't going away at all.
In my experience, navigation with Google Maps can be terrible about interchange / exit lanes. It's much easier just to pick the road name and follow the well-labelled and up-to-date highway signs.
So that's the navigational use case for 'meet person'
Another common use case is 'proceed to building at 123 Long Street'. I've met several confused tourists and couriers whose satnav has dumped them at, say, 973 Long Street with an arrival fanfare.
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.
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.
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.
Can you provide a use case where that would be necessary for a situation where you're not using the navigation? A lot of people seem to think this is a requirement for a map but when are you ever using a map to find a specific street where navigation wouldn't be far easier?
Do Google or Apple let you use navigation offline? I know it can continue an existing route if the connection drops, but I've never tried to start navigation somewhere while offline.
In any case, it seems reasonable to want a 'navigation' map without a specific path, just as you can get a 'discovery' map without a specific search.
