Dangerous 'path' on Table Mountain needs removal

Hi

There is a route listed in OpenStreeMaps showing the scramble\rock climb up Nursery Buttress as a “walking path”. This has led to two rescues, one actively taking place as I type this. OpenStreeMaps data appears in several 3rd party apps, Geocaching.com for example. The route is a “C” grade scramble and ropes are recommended for the middle section. It does not belong on apps recommending walking routes. Can I just remove the route from OpenStreetMaps, should I request someone more experienced remove it?

Any guidance is appreciated.
Andrew

That’s this one: https://www.openstreetmap.org/way/456205637

It is tagged as “demanding alpine hiking”. Perhaps that’s accurate.

Better hiking-focused maps will show this differently than a simple path. (The Geocaching map is not one of these; it doesn’t distinguish, and has other shortcomings for serious use.)

We don’t remove; we tag more accurately. See discussion here:
https://www.openstreetmap.org/changeset/124409974
…for a similar situation, with explanations. Note the link to the “ground truth” rule.

Regards.

My two cents: you can use all the appropiate tags, but if these aren’t used in the rendering of the standard map on osm.org, you won’t help keeping the general public out of trouble.
So a different styling of alpine paths is required.

Yes, there are. Carto has enough problem with informal=yes and via_ferrata=yes already, if not surface= and smoothness. It’s not a hiking render. Even CyclOSM on the OSM website shows some info. If you want to stay safe, use Waymarked Trail, or an overlay.

OK, so here’s my take. I completely understand that the paths are tagged, and that makes sense. However it’s still possible for third party developers to just “download” everything and make it available on their app, in complete ignorance, thereby allowing the users of that app to get into major trouble. This is exactly what happened 2 nights ago on Table Mountain resulting in a 5 hour rescue operation. The app users don’t have an option to interrogate the route in the app and assume that it’s a good path. It is not a walking path!

If you look on websites like Geocaching.com this route is shown with absolutely no reference to the danger and the path “style” is exactly the same as the two adjacent routes which are much easier.

It is pointless following this up with third party developers, it needs to be fixed at source.

Is it possible to by default remove trails over a certain difficulty unless specifically filtered for? This will inhibit third party users from advertising these routes unless they specifically want to include them.

This is also not the only route that should be removed from 3rd party apps. The Ledges\Saddle Face route for example is a rock climb, not a path! Once again, advertised on Geochaching.com and other sites as a ‘path’. It is not a path!

There are numerous others and this is going to result in further incidents.

It the data is correctly tagged in OSM, the source of the problem seems to be the third party app making a misinterpretation of the data.

You can see in the wiki https://wiki.openstreetmap.org/wiki/Key:sac_scale that sac_scale=“demanding_alpine_hiking” is for people with

OSM doesn’t have control about how each app show to their users.

Each developer has complete freedom to download, filter and interpret the data as it seems it is the best for their users. Maybe warning the users of the app in the appstore.

Yes, its possible. Third party app could filter, curate data,and render trails as appropiate.
See https://wiki.openstreetmap.org/wiki/Hiking_maps

Hope that app developers understand that with misinterpretation and bad guidance they could be putting their users at risk.

Or maybe is not correctly tagged. The route modeled by the relation https://www.openstreetmap.org/relation/7057848 has no tags.

You can’t rely on the app developers to check. OSM is advertising this data source, OSM should take responsibility, even if it’s just a check box to stop developers getting access to a certain difficulty of trail unless they select “I agree” or some other sort of gate keeping function.

I don’t know what the mechanism is that the developers use, that’s not my job. My job is to fetch people off the mountain, or bag them if they can’t be ‘fetched’ :frowning:

My team and I would like to do less of this. I’m merely reporting on what we’re seeing and asking if OSM could possibly be part of a solution.

I wonder what the source of this route relation is. Is there actually a route called “Nursery Buttress” waymarked or signposted? If there isn’t, there may be a good argument that OpenStreetMap shouldn’t have a “route=hiking” relation here (even if the underlying way is maintained).

If there is really no identifiable path there is probably a good case for removing it from the data, or for replacing it (or part of it) with the specific climbing tagging documented here:
https://wiki.openstreetmap.org/wiki/Climbing

The user https://www.openstreetmap.org/user/Akkedisi profile says “Active editor of RSA Cape Country mountain features and hiking routes.” so it seems that has a specific interest in this type of features. I sent him message asking to join ths thread.

It may well be that “highway=path” isn’t appropriate at all here, and therefore it does make sense to bring the person who added this into the discussion. I’m not familiar with the area and can’t comment on that, but if there is something there then it should be in OSM (not necessarily as a “highway=path”) and tagged appropriately.

However, even if the current tagging is correct, to be clear - the OSM data is NOT advertising https://www.openstreetmap.org/way/456205637/history as something that people should attempt without knowing what they’re up against. The tags currently used are described at https://wiki.openstreetmap.org/wiki/Key:sac%20scale as “Exposed and demanding terrain. May include steep rock scrambles, glaciers and snowfields with risk of sliding”, with requirements of “Mountaineering boots, Reliable assessment of terrain and excellent navigation skills, Good mountaineering experience, Knowledge of elementary rope and ice axe techniques”.

