remove all climbing* tags which were previously tagged

zbycz

Hi, I would like to know your comments on this topic. In OpenClimbing we are pushing towards crag relations. The main reason is that knowing the position of each route gives you great estimate of the crag orientation, and often is more clear than any topo.My question - do you think it is ok, to remove all climbing* tags which were previously tagged to a natural=peak or natural=cliff and move them to the new relation?The disadvantage is that some renderers may lose the information about climbing possibilty (because they don't understand relations yet), but for me thats a typical "Tagging for renderer" case, so I would say it is fine. Still I would like to know your opinion :-) (edited)

10 replies

Adam Franco :vermont: Tuesday at 5:26 PM

$:\+1:$ I personally dislike climbing* tags on the natural=cliff features because these features exist naturally and independently of anyone climbing them.

$:\+1:$ 4

5:28

Additionally, a named "crag" is often composed of more than one tiers of cliffs and disjoint faces, so adding the climbing* tags to one cliff isn't necessarily accurate as the level of mapping detail goes up.

5:29

I do appreciate adding the natural=cliff feature to the crag relations as a geographically-referenced holding place when there are few or no routes mapped.

Stephen Tuesday at 8:12 PM

At least one major renderer (OsmAnd) is now crag/area relation aware, so I think there's even less reason to tag sport=climbing with naive consumers in mind

$:\+1:$ 2

jvaclavik Tuesday at 10:25 PM

I think natural=cliff and similar shouldn't have climbing tags in general. It's a bit hacky and acceptable way if you don't have crag relation, but IMHO it doesn't belong there.But for example surface=granit is related to cliff, so it should be there. And probably the same for height, but these two tags are quite important also for climbing. So I'm not sure if we should duplicite surface and keep similar number in climbing:height in crag relation. Do you have any ideas here?

Stephen Wednesday at 12:28 AM

IMO height of a cliff shouldn't be assumed to correlate with the height of a climb (which colloquially is taken to mean the distance of rope travel from the belayer to the anchor, and implies the rope length you'll need; this can be more or less than the cliff's height)Surface/rock type tags aren't something I've gotten around to maintaining. I mostly find it annoying to map these at a per-climb or even per-crag area, especially because it's so typical for all the climbs in some super-area (like some of the big national parks) to have the exact same type of rock. IMO we should be able to just set this on any crag/area relation and consumers should display it as an inherited property on all the children/descendants

$:\+1:$ 3

jvaclavik Wednesday at 10:32 AM

Yep, sounds good. Thanks

zbycz Wednesday at 11:53 AM

I think height should stay at the cliff, but for the "climb length" we have climbing:length - so that would be moved.

$:\+1:$ 1

11:53

And using cliffs for mapping crag is fine IMO. OpenStreetMap's core principle is "granular improvement". Anyone can start from rough position (node), to better geometry (way), to more systematic tagging (relation).

$:\+1:$ 2

Harald Husum Wednesday at 2:03 PM

I'm in the "don't mix cliffs and crags" camp. Having a cliff be a member of a crag makes sense, but having a cliff be tagged as a crag does not. In general I don't like it when we overload features in OSM with a bunch of mutually irrelevant data.

$:\+1:$ 3