Render mountain ranges (`natural=mountain_range` and `region:type=mountain_area`)

[ppete2]

Right now important labels of a map - montain ranges - are missing in Carto. There 2 ways of tagging them in use: a) natural=mountain_range b) place=region + region:type=mountain_area

Please render both of them!

As examples there are aleady other maps rendering them like http://gk.historic.place/historische_objekte/l/en/index.html or https://opentopomap.org/ or https://maps.bev.gv.at (brown labels in certain zoom levels, non-OSM)

[imagico]

Thanks for the suggestion.

• natural=mountain_range https://wiki.openstreetmap.org/wiki/Tag:natural%3Dmountain_range: 4651 uses, 2494 on nodes, 1626 on linear ways, 508 on polygons, the rest other relation types.
• place=region https://wiki.openstreetmap.org/wiki/Tag:place%3Dregion: 2939 uses , 1886 on nodes, the rest mostly polygons.
• region:type=mountain_area https://wiki.openstreetmap.org/wiki/Key:region:type undocumented for the specific value: 698 uses, 176 on nodes, 504 on polygons, the rest other relation types

A lot could be said on the issues this request would have even if there was one tag with clear consensus among mappers on its meaning and its use. But since this is not the case and we have various competing mapping ideas (not only in the form of different tags but also in the form of different schools of thought how to use them) there is not much point in actually having that discussion at this point.

I remember several, in parts quite inspired, discussions on the question on how to document verifiable local knowledge on how topography is structured, explicitly aiming to avoid pointlessly recording information that can be much better derived from digital elevation data.

Beyond that there have been considerations to collect non-verifiable data on geographical naming - like https://github.com/dieterdreist/OpenGeographyRegions or on wikidata.

My recommendation for anyone who is interested in this domain is to pursue these two fronts: (a) continue discussion in the OSM community to develop consensus on how to document verifiable local knowledge on how the topography is structured while avoiding the pitfall to try to include non-verifiable ideas in that and (b) pursuing projects outside of OpenStreetMap to collect and maintain non-verifiable data (because there is definitely interest among both data users and mappers in that field).

I suggest we close this because of the lack of a consistent and well established mapping and tagging practice with broad consensus among mappers.

[ppete2]

Thanks, I understand your sight and arguments!

On the other hand the in the map developers' view of e.g. gk.historic.place or opentopomap.org despite all mentioned point regarding competing mapping ideas etc. the Status Quo is worth enough to be rendered on their maps. They wouldn't do it if the current tagging/mapping situation is bad or misleading. OSM is a living project, where not everthing is defined into its finest detail. But also this not-so-well defined attributes like mountain-ranges are already telling important - and in most cases also correct - info which are worth to be rendered.

If I look at a large region like the Eastern Alps in gk.historic.place, almost every mountain-range's name and position is looking correct.

[imagico]

To be clear - i have deliberately not commented on the question if any of the features the suggested tags are used for is worth/desirable/practically possible to be mapped in OSM or to be displayed in a map or if the way this mapping is performed is a correct/suitable/efficient way to do so. That is not a discussion i will have here and also not a discussion for which this would be a suitable forum.

Different map design projects have different goals and premises. Most of them are primarily concerned with producing a useful map in the short term for a certain (usually relatively narrow) audience. We have other goals and that means that our criteria for rendering decisions differ significantly from other map design projects.

Our fairly firm stance on requiring consistent use and a clear consensus on this use among mappers for the tags we render (and that by the way does not necessarily require a language based definition of the tag) and the firm stance on not newly introducing rendering of tagging synonyms has grown from the painful experience of the OSM community due to past mistakes in that domain that have caused and still cause a lot of strife and irritation. The most famous case is the natural=wood vs. landuse=forest conflict - but there are plenty others (highway=path vs. highway=footway and natural=bay for example).

As already said: This is a domain where consensus building in the OSM community is still in a relatively early stage. My suggestion is to pursue this matter on that front and in particular to determine and establish what kind of information can be maintained within OpenStreetMap and what cannot.

[DevelWolf]

