Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] Add line rendering plus name labels for ridges and aretes #3767

Open
wants to merge 7 commits into
base: master
from

Conversation

Projects
None yet
4 participants
@jeisenbe
Copy link
Contributor

commented Apr 26, 2019

Related to #545 and #788
Also see discussion in #1148 and #2774
Replaces part of PR #2138

Changes proposed in this pull request:

  • Add a pattern-based linear rendering for ridges and a similar rendering for aretes
  • Render text labels for named ridges and aretes in the same style used for cliffs and embankments

Explanation

  • Ridges and aretes are well-defined linear landform features
  • Both are approved tags with complete wiki pages and increasing usage by mappers in many areas
  • Other renderings currently render text labels (eg opentopomap) or lines (Osmand) for ridges or aretes
  • In some cases mappers have used natural=cliff to map ridges and aretes, perhaps influenced by the lack of rendering of natural=ridge and natural=arete in this style. Some named natural=peak and natural=mountain_range could 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.
  • Adding rendering of these features in this style will promote correct mapping by showing the geometries in the database and the name labels

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

  • Aretes and ridges are rendered from z13 with 2 patterns. Aretes have a wider pattern at z15 and above (similar to how cliff lines change size at this point), but the ridge pattern is the same.
  • I've also added text labels for the name at z15 and above, in the same style used for cliffs and embankments (gray color).
  • Uses SQL to slightly shorten the ways when they intersect saddles and peaks. This makes it easier to see the peak and saddle icons, but can be confusing at times.
  • Also, it appears that some ridges are not rendered when they are also tagged as a boundary=administrative - I'm not sure if this is a problem with the code I borrowed from @imagico or a mistake in my implementation

z14 Mt Everest aretes - alt-colors style - thin

z14-everest-alt-colors-aretes

z15 Mt Everest aretes - alt-colors style - wide

z15-everest-alt-colors

z13 Parchemuche, Nepal ridges - alt-colors style

z13-parchemuche-alt-colors

z13 Kongde Ri, Nepal ridges- alt-colors style

z13-kongde-ri-alt-colors

2) Modified alt-colors style

  • Here I've simplified the SQL query. The aretes and ridges now are rendered at full length.
  • While it's a little harder to see saddles and peaks along a ridge, this problem also exists for peaks rendered over administrative boundaries, paths, etc, and could be better addressed by adding a halo around the saddle and peak icons or changing the icons to a darker, simpler design.
  • The patterns are the same as in 1): Aretes and ridges are rendered from z13. Aretes have a wider pattern at z15. Name labels are rendered from z15
  • I'm still not sure about this arete pattern: it's directional, and reverses depending on how the osm way is drawn.

z14 Mt Everest aretes - no gap - thin

z14-everest-aretes-no-gap

z15 Mt Everest aretes - no gap - wide

z15-everest-aretes-no-gap

z13 Parchemuche, Nepal ridges - no gap

z13-parchemuche-no-gap

z13 Kongde Ri, Nepal ridges - no gap

z13-kongde-ri-no-gap

z15 - no gap

z15-ridges-borders-glacier-no-gap

3) Narrower ridges at z13 and z14 and staggered arete pattern

  • Where I live, near the equator, the 28 pixel wide ridge pattern is ~400m wide at z13. I've narrowed the ridge pattern to 18 pixels wide and used this for z13 and z14
  • The original arete pattern was directional, so I've tried a different option with staggered v shapes on each side. This was created by moving around the "rocks" in the original ridge svg
  • However, the staggered v-shaped arete line can give an optical illusion of the ridge line zig-zagging back and forth

z13 Mt Everest aretes - alternating pattern - medium width

z13-everest-arete-alternating-mid

z14 Mt Everest aretes - alternating pattern - medium width

z14-everest-arete-mid-alternating

z15 Mt Everest aretes - alternating pattern - wide

z15-everest-aretes

z13 Parchemuche, Nepal ridges - medium width

z13-ridges-parchemuche-mid

z13 Kongde Ri, Nepal ridges - medium width

z13-ridges-mid-kongde-ri

z15 - wide (same as 1) and 2) above)

z15-ridges-borders-glacier-no-gap

