OSM Indoor Meeting 2024-06-05
Jump to navigation
Jump to search
- Previous meetup: https://wiki.openstreetmap.org/wiki/OSM_Indoor_Meeting_2024-03-06
- Next meetup: 2024-09-04 18:00 CEST in https://osmvideo.cloud68.co/user/tob-2uf-drl-eal (recurring every first Wednesday of the third month of each quarter at 18:00 CE[S]T)
- Volker will be traveling that day, Tobias volunteered to chair the meeting instead.
What happened since last time?
- https://wiki.openstreetmap.org/wiki/Indoor_OSM_user_meeting_at_FOSSGIS_Konferenz_2024
- https://lists.openstreetmap.org/pipermail/indoor/2024-May/000019.html
Upcoming events
- sign up for https://wiki.openstreetmap.org/wiki/Karlsruhe_Hack_Weekend_October_2024
- sign up for https://wiki.openstreetmap.org/wiki/Berlin_Hack_Weekend_November_2024
Topics
Multi-floor rooms with different extends
example: lecture halls (e.g. https://www.openstreetmap.org/way/107673793 + https://www.openstreetmap.org/way/107673607)
- model as two rooms (status quo), let the consumer code merge this based on identical room numbers
- relation with most tags, and member geometry per level, what member role?
- no relation but dedicated tagging to assist with merging room parts (room:part=?)
- ...?
Are there precedents for any of that yet?
Discussion:
- related: a shop spanning multiple floors in e.g. a mall or train station
- similar in that it needs the relation, but physically two rooms with separate floors
- is that similar enough though to model this the same way? semantics vs physical shape
- variants of the relation model:
- keep tags duplicated on the members, which is easier to consume but duplicates tagging
- members only contain the level tags, other tags are only on the relation
- try to avoid risks of misunderstanding this as a multi-polygon (for humans and tooling)
- preferred solution: relation
- empty role for members
- type key:
- type=room is too specific (would type=area for indoor=area be needed as well?)
- type=multilevel/multistory is better and more generic, and also covers the multi-level shop case. Ideally we'd find a name that doesn't start with "multi" though to avoid ambiguities with "multipolygon".
- ways need at least the level tag, no level tag on the relation
- moving tags only to the relation would probably be ok for indoor mapping, as that is fairly niche/specialized, but for multi-floor shops that might not be the case, tooling/rendering there might also not be prepared for e.g. shop relations
- counter-example for tagging on the relation: building parts, there the tagging is put on the "main" polygon, but that isn't directly applicable here lacking a "main" element
- alternative approach for the shops: node with the tags, relation for the geometry
Detailed stair part tagging
- landing areas, e.g. https://www.openstreetmap.org/way/107673567
- indoor=area probably sufficient both for rendering and routing, no standardized specialized tagging exists yet
- geometry for individual (large) steps, e.g. https://www.openstreetmap.org/way/107673622
- center line tagged as highway=steps (exists) and outline polygon tagged as area:highway=steps
- remove geometry for individual steps
- add same level tag on the outline as on the center line
Rooftop terraces
How to tag rooftop terraces (e.g. https://www.openstreetmap.org/way/107673613)? This is neither indoor nor a room really, but very much part of a building.
- indoor=area semantically similar, but counter-intuitive
- balconies are similar, if not worse for exceeding the building outline. There is building:part=balcony though.
- location=roof + room=terrace should work