Termite
NOTE: The development of Termite is currently on hold. The existing Termite editor uses a map model different from the currently preferred Simple Indoor Tagging. If you are interested in making indoor maps please see Simple Indoor Tagging on the wiki.
Termite is a project to make an OpenStreetMap editor for indoor mapping. "Termite" is the name of editor software under design here (not implemented yet)
The editor is intended to be easy to use so that non-technically inclined people can easily make indoor maps. It will function both for indoors and outdoors but be targeted towards indoor mapping. An emphasis the editor will have will be for making structured, area-based maps with many overlapping ways.
A user will have a simple means of selecting a level within a structure on which to work, and then be able to work solely with data for that level. And features drawn will automatically be placed on the level. This will ease working with the underlying properties and relations needed to match the features to a level.
Indoor Map Philosophy
Indoor maps are not new and are very common, such as on the store directory at a shopping center. However, it is fairly new that people have started aggregating indoor maps in a consistent format as has long been done with outdoor maps. The existing indoor maps serve as a guide to how the standardized maps should look.
The following diagrams area a representative indoor map from a university building, the Yang and Yamazaki Building from Stanford University.
The philosophy followed in the editor is that each level of a structure comprises a separate accessible space, with the outdoors comprising an additional separate space. To create an indoor map, each level should be populated with map features, just as an outdoor map is populated with map features.
Zlevel
Each level is assigned an integer that we will refer to here as zlevel. By convention the zlevel of the ground floor is 0. Levels below ground have negative values and levels above ground have positive values. The zlevel is not to be confused with the name of the level, which is a string matching the name locally used for the floor. The name is often a number and it may not match the zlevel value. (In the United States, the name of the ground floor is typically "1".)
The zlevel can be viewed as a discrete vertical coordinate. Objects on a given level also have an elevation, or continuous z coordinate. This can be expressed relative to the level or some other absolute reference.
There are two other related but distinct discrete vertical coordinates used in mapping. The names used for these vary in different places. The three concepts are the following.
- zlevel - This specifies a distinct vertical map space, such as floors in a building.
- zindex ("layer" in OSM) - This specifies a distinct (but often unspecified) elevation within a given map space. A different zindex is given to an overpass and the road the is beneath it.
- zorder - This specifies a drawing order within a single vertical position. For example, in a drawing of a conference hall, a booth should be drawn after the room object, although both are at ground level.
In outdoor maps, the road elements serve a double duty as a visual element and as a graph for navigation. In a typical indoor map it is convenient to have navigation graph but this is typically not used as a visual element in existing indoor maps. When the indoor map is created, a navigation graph can be created using the same way conventions that are typically used in the outdoor map. This will allow use of a single routing engine to route through the outdoors up into the room of a building, or to a product on a shelf. The renderer for the indoor map will typically not render these navigation ways, however.
In multilevel structures, the navigation way will traverse between floors, following the path of the level change mechanism (stairs, elevator, escalator...).
Indoor Mapping Recommendations
The following link has some additional indoor mapping recommendations: Indoor/Termite/Mapping_Recommendations
Indoor Model
The official indoor mapping model of OpenStreetMap has yet to be determined. Some of the major proposals can be viewed from the page Indoor_Mapping.
The Termite editor is currently using a model loosely based on IndoorOSM, with a few changes. All naming definitions are contained in a configuration file for easy modification as the indoor conventions crystallize. The relation structure is necessarily coded into the software, but in a way that can hopefully be relatively easy to change.
The following is an overview of the model currently used in Termite:
Structure (Building)
The structure object, typically a building but possibly another object, is the object currently appearing in OSM. As an example, for a building this is the way corresponding to the building footprint.
No example source is provided because this object is identical to standard features in OpenStreetMap.
Levels
A structure can have one or more levels. Each level is represented as a relation object.
Relation Type
The relation type is level.
Roles
The relation contains two roles:
- structure - This is the parent object appearing in the outdoor map.
- node - This is a node that appears on this level.
Ways do not appear in the level relation in this model. A way is drawn on a level if it's nodes appear on that level. This also enables a way to span multiple levels, if it contains nodes from different levels. This is one of the driving motivations to place the nodes rather than the features (nodes and ways) in the level relation. The most important example where this would be done is for a way used in navigation such as the underlying path for a stairway or an elevator. This enables the same navigation and routing infrastructure to be used on the indoors and the outdoors.
There is also a philosophical reason to place the label for the level on the nodes. The level is a discrete z coordinate and is a property of the nodes along with the x and y coordinates.
An alternate proposal is to in fact label the level as a property of the point. This was not done because then there would be no database reference connecting the nodes to the structure, and the database integrity cannot be enforced. The method or labeling the zlevel using a property of the node does however have the advantage that a node is enforced to be placed on only one level. The restriction must be enforced manually if the nodes are placed in a relation.
Properties
There can be many properties on a level. Two of them are of particular importance:
- zlevel - This is an integer describing the ordering of the floor. By convention, 0 is the ground level. Levels above ground are positive and levels below ground are negative. The value of this integer does not have to correspond to the name of the level.
- name - This is the display name for the level, which is seen by users of the map. For example, in the United State the ground level is often called "1". Alternately, levels can be named "G", "37", "B1", "M", "Mezzanine" or even "Promenade".
In the discussion pages on some proposals there seems to be some confusion as to how levels are labeled regarding logical ordering and display names. There is an attempt to make that explicit here. The term "zlevel" is used rather then the term "level" to try to minimize the potential to confuse the logical order with the display name.
Example
An exemplary level relation as OSM-XML is provided below:
<?xml version="1.0" encoding="UTF-8"?>
<osm version="0.6" generator="CGImap 0.0.2">
<relation id="2264497" user="sutter_dave" uid="177052" visible="true" version="1" changeset="12115475" timestamp="2012-07-04T22:07:18Z">
<member type="way" ref="167142181" role="structure"/>
<member type="node" ref="1785444155" role="node"/>
<member type="node" ref="1785444188" role="node"/>
<member type="node" ref="1785444160" role="node"/>
<member type="node" ref="1785444171" role="node"/>
<member type="node" ref="1785444174" role="node"/>
<member type="node" ref="1785444234" role="node"/>
<member type="node" ref="1785444205" role="node"/>
<member type="node" ref="1785444150" role="node"/>
<member type="node" ref="1785444191" role="node"/>
<member type="node" ref="1785444153" role="node"/>
<member type="node" ref="1785444163" role="node"/>
<member type="node" ref="1785444166" role="node"/>
<member type="node" ref="1785444169" role="node"/>
<member type="node" ref="1785444139" role="node"/>
<member type="node" ref="1785444200" role="node"/>
<member type="node" ref="1785444172" role="node"/>
<member type="node" ref="1785444142" role="node"/>
<tag k="name" v="1"/>
<tag k="type" v="level"/>
<tag k="zlevel" v="0"/>
</relation>
</osm>
Features
Features, including nodes and ways, are added to each level. A feature is placed on the level by composing it with nodes that are on the level. The feature types to be used is flexible and has yet to be standardized.
No example source is provided because this object is identical to standard features in OpenStreetMap, modulo new feature types.
Proposed User Interface Layout
This is the proposed layout for the editor.
- Menu Bar - Holds the menu items
- Toolbar - Holds the toolbars
- Mode Toolbar - Holds a row of buttons to allow the user to select the editor mode.
- Submode Toolbar - Holds UI elements specific to the selected editor mode.
- Metadata Panel - A panel on the left side of the screen to hold metadata
- Content Tree - A tree containing the list of structures in the current data and a list of the associated levels. This allow the user to select the active level. There is also an entry representing the general outdoors.
- Feature Layer Panel - A control to select the active feature type. Drawn objects will be of this feature type, such as "wall".
- Property Panel - A panel which displays the properties for the currently selected object.
- Map Panel - Contains the map
- Supplemental Panel - Tabbed panel for additional data
- POI panel
- Reference panel
- Relation panel
- other
Development and Release
Work on the editor is in the early stages.
There are a number of outstanding questions related to indoor maps. Additionally, there is a potential problem related to adding large amounts of indoor data to the OSM database that might not be handled well by existing software, in particular the renders and also the editors. See the page Challenges_for_Indoor_Maps.
This tool and any other indoor editor should be used in a limited fashion until more decisions have been made on the format of indoor maps in OSM.
For more information, contact Sutter.
Some Additional Documentation
Termite Overview: http://code.google.com/p/osm-termite/wiki/QuickStart
Indoor Mapping Recommendations: /Mapping_Recommendations