[RFC] Mapping (climbing) routes using images

[zby-cz (Pavel Zbytovský)]

Hi,

we would like to discuss a new tagging schema for (climbing) routes overlayed over an image.

Currently, more than 60,000 climbing-related features exist (routes, crags, areas). What we’d like to add is an open-data approach to marking climbing topos - ie. maps of the rock faces.

The route always has a name + difficulty grading and is physically equipped by in-drilled glued bolts/anchors on the rock. Climbers need information about the position of the bolts which define their chosen route. The rock faces have different inclinations - a slab, vertical face or overhang. And only the slab can be practically marked with OSM nodes for each bolt, which coould be connected in OSM by a way with climbing=route. The non-digital approach is description like “climb 2m to the shelf, then continue left along the crack to the top” – which is both hard to understand and hard to write.

So we eventually came up with a schema, where routes can be described by a linestring defined by percentage coordinates on an image. You can find the whole definition here: Key:wikimedia_commons:path - OpenStreetMap Wiki

Basically these two tags:

wikimedia_commons = File:Roviště - Monolit.jpg
wikimedia_commons:path = 0.682,0.823|0.642,0.453|0.557,0.177

would say the climber can look at the Wikimedia photo and the route is between pixels:

1. x: 68.2% y: 82.3%
2. x: 64.2% y: 45.3%
3. x: 55.7% y: 17.7%

Example image – in OSM.org – demo viewer:

Of course - to make it really helpful, their app must overlay the position over an image, but that’s straghtforward.

Advantages:

• helpful for climbers – could form the basis for the first open-data climbing guide
• in future this could benefit also other non-climbing usecases, for example:
  • via ferratas - sketching a route in the photo conveys much more information than purely geographical data
  • avalanche exposure - marking the area in a photo gives much better perspective, potentially saving life
  • navigating a path through vast area (desert/ice) where target is clearly visible, but route changes seasonaly, or is optional.
  • HOT OSM - marking a temporary detours sketched on field photos before fresh imagery is available
• from the technical standpoint, there is no limit on how many tags can be applied to a feature, so no issues seem to be here
• this will bring more climbers to contribute to OSM, perhaps not only around rocks
• having the data directly in OSM allows discoverablity (important) and offline usability
• the same schema could work above other image tags like image=* / image:path=*, but I don’t see need for that now.

Disadvantages / questions:

• the numbers in wikimedia_commons:path are readable by human - but unlikely for anyone to do so. Perhaps, similar to color=#ff6600, opening_hours or turn:lanes
• not sure about the key - maybe wikimedia_commons:linestring could be better?
• not sure about the encoding, maybe using full 68.2% could be more human-readable?

With @jvaclavik we designed a proof-of-concept app with editor, to show how this could work - see openclimbing.org.

It’s OsmAPP enhanced with two additional parts: climbing map and topo editor. Both parts are described on the wiki, see the Technical overview section: osm.wiki/Openclimbing.org

We would really appreciate feedback from the community on whether this approach fits into OSM tagging conventions and how it might be improved.

cc @harahu, @Adam_Franco, @_MisterY, @StC, @brightj, @Halbmastwurf

//edit: please focus on the wikipedia_commons:path in this topic. We welcome ideas for the OpenClimbing app, and share the view that upload and offline are two main paintpoints. But the app is still more of a technical preview yet.

Screenshots from the openclimbing.org app:

Mobile:

[_MisterY]

Thank you for sharing this info and opening for discussion. I will just briefly share my experience and observations.

I find the idea fantastic. Representing OSM information in this way - visual, like a map but not in the hundreds-of-year-old top-view perspective - feels innovative as it displays the “map” on a useful plane (climbing walls are mainly vertical).

The idea of having an open topo store is very welcome and totally overdue. There are sites like Bergsteigen but something open and community-driven (hence, longer-term) would be even better. Climbers are relying on books that are 10-years old while the routes and crags are literally exploding in numbers in recent years.

Some sites I’ve visited have their own hand-made topos but standardizing (and optimizing) ways of recording these would help in information creation, storage, and sharing.

