Last weekend we had a workshop around indoor mapping in Frankfurt (Arbeitstreffen Indoor OSM 2022 - OpenStreetMap Wiki). While very productive we didn’t even get close to covering all topics, so we want to follow up on this with a couple of online meetings. This would hopefully also help with expanding collaboration beyond the initially rather German-centric workshop.
The proposed topic for the first session would be questions around the level tag, such as:
What is a level, how to deal with intermediate/fractional levels.
How to deal with level tags beyond a single self-contained building (e.g. for large train stations).
Thank you for your continued work on SIT and making the meeting notes available.
A few thoughts on them
The discussion should not be in German only. The proposed tagging scheme should be applicable to building conventions other than those found in Germany, too. Involving people from across the globe prevents a tagging scheme that relies on regional conventions.
** Wall polygons should be avoided if possible. They are justified for characteristic walls as in the cathedral example, though.
** The indoor mapping should avoid introducing an excessive number of OSM nodes since this makes editing hard especially for users without awareness of filtering in editors (casual mappers and new users).
** It’s not trivial but walls can be generated by data consumers/renderers if needed. I’ve described this in more detail at Augustus Kling's Diary | Floor plans, wall generation and labels | OpenStreetMap where an interactive example is also linked.
** Instead of indoor=corridor it’s preferable to have indoor=room/area + room=corridor since a corridor is only a special case of predominant room/area use.
** I’d challenge if one really wants to model doors in detail. Perhaps its better to stick with door=yes + level + optional width.
** To give details about doors one could draw walkways connected to the door nodes and specify attributes on the walkway. I’m thinking about single directional use (oneways), time restrictions (opening hours) and if the user needs to be able to push/pull to open a door in order to make use of the walkway (may affect routing for disabled people).
** Door or walkway details should be an abstraction that allows deriving meaning for various use cases. The aim should not be to describe every detail that can be seen in reality. For example one could map door materials but I don’t see how this could be a useful thing to do.
** I’ve attempted to detect where outside is in the example linked above and visualize building entrances with green triangles this way. This detection considers the presence of rooms instead of building polygons because the shape of the building may be different for each floor.
** I see no advantage of using indoor=door over door=yes. The former could be removed to simplify SIT.
The next step will be to meet online on a videoconferencing platform.
Independently from these planned online meetings, I hope some of us will also be able to meet face to face at the 2023 FOSSGIS conference in Berlin where I’ve submitted a discussion session (“BoF”) on the topic. But besides that, we have made no plans for another physical meeting so far.
Thank you for your thoughts! I think this is pretty close to what we discussed at the meeting. Agree that it would be good to allow more people to join the discussion, and I hope that continuing the conversation online will help us achieve that.
On the topics that were discussed in Frankfurt, we plan to also bring them up one-by-one in separate discussions/threads. We’ll likely use this forum and would appreciate your input there as well.