Import/Indoor Navigatum

NOT CURRENTLY A FINISHED PROPOSAL

Indoor NavigaTUM is an import of the indoor dataset offered specifically for OSM by the Technical University of Munich (TUM). It is of type OSM-XML covering roughly 400 building-parts in the greater Munich area, mostly Campus Garching-Forschungszentrum, Campus-Munich City Center, Campus-Ottobrunn and satellite campuses like TUMs 13 buildings(/-parts) on the Campus Straubing.

The import is currently (as of 31/10/2024) at the planning stage.

Goals

For indoor mapping and indoor-navigation, having accurate maps is vital.

We (the student club Open Source @ TUM e.V.) see value in Open-Data-ing this (usually proprietary) data.

We anticipate that sharing patches for opening times, floorplans and other feedback between institutions (like universities, libraries, and others) is much simpler if this is done openly. Furthermore, importing this data has the effect of making indoor routing much more seamless as an additional benefit.

We hope that this model of opening up the indoor data silos might (in the future) help other larger Organisations (like University) with the need for roomfinding get to better solutions.

Doing this with only one University might not look ambitious (given the vision), but let's see where the problems first and address feedback on a small scale.

Schedule

• We watched the FOSSGIS 24 talk ”Barrierefreie Indoor-Navigation auf Basis von OSM-Daten” (German only) which talked about how to do indoor routing accessibly. We were motivated to implement something similar in the Universities Roomfinder https://nav.tum.de.
• I asked in the osm matrix channel if there was interest and the feedback was that the data would be interesting, but that our motivation for importing it was unclear. I was redirected to the import and automated editing guidelines.
• TUM has hired a local contributor to OSM to help us review the changes and to suggest fixes before we “bother” the greater community. His job will be to keep us accountable that we are following the process.
• Based on this, we decided doing this manually first is a better fit: As a learning project, we then manually mapped a small (previously unmapped) building on our campus over a number of changesets
• 8. October 2024: We have contacted the Munich OSM chapter and attended a meeting. We discussed our plans and gathered feedback on that meeting. The consensus was overall positive, even though there was a consensus that indoor mapping is quite difficult due to being badly supported by tooling. Our plan to Conflation was the most discussed part, as this will be quite labour-intensive on our (not OSMs' contributors) side.
• October 2024: we started the process of finishing the import proposal and gathering legal approval from the university for this data release
• 13. November 2024: Present the import plan to the Munich OSM chapter (⇐ CURRENT STEP)
• 14. November 2024: sign contract releasing the data to the local OSM community chapter
• TODO: Present the import-plan to the forum and the local matrix channel
• TODO: Iteratively import a building at a time. Gathering feedback if we made a mistake, and import more after the local OSM chapter or wider community finds the added data/process good. This is done more iteratively than other imports due to the labour-intensive, manual conflation noted below…
• TODO: Present the results at FOSSDEM 2025 or State of the Map 2025 to reflect if this is replicatable and if this should be replicated in other universities
• TODO: Release a map based on OSM to our university. Preview with current data here https://nav.tum.de/next

Import Data

Background

Data source site: http://nav.tum.de ⇐ TODO: not on the website
Data licence: ODbL-1.0
Type of licence (if applicable): ODbL-1.0
Link to permission (if required): Granted permission (written, signed contract) ⇐ TODO: Pick up the paper in person, upload to the wiki and link here
OSM attribution (if required): not required
ODbL Compliance verified: yes

OSM Data Files

Provide a link to the data files you have prepared for import.

(Currently not done)

Import Type

This is a one-time import, but we will be monitoring the changes done to the original dataset and manually (if the changes are relevant, most are not) update the data we added/merge diverged data.

We will add the data via JOSM to merge existing and new data manually.

Data Preparation

Data Reduction & Simplification

In the dataset, there are rooms, elevators, corridors, and staircases which are relevant for simplication:

• corridors/rooms/elevators have relatively straight walls already, simplifying them is relatively trivial
• (relatively) straight staircases can just be reduced to start+end
• curved staircases are more of a challenge: The current approach is placing one point per step as a semi-sensible compromise between accuracy and simplification. If someone has a better metric, we would like to hear feedback on this.

There mostly is no need for changing existing data as indoor is usually not tagged. There are two cases, where a part of a building is incompletely tagged already. Differing from the already tagged data, we will

• in the Garching-Forschungszentrum area, we won't add relations between rooms and floors. Reasoning: Not a standard according to Simple Indoor Tagging. We will not change existing data tagged as such. This course of action was discussed this with the local munich OSM chapter on the October meeting.
• In the munich city centre campus, we will have to re-tag stairs tagged as highway=corridor as highway=steps.

Tagging Plans

Type	Tagging plan	Illustartion
level	We will create indoor=level layers manually as appropriate.
room	Extract rooms as polygons with the following attrributes: ref (non-unique) ref used in the buildings signs Example: "MW 2001" alt:tum university-wide room-locator Example: "5510.02.001" height average height of the room indoor=room level=NUMBER	The plan for geometry extraction from CAD-Data
door	Extract doors as points on the two rooms they were attached to with the following attributes: width width of the door height average height of the door indoor=door level=NUMBER
corridor	Connect to previously connected rooms, stairchaes, elevators and doors as polygons indoor=corridor level=NUMBER	Example corridor
staircase	If this is a room, extract the geometry for the room as described above. Tag the room that are stairways as indoor=room room=stairs stairs=yes level=FROM-TO If this is not a room (rather just a semi-random stair such as the free-floating one here), tag as: indoor=area stairs=yes level=FROM-TO Additonally, add the routing information via lines. For the stairs: step_count=NUMBER incline=up (for added clairity, all ways point upwards, can remove if wanted) highway=steps indoor=yes width=NUMBER level=FROM;TO For the flat sections of the stair between chases: highway=corridor width=NUMBER indoor=yes level=FROM;TO Modeling something twice seems insane.. If someone has a better grip on how stairs should be modelled, reaching out is appreciated. The documentation on this is quite conflicting.	Example stairs
elevator	Extract the geometry same as for the room as described above. For tagging, we plan to follow this rather than this this standard from the elevator wiki site. Reasoning: It seems more accepted in the community. The polygon underpinning the geometry of the of the room is: indoor=room room=elevator level=VISITS1;VISITS2;VISITS3;VISITS4 For the middle of the elevators, we will place a point with: highway=elevator level=VISITS1;VISITS2;VISITS3;VISITS4 door:width=NUMBER door:height=NUMBER width=NUMBER length=NUMBER Elevator doors are points to be imported as such: door=sliding automatic_door=button indoor=door (despite this not being on File:Indoor2.0 buildingpart.svg, which according to other docs should be a mistake) width width of the door height average height of the door	Outer doors with different dimensions or different type

Being transparent, these are NOT goals:

• Importing the name tag. The data if a name is actually a name is not good and pretty difficult to clean up. Given that names like "Seminarraum Taurus 1 im Galileo Mo-Fr 7-19 Uhr” is not a name by OSM-Defintion, we think this should better be done manually afterwards for the few rooms where adding a name is actually sensible.
• Importing the rooms actual usage (office/shop/ammenity/room). The data quality here is too difficult to verify. Example: If a large office is actually an office and not a seminar room is difficult to know, and even harder to tag as is. Furthermore, Universities are (sensibly) scared of telling people where we store our uranium (not joking). ⇒ Telling people WHERE a room is and HOW to get there (i.e. without telling WHAT is in the room) is fine, though.

In both cases, we can (and will) go back and refine the tagging via non-import means for these rooms once we have gathered more feedback later.

For example, DiversiTUM has done a full inventory of all toilets or the student council for mechanical engineering has done a survey of all lecture hall names. Both of these would not be imports as far as we read the import guidelines.

Changeset Tags

Fill in the values your changesets will use.

Key	Value
comment	Add indoor data for https://nav.tum.de/BUILDING
import	yes
source	Indoor CAD Data of the Technical University of Munich
source:url	https://nav.tum.de/building/BUILDING/export (<== NOT CURRENTLY LIVE)
source:date	DD.MM.YYYY
import:page	https://wiki.openstreetmap.org/Import/Indoor_Navigatum
source:license	ODbL-1.0

Data Transformation

For the basic data extraction, we will be using TOOL

Then, we will post process this data

Data Transformation Results

Post a link to your OSM XML files.

TODO

Data Merge Workflow

Team Approach

We are a team of 2 people, one acting as the author and one as an internal reviewer.

Disclaimer: we are both paid by the Technical University of Munich.

References

Arial buildings will be used to check locations and to geolocate the buildings outlines.

Workflow

The general workflow is to start at buildings with currently no indoor tagging and end at the buildings with partial indoor tagging. None of the buildings considered have full indoor tagging. This will ensure that the work will stay easily revertible.

This is the proposed workflow per sub-building and floor. It will make sure that existing tagging is not vandalised. Building outlines will sometimes need to be changed to fit our mostly more precise data. Changes to existing tagging have been discussed above.

• Export the geodata about the buildings from the proprietary AUTOCAD-Architecture datasource
• Convert it via TODO into a workable data structure
• Do the transformations as listed above
• Convert it via TODO into OSM-XML
• Load the data into JOSM to see where the conflicts are, resolve them via deleting our data or moving the building outline (thus preserving the history) to the correct place
• The reviewer in our team reviews the change
• Upload to OSM and request feedback (only for the first uploads to not present an undue load)

Changeset size policy

Changesets will be small as we only edit one building at a time.

Revert plans:

If needed (or the community requests this), we will use the reverter plugin in JOSM

Conflation

Conflation is described in the workflow above and will be done mostly manually with a little help from JSOMs' conflation tool for the later buildings (if possible, but we likely will have to merge manually).

QA

Next to running JOSMs existing QA tooling, and request+listen actively for feedback

The imports are “verified” by local knowledge, as we know the buildings geometries (we are students there) and can notice obvious mistakes.

We are aware that this is the first indoor import proposal and want to get this right.

See also

The post to the community forum was sent on YYYY-MM-DD and can be found here