Rendering of valleys, ridges and other mountain elements

[Ircama]

Rendering of valleys, ridges and other mountain elements

[Revised summary]

This PR introduces the rendering of the following essential mountain elements, which were previously unmanaged:
•natural=ridge (name and symbol)
•natural=arete (name and symbol)
•natural=dale (only name)
•natural=gorge (only name)
•natural=couloir (only name)
•natural=valley (only name)
•natural=mountain_range (only name)
•natural=massif (only name)

All elements names have appropriate and distinct colors, to help mappers in the correct representation of these features. Aretes and ridges are also rendered with proper symbols.

[imagico]

A few points here:

• you should show some sample renderings demonstrating the effect of your changes
• you seem to be showing valleys/ridges with labels only - as mentioned in Rendering of natural=ridge #1148 (comment) this is problematic since it will likely result in frequent abuse of these tags for just placing labels
• also the rest of the discussion in Rendering of natural=ridge #1148 might be useful to read - in particular the question how to treat natural=arete.
• you do not seem to modify the existing rendering of natural=glacier so it is unclear to me how your change is supposed to interact with that.

[Ircama]

http://www.openstreetmap.org/#map=11/45.8020/9.9825

http://www.openstreetmap.org/#map=14/45.9294/10.0484

http://www.openstreetmap.org/#map=15/45.9222/10.0402

[mboeringa]

Not a critique of your work, but the rendering does highlight one huge caveat for rendering this type of "mountain" feature: it really needs height contours to truly make sense of things like valley names, ridges and aretes, peaks etc. ...

[Ircama]

@mboeringa: please apologize, I did not comment my previous post: the red ellipses are not really rendered, but manually edited by me (roughly) over each print-screen in order to highlight the names appearing with my suggested modification and that are not currently rendered in the related links that I posted.

@imagico: Thanks for your post, I’ll leave out natural=glacier and check once again #1148 before answering.

[mboeringa]

@mboeringa: please apologize, I did not comment my previous post: the red ellipses are not really rendered, but manually edited by me (roughly) over each print-screen in order to highlight the names appearing with my suggested modification and that are not currently rendered in the related links that I posted.

@Ircama : I fully understood that the red ellipses were just for highlighting, and wouldn't be rendered. I just wanted to point out that all of these mountain features actually need height contours to really make sense. Again, this is not a critique of your work on this rendering for valleys, which looks quite nice, but a general remark also relating to e.g. the current peak rendering already implemented.

[Ircama]

@mboeringa: OK. The drop that I submitted for validation is confined to the rendering of tags like natural=valley and natural=ridge. I'm going to provide an update following received feedbacks.
If you are anyway referring to overlays like http://wiki.openstreetmap.org/wiki/Contours, this should be a separate implementation.

[mboeringa]

If you are anyway referring to overlays like http://wiki.openstreetmap.org/wiki/Contours, this should be a separate implementation.

Agree.

[Ircama]

you seem to be showing valleys/ridges with labels only - as mentioned in #1148 (comment) this is problematic since it will likely result in frequent abuse of these tags for just placing labels

Referring to this, I would agree with @mboeringa 's considerations in #1148. It is a reasonable risk and OSM already allows many ways to place generic tabs.

all of these mountain features actually need height contours to really make sense

Ideally, a spatial interpolation of digital elevation model, rock polygons and specific linear tags (aretes, ridges, couloirs, etc.) could digitally address what cartographers manually draw to represent ridges on classic topographic maps; this should of course require a remarkable Mapnik upgrade, anyway beyond my capabilities. I'll just try to barely draw labels and symbols.

'natural=ridge' might not only mark gentle crests (that should not be sharp or rocky ridges anyway, for which natural=arete should be used instead), but could also cover named hillsides or relevant slopes, that should have a name but might not deserve a graphical symbol (just its name represented as inline text could be enough to show the related form of the mountainside area). Conversely, a (sharp) crest that could be (almost) precisely identified would need natural=arete.

That said, please, check this preliminary testing image: orange is a wide ridge without name (for all big ridges and for the ones, even small, without a name, a smooth symbol is represented), green is a small ridge with a name (and without symbol, as it is < 5 km and has a name), red is an arete (dolomitic shape of Presolana mountain) with a name (and its symbol, as all aretes have the symbol, regardless lenght and presence of name), blue is a cliff.
Do you find this appropriate?

