General discussion: when to use ways vs nodes for difficulty changes of difficulty or hazards on a trail + should we expand hazards (and/or create an obstacle=*) for hiking/walking/multi-use paths?

General talk Tagging general discussion
1

This is something that has come up obliquely in conversation a few times.

Up in the mountains, or in the sandstone canyons of the Southwestern US it’s fairly common for an obstacle that could be T3 or even T4 (a simple mantle requires use of hands to pull yourself up) along an otherwise T1 or T2 path.

In this thread someone mentioned making a 1m section of a path a scramble. It techniquely works, but feels awkward.

I put up some related examples of brief obstacles/hazards in a previous comment.

This also comes up when discussing grading certain paths.

There’s some momentum into having exposure / risk of falling be a hazard node vs a tag on a way. I’m fine with that but if we’re going down that road it’d be helpful to have other ones as well.

This is the approach Hawaiian state agencies use to describe trail hazards:

Screenshot 2023-10-30 at 12.08.26 PM
Screenshot 2023-10-30 at 12.08.26 PM1920×1460 477 KB

This is technically a T4 / scrambling level move but would work better as obstacle=mantle:

Likewise instead of marking an entire trail T2 or surefooted_hiking due to areas like this (or making micro-segments) being able to put in a obstacle=stream_rock_hopping or something here:

1 Like
2

I could see the following for hazard=* off the top of my head. Wording is pretty loose.

steep_slope - the path passes by a slope steep enough that it might not be possible to stop an uncontrolled descent down it.

direct_long_falls - the path is exposed enough that a loss of traction would likely lead to a fall that would be fatal or near fatal

indirect_long_falls - it is possible to have a fall that would be fatal or near fatal, but it would be likely to recover after a loss in traction

airy_but_safe - actual falling would require negligent behavior or failure of protective infrastructure, but people with a fear of heights may be uncomfortable due to feeling exposed.

falling_trees - due to previous fires or loose terrain trees fall somewhat regularly along this path.

flash_flood - during heavy rain this area is prone to flash floods.

falling_rocks - rocks fall on the path here.

slippery_rocks - rocks are moss covered, wet from mist, or otherwise have poor traction due to being wet.

there’s a lot of ocean related ones here Hawaii Camping Reservation - Reservations

These feel more like obstacle=* - they aren’t hazardous but can often occur in a path which generally requires a simpler means of travel (is a T1 path with a water bar T2? with a single mantle T4?)

mantle - you have to use your arms to help pull yourself over an obstacle, but your feet aren’t off the ground for more than two steps

rock_hop_crossing - you have to be surefooted enough to hop across rocks at an unbridged water crossing.

natural_staircase - uneven stairs made of natural rock in a trail to help prevent erosion or assist with stock animal use

water_bar a shin to knee high obstacle in the trail meant to divert water

3

Why? That’s exactly how OSM handles stairs as part of a sidewalk…

I think part of the disagreement about these tags is the convention that a trail be judged by its most difficult part vs the desire to highlight specific trail features for navigation purposes.

That seems more like a rendering issue than a tagging issue to me, since a complete route could contain different sub-trails that each have different difficulty, and the difficulty of the total route should be calculated as the most difficult sub-section included in that path?

3 Likes
4

I like it!

Would that be covered by Tag:ford=stepping_stones - OpenStreetMap Wiki ?

3 Likes
5

In your own words “they all feel wrong to me”. :slight_smile:

I’m not saying it’s incorrect, or that you’re using OSM wrong, just that it isn’t an elegant solution. On a personal note, if I’m viewing a trail zoomed out I don’t really want to deal with it broken into tiny segments (this already happens with junctions to little use trail lookouts etc). How noticeable is that 1m section going to be if someone is looking at a 6km path?

Possibly. There’s a difference between the nice tame stones in the OSM wiki which is a different experience from the one pictured.

Depending on what water levels are this crossing near Tenaya lake is pretty simple.

678×1016 340 KB

This one near Evolution lake requires some more dexterity (too lazy to look for my own photos of these locations).

Imgur

