RfC: Have pathless hiking routes (no trail_visibility) be some manner of related nodes instead of paths

[erutan]

@SK53

I think it needs a more high-level summary, presumably the wiki is the best place. I’d also suggest stepping back a bit from the node or node network ideas at this stage, because, although they may work in your familiar areas, I don’t think the same concepts will apply everywhere (generally determined by the nature of the terrain). I’m going to try and extend my list of places and write these up as a diary entry.

I think this can be broken down into steps:

1. Should pathless paths be displayed on OSM?

2a) If no, end discussion and remove existing ones and document. Possibility of having this be a regional decision - maybe in Italy say social norms err more towards showing proven passable routes, whereas in Austria and the US they prioritize the sense of exploration and challenge of routefinding.
2b) If yes, how should they be represented (see 3)?

3a) Some type of node network?
3b) Some type of area?
3c) Some type of way with special rendering?

I was expecting this thread to be a bit messy and exploratory, because I don’t know the best way to address this issue, but it feels like it’s worth being addressed. At some point having a firm proposal come out of it that would then be voted on would seem appropriate.

@SK53

One other suggestion I have is to use “itinerary” instead of route or trail to avoid confusion with other concepts which use these words in OSM (I noted my use of ski itinerary in the old blog post and realised the phrase could be useful).

I’ve been trying to use “path” to indicate something that has trail_visibility!=no, then route for something which is pathless. The latter matches real world usage in both Europe in the USA.

Some people automatically think of “routing” when they see the word route (or think that trailblazes refer to ease of finding routing between trails etc), but that hasn’t been a source of confusion in this thread so far. Creating another term seems like it’d just add to the confusion IMO.

@ezekielf

If I was to map a “choose your own path” cross country routes I would coin a new tag. Perhaps route=orienteering or route=cross_country_hiking . I would document it as something only specialized backcountry navigation maps should show. I would also make it clear that they should display it not as a path/trail but instead make it clear that it is a commonly used general route where hikers navigate their own path through the terrain.

+1 to that.

@ezekielf

This new tag could be applied to a way or to a relation made up of untagged ways. A model to follow is the piste:type key. This key is regularly used to map ski pistes/trails/runs that are only visible as such in winter. Such pistes are not tagged with a highway= value and are not rendered as paths on many general purpose maps.

Interesting. The closest analogy there would be piste:type=skitour which falls into the area of a cross country route, in that it exists as a known and discussed thing in communities, but doesn’t have any real ground truth to it.

A recommended ski tour way or area that is generally used by many skiers during a season for the purpose of a nordic ascent and a downhill descent in the backcountry. Generally the descent is recommended near the ascent route for safety and terrain judgement and the descent is not mapped.

Rendered as area if first and last point are the same. If a circular way is needed, do not close the way (first and last point is not exactly the same).

@ezekielf

A way is just an ordered list of nodes and so I don’t see anything wrong with using ways to model a pathless cross country hiking route as long as there is some kind of evidence that would support its inclusion in OSM.

I was pondering this - as too many nodes essentially turns a node_network into a way. That said if it was rendered as a very wide way that might help include that visual uncertainty of routefinding.

A few unique advantages of a node_network approach that I can think of:

1. It’s very clear that the abstraction of the route (as opposed to an abstracted way) isn’t meant to be followed as it is mapped.
2. It forces the visual representation to be looser.
3. For routes that have a lot of CYOA I could see there being an area (say the shoreline of a lake) as a bottom then just a node at top, or just the top node. For those that have a key routefinding decision having that as a node allows for attention to be drawn to that point. Being able to select it (long press, etc) on a map and bring up text of a description field also seems handy:

For Cirque Pass I think having a node for the pass, a node for the small pond in the middle that is a decision point between Class 2 and Class 4 (SAC 2-3 vs SAC 6+), then one at the bottom would be fine. Having it be rendered as a way would be clearer, but the top half of that pass can be done in a lot of different ways depending on how much snow there is, people’s comfort climbing down ledges vs pin balling to different sides of the cirque for easier descents, etc.

@ezekielf

A route that is just “the way Bob happened to go” is not something that should be in OSM.

Agreed.

@SK53

My understanding is that this topic is essentially how to provide information on such things without using highway=path, but I may have missed something.

There are people that think highway=path is appropriate for pathless paths, so I think it’s worth putting out a clear stance.

@SK53

Note that even in lowland UK, some orientation on a regular footpath is often required when it traverses an open grassy field, or newly ploughed ground. It’s one reason why I now try and map trees in the hedgerow adjacent to stiles as they can aid this orientation. The actual course of the path can often be determined by the two path markers/fingerposts at either end of the field.

That’d be covered by trail_visibility, though as it stands it’s is contradictory and unclear. The wiki page makes it seem mostly about surface, occasionally markers, but iD includes markers for all levels. The original intent was for surface only and that’s how it is still being used, though apparently as a minority usage based on data scraping and most people use it as a mix of both trail surface and markers (which is already covered by trailblazed:visibility. The terse wording is also a bit problematic - something which is mostly visible vs sometimes not visible doesn’t seem like a strong distinction to me.

I took a stab at clarifying the ratings for it since there’s a push to make a proposal to change it anyways.