Add preset for climbing=route point, way and relation

[harahu]

Description, Motivation & Context

This PR is part of a larger effort to add support for rock climbing related features to iD. In this PR we add a preset for a climbing route. A climbing route is a is a path by which a climber reaches the top of a mountain, a rock face or an ice-covered obstacle. A climbing route can be mapped as a single line tagged climbing=route, or, a relation of lines, possibly including connecting paths. Climbing routes are currently in active use by data consumers, e.g. openclimbing.org.

Climbing routes can be equipped with additional fields, in addition to a name. Useful information could be the difficulty rating of the route (grade) and the type of protection used on the route, as well as the 3D length of the route. I've consciously decided to leave such fields out of this PR, since these are covered in #1590. This PR could be merged independently, and we can update the fields of the preset once that PR is merged.

I've set up a Wikibase entry and a corresponding article for climbing routes, which can be found here:
https://wiki.openstreetmap.org/wiki/Item:Q23048
https://wiki.openstreetmap.org/wiki/Tag:climbing%3Droute

Related issues

• Presets for climbing features #31

Links and data

Relevant OSM Wiki links:

• Climbing routes

Relevant tag usage stats:
https://taginfo.openstreetmap.org/tags/climbing=route
https://taghistory.raifer.tech/#***/climbing/route

2057 current uses

Checklist and Test-Documentation Template

Read on to get your PR merged faster…

Follow these steps to test your PR yourself and make it a lot easier and faster for maintainers to check and approve it.

This is how it works:

1. After you submit your PR, the system will create a preview and comment on your PR:

   🍱 You can preview the tagging presets of this pull request here.
   If this is your first contribution to this project, the preview will not happen right away but requires a click from one of the project members. We will do this ASAP.

2. Once the preview is ready, use it to test your changes.

3. Now copy the snippet below into a new comment and fill out the blanks.

4. Now your PR is ready to be reviewed.

## Test-Documentation

### Preview links & Sidebar Screenshots

<!-- Use the preview to find examples, select the feature in question and **copy this link here**.
     Find examples of nodes/areas. Find examples with a lot of tags or very few tags. – Whatever helps to test this thoroughly.
     Add relevant **screenshots** of the sidebar of those examples. -->

