Arbeitstreffen Indoor OSM 2022

From OpenStreetMap Wiki
Jump to navigation Jump to search

Vom 14. bis 16. Oktober 2022 findet in Frankfurt am Main ein Arbeitstreffen zum Thema Indoor in OpenStreetMap statt. Die Veranstaltung wird vom FOSSGIS e.V. unterstützt.

Zielgruppe sind Mapper:innen und Entwickler:innen, die bei OSM im Bereich Indoor aktiv sind. Sowohl freiwillige OSM-Aktive als auch Mitarbeiter:innen von Unis und Unternehmen sind willkommen!

Zeit und Ort

Tag Uhrzeit Ort
Freitag, 14.10. ab 19:00 Come-Together Vereinslokal des Kanuvereins, Schaumainkai 90, 60596 Frankfurt am Main
Samstag, 15.10. 9:00–17:00 1. Veranstaltungstag BKG-Hauptgebäude, Sitzungssaal B13 und B14 im B-Bau
Sonntag, 16.10. 9:00–13:00 2. Veranstaltungstag

Anreise und Unterkunft

Anschrift:
Bundesamt für Kartographie und Geodäsie
Sitzungssaal B13 und B14 im B-Bau
Richard-Strauss-Allee 11
60598 Frankfurt am Main

Anfahrtsbeschreibung unter https://www.bkg.bund.de/SharedDocs/Downloads/BKG/DE/Downloads-Anfahrt/BKG-Anfahrtsplan-Richard-Strauss-Allee-DE.pdf?__blob=publicationFile&v=7

Der Eingang befindet sich zwischen den Gebäuden B1 und B2 (7-stöckig), gegenüber vom Parkplatz.

Achtung: Beim Betreten des Hauses bitte an der Pforte melden, dort liegt eine Namensliste, die Besucher, die auf der Liste stehen, bekommen einen Besucherausweis.

Versorgung: Für die Versorgung mit Snacks, Getränken und Mittagessen wird gesorgt.

Angebot Organisation Übernachtung:
Wer Interesse hat, dass eine Übernachtung (voraussichtlich Panorama Hostel) organisiert wird, meldet sich bitte bis 04.10.2022 per E-Mail an katja.haferkorn@fossgis.de + ein Hinweis in der Wikitabelle.

Anmeldetabelle zur Teilnahme

Bitte trage Dich bei Interesse an einer Teilnahme in diese Tabelle ein.

