Webbrowserbasierte Indoor-Navigation für mobile Endgeräte auf Basis der OpenStreetMap

FAKULTÄT FÜR INFORMATIK DER TECHNISCHEN UNIVERSITÄT MÜNCHEN Bachelorarbeit in Informatik Webbrowserbasierte Indoor-Navigation für mobile Endgeräte auf Basis der OpenStreetMap Andreas Hubel

FAKULTÄT FÜR INFORMATIK DER TECHNISCHEN UNIVERSITÄT MÜNCHEN Bachelorarbeit in Informatik Webbrowserbasierte Indoor-Navigation für mobile Endgeräte auf Basis der OpenStreetMap Webbrowser based indoor navigation for mobile devices based on OpenStreetMap Autor: Andreas Hubel Themensteller: Prof. Dr. Uwe Baumgarten Betreuer: Dipl.-Ing. (Univ.) B.Sc. Christoph Söllner Datum: 15. November 2011

Ich versichere, dass ich diese Bachelorarbeit selbständig verfasst und nur die angegebenen Quellen und Hilfsmittel verwendet habe. München, den 15. November 2011 Andreas Hubel

Abstract Durch die Verbreitung von Smartphones mit Funktionen wie WLAN, GPS und Beschleunigungssensoren wird Indoor Navigation wird immer mehr für die breite Masse zum Thema. Andere Projekte setzen ihren Fokus oft rein auf die Lokalisierung, wodurch das entstehende Datenmodell nur ein Abfallprodukt ist. Die entstehen Prototypen funktionieren im schlimmsten Fall nur für den betrachteten Anwendungsfall, nur innerhalb des betrachteten Gebäudes und nur mit der ausgewählten Spezial-Hardware. Im Rahmen dieser Arbeit wurde deswegen eine Web-Anwendung entwickelt, die Indoor- Navigation auf Basis des Daten des OpenStreetMap Projekts demonstriert und in den Webbrowsern aktueller Smartphones läuft. Die Routenberechung und Kartendarstellung wird direkt auf dem Gerät in JavaScript durchgeführt. Insbesondere wird eine Lösung zur Darstellung von unterschiedlichen Stockwerken auf einer 2D Karte aufgezeigt. Da noch kein Schema für Indoor-Daten in OpenStreetMap definiert war, wurde ein Vorschlag entwickelt und Teile eines Gebäudes darin umgesetzt. By the distribution of smart phones with features like Wi-Fi, GPS and accelerometers indoor navigation is increasingly becoming a topic for the masses. Other projects often set their focus purely on location, so the resulting data model is often only a waste product. The resulting prototypes work in the worst case only for the considered application, only within the considered building and looked only on the selected special-purpose hardware. In this work, a web application was designed, which demonstrates indoor navigation based on data from the OpenStreetMap project and runs in current smartphone web browsers. The route calculation and map rendering is performed directly on the device via JavaScript. In particular, a solution is shown to represent different levels on a 2D map. As there was no schema for indoor data in OpenStreetMap defined yet, a proposal was developed and parts of a building were implemented in it. vii

viii

Inhaltsverzeichnis Abstract vii 1 Einführung 1 2 Ausgangssituation 3 2.1 Technik........................................ 3 2.1.1 Datenbanken................................ 3 2.1.2 Renderer................................... 3 2.1.3 Routing................................... 6 2.1.4 HTML5................................... 9 2.1.5 Slippy Map Frameworks.......................... 10 2.2 Datenformate.................................... 11 2.2.1 Anforderungen............................... 11 2.2.2 Drawing Interchange Format (DXF)................... 12 2.2.3 Industry Foundation Classes (IFC).................... 13 2.2.4 Geography Markup Language (GML).................. 14 2.2.5 OSM XML.................................. 16 2.3 OpenStreetMap................................... 16 2.3.1 OSM Datenmodell............................. 17 2.3.2 Editoren................................... 19 2.3.3 Schnittstellen................................ 20 2.3.4 Aufbau OSM Serverinfrastruktur..................... 24 2.4 Related work..................................... 26 2.4.1 University of Salford............................ 26 2.4.2 Geopard................................... 28 2.4.3 Leadme................................... 29 2.5 Zwischen-Fazit................................... 29 3 Implementierung 31 3.1 Datenmodell..................................... 31 3.1.1 Stockwerk/Höhe/Z-Koordinate..................... 31 3.1.2 Räume.................................... 32 3.1.3 Wege, Gänge und Treppen......................... 33 3.1.4 Relationen.................................. 33 3.2 Datenerfassung................................... 34 3.3 Anwendung..................................... 37 3.3.1 Anzeige/Rendering (orange)....................... 38 3.3.2 Routing und Suche (blau)......................... 39 3.3.3 Web-App.................................. 40 ix

Inhaltsverzeichnis 4 Zusammenfassung und Ausblick 45 4.1 Zusammenfassung................................. 45 4.2 Fazit.......................................... 45 4.3 Ausblick....................................... 46 Literaturverzeichnis 49 x

1 Einführung Inzwischen gehören Navigationsgeräte im Auto schon fast zur Standardausrüstung. Es gibt viele unterschiedliche Implementationen: von werkseitig fest eingebauten Geräten über Navis aus dem Supermarkt zu entsprechenden Anwendungen für Smartphones. Die heutigen Geräte führen den Nutzer vom aktuellen Standort zur gewünschten Zieladresse. Bei großen Gebäuden wäre eine detaillierte Navigation, möglicherweise bis zum gesuchten Raum, durchaus sinnvoll. Verwendet der Nutzer zum Autofahren eine Navigationsanwendung auf seinem Smartphone, könnte er dieses auf Parkplatz aus der Halterung entnehmen, um als Fußgänger zum entsprechenden Raum im Gebäude geführt zu werden. Wünschenswert wäre dabei eine Plattform unabhängige Anwendung, die im Zweifelsfall auch ohne Verbindung zum Internet also offline funktioniert. Dazu ist es notwendig trotz der begrenzten Ressourcen auf einem mobilen Gerät die entsprechenden Daten offline vorzuhalten und die Routenberechnung lokal im Gerät durchzuführen. Um nicht zu viel Speicherplatz zu verschwenden, sollte die Darstellung der Karte bei Bedarf generiert werden. Ziel dieser Arbeit ist somit ein Proof of concept einer plattformunabhänigen, offlinefähigen Indoor Navigationsanwendung auf einem mobilen Gerät. In Kapitel 2 werden zunächst bestehende Techniken, Datenmodelle und Projekte untersucht. Die Plattformunabhänigkeit der Anwendung wird über die Implementation als Web Applikation gewährleistet. Als Datenbasis zur Darstellung und Navigation wird auf das OpenStreetMap (OSM) Projekt gesetzt, das deswegen in diesem Kapitel vorgestellt wird. In Kapitel 3 wird in die Implementierung übergegangen. Es muss zunächst ein Schema für Indoor-Daten in OSM entwickelt werden, um dann einen Beispiel-Datensatz darin umzusetzen. Als Testgebiet wurde das Gebäude der Fakultäten für Mathematik und Informatik der TU München gewählt. Mit diesen Testdaten kann die Applikation unter Anwendung einer Auswahl der in Kapitel 2 vorgestellten Techniken umgesetzt werden. Abschließend wird das Ergebnis dieser Arbeit in Kapitel 4 zusammengefasst, ein Fazit gezogen und auf mögliche Verbesserungsansätze eingegangen. 1

1 Einführung 2

