Show important peaks sooner and fewer minor peaks on z11

[jeisenbe]

Expected behavior

Prominent and isolated peaks should be shown at mid zoom levels. It's common for large-scale maps to show the tallest mountain peak in a country, thus the most important mountain peaks should be shown as early as z8, when rivers are first shown.

Minor sub-peaks on the sides of larger mountains and insignifcant hills should not be shown until high-mid zoom levels (eg z14)

The names and elevations of important mountains should be rendered with priority. They should not be blocked by nearby minor peaks

Actual behavior

All natural=peak features are shown from z11 without names or elevation, and the names are shown at z10 without clear prioritization of prominent peaks. In areas where many small peaks have been mapped, the map is full of peak symbols at z11

While the icons of taller peaks are prioritized, the name label of a tall mountain can be blocked by a minor subsidiary peak; eg the tiny "South Summit" of Mt Everest blocks display of the main peak's name label at several zoom levels.

Possible Solutions

1) Use existing OSM tags, including name and elevation tags, to simply filter out less important peaks (i.e. those lacking names, elevation, or both).

• This can reduce the number of peaks in some areas, but many areas would still have too many at z11, and it would not be easy to filter for the 1% of most important peaks which could be shown at lower zoom levels.

2) Calculate an importance value for each peak based on the distance to the next higher peak

• This is similar to isolation, but would only look at the distance to other peaks (and saddles?) tagged with elevation
• Could be sufficient to show some very important peaks sooner, but would not work well in areas where elevation is not tagged for many peaks

3) Preprocess peaks from OSM database with a DEM (digital elevation model) to determine the isolation of each peak, and use this to help rank importance (along with name and elevation)

• Requires preprocessed data stored elsewhere or preprocessing along with a DEM at time of rendering
• Should allow a fairly robust importance rating for all peaks in the OSM database, including those that lack elevation tags
• Could be done frequently; daily basis

4) Preprocess peaks with a DEM to calculate prominence

• More complicated that finding isolation, because this requires creating a model of all ridge lines and saddles in addition to the location of peaks. However, prominence is considered a better importance rating for peaks by most mountaineers and climbers.
• Probably would need to be done infrequently; once per month, with results stored in a separate file (eg at osmdata.openstreetmap.de)

Links and screenshots illustrating the problem

• The name and elevation of Mt Everest are blocked by the icon for South Peak (a tiny bump on the ridge with prominence of only 10 meters)

https://www.openstreetmap.org/#map=11/-6.9384/107.4223

• z11 East of Bandung in Java, many peaks are shown, but it isn't clear what is the tallest mountain, or where the main ridgeline is located.

https://www.openstreetmap.org/#map=11/48.9651/19.2563

• z11 Many peaks are shown at z11 near Ruzomberok in Slovakia, but most do not add clear information to the map

https://www.openstreetmap.org/#map=11/-3.2416/119.0774

• z11 in Sulawesi, Indonesia. Showing all of these peaks equally at z11 is not very helpful.

Zooming out to z10 shows no peaks. Mauna Kea in Hawaii is the tallest peak for 1000s of kilometers in all directions, and an elevation of 4205 meters, but is not shown at z10. https://www.openstreetmap.org/node/2189450439#map=12/19.82069/-155.46804

[jeisenbe]

The idea of using external data (e.g. a DEM for elevation data) was discussed in #3720 where it was decided that using data from other crowdsourced databases (e.g. Wikidata) to find pre-calculated prominence or isolation values would not be a good idea, however use of a DEM may be possible.

[matkoniecz]

Use existing OSM tags, including name and elevation tags, to simply filter out less important peaks (i.e. those lacking names, elevation, or both).

https://taginfo.openstreetmap.org/tags/natural=peak#combinations - I am quite surprised that 28% of peaks has no specified name tag. It is quite weird and worth investigating.

[matkoniecz]

The name and elevation of Mt Everest are blocked by the icon for South Peak (a tiny bump on the ridge with prominence of only 10 meters)