I am trying at the end to render the following tags:

• natural=ridge (name and symbol, see example)
• natural=arete (name and symbol, see example)
• natural=dale (only name in specific color)
• natural=gorge (only name in specific color)
• natural=couloir (only name in specific color)
• natural=valley (only name in specific color)
• natural=mountain_range (only name, similar to valley, but with different color)
• natural=massif (only name)
  At the moment the minimum zoom to possibly render them is 10.
  natural=cliff will remain unchanged.

[imagico]

It is a reasonable risk

Note this is not a risk, experience elsewhere tells that this will happen. So the questions is if this is considered an acceptable side effect. IMO not - it is the responsibility of this style due to its prominent exposure to try its best not to adversely affect mapping decisions even if this comes at the price of a less that ideal map quality in some cases.

and OSM already allows many ways to place generic tabs

The most famous and most widely abused generic label tag currently is place=locality which likely has more abusive uses than justified ones. However this is still much less prone to abuse since it is points only and only starts at z15. But most importantly other label only point features (things like natural=bay etc.) are much easier to falsify so abuse can be spotted and fixed much better.

The wiki page for natural=valley currently also explicitly states label placement to be the purpose of the tag which is at odds with the general principles of OSM - i added a note there in that regard.

As said in #1148 i would support rendering ridges with lines and labels although it is of course not so easy to do this in a way that looks good considering the wide range of applications for natural=ridge (which includes many cases where the tag does not really apply). Valleys OTOH i would only consider if the tag definition is sufficiently sharp and generic and mapping mostly complies with that definition.

Don't get me wrong - your renderings look quite nice, especially considering the limitations of the tools used. My objections are unrelated to the specific design.

These things aside your sample renderings show valley labels overlapping with other labels - this would need to be fixed.

[Ircama]

it is the responsibility of this style due to its prominent exposure to try its best not to adversely affect mapping decisions even if this comes at the price of a less that ideal map quality in some cases.

Maybe there are two different topics that could be separately adressed. Are you sure that the rendering process shall be able to effectively compensate the drawbacks of the unrestricted updating policies of OSM? I would think that its price will be too high.

The wiki page for natural=valley currently also explicitly states label placement to be the purpose of the tag which is at odds with the general principles of OSM - i added a note there in that regard.

However I wonder whether this is limiting the quality of topographic data in OSM. To me OSM is currently unusable when representing mountains, as data is poor also for trivial usage. So I would consider appropriate to encourage the insertion of geographical data and long time will be possibly needed to fill the current huge gap.

For instance, we have 327943 named peaks now in OSM, but only 36644 ridges. Consider that one peak should have one or more named ridges, so there is a serious problem in OSM now. Also, we have only 5664 valleys: 47 peaks per valley means that at the moment this information has no quality.

Now, peaks are represented in Mapnik, while ridges and valleys aren't.

The policy behind this situation might have some responsibilities.

Valleys OTOH i would only consider if the tag definition is sufficiently sharp and generic and mapping mostly complies with that definition.

Drawing valleys with a symbol is better than not rendering them at all, but IMHO might not be appropriate from the graphical point of view. For instance, please consider this old-school map I have just found in Internet:

http://satlavis.weebly.com/uploads/3/2/4/9/3249414/kompass_-_59_gruppo_sella-_marmolada.jpg

Produced in the late 70's with touristic targets, it still presents virtually unachievable quality when compared with the current version OSM/Mapnik.

http://www.openstreetmap.org/#map=14/46.4626/11.8443

And valleys are represented there in the correct way.

These things aside your sample renderings show valley labels overlapping with other labels - this would need to be fixed.

What I am using now to test:

text-placement: line;
text-placement-type: simple;
text-placements: "N,S,E,W,NE,SE,NW,SW,18,16,14,12,10,9,8";
text-label-position-tolerance:10;
//[zoom >= 11] { text-allow-overlap: true; }

If I keep the last line commented out, even if the remaining configuration looks pretty tolerant, the name of the valley might not be rendered for some zoom levels. And we might not love this of course :-) Please advise.