<!-- FYI: What we will check:
     - Is the [icon](https://github.com/ideditor/schema-builder/blob/main/ICONS.md) well chosen.
     - Are the fields well-structured and have good labels.
     - Do the dropdowns (etc.) work well and show helpful data. -->

### Search

<!-- **Test the search** of your preset and share relevant **screenshots** here.
     - Test the preset name as search terms.
     - Also test the preset terms and aliases as search terms (if present). -->

### Info-`i`

<!-- **Test the info-i** for your fields and preset and share relevant **screenshots** here.
     The info needs to help mappers understand the preset and when to use it.
     [Learn more…](https://github.com/openstreetmap/id-tagging-schema/blob/main/CONTRIBUTING.md#info-i)
 -->

### Wording

- [ ] American English
- [ ] `name`, `aliases` (if present) use Title Case
- [ ] `terms` (if present) use lower case, sorted A-Z
<!-- Learn more in https://github.com/openstreetmap/id-tagging-schema/blob/main/GUIDELINES.md#2-design-the-preset -->

[github-actions]

🍱 Your pull request preview is ready

Please use this preview to check your changes. Ideally use the test documentation template and document your test results by commenting on the PR. This will speed up the review process for everyone.

FYI, once this PR is merged, you can use the iD Editor Preview to test your changes in interaction with all other changes.

[harahu]

Test-Documentation

Preview links & Sidebar Screenshots

As a relation:
https://pr-1598--ideditor-presets-preview.netlify.app/id/dist/#locale=en&map=16.42/68.16330/16.59709&disable_features=boundaries&background=geovekst-nib&id=r19216687

As a way:
https://pr-1598--ideditor-presets-preview.netlify.app/id/dist/#locale=en&map=16.61/68.16458/16.58893&disable_features=boundaries&background=geovekst-nib&id=w1391541121

Search

Info-i

Wording

• American English
• name, aliases (if present) use Title Case
• terms (if present) use lower case, sorted A-Z

[tordans]

This looks good to me. I will ask for some more feedback because I did not review relations before…

[harahu]

This looks good to me. I will ask for some more feedback because I did not review relations before…

I just re-based this PR and included the fields added in #1590 in the route presets, so I think this PR is now ready to go. If you prefer, I can split the relation part out into a separate PR.

[tordans]

I just re-based this PR and included the fields added in #1590 in the route presets, so I think this PR is now ready to go.

TBH it feels weird to promote the fields for routes-way, route-relation and route-bottom which are all part of the same "object" (🔗 ). I guess the data users and consumers will have to keep an eye on double tagging and the resulting missmatch in data and come up with a proposal to clean this up later. Ideally only the route-bottom would hold the tags which is likely the lowest common denominator.

If you prefer, I can split the relation part out into a separate PR.

No, it all looks good to me. I will wait until the weekend to give people I pinged time to have a look but otherwise merge. We can always fix things later :-).

[harahu]

I just re-based this PR and included the fields added in #1590 in the route presets, so I think this PR is now ready to go.

TBH it feels weird to promote the fields for routes-way, route-relation and route-bottom which are all part of the same "object" (🔗 ). I guess the data users and consumers will have to keep an eye on double tagging and the resulting mismatch in data and come up with a proposal to clean this up later. Ideally only the route-bottom would hold the tags which is likely the lowest common denominator.

I agree that adding fields to both the route_bottom, and the way/relation would be unnecessary double tagging, and that this is a pitfall of the current schema. I don't think route_bottom is the lowest common denominator, though. In the case where a route is drawn as a way, having a route_bottom node isn't always appropriate (e.g. in the case of bidirectional ridge traverses), so one has to be able to add these fields to the way. In the case of multi-pitch routes represented as relations, it makes sense to add data fields to the individual pitches as well as the route as a whole, since these will be different. Individual pitches won't have route_bottom tags either.

I think the best option for cleanup here is to propose a change where route_bottom is deprecated in favor of

• a route node, in the case of mapping a route as a single node (still to be placed at the bottom of the route when possible)
• a field on the route way indicating whether the route/pitch is unidirectional (default) or bidirectional, in the case of routes drawn as ways.

That way we won't have potential for double tagging, and we also align tagging of directionality with how it's done for other features in OSM, e.g. highways. It's also an easier schema to follow, because I don't think a user today will necessarily know that they should also add a route_bottom node when having mapped a route as a way. For me, at least, it took a while before I started doing this for my routes.

[harahu]

No, it all looks good to me. I will wait until the weekend to give people I pinged time to have a look but otherwise merge. We can always fix things later :-).

Was there any interest from the people you pinged over the weekend? If there was no interest and you're still uncertain about the relation part, my offer of splitting the PR remains open.

From what I can see though, the relation schema works as well as can be hoped for in iD at the moment, so I'm not too concerned with just merging it as it is. And if issues do arise after merge, I'd be more than happy to help in resolving them.

[tyrasd]

Sorry for jumping in a bit late here, but I noticed that we now have two presets with the same name "Climbing Route". One for the lines and one for the type=route relation. I also see that there are only a handful of route relations with route=climbing and could not find it mentioned on the wiki…

Intuitively, it would make sense to also have relations for climbing routes (that perhaps also include also the access paths to the route bottom, etc.), but those should be properly defined, discussed and documented fist, shouldn't they?

[tordans]

@harahu this #1598 (comment) is best answered by you. I did in fact not check what Martin mentioned but only the route example from the preview which would then be one of those 5.

[harahu]

The route relation style is in fact mentioned in the wiki. Here: https://wiki.openstreetmap.org/wiki/Climbing#Multi-Pitch

Each stage/pitch of a multi-pitch route can be mapped as a climbing route. A relation that represents the whole route can include all of them together. There could also be a highway=path connecting the climbing routes. These sections can also be added to the relation. The route relation would have the name of the route.

I'll admit, it's not the clearest unambiguous description, but I think the schema in this PR is a sensible interpretation. What do you think, @tyrasd @tordans?