Note that peaks are already rendered with priority, by elevation.

Adding new way of calculating priority will not help at all in this case.

Fixing this requires making possible to render high priority label before peak icon with a lower priority,

[jeisenbe]

Peaks are already rendered with priority, by elevation. Adding new way of calculating priority will not help at all in this case. Fixing this requires making possible to render high priority label before peak icon with a lower priority

It would solve the problem for low-mid zoom levels; for example, only peaks with isolation >10 km or prominence >200m might be shown at z9 to z12, thus Everest would be shown and South Peak would not.

It's true that additional changes would be required to fix the problem at mid-high zoom levels in some case, but having a better prioritization system could still be helpful. Checking for isolation in particular can make certain that there is enough room for a normal sized name label for the peak with higher priority.

[imagico]

Fixing this requires making possible to render high priority label before peak icon with a lower priority,

Note this is a problem that is not specific to peaks, you have it also with higher zoom level POIs (mostly the other way round - with labels disappearing as you zoom in because new icons turn up). This is one of the major problems i mentioned that need fixing in #3635.

[jeisenbe]

@imagico - would this be proper data to include at osmdata.openstreetmap.de (a file including all OSM peaks with their isolation or prominence, calculated automatically on a frequent basis)? I suppose there would need to be scripts and an example of the results first.

[imagico]

As said in another context i would suggest to discuss this based on a specific process once it exists and not in abstract form for something yet to be developed.

As also said i would in general be very careful with adding dependencies on external data to this style - no matter how it is produced. There would need to be a clear justification in terms of the goals we have that goes beyond a simple it looks better.

[Tomasz-W]

@jeisenbe Can you do something about this issue? It causes real mess in some places:

https://www.openstreetmap.org//#map=11/50.2006/16.6834 https://www.openstreetmap.org//#map=11/47.3914/7.6877 https://www.openstreetmap.org//#map=11/45.7761/14.1133

[matkoniecz]