Anyway, in the Marmolada map that I linked, you can see that sometimes (rarely) labels overlap.

[imagico]

Much of what you wrote about map design in general and OSM mapping practice goes beyond the scope of this issue tracker. Discussion on how to map and tag valleys, ridges and other things should take place on the mailing lists and wiki. Note my critique of the current definition of the valley tag does not mean i am against mapping valleys in principle. And i am right with you regarding the problem that some types of features are enormously underrepresented in the OSM database.

Are you sure that the rendering process shall be able to effectively compensate the drawbacks of the unrestricted updating policies of OSM?

I am not sure what you mean with unrestricted updating policies of OSM.

Regarding valley rendering in general - creating high quality labels would require tuning the label configuration (position, direction, curving, letter spacing etc.) with consideration of the valley form (which is what would need to be mapped) and the other map elements and in interaction with other labels in the map. Doing so would not only result in a nicer map, it would also significantly reduce the problem of mapping for the renderer since the label would not be shown exactly where the mapper placed the corresponding feature anyway.

This however is not possible at the moment in a real time updated tiled map.

If I keep the last line commented out, even if the remaining configuration looks pretty tolerant, the name of the valley might not be rendered for some zoom levels. And we might not love this of course :-) Please advise.

Labeling consistency across zoom levels in this style leaves much to the desired. In general a label that is rendered at one zoom level should also appear on all higher zoom levels unless labels for this kind of feature are removed in general at a certain level. To achieve this label priorities need to be in the order of the zoom levels they appear in (which is currently not universally done in this style).

And labels with characters overlapping characters of other labels is a big no-no in cartography. Labels may cross if characters do not intersect but most map rendering systems do not support this. And avoiding overlaps is definitely more important than cross-zoom-level-consistency.

[Ircama]

you seem to be showing valleys/ridges with labels only - as mentioned in #1148 (comment) this is problematic since it will likely result in frequent abuse of these tags for just placing labels

Also following previous comments, am I correctly interpreting your suggestions for valleys?

• Points: #text-point, rendered in my drop, problematic for you, since it will likely result in frequent abuse of these tags for just placing labels
• Lines: #text-line, rendered in my drop, fine with you, so that a mapper shall appropriately draw the line in order to have its name rendered.
• Polygons: #amenity-points-poly, rendered in my drop, fine with you

I can remove #text-point in this case, or set #text-point[zoom >= 15], let me know.

avoiding overlaps is definitely more important than cross-zoom-level-consistency.

OK thanks, I'll set text-allow-overlap: false;

[imagico]

Also following previous comments, am I correctly interpreting your suggestions for valleys?

No, my suggestions for valleys are:

1. creating a consistent, well defined and universally applicable and verifiable mapping and tagging concept for valleys. This is difficult since neither of the standard data structures of the OSM data model (nodes, linear ways and areas) are well suited for this task. But it is doable.
2. convincing mappers to adopt this system.
3. making sure practical mapping adheres to this system (by communicating with mappers who use it incorrectly and establishing good practice for others to take as an example).
4. create a rendering proposal here that well represents and supports the mapping scheme.

This probably sounds like a lot of work and a long process but if 1. is done well 2. and 3. usually do not take long. And with a well defined concept a few hundred features mapped by a dozen mappers are often sufficient to add something here if it integrates well with the rest of the map.

With ridges this process is already much further ahead - there is some distinct lack in 3. partly due to the lack of clear limits in the definition of a ridge (towards mountain ranges, arete and cliff in particular). But here we are clearly at a point where rendering ridges (in a way that indicates a ridge and not just something linear with a name) could help to improve the data.

[Ircama]

@imagico: your suggested methodology is valid, also in the consideration that the currently populated database is very limited; through simple and consistent guidelines together with a well defined communication concept, mappers can be quickly driven to the most effective process. Of course, this model should be iterative and continuously improving.

I fully agree that "creating high quality labels would require tuning the label configuration (position, direction, curving, letter spacing etc.) with consideration of the valley form (which is what would need to be mapped) and the other map elements and in interaction with other labels in the map."

With reference to the technical aspects, I have pushed a new commit.

The following elements are now rendered:

• natural=ridge (name and symbol)
  

