Hello,
I would like to discuss what the correct way to map indoor stairs is.
I can write a proper proposal, current wiki is a bit underspecified, but only if things are clear to prevent bikeshedding.
Currently, I think the following could be a workable schema, but I am not pleased with
I think the geometry is fine. (The example of steps starting immediately after a door seems a bit unusual? In a proposal, it might be nice to also have an scenario without doors to avoid the impression that these are somehow an inherent part of mapping indoor stairs.)
There are a few issues I have with the tagging:
indoor=stairs isn’t an established tag and is redundant, so I would simply omit it.indoor=area for the landing to make it unambiguously un-walled. It certainly has no walls at least towards the bottom side where the highway=steps ways connect to it.However, I think the big issue here – and one that is major enough to warrant separate consideration – is the use of fractional levels. Those aren’t part of SIT so far, and I’m not confident we have thought through all the conceptual issues with them, such as:
level=0.6 if the stairs aren’t split evenly before and after the landing?It’s not intended to draw highway=steps lines indoors. Lines creates a mess for stacked ones. It doesn’t work nicely. If you aren’t drawing =footway around for through traffic, it’s not necessary either.
Yes, it is. In fact, that’s the only established way to map individual flights of stairs indoors. (As opposed to entire staircases, which would be rooms or areas with stairs=yes.)
You’ll find highway=steps ways at most buildings with detailed indoor mapping.
Stacked elements are a fact of life in indoor mapping. Using some kind of filter or level selector is pretty much mandatory when editing or viewing indoor data.
This different treatment is entirely not mentioned in wiki Simple Indoor Tagging - OpenStreetMap Wiki
How is it the only method when there’s at least area:highway=steps ?
I’m not complaining about about overlapping areas, or the density of points. It’s the stacked or helical stairs requiring lines to be drawn in an arbitrarily offset spiral. I won’t want to draw many stacks of it, whether indoors or outdoors. It’s tricky to connect properly as well, let alone the problem with routing them through stacked landings / access points.
You have a point that this should be mentioned explicitly, and I hope we can improve the documentation after this discussion.
I don’t see a “different treatment” here, though. In general, most things in SIT-style indoor mapping are mapped exactly as if they were outdoors, except with a level tag added, and stairs are no different in this regard. The few indoor-specific tags in SIT are for things which don’t really exist outdoors, such as rooms.
Well, area:highway=steps, like all area:highway polygons, is supposed to be mapped in addition to a highway way running through its center. So it’s not an alternative to highway=steps, just an optional addition to it.
Well, it may be an option to not map them (and with indoor mapping, perhaps just map the staircase). But if you do map them, I don’t see any practical and correct alternative to drawing exactly as many stacks/windings of them as there are in the real world.
As for helical stairs, I don’t think anything involved in mapping them is more arbitrary than the ultimately arbitrary decision on where to, say, place nodes in a curved road section.
Technically, area:highway= doesn’t always have a highway= line inside yet, eg =traffic_island which is still linear for medians. If this is a problem, proposing indoor=steps would be simpler. In the same sense, highway=steps lines alone doesn’t solve what the flight’s area should be, which is empty in the question’s diagram.
How do you solve staircase doors on different floors above each other? Placing them next to each other is even messier than the sausage-making of stairs.
Ultimately there’s an inconsistency with using =steps + indoor=yes lines for flights, while indoor=corridor area, not highway= lines, are used for corridors. For compatibility, renderers need to realize they should be hidden to not have islands of stairs shown floating inside buildings. If the directionality info is required for the flight area, it would be easier to have another feature shared between different flights vertically.
You just place them on top of each other.
In indoor taggin it is implied that you are not using ID, but something with a level=X filter in both the editor and rendering.
You can use repeats_on to “simplify” mapping, but that only really simplifes your live for >2 floors in my opinion 
Also makes editing much harder and confusing, so better avoided.
Renderers are much ahead of you. People do wild things with stairs currently, which are generally handled well.
There exists the tagging on our campus “Garching Forschungszentrum” (which is to be expected, SIT is invented here, so much experimentation).
Warning: don’t open it in ID, that lags too much. Only JOSM is usable.
| tagging | ingnored by renderers |
|---|---|
highway=corridor + stairs=yes + level=... |
 |
highway=corridor + indoor=stairs + level=... |
|
indoor=stairs + level=.. |
|
indoor=steps + level=.. |
|
highway=steps + level=.. |
 overpass turbo |
