# Talk:Proposed features/cliff clarification

"Default to area=no (except for multipolygons)." - why "except for multipolygons"? For example named group of rock spires would be probably mapped this way (multiple outer ways) Bulwersator (talk) 08:05, 23 August 2014 (UTC)

Because Multipolygons are for areas, not for linear features, let alone asymmetrical lines such as cliffs where left and right sides differ. A renderer won't know which side of a multipolygon ring is the upper side. Think about two touching inner rings. Is there one cliff around both, or one around each? What about the intersection line? This is only solvable if you define loads of rules and exceptions in the Wiki. So just draw each cliff separately. Don't use multipolygons.
If you want to group them, giving one name to them altogether, you need a collecting relation such as type=collection or type=cluster or type=site. Unfortunately, none of them is really approved. Some of those relation types are in use, but without a consensus. --Fkv (talk) 09:01, 23 August 2014 (UTC)

I first came across cliffs as areas when wondering why no cliffs were rendered in the Chartreuse region. It turned out that they had been mapped, but as areas. Although the cliffs over the Isere valley appear formidably steep (both from above and below) the aerial photos showed they were still far from vertical. As Dieterdreist says below one loses the directional information, and certainly when I used natural=cliff to map a sinkhole it took me a while to realise that area=no was required. It might be interesting to look at the use of the area tag on the existing ones using a closed way. I don't think that using areas can be prevented, but I'd tend to suggest that closed ways or relation multipolygons be 'undefined' if no area tag is present; as well as being deprecated or not recommended. The problem for cliffs like those of the Chartreuse is that natural=bare_rock does not tell us anything about the inclination of the bare_rock or which areas of bare rock are associated with a cliff and which are not. Potentially the incline tag could be used, but for most cliffs this would be fairly meaningless because of their structure. In other words I think we need some way to clearly show the surface area of a cliff in such a way that it is unambiguously associated with linear ways. SK53 (talk) 17:38, 2 September 2014 (UTC)

"I'd tend to suggest that closed ways or relation multipolygons be 'undefined'" - That's status quo, and that's the root of current problems. I wonder why you are thinking about incline=* ? You probably want to use a fine elevation model (e.g. laser scan) to get the inclination of areas. --Fkv (talk) 14:47, 17 December 2014 (UTC)

## Against areas for natural=cliff

I am against the usage of natural=cliff on areas, because this would remove the directional information (which side is up and which down). Hence I am supporting the idea that natural=cliff on closed ways implies area=no. --Dieterdreist (talk) 14:31, 2 September 2014 (UTC)

One solution would be to use an area of bare_rock and a way natural=cliff along one of its sides to denote the cliff edge. RicoZ (talk) 16:53, 2 September 2014 (UTC)
This has the additional benefit of distinguishing rock cliffs from dirt cliffs (like vertical moraine walls), waterfalls, and icefalls. --Alan Trick (talk) 17:35, 9 September 2014 (UTC)

## Against natural=cliff on nodes

I believe that a node is a bad representation. It doesn't state direction (up and down) and even in the case of approximate positional accuracy (i.e. estimation needed) or very short cliffs it will still be much better to draw an estimate / a short way, which might later be refined. My suggestion is to discourage usage on nodes. As of now there are ~10% of cliffs tagged on nodes according to taginfo (16086 instances on nodes)--Dieterdreist (talk) 14:31, 2 September 2014 (UTC)

I believe the direction is quite obvious for nodes, do not think someone would get the idea do draw a hole with cliffs inside as a node but using it for a small approximately circular shaped rock is not farfetched. RicoZ (talk) 16:50, 2 September 2014 (UTC)
I agree. Dieter was obviously afraid of nodes meaning short asymmetric cliff lines, but I am convinced that the vast majority of natural=cliff nodes actually mean rock spires. That's why I suggest a respective definition. --Fkv (talk) 14:24, 17 December 2014 (UTC)

## Waterfalls

Cliffs are also used to map waterfalls and it would be nice to have a special attribute for cliffs to mark them as being the waterfall-edge. RicoZ (talk) 16:38, 2 September 2014 (UTC)

No attributes needed. Just draw one line for the natural=cliff, one line for the waterway, and tag the intersection point as waterway=waterfall. --Fkv (talk) 13:44, 17 December 2014 (UTC)

## Cliffs and coastlines, riverbanks and islets

Cliffs are very frequently around islets, coasts and riverbanks and we are hitting all problems here:

• natural=coastline + natural=beach don't go together well
• riverbanks are usually closed areas and often multipolygons
• islets (in oceans) are both an are and natural=coastline

How do folks deal with that? RicoZ (talk) 15:46, 3 September 2014 (UTC)

A beach should not be tagged as a line, but an area. A beach surrounded with a cliff with no ocean view? :-)
Same with riverbanks areas. If the riverbank is an MP the side of the river could be a cliff and an outer line of the MP.
islets are a problem when there is cliff all around the island. In all this cases the cliff should be a seperate osm way sharing the same nodes with the base feature. --Zuse (talk) 14:07, 4 September 2014 (UTC)