A highway=unclassified recently received an overhaul: Most prominently guardrails were installed. Even where there is a highway=path joining in. See picture:
How to proceed? Map a barrier (would that then be barrier=guard_rail? Editor QA displays an invalid mapping warning icon but does not complain verbally. The path is a convenient shortcut and despite the barrier still showing use, and from the other end not obvious how it terminates, so it may well live on. Or shorten the path and let it end in a gap?
I wouldn’t keep a gap because it completly disables routing for it. I would guesspeople might just follow the guard rail on the outside until they get to the next gap? (Probably depends on how far that is)
If that’s the case, I would just add a parallel path to the road and map the barrier=guard_rail as a line inbetween.
If people just climb over, I would keep the path attached to the road as is, draw the guard rail as a line and also add that barrier tag at the crossing point with the path. You will probably get the same warning since that barrier tag is not supposed to be used on a single node, but I think its fine for that purpose, since apps might just show generic barrier, even if they don’t recognize point guard rail barriers.
Thank you, I also lean to barrier=guard_rail, never mind the documentation, instead based on the ATYL principle.
Two things can be observed from the photo: One, exactly where people climb over the guardrail, that is where the dirt on the freshly lain asphalt starts. Second, that the rail continues without a gap a hundred or more meters, far beyond where on the other side of the highway the footpath at the guidepost starts.
PS: When I rode there with my pedal bike today, two young ladies came up the path (that extends behind camera on the right hand side of the photo, the dirt, not the concrete) and turned around when they realized that they would have a long way to walk beside the rail. Obviously it did not occur to them to just step over.
PPS: Additionally, I’d be thankful of suggestions what sac_scale value the barred path should get. I’d think hiking fine? The obstacle not enough to make it mountain_hiking? At least if separately mapped?
barrier=guard_rail way mapped separately, parallel to the highway=unclassified way
highway=path way mapped separately, parallel to the highway=unclassified way
At the place people climb over, connect the highway=path way perpendicularly to the highway=unclassified way
barrier=guard_rail on the node at the intersection of the highway=path way and the barrier=guard_rail way
Should look something like this in-editor:
(Also: Parallel mode in JOSM is really helpful for making separate geometry like this. Start with a nicely detailed roadway centerline curve (CreateCircleArc from the UtilsPlugin2 plugin is a good way to do this, and that’s what I used below) and then it only takes a few seconds to make the parallel ways and re-tag them)
barrier=guard_rail on the node at the intersection of the highway=path way and the barrier=guard_rail way
I agree there should be a shared node of the path and the guard rail, but I do not understand why the node must get tags, in particular the same tags that are already on the barrier way. These node tags are not adding anything, are they?
I worked around that by just simply not mapping the guardrail at all, only tagged the node in the pathway as a barrier of type guardrail. (The notion of what value to put on the intersection occurred to me even before I started to digest what is documented.) Two things factoring in: The unclassified was overhauled and may have moved since the latest aerial was taken, so interpolating from that might create bad geometry and double the work of a follow up mapper. 2) I am not so much into guardrail mapping, rather in mapping thoroughfares and PoIs (such as barriers) along them.
Now it gets complicated: This once was a footpath maintained by a local association “Verschönerungsverein”. It still shows in administrative GIS. Where now it is joining the unclassified, ten years ago it was crossing. The northern half got demolished by the forestry department by clear-cutting and re-planting meanwhile. But perhaps, informal=yes an alias for abandoned=yes?
Will wait for further comments until selecting the solution. But Thanks for the heads up!
Not really as the dirt shows it isn’t abandoned by users. On ground informal=yes is fine but on official GIS it’s still a normal path. Complicated or weird? Or both!
Another option to consider is https://wiki.openstreetmap.org/wiki/Tag:noexit%3Dyes: if the path don’t cross the road anymore, if the road is not intended for people to walk along (I don’t see any painting or signage in favor of such usage), the path ends here. If people continue on the road, it’s their business.
Right now, my favorite option (also compatible with guided rail mapping).
Keep the path connected to the road and the guard rail and leave it up to the router to decide how to handle it.
I would personally just climb over it but a router developer can decide who the target user is. Probably no access for a general pedestrian router but crossable by a hiking router.
Report the obstruction to the local authority and get it fixed.
The validator warnings are just wrong in this case. It’s fine to tag barrier=* on a node.
Routers and other data consumers only consider barriers when they are tagged directly on a node of the highway. When they just share a node with a way that’s tagged as a barrier it’s ambiguous whether the barrier actually blocks the highway or not.
Not when it comes down on how it is defined in the wiki.
The documentation tells us that its to be a line feature only. But in special cases like this, I would think using it as a node (as well) would be beneficial for routers, as you have stated below.
The wiki is just also not entirely correct ;)
The usual way guard rails are mapped is as a linear way alongside highways, hence why it says they should be mapped as such and that’s correct. However barriers all have this dual function of
Marking the physical location and extent of the barrier (which is usually linear and mapped as a way)
and
Marking a highway as being blocked by a barrier (which requires it to be tagged on a node on the highway)
Here its case 1., not 2., 2. at most by accident.
The path go nowhere after, it’s not a blocking barrier, it’s an end, therefore my noexit=yes proposal.
I messed up a bit, the way is NOT in current administrative GIS, I must have looked at the wrong place or the wrong map. It is in old printed maps and prominent on old aerials: As those more than 30 years of age and the way still seeing use, our local law would allow anybody wanting to walk there unobstructed to file for broken easement (not knowing the special terms this is called in English?) I personally see this as a lack of insight of the planners, not friendly to pedestrians. I like the idea of @Fjellrev to place a pedestal.
In our legislation people may walk on the carriageway of any road unless it features a sidewalk, in case that it takes them where they want to get to and unless they carry bulky goods that would hinder other pedestrians use of the sidewalk.
Will wait a bit to see what consumers make of this ATYL style mapping. This certainly a niche case. The mapping intent I think should be clear, barrier=*.
Fine, but then, do you consider this specific way among other as a path (i.e. also OK for pedestrians)? Open question.
Apparently two young ladies didn’t share your opinion (i.e. even if legal).
Even if legal, without warning for vehicles coming into the area that pedestrians may be on the “wrong” side of the guard rail i.e on the carriage, it’s dangerous for pedestrians isn’t it? Or is it normal for your legislation to have pedestrians on the “inner side”? Some vertical and horizontal signage would make the situation less hazardous.
Best is to report the issues to the authority. You said the path was maintained. if the association doesn’t maintain it, it could/should mention the usage of the path to the authorities. Up to them to break the path due to this gap, or to make the situation acceptable for pedestrians.
Nah they were not of a different opinion regarding legal stuff, they simply perceived of the barrier insurmountable. Perhaps they well educated and therefore considering to stay on the “right” side of the (linear) barrier? Which would have taken them to sac_scale=demanding_mountain_hiking terrain, including quite a detour. So they opted for a ramble which would make them walk even more length on the no-pavement-road. (Hopefully on the left side of the carriageway – as traffic code suggests.)
Routers and other data consumers only consider barriers when they are tagged directly on a node of the highway. When they just share a node with a way that’s tagged as a barrier it’s ambiguous whether the barrier actually blocks the highway or not.
these routers could be fixed. If the data is clear it must not be repeated, redundancy does not add anything here.
IMHO, if the highway crosses the barrier without sharing a node it can be seen as ambiguous, a potential tagging error, but if the mapper created a shared node it should be clear that was made on purpose.
To me it seems somehow arbitrary which barriers can be mapped on a node according to the wiki:
it sounds so based on description. I would also add note=see https://community.openstreetmap.org/t/barrier-or-gap-on-path/139273/ to reduce risk of some armchair QAist damaging data and to reduce risk of people being confused.
I would also consider contacting local government so that stile=ladder ( Tag:barrier=stile - OpenStreetMap Wiki ) or gap in guard rail can be placed there (depends on importance of the path). Or something else similar in function.
it is not really stile, and in fact missing stile is part of the problem
It’s not a problem with the routers, it’s simply how the tagging scheme for physical and logical barriers works in OSM. (Besides, changing this behavior in all routers using OSM data is simply infeasible.) One is the element + tag for the physical barrier, one is the element + tag for the logical barrier on the highway.
