Indoor Tagging Meeting 2023-02-14

From OpenStreetMap Wiki
Jump to navigation Jump to search

Meeting Notes

Online follow-up to Arbeitstreffen_Indoor_OSM_2022.

What is a level?

  • level:ref is the on the ground label
  • level is a numerical ordering of level:ref
  • same elevation/plane is not required


  • What is a level? How many steps? Sub-levels/fractional levels?
  • What about level outside of buildings?
    • in use, but undefined behavior, problematic for buildings along hillsides for examples
    • the larger the area gets the harder it gets to keep that consistent

Relative elevation difference between adjacent levels?

  • tag as elevation difference to a base elevation of a level in a level domain?
  • new tag, referring to a base level elevation
  • some connecting elements like stairs can already carry that information
  • use a relation as a "mapping table" between levels of different level domains?
  • level domain mapping on nodes/ways connecting levels in different level domains?
  • implicitly via existing level ranges?
  • explicitly with a dedicated tag?

Railway line level tagging?

  • should this be level tags on the railway line itself or on stop position nodes (which then can be propagated by renderers as needed)?

Level Domains

  • define that concept
  • where possible imply that from e.g. building outlines or station outlines (?)
  • a way to define base level elevations


  • level vs level:ref, how to reference which level domain a level[:ref] refers to
  • is a level domain containable in a defined area?
  • for railway stations, the station outline /stop area (group) element can enumerate the levels

Additional tags

  • relative elevation differences between areas/levels in the same level domain
  • mapping levels between level domains on the connecting nodes/ways

How does this all relate to the 3D tagging scheme?

Connecting to the outside world: similar problem as the mapping between level domains, entrance nodes can carry that information

Where to put the notes and collaborate on expanding the concept/proposal?

Objects on the roof

  • level tag for every element?
  • location=roof?
  • -> both, level is enough for indoor-capable renderers, location useful for those that aren't
  • -> roofs can stack, level tag is less ambigious
  • Gare Montparnasse example: this is less of a tagging problem than a limitation of the outdoor rendering
  • needs discussion with people working on outdoor rendering

FOSSGIS conference

  • German-only event, Indoor BoF Thursday 14:00
  • additionally, there's the unconference day on Saturday, hybrid setup, English session possible - https://wiki.openstreetmap.org/wiki/FOSSGIS_2023/OSM-Samstag
  • advertise this topic and round there, get more people into this topic
  • if there's outcome, translate and communicate to this group here as well

Elevator vs stairs

  • highway=* used for ways in both cases
  • indoor=room etc used for the surounding
  • door nodes instead of repeating can be relevant for accessibility data if that differs per level
  • see also https://wiki.openstreetmap.org/wiki/Arbeitstreffen_Indoor_OSM_2022#Level_changing
  • elevator node connected by way to the door, or map the interior area/elevator shaft as elevator? -> the latter eliminates the connecting footway which is only really needed for routing

repeat_on definition inconsistencies

https://wiki.openstreetmap.org/wiki/Simple_Indoor_Tagging#Multi-level_features_and_repeated_features

  • does repeat_on require a level tag? text and diagram disagree
  • there's no semantic difference by both of those overlapping, it doesn't matter which one is in level and which ones are in repeat_on
  • ie. the desired result is the union of both
  • should be clarified in the wiki

Different extends per level, complex room geometry across levels

  • e.g. stair cases, multi-story shops in malls, audioriums, etc
  • for stair cases, mapping stair ways can be an alternative
  • we lack a way to group multiple per-level areas together -> needs a relation
  • approach 1: relation gets all the usage tags (e.g. shop), with both areas as member
  • approach 2: one area gets all the usage tag, with the relation connecting to the other untagged area
  • approach 3: all usage tags are duplicated on all areas, shallow relation connecting them
  • approach 1 is conceptually clean, but incompatible with existing renderes, approach 2 works with existing outdoor renderes, approach 3 work with existing indoor renderers but duplicates information
  • we essentially need a generic multi-level relation, similar to what multipolygon does in 2D plane, e.g. type=multilevel
  • tags on the relation are difficult to edit, many tools not prepared for relations in this context
  • start with approach 2, if relation support increases at some point transition to approach 1 possible
  • next step: write a proposal for this

Next steps

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Indoor_Tagging_Meeting_2023-02-14&oldid=2478816"