If a map based on OSM data is giving an incorrect impression then that’s something that has to be taken up with the developers of that map. In the case of OSM’s “Standard” map, this issue has been raised at https://github.com/gravitystorm/openstreetmap-carto/issues/1500 , but unfortunately that project is struggling to make decisions about the way forward due to the entrenched views of one of the maintainers**.

Different maps and apps have different goals. A quick check suggests that a map actually designed for hiking https://www.gaiagps.com/map/?loc=15.6/18.4207/-33.9850&layer=GaiaTopoRasterMeters doesn’t show “Nursery Buttress” but does show “Nursery Ravine” below.

In cases like this, “just removing the data from OSM” is almost never the right answer. Another user will just add it back, perhaps with even fewer warnings.

Best Regards,

Andy

(writing here in an entirely personal capacity)

** for completeness, I do look after a map style based on a historic version of OSM’s “standard” map that would explicitly exclude this “path” from view due to the sac_scale value. Although it would be possible to, I don’t currently create maps of South Africa using it. I’d be happy to create a pull request to try and alter OSM’s “standard” style if I thought that there was even the slightest chance that I wouldn’t be wasting my time, but I don’t think that there is.

Isn’t it better to place a warning sign on the beginning of the trail?
I think if we start to remove every highway=* from the osm where accidents are happening, than we can better stop with the osm.

At the moment, it seems to me (without having knowledge on the situation on the ground, so purely based on this discussion) that the facts are correctly recorded in the OSM database.

However, while an application developer using OSM data has all the information needed to display (or hide) this ‘path’ in an appropriate fashion, the structure of the OSM data model means that a lazy or uninformed developer – one who does not consider this issue at all – will default to displaying this as a regular path.

So there is an argument to be made that the OSM data model ought to be changed so that developers would have to make a conscious decision to display dangerous routes. For example, this could be done by assigning these to a separate highway class instead of classifying them as a “path”. This would be a larger change, though, not something that can be meaningfully done for this particular path in isolation.

So I did as suggested and brought this to the attention of the developers of one of the apps, here’s the response.

Hello Andrew-

Thank you for contacting Geocaching HQ.

Geocaching HQ is not a cartography company. Geocachers who decide to use OpenStreetMaps or another mapping tool understand that the map may not accurately depict the physical environment. Please contact OpenStreetMaps for additional assistance.

Additionally, geocaching by its nature is dangerous. By using Geocaching.com® or the Geocaching® mobile app, geocachers agree to all of the risks which may be present when attempting to find a geocache. Please consult our Terms of Use should you have additional questions.

Best regards,

Adam
Community Coordinator

So I guess that effectively ends this discussion.

cheers all

@IdleLayabout just some nearly random comments

  • as can been seen from the previous comments this is not a new topic, and has regularly cropped up in the past and even that has increased fueled by the pandemic and the wider adoption of OSM,
  • we strive to accurately model the real world, but often there is even fuzziness and subjectivity even in what you would think are clear categories,
  • if there are sections of the route in question that go above UIAA II (but see above) then they should be split out and the whole thing should be modeled as a climbing route with access and exit,
  • hiking is a dangerous sport (in absolute numbers of bad outcomes) and people are capable of getting stuck and killing themselves completely without the help of OSM,
  • proper hiking preparation requires using appropriate maps / apps and best local knowledge,
  • geocaching.com clearly isn’t geared towards such activities which makes the references to it a bit of a red herring (BTW a vague “ropes recommended” statement would seem to be just as bad as using an inappropriate map, likely to simply get more people in to trouble when things go pear shaped).

Now as has been pointed out we don’t and can’t have control over what third parties do with our data, but there has been work done on codifying best practices (see the work of the OSM-US trails working group, Frederik Ramms talk at last years SOTM https://2021.stateofthemap.org/sessions/GEKXWL/ and others). While this work has mainly centered on ecological impact, safety is clearly part of the scope and one of the outcomes could well be criteria, a vetting process and a label for uses of OSM data that follows best practice. The discussions on these topics is split out over many fora right now, but you are naturally invited to participate in the discussion and I hope that we can move all of this to a more central place.

Simon

This just shows that the geocaching company doesn’t really care and has no idea what they are talking about.

  1. You can’t just “contact OpenStreetMap” (no trailing s) because it’s not a company and there isn’t a single representative point of contact
  2. OSM does not provide cartography, it provides geodata that can be used by others for cartographic purposes (i.e. the maps are not made by OSM)

i.e. the problem is that geocaching.com can’t be bothered to care about the security of its users. Removing information for everyone else who would like to use that information responsibly is not an option.

There is an effort in the US to define consistent tagging for things like informal trails. Parties to the discussion include representatives of the companies that make AllTrails and Gaia. I believe that they are already working on revising their rendering to reflect, at the least, the difference between formal, maintained trails and informal, unmaintained trails. It would not surprise me if other attributes like the SAC scale will be considered too.

I think the way forward is to assure that this route (I hesitate to call it a trail) is properly tagged in OSM and then to get the developers of the various apps to emphasize, de-emphasize or even hide trails/routes based on the tagging. To this end, has anyone contact the geocaching.com people about how they render routes marked as demanding mountain hiking?

I think that’s what IdleLayabout did, as reported in their reply above (23 August).

Do we know if geocaching.com renders their own map, or do they use tiles from a third party? (I couldn’t see anything on their website without signing up).