4) Even thinner ridges and aretes at z13

  • This option tried thinner ridges and aretes z13, and the medium thickness at z14, requiring 3 different pattern files.
  • However, I think this may be too light and hard to see

z13 Mt Everest aretes - thinnest

z13-everest-aretes-thinnest

z14 mid-width aretes

z14-everest-arete-mid-alternating

z13 Konge Ri ridges - thinnest

z13-everest-aretes-thinnest

z14 mid-width ridges

z14-ridges-thin-kongde-ri

5) Symmetrical arete pattern

  • As mentioned, the staggered or alternating arete pattern causes a bit of an optical illusion that causes the line to appear to zig-zag.
  • Here the aretes are rendered with the "V" shapes directly opposite each other, so that the ridge line still appears straight
  • However, it looks like I still need to improve the SVG to look more even and so that there is not a cut-off appearance on one end of the arete
  • 2 ridge patterns: ridge-mz.svg for z13 and z14, ridge-hz.svg for z15 and above; 2 arete patterns.

z13 Mt Everest aretes - symmetrical medium-thin pattern

z13-everest-symmetrical-aretes

z15 Mt Everest aretes - symmetrical wider pattern

z15-everest-aretes-symmetrical

z16 Northeast Ridge, Everest - need to adjust the pattern so it doesn't look cut-off (right side)

z16-ne-ridge-arete-symmetrical

Test areas

Remaining questions

  • What arete pattern should be used?
  • Should ridges be rendered with a thinner pattern at z13 and z14?

jeisenbe added some commits Apr 24, 2019

Add line rendering and text labels for ridges and aretes from alt-col…
…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
@jeisenbe

This comment has been minimized.

Copy link
Contributor Author

commented Apr 26, 2019

6) Improved symmetrical arete pattern

  • New SVGs arete-wide.svg for >=z15 and arete-mid.svg for z13-z14
  • This commit uses the same ridge patterns as 3) and 5) above: narrow at z13-z14, wide at >=z15

z13 Everest aretes - improved symmetrical pattern - mid width
z13-everest-aretes-smoother-symmetrical

z14 Everest aretes - improved symmetrical pattern - mid width
z14-everest-aretes-smoother-symmetrical

z15 Everest aretes - improved symmetrical pattern - wide
z15-everest-aretes-smoother-symmetrical

z15 Northeast ridge Everest - improved symmetrical pattern - wide
z15-aretes-northeast-everest-smoother

z16 Everest aretes - improved symmetrical pattern - wide
z16-everest-aretes-smoother

@Adamant36

This comment has been minimized.

Copy link
Contributor

commented Apr 26, 2019

Interesting..Very, very, interesting..

@jeisenbe

This comment has been minimized.

Copy link
Contributor Author

commented Apr 26, 2019

Here are some tests in other areas with the latest commit:

Cerro de los Huertos - Spain

z13 ridges and aretes
z13-spain-ridges-aretes-smooth

z15 ridges on rock
z15-cerro-de-los-huertos-ridges

Cabeza del Estillo - Spain

z13 aretes - thin
z13-cabeza-del-viejo-aretes-forest-improved

z15 arete - wide
z15-cabeza-del-estillo-forest-arete-improved

Pasir Putih, Baliem Valley, Indonesia

z14 ridges - thin lines
z14-pasir-putih-improved

z15 ridge - wide line + name label
z15-pasir-putih-ridge

@imagico

This comment has been minimized.

Copy link
Collaborator

commented Apr 26, 2019

