ES:Etiquetado de interior sencillo
Este artículo es una traducción incompleta de Simple Indoor Tagging: puede tener carencias, errores no corregidos o partes que todavía no han sido traducidas.
Si comprendes el artículo original en inglés, por favor, ayuda a completar esta traducción al español. Lee las instrucciones sobre cómo traducir este wiki.
Parece que nadie está trabajando en la traducción en este momento. Anímate y colabora en la tarea de traducción.
Simple Indoor Tagging is a tagging schema for Indoor Mapping. It is simple to use but still holistic to even cover complicated cases. A list of other/previous indoor tagging schemes can be found here. This document was created in 2014 by SimonPoole, Tordanik, Peda and Andi; and primary written for mappers.
- 1 Summary
- 2 Use Cases
- 3 The Model / Tagging Schema
- 4 Tagging Examples
To sum up, these are the main characteristics of the model:
- mapping of indoor spaces including different floors (alias levels)
- existing OSM methodologies (nodes, ways, relations and keys) are utilized
Compatibility with Simple 3D buildings is an explicit goal of Simple Indoor Tagging. When combining SIT with S3DB, tags from both should be used at the same time.
Indoor maps or 3D Indoor information can be used for various applications, e.g.
- Indoor Navigation/Routing
- Floor plans and 3D maps
- Public Participation
- Emergency response
for public buildings.
The Model / Tagging Schema
In the following section, the model is presented and described
Simple POI mapping
Mapping of objects in OSM works best when there is no upfront requirement to immediately add everything in great detail. Most of the time mapping progresses from rough to detailed to insane. To support this we need to define a simple POI mapping scheme that can be used together with the indoor schema to allow visualisation and routing even when detailed floor plans are not available.
One approach is to allow such nodes simply to be tagged with a "level" tag. To make this simple enough to consume we suggest that either on the building outline or on the building relation at min_level=* and max_level=* should be tagged.
In the simplest case this would require only the addition of 2 tags to the building polygon and level tags to the POIs for a rough visualisation to work (routing would not be supported without additional indoor elements).
|level=*||the level the POI is located on||level=3, level=-1|
TODO: give examples, e.g. ATM in underground train intermediate level, doctors in 1st floor etc.
To make it easy for data consumers to find buildings with indoor coverage we suggest the tags min_level=* and max_level=*. In some countries specific level values are not assigned, e.g. floor 13 in western countries or floor 4 in China. To make these cases easier to map, we propose non_existent_levels=*.
|min_level=*||minimum indoor level||min_level=-1|
|max_level=*||maximum indoor level||max_level=14|
|non_existent_levels=*||optional: levels which don't exist e.g. for regional reasons||non_existent_levels=4;13|
Modelling the different indoor elements
The different indoor elements of a level also need to be mapped in OSM. Thereby, those parts with a covered area (i.e. rooms, stairways, corridors) are mapped as areas (closed ways or multipolygons).
We propose four basic indoor elements, with which everything can be modeled. The 5th value indoor=level is optional and not intended for rendering purposes, but for having a place to add additional information like a floor name.
|indoor=*||room||Conventional room with walls|
|indoor=*||area||Area without walls|
|indoor=*||wall||Individual (non-passable) wall element, when not already defined by indoor=room|
|indoor=*||corridor||Unwalled connecting passage|
|indoor=*||level||optional: see below|
The individual areas share the same nodes where they share a wall in real world. The connection between a room an a corridor is done by a door=* node, again shared by both objects.
TODO: Verweis auf Window und Door Proposal
Note: separate proposals for windows and doors are being developed therefore we don't propose any further details on both.
- Proposed features/door
- Opening direction from F3DB#Tagging_of_door_direction
Modelling connections between different levels
Stairs and escalators are modeled with same way as above. They span multiple levels (level=-1-5) and are connected to indoor=corridors via a door=* node on each floor. door=no can be used to tag a connection to a corridor when no physical door is present.
A uniform staircase or classic elevators would lead to duplicate door nodes in the same way. The nodes are also at the same lat/lon coordinates, only differing in the level value. For these cases we recommend to use only one door=* node with multiple level values or ranges, e.g. repeat_on=1;2 or repeat_on=1-5 (more see below). We recommend consumers of indoor data to duplicate these objects during preprocessing, using one level value for each.
|Photo||Use case||Proposed Tagging|
indoor=room or indoor=area when there are no walls.
indoor=room or indoor=area when there are no walls.
indoor=room or in special cases indoor=area when there are no walls.
Use a semicolon to separate the levels covered by the stairs, escalator, or elevator. Example: level=0;1could be used on some stairs to indicate that they connect levels 0 and 1.
TODO: detailled mapping of the individual stairs
Advanced modelling the different levels (floors)
All elements on the same level get a level tag or are optionally member of a level relation.
|level=*||describes on which level the element is (0 is normally the ground-level, -1 is the first basement etc.)||level=0, level=-2, level=3|
Local level notations per building should be reused. e.g. at Munich Airport 3 is the ground level.
Reasonable and sensible keys and values which could be added to an optional level-outline (indoor=level) are mentioned in the following table:
|name=*||the name of the corresponding level||name=Ground Floor|
|level:ref=*||the number or code of the level. This models the level numbering scheme as it is displayed in the building itself, e.g. on floor plans or elevator buttons, which may be different from the level=* value.||level:ref=K level:ref=E level:ref=3|
|height=*||the height of the level (with default unit meter)||height=4|
|level=*||describes which level number the current level has (0 is normally the ground-level, -1 is the first basement etc.)||level=0, level=-2, level=3|
Information about the indoor elements themselves (e.g. a name or type) are again attached as key-value pairs to the corresponding indoor element.
|level=*||MANDATORY the level the indoor element is located on||level=111, level=-1|
|name=*||the name of the indoor element (e.g. the room name)||name=Vesalius Aula, name=Audimax|
|ref=*||the ref of the indoor element (e.g. the room number)||ref=101, ref=01.15|
|height=*||individual height of an indoor element (defaul unit is meter)||height=3, height=2.5|
Multi-level features and repeated features
|level=*||in addition to the previously described cases, features spanning multiple levels (e.g. stairs, elevator shafts, high rooms) can be mapped by listing more than one level in the value||level=1;2, level=-1-5, level=-4--2|
|repeat_on=*||features that have identical copies on other floors can be mapped as a single node with this tag. This should be used sparingly and only if it is necessary (often the case with windows and elevator/staircase doors). The starting level is not included in this list, e.g. a feature with level="0" then repeat_on starts with "1".||repeat_on=1;3, repeat_on=0-6|
|place||levels||status||OSM link||OpenLevelUp link|
|Aachen University Building 1380||-1 - 3||all 92 rooms+toilets+entrances||||
|Public University of Navarre (UPNA) Lecture Building||0 - 3||All classrooms, corridors, toilets, entrances||||
|Public University of Navarre (UPNA) Library Building||-1 - 2||Everything||||
|Many Railway Stations worldwide (Berlin, Paris, New York Central, L.A., Sydney, Tokio Ueno Station||Growing, see Wiki OpenStationMap||www.openstationmap.org|