• natural=arete (name and symbol)
  

• natural=dale (only name)
  

• natural=gorge (only name)
  

• natural=couloir (only name)
  

• natural=valley (only name)
  

• natural=mountain_range (only name)
  

• natural=massif (only name)
  

Aretes and ridges, other than allowing names, are rendered with proper symbols.
All elements have distinct colors.
The minimum zoom to possibly show lines is 10.
To discourage defining elements with labels only, points will be visible only with zoom >= 15.
To encourage using lines vs. polylines for these elements, lines are better rendered, more clearly than polylines.
Labels do not overlap.
Finally, natural=cliff and natural=glacier remain unchanged (modifications in my previous commit have been reverted, apart from the minimum zoom level for cliff names, which is now 11).

[Ircama]

[imagico]

I suggest you

• drop everything but ridge/arete in this PR to be able to concentrate on one thing.
• drop any complex and non-intuitive logic regarding the name.
• change the line_length field to a way_pixels equivalent (i.e. normalize with the rendering resolution), this is better readable and usually simplifies the mss code.
• reconsider the length limit for showing/not showing ridges - this would often lead to missing segments within a network of ridges.
• reconsider the starting zoom level - there is a reason why natural=cliff is not rendered below z=13. At low latitudes at z=10 a ridge of less than 10km length makes no sense to display, even with a very compact styling - with your current styling the limit would be more around 30km and continuous ridges of this length are very rare - most cases with this length in the database are abuse of natural=ridge for mountain ranges.
• differentiate ridge/arete in a way that clearly communicates arete is a sharper feature
• at the higher zoom levels render with a clearly visible center line - does not have to be a continuous line or be very prominent but should allow mappers to verify if the way is placed at exactly the right position.
• drop labeling of polygon features for ridge/arete - neither should be mapped as areas so these should not be shown.
• look if you can improve visibility of paths/footways above ridges - this is fairly poor right now at the lower zoom levels.
• test in some other areas, ridge mapping is particularly popular in Russia and other former Soviet countries. See for example the Caucasus mountains: http://overpass-turbo.eu/s/gAi

[imagico]

Addition:

i would probably also drop rendering ridges mapped as nodes. Although in principle it is all right in OSM to map something as a node if you have no more detailed information this is not a common case in reality for ridges. Nearly all of the nodes with the ridge tag in the database right now are from imports, mostly in Norway. I don't think there is a gain from rendering these with labels.

[Ircama]

I'm surprised. Why do you want me to drop valleys? It was the starting point of my initiative...

[imagico]

I am only suggesting not to take on too much at once. So far none of the maintainers here have commented on your proposal but it is unlikely any of them is satisfied with everything in it so you significantly increase the chances of at least some of it making it into the map if you split it into smaller packages.

Also keep in mind that you can never reliably test your changes without a full planet database so it makes sense to first see how some if it works in the real whole world, learn from the results, consider feedback from users and refine your approach before taking the next step.

[dieterdreist]

sent from a phone

Il giorno 01 giu 2016, alle ore 23:54, Christoph Hormann notifications@github.com ha scritto:

This however is not possible at the moment in a real time updated tiled map.

we could mix them in from precomputed e.g. shapefiles (that get frequently updated, similar to the coastline process.) Valleys don't change that much...

[dieterdreist]

sent from a phone

Il giorno 01 giu 2016, alle ore 23:54, Christoph Hormann notifications@github.com ha scritto:

To achieve this label priorities need to be in the order of the zoom levels they appear in (which is currently not universally done in this style).

there's also an advantage in the way it is done now. The importance of labels changes at different scales (because the intention and context of the map change at different scales).

Take Paris for example, in zoom6 the label is very important: http://www.openstreetmap.org/#map=6/48.951/2.362

also at zoom7 ;-)
http://www.openstreetmap.org/#map=7/48.951/2.362

(yes, there is a consistency problem in this case, because similar cities are labeled at this zoom)

But you don't want it in zoom13, because Paris is not a spot at this scale, it is everywhere:
http://www.openstreetmap.org/#map=13/48.8551/2.3496

(and indeed from zoom 14 on, the label disappears as it should)

Similarly you might want a big building labeled early, but at high zooms you would give more priority to the constituents and put the label for the bigger part wherever space remains, if at all.