A number of comments here on the alternative-colors implementation:

  • credit for the fundamental idea goes to @Ircama who in #2138 first explored this design approach.
  • the implementation in the ac-style does not necessarily mean i would support this here in the same form. This is a test how it works that does not yet fully consider all the implications.
  • My choice of not rendering names was deliberate. Only a relatively small fraction of ridge/arete features have names tagged and of those a fair number have descriptions as names (like Northeast Ridge) or names duplicated from peaks.
  • Related to that use of natural=ridge is fairly non-uniform world wide and is often widely applied to features that are not actually ridges, mostly labeling geometries for mountain ranges or similar concepts. It might be that such rendering would counteract such misuse but that is not guaranteed.
  • My rendering was mostly oriented at the mapping of ridges in Russia and other former Soviet Union countries which is both fairly extensive and fairly consistent. The results with such mapping are essentially a variant of what is known as skeletal line relief rendering (German: Gerippelinien) which is fairly common for example in small scale sketch maps with a topography focus (like here).
  • The patterns are generated with a fairly ad-hoc modification of jsdotpattern which i have not published (the usual with some hardcoded parameters in the code and some non-intuitive parameters to adjust).
  • The problem with the directed pattern for arete is obvious. Aretes are not currently mapped with consistent orientation although this would of course be fairly useful for data users.
  • The biggest problem with implementing this kind of rendering in good quality is the lack of support in Mapnik to define line caps for pattern lines. This necessarily makes the whole thing somewhat crude.
  • This kind of rendering of course aggravates the problems with color mixing of the purple boundaries.
@jeisenbe

This comment has been minimized.

Copy link
Contributor Author

commented Apr 26, 2019

Thanks for the work you did on this @Ircama! I would be happy to make any changes or improvements that you might suggest.

Not rendering names was deliberate. Only a relatively small fraction of ridge/arete features have names tagged and of those a fair number have descriptions as names (like Northeast Ridge) or names duplicated from peaks.

Out of 133 natural=ridge that I happened to download for testing (above, mainly Spain, Portugal and France), 11 have names. This is consistent with taginfo: 12.7% of all features tagged natural=ridge are combined with a name=*.

The ridge names that I happened to download appear to be real:

  1. "Crête de Coum Grane"
  2. "Crête du Liou" (x2)
  3. "Crête du Lys"
  4. "Crête du Moun Né"
  5. "Cuchillar de las Navajas"
  6. "Cuerda de los Pelillos"
  7. "Cuerda del Berrueco"
  8. "Cuerda del Caramito"
  9. "Los Tres Hermanitos"
  10. "Riscos de la Portilla Honda"

Taginfo doesn't have combinations for natural=arete but overpass-turbo shows 198 natural=arete with name=* out of 2026 ways - that's almost 10%

By comparison, currently natural=cliff names are rendered, but only 6.4% of natural=cliff have a name=* tag: https://taginfo.openstreetmap.org/tags/?key=natural&value=ridge#combinations

And man_made=embankment names are rendered; only 2.6% have a name

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)

@jeisenbe

This comment has been minimized.

Copy link
Contributor Author

commented Apr 26, 2019

use of natural=ridge is fairly non-uniform world wide and is often widely applied to features that are not actually ridges, mostly labeling geometries for mountain ranges or similar concepts.

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.

The problem with the directed pattern for arete is obvious. Aretes are not currently mapped with consistent orientation although this would of course be fairly useful for data users.

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.

This kind of rendering of course aggravates the problems with color mixing of the purple boundaries.

I'll work on that again, as soon as we deal with the current controversial PR.

@jeisenbe

This comment has been minimized.

Copy link
Contributor Author

commented Apr 26, 2019

Here's some test renderings from the previously suggested area in the Caucasus, with the current commit.
https://www.openstreetmap.org/#map=13/43.2551/42.8607

z13 ridges and aretes
z13-south-potop-ridges-aretes-thin

z14 ridges and aretes
z14-Worehuykoba-aretes-ridges-scree

z14 ridges
z14-potop-ridges

z15 ridges and aretes
z15-worehujkoba-aretes-ridges

z15 ridges
z15-potop-ridges-wide

The bare_rock pattern is challenging. I wonder if the bare rock pattern really needs to be so much stronger than scree/shingle?

@imagico

This comment has been minimized.

Copy link
Collaborator

commented Apr 26, 2019

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.

I actually haven't seen this yet. Do you know of well-mapped places where this is common?

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
https://www.openstreetmap.org/way/655973348
https://www.openstreetmap.org/way/530704973
https://www.openstreetmap.org/way/338467628
https://www.openstreetmap.org/way/549656211

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.

@jeisenbe

This comment has been minimized.

Copy link
Contributor Author

commented Apr 26, 2019

https://www.openstreetmap.org/way/143571111

