I can see how a node network of sorts could exist without fixed routes between the nodes. I imagine a cluster of recognizable objects (poles, stones) with unique labels (numbers, codes or names of nearby landmarks) distributed in a region, serving as intermediary destinations in a composed itinerary. There would be verifiable ground truth and fixed geolocations, so it’s OSM-mappable. Named landmarks themselves could serve as network nodes.
You can do network planning using just the nodes, no problem. The routes would be bird routes as placeholders, to be replaced by real routes by the user, who has to find her/his way from Node to Node.
If enough people use the same trails while gps-tracking and uploading the gps-tracks afterwards, gps-heatmaps could be available, and I am sure software/apps could use this to suggest possible routes (even with seasonal variations) realtime.
How to map? I think you just map and tag the designated Nodes as separate features, then determine possible connections. Each connection connects two Nodes, and if intermediate features, whch show the way but are not destinations themselves, are known (ways or nodes) they are entered as members of the connection relation, in the right order.
I would think such a way-less network should have its own network:type value.
The connection relations would require their own ground truth, I think. A relation starting at Node Elms_Peak and ending at Node Rock_Bottom, how can you verify on the ground that it exists? I think the Nodes need to actually point the hiker to the adjacent Nodes vice versa.
Just brainstorming. Hope this is relevant, somehow.
By bird routes you mean straight lines between the nodes? I’d prefer a wavy slightly dotted line or something just to make it clear that it’s arbitrary (or perhaps a very thick partially transparent line to show possibility).
Without the infrastructure in the first half of the post (conveniently ignoring ground truth of markers for the moment), nodes can just reference real features - in the case of the little Joe pass sat imagery I’ve referenced a few times, the bottom would be the bottom of the avalanche chute, the two decision points in the middle would be junctions in it (though that is a very obvious linear example).
In terms of the major decision point on the palisade lakes side of Cirque Pass people take the wrong turn at a little pond - marking that pond then having a note (description?) to go SE vs NW would work. The other side is open enough to need no route IMO, just make your way up from the nearby lake to the pass as you see fit.
I think it’s important to keep nodes to where they actually make a meaningful difference (say avoid exposure, keep things down 1-2 SAC levels, etc) vs someone’s personal route choice through open terrain. In terms of auto-generating routes based on the season - every season has slightly different snow coverage and unless it’s pulling in historical snow coverage data and changing that by the week it’d still give potentially poor results. Creating a “path” gives a false sense of security that routefinding / orienteering isn’t necessary.
There’s also just the fact that a lot of routefinding comes down to personal preference, and trying to stick a path on it kills the spirit. Even doing the same route together, with pretty similar levels of technique my partner and I will often make different decisions.
From the OSM US Trails group:
I guess what I need to get my head around is why do folks feel the need to load non-trail/path routes into OSM at all. My bias is that route-finding in-and-of-itself is an activity that depends on a blank slate mapping-wise. Just your eyes see the landscape and understand the topography of the (USGS?) map. That’s the joy of it.
I also wonder if this has to be, or should be, a global standard. Perhaps each country or region can have its own policy regarding making routes into paths.
Apparently you didn’t read what I wrote (“in the spirit of”) and what’s in the link. Wikipedia’s “Original research” applied to OSM would for instance be if I would create a hiking route relation named “Richard’s favourite hike” that includes my favourite hiking paths, but that only existed in my own head before. It’s similar to OSM’s verifiability principle.
no, it’s not, WP doesn’t want your observations and interpretations of the world, they want you to select information and interpretations from experts (sources), OpenStreetMap’s verifiability requirement states that everybody is an expert for their area.
This is a very interesting thread, but there is a heck of a lot of information in it.
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 do think we need something like this, if only because people have been mapping such things as paths anyway (see also discussion on scramble). However, this does mean identifying suitable criteria for inclusion on OSM.
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).
In my opinion pathless routes (cross-country/orienteering) should not be mapped as highway=path , highway=footway or route=hiking . These tags all indicate some reasonable level of visible path on the ground and/or trail blazing that can be followed.
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. 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. However they are rendered on specialized winter sports maps. Example area:
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. A route that is just “the way Bob happened to go” is not something that should be in OSM.
I’d say that the solution we’ll end up with needs to account for grey areas, not all black and white. In France we have very official hiking routes that e.g. cross a large concrete pr pavement area with no “path” visible, or a rocky place, etc. All have in common that you more or less see “the other side” of the gap, you known where to go. Switching to orienteering or to an fake path would seem inappropriate in those cases.
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.
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.
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.
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.
+1 to that.
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).
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:
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.
It forces the visual representation to be looser.
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.
Agreed.
There are people that think highway=path is appropriate for pathless paths, so I think it’s worth putting out a clear stance.
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.
The discussion of node networks in this thread is very confusing. A node network is a very specific thing with very specific signage and should not be conflated with a pathless route in the wilderness. Very different situations. If what is meant is “an ordered list of nodes”, then lets say that to avoid confusion.
Agreed. For small gaps in a path I see no problem with that being mapped as a highway=path. My comments are specifically about routes that are entirely or almost entirely pathless.
Just to clarify another potential source of misunderstandings.
In the OSM database, a ‘way’ is a type of object that contains nodes. It can represent a highway=path but also a river, a wall, a ski lift. Just because a list of nodes is stored as a ‘way’ in the database doesn’t mean that maps need to draw a straight line between successive pairs of nodes. Straight lines drawn on maps is what we’re trying to avoid, but that’s not an argument to avoid the use of the OSM database object type ‘way’ in favour of something more complicated (a relation).
The real question for me is: does the OSM object that you want to invent - for the network as a whole - only contain nodes? Then it can be stored in the database using a ‘way’. Or does it also contain ways (such as highway=path) and/or areas? Then it would need to be a relation.
Edit: Also if you want to store information like ‘from A you can go to D either via B or via C’ then I think you would need a relation.
A related / networked set of nodes is what I thinking of, similar to how climbing has a top, bottom, and bolt node but not connected visually with a way.
An ordered list of related nodes works for me.
I’d be fine saying the only acceptable use of something with true trail_visibiilty=no is a ground truth hack to allow for routing of formal trails across small gaps. That sort of begs the question of whether trail_visibiilty=bad should exist, although it’s probably not reasonable to expect every gap in trail to be broken into a segment and labeled. I do find small segments on trail in the backcountry more useful and appropriate than paths with varying strength and visibility.
I illustrated an example here of a short patch of trail_visibiilty=good where IMO it’s not appropriate to create massively longer path to allow for routing. I also agree that these shouldn’t show up in standard routing so that kind of makes the point moot to me.
I wasn’t leaving areas out on purpose, no, I forgot about them
But I agree with @erutan that walkable areas in the mountains often don’t really have verifiable boundaries. Picture a U shaped valley, where precisely does the sac_scale=2 terrain end and sac_scale=3 terrain begin? The hiking just gets progressively more difficult the steeper the slope.
I do fear that thinking of it as a way will lead to there being more nodes than is absolutely necessary or in the spirit of such pathless routes. That’s not necessarily a strong argument against it.
I feel like areas can be useful to show ambiguity - for some routes (say up to Dragon Pass/Peak) there is a heavily informally cairned area at the side of the lake below it which is a natural place to ascend and could be a set route_bottom. For others it really is just "head up somewhere, anywhere, just make sure you end up at the pass marked as route_top. It might not be worth having an area for the bottom as that could complicate things, instead just leaving it blank and up to map reading skills.
The route could also just be represented by area shapes that show “passable” terrain as was previously suggested by someone else earlier in the thread (Italy mod iirc).
For Valor Pass I know of people that hiked up the ridge on the south side, then dropped as that is a little simpler. We felt perfectly comfortable doing a more direct approach, but stayed above cliff bands (which doesn’t really show as well on opentopo, but with USGS or slope angle shading the map gets noisier for this purpose). This is a pretty vague representation based on my memory - and isn’t entirely accurate as there might be some 2-3m cliffs or ledges etc that could pose a navigational hazard in the middle of that area.
This tells the story pretty well, but is probably a bit overkill and prone to small errors in terrain. In this case just having a node at the top of the pass seems fine to me, the rest doesn’t have any needles that need to be threaded (aside from perhaps the chutes dropping from Valor lake to Ambition, but at some point you have to consider the route to the pass done).
Good summary. I think we should focus on these issues and leave 3) for later. (For the record I’m broadly in favour of @ezekielf’s position here).
On 1. I think we will always have some attempt to represent various hiking/climbing/scrambling routes as we do now. So I think the answer is broadly yes. What we don’t have is some clearer demarcation of bounds.
On 2. I think we need a bit more of a discovery phase. I can suggest locations in the Alps, Scottish Highlands and upland North Wales each with somewhat different characteristics, from those of the Western US. It would be interesting to have a perspective from NZ or Australia where missing the route seems rather hazardous.
We also should consider how this might apply to other areas: arid places such as deserts, tropical rainforests where routes get overgrown.
Deserts are relatively straightforward - sand will cover occasional foot traffic in many places within a year, which helps prevent informal paths from being created (though in some areas you have “biological crust” which should be avoided).
Paths can go onto slick rock as shown in the set of photos earlier in this thread which don’t hold any footprints at all but can be easily cairned. There are a lot of small cliffs in the rippling of sandstone which pose a navigational and safety hazard.
Generally long lines of sight, unless one is in a canyon, at which point things are pretty straightforward. Sedimentary cliffs tend to be problematic with different layers, having undercuts / overhangs along with strata that are very vertical are common, but finding routes that work up/down on fans caused by erosion is pretty easy to spot on topo using slope angle shading.
I’m personally mostly interested in the shorter routes up to a pass, side feature, etc rather than long multi-day routes. The longer ones, such as this previously mentioned 315km mix of paths and routes, I’m unsure about trying to represent in OSM.
Someone created and is selling a guide including “breadcrumbs” but said the following about it “My maps have breadcrumbs, not a line, in order to depict the route. Two reasons. First, there are oftentimes multiple routes to get you there. Second, I didn’t want to steal your fun by showing you the optimal route between points — you can figure that out.” in comments and then regarding a GPS track “No, there is not, intentionally. I would encourage you to ask yourself whether you need or want one. If you need one, the SHR is probably not the right route for you. If you want one, you probably know how to create one, or you can use this as an opportunity to learn.” Further comments showed that person found one online and it was useful for them. I haven’t bought the guide as I’ve done bits and pieces of nearly the entire SHR over the years just on my own trips.
I personally don’t want nodes in way so close together that they’d create a certain interpretation of a route, or create paths of that interpretation (though of course myself and others would be free to disregard it). That’s a pretty common feeling in the conversations I’ve had elsewhere was well. That said I am totally open to there being regional differences for the precision at which these routes are rendered.
People die from being off route in the US fairly regularly (which is why people need to know how to routefind!. That said the terrain in NZ tends to be incredibly vertical (and in the alps from what I know), both ranges have significantly more glaciation than a lot of the ranges in the Western US and don’t have the nice hanging basins that I and others enjoy so much, which would limit terrain. A lot of their normal trails are SAC T3-4 lol, which surprised me, and there’s not as many pleasant options for off-trail travel given vertically, thick brush, and areas that are boggy.
There’s been a useful back and forth on the US Trails group channel on node_networks. Someone in Germany came up with a “basic network” that could be worth looking at for ideas.
I think the structure will be defined by how much precision is wanted. I prefer just having some key “digital cairns” so having a grouping of nodes being more cumbersome seems fine, and even helps promote that thoughtful minimalism.
If people want a more defined route to follow then the amount of nodes would lend itself to a way. The latter could be more appropriate for some of the formal “alpine routes” in the alps etc.
I’m not sure it’s a good idea, but there could be the option of a grouping of nodes for “looser routes” and a way for “tighter routes” to cover different use cases and community norms.