I’m not sure we need to have a whole key based on stepping_stones lol, but I think there’s at least two meaningful levels of difficulty. Or there could just be more examples on the wiki to show the range of options.

That’s a related issue. I’ll rarely break an existing path up into distinct subpaths - one clear example was where a T1 trail went into a rappel. :stuck_out_tongue: That could theoretically all just be a climbing route, but you can walk up a wash a decent distance into a canyon before you hit the spillover, in that sense it’s useful knowing that part of it is a pretty straightforward walk and then you hit technical climbing.

There are some trails in Needles NP that have a mantle a few miles in - IMO having the entire trail be marked T4 due to that, or be rendered like that client side isn’t helpful. Having a little mantle icon overlaid over that spot would seem more useful.

For a trail which is consistently T3-T4 that’s not necessary of course, but for many people knowing they can get to X point before it’s exposed or has some obstacle etc would be useful.

If this is in the middle of an otherwise T1-T2 trail (which can just be collapsed into T2 unless you can get a meaningful distance or to an interesting area when it is T1) should the entire trail be rendered as T3, or should someone have to zoom into a 0.2m segment to see how it is stippled/colored/etc?

6

I don’t think that we should get into the realm of “map every literal obstacle” - but I can think of quite a few times where there is literally one or two short sections that place more physical or psychological demands (or have safety issues) on a trail. Having it be rendered similar to the Hawaii map seems like it’d be more useful than just bumping up the technique difficulty for the entire way, or trying to break it into micro-segments. That is a rendering issue, but also one of data structure.

There would probably some caveats like obstacle=mantle isn’t necessary on trails that are already T3 or above etc.

The following are all technically T4 moments that exist once in long stretches (1-4 miles) of T2 terrain. Mostly XC because that’s what I’m more interested in personally, but some of these are along informal=yes ways in OSM. Personally having a 0.3m way that is T4 seems awkward, but it’s also not quite fair to put the entire route at T4 (looking at the example photo on the OSM wiki). I can pull up more, but I think these get the general idea across.

2.5-bday
2.5-bday1536×2048 515 KB

2.5-ff
2.5-ff1536×2048 506 KB

2.5-gc
2.5-gc1920×1440 567 KB

2.5-paria
2.5-paria1920×1440 559 KB

Likewise with the photo featured before, from the north you can go by two lakes on T1-T2 terrain, and from the south you can walk up a nice valley to a waterfall on T1 terrain. Marking that entire way as T4 isn’t accurate, nor is calling it T2 because 99.99% of it is up to that scale either.

7

Here are my thoughts and how I see things with the hope it might be useful:

Ways should represent continuous attributes like a sustained change in difficulty or a prolonged hazardous stretch, ensuring a coherent depiction of the trail’s character. Occasionally, this might necessitate splitting up a way more than desired, akin to the segmentation seen with turn lanes on highways.

Nodes on the way can denote discrete, localized features such as a particular rocky area or a sudden steep incline, akin to how curbs are denoted on sidewalks, providing localized pinpointing of such obstacles. ford=stepping_stones is a great example of this in action for trails already. Keep in mind each key can (potentially) have various different prefixes and suffixes as well as sub-keys. So if we determine more detail or sub classification is necessary, a scheme like landuse=residential + residential=* could be put together.

It might be tempting to be as specific as possible with every tag one adds. In reality, this is usually a bad idea: The simpler and shorter a key is, the higher the probability that some user, app or map is actually making use of this information and can display it when appropriate.

Distinct Features from the trail like a nearby cliff or a river can be represented as nodes, ways, or areas, based on their spatial extent. It is important to stay true to one feature, one element.

Relationships can encapsulate the overarching properties of a trail route, knitting together various segments and features into a comprehensive trail representation. An overarching difficulty level for example could be either automatically inferred by data consumer by looking at the difficulty of the member segments or it could just be set as a tag on the relationship itself.

1 Like
8

Agree with what you’re saying, so what would you add?

difficulty=*?

Very subjective as some people will sprint across a spot where others will edge across with a stick to help keep their balance!

9

