Wenn Sie Indoor-Navigation, Analytik oder ein digitales Verzeichnis über mehr als ein Gebäude hinweg aufbauen, ist das gewählte Kartenformat kein Detail, das Sie aufschieben können. Ein einmal für eine einzelne Lobby gezeichneter Grundriss kann in nahezu jedem Format existieren. Sobald dieselbe Karte jedoch Routing steuern, eine Positionierungsebene speisen und über zehn Standorte hinweg, die von verschiedenen Teams erstellt wurden, konsistent bleiben soll, wird die Kodierung zu dem, worauf alles andere aufbaut.
Genau dafür sind Standards für Indoor-Kartendaten da. Sie definieren eine gemeinsame Struktur für das, was das Innere eines Gebäudes enthält, sodass eine Kartierungs-Engine, eine Routing-Engine und eine Analytik-Ebene alle dieselbe Datei auf dieselbe Weise lesen können. Dieser Beitrag erklärt die Standards, nach denen ein GIS-, Produkt- oder Facility-Team namentlich sucht: GeoJSON als Basiskodierung, IMDF als das darauf aufbauende, standortstrukturierte Format und IndoorGML als den Standard, der den Innenraum sowie den für das Routing verwendeten Netzwerkgraphen modelliert. Zum Arbeitsablauf, aus architektonischen Quelldaten eine Karte zu erstellen, siehe von BIM zur Wegeführungskarte; dieser Beitrag ist die begleitende Referenz zu den Formaten selbst.
Was sind die wichtigsten Standards für Indoor-Kartendaten?
Die am häufigsten genannten Indoor-Kartenstandards sind IMDF (Indoor Mapping Data Format), das die Etagen, Ebenen, Einheiten und Points of Interest eines Standorts als eine Reihe von GeoJSON-Features strukturiert, sowie IndoorGML, ein Standard des Open Geospatial Consortium, der den Innenraum und den für das Routing verwendeten Netzwerkgraphen modelliert. GeoJSON selbst ist die zugrunde liegende Kodierung, auf der IMDF aufbaut. In der Praxis erstellen Teams Geometrie in CAD oder BIM und exportieren oder konvertieren sie dann in einen dieser Standards, damit eine Kartierungs- und Routing-Engine Etagen, Verbindungen und Ziele über Standorte hinweg konsistent verarbeiten kann.
Sie sind nicht im einfachen Sinne Konkurrenten: GeoJSON ist eine Allzweck-Kodierung, IMDF ist eine Art, GeoJSON für Gebäude zu verwenden, und IndoorGML ist ein eigenständiger Standard, der das Routing-Netzwerk in den Vordergrund stellt. Wozu ein Team greift, hängt davon ab, ob die Priorität eine portable Standortbeschreibung oder ein expliziter Navigationsgraph ist.
GeoJSON: die Basiskodierung für Indoor-Features
GeoJSON ist ein Format zur Kodierung geografischer Datenstrukturen mithilfe von JSON, von der IETF als RFC 7946 (2016) veröffentlicht, was es zu einer offenen, stabilen und weithin implementierten Spezifikation macht statt zu einem herstellergebundenen Format. Es ist nicht speziell auf Indoor-Kartierung ausgelegt; es ist die allgemeine Kodierung, die sehr viele Web- und Geodaten-Werkzeuge bereits lesen.
GeoJSON definiert eine kleine Menge von Geometrietypen, darunter Point, LineString und Polygon, verpackt sie in Features, die Eigenschaften tragen, und gruppiert Features in einer FeatureCollection. Für eine Indoor-Karte beschreibt dieses Vokabular die reinen Formen: ein Raum ist ein Polygon, eine Tür ist ein Punkt, eine Korridor-Mittellinie ist eine Linie, und jedes trägt Eigenschaften wie einen Namen oder eine Kategorie.
Was einfaches GeoJSON nicht liefert, ist irgendeine Indoor-spezifische Bedeutung. Es hat kein eingebautes Konzept einer Etage, keiner Beziehung zwischen einer Ladeneinheit und dem sie enthaltenden Gebäude oder wie eine Ebene mit der nächsten verbunden ist. Sie könnten eigene Eigenschaften erfinden, um all das auszudrücken, doch dann würde jedes Team sie anders erfinden, und die Konsistenz über Standorte hinweg, die Sie wollten, wäre genau das, was Sie verloren hätten. Diese Lücke ist der Grund, warum es IMDF gibt.
IMDF: wie es Standorte, Ebenen, Einheiten und Points of Interest strukturiert
IMDF, das Indoor Mapping Data Format, wurde von Apple entwickelt und wird von Apple als veröffentlichte Spezifikation getragen, und es wurde vom Open Geospatial Consortium als Community Standard übernommen. Seine zentrale Designentscheidung ist, dass es auf GeoJSON aufbaut. Ein IMDF-Datensatz ist eine Reihe von GeoJSON-FeatureCollections, sodass alles, was GeoJSON bereits lesen kann, den halben Weg zum Lesen von IMDF zurückgelegt hat.
Was IMDF hinzufügt, ist ein definiertes Vokabular von Feature-Typen, das um einen Standort herum organisiert ist. Statt Ihnen zu überlassen, Eigenschaftsnamen zu erfinden, gibt es die Kategorien vor, aus denen ein Gebäude besteht, und wie sie ineinander verschachtelt sind. Grob gesagt beschreibt ein IMDF-Datensatz:
- Standort und Gebäude. Das Gelände als Ganzes und die physischen Bauwerke darauf.
- Ebene. Jede Etage mit ihrer Ordinalzahl, damit die Software die Stapelreihenfolge kennt.
- Einheit. Die einzelnen Räume auf einer Ebene, etwa ein Laden, ein Zimmer oder ein Gehweg.
- Öffnung. Die Verbindungen zwischen Einheiten, etwa Türen und Durchgänge.
- Ausstattung und Point of Interest. Die benannten Ziele, nach denen ein Besucher sucht.
Weil diese Typen und ihre Beziehungen durch die Spezifikation festgelegt sind, sieht eine nach IMDF exportierte Karte eines Standorts strukturell aus wie die Karte eines beliebigen anderen. Genau diese Eigenschaft braucht ein Mehrgebäude-Programm: Eine Routing-Engine kann davon ausgehen, dass sie immer Ebenen mit Ordinalzahlen, beschriftbare Einheiten und als Verbindungen behandelbare Öffnungen findet, ohne jeden Standort gesondert behandeln zu müssen. Die Bindung von IMDF an GeoJSON ist auch der Grund, warum es sich in Pipelines einfügt, die bereits geografisches JSON verarbeiten.
IndoorGML: Modellierung von Raum plus Routing-Netzwerkgraph
IndoorGML ist ein Standard des Open Geospatial Consortium, der das Problem aus einer anderen Richtung angeht. Wo IMDF auf GeoJSON aufbauendes JSON ist, wird IndoorGML in GML ausgedrückt, der XML-basierten Geography Markup Language des OGC, und sein Schwerpunkt liegt nicht nur auf den Formen des Raums, sondern auf der Konnektivität zwischen Räumen.
Die charakteristische Idee in IndoorGML ist eine duale Darstellung. Auf der einen Seite beschreibt es den zellulären Raum: die Räume, Korridore und anderen begrenzten Bereiche eines Gebäudes. Auf der anderen leitet es einen Knoten-Beziehungs-Graphen ab, in dem jeder Raum zu einem Knoten wird und jede Verbindung zwischen benachbarten Räumen zu einer Kante. Genau diesen Graphen braucht ein Routing-Algorithmus. Um einen Weg von einem Raum auf einer Etage zu einem Ausgang auf einer anderen zu berechnen, durchläuft eine Engine einen Graphen aus Knoten und Kanten, statt direkt über Polygone zu argumentieren, und IndoorGML macht diesen Graphen zu einem erstklassigen Bestandteil des Standards, statt zu etwas, das jeder Hersteller neu aufbaut.
IndoorGML wurde vom OGC über mehr als eine Revision hinweg gepflegt, sodass ein Team, das sich darauf standardisiert, die aktuelle Version im eigenen Register des OGC bestätigen sollte, statt eine feste Nummer anzunehmen. Die Designabsicht ist über die Versionen hinweg konsistent: den Innenraum zu modellieren und daneben das Navigationsnetzwerk, von dem das Routing abhängt. Das macht IndoorGML zum natürlichen Referenzpunkt, wenn der Routing-Graph selbst die Priorität ist.
Vergleich der Standards
Die drei Standards lassen sich am leichtesten nebeneinander im Kopf behalten. Die folgende Tabelle fasst zusammen, wofür jeder da ist und wie sie zueinander stehen.
| Standard | Was es ist | Basisformat | Routing- / Netzwerkunterstützung | Verwalter | Typische Verwendung |
|---|---|---|---|---|---|
| GeoJSON | Allzweck-Kodierung für geografische Daten | JSON (eigenes Format) | Keine eingebaut; nur Geometrie | IETF (RFC 7946) | Reine Indoor-Geometrie; die Basis, auf der andere Formate aufbauen |
| IMDF | Standortstrukturiertes Indoor-Kartenformat | GeoJSON | Konnektivität über Öffnungen; kein expliziter Graph-Standard | Apple; als OGC Community Standard übernommen | Portable, konsistente Standortbeschreibung über viele Gebäude hinweg |
| IndoorGML | Indoor-Raummodell mit explizitem Netzwerkgraphen | GML (XML) | Knoten-Beziehungs-Graph als erstklassiges Konzept | Open Geospatial Consortium | Routing-zentrierte Anwendungen, bei denen der Navigationsgraph die Priorität ist |
Das Muster ist über die Zeilen hinweg klar. GeoJSON liefert Ihnen die Formen. IMDF fügt eine feste Standortstruktur hinzu, die über Standorte hinweg konsistent bleibt. IndoorGML fügt einen expliziten Routing-Graphen hinzu. Keiner von ihnen sagt Ihnen für sich genommen, wo ein Besucher gerade steht. Das ist eine eigene Ebene, und darauf kommt diese Referenz immer wieder zurück.
Von CAD und BIM zu einer Standard-Indoor-Karte
Fast keine Indoor-Karte beginnt ihr Leben in einem dieser Standards. Sie beginnt als architektonische Zeichnung: Das Gebäude wurde in CAD entworfen oder in BIM modelliert, und die Standard-Indoor-Karte wird aus dieser Quelle abgeleitet.
CAD-Dateien beschreiben ein Gebäude für Bau und Dokumentation. Sie sind reich an Linienwerk und Ebenen, waren aber nie dafür gedacht, navigierbare Bedeutung auszudrücken: Eine CAD-Ebene weiß, dass sie Wände enthält, nicht dass ein bestimmter Raum eine Ladeneinheit ist, zu der ein Besucher geführt werden kann. BIM geht weiter und trägt strukturierte Objekte und Attribute statt bloßer Geometrie, sodass mehr von der Bedeutung, die eine Karte braucht, bereits im Modell vorhanden ist.
Die Konvertierung tut zwei Dinge. Sie vereinfacht die Quelle auf das, was Navigation und Analytik tatsächlich benötigen, und verwirft Baudetails, die in einer Wegeführungskarte keinen Platz haben. Und sie bildet die verbleibenden Elemente auf das Vokabular des Zielstandards ab, sodass aus einem modellierten Raum eine IMDF-Einheit oder ein IndoorGML-Raum wird, aus einer Tür eine Öffnung oder eine Kante, und jede Ebene mit ihrer Ordinalzahl versehen wird. Dieser Übersetzungsschritt ist Gegenstand der vollständigen Anleitung von BIM zur Wegeführungskarte, und wie sich diese flache Beschreibung in ein dimensionales, mehrstufiges Modell verwandelt, behandelt Aufbau einer 3D-Indoor-Karte.
Das Ergebnis in einem Standard statt in einem maßgeschneiderten Export abzulegen, kommt auf Konsistenz zurück. Wenn die Karte jedes Standorts dasselbe Vokabular verwendet, kümmern sich die nachgelagerten Werkzeuge nicht mehr darum, welches Gebäude sie gerade betrachten: Ein Verzeichnis, eine Routing-Engine und eine Analytik-Ebene können jeweils einmal gebaut und auf jeden Standort gerichtet werden. Verzichten Sie auf den Standard, bauen Sie diese Integration für jeden Standort neu auf. Dazu, wie diese Karten in einem Navigationssystem sitzen, siehe wie Indoor-Wegeführung funktioniert.
Warum Standards für Positionierung und Analytik über mehrere Standorte hinweg wichtig sind
Eine Standard-Indoor-Karte beschreibt, wo sich die Wände, Einheiten, Ebenen und Ziele befinden. Sie verortet für sich genommen keine Person auf dieser Karte. Ein Navigations- oder Analytiksystem braucht beides: die Karte für das Gebäude und eine Positionierungsebene, um einen Besucher in Echtzeit darauf zu platzieren, eine gesonderte Technologieentscheidung, die in die Positionierungsebene, die die Karte nutzt betrachtet wird.
Für ein Programm, das über viele Standorte hinweg läuft, machen Standardkarten die Positionierungs- und Analytik-Ebene weitaus einfacher zu betreiben. Wenn die Karte jedes Gebäudes dieselbe Struktur teilt, kann die Ebene, die Besucher platziert und Bewegung misst, einmal konfiguriert und wiederverwendet werden, statt pro Standort neu entwickelt zu werden. Konsistente Karten machen auch die Ergebnisse vergleichbar: Eine gegen eine IMDF-Einheit gemessene Zählung bedeutet in einem Standort dasselbe wie in einem anderen, was einem Team erlaubt, über ein Portfolio hinweg zu vergleichen, statt jedes Gebäude isoliert zu lesen. Dieselbe Logik gilt für das Platzieren von Points of Interest in den Kartendaten selbst.
Ariadne sitzt auf der Positionierungs- und Analytikseite dieser Aufteilung. Es nutzt Standard-Indoor-Karten unter seiner Positionierungsebene; es definiert diese Standards nicht und liefert keine Suite zur Kartenerstellung. Die Karte beschreibt das Gebäude; Ariadne platziert Bewegung darauf.
Ariadne misst dies mit Hybrid Fusion, der patentierten kamerafreien Methode. Time-of-Flight-Tiefensensorik zählt an den Eingängen jeden Besucher und erfasst Geometrie statt Bilder, während die patentierte Signalerfassung die Bewegung im Innenraum verfolgt und die Signale erkennt, die ein Telefon aussendet, selbst im Flugmodus, und diese Bewegung auf etwa einen Meter genau auflöst. Der Sensor streamt beide Datenströme an Ariadne, wo Hybrid Fusion sie zu einer Trajektorie pro Besuch zusammenführt und Zählwerte, Verweildauer und Wege berechnet. Die Datenströme tragen keine Identifikatoren: keine MAC-Adresse, keine Geräte-ID, keine biometrischen Daten, und es ist keine Kamera beteiligt. Identifikatoren werden nur gespeichert, wenn ein Besucher ausdrücklich zustimmt, was die Methode datenschutzfreundlich und außerhalb des biometrischen Bereichs hält.
Deshalb ist das Kartenformat eine echte Entscheidung, keine Formalität. Halten Sie die Karte über Standorte hinweg konsistent, und die Positionierungsebene skaliert; lassen Sie jeden Standort in sein eigenes Format abdriften, und jede Messung wird zu einem Sonderfall. Um die Positionierungsseite als Produkt zu sehen, siehe Ariadne Indoor-Navigation.
FAQ
Was ist der Unterschied zwischen IMDF und GeoJSON?
GeoJSON ist ein Allzweck-Format zur Kodierung geografischer Geometrie in JSON, von der IETF als RFC 7946 veröffentlicht. IMDF baut auf GeoJSON auf, fügt aber ein festes Vokabular von Feature-Typen für Standort, Ebene, Einheit, Öffnung und Point of Interest hinzu, sodass Indoor-Karten über Standorte hinweg strukturell konsistent bleiben. Kurz gesagt ist IMDF eine Indoor-Struktur, die auf der GeoJSON-Kodierung aufbaut.
Ist IMDF ein offener Standard?
IMDF wurde von Apple entwickelt und wird von Apple als veröffentlichte Spezifikation getragen, und es wurde vom Open Geospatial Consortium als Community Standard übernommen. Es baut auf der offenen GeoJSON-Kodierung auf, was bedeutet, dass Werkzeuge, die GeoJSON bereits lesen, beim Lesen von IMDF einen Vorsprung haben.
Wofür wird IndoorGML verwendet?
IndoorGML ist ein Standard des Open Geospatial Consortium, der den Innenraum und daneben einen Knoten-Beziehungs-Graphen modelliert, wie Räume verbunden sind. Diesen Graphen durchläuft eine Routing-Engine, um einen Weg zu berechnen, was IndoorGML zum Referenzpunkt macht, wenn das Navigationsnetzwerk selbst die Priorität ist.
Sagt Ihnen eine Standard-Indoor-Karte, wo sich Besucher befinden?
Nein. Eine Standardkarte beschreibt das Gebäude, einschließlich seiner Etagen, Einheiten und Ziele. Einen Besucher in Echtzeit auf dieser Karte zu verorten, ist eine gesonderte Positionierungsebene. Ein Navigations- oder Analytiksystem braucht beides: die Karte für die Struktur und die Positionierungsebene für den Live-Standort.
Erfordert das Verorten von Besuchern auf einer Indoor-Karte Kameras?
Nein. Ariadne zählt mit Hybrid Fusion: Time-of-Flight-Tiefenmessung plus patentierter Mobilfunksignal-Erfassung, niemals Kameras. Time-of-Flight erfasst Geometrie statt Bilder, und die Signalerfassung erfasst standardmäßig keine MAC-Adresse, sodass die Messung kein Video, keine Gesichter und keine biometrischen Daten umfasst.