The main issue with the proposed scheme, that I see, lies in implementation. The image upload and linking is fairly tedious at the moment. That is probably why there is not much uptake on the idea. I’ve done a few and still have to refer to a task list in order to complete the next upload. A decent part of the issue is wikimedia’s 5 screens of mandatory fields for what is supposed to be a simple image upload.

Other than that, I’m fairly excited by the idea and the solution so far. I now often make crag photos and have another member of the climbing group taking crag shots with a drone. But adding these, in the current setup, would take a better part of my remaining life, I’m afraid.

That’s my $0.02. Thank you for the creation of openclimbing and looking forward to making it more popular and accepted in the climbing community.

This reminds me of a separate issue. In order for the site to really be useful to climbers, the app would definitely have to be available completely offline. The majority of multi-pitch routes and mountain crags are away from the mobile coverage. OsmAnd has recently significantly improved the coverage of climbing items on the map, which is commendable. But the topos are the most useful when actually at the crag/location.

[fschmidt]

Wouldn’t the path become invalid when the image is replaced?
Poor example, as there is no climbing route in the picture: File:Fichtelberg.jpg - Wikimedia Commons has a new version of the same photography, slightly rotated.

[brightj]

Yeah I was going to say the same thing. You should reference a particular version of the image in case it gets cropped, etc.

[Kovoschiz]

Fundamentally before anything is discussed, you need to explain why this should be included in OSM. “having the data directly in OSM allows discoverablity (important) and offline usability” isn’t a sufficient reason, as this can be argued for everything. Photo annotation quite characteristically belongs to a different database, in your project. Eg OSM doesn’t even pinpoint or circle where the object is in a wikipedia_commons= photos yet. Therefore, an openclimbing:*= similar to openplaques:= and openbenches:*= is preferable. .

For implementation issues that even your software needs to consider, Commons can have newer file versions uploaded, and categories can illustrate something in different angles with multiple photos. You would need to refer to a certain version, and consider how categories should be integrated.

[Adam_Franco]

I wonder if it would be possible to add the path data to the File object page in wikimedia commons instead of OSM? Since the path data is fundamentally related to the image, storing it with the image could make sense.

Potentially a MediaWiki template could help make the data both human and machine readable. Ideally, such a template could even overlay the path on the image for display in wikimedia commons.

All that said, I could then see there being a challenge associating the OSM climbing=routewith the path in Wikimedia commons when a photo might include several routes.

[Adam_Franco]

Maybe a representation of the route in Wikidata would be better. The OSM node/way for the route could point at a wikidata entry, which could then store the references to photos and the path data. This wikidata entry could also include additional route details like pointers to the first assentionist and other information that might be less appropriate for storing in OSM tags.

Spreading data across multiple databases is less ideal than only one, but OSM tags come with many limitations.

[zby-cz (Pavel Zbytovský)]

Hi everyone, thanks for the valuable and constructive feedback!

@_MisterY Thank you very much for the encouragement! Regarding upload+offline, we know these are the main painpoints. The current app is more of a technical preview.

@fschmidt & @brightj – regarding reference to the exact image: thats a very good point! I think the way forward would be to use the “old id” numeric wikimedia ID of revision, which could be perhaps added as the last part, eg. wikimedia_commons:path=<point 1>|<point 2>|...|oldid=<oldid>. This would also prevent losing the information about the image, in case of accidental edit of the photo name, which is stored in a different key.

@Kovoschiz – thanks for this fundamental question.
We believe that this data is also spatial data, and even though it is projected on a 2D image, the line string represents a physical path on a real-world object. It is basically a micro-map. We see the photo not as a picture, but as a basemap for that specific vertical face.
Using tag key as openclimbing:path is also completely fine, but I think this schema has broader potential. Btw, the linestring schema could be also without modification used for pinpointing the object location in the wikimedia_commons photo.
As for Categories - this schema only works with File links - wikimedia_commons value starting with File:

@Adam_Franco – While storing this data in Wikimedia Commons page content, or Wikidata is perfectly technically feasible, we still believe that simple, straightforward (hackable) things work the best. This is the case of OpenStreetMap as whole, and also the very simple syntax of the proposed wikimedia_commons:path. The simplicity of working with such schema has been proven while designing the demo viewer and editor.

[woodpeck (Frederik Ramm)]