# Wer Projekt/Interessen Parkplatz Kommentar (z.B. An-/Abreise) Orga Übernachtung gewünscht? Freitag dabei? Barrierefreiheit (x)
1 Tobias Knerr OSM2World (3D-Rendering von Indoorkarten) nein
2 Katja Haferkorn Unterstützung Orga nein Ankunft 14.10.
Angebot: siehe Anreise und Unterkunft
ja
3 David Lange Erweiterung Simple Indoor Tagging ja Ankunft 14.10. ja ja
4 Simon Poole nein Teilnahme muss noch abgeklärt werden
5 Johannes Heep BKG Projekt Denied Areas ja 069-6333-353
6 Joachim Bobrich Indoor-Positionsbestimmung nein nein nein
7 Jan Schmalfuß-Schwarz AccessibleMaps nein Ankunft 14.10.
Abreise bereits am 15.10. nach 17 Uhr
nein ja
8 Claudia Loitsch AccessibleMaps nein Ankunft 14.10.
Abreise bereits am 15.10. nach 17 Uhr
nein ja
9 Matthias Meißer (hmt) Raumplan für Hochschulen (siehe Tagung 2022 StudIP4future S10 pp. - (nur falls remote möglich oder Videonachricht?)
10 Volker Krause KDE Itinerary (Bahnhofs- und Flughafenkarten) nein 15/16.10. nein nein
11 François de Metz indoor= no no yes
12 Jakob Trenkler CampusGIS2 no 15.10 no no

Inhalte und Tagesordnung

Ziele des Treffens

  • Kennenlernen und Informationsaustausch
  • Diskussionen zu Themen, die im OSM-Indoor-Bereich aktuell angegangen werden müssen
  • Weiterentwicklung des Taggings (v.a. Simple Indoor Tagging): Fehlende Features, Kompatibilität zwischen Projekten

Tagesordnung

Ablauf Samstag, 15.10.2022

  • 9 - 11 Uhr: Einstieg, gegenseitige Vorstellung Teilnehmende, Fragen und Diskussionsbedarf zum Thema
  • 11 - 11.30 Uhr: Pause
  • 11.30 - 14 Uhr: Gestaltung Tagesablauf, anschließend Start in die Themenbearbeitung
  • 14 - 15 Uhr: Mittagspause
  • 15 - 17 Uhr: Themenbearbeitung

Ablauf Sonntag, 16.10.2022

  • 9 - 11 Uhr: Themenbearbeitung
  • 11 - 11.30 Uhr: Pause
  • 11.30 - 13 Uhr: Ergebnissicherung, Ausblick


Themenwünsche

  • Vorstellung von Personen und Projekten -> Kennenlernen, verschiedene Anwendungsfälle von Indoor-Daten
  • Datenmodell/Tagging
    • Flächen für Wände, Säulen etc.
    • SIT außerhalb von Gebäudeumrissen (z.B. Bahnhöfe)
    • Fenster
    • Tags für Treppenhäuser und Aufzüge
    • Objekte auf dem Dach
    • Höhenunterschiede innerhalb eines Stockwerks
  • Gedankenaustausch zu zukünftigen Entwicklungen
    • Balkone
    • Zwischengeschosse/Komma-Level
    • Objekte mit unterschiedlicher Ausdehnung je Stockwerk
    • ...
  • Parallele Diskussionen in kleineren Gruppen:
    • Möglichkeiten zur Zusammenarbeit bei Entwicklern (Vorverarbeitung, Bibliotheken, Vektortiles, ...)
    • Wunschliste Werkzeuge fürs Mappen
  • Gemeinsame Schlussrunde:
    • Pflege der Dokumentation
    • Pläne für Aufrechterhalten der Kommunikation nach dem Treffen

Discourseforum der OSMF, Matrix, ...?

Weitere Themenwünsche

Was wollt ihr sonst noch gerne diskutieren? Bitte ergänzen!

  • Auswirkungen möglicher Änderungen am Datenmodell (API 0.7) auf Indoor-Mapping
  • Universelle Referenzen auf Räume, was vlt auch Anwendungsübergreifend funktionieren / verstanden werden könnte z.B. <Adresse;Raum-Ref> (oder: Wie könnte man aus Kalender auf Karte(n) springen und die Lage des Raumes dort darstellen?)
  • ...

Documentation of the meeting

  • 15. + 16.10.2022, Frankfurt/M.
  • at Bundesamt für Kartographie und Geodäsie, Sitzungssaal B13 und B14 im B-Bau, Richard-Strauss-Allee 11, 60598 Frankfurt am Main
  • Wiki: https://wiki.openstreetmap.org/wiki/Arbeitstreffen_Indoor_OSM_2022
  • Number of paticipants: Saturday: 11, Sunday: 6
  • The event was partly held hybrid so that remote participants can participate.

introduction of participants & project presentations

- Tobias Knerr, 3D-Rendering von Indoorkarten, Organizer
Project: OSM2World, Presentation OSM2World, OSM-Datamodelchanges (API 0.7), OSM and Simple Indoor Tagging
- David Lange, TU Chemnitz, Indoor-Navigation-App, Organizer
Present: and Simple Indoor Tagging, Project: https://wiki.openstreetmap.org/wiki/Simple_Indoor_Tagging
- Katja Haferkorn, coordination office FOSSGIS e.V., Organizer
- Johannes Heep, BKG
project: BKG Projekt Denied Areas
- Jan Schmalfuß-Schwarz, TU Dresden
project: AccessibleMaps
- Claudia Loitsch, TU Dresden
project: AccessibleMaps
- Antoine Riche, Carto'Cité
project: Mapping train station in and around Paris for SNCF (see slides), wrote Guidelines for pedestrian navigation
- Matthias Meißer (hmt), Raumplan für Hochschulen (siehe Tagung 2022 StudIP4future S10 pp.
Project: Indoor and Universities
- Volker Krause, KDE, Bahnhofs- und Flughafenkarten
project: KDE Itinerary
- François de Metz, indoor=
project: Indoor=, https://wiki.openstreetmap.org/wiki/Indoor%3D, https://indoorequal.org/#map=3.62/51.71/18.63
- Jakob Trenkler, CampusGIS2

OSM and Simple Indoor Tagging

Tobias & David - Presentation Introduction OSM and Indoor OSM

Themes for discussion

discussion themes

Level changing

Level changing

Inclined elevators:
Wiki: https://wiki.openstreetmap.org/wiki/Tag:highway%3Delevator
- using an _open_ way as documented on highway=elevator + width=* and possibly other tags is the best option with current tags
- it would be possible to map the extent of the cabin at each level as a polygon in addition to the open way mentioned above, tag for this would be TBD

Elevator cabin vs. elevator shaft:
- separating these into 2 separate elements has the benefit of tagging levels where elevator stops with level=* on cabin
- alternative would be a separate key (stops_at_level or something like that); would avoid the "abuse" of the level key with slightly different semantics

  • could also have separate information for private access

- 3rd option (and currently documented on SIT) is to use door nodes
-> preferred option: no changes are needed, highest achievable level of detail
TODO: make it more clear on the elevator page (and perhaps also on SIT) --> Tobias

Stairs:
Wiki: https://wiki.openstreetmap.org/wiki/User:Daveloper/indoor-stairs-mapping
- we need both a way + a polygon to achieve the desired level of detail
- Way: highway=steps like outdoors (matches current practice) + area:highway=steps

  • matching of polygon + way is possible; it should be required that both elements get level tags

- Polygon: indoor=room|area + room=stairs ?
- also see drawings on flipchart (u-shaped polygon, highway with no indoor tag) (pictures on nextcloud, links at the bottom)
TODO: write this down as a consistent proposal --> David and Tobias as assistant

SIT

SIT

indoor=wall vs. barrier=wall
- indoor=wall comes with a default assumption of full level height
- postponed

polygons for walls
- columns as nodes or areas are unproblematic
- indoor=column is in use but undocumented
- polygons for actual walls? e.g. cathedral example https://indoorequal.org/#map=19.38/4.5978117/-74.0753312&level=0
- abstract linear walls are more useful for some usecases (e.g. tactile printing) and make it easy to extract room adjacency
- polygons are nice for many rendering styles, though
- we could have walls overlapping rooms (with rooms sharing nodes)? Essentially have different "layers".

  • would require navigation applications to perform subtraction to shrink the room to the actual walkable/usable area
  • likely hard to explain to mappers

- is automated generation of walls from polygons possible? Probably quite messy.
- even these 2d walls are an abstraction of a 3d structure ... are we reaching problems encountered in CAD
-> consensus:

  • straight walls should be preferredly tagged as lines (potentially + width)
  • complex walls as polygons are ok BUT must reliably share nodes with rooms

TODO: get feedback from the community, then change the SIT documentation --> François

indoor=corridor
- corridor could be replaced with indoor=area/room (depending on whether there are walls)
- corridor may require adding some walls if there no rooms next to it
- room=corridor as a subtag for either indoor=area/room
TODO: get feedback from the community, then change the SIT documentation -> François

indoor=area
- intended use is for unwalled spaces, e.g. balconies

  • holes in the floor should be cut out with a multipolygon

- some have also used this to map a subsection of a room
-> can we use the same tag for both use cases?
-> is the second use case even necessary? Probably not, we can use established tags from the outside + level. Also, avoiding areas on polygons for routing is necessary outdoors as well (e.g. on a market square).
-> We might want new tags for other things, e.g. indoor equivalent of leisure=outdoor_seating (outside of the shop/restaurant, but not necessarily uncovered)
TODO improve documentation with examples and pointers for other things --> Tobias

Indoor furnitures
- there are tags for some kind of furniture (amenity=bench), but not for others (e.g. bookshelves)
- no need to make this indoor-specific
- follow the bench model and invent new tags (e.g. amenity=* or man_made=*, NOT barrier=*), a generic amenity=furniture could be used for obejcts that have no more specific tags
- should only be used for (relatively) permanent objects
TODO David to invent some tags for their micromapping use case -> David
TODO Improve documentation -> Tobias
- tags you may want to use in the context of indoor mapping (maybe on the Indoor Mapping page...?)
- use general tags for shops etc. instead of specific indoor tags -> mention in the context of room=*, for example

Doors & windows
- should make the importance of door=* in the context of SIT more clear (rooms should have doors)
- window=yes also exists and could be treated as standard
- where is the "upper limit" of a door (e.g. foldable wall) or a window (vs. glass wall)?

  • related problem: Room dividers that allow you to re-configure a space. -> separate topic, needs a solution as well. (separate tag on a wall) -> Postponed sub-discussion
  • these foldable walls are wide enough that contracting to a node door might affect navigation results

- Various options: separate wall type? separate indoor element? (does it exist outdoors?) door/window as ways? (node should be considered preferred for simple/common cases)

  • door type as "foldable glass panels"?

TODO start a discussion on doors as ways (but mention that nodes should still be the typical case) --> Volker

Doors: opening direction
- direction angle makes most sense (as angle number or cardinal direction)
- can be more complex (folds to the left/right, hinged doors that can swing in either direction)
- we also need directions as a reference point for the placement of hinges etc.
-> once we have a defined "door direction", "forward/backward" and "left/right" make sense

  • other directional door attributes: oneway doors

- for doors on the outer edge of a building, we can use the knowledge about "outside" to make angle unnecessary
TODO Tobias to draft a proposal/documentation based on direction angles

window
- there is need to know the height of the handle for accessibility reasons. Use window:handle:height ?
- most of them open inside ?
- https://wiki.openstreetmap.org/wiki/User:Tordanik/Window_tagging could probably be extended in a straightforward way with accessibility attributes
TODO: Tobias to ensure SIT is updated to consider window=yes part of the standard

Remove the documentation on indoor=door ? Most of them also have a door= tag
TODO: bring it up on the wiki again, remove recommendation to use indoor=door from Key:door -> Tobias to find previous discussion and start a new one on it

Continuing the exchange, next steps

left open, next todos

- use the forum at https://community.openstreetmap.org
-> use a tag #indoor on the General forum: https://community.openstreetmap.org/tag/indoor
- meeting at FOSSGIS conference
-- proposing a talk
-- BoF -> TODO Tobias to submit a BoF session
-- barcamp at OSM-Samstag
- online meeting ?
-- we can use the BBB room: https://osmvideo.cloud68.co/user/kat-75y-3pe-jgc
-> should be configured to allow others to administrate (give presentation rights) and allow everyone to start the meeting [done]
-- focus on a big topic (e.g. level definition, structure), timeboxing is import;ant to properly schedule it
-- 30 min intro, at least 2h(??) discussion -> maybe a 4h slot total
=> Volker to poll for the date
-- week 46: 13-20 november ? 8AM-12AM ; 1PM-5PM; evening
-- done here: https://community.openstreetmap.org/t/indoor-mapping-online-meeting/4442

Follow up meetings

About the data model change

https://media.jochentopf.com/media/2022-08-15-study-evolution-of-the-osm-data-model.pdf
https://github.com/osmlab/osm-data-model

Notes

Potential question to 2d people: are indoor features easy enough to filter out?

link collection

some impressions