Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
[WIP] Add line rendering plus name labels for ridges and aretes #3767
Changes proposed in this pull request:
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.
Options with test renderings
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
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)
6) Improved symmetrical arete pattern
Here are some tests in other areas with the latest commit:
Cerro de los Huertos - Spain
Cabeza del Estillo - Spain
Pasir Putih, Baliem Valley, Indonesia
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
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.
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:
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:
https://www.openstreetmap.org/way/449889553 - and around
Europe - Spain and France:
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.
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)