@Tomasz-W Please, avoid +1 comments. Reactions added by Github are much better way to express that ( see https://github.blog/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/ guide for how one may use them )

[Tomasz-W]

@matkoniecz Please avoid looking for a problem everywhere. Commenting abandoned tickets is a common way to suggest coders which issues are more important and which are less. Reactions don't provide notifications while comments do.

[matkoniecz]

Reactions don't provide notifications while comments do.

That is the main reason why +1 comments are awful and unwanted.

[jeisenbe]

Here's another example, from all the way up at 53 degrees north in Wales; there would only be 60% as much space between peaks at the equator for an area mapped similarly, leading to even more collisions:

Is it possible to calculate the distance to the nearest natural=peak node in SQL?

That would be a simpler version of "isolation" which could work well to avoid rendering minor peaks at z11 and z12.

[kennykb]

"Feature density" is something that would be nice to have for all POI's, but I haven't found anything better yet than what we already do: try to order features by some sort of importance, and then suppress ones that would paint over existing ones - that's done in Mapnik of course.

"Find the nearest neighbouring peak" is doable in PostGIS but it's pretty horrific. It's a special case of "find the K nearest neighbours", and it really needs you to create an index to support the query, since the search HAS to be with the <-> operator and there has to be a LIMIT clause in the subquery. It's also a very bad thing to do in bulk; if you have a set (like the peaks in a super-tile) and need nearest-neighbor for all of them, the time to find the neighbours goes up faster than linearly. It's almost certainly better to do some sort of processing on top of ST_DelaunayTriangles instead. In any case, this will not be a fast query. It's rather a difficult question that we're asking, and the answer will be corrrespondingly expensive to compute.

I've experimented with some other approaches in maps that I render. One thing that, while not entirely satisfactory, has at least improved matters for me is to start rendering 'buillt' PoI's at a different zoom level depending on whether the area is 'urban' or 'rural' That mans that I can continue to show availability of services at low zoom in the countryside without turning the cities into totally unreadable clutter. Here, the working definition of 'urban' is 'intersects the polygon for an urban area in Natural Earth's 1:10 000 000-scale data. The query to return PoI's looks like

       (SELECT way, aerialway, aeroway, amenity, highway, leisure,
               man_made, "natural", "power", railway, religion,
               tourism, waterway, (u.ogc_fid IS NOT NULL) AS urban
    FROM
        (SELECT ST_PointOnSurface(way) AS way,
                aerialway, aeroway, amenity, highway, leisure,
                man_made, "natural", power, railway, religion, 
                tourism, waterway
         FROM &db_osm_polygon_table;
         WHERE
       (aerialway IN ('station')
        OR aeroway IN ('aerodrome', 'airport')
            -- about a dozen more OR conditions go here!
          )
      AND ST_Intersects(way, ST_SetSRID(!bbox!,3857))

         UNION
         SELECT way,
            aerialway, aeroway, amenity, highway, leisure, 
                man_made, "natural", power, railway, religion, tourism, waterway
         FROM &db_osm_point_table;
         WHERE
       (aerialway IN ('station')
        OR aeroway IN ('aerodrome', 'airport')
            -- about a dozen more OR conditions go here!
          )
      AND ST_Intersects(way, ST_SetSRID(!bbox!,3857))) t
      LEFT JOIN ne_10m_urban_areas u
      ON ST_INTERSECTS(t.way, u.wkb_geometry)
    ) AS Result

For maintainability, I really need to rewrite that monster with WITH clauses instead of nested SELECT's.

I don't find the fact that the same type of PoI might appear at a different zoom level depending on context to be terribly distracting. Most users of the maps simply zoom until enough detail appears, and decluttering only helps.

The 'urban-rural' distinction is, to me, even more critical than the latitude-dependent one. There would be a difference of almost exactly 1 zoom level in going from Quito to Oslo. Two zoom levels would go to the latitude of Longyearbyen, and there's very little mapping in the extreme polar regions. (We'd need a whole different approach for mapping up there - polar-stereographic perhaps.) By contrast, I find that to get a good feature density in the countryside as opposed to the cities, a 2-3 zoom level difference is routine.

The use of Mercator at extremely low (z3 for instance) is certainly of tremendous political significance, because it does overemphasize the northern latitudes and produce a Eurocentric map. It's of little consequence at high zoom levels, where the scale distortion is no longer apparent and you're left with a much less consequential amount of feature clutter.

Since there's really no good answer if you presuppose a rectangular canvas that will be recursively divided into tiles of progressively smaller size, the map scale question may not have a general answer at our current level of technology.

[jeisenbe]

urban-rural distinction

Peaks are too dense even in very rural areas and at high latitudes, like the example at 53 north in Wales, so neither a change in map projection or differentiating rural and urban areas would help with this particular issue.

really no good answer if you presuppose a rectangular canvas that will be recursively divided into tiles of progressively smaller size

OT: While it would be difficult to change this map style away from mercator (since all existing links to maps on the openstreetmap.org main page assume this projection) there's no technical reason that you can't render your own web maps in a rectangular equal-area projection: https://en.wikipedia.org/wiki/Cylindrical_equal-area_projection

[c933103]

Could improvement be made by introducing new tags, like prominence=\* (although I am not sure how can such data be freely obtained/verified), or main_peak=yes, although I am not sure about how can you define it.

[StyXman]

Just some random thoughts here: Take in account that we use Mapnik, and we're limited by it.

In particular, peak symbols and their names are handled in two different layers; first the symbols, then the names. Also symbols and text fight for the same space, and because symbols are drawn first, they're mostly not being drawn in places with dense peaks. That's actually what's going on with your sshot about the Everest: its label has no space because the symbol for the South Peak is already there.

I tried by putting the peaks on their own layer and try to add some margin, bur MarkerSymbolizer does not have a margin attribute. I tried to let text overlap, but it overlaps itself and becomes unreadable. I wish Mapnik was more maintained and/or easier to modify.