Cordillera Cutucú Oriental, mapped in 2012 in Ecuador.
(Spanish-speaking countries use similar words for "ridges" and "(Mountain) ranges": this is a small mountain range).
This way looks like it consists of 3 ridges, in the north, central and south parts, but they've been connected across a couple of flatish areas, and the southernmost end is iffy (though I am just basing these opinions on the contour lines). It's not great, but could be fixed with a couple minute's work.

https://www.openstreetmap.org/way/655973348

Serra da Chibata, Brazil

  • Serra means "ridge" or "(mountain) range" in Brazil
  • Probably imported: source IBGE by user "importES"
  • The southern 30 km of this way seem to follow the top of a long ridgeline. Then it goes northeast along another ridge, and then north again on a third ridge. The northern third has a couple of flat spots that are mistakes. But overall it looks like most of it follows ridges - it just needs to be broken into smaller ways.

https://www.openstreetmap.org/way/530704973

Serra Mundo Novo, Brazil

  • This way is drawn rather coarse, perhaps because it's from "IBGE" as well? It should be 2 separate ridges, broken right about the middle (where the two ridges are connected by a small saddle or pass). But I've seen many rivers and coastlines in the tropics that are mapped more coarsely: rendering them helps remind mappers to fix them.

https://www.openstreetmap.org/way/549656211

Unnamed ridge in western USA.
The changeset says ""boundary=administrative" is not to be used specifically on ways used to separate areas of woodland"
It looks like these 2 ridges got attached to the natural=wood area and an administrative boundary; perhaps that's why they are joined across a relatively flat area in the middle.

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/462657726

  • and the other nearby ridges are caldera rims - much better tagging than natural=cliff

https://www.openstreetmap.org/way/449488940 and https://www.openstreetmap.org/way/449488929

  • Many small branching ridges are nicely drawn off of these

https://www.openstreetmap.org/way/449889553 - and around

North America
https://www.openstreetmap.org/way/182814444 - lots of named ridges in the SW USA
https://www.openstreetmap.org/way/452735804

Europe - Spain and France:

Nepal:
https://www.openstreetmap.org/#map=13/27.8088/86.5408

I haven't looked in the Alps or Norway, probably too much data to download, but I suspect there are many good examples there?

@imagico

This comment has been minimized.

Copy link
Collaborator

commented Apr 26, 2019

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.

@jeisenbe

This comment has been minimized.

Copy link
Contributor Author

commented Apr 27, 2019

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.

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

  1. My first guess it that you object to mappers using this tag for mountain ranges which are not one linear ridge. This seems to happen in language areas where the difference between "range" and "ridge" is not so clear (eg "cordillera", "sierra"/"serra" etc).

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 natural=ridge - but I suspect that rendering these features as a continuous line will help make it clear that they are not just name label geometries.

  1. Perhaps also there are too many ridges where one line has been used to map a very long feature which would be better broken up into shorter ways?

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).

  1. I don't really understand this example: "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"

It looks like the problem with place=square is that it is used for 3 different things, which can all be tagged in another way.

  • I. A small urban park in the center of a town, village or city neighborhood, usually rectangular and surrounded by streets (or pedestrian streets) - very common in Latin America.
  • II. A paved open area in the middle of a town, village or quarter, traditionally used for parades and markets, also good for demonstrations, protests, etc.
  • III. A neighborhood surrounding a square, plaza or traffic circle, which is named for the central square. Eg Harvard Square (Cambridge, Boston), Trafalgar Square (London)

I. Can be mapped as leisure=park instead,
II. Can be mapped as highway=pedestrian with area=yes and surface=paved/cobblestone/etc, III. can be mapped as place=neighborhood (and is mistagged if mapped as place=square according to the wiki definition)
So place=square this is an ambiguous tag but there are better alternatives (all of which have a name label rendering in this style).

I don't see this problem with natural=ridge: there are no correct alternative tags. The tag natural=peak is clearly defined as a high point, not a linear feature.

The one issue is mistagging of mountain ranges as ridges. These should probably be tagged as natural=mountain_range - however that tag is not very widely used and not well documented, so it's not surprising that natural=ridge is sometimes misused in this way.

@imagico

This comment has been minimized.

Copy link
Collaborator

commented Apr 27, 2019

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 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.

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.

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=*).

@verdy-p

This comment has been minimized.

Copy link

commented May 12, 2019

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.