Proposal:Indoor

From OpenStreetMap Wiki
(Redirected from Proposed features/indoor)
Jump to navigation Jump to search
indoor
Proposal status: Obsoleted (inactive)
Proposed by: saerdnaer
Tagging: room, level, type=level, type=building, outdoor=*
Applies to: node, area, relation
Definition: This proposal is for detailed mapping of public buildings like universities, train- and underground stations.
Statistics:

Draft started: 2011-03-28

ToDo: Translate to english and use default template for proposed features.

Revision 2

not documented yet. --Saerdnaer 13:30, 2 December 2011 (UTC)

Revision 1.5

Um Räume in OpenStreetMap abzubilden ist es aus meiner Sicht nicht notwendig, das grundlegende Modell aus Node, Way und Relation zu ändern, man muss sich nur auf gewisse, zusätzliche Tagging-Regeln zu einigen.

Stockwerk/Höhe/Z-Koordinate

Ein Node hat in OSM aktuell standardmäßig nur Längengrad/Breitengrad (lat/lon) bzw. X/Y Koordinaten, erlaubt aber wie alle Objekte in OSM freies Tagging, wodurch sich die Z Koordinate als weiteren Tag umsetzen lässt.

In OSM gibt es bereits den Tag ele=*, der die Höhe über dem Meeresspiegel in Metern angibt und bisher hauptsächlich für Berge (Gipfelhöhen) und Pässe verwendet wird. Es existiert auch der Tag layer=*, der insbesondere bei Brücken und Autobahnkreuzungen, die richtigen Ordnung bezüglich "übereinanderliegen" ausdrückt. Man könnte ihn sozusagen als Stockwerk interpretieren, allerdings ist der Begriff Layer in der klassischen CAD/GIS Welt mit einer anderen Bedeutung besetzt und führt nur zu Verweslungen.

Im Allgemeinen ist es vom klassischen Mapper zu viel verlangt die absolute Höhe des jeweiligen Stockwerks zu kennen, weswegen ich mich entschieden habe direkt auf die Stockwerksbezeichnungen vor Ort zu gehen. Im Regelfall ist Level 0 das Erdgeschoss (EG), Level 1 das 1. Obergeschoss (OG), Level -1 das 1. Kellergeschoss (UG) usw.

Zwischengeschosse lassen sich mit Komma-Werten ausdrücken. In Geschoss zwischen EG und 1. OG wäre demnach Level 0.5. Das selbe Prinzip lässt sich auch bei Treppenhäusern anwenden, vgl. Bild. Es sind bis zu zwei Nachkommastellen erlaubt.

Indoor steps1.png Indoor steps2.png

Es gilt die lokale Beschilderung der Stockwerke. Am Flughafen München wäre das Erdgeschoss demnach Level 3. Dieses Offset sollte an gegebener Stelle (z.B. building oder site) mit dem Tag level_offset=* deklariert werden. In diesem Beispiel wäre level_offset=3.

Räume

Indoor room.png

Die einzelnen Räume werden durch eine Fläche (Area, geschlossener Way) realisiert, der einen Tag mit dem Key room=* enthällt. Der Wert beschreibt die Art des Raumes. Falls die Art unbekannt ist wird einfach nur yes verwendet. Die Werte orientieren sich an dem von der SIG 3D erarbeiten RoomFunctionType, wie er in der CityGML Spezifikation V1.0.0 auf Seite 163 aufgeführt ist. Die gewählten Werte und deren -- von der SIG 3D gewählten -- Code finden sich in Tabelle auf Key:room. In dieser Spezifikation gab es in machen Fällen mehrere Codes für den selben Raumtyp. Teilweise konnten auch schon existierende Reglungen aus OSM übernommen werden wie z.B. die Feingliederung bei Büros mit office=*.

Wände ergeben sich implizit an den Grenzen der Räume und werden nicht gesondert modelliert. Türen sind einzelne Nodes des Raum-Ways die mit dem Tag entrance=yes versehen sind. Zugangsbedingungen können mit dem bereits bestehenden Tag access=* deklariert werden. Fenster werden aktuell nicht modelliert, da für die aktuell relevanten Anwendungsfälle nicht benötigt werden.

