"The only pub for 100 miles" (dynamic zoom)

[brycenesbitt]

Based on talking to Artem Pavlenko and Andy Allen at State of the Map USA 2013:

---

This issue is for support of dynamic zoom. It is motivated by mapping in the USA West Coast where there are large arid areas that are desolate in real life, but even more desolate on OpenStreetMap.

The proposal is to raise the minimum zoom level of POI features in sparse areas, worldwide. For example here is a virtually invisible feature that happens to be the only radiator or drinking water for at least 50 miles in any direction:
http://www.openstreetmap.org/?lat=42.7678&lon=-117.7278&zoom=12&layers=M

Or you could imagine the only pub in the district... should it not appear a bit more prominently? How about the only farm stand along a 50 mile section of highway?

---

I can think of several was to make this happen:

1. Before rendering each tile count the number of features that will render. If it is less than a certain threshold add one to the maximum zoom level for each POI. Lather rise repeat until there is something interesting to map. Render everything that overlaps the edge even if the adjacent tile is full of POI's.

2. Batch process all the PIO's in the planet file and calculate their nearest neighbour of the same type. Calculate a zoom level to pass to mapnik.

3. Create a feature heat map. At render time set zoom thresholds based on the heat map results (e.g. http://www.openheatmap.com/ )

Attempting this for roads would be too messy. I suggest this only for POI's and perhaps for small tagged building outlines.

Note that method #2 may elevate the prominence of otherwise obscure features, simply because there are few of them. Option #1 could be used the other way: to tone down the map in dense urban cores.

[springmeyer]

Hi @brycenesbitt - thanks for the thoughts, but I'm missing how this has to do with Mapnik? This bug tracker if for software features of Mapnik and not for the task of styling OSM data. Maybe you are looking to file an issue at https://github.com/gravitystorm/openstreetmap-carto?

[brycenesbitt]

I think this needs to be integrated into Mapnik software, as only the Mapnik software can readily count the number of features in a given region. Then OSM (or others) could use the Mapnik features to build dynamic style sheets.

[springmeyer]

What exactly needs to be integrated into Mapnik?

[tomhughes]

I think what he wants is a way of making style rules conditional on the number of other features in the general area, so that certain features will only render if there aren't many other features around.

I'm not sure it is necessary, or would even work, to do this at the mapnik level though.

Collision avoidance, combined with rule ordering, will already drop things when there are multiple features that conflict.

The reason that, for example, we don't render pubs at low zooms (even if collision avoidance would remove many of them in builtup areas) is that you might still get large numbers of them spattered across the map - what is wanted here is way, when rendering a tile, to look at a much larger area than just that one tile to see how pubs (or features in general) there are and then to render the pub if that feature density is low.

The requirement to look a larger area than the one being rendered means that doing it in mapnik is probably not a good fit however - it's more likely that some separate "feature density" database could be used to control things outside of mapnik code.

[brycenesbitt]

Yes, an external feature density database could do this work.
The zoom level range of a given feature could be tweaked before Mapnik sees it.
But you'd need to pass in a zoom level per feature, not per feature type. As I understand it, the current Mapnik XML only lets me give &maxscale and &minscale for a RULE.

---

To be clear this is the opposite of collision avoidance. The avoidance drops features. Here you want extra features to appear based on sparse density. And you may want to tweak avoidance at those levels also. A human cartographer, faced with a tight cluster of features at a desert gas station, might well draw them all in a cluster, even if that cluster intruded on the nearby empty space. The same density of features in New York City would bear little consideration.

---

Going a tile at a time you can calculate overall feature density, it might work just fine. If you want to get fancy and truly calculate the nearest "X" feature, that may be a better preprocessing job followed by dynamically adjusting the &maxscale and &minscale for the feature or feature class.

See also http://lists.openstreetmap.org/pipermail/talk/2012-March/thread.html#62286

What path forward might produce more interesting maps in sparse areas?

[tomhughes]

Please ignore the current XML stylesheet - the thing to look at going forward is the new carto stylesheet (https://github.com/gravitystorm/openstreetmap-carto).

It's not really the opposite of collision avoidance as such - my point there is that you would simply enable these features at a wider range of zooms and rely on collision avoidance to get rid of the excess ones. That has a similar effect to what you are talking about.

But yes, what you want does go rather beyond what collision avoidance can do, but it also goes beyond what mapnik can really do because (in the way OSM uses it) it is only looking at a very small area and the sort of "low density" detection you are talking about needs to look at rather wider areas.

You're quite right of course about a human cartographer deciding to keep a whole cluster in an otherwise empty area - to do that they would have to peturb some of them from their correct positions. That sort of thing is currently extremely hard in machine cartography because machines are not good at those kind of judgement calls in the way humans are.