IndoorOSM
This page is intended to present and DISCUSS a proposal for an IndoorOSM tagging schema (Project IndoorOSM). For a general overview of all available proposals have a look at Indoor.
| IndoorOSM | |
|---|---|
| Status: | Draft (under way) |
| Proposed by: | Gomar1985 |
| Tagging: | building=*, bulding:*=*, height=*, bulding:roof:*=*, bulding:facade:*=*, type=building, level:*=*, type=building:level |
| Applies to: | 
|
| Definition: | The main characteristics of the model proposal are:
|
| Rendered as: | |
| Draft start: | 2011-11-29 |
| RFC start: | |
| Vote start: | |
| Vote end: | |
Contents |
Intention of this project
Currently, most maps (not only online maps but also mobile maps on smartphones) focus on outdoor environments, although most of our time, we spent indoors. Additionally, new (high rise) buildings are constructed and their internal structure gets more and more complex, thus it is likely that (especially foreign) people get lost inside such places.
As many others, we (GIScience UniHD) discovered, that there is an increasing interest inside OSM for building mapping activities (currently there are nearly as much buildings as streets). These two facts (the increasing interest in buidlings and the need for indoor maps) have encouraged us to extend OSM to indoors. We have investigated the (hardly) existing indoor ideas in the community and created an extensive model for OSM indoor mapping activities, and also tried to communicate this with mappers and the research community (Cf. Goetz M., Zipf A. (2011): Extending OpenStreetMap to Indoor Environments: Bringing Volunteered Geographic Information to the Next Level , In: Rumor, M., Zlatanova, S., LeDoux, H. (eds.) Urban and Regional Data Management: Udms Annual 2011: Delft, The Netherlands. p. 47-58.) and received a lot of positive feedback. People in that community like the model and think that it is a very important step for the future.
Of course we want to involve you all (the OSM community) in this model development process and are looking forward to your comments and ideas. In addition to improvements and extensions of the model, also editors and visualizations need to be adapted.
Summary
To sum up, these are the main characteristics of the model:
- mapping of indoor spaces including different levels (floors)
- mapping of doors and windows (inside as well as facade)
- 3D properties (e.g. height etc. are also included)
- existing OSM methodologies (nodes, ways, relations and keys) are utilized
Use Cases
Indoor maps or 3D Indoor information can be used for various applications, e.g.
- Indoor Navigation/Routing
- 3D Visualization OSM-3D
- 2D Maps
- Public Participation
- Emergency response
for different venues, e.g.
- Airports
- Hotels
- Universities
- Schools
- Museums
- Train stations
- Shopping Malls
- other public buildings
The Model / Tagging Schema
In the following section, the model is presented and described
A building (main relation)
 |
