I’d say level=X;Y rather than level=X-Y, as stairs typically connect exactly two levels, rather than an entire range. That especially becomes relevant when the connected levels are not consecutive numbers (somewhat rare, but does happen).
1 Like
I was thinking about terraces, also on roofs, or courtyards. indoor means enclosed space but building related can be outside as well.
The level tag of a highway=steps way does not tell you which levels the steps connect, just which levels the steps are on. So if there are steps to connect levels 3 and 5, which do not connect to anything on level 4 and therefore cannot be used to access level 4, but of course still physically pass through level 4, they should be tagged level=3-5 (or level=3;4;5).
That makes a range the most natural choice for their level values, even though you can equivalently use a semicolon-separated list.
The same is true for rooms. For example, a room may be two levels high and therefore be tagged as level=3-4 or level=3;4 even though it is only accessible from level 3.
both should be possibile. -5–1 is error prone (e.g. because of text correction), but -2-45 is easier than putting the sequence manually
indoor=corridor + corridor=landing ? If the walled criteria is the problem, a new indoor= feature for unwalled walking space can be considered, similar to how there’s both =room and =area for the usable spaces.
I understand this. That’s why I suggest having another shared linear feature that can be used across different storeys for the directionality info explicitly, and avoid drawing winding highway=steps lines at the same time.
The difference between lines and polygons is polygons can be attached together, when indoor= area routing should already consider their level= etc. highway=steps lines can’t be attached, resulting in windings, to avoid short-circuiting from naive linear routing, especially at entrance= where there are =footway connecting different storeys.
I think more people than I have trouble understanding what your concern is.
Could you draw a quick diagram?
I am not deeply into routing, so don’t quite understand all the nuances 
Do corridors have walls?
Currently, this is not specified…
Areas, on the other hand, are documented to not have walls.
I would rather not make a messy situation worse by introducing another case where corridors may have walls or may not.
indoor=corridor + corridor=landing might do this if at some point a proposal lands that specifies this.
indoor=area + area=landing would be clear in the not having walls area
So to gain better insights how the room (pub intended) swings in this discussion. What would be the preferred way to tag indoor stair landings?
indoor=landingindoor=areaindoor=area+area=landingindoor=corridorindoor=corridor+corridor=landing
0
voters
what do you mean by “have walls”? Whether walls are implied? Whether they should be explicitly drawn? Whether the presence of walls prevents from using the tag?
Are those not all the same thing?
If walls are implied such as for indoor=room then they should be drawn.
If walls are forbidden such as for indoor=area, they should not be drawn.
Landings generally don’t have walls under the model, as they part of a stairwell (indoor=room) which does have walls.
Yes, indoor=area is clear from being defined as unwalled. But it means usable spaces as an unwalled counterpart to =room , not walkable spaces which indoor=corridor is for.
area= further collides with area= =yes vs =no for determining whether a feature is an area. That’s critical data-wise.
If indoor=corridor is undefined for whether it is walled, this question can be ignored. Rather it should be asked, whether indoor=corridor can be drawn inside a =room / =area (for the stairwell)? At the same time, another question is whether smaller =area is being drawn inside an =area , if =area is suggested to be used.
I think we are talking about different things, with “implied” I meant you would not need to draw the walls, they are there without drawing them.
The indoor=area page in the wiki is very mysterious, starting with the image (how on earth could a building section be representative for an area?)
The tag
indoor=areais used to map indoor areas (such as aHall) whose boundary is not represented by walls, as opposed to
indoor=roomwhich is meant to map an indoor space enclosed by walls.
I would guess most areas have at least one or two walls who delimit them, but are not fully enclosed so they are not a room (in osm). Saying “walls are forbidden” seems a stretch.
By the way, the only example given, a hall, is also linked to wikipedia which says in the first sentence:
architecture, a hall is a relatively large space enclosed by a roof and walls.
Generally, any wall that exists could be drawn explicitly, IMHO, the question could be whether it must be drawn for a complete mapping or whether implicit mapping (by drawing just the rooms and imagining walls between them) is possible.
“have walls” imho means that the real world object must have walls to get this tag, but it does not prevent us from drawing an explicit wall at the border of the indoor=room, or does it?
Would you say this prayer hall “has walls” or doesn’t it?
I think the two of you are using “draw” differently. An indoor=room has walls by default. Therefore, a map should render (“draw”) walls around it even if they have not been mapped (“drawn”) explicitly as an indoor=wall.
In contrast, an indoor=area has no walls except where they have been explicitly mapped as indoor=wall or where they are adjacent to a polygon, such as an indoor=room, which has implicit walls.
I agree that the indoor=area page is quite unhelpful. Some of it is pure bullshit, such as the image and “Hall” wiki link added by a banned user notorious for questionable wiki edits. That page needs to be rewritten from scratch.
A landing is actually a pretty good example of the type of thing we talked about when inventing that tag as part of Simple Indoor Tagging.
There is no expectation whatsoever that it is a “usable space”, by the way.
1 Like
I edited the page, and removed the Hall reference from indoor=area since the consensus seemed pretty clear that that was a typo.
If =area wasn’t defined as an unwalled counterpart to =room for usable space, on the contrary, it isn’t defined for walking as =corridor is either. Otherwise, =corridor would be unnecessary if room=corridor and eg indoor:area=corridor are used instead.
To come back to stairs themselves:
I agree that it is not ideal that the indoor tagging scheme already duplicates features that are outside. But IMO adding indoor=steps still is a good idea to have a consistent set of indoor elements.
The idea of using the outdoor highway=steps for indoor mapping as well would lead to very inconsistent data with highway=steps not being connected to other highways and only surrounded by indoor elements.
Honestly, it is a little weird that “corridor” is a top-level feature rather than just a type of room/area. I might do it differently if I was asked to design an indoor tagging standard from scratch today.