2 Ausgangssituation Zunächst möchte ich die bisherige Situation darstellen. Vorgestellt werden verschiedeneste Software, bestehende Dateiformate und das OpenStreetMap Projekt. Danach folgen verschiedenen Projekte mit ähnlichen Zielsetzungen, um das Kapitel schließlich mit einem Zwischenfazit abzuschließen. 2.1 Technik Im Abschnitt Technik beschäftigen wir uns zunächst mit der Datenhaltung und deren Darstellung, um dann darauf aufsetzende Routing-Software zu begutachten. Im Anschluss stelle ich dann noch einige Webframeworks vor, die schließlich als Interface gegenüber dem Nutzer agieren. 2.1.1 Datenbanken Um mit Geodaten effizient zu arbeiten gibt es speziell optimierte Datenbanken. Neben klassischen Datentypen wie Integer und Text werden auch Koordinaten, Linen und Flächen nativ angeboten. Zur effizienten Abfrage verfügen Geodatenbanken über räumliche Indexstrukturen wie R-Bäume. Außerdem lassen sich räumliche Abfragen wie liegt Punkt A in Fläche B oder schneidet Fläche B die Fläche C mit Hilfe zusätzlicher Funkionen bereits in der der Datenbank durchführen. Frei verfügbare Implementationen sind z.b. die PostGIS Erweiterungen für PostgresQL oder SpatiaLite auf Basis von SQLite. Für Daten ohne festes Schema eigenen sich Key Value Stores eher als klassische relationale Datenbanken. Es existieren auch Mischformen: Für PostgresQL stellt die hstore Erweiterung einen entsprechenden Datentyp zur Verfügung. 2.1.2 Renderer Den Prozess Rohdaten in eine grafische Darstellung umzuwandeln bezeichnet man als Rendern. Bei Moderne Renderern lässt sich die Darstellung durch sogenannte Stylefiles konfigurieren. Nachfolgend werden mehrere Renderer vorgestellt: Mapnik, Osmarender und Kothic JS. Letzterer kann auf Grund der Implementierung in JavaScript direkt im Web-Browser zum Einsatz kommen. Mapnik Mapnik ist eine C++ Bibliothek, die zum Zeichnen der einzelnen Kacheln wiederum auf die 2D Grafik Bibliothek Anti-Grain Geometry (AGG) setzt und neben ESRI Shapefiles, 3

2 Ausgangssituation PostGIS Datenbanken, TIFF Raster Dateien auch OSM-XML verarbeiten kann. Aus Performancegründen wird in den meisten Fällen allerdings auf PostGIS Datenbanken gesetzt. [24] 1 <?xml version="1.0" encoding="utf-8"?> 2 <!DOCTYPE Map [ 3 <!ENTITY % entities SYSTEM "/usr/share/osm-mapnik/inc/entities.xml.inc"> 4 %entities; 5 ]> 6 7 <Map bgcolor="transparent" srs="&srs900913;" minimum_version="0.6.1"> 8 &fontset-settings; 9 10 <Layer name="rooms" status="on" srs="&osm2pgsql_projection;"> 11 <StyleName>rooms</StyleName> 12 <Datasource> 13 <Parameter name="table"> 14 (SELECT room, name, way FROM &prefix;_polygon WHERE room is not null and level = 1 ) AS t 15 </Parameter> 16 &datasource-settings;</datasource> 17 </Layer> 18 19 <Style name="rooms"> 20 <Rule> 21 <LineSymbolizer> 22 <CssParameter name="stroke">#888</cssparameter> 23 <CssParameter name="stroke-width">0.5</cssparameter> 24 </LineSymbolizer> 25 <TextSymbolizer name="name" fontset_name="book-fonts" size="11" fill ="#000" halo_radius="1" wrap_width="20" wrap_character=";" min_distance="2" /> 26 </Rule> 27 </Style> 28 </Map> Listing 2.1: Beispiel für ein einfaches Mapnik Stylesheet zur Darstellung von Räumen Im Beispiel wird zunächst ein neuer Layer erstellt. Die dazu benötigten Daten werden mittels SQL Query direkt aus einer PostGIS Datenbank geholt. Auf einen Layer können ein oder mehrere Styles angewendet werden. Diese Styles bestehen wiederum aus einzelnen Regeln, die ein oder mehrere Symbolizer auf ein Objekt anwenden. Ein LineSymboliser zeichnet am Rand des Objekts eine Line mit den gewählten Parametern, ein TextSymbolizer versieht das Element mit einem Schriftzug. Dabei ist der TextSymbolizer so intelligent, dass er die Schrift bei einer Fläche (polygon) in der Mitte platziert und bei einer Straße (line) entlang der Linie führt. Osmarender Bei Osmarender wurde dagegen ein anderer Weg gewählt: Mittels eines XSLT-Stylesheets wird ein OSM-XML Planet Auszug in SVG (Scalable Vector Graphics, W3C Standard zur Beschreibung zweidimensionaler Vektorgrafiken) transformiert. Die Transformation in ei- 4