I am not sure I understand the full depth of this, not being a climber myself. You mention “bolts” in your post, and if there are any bolts or other real-world objects it is ok to map them. What is not ok, however, is the mapping of any suggestion as to how to navigate a rock face in the absence of physical markers. Such suggestions - unless painted onto the rock or otherwise marked - have no place in OSM because they are not verifiable on the ground (or, more accurately in this case, on the rock face).

[brightj]

There are lots of things mapped in OSM that don’t have physical markers…

[_MisterY]

@woodpeck

unless painted onto the rock or otherwise marked

This stems from “not being a climber myself”. The climbing routes are usually well established, in a sense that a particular route needs to be followed to the letter. Otherwise, there is a big risk of not making it to the end due to difficulty increasing exponentially by making a 1m traverse in a wrong direction.

In Austria, at least, these are also mainly well bolted, with bolts indicating the way. Otherwise, one follows what is know as a “topo”, i.e.:

The point being, if the route is grade 4, and you can do 6, then you can be reasonably confident about making it to the end. Straying away from the route gets obvious fairly quickly, most of the time. This goes for multi-pitch routes.

Sport routes are even easier. They are (almost) always bolted and easy to follow. Well, sometimes they cross or are too close together but that’s another story. All this, however, is obvious from the topo. And what @zby-cz is demonstrating here, is basically creating and storing the topos in this specific format and medium.

Edit: With this example above, you can imagine how much easier this process is made by using photos, instead. Obviously, this was not the most practical option years ago, when the scheme developed.

[woodpeck (Frederik Ramm)]

@brightj

There are lots of things mapped in OSM that don’t have physical markers…

Yes. Maybe not lots, but some.

Still, our general rule and the foundation of peace in our project is on-the-ground verifiability. You will find dozens of wiki pages that explain the concept. If two mappers disagree, then we must be able to visit the place, look at it, and say: aha, obviously X is right and Y is wrong.

As with every general rule, we do sometimes make exceptions. The existence of exceptions does not mean that the rule can simply be discarded altogether and that everyone is free to map subjective things like “this is a recommended nice afternoon stroll from my house”! We make exceptions from the rule where we believe that the non-observable data is of exceptional importance and that the benefits of having it in OSM outweigh the problems of lack of verifiablity. Typically we make these exceptions for administrative boundaries - because not only are they relevant for people, they are frequently also relevant for the mapping process itself.

Anyone who wants to map something in OSM that is not verifiable on the ground must explain why they believe that it is of high enough importance to suspend the important principle of verifiability.

“Others do it too” is not a sufficient explanation - in fact, we should all make an effort to find and remove un-verifiable data from OSM where there is no explicit community consensus on having it.

[brightj]

Well, they are “verifiable” in that they follow physical cracks or features in the rock and you can look at the topo and verify that you’re on-route.

• Climbing - OpenStreetMap Wiki
• climbing=route | Tags | OpenStreetMap Taginfo

[alan_gr (Alan)]

@zby-cz

As for Categories - this schema only works with File links - wikimedia_commons value starting with File:

But one of the advantages of the wikimedia_commons key is that it can validly point to a category. What happens if a mapper notices, say, that wikimedia has good photos of the route taken in morning and evening light and that each shows details that are unclear in the other, so changes the tag to refer to a category? It seems that would break the :path tag. But it would be odd to revert the change given it adds useful information.

I think this is a good illustration of something touched on in other replies: the proposal ties together a widely used tag visible in many tools, and a very specialised one that most mappers won’t be aware of. I wonder if it would be more stable to use two specialised tags.

[zby-cz (Pavel Zbytovský)]

@alan_gr - Yes, that already happened a few times. In that case we left the Category: in wikimedia_commons. And add second image tag with the linestring, like:

wikimedia_commons:1=File:...
wikimedia_commons:1:path=<point1>|<point2>

But I am starting to realize, that using a specific key would be probably more viable option. Something like photo_with_linestring, climbing:linestring or perhaps even openclimbing:linestring… I have to give it more thought first. A very raw unfinshed idea below:

photo_with_linestring=File:ABC.jpg?oldid=123|<point1>|<point2>
-or-
photo_with_linestring=File:ABC.jpg?oldid=123
photo_with_linestring:path=<point1>|<point2>