If I look at a large region like the Eastern Alps in gk.historic.place, almost every mountain-range's name and position is looking correct.

Maybe you should know about the history of this tagging.

It started with some discussion in the German OSM forum about the possibility of rendering the names of general geographic regions. Because there were no example data to use in the OSM database at this time, I added the subareas of the Eastern Alps: they are well-defined by the German and Austrian Alpine Club, and I only had to read the description “Alpine Club classification of the Eastern Alps” (https://en.wikipedia.org/wiki/Alpine_Club_classification_of_the_Eastern_Alps) and draw it to the OSM database.

The tagging “place=region;region:type=” resembles the situation at that time: the goal was not to capture mountain ranges, but geographic regions in general. The “region:type” could be used to control the rendering of the label.

User maxbe did some groundbreaking work to use this data to render the region names pleasantly to his topographic map (https://geo.dianacht.de/topo/?zoom=11&lat=47.21697&lon=10.62968) without overdrawing important map content. This algorithm was applied to the OpenTopoMap, too, when maxbe joined the OTM makers.

To my knowledge, the OTM uses a different render chain than the main OSM map; so you cannot apply the used algorithms directly to the OSM main map. Nevertheless, if you want to work on rendering region labels, this is the point to start at.

The OTM encountered some problems because of used software reaching end of life and the maintainers not having enough spare time to fix this. So the easiest way for you is to offer your time to help. (And raise some funds to be able to rent a high-end server, which solves a lot of problems without needing developer resources.)

The region displayed on “gk.historic.place” is an overlay, which does not take into account the underlying map and happily obscures existing features and labels. You cannot (at least should not) use this method to produce map tiles. The data processing chain of GHP computes the center and area of each area feature using basic standard math; we designed another algorithm to compute the “orientation” of each area feature, and use this data to place, size and rotate labels. The algorithm is very fast O(#nodes) and can be used to provide labels for a lot of regions (https://www.netzwolf.info/karten/water-areas.html), but by its very nature it's dumb: as said it does not take into account other layers including the base map. So you cannot base your work on it.

[DevelWolf]

Addendum to the stupidity of the algorithm: it does not even avoid overlaps within a layer created by itself. https://www.netzwolf.info/karten/regions.html?zoom=10&lat=46.87274&lon=10.9465 https://www.netzwolf.info/karten/regions.html?zoom=10&lat=46.44375&lon=12.04533 🙄

[mboeringa]

Addendum to the stupidity of the algorithm: it does not even avoid overlaps within a layer created by itself.

@DevelWolf

Well, a map showing mountain regions based on OSM data certainly doesn't have to look that way!

From my perpetually 'in-development' ArcGIS Renderer for OpenStreetMap, that I also presented at SOTM 2022 Firenze (Poster at https://files.osmfoundation.org/s/xDdDz3rpQX2C7FJ and all posters at https://2022.stateofthemap.org/posters/).

1:500k map:

[DevelWolf]

My comment was solely related to the area labelling algorithm we use on GHM (which was referenced in the starting post) for overlays, to explain why it cannot be a basis for labelling areas on tile layers. I have no relation to Carto or the OSM main map, and I have no need for the creation of map tiles.

[hungerburg]

From my perpetually 'in-development' ArcGIS Renderer for OpenStreetMap

The picture shows my homey region. It is not en par with what the hand-curated administration (tiles) or the hand-crafted rambling club (printed) offers, but it is quite fine. @mboeringa care to participate in opentopomap? Last I heard, they run low on fuel.

[mboeringa]

@hungerburg

As you probably understood if you've looked at the SOTM 2022 poster I linked, I work on a completely different platform - a GIS - then opentopomap or openstreetmap-carto, so have little to offer in terms of technical or other support, not even mentioning my own time constraints. I already invested a gargantuan amount of time in this.

Apart from my professional background, the choice for a GIS is also very much a conscious personal choice: I'd much rather work in a visual interface of a GIS to style my map, instead of having to hack my way through JSON, YAML or whatever textual style format other projects use, that often require you to set colors in HEX values, or having to define all label placement through sometimes very complex SQL rules... Of course, peoples' preferences differ, but this is my way of working.

Yes, the labeling results may not be on par with hand-curated national mapping agency's tiles with painstackingly hand-placed annotation labels, but that said, I think I am closer to reproducing a "national map" style in a fully automated global map, than many others, and in some ways surpass them. The SOTM poster shows one example.

[hungerburg]

@mboeringa Sorry, I did not want to diminish you work. Instead, this poster a very nice looking map with lots of detail in there all the while readable just fine. I think you are at or at least very close to what can be made out of openstreetmap data.

I like Venedigergruppe a lot - how it bows into the mapped area. Opentopomap can do that too, with mountain ranges and with lakes. A national map must have those and all the other named regions. They help orientation, make maps more useful. Obviously a lake is easier to circumscribe. E.g. Venedigergruppe on our national maps bows just the other way around. Because the border in OSM includes stuff, that might belong to Venedigergruppe (who knows for sure?) but is not relevant for labelling. Because, while Venedigergruppe is part of the Supergroup Hohe Tauern it contains Durreckgruppe, Panargenkamm und Lasörlinggruppe as Subgroups (if I can trust Wikipedia on this.) Yet a useful label should trace the Hauptkamm of it ;) To do that algorithmically some new tagging seems necessary. That might also help in deciding, what shows in which zoom. E.g. not everything here https://www.openstreetmap.org/relation/2113486 is of the same national importance. I think you are at or at least very close to what can be made out of openstreetmap data.

[mboeringa]

@hungerburg.

The specific issue you refer to of "non-curved" labels, where you would expect them to curve following the mountain chain, is actually an ArcGIS issue, that I personally consider a bug. I fully agree these labels should have been placed "curved".

I use ArcGIS's 'Maplex' label engine for the automatic labeling, and the specific label class used to label the moutain regions is set to use "Curved in polygon".

However, some three years ago, ESRI, the company behind ArcGIS, probably in the course of introducing some new options to Maplex, changed some of the heuristics guiding the label placement which affected the "Curved in polygon" labeling results.

Where previously most labels would be placed "curved" (as they should according to the Maplex setting), with the new heuristics it became more like "If label fits horizontally, place it horizontally, and only if it doesn't fit horizontally, place it curved".

I actually logged a bug with ESRI when I first noticed the change in labeling behavior. Unfortunately, although if I remember it well ESRI did make some efforts to enhance the results, the heuristics still prefer horizontal.

Unfortunately, there is not a lot more I can do, besides maybe stirring up this issue once again with ESRI...

Another issue of course, is that some of the mountain region polygons, do not have a clear orientation, e.g. https://www.openstreetmap.org/relation/2110287. If that is the real situation, then of course a simple "horizontal in polygon" fit of the label is fine, and curved doesn't make sense, and any automated heuristic for "Curved in polygon" likely won't be able to come up with a logical solution.

All that said, there is just one other thing I am currently trying out after your remark: I noticed a potential solution by creatively using another Maplex setting designed for placing labels on curvy river polygons. I hope this might change the result to more "curved" placed labels. I still need to wait for a large data import to test that out though.

Lastly, my Renderer's styles also support mountain ranges as non-closed linear ways, as there are quite a few of them in other parts of the world, which will of course always follow the curves of the line digitized (but some would call this undesirable "label painting").

[imagico]

Ok, i need to put a limit here now concerning how far to let this deviate from the subject. As much as i appreciate the interest in general map design questions - this is definitely too off-topic now in this issue.

If there is an interest in discussing labeling methods in this style (which certainly is a topic of interest for the project from my perspective) - please open a new issue for that. But please also there keep it goal oriented towards actually improving the style. Outside examples are often useful in that regard - but only as far as they provide useful inspiration for us.

I am closing this issue for the reasons mentioned above in https://github.com/gravitystorm/openstreetmap-carto/issues/4899#issuecomment-1801737070 and https://github.com/gravitystorm/openstreetmap-carto/issues/4899#issuecomment-1803608715. If there are developments in the consensus building process in the mapper community at large, pointers will of course be welcome here.