Worldwide, there is likely much more variety in tagging.
This is one motivation why I think doing an RFC and then documenting this properly is worth the time
Yes, I know all these. I’m exactly asking about using highway=steps + indoor=yes alone, resulting in it being rendered on its own. The door= points are not simply coincident or very close, and unconnected here, but need to be attached to the =room / =corridor edge. repeat_on= is misleading for routing when they are entrance= connected to =footway outside, which causes it to be ignored in a short-circuited manner.
I agree with @Kovoschiz that adding highway=steps inside a building without any connection to other highways is weird. IMO indoor=steps is a good choice for such stairs that fits well into Simple Indoor Tagging.
Here is a proposal that we could just revive: Proposal:Detailed indoor stairs mapping - OpenStreetMap Wiki
We just need to be clear about the tagging.
As a data producer/consumer, I don’t have a strong opinion how this should be done, sadly.
The important part is just that it is less messy than whatever the current state of the art is
I’m reluctant to create indoor clones of outdoor tags for the same kind of object. Where would you stop? For example, using amenity=parking_space and highway=service + service=parking_aisle to map the details of a parking deck in a building would also cause those features to be visible on mainstream maps which don’t intentionally hide indoor data. Should we therefore also invent indoor=parking_space and indoor=parking_aisle? We’d end up duplicating a large subset of the OSM data model.
That’s not what I’m asking. Please don’t frame it as a slippery slope. In fact I recently commented against a wiki user promoting different indoor= features as well.
The question is there is indoor=corridor as areas foremost, and perhaps areas only in almost all cases. Then why must stair flights entail using highway=steps lines, and area:highway= instead of indoor= as the area feature? (The need is not from routing with lines, as the indoor=corridor area already areas) As a result, this further creates gaps between indoor=corridor areas, which is already used for the landings. That makes me raise the possibility of whether a indoor=steps can be used to avoid drawing highway=steps lines, and to be consistent with indoor=corridor falling inside the indoor= features.
The other idea I suggested is if the directionality info is needed for showing up & down, a shared linear feature across all floors can be used. This avoids drawing the spiral of highway=steps lines for each flight. An added benefit is it can be aligned precisey along the center.
It’s a good topic whether =service road lines should be drawn internally too. That’s for another post.
Is the indoor=yes even necessary for highway=steps?
This seems duplicated with the level=xx tag, or?
I agree, for indoor staircases, mapping them as an area (representing a volume) seems appropriate, with the exception of stair flights running openly through the space like the main ones in shopping centers or lobbies etc. It would be tedious to draw overlapping stairs (and it is in the nature of stairs that they overlap), for no real gain. For routing, we could connect routable ways to the staircase area on the interested floors (level tags on connecting ways).
Basically, they would be mapped like an elevator (i.e. could even be just a node in the simple version).
For more detailed mapping, counting the steps between floors (and being able to tag it) would be interesting I think.
you can have level tags also outdoor.
Simple Indoor Tagging doesn’t require it.
Sure, and that’s already possible.
But as you said yourself, not all stairs are inside staircases. And sometimes, we’re also interested in the extra detail of mapping the geometry of the stairs within staircases. So I’d like to primarily discuss how to map the stairs themselves. As always, whether to map them is up to the mapper who either chooses to put in the extra work or chooses not to.
Currently, we rely on the way for direction-dependent tags such as incline=up, handrail:left=yes or conveying=forward.
In theory, it would probably be possible to define a purely area-based convention for mapping steps. (Say, the direction is always up, and which side is up is derived from the level tags on features sharing nodes with the polygons.) But using left/right/forward/backward tags on areas is not a widespread concept so far. From some data consumers’ perspectives, it may also at least require some thought on how to deduce the centerline for arbitrarily shaped stairway polygons. And of course, mapping stairs as polygons wouldn’t by itself avoid spiralling/overlapping geometries. Without any extra changes, you would simply end up with overlapping polygons instead of overlapping ways.
In any case, switching to mapping steps as areas definitely amounts to proposing a novel and unprecedented approach, whereas the original post by @CommanderStorm pretty much just documents the status quo (with the caveats I pointed out before).
Key:level - OpenStreetMap Wiki does not seem to support this.
So really stupid question, would the following tagging schema be ideomatic for the stair elements?
)highway=stairslevel=X-Ystep_count=10incline=up (default: up)width=ZBasically, the outdoor schema, but with the level=X-Y tag.
=> fully backwards compatible, just documenting things.
For the landings, either of the below work.
indoor=landing (=> allowing different rendering)indoor=areaindoor=coridorSince those are usually quite lumpy, I would just map them as polygons, simplifies things.
Current tagging specifies this as a way, but that is kind of akward to tag indoors.
According to my intuition, both corridors and areas don’t have walls, so should be semantically similar.
The wiki is unspecified on this, but this is how I am handling it currently. Maybe I am missing something.
Yes, I think that describes the status quo, except it’s called highway=steps (probably a typo), and there’s no default value for incline.