Add line rendering plus name labels for ridges and aretes #3767
Conversation
6) Improved symmetrical arete pattern
z13 Everest aretes - improved symmetrical pattern - mid width z14 Everest aretes - improved symmetrical pattern - mid width z15 Everest aretes - improved symmetrical pattern - wide z15 Northeast ridge Everest - improved symmetrical pattern - wide z16 Everest aretes - improved symmetrical pattern - wide |
|
Interesting..Very, very, interesting.. |
|
Here are some tests in other areas with the latest commit: Cerro de los Huertos - Spainz13 ridges and aretes z15 ridges on rock Cabeza del Estillo - Spain
z13 aretes - thin z15 arete - wide Pasir Putih, Baliem Valley, Indonesia
z14 ridges - thin lines z15 ridge - wide line + name label |
|
A number of comments here on the alternative-colors implementation:
|
|
Thanks for the work you did on this @Ircama! I would be happy to make any changes or improvements that you might suggest.
Out of 133 The ridge names that I happened to download appear to be real:
Taginfo doesn't have combinations for By comparison, currently And While it's true that sometimes a ridge and a peak share a name, in my experience there are more peaks incorrectly tagged with a name that belongs to it's ridge than the other way around. For example, in my home town area in California, many of the ridge names were imported as peaks from GNIS. There are currently 5 natural=peak with a name "X Ridge" - I've also now mapped the ridges as linear ways, but I didn't bother to remove the name from the peak node. There's a total of 6 named ridges within a 5 mile radius of my old house, compared to 7 named peaks (5 "X Peak", 2 "Y Mountain"). And I've been known to tag a peak with the name of a ridge even here in Indonesia (see Pasir Putih ridge and peak above. It's really the name of the ridge; the high point is not visually prominent) |
I actually haven't seen this yet. Do you know of well-mapped places where this is common? The main problem I've seen is that most ridges are mapped rather roughly, in the general direction of the ridge but not exactly following the ridgeline. Perhaps this is due to lack of good aerial imagery, but it may be that many people think of these as labeling lines, rather than an exact representation of the ridgeline. Rendering a linear feature will help change this perception.
For a while the natural=ridge page said that ridges had to be mapped in an uphill direction, so I was doing this, but it was quite tedious to change the way direction every time the ridge went up and down. Now I found out that this was a rogue wiki edit, and most ridges are not mapped in this way. This is why I've tried to make non-oriented patterns for aretes. This has taken up the most time so far. If we can't get a good arete pattern to work we could just use the same pattern for ridges and aretes. There are only 2000 aretes mapped, and they are a type of ridge. But I hope the new pattern might work.
I'll work on that again, as soon as we deal with the current controversial PR. |
|
Here's some test renderings from the previously suggested area in the Caucasus, with the current commit. z13 ridges and aretes z14 ridges and aretes z14 ridges z15 ridges and aretes z15 ridges The bare_rock pattern is challenging. I wonder if the bare rock pattern really needs to be so much stronger than scree/shingle? |
|
I did not mean to say that names should for sure not be rendered. However if mapping ridges is meant to document a physical geography feature (which is the only sensible idea for that tag IMO) matching names to this is often counterproductive because it leads people to delineate abstract named features and not locally verifiable physical structures And from what i saw looking at the data named ridges are often cases of poorer mapping than unnamed ridges.
Well mapped places? - i am not sure what qualifies as such. A few examples for uses of ridges for things that are not well defined locally verifiable physical features: https://www.openstreetmap.org/way/143571111 Based on this kind of mapping i would generally consider natural=ridge not suitable for rendering here but since there is as explained a considerable volume of consistent use in some parts of the world i would not rule it out if we can make sure that the style of rendering supports this use and discourages other applications. |
|
Cordillera Cutucú Oriental, mapped in 2012 in Ecuador. Serra da Chibata, Brazil
Serra Mundo Novo, Brazil
Unnamed ridge in western USA. In contrast, I picked a couple of random areas in California, Spain, Chile and Argentina. There were a couple of long ridges in Argentina that need to be broken into smaller pieces, and some of the ridges in California are roughly traced and need to be more precise. But most of the ridges in the places that I checked were quite good, and rendering will be helpful, eg: South America
https://www.openstreetmap.org/way/449488940 and https://www.openstreetmap.org/way/449488929
https://www.openstreetmap.org/way/449889553 - and around North America Europe - Spain and France:
Nepal: I haven't looked in the Alps or Norway, probably too much data to download, but I suspect there are many good examples there? |
|
Note my critique of the linked to samples is not that they are mapped imprecisely but that they don't represent something that is defined in a verifiable way. This is a very similar to the problem of place=square - which as a tag is used in a self referential fashion for things called a square (or what a mapper might consider an equivalent to that in some other language) but without there being a way to independently determine if something is a square or not. Such use of natural=ridge is not the dominating use but it is not a rare one either so i am not sure we can actually render ridges in a way that provides productive mapping support. |
Could you clarify this? What sort of research can I do that will show if these features are tagged consistently enough for rendering? There are over 60,000 ridges, but I could download a sample from several countries. The thing is, I don't know exactly what problems I'm looking for. I don't think you are saying that ridges are not verifiable features. Back in 2014 and 2015 you were in favor of rendering ridges. The topographical definition of ridges is quite precise
A Brazilian mapper mentioned the issue in 2015: #2138 (comment) "When I started to map the Serras in this region my understanding was that "Serra" translates best as "ridge". The official IBGE maps which we are allowed to use for OSM simply show in capital letters the approximate location of these Serras, they do not go into any geological details. At the same time, the only documented/approved tag I found on OSM's wiki was natural=ridge. So it was a natural step to map all the Serras as ridges. It is now clear to me that it best to revise this." I can check the Portuguese and Spanish translations of the wiki for
This would be analogous to the situation with rivers, where best practice is to keep the lines shorter than 10km, and the water polygons should be even shorter to make editing easier. (Our current way_pixel based filtering at <z10 provides bad incentives about this) However, this is quite easy to fix by breaking up the long ways. They can even have the same name if the local name is still correct for each ridge segment, or the name may change (just like it does on the Rhine at language borders).
It looks like the problem with
I. Can be mapped as I don't see this problem with The one issue is mistagging of mountain ranges as ridges. These should probably be tagged as |
I don't think there is anything you could do from the mapping side. As you said there are tens of thousands of features and a significant fraction of them is with a strong variability in what exactly they are applied to (as illustrated with examples). It would of course be interesting to analyze more precisely what fraction this is and what classes of use can be identified.
In the course of implementing the ac-style rendering i looked at the data more closely than before and this changed my position a bit. I will try to explain it from a slightly different perspective: How would you define a natural=ridge tag from scratch if you wanted it to be clear and locally verifiable? That would need to be based on the local relief. And in many, especially in relatively flat areas or with small scale erosion, you would need to define some quantitative cutoff - otherwise you could end up with an almost arbitrarily dense set of ridges that can be mapped in most areas. The current wiki description provides no really meaningful definition. The continuous elevated crest (which i added back in 2014, which however turned out to be quite insufficient as a discerning definition) is functionally equivalent to defining a ridge as any watershed divide. Based on this actual use in the database as we discussed like the labeling geometries or the >100km long lines drawn along some watershed considered to be the main crest of some mountain range and labeled accordingly are often not formally wrong according to the definition. Yet for the data users they are something completely different than what you for example see in the Caucasus and elsewhere. A clear new definition for a ridge tag would be a line of continuous negative earth surface curvature with a continuous curvature radius of less than X meters - with X being something like 20-50m probably. The problem with that is that it would be interrupted at every saddle point (which by definition has zero curvature) - so you might want to introduce some skipping rule for small saddles - which however could affect local verifiability. Note use of natural=arete probably follows such a definition more closely already with a much smaller value for X. Anyway - this is an abstract exercise, we are not inventing a new tag here but dealing with an existing one in wide use. I guess my question for the decision on rendering is if we can have the reasonable expectation that use of natural=ridge will develop into something that follows a uniform, locally verifiable definition (if similar to the one i made up above or a different one does not really matter) and if we can with a suitable rendering support such a development. This is what i am looking for here. Because if use of natural=ridge stays as broad and undefined in meaning as it is right now the more responsible decision would be to recommend to mapper to create and use a new, better defined tag instead for what they want to map (as it happened in other cases in the past - like leaf_cycle/leaf_type instead of wood=*). |
|
Aretes and ridges are directional objets: if you use chevrons to render them, they should be oriented consistantly, depending on the altitude, just like river ways, and should not depend directly on how the way was drawn (where the altitudes are kwown between nodes, and there should be a node at each summit/peak and at each minimum). You may also consider the difference of altitude between marked nodes to compute the way length and the average steep: this can be used to customize the length of the chevron strokes (or its apparence like angle relative to the main way of the arete or ridge): its not uncommon for ridges and aretes to have "flat" sections (no significant change of altitude along them, even if the half planes of on the two sides are sharply angled). Finally ridges and aretes should have a way to define how sharp they are (i.e. the relative angle of the two orthogonal lines on each side) This also applies to cliffs (mostly horizontal on one side, but nearly vertical on the other side). This can generalized (cliffs, ridges, aretes) by tagging the steep angles for orthogonal directions to the left and right of the way (these two angles are not necessarily the same, especially for cliffs, and for most rocky or icy aretes). This could as well apply to some large buildings or infrastructures (e.g. dams), or even in large enough pedestrian areas (transition betwen a flat surface and a steeply inclined surface, when there surfaces are significantly larger than a street, or transition by very wide stairs not well repredented as ways in OSM, but where drawing each "step" is not very useful of not suitable beause there are no steps but only an softly inclined plane, for example in plazzas around large elevated monuments or buildings). The idea is then to tag elevations on nodes of the geometry of ways, plus additional tags for angles on the left and right side of ways (but only if this is a linear feature). For area features, we don't need these additional angle tags, we just need altitudes on at least 3 nodes of the closed polygon, it is eanough to compute the angles by splitting the polygon into triangular facets that are the closest to equilateral, i.e. whose the sharpest of their 3 angles are maximized: there are good triangulation algorithms used in CAD for 3D modeling of a surface sampled on a more or less regular grid of nodes). And for these computed facets, the ridge/edge/cliffs can be determined automatically without even drawing them as ways in OSM (it is already useful for numeric terrain models, already rendered in some OSM maps: the isobaths are computed and interpolated directly from a sampled grid of elevation measurements and this requires much less data than drawing all ways for each altitude or depth by step of 10 meters: the grid of elevations is triangularized, then the skeleton of riges/areates are determined, then nodes at each elevation step along this skeleton are computed, then nodes are connected between each side of the triangular skeleton, finally these generated polylines are smoothed by quadratic or cubic Beziers and altitude values can be texted along these Beziers) |
|
@imagico - I take your comments above (#3767 (comment)) as rejecting rendering of That would suggest using a different style for |
|
No, i am not rejecting idea, i am just suggesting to critically evaluate if the proposed rendering (in terms of design and starting zoom levels) provides constructive mapper feedback in support of consistent use of the tag. The dominant use of natural=ridge is clearly for mapping skeleton lines in (mostly glacially shaped) mountain areas, as it is widely done in Russia and former Soviet countries. Rendering should ideally positively support such use and discourage use on other things like for mapping mountain ranges with labeling lines etc. |
Could this be done by avoiding rendering at mid-zoom levels, starting at z14 only? This would help suggest that the rendering is not for large mountain ranges. We could also avoid rendering names for now, since |
|
Yes, not starting rendering too early and not rendering names (or rendering them later/less prominently) could definitely help. As said i am fairly unsure about this - would need to test the particular design suggestion and would probably also need to evaluate the effect carefully after roll-out. |
|
This PR implements 6) Improved symmetrical arete pattern, right? I'm broadly-speaking in favour, but don't feel qualified to review it since there aren't natural=ridge features where I normally map. |
|
The latest test images in #3767 (comment) show the current commit, with "6) Improved symmetrical arete pattern" for aretes, and the same ridge pattern as 3) "Narrower ridges at z13 and z14". |
|
Can we take the [WIP] label off of this PR and come to a decision about it, or is more work still needed? |
|
I've updated the PR by changing the initial zoom level to z14 for the line rendering of aretes and ridges, and I've renamed the svg files while deleting those that are no longer needed. For now I've left the name rendering at z15, pending review. |
jeisenbe
changed the title
…ors style This commit is based off of the osm-carto-alternative-colors style at github.com/imagico/osm-carto-alternative-colors/ by @imagico, including the arete.svg, arete2.svg and ridge.svg symbols A linear rendering is added for ridges and aretes at z13 and above. In addition, text labels following the line are added at z15 and above in the same style used for cliffs and embankments
…ttern at z15 and above
|
Rebased for v5.0.0, but I think we need input and perhaps a review from @imagico. Since there are concerns about how natural=ridge is being used around the world, perhaps someone who has a global server would be willing to test this PR, so we can check a larger variety of areas? |
|
Ok, some areas checked (these are pbf extracts which I've already downloaded, picked somewhat randomly, the data may be 3 to 12 months old). Probably helpful to view these with the opencyclemap layer to see terrain. Karlovarsky, Poland (28 mb file)1 Armenia (25 mb file)221
The rest are unnamed, no other tags. Random examples:
Other areas with more landcover and cliffs mapped:
Wales, UK: (73 mb)
Ridges: 5 named, 9 unnamed.
Named:
way 276120618, "name": "Y Gribin",
way 755441509, "name": "Pant-y-gwair",
Unnamed (samples: first, middle and last):
way 24471527 - ridge in health, around end of stream:
Shikoku, Japan (67.5 mb)
Ridges:
-way 453108986 - no other tags. Seems right:
Latvia (65 mb)6 natural=ridge ways, no aretes. None have a name or any other tags.
Cape Verde Islands (7 mb)
Costa Rica (22 mb)
Example: way 560663243 Sogn Og Fjordane region, Norway (29 mb):1 ridge only (surprisingly): - named (same as peak). No aretes.
Corsica, France (25.6 mb)11 natural=ridge, all named. 1st, middle and last:
Hautes Alpes, France22 aretes, 2 with names (finally): Way: Pointes de la Condamine (359540655) Way: Rochers de la miglia (430618548)
86 natural=ridge, 45 with names:
Honduras:1 natural=ridge: Extremadura, Spain:5 natural=arete features, 2 with names 16 natural=ridge features, 7 with names:
Bhutan2 ridges: Way: 469614592 - https://www.openstreetmap.org/#map=14/27.248865/89.6989217 No Ridges or aretes:
EstoniaUruguaySingapore:Congo (Brazzaville):Burundi:Looking at all of these, I think a large majority of uses of natural=ridge are appropriate and will work with this proposed rendering, and there are enough named ridges for the name label to be reasonable, though there are still a few that need to be better mapped and a few that should be natural=mountain_range. The aretes seem to be fine too. |
http://www.imagico.de/files/arete_x4.svg I was trying to compromise between showing aretes in a similar way to ridges, or making them more like cliffs. You've approved this PR, so do you think we should go with this for now, or should I try some other options for the aretes first? (Either way, I will wait till after v5.0.0) |
I think the current design is acceptable - but definitely could be improved. |
|
Tests with arete_x4.svg design from #3767 (review) for z15 and above: https://www.openstreetmap.org/#map=15/40.2577/-5.3925 https://www.openstreetmap.org/#map=15/40.2663/-5.3367 |
|
The z14 rendering is unchanged. I've cleaned up the files to remove unneeded metadata. |
Fixes #1148
Related to #545 and #788
Also see discussion in #2774
Replaces part of PR #2138
Changes proposed in this pull request:
Explanation
natural=cliffto map ridges and aretes, perhaps influenced by the lack of rendering ofnatural=ridgeandnatural=aretein this style. Some namednatural=peakandnatural=mountain_rangecould be better mapped as ridges, in the case that the name refers to one linear hill or mountain feature, but the lack of rendering may discourage this.However, a pleasant and clear rendering is not easy. A previous PR was closed due to issues about the initial zoom levels, name label size, and the appearance of the ridges.
This new attempt is initially based off of work by @imagico in the osm-carto-alternative-colors style.
Options with test renderings
1) osm-carto-alternative-colors style
z14 Mt Everest aretes - alt-colors style - thin
z15 Mt Everest aretes - alt-colors style - wide
z13 Parchemuche, Nepal ridges - alt-colors style
z13 Kongde Ri, Nepal ridges- alt-colors style
2) Modified alt-colors style
z14 Mt Everest aretes - no gap - thin
z15 Mt Everest aretes - no gap - wide
z13 Parchemuche, Nepal ridges - no gap
z13 Kongde Ri, Nepal ridges - no gap
z15 - no gap
3) Narrower ridges at z13 and z14 and staggered arete pattern
z13 Mt Everest aretes - alternating pattern - medium width
z14 Mt Everest aretes - alternating pattern - medium width
z15 Mt Everest aretes - alternating pattern - wide
z13 Parchemuche, Nepal ridges - medium width
z13 Kongde Ri, Nepal ridges - medium width
z15 - wide (same as 1) and 2) above)
4) Even thinner ridges and aretes at z13
z13 Mt Everest aretes - thinnest
z14 mid-width aretes
z13 Konge Ri ridges - thinnest
z14 mid-width ridges
5) Symmetrical arete pattern
ridge-mz.svgfor z13 and z14,ridge-hz.svgfor z15 and above; 2 arete patterns.z13 Mt Everest aretes - symmetrical medium-thin pattern
z15 Mt Everest aretes - symmetrical wider pattern
z16 Northeast Ridge, Everest - need to adjust the pattern so it doesn't look cut-off (right side)
Test areas
Remaining questions