When the thing being labeled extends significantly the size of the screen that you look on, then a label can be more confusing than helpful.

[Ircama]

there's also an advantage in the way it is done now. The importance of labels changes at different scales (because the intention and context of the map change at different scales).

your consideration on zooms is clear and I had it in mind; I anyway think that I implemented an appropriate configuration for these mountain elements, which would need such rendering for labels; in my point of view the defined settings are valid for each zoom and I of course compared the results many times with standard topographic maps.

change the line_length field to a way_pixels equivalent (i.e. normalize with the rendering resolution), this is better readable and usually simplifies the mss code.

I considered this and think that line_length is an appropriate parameter for these elements, where the rendering shall be based on the real length. If you have a way_pixels equivalent (working for lines) that behaves the same as line_length but is more performant, please advise.

reconsider the length limit for showing/not showing ridges - this would often lead to missing segments within a network of ridges.

I reduced the min length to 2.5 km. Consider that there might be cases where for a single peak e.g. 10 or more small ridges are present; this might lead to clog the mountain with too many symbols.

reconsider the starting zoom level - there is a reason why natural=cliff is not rendered below z=13. At low latitudes at z=10 a ridge of less than 10km length makes no sense to display, even with a very compact styling - with your current styling the limit would be more around 30km and continuous ridges of this length are very rare - most cases with this length in the database are abuse of natural=ridge for mountain ranges.

Please check the samples.

differentiate ridge/arete in a way that clearly communicates arete is a sharper feature

I revised the symbol

at the higher zoom levels render with a clearly visible center line - does not have to be a continuous line or be very prominent but should allow mappers to verify if the way is placed at exactly the right position

I revised the symbol

drop labeling of polygon features for ridge/arete - neither should be mapped as areas so these should not be shown

By now I changed the rendering zoom setting it to >= 14

I would probably also drop rendering ridges mapped as nodes. Although in principle it is all right in OSM to map something as a node if you have no more detailed information this is not a common case in reality for ridges. Nearly all of the nodes with the ridge tag in the database right now are from imports, mostly in Norway. I don't think there is a gain from rendering these with labels.

There might be some small ridges anyway that someone might quickly represent as nodes, in order to promptly provide a locally acquired name; representing them at high zoom level contributes enriching data from one side, and from the other helps mappers when subsequently converting nodes to lines, so that nodes will not remain there, other than lines.

Please find below some examples based on the geographic area indicated by imagico.

This is an arete:

[dieterdreist]

sent from a phone

Il giorno 03 giu 2016, alle ore 04:02, Ircama notifications@github.com ha scritto:

your consideration on zooms is clear and I had it in mind; I anyway think that I implemented an appropriate configuration for these mountain elements, which would need such rendering for labels; in my point of view the defined settings are valid for each zoom and I of course compared the results many times with standard topographic maps.

I believe you misread this, it was a reply to Christoph against his idea to strictly keep rendering priority throughout all zoom levels, while I believe that different zoom levels can have different priorities for things because those different scales serve different purposes.

[imagico]

Thanks for the examples. For me they confirm that z10 is too early to start displaying ridges - they are mostly noise at this scale. Keep in mind this is already 43 degrees latitude.

If you have a way_pixels equivalent (working for lines) that behaves the same as line_length but is more performant, please advise.

The equivalent would be

ST_Length(way)/NULLIF(!pixel_width!::real,0) AS way_pixels

This would allow you to make equivalent labeling decisions at different zoom levels with a single rule.

I reduced the min length to 2.5 km.

It does not matter what length limit you use - you will still have segments missing heavily distorting the results. You can see that in your example in the area of my overpass link and along the main watershed quite well.

I revised the symbol

I probably did not explain myself sufficiently here. I think the pattern for arete needs to be significantly more articulated, less blurry, more line-like than for ridge. The side structures in the arete pattern by the way are a bit problematic since they are directed indicating the direction has meaning (which it does not).

And both patterns should IMO have a visible center line at the higher zooms that allows the viewer to locate the way location within a pixel accuracy.

In general based on your new examples the pattern appears a bit noisy, especially at the low zooms. It might be a good idea to design it as SVG - you could use jsdotpattern for the base pattern and modify it with inkscape. This gives you better control on the sub-pixel level than pixel painting it.