Angrenzende Räume müssen die bestehenden Nodes des bereits existierenden Raumes -- soweit sinnvoll -- mit einbinden. Es dürfen keine neuen Nodes mit den selben Koordinaten (lat, lon sowie level) angelegt werden, wenn bereits ein Node dafür existiert. Dies impliziert, dass ein Node, im Bezug auf die Realität, genau in der Mitte einer Wand sitzt. Wandstärken werden aktuell nicht betrachtet und modelliert.

Für Raumnummern wird der ebenfalls bestehende Tag ref=* benutzt. Es gilt analog zu den Stockwerken die Raumnummer, die vor Ort auf dem Türschild steht.

Jeder Raum sollte selbstverständlich auch mit einem level=* Tag (siehe vorheriger Absatz) versehen sein.

Wege, Gänge und Treppen

Wege, Gänge und Treppen werden nicht als Raum bzw. Area sondern in mit einem Way modelliert. Die räumliche Ausdehnung ergibt sich aus den Flächen eines Gebäudes die nicht als Raum deklariert sind. Optional kann die Breite des Weges mit dem bereits existierenden Tag width=* angegeben werden. Dieser Weg verbindet alle Türen bzw. entrance=yes Nodes miteinander, wodurch ein Erreichbarkeitsgraph entsteht.

Als Tag für diesen Weg wird highway=corridor verwendet. Falls es sich bei dem Weg um eine Treppe handelt, stattdessen highway=steps.

Für Aufzüge existiert bereits der Vorschlag highway=elevator. Pro Stockwerk gibt es einen Node der entweder mit einem Weg mit Level-Tag verbunden ist oder selbst einen Level-Tag enthält. Da Aufzüge senkrecht verlaufen, haben alle Nodes die gleichen X,Y Koordinaten. Diese Nodes sind, in der richtigen Reihenfolge, mit einem Way mit highway=elevator verbunden.

Standardmäßig wird davon ausgegangen, dass alle Wege innerhalb eines Gebäudes nur durch Fußgänger und Rollstuhlfahrer richtungsunabhängig nutzbar sind. Falls vor Ort andere Regelungen herrschen kann wiederum auf die Access-Tag Familie (access=*, foot=*, bicycle=*, wheelchair=*, oneway=*) zurückgegriffen werden.

Falls ein Weg von oben gesehen innerhalb eines Gebäudes liegt, durch bauliche Gegebenheiten aber trotzdem außerhalb verläuft ist dies durch den Tag outdoor=yes zu kennzeichnen.

Selbstverständlich muss auch jeder Weg wiederum mit einem level=* Tag versehen sein. Bei Treppen ergibt sich das Level automatisch aus dem Zusammenhang. Falls eine Treppe ohne Zwischenpodeste nicht linear ansteigt, können auch einzelne Nodes mit einem Level versehen werden.

Ist ein Weg innerhalb einer Area mit building=yes, verläuft aber im Freien, muss zusätzlich der Tag outdoor=yes hinzugefügt werden (vgl. Bild)

Indoor outdoor.png

Relationen

Um dieses Model einfach in andere Formate transformieren zu können, ist es noch möglich die einzelnen Objekte zu verknüpfen.

Räume eines Stockwerks werden mit einer Relation zusammengefasst. Diese Relation bekommt den entsprechenden level=* Tag. Diese Level-Relations werden wiederum zu einer Building Relation zusammengefasst werden, in dem der ursprüngliche Gebäudeumriss (Area mit building=yes) als outline=* ebenfalls enthalten ist. Falls einzelne Stockwerke vom Gebäudeumriss abweichen kann in der entsprechenden Level-Relation ebenfalls auf eine Area als outline=* verwiesen werden.

Bei Bedarf können mehrere Gebäude (Building-Relations) zu einer Site-Relation zusammengefasst werden.

Areas of Interest (AOIs, vgl. BIGML) können bei Bedarf ebenfalls mit Relations umgesetzt werden.

Indoor relations.png

Beispieldaten in diesem Schema

Sonstiges

Lightning Talk auf FOSSGIS 2011:

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal:Indoor&oldid=2514643"