I don’t know how deep I want to go down this rabbit hole.

  1. keep ford=stepping_stones to refer to the sort of flagstones in the water pictured on the wiki page and then add in a ford=uneven_stepping_stones? In practice distance between stones is important too, but…

  2. just expanding the wiki to make it clear that it encompasses the range of the following:

  • flat easily walkable flagstones placed in the crossing
  • regularly spaced natural boulders placed in the crossing
  • uneven naturally distributed rocks in the crossing

The word difficulty is very problematic. From my hiking_technique / foot_scale thread:

10
  1. keep ford=stepping_stones to refer to the sort of flagstones in the water pictured on the wiki page and then add in a ford=uneven_stepping_stones ? In practice distance between stones is important too, but

The problem with introducing a new tag like ford=uneven_stepping_stones is that it fractures the existing ontology and makes it more difficult for systems that rely on those tags to parse and understand the data accurately. This is a particular concern for backward compatibility.

A better approach would be to employ a composite tagging scheme that utilizes existing, well-understood keys. For instance, you could use ford=stepping_stones in conjunction with additional qualifiers such as stepping_stones:spacing=irregular or difficulty=high. This method is more extensible and flexible, allowing for a richer dataset without requiring a change in the base key.

For example:

  • ford=stepping_stones
  • stepping_stones:spacing=15cm-50cm
  • difficulty=moderate

By using this approach, existing systems can still understand the basic ford=stepping_stones tag, while newer, more capable systems can interpret the additional tags to offer a nuanced understanding of the ford’s characteristics.

11

For the difficulty rating of a stepping stone ford? sac_scale may be the key you are looking for :wink:

12

eh, sac_scale has issues and the wiki explicitly states it shouldn’t be used on nodes. I described it as T2 because it’s a commonly used system in OSM, but most of the world doesn’t have any prior experience with the Swiss Alpine Club.

That’s probably overly detailed - difficulty is also very subjective and can vary depending on water levels of the crossing (something in the spring or after a big rain could be dangerous, while in the fall it would be trivial). Angle, traction, size, etc are more useful than a generic difficulty (difficult for whom?). I personally consider a lot of T2 terrain “fun” vs “difficult”, but I would also boulder hop for hours as a kid for recreation.

I’m less concerned with implementations of a specific obstacle at this point vs the idea of having a node that embodies this vs bumping up the difficulty of a way. Apple Maps actually popped up a staircase (a common urban obstacle mapped in OSM) using a similar visual treatment.

IMG_8519
IMG_85191179×1087 122 KB

13

Did you mean sak_scale instead? Swiss army knife scale? Then I’d be fine with this advise. Otherwise, no.

14

highway=scramble wasn’t in my list of things that feel wrong, though…

15

I don’t think I mentioned highway=scramble in my original post here or in my response to you, just the fact that you marked a 1m portion of trail as a scramble. The markup was as a step, but the intention was for it to denote a very short section that required scrambling (I assume it is not literally a 1m high staircase consisting of one step). That seems more appropriate than trying to create a 1m way, but having a node that fits more cleanly seems like it’d be more ideal than stretching what a “step” is.

16

It’s just a stone ledge on the trail where you use your hands and high-step up onto it and pull yourself up to the higher trail. You might not realize it’s part of the trail otherwise. Node: 11131430529 | OpenStreetMap

17

We have highway=ladder now for both nodes and ways. I if got tasked with scramble on nodes, I’d call it barrier=scramble instead. I do not see much sense in mapping things as a highway that are points on the aerial. A highway=* on a node may make sense for constructed things like ladders or intangibles like busstops. Curiously, we have barrier=step on nodes vs. highway=steps on ways. OSM has no logic. Everybody free to draw up their own. I put my money on foot_scale in the mean time. But is it for nodes?

18

Curiously, we have barrier=step on nodes vs. highway=steps on ways. OSM has no logic.

to me this seems logical, because an individual step is just a point (the width is represented by a tag and the direction is orthogonal to a way), while “steps” are linear, they have a length in addition to their width (both also would have heights, which could be expressed similar to width).