The 3D Development 'staff' currently works on unifying the 3D related tags. Please join the discussion or the 2nd 3D Workshop Garching. |
A building is represented as a relation within our model, whereby the type of the relation is set to building. Additional (general) information about the building such as address, name, height etc. is attached as OSM keyvalue pairs to this main‐relation. The relation‐members (i.e. the children) of the main‐relation comprise the different levels and entrances/exits of the building. That is, for each building level (floor) there is one relation member. The role of these members define which level the corresponding level is (i.e. level_0, level_1, level_‐1, etc.). The ground level is always level_0. The entrances/exits are also mapped as relation‐members (Single nodes), but their role is entrance_exit. The main idea of what a building is, is depicted in Figure 1. As one might notice, the whole model follows some kind of relational approach.
An exemplary main-relation of the IndoorOSM model as OSM-XML source code is provided below:
<?xml version="1.0" encoding="UTF-8"?> <osm version='0.6' generator='JOSM'> ... <relation id='1370729' timestamp='2011-12-02T12:16:49Z' uid='300276' user='gomar1985' visible='true' version='8' changeset='10016221'> <member type='relation' ref='1370727' role='level_-1' /> <member type='relation' ref='1370728' role='level_0' /> <member type='relation' ref='1370725' role='level_1' /> <member type='relation' ref='1370726' role='level_2' /> <member type='node' ref='1098227410' role='entrance' /> <tag k='addr:city' v='Heidelberg' /> <tag k='addr:country' v='DE' /> <tag k='addr:housenumber' v='48' /> <tag k='addr:street' v='Berliner Straße' /> <tag k='amenity' v='university' /> <tag k='building' v='yes' /> <tag k='building:architecture' v='modern' /> <tag k='building:buildyear' v='1980' /> <tag k='building:cladding' v='concrete' /> <tag k='building:condition' v='good' /> <tag k='building:facade:colour' v='grey' /> <tag k='building:levels' v='4' /> <tag k='building:max_level' v='2' /> <tag k='building:min_level' v='-1' /> <tag k='building:roof:colour' v='black' /> <tag k='building:roof:material' v='cardboard' /> <tag k='building:roof:shape' v='flat' /> <tag k='height' v='14.5' /> <tag k='name' v='Geographisches Institut' /> <tag k='type' v='building' /> </relation> ... </osm>
Generally, due to the open key‐value pair methodology, it is possible to add any kind of information to the main-relation. However, we think that the following attributes are the most relevant ones (many of them are already used in OSM in some context).
Modeling the different levels (floors)
Each level of a building (i.e. each relation-member of the main-relation) is again mapped as an OSM relation. The type of these relations is building:level. The members of these relations are OSM elements (i.e. nodes, ways or relations) which represent the different level parts (e.g. rooms, corridors etc.). Their individual role is buildingpart. General information about the level (e.g. name, usage etc.) is attached as key-value pair to the corresponding level-relation.
There is also one closed way added to the relation to represent the shell (outline) of the level.
An exemplary level-relation of the IndoorOSM model as OSM-XML source code is given below:
<?xml version="1.0" encoding="UTF-8"?> <osm version='0.6' generator='JOSM'> ... <relation id='1370725' timestamp='2011-12-02T12:16:50Z' uid='300276' user='gomar1985' visible='true' version='6' changeset='10016221'> <member type='way' ref='94551306' role='buildingpart' /> <member type='way' ref='94551291' role='buildingpart' /> <member type='way' ref='94551309' role='buildingpart' /> <member type='way' ref='94551293' role='buildingpart' /> <member type='way' ref='94551280' role='buildingpart' /> <member type='way' ref='94551479' role='buildingpart' /> <member type='way' ref='94551407' role='buildingpart' /> <member type='way' ref='94551384' role='buildingpart' /> <member type='way' ref='94551345' role='buildingpart' /> <member type='way' ref='94551321' role='buildingpart' /> <member type='way' ref='94551352' role='buildingpart' /> <member type='way' ref='94551323' role='buildingpart' /> <member type='way' ref='94551312' role='buildingpart' /> <member type='way' ref='94551295' role='shell' /> <member type='way' ref='94551468' role='buildingpart' /> <member type='way' ref='94551456' role='buildingpart' /> <member type='way' ref='94551411' role='buildingpart' /> <member type='way' ref='94551389' role='buildingpart' /> <member type='way' ref='94551418' role='buildingpart' /> <member type='way' ref='94551392' role='buildingpart' /> <member type='way' ref='94551363' role='buildingpart' /> <member type='way' ref='94551325' role='buildingpart' /> <member type='way' ref='94551282' role='buildingpart' /> <member type='way' ref='94551482' role='buildingpart' /> <member type='way' ref='94551470' role='buildingpart' /> <member type='way' ref='94551458' role='buildingpart' /> <member type='way' ref='94551472' role='buildingpart' /> <member type='way' ref='94551460' role='buildingpart' /> <member type='way' ref='94551428' role='buildingpart' /> <member type='way' ref='94551394' role='buildingpart' /> <member type='way' ref='94551315' role='buildingpart' /> <tag k='height' v='4' /> <tag k='level' v='1' /> <tag k='level:usage' v='academic' /> <tag k='name' v='1. Obergeschoss' /> <tag k='type' v='level' /> </relation> ... </osm>
Reasonable and senseful keys and values which should be added to such a level-relation are mentioned in the following table:
| Key | Description | Example value(s) |
|---|---|---|
| name=* | the name of the corresponding level | name=Ground Floor |
| level:usage=* | describes the usage of the level | level:usage=academic, level:usage=residential |
| height=* | the height of the level (with default unit meter) | height=4 |
| level=* | describes which level number the current level has (0 is always the ground-level, -1 is the first basement etc.) | level=0, level=-2, level=3 |
Modeling the different building parts
The different building parts of a level (Cf. above) also need to be mapped in OSM. Thereby, those parts with a covered area (i.e. rooms, stairways, corridors) are mapped as closed-ways, whereat in contrast other parts such as doors or windows are mapped as single nodes with additional information about the width, height, accessibility etc. Information about the building parts themselves (e.g. a name or type) are again attached as key-value pairs to the corresponding building part element. An exemplary OSM-XML excerpt for a building part is given below:
<?xml version="1.0" encoding="UTF-8"?> <osm version='0.6' generator='JOSM'> ... <way id='94551494' timestamp='2011-12-02T12:16:58Z' uid='300276' user='gomar1985' visible='true' version='3' changeset='10016221'> <nd ref='1098227358' /> <nd ref='1098226969' /> <nd ref='1098227303' /> <nd ref='1098226902' /> <nd ref='1098227358' /> <tag k='buildingpart' v='room' /> <tag k='height' v='3m' /> <tag k='indoor' v='yes' /> <tag k='name' v='010' /> </way> ... </osm>
| Key | Description | Example value(s) |
|---|---|---|
| buildingpart=* | what type of buildingpart is it | buildingpart=room, buildingpart=hall, buildingpart=corridor, buildingpart=verticalpassage |
| name=* | the name of the buildingpart (e.g. the room name) | name=Vesalius Aula, name=Audimax |
| ref=* | the ref of the buildingpart (e.g. the room number) | ref=101, ref=01.15 |
| height=* | individual height of an buildingpart (defaul unit is meter) | height=3, height=2.5 |
| window=* | it's a window (attached to a node which is part of the buildingpart way). The node should be placed in the center of the actual window.
The value of this key can either be yes or it can also be used for refining the type of the window (see examples) |
window=yes, window=glass, window=hole, window=lattice window |
| width=* | individual width of a window (default unit is meter) | width=2 |
| height=* | individual height of a window (default unit is meter) | height=1.2 |
| breast=* | the breast of a window (i.e. the space between the ground and the bottom of the window, default unit is meter) | breast=1.3 |
| door=* | it's a door(attached to a node which is part of the buildingpart way). The node should be placed in the center of the actual door.
The value of this key can either be yes or it can also be used for refining the type of the door(see examples) |
door=yes, door=manual, door=automatic |
| width=* | individual width of a door (default unit is meter) | width=1 |
| height=* | individual height of a door (default unit is meter) | height=2 |
Modeling connections between different levels
A crucial issue about indoor mapping (at least in current 2D editors) is the mapping of vertical connections between different levels (vertical connectors). There are already some other ideas within OSM (Cf. Indoor1, Level Map or Indoor2, see also the Discussion page here), but they (especially the latter two ones) are not applicable for vertical connectors which do not have the same coordinates on the different levels (e.g. escalators or stairways).
The IndoorOSM model proposes the following approach:
As mentioned above, the buildingparts which represent a vertical connector (a verticalpassage) should be mapped as buildingpart=verticalpassage. That is, each elevator funnel, each stairway area or each escalator platform will be mapped as a closed way. For providing information about what kind of verticalpassage it is, the tag buildingpart:verticalpassage=* with values stairway, elevator, escalator can be used. The general floorrange of the vertical connector can be provided by using buildingpart:verticalpassage:floorrange=*. Also, all verticalconnectors are accessed via a door (see above), so for each entrance to a vertical connector, a door node should be provided. The information about the vertical connection itself is attached to these door-nodes by using the key connector:ids=*. The value of this key is then the OSM-ID of the OSM element which it is (in reality) connected to. If a verticalpassage is connected to several levels (e.g. an elevator), then several values are provided, e.g. connector:ids=94551469, 94551394. In the case of an one-way vertical connector (e.g. an escalator), only the starting node of the connector will be enriched with this key.
Example 1 (an escalator, A -> B):
OSM node id 12345
connector:ids = 67890
OSM node id 67890
Example 2 (an elevator with two entrances, A <-> B):
OSM node id 12345
connector:ids = 67890
OSM node id 67890
connector:ids = 12345
Example 3 (an elevator with three entrances, A <-> B <-> C):
OSM node id 12345
connector:ids = 67890
OSM node id 67890
connector:ids = 67890
connector:ids = 11111
OSM node id 11111
connector:ids = 67890
By mapping vertical passages in this way, it is possible to create a (semantically described) connection between various levels. For the current OSM editors it might be a bit circuitous to obtain the corresponding OSM ids, but it might be the best method (for any kind of vertical connection) to map vertical connectors.
Other issues
There is not yet a proper name for this indoor project. Do we need one? For example we could think of IndoorOSM or (having the OPEN in mind and one of the most important use cases (see below for activites of other companies) ) e.g. OpenVenueMaps (OVM). These proposals are of course open for discussion - so if you have other ideas, just provide them :)
Places/Examples
A list of all places which are mapped according to this model:
- Institut of Geography in Heidelberg
Applications with IndoorOSM data
A first draft version of an IndoorOSM map application has been developed and is available here: http://indoorosm.uni-hd.de/
The application visualizes the interior structure of a building for each building-level. It shows a birds perspective of one level and a level-switcher allows the selection of different levels. Also, Indoor Routing capabilities are integrated in the client, so it is possible to compute routes through the building (also for rooms on different levels). When computing a route, a user can decide between two different modes: on the one hand, the complete route is displayed (which provides a brief overview but looks a bit strange for mutli-storey routes). Otherwise, the user can request partial routes for each individual floor, so while switching the floors, the different route parts are visualized. Also a blue dot indicates the start of the route, and a blue cross visualizes the target.
The application functions in different browsers as well as on the IPad and Blackberry devices (IPhone should also work). The application at the moment is of course an online application, however memory requirements are quite low, thus it should also be able to provide an standalone (offline) version (not yet tested).
