is there any indoor mapping application that needs level=* on nodes at the beginning and end of ramps, stairs and elevators if the nodes themselves have no other tags and the ramp/stairs/elevator have level=* of both levels set?
In German train stations, level=* is used if the station has an underpass or bridge to access the platforms. However, in addition to level=* on platforms, footways, stairs, vending machines etc., many nodes at the beginning and end of stairs, ramps and elevators have a level=* tag but no other tags (example).
My company, Geofabrik, is currently contracted to improve mapping of train stations in Baden-WĂĽrttemberg. Before we start adding level=* nodes and waste time on something nobody needs, I would like to reach out.
If nobody can point me to a use case where these nodes are required, I will instruct the mappers of my team to not add these useless tags.
The nodes are redundant in my opinion. If a highway=steps way has both level=0;1 and incline=* (as in your example), it’s implicit that the lower side has the lower level number (0) and the upper side the higher level number (1).
I would say that it’s sufficient to have level=* at ways. In MOTIS’ routing (see GitHub - motis-project/osr: osr is a memory efficient multi-mode OpenStreetMap router), a node can be used in different ways with different level tags (because it happens in practice and is no big deal to support) and the actual level is only derived from the way. So I would say that adding level to nodes is a waste of time.
We had more problems in cases where layer was used instead of level or with stations that are at a hill and mappers didn’t agree which entrance is on level=0 (it’s impossible that all entrances are at level=0 even if they are all “ground level”).
OSM2World does evaluate level tags on the start and end nodes of indoor stairs (and ramps) to distinguish between the upper and lower end.
However, it also supports some alternative approaches to obtain that information:
Look at incline tags of stairs or ramps. (This works if the node is the first or last node of such a way.)
Look at the level tags of other ways or areas connected to the node. (This works if those features have a single integer value in their level tag, and it’s the same for all connected features.)
In situations where these alternative approaches yield an unambiguous result (which is the case for your example), these otherwise untagged nodes do not need a level tag as far as OSM2World is concerned.
level tags on the start and end nodes of indoor stairs (and ramps) to distinguish between the upper and lower end
For the routing use case, there’s no reason to distinguish between upper and lower end. It’s clear that if you are currently on level=4 and use stairs that connect 3 and 4, you’ll end up on level=3.
For non-routing use cases, I would expect the second approach to work quite well. A node that’s at one end of stairs and connected to several other ways with different single integer value level tags where both values of the stairs appear is probably quite rare.
For our (area-based) indoor router we evaluate those tags but also fall back to the mechanisms Tobias described when those tags aren’t present (which is I think the majority of cases).
To know which side is on which level is crucial, so level tagging on the ways to/from the stairs and/or the incline tag becomes more important then. In the (German) public transport context connecting ways usually exist, so we shouldn’t have a problem here.
(In buildings more closely following SIT that might not be the case though and stairs can end inside an area without being connected to anything else. Happens e.g. in the Paris Metro.)
The application for 2.5D indoor maps which I created with fellow students and we presented at the FOSSGIS 2025 (Poster-presentation on YouTube (german only)) uses OSM data to generate a map like those found at infopoints in shopping malls. For that we also try to show stair shapes in 3D, which is the relevant part for this post. Our application currently targets buildings, which is why we aligned it to SIT, but a comprehensive standard is not available (yet).
In my opinion the level=* tags would not be needed in your example, but I can think of examples where it could be used. If an application (like ours) wants to show the stair shape with all the horizontal breaks it has, like the below image, the nodes on that small platform should at least exist.
At the moment there are discussions how that kind of staircase should be represented in OSM, with one path or multiple or something else entirely, and that would also change the need for nodes that just have a level=0.5 tag like in this example. Also our application is quite young, so it should also follow the existing standards to a degree and not boldy decide that our way is the only correct one.
So in summary: Yes, there are application that (currently) use nodes that only have a level=*, but that is currently in discussion and there might be different ways to achieve the result we are looking for. It would just be difficult if not impossible to later add the nodes, if a way to tag those stairs is agreed upon in future and relies on this infomation.
PS: SIT says that stairs should connect to corridors with a door node, where door=no can be used to show that there is no physical door at the connection. One can now argue that train stations are not buildings and cannot be expected to follow SIT, as that would bring more rules to follow and tags to add, but if there were doors, they should also have a level, I would say.
