Please comment on the proposal for highway=ladder
10 Likes
Are you sure that this one
is a ladder and not stairs? Here’s a closeup:
Other than that: straightforward, but some frightening examples 
1 Like
thank you for noticing, I have replaced it
I like this proposal. How do you propose to tag the direction in which a ladder leads up?
if it is a way you can use the incline tag. For nodes the information is expected to come from the context (e.g. level, layer or ele tags in the surroundings, an external model, etc.)
You sure - mangling with the highway key? Just joking. Still, did you consider how many gaps in OSM-Carto rendering of pathways of national importance this will create? Joking once more 
are there any more comments on this? Otherwise I would start voting in a couple of days…
- The proposal wants to deprecate the approved ladder=yes, which has 3500 uses, 3000 of which are on nodes. Is there a strategy how to handle those deprecated mappings - Are they supposed to let linger?
- There is one picture with a ladder that is not vertical, so might get mapped a way - a bit like the ratio in current ladder mappings above, one in seven. This one though, I do not see something, that could be stuffed under the highway key. Such ladders abound on rooftops to help the chimney sweep e.g. No highway, in my opinion.
I didn’t think it was deprecating the entire key, just the combination of highway=path ladder=yes. This has only been used 291 times.
Presumably the Wiki page will have to be rewritten to match how ladder=yes is actually used: mostly on nodes, especially amenity=hunting_stand (2351 uses).
@Dieterdreist: can you confirm? is your proposal also deprecating standalone usage of ladder=yes as in this example (swimming pool) or this one (on a pier)?
2 Likes
You propose to use layer on the adjacent ways to capture the incline of a node-mapped ladder. I feel like level may be more appropriate (think of a ladder that gives access to different levels of a building). Either way, it feels like a bit of a crutch, but I cannot think of a better solution, and, in general, I support the proposal.
I think you can do that right now, regardless of how a vote turns out!
For the remainder of nodes, I’d still prefer barrier=ladder, which is quit in line with barrier=stile, and much less a crutch than highway=ladder, in my opinion.
Yes, “standalone” ladder-properties on nodes are also “deprecated”, these should sooner or later be retagged to highway=ladder on a node. One could argue that a property without a feature tag is invalid in general, regardless of this proposal.
1 Like
layer and level cannot be use interchangeably, in particular in the natural environment, “level” makes less sense, as it is typically referring to building levels. “layer” is a generic tag to describe topology (vertical stacking) and is suitable for both, the natural and the built environment.
Would it not make sense to be explicit in the proposal text about what is being deprecated (e.g. the combination of highway=path ladder=yes and standalone ladder=yes) and what is not (ladder=yes as a property e.g. on amenity=hunting_stand)?
1 Like
In my view, the barrier=* prefix doesn’t makes sense for ladders generally as their primary usage is to facilitate movement rather than block it.
The barrier=* prefix makes more sense for barrier=stile because the entire point of the stile is to filter traffic/movement by blocking certain sorts of movement (e.g. livestock, vehicles, etc) while allowing others (e.g. foot traffic) to pass.
5 Likes
From point of view of accessibility, ladders are indeed barriers.
From the Wiki:
The layer=* tag is one of several methods used to describe vertical relationships between crossing or overlapping features.
The adjoining paths of a ladder only rarely overlap.
Layer is not suitable to define vertical relationships of adjoining, nearby or distant elements or areas. Applying it to long ways however will unpredictably affect (usually break) intersections far outside the visible editing area.
Ways in buildings (or similar structures like multi-level parking lots, shopping centers, airports, railway stations, some multi-level bridges and roads…) should be mostly described with level=* instead of layer. level=* is used for the physical vertical arrangement of levels (floors, walkways) inside structures.
Highways (and other ways) can be also tagged with level=* when they are essentially bound to a floor of a building complex (such as multilevel parking buildings, railway stations or airports).
So yes, level is referring to buildings and not general structures. But unlike layer, where one contradicts the current definition in the general case (i.e., ladder is at an angle and, thus, no overlapping or crossing occurs), the definition of level only needs to be extended from buildings to general structures. Apart from that, the definition of level fits very well.
Two sides of the same coin:
- If there was no ladder, it would most likely be less accessible.The barrier is the terrain/building/… .
- If the path could continue without the ladder, it would be more accessible. So the ladder marks the location of a barrier.
I like this definition. But there will still often be two ways to view it. Like with a cattle guard: Is its primary goal to allow cars to pass through fences (highway) or is its primary goal to hinder cattle from using the road to pass through the fence (barrier).
1 Like
Very interesting indeed! OSM usually is not consumed by cows (barrier in this case) but rather humans (highway in this case.)
PS: One alternative to a ladder is the elevator, it is in the highway key. But there is also Tag:barrier=entrance - OpenStreetMap Wiki