I suspect, all the people allowed to travel there by car in the knows. Why map that in OSM? Because there are routers that give a damn about access restrictions? No, Because the operators of local rescue services use OSM and should get a NoGo when trying to route there, Perhaps?
No idea how to map that, openclosures.ch? hazard? max_width? barrier? …?
There are at least three different landslide tags, so it’s your choice:
hazard=landslide (would fit best althouth wiki says it is only allowed if there is a hazard sign) natural=landslide (for the slope) barrier=landslide (probably for the track)
Big no to motor_vehicle=no here, that’s a legal access tag, and there’s no sign, just damage. It also excludes motorcycles, which are narrow enough to pass. Physical narrowing should be tagged as a physical property (eg. width=1.5), not an access restriction.
I’d steer clear of hazard=landslide here, that tag is meant for warning signs, not the underlying damage itself.
If this is temporary, obstacle=* fits the definition, though worth noting almost no routers actually consume that tag, so it’s mostly documentation rather than something that will stop a router.
If it’s likely permanent, I would just reclassify the segment as highway=path + width=1.5, no landslide tag needed at that point. The highway=path is what actually excludes cars in router profiles, width is a useful addition on top but not all routers honor it either.
is it real case where you look for help how to map or another purely theoretical one?
this looks like highway=path section (unless very prompt fix is expected to happen)
I would probably put also note=landslide turned highway=track to highway=path, see photo at https://community.openstreetmap.org/t/mapping-of-damage-to-infrastructure/146185
and access=no etc if legal status is such, would not add it if it remains legal to pass there
this fails to express that it remains partially passable
no sign, no hazard=
only if it is now illegal to go with motorcycles etc
That is not a problem as any barrier tag can go together with maxwidth:physical to give exact information about the situation OTG. I’d say this is definitely more precise than degrading the track to a path.
Anyhow such sections usually are completely blocked by the authorities very fast to prevent stupid people from trying to pass there and slide down the slope with another portion of the track. So it would be well worth to recheck this place at short notice to check what is going on there.
From what I gather, advise mostly: Split at both ends of damaged section, turn damaged section into a path. I cannot follow: Path is not a physical trait, but a functional one, not intended for cars, so to say. Therefore I’d have to extend the “path” to the closest junctions either end.
Meanwhile, the thing I know for a certain, maxwidth:physical is the very key for situations like this. Apply to the track (from junction to junction) or a node on the track (what to use as primary tag then)?
BTW: There are barriers (we call them Scherengitter) on either end (junctions) but one of those already pushed aside, and both not a barrier for pedestrians and cyclists. I also guess, this will stay longer, as the fix will be very expensive and not many users.
I agree with that, but I would also consider adjusting the highway=*-tag of the section.
According to the wiki, a highway=track are Roads for mostly agricultural or forestry uses.
A highway=path is “A non-specific path. […] and highway=track for those that are passable by agricultural or similar vehicles.”
However, the path is certainly no longer usable by agricultural machinery, so perhaps highway=path would be more appropriate?
Splitting a way for a physical constraint doesn’t need to match a functional boundary, that’s the normal way ways get split for any attribute (surface, smoothness, width) that only applies to part of a stretch. The path tag on that short segment just says this bit isn’t usable by cars, the track either side stays a track because it still is one. You wouldn’t extend a bridge=yes tag to the nearest junctions either, same logic applies here.
nope, not ion this case - highway=track is for land access. Remaining parts remain intended for larger vehicles (highway=track is not necessarily for cars).
They may be now far less useful, except for landslide gazing and may become overgrown/fall into disrepair but for now it exists. And if someone is logging forest, they may be entirely useful
(BTW, technically it is not necessarily highway=track, in theory it can be highway=service service=driveway or highway=unclassified - in such case longer stretch would change highway= value)
Solution awarded to @Map_HeRo - for being the only one to have a clear understanding of the risks of passing there (terrain seriously wounded, an unsigned landslide waiting to happen, especially after heavy rainfall) and mentioning that there are other mappable barriers around, even when pushed aside by the populace
Barriers mapped where originally placed on the ground by the authorities, i.e. nearby the junctions either end. maxwidth:physical set to 1 for the section between the barriers, a car with 1.5 would fit, but get quite close to the edge: Will the ground hold? It’s gravel, likely dozens of metres deep. Quite some deliberations on my end while assessing On The Ground Truth. So much for that. Thank you all for the input.
@fs_LT Happy to learn that maxwidth:pyhsical is supported by the local rescue services routing engine. Placed an OSM note, so others can track progress.
maxwidth:physical isn’t universally read. OSRM, GraphHopper, and OsmAnd support it. Valhalla and BRouter have no handler for it at all, they’d route through the section as if untagged.
highway=path would have been a defensible fallback. Tag:highway=path defines it by width (“not for use by four-wheeled vehicles, often simply too narrow”), not by purpose, and paths provide land access all the time. At ~1m clear width (#15), the section fits that definition on its own terms, so reclassifying wouldn’t have meant excluding land access, just naming what’s already true physically.
This is not the problem of the mapper, but the router.
A track does not automatically become a path, when a part gets blocked by a barrier. For such situations we do have the barrier tag which reflects the reality quite good imo.
It may become a (informal) path in the long term if it does not get repaired, people continue walking there and a real path becomes visible on the ground, but at present it is nothing but a damaged track which is closed to the public anyhow.