2.1 Technik ne Bitmap Grafik erfolgt dann über die Kommandozeilen-Version von Inkscape. Kothic JS Kothic JS basiert wiederum auf einem ganz anderem Ansatz. Die Daten werden aus einer PostGIS Datenbank als GeoJSON [28] abgerufen und dann im Browser in ein Canvas Element gezeichnet. Das Datenbank Schema entspricht dabei dem selben wie bei Mapnik. Zwischen Browser und Webserver werden allerdings keine Bitmaps, sondern an die aktuelle Zoomstufe angepasste Vektordaten ausgetauscht. Eine Antwort folgt folgendem Schema: 1 onkothicdataresponse({"features":[ features list ], "bbox":[ EPSG:4326 bounding box ], "granularity": granularity }, zoom, tile-x, tile_y ) features list enthält die einzelnen Merkmale als JSON Objekte nach GeoJSON Definition: 1 {"reprpoint":[5388,5976],"type":"polygon","properties":{"landuse":"residential ","name":"am Berg"},"coordinates" :[[[5380,5975],[5383,5985],[5397,5979],[5391,5968],[5380,5975]]]} Alle Koordinaten der Merkmale sind Spherical Mercator integers. Um Transportkapazität und Speicherplatz zu sparen, werden sie relativ zu den Abfragegrenzen angegeben. [0,0] repräsentiert die linke, untere Ecke und [granularity, granularity] die obere, rechte Ecke. Polygone enthalten zusätzlich im Feld reprpoint die Koordinaten eines repräsentativen Punktes der sich zur Platzierung von Text oder einem Symbol anbietet. [22] Diese Antwort wird im Webbrowser per JavaScript interpretiert und auf ein Canvas Element gezeichnet. Auch hier kommt ein Stylesheet wie in Listing 2.1.2 zum Einsatz. 1 (function (MapCSS) { 2 use strict ; 3 4 function restyle(style, tags, zoom, type, selector) { 5 var s_default = {}, s_centerline = {}, s_ticks = {}, s_label = {}; 6 7 if ((selector == canvas )) { 8 s_default[ fill-color ] = #C4D4F5 ; 9 } 10 11 if (((selector == area && tags[ natural ] == coastline ))) { 12 s_default[ fill-color ] = #fcf8e4 ; 13 s_default[ -x-mapnik-layer ] = bottom ; 14 } 15 16 if (((selector == area && tags[ natural ] == glacier ) && zoom >= 3)) { 17 s_default[ fill-color ] = #fcfeff ; 5

2 Ausgangssituation 18 s_default[ fill-image ] = glacier.png ; 19 } 20 21 if (((selector == area && tags[ place ] == city ) && zoom >= 10) ((selector == area && tags[ place ] == town ) && zoom >= 10)) { 22 s_default[ fill-color ] = #FAF7F7 ; 23 s_default[ fill-opacity ] = 0.6; 24 s_default[ z-index ] = 1; 25 } Allerdings wird dieses in der Regel nicht per Hand geschrieben, sondern aus einem MapCSS Stylesheet generiert. Eine Instanz zur Demonstration wird von den Autoren unter http://kothic.org/ js/ betrieben. Dort kann das Rendering-Ergebnis direkt mit der Ausgabe von Mapnik verglichen werden. MapCSS Mit dem Aufkommen von immer mehr verschiedenen Renderern wuchs auch das Bedürfnis nach einer einheitlichen Stil-Beschreibungssprache. Dies führte zur Definition von Map- CSS. Wie der Namensteil CSS andeutet basiert es auf den Cascading Style Sheets des W3C. Das obige Beispiel-Stylesheet für Mapnik entspricht ungefähr folgender Notation in MapCSS: 1 area[room][level=1] { 2 color: #888; 3 width: 0.5; 4 5 text: name; 6 font-size:11; 7 font-family: DejaVu Sans Book; 8 text-color: #000; 9 text-halo-radius: 1; 10 text-halo-color: #ffffff; 11 text-allow-overlap: false; 12 text-placement:any; 13 max-width:20; 14 } Zur Zeit (September 2011) liegt MapCSS in Version 0.2 vor und wird bereits von 8 verschiedenen Render-Programmen unterstützt. Allerdings weicht die Prozentzahl der unterstützten MapCSS Features von Implementation zu Implementation stark voneinander ab [16]. Inzwischen existieren auch Werkzeuge um aus einer MapCSS Datei ein Stylesheet für Mapnik zu generieren [1]. 2.1.3 Routing Der Begriff Routing bezeichnet die Wegfindung in einem Wegenetz. Im Vergleich zum Rendering wird hier ein Graphen-Modell benötigt. 6

2.1 Technik Um den besten Pfad zu finden werden in der Regel Varianten von Dijkstra, A* oder Contraction Hierarchies benutzt. [47] Im OSM Umfeld gibt es viele verschiedene Ansätze zum Thema Routing. Im Wiki sind über 25 verschiedene Projekte aufgeführt [23]. Da das Ziel dieser Arbeit eine Web-Anwendung ist, werden nur die Projekte betrachtet, die bereits ein Webinterface anbieten. Vier Dienste wurden näher auf ihre Tauglichkeit zur Indoor Navigation untersucht: Open Source Routing Machine (OSRM) Gosmore/Osm.org Routing Demo OpenRouteService.org Cloudmade Routing OSRM und Gosmore sind Open Source Projekte, von Cloudmade Routing und Open- RouteService ist der Quelltext dagegen nicht verfügbar. Es zeigte sich das bis auf OSRM alle einen Weg für die Teststrecke fanden, allerdings ist das Interface jeweils nicht für verschiedene Stockwerke ausgelegt. So lässt sich nicht auswählen ob der Nutzer nun den Raum im 2. oder im 3. Stock als Ziel festlegen möchte, wenn diese an den selben Koordinaten platziert sind. OSRM benötigt für jedes Profil (Auto, Rad, Fußgänger) einen eigenen Graphen, da die unterschiedlichen Geschwindigkeiten direkt in die Kantengewichte mit einfließt. Die Probleme im Test begründen lassen sich darauf zurückführen, dass die verwendete Demo- Installation nur mit einem Graphen für Autos ausgestattet ist. Abbildung 2.1: OpenRouteService.org 7

2 Ausgangssituation Abbildung 2.2: Open Source Routing Machine (OSRM) Abbildung 2.3: Gosmore/Osm.org Routing Demo 8

2.1 Technik Abbildung 2.4: Cloudmade Routing 2.1.4 HTML5 Unter HTML5 werden im Allgemeinen neue Entwicklungen im Web-Umfeld verstanden. Mit diesen Neuerungen wird es möglich, Anwendungen, die bisher nur nativ in der Umgebung des jeweiligen Betriebssystems umsetzbar waren, für Webbrowser zu implementieren. Somit steht einigermaßen einheitliche Plattform zur Verfügung, mit der sich weites Feld an Geräten abgedeckt wird. Das Entwickeln von eigenständigen Anwendungen für jedes (Smartphone-)Betriebssystem entfällt somit. Es gibt zwei Spezifikationen: Den versionslosen HTML-Standard der Web Hypertext Application Technology Working Group (WHATWG) und den noch nicht offiziell verabschiedeten HTML5-Standard des World Wide Web Consortium (W3C). Hauptautor bzw. Editor ist jeweils Ian Hickson. Ziel des W3C ist es eine stabile Momentaufnahme der Spezifikation unter dem Namen HTML5 zu publizieren, wohingegen die WHATWG am einem Living Standard, also einer Spezifikation, die einer ständigen Korrektur und Erweiterung unterliegt, arbeitet. Die Browserhersteller folgen in der Regel dem WHATWG- Entwurf. [2] Da für das Ziel der Arbeit nur die Offline-Nutzung, Darstellung und Positionsbestimmung relevant sind, werden die anderen Teilbereiche nicht betrachtet. Offline-Nutzung Um eine Webanwendung offline nutzen zu können, muss sowohl der Programmcode als auch die Daten auf dem Gerät gespeichert sein. Für den Programmcode und fixe Daten gibt es im HTML Standard nun die Möglichkeit über sogenanntes Cache Manifest für eine Liste von Dateien das Pufferverhalten festzulegen [32, Abschnitt 6.6] [31, Abschnitt 5.6]. Entscheidet sich ein Nutzer dafür eine Anwendung auf seinem Gerät auch offline nutzen zu wollen, kann dessen Browser alle dort aufgelisteten Dateien lokal speichern. 9

2 Ausgangssituation Für dynamische Daten gibt es andere Wege. Unter dynamischen Daten verstehe ich Daten, bei denen der Nutzer auswählen soll was genau gespeichert werden soll. Bei einer Webkarte sind das beispielsweise verschiedene Bereiche in verschiedensten Detailstufen. Dazu ist es notwendig, dass die Anwendung im Browser, über eine entsprechende API, Daten ablegen kann. Dem HTML-Standard wurde dazu die Erweiterung Web Storage beigefügt. [32, Kaptiel 12] Beim W3C wurde diese Erweiterung in ein eigenes Dokument ausgelagert [3] und ist somit nicht Teil des W3C HTML5-Standards. Es gab auch Ansätze wie die z.b. über die Web SQL Database API eine relationale Datenbank anzubieten. Da man sich allerdings nicht einig wurde, wurde die Arbeit an dem entsprechenden W3C Papier eingestellt [?]. Wie lange die bereits vorhandenen Implementationen in Apple Safari, Google Chrome und Opera verbleiben ist nicht absehbar. Darstellung Der in HTML neu eingeführte Canvas-Tag erlaubt 2D Grafiken direkt im Browser zu zeichnen. Dies ermöglicht Karten direkt im Browser rendern. [32, Abschnitt 4.8.11] [31, Abschnitt 4.8.11] Im Vergleich zu SVG wird es möglich auf einer niedrigeren Stufe mit dem Renderer des Browsers zu kommunizieren. Cascading Style Sheets ist eine Beschreibungssprache zur Darstellung von Webseiten. Mit Level 3 (CSS3) wurden die Spezifikation in einzelne Teile, sogenannte Module gesplittet. Bisher wurden erst die Module Selectors, Namespaces und Color offiziell verabschiedet. Interessant für unseren Anwendungsfall sind 2D Animations und Transitions, wodurch Änderungen der Zoomstufe in der Karte flüssiger wirken können. Positionsbestimmung Zur Positionsbestimmung wurde die Geolocation API eingeführt. Sie ist nicht Teil der HTML-Standards, sondern ein eigenständiger und offiziell verabschiedeter W3C Standard [39]. Dadurch wird es möglich die aktuelle Position des Nutzers (mit Fehler-Toleranz) per JavaScript abzufragen, um diese beispielsweise auf einer Karte darzustellen. Auch Turnby-Turn Navigationsanweisungen werden dadurch grundsätzlich möglich. 2.1.5 Slippy Map Frameworks Im Unterabschnitt 2.1.2 Renderer ist darauf eingegangen worden, wie rohe Geo-Daten in eine Karte überführt werden können. Wie wird dieses Bild nun dem Nutzer angezeigt? Lange zeit war es üblich den Renderer ein Bild für den kompletten Bildschirm berechnen zu lassen. Verschiebt der Nutzer die Ansicht etwas zur Seite, muss wiederum wieder der komplette Bildschirm neu berechnet werden. Erfolgt die Darstellung und das Rendern auf zwei unterschiedlichen Rechnern, wie z.b. bei einer klassischen Karte im Web, ergeben sich oft lästige Wartezeiten für den Nutzer. Google hat mit ihrem Produkt Maps ein neues Konzept verbreitet: Die gesamte Karte wird in kleinere Stücke sogenannte Tiles, zu deutsch Kacheln zerschnitten. Beim Nutzer werden die Tiles dann wieder richtig zusammengesetzt. Wird nun die Karte zur Seite verschoben, müssen nur die Kacheln am Rand vom Server angefordert werden. Durch die- 10

2.2 Datenformate se Fixierung auf feste Ausschnitte ist es auch möglich die einzelnen Kacheln zu puffern, um nicht bei jedem Aufruf neu rendern zu müssen. Eine Kachel hat eine Größe von 256x256 Pixel und stellt auf Zoomstufe 0 den ganzen Planeten dar. Auf Stufe eins sind es insgesamt 2 2 = 4 Kacheln, auf Zoomstufe zwei 4 4 = 16, etc. Abgerufen werden diese Kacheln über http://domain.tld/optionen/ zoom/x/y.png. [4] Für die Aufgabe des Zusammensetzens im Web-Browser gibt es gesonderte JavaScript Frameworks. Weitere Aufgaben für diese Frameworks sind die Bereitstellung des Userinterfaces wie Zoomen per Mausrad bzw. Schieberegler und Annotation der Karte z.b. mit Markern zur Kennzeichnung der gefundenen Orte. Näher betrachtet wurden hier die freien Frameworks OpenLayers, Leaflet und KHTML: OpenLayers ist sehr weit verbreitet und hat sehr viele zusätzliche Funktionen und wirkt wie ein Schweizer Taschenmesser, ist aber erst mit der neuesten Version auch mit Geräten mit Touch-Screen verwendbar. Leaflet ist eine leichtgewichtige Implementation eines Slippy Map Frameworks. Es wurde unteranderem für Geräte mit Touch-Screen ausgelegt und wird in der Demoinstallation von Kothic JS verwendet. KHTML ist ebenfalls eine Neuimplementation der Basisfunktionen von OpenLayers, mit dem Fokus auf schnellere Kartendarstellung. 2.2 Datenformate Bei der Betrachtung der Projekte, die sich mit dem Thema Indoor-Navigation beschäftigen viel auf, dass der Fokus selten auf dem Datenmodell an sich liegt. Dadurch entstehen Prototypen, die für genau einen Anwendungsfall funktionieren, aber dann auch nur dort nutzbar sind. Ein Ziel diese Arbeit ist es deswegen Software und Daten zu produzieren die allgemein verwendbar sind. Dazu ist es notwendig, dass die Daten in einem gut definierten Format vorliegen. Um das Rad dabei nicht neu zu erfinden, ist eine Analyse der bestehenden Formate notwendig. Hier beschränke ich mich auf die Formate DXF, IFC, GML und OSM-XML. Um die Modelle sinnvoll miteinander vergleichen zu können wurden folgende Anforderungen aufgestellt: 2.2.1 Anforderungen Zum einen muss das Model in der Lage sein alle relevanten Aspekte eines Gebäudes abzubilden und diese in einzelne Objekte zu gliedern. Diese Objekte sind an einem gewissen Ort bzw. haben eine gewisse Ausdehnung im Raum und stehen in Beziehung zu anderen Objekten. Es muss sowohl die Topologie (Wie kommt man von A nach B, welche Räume hängen wie zusammen) als auch die Geometrie (welche Form hat der Raum) abgebildet werden können. Die Topologie bzw. ein sich daraus abgeleiteter Weggraph ist für Routing- Anwendungen unerlässlich. Um die Route dem Nutzer aber wiederum verständlich darstellen zu können, ist auch ein visueller Gebäudeplan notwendig. 11

2 Ausgangssituation Ein Anwender oder Entwickler, der Anwendungen mit dem Modell umsetzen möchte, soll sich nicht lange in das Modell einarbeiten müssen, sondern sofort mit dem Eintragen der Daten oder der Implementierung der Software starten können. Dies impliziert, dass auf bestehende Standards wie XML gesetzt wird. Für viele Probleme bestehen in XML bereits Lösungen, wie z. B. XSLT zur Transformation in andere Darstellungen oder XPath zur Adressierung bzw. Filterung. Das System muss mit regelmäßigen Änderungen (Bau von neuen Gebäuden, Unterteilung von Räumen) umgehen können und diese auch in angemessener Zeit an daran angeschlossene Systeme weitergeben können. Dazu ist es notwendig, dass jedes Objekt eine Versionsnummer enthält. Nur so ist ein sinnvoller Vergleich zwischen einzelnen Revisionen eines Objekts möglich. Negativbeispiel aus dem Straßenverkehr: Bis ein neuer Kreisverkehr im Auto Navigationsgerät landet, können schon einmal 2 Jahre vergehen. Der Umbau muss erst vom Datenlieferanten erfasst und an die Navigationsgerätehersteller weitergegeben werden, die diese dann wiederum jährlich auf CD/DVD an den Endnutzer verkaufen, der diese dann wiederum auf seinem Gerät einspielen muss [40]. Das zeitnahe Abbilden von Baustellen ist deswegen gar nicht denkbar. Die Motivation ein System zu nutzen wird erhöht, wenn die Anwender das Ergebnis ihre Arbeit zeitnah betrachten und nutzen können. Die Daten sollen deswegen einfach einsehbar und erforschbar sein. Wünschenswert wäre eine entsprechende Webapplikation nach dem HTML5 Standard. Um flexibel und spontan auf neue Anforderungen reagieren zu können, muss es möglich sein beliebig viele neue Attribute an Objekte zu hängen (sogenanntes Freies Tagging ) bzw. allgemein das Modell problemlos erweitern zu können. Diese Daten müssen strukturiert in Dateien oder besser einer Datenbank abgelegt sein. Sie sollten via standardisiertem Netzwerkprotokoll (vorzugsweise via HTTP) global via Uniform Resource Identifier (URI) adressierbar und zugänglich sein. Es muss definierte Wege (Schnittstellen) geben, wie man an die Daten bzw. Teile davon kommt. So macht es wenig Sinn, wenn man die Fläche eines einzigen Raumes in Erfahrung bringen will, erst das komplette Gebäude in den Arbeitsspeicher des Rechners bzw. des Mobilgeräts zu laden. Ein weiteres Beispiel für eine gefilterte Anfrage: Alle Kopierer im Gebäude X. Das Modell sollte in andere Modelle ohne all zu großen Aufwand transformierbar sein. Diese Anforderung kann mit Hilfe eines bestehenden Konverters oder durch die Anwendbarkeit eines XSLT-Stylesheets erfüllt werden. Diese Anforderungen werden nun an den oben aufgezählten Modellen und deren Umfeld angelegt: 2.2.2 Drawing Interchange Format (DXF) DXF ist das Datenformat, das heutzutage den Quasi-Standard zum Programm übergreifenden Datenaustausch darstellt. Die Spezifikation [26] und Dokumentation wird von der Firma Autodesk gepflegt und kostenfrei zur Verfügung gestellt. Es ist ein ASCII Format, basiert auf wenigen Primitiven wie (nicht vollständig) Punkt, Linie, Kreisbogen und Text. In neueren Versionen können einzelne Objekte zu Blöcken zusammengefasst werden. Es lässt sich durch den einfachen Aufbau und die vorhandene Dokumentation gut mit eigenen Programmen verarbeiten, allerdings gehen beim Export 12

2.2 Datenformate aus dem CAD Programm viele Informationen verloren. Es ist sozusagen nur der kleinste gemeinsame Nenner vieler CAD-Programme. Die konkrete Bedeutung und Zusammengehörigkeit der einzelnen Linien lässt sich fast nur noch erraten, bzw. von den Farben der Form und den nicht standardisierten Namen der einzelnen Layer ableiten. Topologische Informationen sind wenn überhaupt nur als Linien in einem Fluchtweg Layer enthalten. Den Namen, Nummer und Nutzungsart des Raumes kann man ebenfalls nur Ableiten, wenn man einen Text sucht der sich innerhalb einiger Linien, die den Raum darstellen sollen, befindet. Erfahrungen in früheren Projekten [15] und eine Analyse des TUM Roomfinder [5] zeigen, dass bei DXF basierten Rauminformationssystemen oft mit zusätzlichen externen Datenbanken gearbeitet wird, in denen die Informationen strukturiert abgelegt sind. Versionierung ist nur manuell über Dateinamen o.ä. möglich, als Web-Visualisierung sind beispielsweise Flash-Applikationen wie AutoCad WS verfügbar. Offene Spezifikationen für serverbasierte DXF Schnittstellen konnten nicht gefunden werden. Da es sich allerdings um ein sehr verbreitetes Format handelt und Daten oft auch nur als DXF vorliegen, wurden in anderen Arbeiten oft Werkzeuge und Algorithmen entwickelt um die notwendigen Informationen aus DXF Daten automatisiert abzuleiten. [33] [35] 2.2.3 Industry Foundation Classes (IFC) Die Industry Foundation Classes sind ein offener ISO-Standard zur digitalen Beschreibung von Gebäudemodellen, dort auch unter dem Begriff BIM (Building Information Modeling) bekannt [18]. IFC hat sich zum Ziel gesetzt, DXF in der Architektur und im Bauwesen abzulösen. Sie werden von buildingsmart International (bsi) früher bekannt als International Alliance for Interoperability (IAI) einem Zusamenschluss von Baufirmen, Planern und Softwarehäusern, definiert. Es setzt auf einen objekt-orientierten Ansatz, in dem Gebäude, Wände, Türen und Fenster entsprechend modelliert und miteinander in Beziehung gesetzt werden. Die meisten CAD Programme unterstützen das Format inzwischen, doch die Anwender nutzen es noch zu selten, da sie den Mehrwert nicht erkennen oder DXF gewohnt sind. Älteres Datenmaterial lässt sich häufig durch Öffnen der proprietären Projektdateien (Beispiel Autocad: DWG) mit den aktuellen Versionen der CAD Programme, mit denen sie erstellt wurden, als IFC abspeichern bzw. exportieren. Für IFC besteht ein Gebäude aus einzelnen Bauteilen, die dann zusammengesetzt das gesamte Modell ergeben. (vgl. Abbildung 2.5) IFC löst viele Probleme von DXF durch den Objekt-orientierten Ansatz. Allerdings wird der Großteil der spezifizierten Klassen in der Praxis nicht genutzt [27]. Es wirkt komplexer als eigentlich notwendig. Die Topologie lässt sich ableiten, da ein Raum (IfcSpace) die selbe Tür (IfcDoor) als Objekt referenziert, wie der Raum in dem man durch diese Tür kommt. Allerdings wies die Treppe im untersuchen Beispielmodell keine Referenzen auf die Stockwerke bzw. Räume auf, die sie verbindet. Grundsätzlich sieht IFC wohl auch Weggraphen vor, allerdings werden diese nur sehr selten von den Planungsprogrammen automatisch erzeugt. 13

2 Ausgangssituation Abbildung 2.5: Bauteile von IFC [38] Die Versionsverwaltung und Austauschschnittstellen sind nicht im Standard definiert, allerdings springt ein Open Source Projekt namens BIMserver in diese Lücke [27]. Diese in Java geschriebene Software bietet unter anderem Versionierung auf IFC-Objekt Basis, Filterung, Vergleich, Im- und Export der Daten in den verschiedenen IFC Varianten, REST- und SOAP-Schnittstellen, Export nach CityGML (mit Erhaltung der Informationsdichte durch offizielle IFC-Erweiterung GeoBIM), Collada (Sketchup), KML (Google Earth) und O3D/WebGL. Letzteres wird insbesondere im ins Webinterface integrierten O3D-Viewer verwendet, ein WebGL Viewer ist noch im frühen Entwicklungsstatus. [6] In der Praxis sieht man in Deutschland relativ wenig IFC Datenmaterial [35]. Es bleibt zu hoffen, dass sich dies in Zukunft ändert. 2.2.4 Geography Markup Language (GML) Die Geography Markup Language ist ein offenes XML Format zum Austausch raumbezogener Objekte. Es weist eine Vielzahl von Primitiven auf, die durch sogenannte Profile eingeschränkt oder durch Anwendungsschemata erweitert werden können. So gibt es ein GML-Profil für JPEG 2000 um zum Bild eine Koordinate abzuspeichern oder das Anwendungsschemata CityGML mit dem ganze Städte modelliert werden können. GML wird vom Open Geospatial Consortium (OGC) gemeinsam mit einem technischen Komitee der ISO (ISO TC211) definiert. City Geography Markup Language (CityGML) Die City Geography Markup Language (CityGML) kommt aus dem Vermessungswesen und ist ein GML-Anwendungsschema und OGC-Standard zur Speicherung und zum Austausch von virtuellen 3D-Stadtmodellen. 14

"PZS$6175B7)B$L4719)4$,)+,4)1.46$W4567%'5-$41=>X$75B$104$#.1-"PZ$6,4=.L.=$,)+,4)1.46$8.Y4$890-(%'6:-+-(-%,-;>$ [)+:$ U"#$%&'()*$(+',-;$ 104$ 104:71.=$ =876646$ :##+*$(+',-<= >'66*$(+',-<=?(#$%&*$(+',-<=.6#;$(-*$(+',-<= @6##(*$(+',-<= A%0-(/#(>'66*$(+',-<$ 75B$.-/6/%4*$(+',-$ 7)4$ B4).A4B>$ F04$ 104:71.=$ =8766.L.=71.+5$ +L$ I9.8B.5/$ 69)L7=46$.6$.88961)714B$.5$[./>$3&$75B$69I64O94518-$6,4=.L.4B>$$ [+)$47=0$Z!\$I41]445$3$75B$T;$104$/4+:41)-$+L$7$U"#$%&'()*$(+',-$:7-$I4$B4L.54B$I-$7$B.LL4)451$B$60/*$(C +',-?-#5-0()>$<5$Z!\3;$10.6$69)L7=4$/4+:41)-$:961$I4$6.:,8-$=+554=14B;$]0.=0$:4756$1071$104$=+:,+54516$+L$ 104$B$60/*$(+',-$W4>/>$4567D#6)4#%X$:961$5+1$07A4$.554)$0+846$W4567/%0-(/#(X>$ 2.2 Datenformate <5$Z!\S$75B$Z!\T;$7$U"#$%&'()*$(+',-$:7-$)4L4)45=4$U1E-%/%4;$W644$*%>S>TX$8.Y4$B++)6$75B$].5B+]6>$<L$104$ /4+:41).=$8+=71.+5$+L$U1E-%/%4;=1+,+8+/.=788-$8.46$].10.5$7$69)L7=4$=+:,+5451$W4>/>$4567D#6)4#%X$+L$104$B$60/C Modelliert werden Stadt- und Landschaftsobjekte, insbesondere das Gelände, Gebäude, *$(+',-?-#5-0()<=10464$U1E-%/%4;$:961$I4$)4,)464514B$76$0+846$].10.5$1071$69)L7=4>$?$0+84$.6$)4,)464514B$I-$75$ Wasser- und Verkehrsflächen, Vegetation, Stadtmöblierung und Landnutzungen. [17].514).+)$).5/$].10.5$104$=+))46,+5B.5/$69)L7=4$/4+:41)-$+IN4=1>$<L$69=0$75$+,45.5/$.6$64784B$I-$7$ F##(;$7$>/%C Es führt insgesamt 5 verschiedene Detailstufen (Levels of Detail, LoD 0-4) ein. Einzelne Objekte können abhängig vom LoD detaillierter beschrieben werden oder dort auch &#G;$+)$7$.6#;$(-*$(+',-;$104.)$+914)$I+95B7)-$:7-$=+56.61$+L$104$67:4$,+.516$76$104$.554)$).5/$WB45+1.5/$104$ 0+84X$+L$104$69))+95B.5/$69)L7=4>$^+]4A4);$104$,+.516$07A4$1+$I4$6,4=.L.4B$.5$)4A4)64$+)B4)$W4D14).+)$I+95B7).46$ =+9514)'=8+=Y].64$75B$.514).+)$I+95B7).46$=8+=Y].64$]045$8++Y.5/$.5$+,,+6.14$B.)4= erstmalig erscheinen. [30] A4=1+)X>$F04$4:I)769)4$69)L7=46$+L$75$1E-%/%4$I48+5/$1+$104$)484A751$7BN7=451$U"#$%&'()*$(+',->$<L;$L+)$4D7:' Im Vergleich zu IFC werden Gebäude und Räume durch sich gegenseitig abgrenzende,84$7$b++)$64786$104$1e-%/%4;$104$4:i)769)4$69)l7=4$+5$104$+54$6.b4$+l$104$b++)$i48+5/6$1+$104$a%0-(/#(>'66*$(c Flächen beschrieben (vgl. Abbildung 2.6). +',-$75B$+5$104$+104)$6.B4$1+$104$>'66*$(+',-=W[./>$3&$+5$104$)./01X>$ 89:*'0#'!;<*,, "##$!%&'$()* @*0,0/1! %&'$()* +(,,! %&'$()* "##> +(,, ;&'$()*?/:*'0#'+(,, ;&'$()* -.*/0/1 2+0/6#74?/:*'0#'+(,, ;&'$()* # =,##'!%&'$()* 5'#&/6!%&'$()* -.*/0/1! 23##'4 CityGML wirkt ebenfalls komplexer als notwendig. Insgesamt deckt es für den hier gewählten Anwendungsfall einfach zu viel ab. Im Vergleich zu IFC werden Gebäude und Räume durch sich gegenseitig abgrenzende!"# #+,-)./01$2$3%%&$!,45$"4+6,71.78$#+56+)1.9:;$<5=>$?88$@./016$@464)A4B>## Flächen beschrieben. $ Zum Thema Versionsverwaltung in CityGML konnte kein Material gefunden werden. Eine Austauschschnittstelle ist, durch der Abstammung von GML, in der Web Features Service (WFS) Spezifikation des OGC festgelegt. Ein WFS wird beispielsweise unter anderem durch den UMN Mapserver implementiert. Erweiterungen können durch sogenannte Application Domain Extensions (ADEs) mit eigenem Schema und XML-Namespace eingeführt werden. Die Transformation in andere Modelle sollte dank der technischen Basis XML mit XSLT möglich sein, allerdings könnte das verwendete Flächenmodell je nach Zielformat ggf. Herausforderungen aufwerfen. $ $ $ -.*/0/1 3##' [./>$3&E$#8766.L.=71.+5$+L$"#$%&'()*$(+',-;=W84L1X<=.5$,7)1.=987)$L+)$1E-%/%4;$W)./01X$W/)7,0.=E$<""$_5.$J+55X>$ Abbildung 2.6: Flächenmodell von CityGML, Quelle: IGG Uni Bonn $ BIGML BIGML ist ein GML Applikationsschema zur semantischen Beschreibung von Gebäuden, welches im Rahmen der Diplomarbeit von Moritz Kessel [33] entwickelt wurde. Schwerpunkte des Modells liegen auf der Modellierung von Begehbarkeitsinformationen (Wegegraphen) und auf der effizienten Darstellung der meistbenötigten Informationen für Ortsbezogene Dienste innerhalb von Gebäuden. [34] 15

2 Ausgangssituation Es gliedert die Daten in Gebiet, Gebäude, Stockwerke und Räume. Einzelne Räume werden mit Portalen wie Türen, Treppen, Aufzügen, Rolltreppen und Rampen verbunden. Zusätzlich zu Points of Interest (POI) ist es auch möglich, Areas of Interest (AOI) zu definieren. Diese müssen sich nicht an die Hierarchie aus Stockwerken und Räumen halten. Neben den fest definierten Attributen ist es auch möglich, jedes Objekt mit weiteren Informationen anzureichen, indem man es mit beliebig vielen Tupeln aus Schlüssel und Wert versieht. BIGML sieht auf den ersten Blick sehr vielversprechend aus. Es ist nicht zu komplex, enthält interessante Konzepte wie Areas of Interest (AOI), Adressierbarkeit durch URIs und setzt auf Weggraphen. Es setzt auf bestehende Standards wie XML und GML, ist aber selbst weder standardisiert noch weit verbreitet. Da es sich ebenfalls von GML ableitet, kann wiederum ein WFS als Schnittstelle dienen. Ansonsten ist über definierte oder verfügbare Schnittstellen oder Versionsverwaltung nichts bekannt. Durch die Verwandtschaft mit XML lassen sich Erweiterungen einfach durch Verwendung eines entsprechenden XML-Namespace umsetzen. Es existieren bereits einige Werkzeuge, die ermöglichen DXF in BIGML zu konvertieren und mit Weggraphen anzureichern, allerdings sind diese nicht frei verfügbar. 2.2.5 OSM XML Die Auswertung von OSM XML folgt im direkt anschließen Abschnitt OpenStreetMap unter 2.3.1. 2.3 OpenStreetMap OpenStreetMap ist Open-Data-Projekt zur Sammlung von freien Geodaten. Nach dem von Wikipedia bekannten Prinzip kann jeder Nutzer neue Daten eintragen und bestehende verändern. Die Historie (alte Versionen der Objekte) wird ebenfalls gespeichert und kann von jedermann eingesehen werden. Obwohl im Namen des Projektes das Wort Straße enthalten ist, beschränkt sich die Datenbank nicht auf diese: Auch Fahrrad- und Fußwege, Gebäude, Briefkästen, Telefonzellen, Bankautomaten oder auch Parkbänke werden von den Mappern (Nutzer die Daten zum Projekt beitragen) eingetragen. Die Detaildichte ist je nach Gebiet sehr unterschiedlich: In Städten ist sie im allgemeinen sehr hoch, auf dem flachen Land insbesondere bei schlechter Breitbandabdeckung ist teilweise nur die Hauptstraße und der Name des Ortes eingetragen. Um dies weißen Flecken auszudünnen, werden von der Community sogenannte Mapping Partys veranstaltet: Erfahrene Nutzer und Neulinge treffen sich an einem Wochenende mit ihren GPS Geräten, Fotoapparaten und Notizblöcken, um sich das Gebiet aufzuteilen und neue Daten zu erfassen. Diese Rohdaten werden mit Hilfe von entsprechenden Editoren (Unterabschnitt 2.3.2) in die passende Form gebracht und in die Datenbank hochgeladen. Dort erscheinen sie nach wenigen Minuten auf der offiziellen Webkarte unter http://openstreetmap.org. Die Nutzeranzahl sowie die Anzahl der eingetragenen Objekte steigt jeweils exponentiell [7], inzwischen findet eine jährliche Konferenz der Community statt und fast in jeder 16

2.3 OpenStreetMap größeren Stadt insbesondere in Deutschland treffen sich Anwender regelmäßig zum OSM-Stammtisch. Ich stelle nun einige Teilbereiche des OSM-Projekts genauer vor: Nach der Einführung in das zugrundeliegende Datenmodell, stelle ich eine Programme vor die es ermöglichen Daten in eben diesem zu erfassen und zu bearbeiten. Anschließend werden die Schnittstellen zum Datenaustausch zwischen den einzelnen Komponenten beschrieben um mit einen Überblick über den technischen Aufbau des Projekt abzuschließen. 2.3.1 OSM Datenmodell Das OSM Datenmodell kommt mit drei festen Entitäten aus: Nodes, Ways und Relations.!"#$%&'()*(+",(+"%&-./0&''!""#$%&'()*+,-)./0/#'12345/)62075/$$&'()%/7)285&/$$/')625/'9:%/$$7 Abbildung 2.7: vereinfachtes OpenStreetMap Klassendiagramm [41]!"#"$%&'#"(%)"#"$%*+,%-.#%)"#"%/"0+12'.%2.%#"$%3+1".4+.5%"$6+01".%4"2%26$"$%7$8"-9 :-.:%"2."%"2.#"-12:"%.-;"$2<=6"%>"..-.:%?@3A(%-.1"$%#"$%<2"%4"+$4"21"1%-.#%+4:"$-B".% Nodes C"$#".%5D..".E%32"%>"..-.:".%:"0D<=61"$%F4)"51"%C"$#".%.2=61%."-%G"$:"4".E%HI$% bestehen aus 2D Koordinaten (geografische Länge und Breite), +00"%#$"2%F4)"511,J".%C2$#%"2.%-.1"$<=62"#02=6"$%&-;;"$.$+-;%G"$C".#"1%?"<%5+..% Ways +0<'%<'C'60%"2.".%*+,%+0<%+-=6%"2.".%&'#"%;21%#"$%@3%K%:"4".AE verbinden einzelne Nodes miteinander und Relations!"#$% gruppieren Nodes und Ways zu größeren Objekten bzw. geben Beziehungen zwischen diesen wieder. 72.%&'#"%G"$BI:1%I4"$%#2"%B'0:".#".%@.B'$;+12'.".L M :"':$+J62<=6"%NO.:"%-.#%P$"21"( Die konkreten Bedeutungen der einzelnen Objekte wird mit Hilfe von sogenannten Tags M Q"21J-.51%#"$%0"181".%R.#"$-.:(%P".-18"$.-;;"$%-.#%95"..-.:%#"<%0"181".%P"+$9 (Tupel aus Schlüssel und Wert) festgelegt. So wird ein Node beispielsweise mit amenity= 4"21"$<(%S"$<2'.(%S"$C"2<%+-B%#+<%T6+.:"<"1(%2.."$6+04%#"<<".%#2"%0"181"%R.#"$-.:% postbox zum "$B'0:1"%?<2"6"%U"21"%VWA( Briefkasten oder ein Way mit highway=primary zur Bundesstraße. FlächenM werden 'J12'.+0%"2."%4"02"42:"%X".:"%G'.%Y+:<E als geschlossener Way modelliert, wobei Start- und End-Node identisch sind. Löcher in Flächen werden durch gesonderte Ways umgesetzt, die mittels zugehöriger NO.:"%-.#%P$"21"%C"$#".%2.%G'00".%Z$+#%;21%<2"4".%&+=65';;+<1"00".%:"<J"2=6"$1E% Relation 3+<%".1<J$2=61%"2."$%Z".+-2:5"21%G'.%?2;%-.:I.<12:<1".%H+00"A%[K%=;%-.#%$"2=61%#+6"$% entsprechend zugeordnet werden. Es wird allerdings gerade diskutiert ob nicht besser einbi$%+00"%#"$8"21%#".54+$".%\.c".#-.:<:"42"1"%+-<%]%2.<4"<'.#"$"(%c"..%;+.%#2"%y+19 eigener Datentyp dafür eingeführt werden sollte. [19] Weitere<+=6"%4"$I=5<2=612:1(%#+<<%#2"%4"<1"%#"$8"21%;21%6+.#"0<I402=6".%Z^U%"$82"04+$"%Z".+-9 Anwendungsfälle für Relations sind Abbiegevorschriften ( an dieser Kreuzung darf nicht 2:5"21%2;%P"$"2=6%G'.%[V%;%02":1%?<2"6"%U"21"%_`AE links abgebogen werden ) und Bus- oder Fahrradrouten. Die gesamte &'#"<%5D..".%8-%*+,<%G"$4-.#".%C"$#".%-.#%#2".".%<'%+0<%aU1I18J-.51"b%BI$%#".% Datenbank ist aus mathematischer Sicht ein sehr großer, nicht zusammenhängender, S"$0+-B%"2."$%N2.2"%?8-;%P"2<J2"0%"2."$%U1$+c"A%'#"$%#".%d;$2<<%"2."$%H0O=6"%?8-;%P"29 gerichteter und annotierter Graph. <J2"0%"2."<%U""<AE 1) 17

2 Ausgangssituation Das Tagging-Schema wird von der OSM-Community gemeinsam auf einer Wiki-Seite namens Map Features [20] erarbeitet und auf Mailinglisten diskutiert. Auf http://taginfo.openstreetmap.org/ finden täglich statistische Auswertungen der verwendeten Tags statt, an der sich insbesondere neue Nutzer orientieren können. [46] Dieses freie Tagging-Schema erlaubt agiles Arbeiten, allerdings wirft es auch Schwierigkeiten für weitergehende Anwendungsfälle als eine reine Darstellung als Karte auf. So taggen manchen Nutzer leider nicht objektiv, sondern für die Renderer. (vgl. Abb. 2.8) Abbildung 2.8: Beispiel: Die Tunnel der Teilchenbeschleuniger des CERN wurden von einem Nutzer als getunnelte Autobahn bzw. Bundesstraße eingezeichnet, da es auf der Karte ganz gut aus sah. [8] Ein gravierenderes und nicht ganz so offensichtliches Beispiel sind Radwege. Es gibt mehrere unterschiedliche Ansichten was welche Tags zu bedeuten haben. So ist highway= cycleway relativ klar definiert, highway=footway bicycle=yes wird dagegen von einem Großteil der Nutzer als Fußweg auf dem man notfalls auch mit dem Fahrrad fahren kann interpretiert. Der Ersteller der offiziellen Cycle Map sieht das aber wiederum anders und rendert beide exakt gleich. Insbesondere klassische Geodaten-Anwender vermissen eine klare hierarchische Gliederung der Merkmale. [44] Der OSM-Graph muss je nach gewünschter Anwendung erst einmal in das gewünschte Format konvertiert werden, je nach Anwendungsfall auch verlustbehaftet. So sind für 18

2.3 OpenStreetMap einen Reverse Geocoder (Koordinate zu Name oder Adresse) Objekte irrelevant, die keinen Namen haben, wie z.b. Stromleitungen oder Telefonzellen. In OSM existieren bereits einige Versuche zur Abbildung von Räumen in Gebäuden, eine richtige Tagging Empfehlung zu diesem Themengebiet gibt es allerdings noch nicht. Das Modell ist von Haus aus ein Topologie Modell, dies müsste bei einer neu zu entwickelnden Empfehlung zwingend berücksichtigt werden. Die Weggraphen müssen sich schon allein durch die Modellierung ergeben. Versionsverwaltung und Konfliktmanagement ist vollkommen integriert. Jedes Objekt hat eine Versionsnummer, ältere Versionen sind via API abrufbar. Die Webdarstellung ist durch eine Slippy Map in HTML und JavaScript implementiert. Die dazu notwenigen Bilder (Tiles) werden auf Anforderung von einem servergestützten Render Stack erzeugt. Erweiterbarkeit ist zum einen über die freie Vergabe von Tags, aber auch über XML- Namespaces möglich. Es existieren definierte REST-Schnittstellen, die die meisten Anwendungsfälle abdecken. Gefilterte Abfragen sind über die XAPI möglich. REST steht in diesem Kontext für Representational State Transfer und ist ein erstmals in [29, Kap. 5] definierter Softwarearchitekturstil. Transformation in andere Formate z.b. SVG wird beispielsweise über XSLT umgesetzt. Es existieren aber auch frei verfügbare Konverter zu ESRI Shapefiles, KML, GML, PostGIS, Adobe Illustrator, Garmin GPS. OSM hat insbesondere in Deutschland eine sehr breite Nutzerbasis [42, 3:20], wodurch die Modellierung der Gebäude im besten Fall durch die Community übernommen werden könnte. 2.3.2 Editoren Um Änderungen am Datenbestand von OSM vorzunehmen, gibt es viele verschiedene Möglichkeiten. Diese reichen vom vollwertigen Desktop-Graph-Editor, über speziell formatierte Twitter Nachrichten mit Geo-Position bis zu einem Interface via Papier. Die erste Variante versteckt sich auf der Haupt-Webseite hinter dem Tab Bearbeiten : ein in Adobe Flash geschriebener Editor, Podlatch. Er bietet alle wichtigen Funktionen und bindet Standardmäßig Lufbilder von Bing als Hintergrund mit ein. Diese Luftbilder sind von Bing zum Ableiten von Merkmalen freigegeben. Als Desktop Editor kommt hauptsächlich der Java OpenStreetMap Editor (JOSM) zum Einsatz. Als Java Anwendung läuft dieser auf den verbreiteten Betriebssystemen. Es werden, laut der JOSM Wiki, ca. 85 Plugins (Stand November 2011) angeboten, die beispielsweise das Importieren von Vektor- oder Bitmapgrafiken erlauben. Die Tags können entweder manuell oder mit Hilfe von sogenannten Vorlagen zugewiesen werden. Änderungen können über die OSM-API direkt in die Datenbank hochgeladen werden, oder auch als lokale Datei abgespeichert werden. Ein weiterer Flash-Editor ist Mapzen von Cloudmade und wird hier hauptsächlich aufgrund seines innovativen Userinterfaces erwähnt. Insbesondere das Bearbeiten von Abbiegevorschriften wurde sehr gut gelöst. 19

2 Ausgangssituation T'(*+"5'$%&'()*+''*,"&-!3'(#*'!+3**"(23'*'+ 4'(*+"5' %),-!E VK.R7$W%,K7$X+"&3BBB %#9/#3# K.R &5"('* B/#9 8"35< B/#G BBB B/#G ":#4:> B/#9 K.R %),- S83*/+'(!/D(5/"8UK(D'(8:(>!""#$%&'()*+,*-)./)(#"0)123/45#2%2'2)62(27)8')%#2)9:;,<802')=&)>?@@2' Abbildung 2.9: Verschiedene Wege zu OpenStreetMap Daten [41] Für ios und Android gibt es auch jeweils eine native Anwendung mit dem Namen Mapzen POI Collector, die erlaubt neue Nodes auch unterweges vom Smartphone zur Datenbank hinzuzufügen. Das Bearbeiten von existierenden Nodes ist natürlich auch möglich, was allerdings nicht auf Flächen oder Wege zutrifft. Nun noch zu zwei eher ungewöhnlichen Lösungen: osmitter verbindet den Kurznachrichtendienst Twitter mit OpenStreetMap: Nach dem Verbinden seines Twitter- und OSM-Accounts auf http://osmitter.com/ kann man mit Hilfe des Schlüsselworts #osmit neue Objekte in der Datenbank anlegen. Als Ort werden die Koordinaten der Nachricht übernommen. So lässt sich eine Italienische Pizzeria z.b. mit Tweet mit dem Inhalt amenity=fast food name=pizza Ololo cuisine= italian #osmit anlegen. Walking Papers erlaubt Änderung direkt via Papier zu machen. Auf der Seite lässt sich ein georeferenziertes PDF mit 2D Barcode erzeugen, dass die bereits existieren Daten!" im Zielgebiet #$%&'(()*$()+',)-./01*2,3 enthält. Dieses Dokument druckt sich der Nutzer auf DinA4 aus, nimmt es mit vor Ort und trägt die Änderungen handschriftlich ein. Anschließen wird ein Foto oder Scan der Seite wieder auf die Webseite hochgeladen. Diese erkennt aufgrund des 2D- Barcodes den genauen Ort. Nun kann ein beliebiger Nutzer sich das Dokument im Hintergrund!"#$%&'()*+''*,"&-.+/0'1*$2'*+'32*$'3('($4'(*+"5'($!"*'(2"(1#'+6'+7$8'+$3($'3('9$ von Podlatch oder JOSM einblenden lassen und die Änderungen digitalisieren. Insbesondere )'+6'++":9$8'#$;(36'+#3*<$=/55'>'$/?$@/(8/($#*'A*B$C355$9"($93*$8'($%&'()*+''*,"&- bei Mapping Parties kommt diese Methode oft zum Einsatz.!"*'($#'52#*$3+>'(8'*D"#$"(#*'55'(7$4:9$E'3#&3'5$'3>'('$F"+*'($2'+'GA('($/8'+$'3('($ 2.3.3 C'283'(#*$":?#'*4'(7$8'+$83'$!"*'($2'(:*4*7$9:##$9"($#3GA$83'$!"*'($4:'+#*$6/($8/+*$ Schnittstellen /8'+$":#$'3('+$8'+$"(8'+'($H:'55'($A'+:(*'+5"8'(B!"?I+$>32*$'#$>+:(8#J*453GA$6'+#GA3'8'('$K(#J*4'$LK22358:(>$MN-MOP$)3'$1Q(('($83'$"1- Das Projekt besteht aus vielen unterschiedlichen Diensten, die teilweise auch von ein- *:'55'($!"*'($'3('#$>'/>+"&A3#GA'($E'+'3GA'#$'(*D'8'+$83+'1*$I2'+$83'$%),-K.R$LK&&- 53G"*3/($.+/>+"993(>$R(*'+?"G'O$6/9$)'+6'+$2'1/99'(7$/8'+$)3'$2'(:*4'($'3('($8'+$ 20!"#

2.3 OpenStreetMap zelnen Privatpersonen getragen werden. Dem zugrunde liegt eine einzige zentrale Datenbank an der Änderungen nur via OSM-API vorgenommen werden können, lesender Zugriff ist auch über andere Methoden möglich. (Siehe Abbildung 2.9) OSM-API Die OSM-API ist das primäre Bindeglied zwischen der OSM Datenbank und dem Internet. Sie ist als RESTful HTTP API konzipiert und aktuell in Ruby on Rails implementiert. Die Spezifikation ist unter http://wiki.openstreetmap.org/wiki/api_v0.6 abrufbar. Neben Methoden zum Ändern einzelner Objekte gibt es auch Möglichkeit, mehrere Änderungen in einer oder mehreren Transaktionen als Changeset (Gruppe von Änderungen mit Kommentar, vgl. Versionsverwaltungssysteme wie Subversion oder GIT) hochzuladen. Die am häufigsten benutzte Methode ist allerdings zum Herunterladen der Daten. Um z.b. den kompletten Garchinger Campus herunterzuladen muss nur folgende URL via HTTP abgerufen werden http://api.openstreetmap.org/api/0.6/map?bbox=11.66086,48.25848,11. 67912,48.27061 1 <osm version="0.6" generator="cgimap 0.0.2"> 2 <bounds minlat="48.2584800" minlon="11.6608600" maxlat="48.2706100" maxlon ="11.6791200"/> 3 <node id="427201" lat="48.2679144" lon="11.6626228"...> 4 <tag k="highway" v="traffic_signals"/> 5 </node> 6 <node id="269349081" lat="48.2673961" lon="11.6686525"...> 7 <tag k="amenity" v="post_box"/> 8 <tag k="collection_times" v="fixme"/> 9 <tag k="operator" v="deutsche Post"/> 10 </node> 11 <node id="277698457" lat="48.2623903" lon="11.6687609" user="saerdnaer" uid ="6998" visible="true" version="5" changeset="8666772" timestamp ="2011-07-08T14:25:27Z"/> 12... 13 <way id="23316556" user="ulfm" uid="107037" visible="true" version="13" changeset="8799596" timestamp="2011-07-22t17:22:49z"> 14 <nd ref="252445889"/> 15... 16 <nd ref="252445889"/> 17 <tag k="alt_name" v="atom-ei"/> 18 <tag k="amenity" v="university"/> 19 <tag k="building" v="yes"/> 20 <tag k="name" v="forschungsreaktor München"/> 21 </way> 22 <way id="116577456" user="marek kleciak" uid="338611" visible="true" version ="1" changeset="8358426" timestamp="2011-06-06t10:01:07z"> 23 <nd ref="311786993"/> 24 <nd ref="539773152"/> 25 <tag k="highway" v="service"/> 26 <tag k="service" v="parking_aisle"/> 21