The Indoor OSM Workshop on 11th and 12th July 2026 is a meeting in Berlin to foster collaboration between people and groups interested in indoor data in OpenStreetMap and to improve standardization of indoor tagging. It's inspired by, continues the work at, the similar 2022 event in Frankfurt. All mappers and developers involved with indoor-related topics in OSM in are welcome!
The following checklist was proposed and used to evaluate suggested changes:
OSM compatibility
Does it follow established practices?
Is the proposed approach explainable and easily mappable, and does it result in maintainable data?
Impact on existing data and/or established semantics
Alignment with outdoor mapping
Use the same concepts/approaches/tags wherever possible, i.e. no duplicate indoor tagging model
Indoor-specific tagging only where there's a good reason for it
Impact on 2D rendering
Impact on 3D rendering
Impact on tactile rendering
e.g. OSM2World or TU Dresden's work on perspective 2.5D visualization
Impact on routing
both graph-based and area-based approaches
Can all accessibility-relevant use-case be modelled/mapped with this?
Impact on importing BIM data
Walls
Terminology
Thin walls: walls are represented as an one-dimensional feature, i.e. a line . Typically that's the center-line of the wall.
Implicit thin walls: not mapped explicitly but derived from features that have implied walls, e.g. indoor=room. Two adjacent rooms share an edge, which is the center line of the (implied) wall between those rooms.
Explicit thin walls: walls mapped as individual feature, i.e. indoor=wall.
Thick walls: walls are represented as a two-dimensional feature, i.e. as an area .
Implicit thick walls: thick wall areas are not explicitly mapped, but derived from explicit or implicit wall surfaces. Two adjacent indoor=rooms would not share an edge in that case, the gap between them is then the (implied) thick wall.
Explicit thick walls: wall areas are explicitly mapped in this case, as indoor=wall + area=yes. Two adjacent indoor=rooms would each share an edge with the wall area in this case.
There's general agreement for the need of being able to map thick walls.
Thin walls are still the preferred and encouraged approach wherever they are viable, thick walls are for the complex cases that can't reasonably be mapped otherwise.
Thick walls are a major complication for tactile rendering, as that needs to do significant simplification/abstraction. This is hardly avoidable though, and will get harder with any increase in level of detail. A similar approach as Richard implemented for generating routing graphs out of areas could be used to generate and simplify wall center lines for tactile rendering.
Thick walls must include door cutouts, i.e. in the place of a door the thick wall must have an opening so that adjacent rooms/areas share an edge. We do not want “tunneling doors” that either float in the middle of the wall, or are mapped as a way perpendicular to the wall.
Arguments in favor of explicit thick walls:
Very intuitive and easy to explain.
Arguments in favor of implicit thick walls:
Avoids redundancy and potential inconsistencies.
Allow for different surface parameters on each side of the wall (material, color, etc).
For both proposals: The meaning of the indoor:room outline changes from wall centerline to surface. Is it necessary to reflect this in tagging?
Holes in the floor (e.g. openings to the level below) are also implicitly mapped, does that introduce an ambiguity with implicit thick walls?
The more general ambiguity is independent of wall mapping: is unmapped territory to be treated as solid volume or empty air?
Implicit thick walls towards the building outside would introduce implied walls on the building outline.
What we map represents a cut at the floor height, unlike in common building plans which show a cut at around 1m height. This has implications e.g. when mapping based on a floor plan which might show wall cutouts around windows. It is not a problem for BIM imports though, those can freely decide where to place the cut.
This implies that wall segments above doors are not mapped explicitly, but are left to 3D renderers to fill themselves.
Can both proposals coexist or is it discouraged to leave out explicit walls and fall back to implicit thick walls? They could be added later.
Decision
A majority of participants were leaning towards the explicit thick wall approach, Frank's proposal for that has been sent to voting.
Doors
Terminology
Node doors
Doors are represented as a zero-dimensional features (point), i.e. a OSM node with door=*. This is the existing approach.
Way doors
Doors are represented as a one-dimensional feature (line), i.e. a OSM way . This is not currently in use.
Proposal
Allow way doors alongside node doors. Reasons:
Allow for mapping more complex shapes, e.g. for multi-panel foldable (glass) doors at shop fronts, or similar structures in conference or sport venues.
Easier to map with correct width when working with building plans.
Unlike nodes, ways have an inherent direction, enabling directional door attributes.
Discussion
Foldable walls are not doors, as they themselves can contain doors. So those should be mapped as (movable) walls instead.
Directional door attributes are important e.g. for accessibility.
The suggested approach of mapping directional attributes for node doors is having a direction=* tag defining a (cardinal) direction which is then used as reference for relative (e.g. forward/backward, left/right) directions for the door attributes.
This is hard to explain/understand and would need editor/tool support to be usable.
Way doors have a built-in direction, but it points in the “wrong” direction, along the line of a (closed) door, rather than perpendicular to it in walking direction.
This is equally hard to explain/use than the reference direction, if not worse.
It's also different to how node doors handle this, adding more complexity.
Other approaches to define directional door attributes like an “inner-ness hierarchy” between rooms are even worse.
Two-node way doors don't connect well with (outdoor) paths, we'd need three-node way doors there so paths can still connect to the door center rather than to one of its edges.
It is assumed that way doors would not be accepted “outdoors”, and thus would not be usable on the building outline but limited to just between indoor rooms.
door=* should be the preferred and universal way of tagging doors, indoor=door should be phased out (but still has ~5000 uses).
Should be done whenever there is a physical room enclosing the stairs.
For open staircases (i.e. without an enclosing room), indoor=area + room=stairs is suggested, in particular for stairs connecting more than two levels.
Can also be tagged as individual indoor=area connected by highway=steps for a higher level of detail. Explicit tagging as a stair landing is considered optional, an area only reachable by two (or more) highway=steps is implied to be a landing. Explicit tagging could be proposed later if needed e.g. with landing=* or stair_landing=*.
Tagging stair outlines:
For rectangular shaped flights of stairs highway=steps + width=* can sufficiently describe the outline.
For more complex shapes a highway=steps centerline with an area:highway=steps outline is recommended, same as in use outdoor.
Are inverse ranges in level=* allowed (e.g. 3-5 vs 5-3)?
Highly discouraged and warned about by validators, but recommended to be handled as equivalent by tolerant parsers.
Are level sets/ranges unions, i.e. are 1;2 and 1;2;1 equivalent?
Yes, there is no order semantics on level=*. Same as above, highly discouraged and warned about, but recommended to be handled by tolerant parsers.
Fractional levels
In use, but not officially defined.
Introducing them requires careful review of all places using levels and defining the semantics in the presence of fractional levels.
Not enough time in this meeting to actually do that, besides the following:
Level enumeration as done e.g. by repeats_on=* only lists integer levels. This cannot include fractional levels without knowing all actually present levels in the current level domain, which is non-trivial to determine.
Level ranges include all fractional levels, i.e. a room with level=1-2 also spans all fractional levels in between.
Tactile Paving
Discussion
tactile_paving=* is currently only defined as a secondary tag on ways, not as a primary tag on ways.
We also need the latter though, man_made=tactile_paving is suggested as a primary tag for this, for mapping the actual path of the tactile paving independent of the way/area containing it.
Needs an official proposal.
Columns
Discussion
indoor=column exists for nodes as well as in combination with area=yes for ways, for more complex/explicit shapes.
The distinction between area columns and area walls is somewhat arbitrary, similar to the distinction between indoor=area and indoor=column.
The main value of indoor=column is on nodes, to efficiently tag column cases.
Clarify indoor=corridor has no implied walls. This is based on a previous discussion/decision and practically necessary by how this is used in most places, with the prominent exception of the “strict SIT” tagged TU Dresden campus.
Remove “… or are optionally member of a level relation.”, a historic leftover referencing the never materialized concept of level relations.
Link collection
Some of the things used as example or that came up in discussions, or generally interesting.
https://huberlin.vscout.biz/ Is a nice visualization with both 2D and 3D variants (not using OSM data). Shows the levels of the Grimm Zentrum. There are stairs which connect the levels by going straight on, e.g. you don't change direction going from level 0 through level 1 to level 2. Is the area between the two stairs on level=1 a landing? To one side is a corridor “attached”, on the other is a door giving access to a room.
How would the “empty” space in the center be mapped when using implicit thick walls? (linked from Treppenhaus on Wikipedia)
Surreal number on Wikipedia. As example for an alternative to fractional levels (using decimal numbers); referencing only the above and below level to give a relative description of an in-between levels location. (Joke)
How the description of the Hamburg Trainstation level problem appears to be, level=1 might have a very small and gradual drop in elevation across the entire station, thus on the east end it is at a different level than in the west.
. Typically that's the center-line of the wall.
.
with 
