Indoor OSM Workshop 2026

Location: Wilhelminenhof Campus of the University of Applied Sciences, building G, room G 008.

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!

Participants are required to register in advance through OSMCal: https://osmcal.org/event/4892/.

Time and location

The event will take place in Berlin on the Wilhelminenhof Campus of the University of Applied Sciences, building G, room G 008.

Time: starting at 09:00 each day.

Agenda

Overall goals

• Connecting the indoor community and sharing information
• Resolving open tagging issues (especially Simple Indoor Tagging) and documenting the results
• Improving compatibility between different applications and mapping or import projects

Ideas for potential topics

As a participant, feel free to add topics to this list:

• Wall areas
• indoor=column
• Level value syntax (ordering of values in level ranges and level lists)
• Multi-level features with different extent per level / multilevel_feature relation
• indoor=door
• Editorial changes in SIT documentation (mention of "level relation", page structure)
• indoor=area elements which function as corridors, room=corridor
• Potential stairs=yes renaming
• Directionality of doors and windows (left/right/forward/backward tags)
• Level Domains
• Fractional levels, relative elevation within a level
• ...

Notes

Evaluation Criteria

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, ie. 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, ie. a line. Typically that's the center-line of the wall.
• Thick walls: walls are represented as a two-dimensional feature, ie. as an area.
• 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, ie. indoor=wall.
• 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.

Proposal

Proposal:Allow area=yes for indoor=wall proposes to allow mapping of explicit wall areas. Proposal_talk:Allow_area=yes_for_indoor=wall suggests an alternative approach to use implicit thick walls instead.

Discussion

• 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 be 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, ie. 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.
  • Allow for different surface parameters on each side of the wall (material, color, etc).
• Holes in the floor (e.g. openings to the level below) are also implicitly mapped, does that introduce an ambiguity with implicit thick walls?
• 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.

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), ie. a OSM node with door=*. This is the existing approach.
• Way doors: Doors are represented as a one-dimensional feature (line), ie. 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 use as a 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 worth.
  • 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).

Decisions

• Consensus was to reject way doors.
• (Re)movable walls should be mapped as walls with an extra tag (to be proposed, e.g. indoor=wall + movable=yes/folding/sliding/...).
• Directional door attributes should be tagged via a cardinal reference direction.

Stairs

to be continued