There might be some small ridges anyway that someone might quickly represent as nodes

As said if you look at the data this is not a practically common case. A mapper who can identify a ridge generally is also able to create a way instead of a node. It is good if the style urges him/her to do so.

[dieterdreist]

2016-06-02 22:24 GMT+02:00 Martin Koppenhoefer dieterdreist@gmail.com:

But you don't want it in zoom13, because Paris is not a spot at this
scale, it is everywhere:
http://www.openstreetmap.org/#map=13/48.8551/2.3496

I have to adjust this, it really depends on your screen size here, only on
a phone the above is correct, on a full-hd resolution it is justified to
have a label for Paris at z13 (and not on z14 and higher - as it is now
already).

[Ircama]

z10 is too early to start displaying ridges

IMHO it is fairly decent as a first rendering attempt. I also tried to check with a satellite image and different renderers.




Anyway a feedback from the author who defined these elements would be the most influential, because he might know these territories very well and he could also have experience on how they are represented in their standard cartography.

ST_Length(way)/NULLIF(!pixel_width!::real,0) AS way_pixels

OK, I see, you are still using ST_Length, as I did. I’m afraid anyway that the ratio you added is not what we need, as in such mode way_pixels will be relative to the zoom level; we need absolute values instead for quality rendering of these elements.

It does not matter what length limit you use - you will still have segments missing heavily distorting the results. You can see that in your example in the area of my overpass link and along the main watershed quite well.

Maybe I did not realize here. Please explain better with a graphical example. Which are the segments you find missing and where do you find distorted results?

the pattern for arete needs to be significantly more articulated

Mine would be a starting point to render these objects and above all to finally allow showing a name for them.
Stat Roma pristina nomine, nomina nuda tenemus.
I’m sure that there are a lot of graphic designers willing to contribute, in order to enhance these patterns.
Anyway, IMHO a graphical distinction between ridges and aretes is already present at the moment; the fact that it is not too much emphatic was by design (don’t get me wrong, I’m not saying that it does not deserve an improvement!); also its center definition should be pretty visible at higher zooms (how sharp should be this arete?).

A mapper who can identify a ridge generally is also able to create a way instead of a node.

Also in this case, having feedbacks from many commenters would be useful to take a decision. My stating consideration is that in a freedom map like OSM we expect many (or even too many) elements, not such huge lack of information, that makes it practically useless so far, apart from mapping significantly populated places (like cities and suburban areas). Not to say that OSM has “street” within its acronym, not e.g. planet.

[pnorman]

Don't use line length, use line length relative to zoom, or what @imagico indicated earlier. For better non-mercator compatibility, use ST_Length(way)/NULLIF(SQRT(!pixel_width!::real*!pixel_width!::real),0)

[Ircama]

[kocio-pl]

General question: are there unexpected problems with merging stuff or just lack of time to take care of the incoming code? This PR is pretty wide and important, but it's been polished according to remarks and it's quite a long time since it seems to be ready.

[pnorman]

I am leaning against it for cartographic reasons, so haven't done a final review.

[Ircama]

I am leaning against it for cartographic reasons, so haven't done a final review.

I agree that new features shall be appropriately weighed up.

Would you please elaborate the possible cartographic drawbacks that such PR might introduce? In case, we can rework it.

[kocio-pl]

@pnorman

I'm not sure we should render these features. Without hillshading, we will never be a good topographic map and it's not one of our goals.

It would be good to decide which features make no problems and which are problematic somehow, for a start. This PR could be then split into parts and not hold everything stalled.

For example ridge rendering is good to have anyway IMO. Hillshading would just add more details how the terrain is shaped, but still would not replace rendering ridge name. These features are only partially overlapping.

[pnorman]

Yes, we need to figure out which need height contours to make sense and which don't.

[kocio-pl]

@Ircama For me rigde is a perfect candidate for merging, because it doesn't need contours, but I'm not that involved in this topic to say about all the other features. Maybe you could write down your opinion first, so the rest can refer to it - that will probably the easiest thing to do to reach decision stage.

[dieterdreist]

2016-11-07 17:14 GMT+01:00 kocio-pl notifications@github.com:

@Ircama https://github.com/Ircama For me rigde is a perfect candidate
for merging,

if we are discussing this list:

•natural=ridge (name and symbol)
•natural=arete (name and symbol)
•natural=dale (only name)
•natural=gorge (only name)
•natural=couloir (only name)
•natural=valley (only name)
•natural=mountain_range (only name)
•natural=massif (only name)

I believe none of them needs contour lines (equal elevation profile lines)
in order to make sense. They can all be seen as natural place names, and
only for ridge and arete a symbol is proposed (those are both similar
features, if ridge makes sense, arete will as well)

[Ircama]

Thanks a lot for resuming comments. I understand that we need to be generally cautious when adding new features and I appreciate the intention of performing researches and reviews before taking a decision.

Like other physical elements already available in this style, I am convinced that the features proposed with this PR have a value per se and are not correlated to contour lines or hill-shading, even if hypothetically having some future option to apply such layers could be of general benefit to OSM for terrain representation. In my point of view peaks, which are currently rendered in this style, have their own role in documenting territory, although their descriptive importance could be amplified by relief visualization.

As reviewers have already notified, the rendering of names is a relevant part of this PR.

None of these elements is in the field of scientific/technical cartography and all have unquestionable social and cultural merit for common people of all ages.

While openstreetmap-carto style excels on populated places, in which some reassessment on the need to render features in overcrowded zones (especially for business related symbols) might be worthwhile to be evaluated, there is in my point of view some gap with unpopulated areas, where the features in this PR are usually circumscribed. In addition, representing these features could be a positive accelerator for OSM data, which also needs improvement on mountain terrain tagging, as for these zones the database itself is not at the same quality level as in the cities.

[imagico]

@Ircama - these arguments are all quite understandable but the discussion here is not about if something like a valley can or should be rendered in a map in general, it is about if what is mapped as natural=valley in OSM with a linear way should be rendered in this map style with a label placed along the way.

The previous discussion we had above did not really have any substantial results. You have not participated in the discussions on the wiki regarding how to map valleys in a verifiable way. Overall it seems to me you do not really consider it a problem if mappers place labels rather than mapping something observable and verifiable in nature. This is an understandable viewpoint from a map design perspective but it clashes with the basic principles of OSM.

As i said the concept of rendering ridges and aretes is on a good way i think - still requires some tuning and testing probably but i definitely consider this suited for this style. The rest however IMO requires more thorough consideration on the level of mapping and tagging first. I explained the approach in #2138 (comment) - the discussion i had with @RicoZ-OSM on the wiki would probably be a good start.

[dieterdreist]

sent from a phone

Il giorno 08 nov 2016, alle ore 11:11, Christoph Hormann notifications@github.com ha scritto:

Overall it seems to me you do not really consider it a problem if mappers place labels rather than mapping something observable and verifiable in nature. This is an understandable viewpoint from a map design perspective but it clashes with the basic principles of OSM.

interesting that this argument is always coming up when speaking about natural/geographic features, but apparently nobody has a problem with place=locality, a tag that is already rendered, that has very imprecise and generic meaning (hence is used more than a million times, also because no more specific alternatives have been established), that is often describing something with significant extent but is almost exclusively used on nodes. This is actual label dropping, not specifying a valley and its name and giving it a rough location.

[imagico]

but apparently nobody has a problem with place=locality

You are aware that place=locality was mentioned here in #2138 (comment)

[dieterdreist]

thank you for reminding, so we agree that the situation with place=locality is worse (what doesn't necessarily mean we should add the features from this PR, naturally).

[imagico]

No, not worse, just very different. In any case nothing really related to the subject of this issue. Stopping rendering labels for place=locality could still be worth considering (but in a separate issue).

[Ircama]

You have not participated in the discussions on the wiki regarding how to map valleys in a verifiable way.

Oh no, I was not aware, thanks for notifying. I just had a look at the Talk tab at the time of developing the rendering of valley, when your topic was not yet disserted. The current PR follows the "approved" polymorphism of this tag in the Wiki, the one which is currently known to mappers, with the extension to also cover polygons that look rarely used at the moment. I understand the concept that data modelling suggests a valley should be an area, meaning that to verify a farm is in a valley we intersect their areas other than relating them with names. Anyway I will better check that discussion. I also appreciate, if I am well interpreting feedbacks, that there is no a priori apprehension for rendering common geographical features in this style, just a concern on data model.

[imagico]

Note there is nothing 'approved' about the tag page on the wiki. The status in the description box refers to the fact that there is an approved proposal that mentions this tag (in this case it piggy-backed on the ridge proposal without the concept of natural=valley being discussed in the proposal process). As has been pointed out repeatedly the proposal process is essentially meaningless for rendering decisions here, it is just a means (but no guarantee) to improve tagging consistency.

[Ircama]

I would separate the code for ridges/aretes from the other features here proposed and, if you do not see a better option, I can create a new PR just to render ridges/aretes and consider to use this space to go on better focalizing the problem of rendering the other features. We can close this PR meanwhile if you prefer.

Basing on the hypothesis to redefine a valley as area (to be discussed in the wiki) I see two implications and a rendering questions I'd like to develop here.
While rendering the name of an area is fine IMHO in case of very small convex polygon, valleys can be complex to tag and the same logic that allows relations of adjacent surfaces (adopted for other OSM elements), could be considered also in this case (at least as an assumption for the question). Besides, related polygon is often concave; I wonder whether in such cases the renderers (like Mapnik) can easily process the name for these data models (union of concave polygons), and, if not, whether it would be worthwhile to consider including a line in the relation (a way) to allow rendering the name. After all, OSM adopts the same data model e.g., for rivers, where the adiacent polygons are complemented by a linear way positioned along its thalweg. Apart from considering that for natural implications many shapes of valleys can be analogous to the ones of rivers and that a thalweg might be useful information for administrative purposes (all these points to be better discussed in the wiki rather than here), there is a data redundancy that in reality has a task to support renderers in better processing the name of the feature.
Regardless the side effect to reuse the simple logic in this PR for valley, do you see an alternative way for the renderers (e.g., Mapnik) to process complex concave polygons (also relations of polygons) for drawing a valley name (possibly in a similar way the valleys are drawn in classic maps, which is hopefully the aim)? E.g., alternatively a thalweg shapefile or something similar? Thanks

[imagico]

I can create a new PR just to render ridges/aretes and consider to use this space to go on better focalizing the problem of rendering the other features.

You can do either that or repurpose this PR by removing the other changes and rebasing your branch. Given the length of this discussion it is probably cleaner to simply start a new one.

Basing on the hypothesis to redefine a valley as area (to be discussed in the wiki)

I don't think this was ever seriously discussed in the wiki - the discussion RicoZ started was about mapping them as a relation type that is not a multipolygon, that does not require defining a full outline of the feature in question.

Developing such a type of relation should be based on mapping considerations, not on rendering since this would ultimately end up in suggesting mappers to map in a way that primarily works around the shortcomings of rendering engines.

After all, OSM adopts the same data model e.g., for rivers, where the adiacent polygons are complemented by a linear way positioned along its thalweg.

This seems to be based on a common misunderstanding of the system of river mapping in OSM. This does not have the purpose of catering rendering needs, it represents two different and separately mappable aspects of the river system, namely the water flow structure and the water covered area. If a similar distinction exists for valleys that could be discussed (not here of course) but i don't see this at the moment.

Regardless the side effect to reuse the simple logic in this PR for valley, do you see an alternative way for the renderers (e.g., Mapnik) to process complex concave polygons (also relations of polygons) for drawing a valley name (possibly in a similar way the valleys are drawn in classic maps, which is hopefully the aim)?

Yes, more sophisticated label placement for complex polygons is entirely feasible, even for real time rendering purposes. If it is likely that Mapnik will natively support something in that direction in the future is a completely different question of course.

[Ircama]

I don't think this was ever seriously discussed in the wiki - the discussion RicoZ started was about mapping them as a relation type that is not a multipolygon, that does not require defining a full outline of the feature in question.

Yes, I know.

I close this PR as the data definition of the features different from ridge and arete needs some revision.

I see that the data model of natural elements in mountain areas can still be questionable and incomplete. Maybe this is another reason for the very limited usage of such features.

Thanks for the comments and revisions so far.