Hochschule Karlsruhe Technik und Wirtschaft Fakultät für Geomatik Fachbereich Kartographie und Geomatik

Transkript

1 Hochschule Karlsruhe Technik und Wirtschaft Fakultät für Geomatik Fachbereich Kartographie und Geomatik Bachelor-Thesis OpenStreetMap in ArcGIS: Automatisierte Datenaufbereitung für Netzwerkanalysen verfasst von Eva Zimmermann betreut von Prof. Dr. Anne Rauner durchgeführt bei ESRI Deutschland GmbH Kranzberg, 30. Juni 2010

2 Eidesstattliche Erklärung Hiermit erkläre ich, Eva Zimmermann, dass ich die vorliegende Bachelor-Thesis selbstständig angefertigt habe. Es wurden nur die in dieser Arbeit ausdrücklich benannten Quellen und Hilfsmittel benutzt. Kranzberg, den 30. Juni 2010 Danksagung An dieser Stelle möchte ich allen danken, die mich bei der Erstellung der Bachelor-Thesis unterstützt haben. Mein Dank geht an Prof. Dr. Anne Rauner für ihre gute Betreuung. Des Weiteren möchte ich mich bei Frederik Ramm von der Geofabrik aus Karlsruhe für die Einführung in der Thema OpenStreetMap und die Überlassung des Quellcodes des OSM-SHP-Konverters bedanken. Insbesondere möchte ich den Mitarbeitern von ESRI aus Kranzberg und den anderen Niederlassungen danken, die meine Arbeit kritisch betrachtet und korrekturgelesen haben. Namentlich möchte ich an dieser Stelle Grischa Gundelsweiler und Kathrin Gobitz-Pfeifer nennen, die mich sehr gut betreut, unterstützt und mir viele Ratschläge und Ideen gegeben haben. Schließlich möchte ich meiner Familie danken, die mich während des Studiums und der Erstellung der Abschlussarbeit tatkräftig unterstützt hat. II

3 Thema Aufgabenstellung für die Bachelor-Thesis von Eva Zimmermann Fakultät für Geomatik Studiengang Kartographie und Geomatik OpenStreetMap in ArcGIS: Automatisierte Datenaufbereitung für Netzwerkanalysen Rahmenbedingungen Auftraggeber der Bachelor-Thesis ist die ESRI Deutschland GmbH in Kranzberg. Die Arbeit wird von Frau Prof. Dr. Anne Rauner (Hochschule Karlsruhe) und Frau Dipl.-Ing. (FH) Kathrin Gobitz-Pfeifer (ESRI) betreut. Situation Als GIS-Softwarehersteller bietet ESRI mit ArcGIS ein komplexes Geoinformationssystem, mit dem Geodaten erfasst, bearbeitet, verwaltet, analysiert und präsentiert werden können. Neben anderen geografischen Analysearten können in ArcGIS mit Hilfe der Erweiterung Network Analyst Netzwerkanalysen für Verkehrsnetzwerke durchgeführt werden. Das freie Projekt OpenStreetMap entwickelt sich zunehmend als Konkurrenz zu anderen freien und kommerziellen Datenanbietern von Geodaten. Bisher gibt es schon mehrere Möglichkeiten, wie O- penstreetmap-daten in ArcGIS verwendet werden können. Neben einigen Internet-Seiten, von denen OpenStreetMap-Daten für die Verwendung in ArcGIS heruntergeladen werden können, existieren auch frei zugängliche Skripte und Programme, mit denen die Daten in ESRI-Datenformate konvertiert werden können. Doch um diese Daten für Netzwerkanalysen im Network Analyst von ArcGIS verwenden zu können, sind noch weitere Aufbereitungsschritte nötig. Diese komplizierte Aufbereitung könnte ArcGIS-Anwender davon abhalten, OpenStreetMap-Daten für Netzwerkanalysen in ArcGIS zu verwenden. Zielbeschreibung Im Rahmen der Bachelor-Thesis soll analysiert werden, wie die Verwendung von OpenStreetMap- Daten für Netzwerkanalysen in ArcGIS vereinfacht werden kann. Dazu soll eine prototypische Anwendung geschrieben werden, mit der OpenStreetMap-Daten automatisiert für Network Analyst- Anwendungen in ArcGIS eingelesen werden können. Folgende Punkte sind Bestandteil der Thesis: Einordnung des in der Arbeit analysierten Netzwerks und der in der ArcGIS-Erweiterung Network Analyst möglichen Netzwerkanalysen in die in Geoinformationssystemen verwendeten Netzwerke und Netzwerkanalysen Vorstellung des OpenStreetMap-Projekts und Analyse des OpenStreetMap-Datenformats im Hinblick auf die allgemeine Verwendung in Netzwerkanalysen III

4 Vergleich der OpenStreetMap-Daten mit Straßendaten anderer öffentlicher Anbieter, Privatanbieter und von frei verfügbaren Quellen (im Hinblick auf geographische Abdeckung, dargestellte Inhalte, Datenqualität, Datenverfügbarkeit, Nutzungsrechte) Analyse verfügbarer OpenStreetMap-Daten in ESRI-Datenformaten im Hinblick auf die Nutzung im Network Analyst manuelle Datenaufbereitung von Original-OpenStreetMap-Daten für die Anwendung im Network Analyst und Durchführung einer beispielhaften Netzwerkanalyse Konzeption und Realisierung einer prototypischen Anwendung zur automatisierten Konvertierung und Datenaufbereitung von OpenStreetMap-Daten für die Anwendung im Network Analyst Vergleich der mit der programmierten Anwendung erzeugten Daten mit angebotenen Netzwerkanalyse-Daten und -Services in ArcGIS sowie Vergleich mit ArcGIS-unabhängigen O- penstreetmap-routendiensten abschließende Bewertung der Anwendung und der erzeugten Daten Ergebnis Das Ergebnis ist eine Analyse der Verwendung von OpenStreetMap-Daten im Network Analyst von ArcGIS sowie die Konzeption und Realisierung einer prototypischen Anwendung zur automatisierten Datenaufbreitung dieser Daten im Hinblick auf deren direkten Nutzung im Network Analyst. Erstprüfer (Hochschule): Prof. Dr. Anne Rauner Zweitprüfer (ESRI): Dipl.-Ing. (FH) Kathrin Gobitz-Pfeifer Bearbeitungszeit: 3 Monate Tag der Ausgabe: 01. April 2010 Tag der Abgabe: 30. Juni 2010 Anschrift der Bachelorandin: Ort, Datum: Eva Zimmermann Giggenhauser Straße 25a Freising zimmermann.eva@gmx.de Unterschrift: (Erstprüfer) (Zweitprüfer) IV

5 Executive Summary - Deutsch Als GIS-Softwarehersteller bietet ESRI mit ArcGIS ein komplettes Geoinformationssystem, mit dem Geodaten erfasst, bearbeitet, verwaltet, analysiert und präsentiert werden können. Mit Hilfe der Erweiterung Network Analyst können in ArcGIS Netzwerkanalysen für Verkehrsnetzwerke durchgeführt werden. Das freie Projekt OpenStreetMap (OSM) entwickelt sich zunehmend zur Konkurrenz zu anderen Datenanbietern von Geodaten. Bisher gibt es mehrere Möglichkeiten, wie OSM-Daten in ArcGIS verwendet werden können. Neben einigen Internet-Seiten, von denen OSM-Daten für die Verwendung in ArcGIS heruntergeladen werden können, existieren auch Skripte und Programme, mit denen die Daten in ESRI-Datenformate konvertiert werden können. Eine Integration und Betrachtung der Daten ist also möglich. Des Weiteren können sie als Basis für grundlegende Analysen dienen. Um einen Schritt weiterzugehen und die Daten für Netzwerkanalysen im Network Analyst von ArcGIS verwenden zu können, ist eine aufwendigere Aufbereitung der Daten notwendig. Im Rahmen der Bachelor-Thesis wurde untersucht, ob die OSM-Daten für Netzwerkanalysen in ArcGIS geeignet sind und wie die Integration und Nutzung vereinfacht werden kann. Dazu wurde eine prototypische Anwendung entwickelt, die es ermöglicht, OSM-Daten automatisiert für die Anwendung im Network Analyst vorzubereiten. Diese Anwendung wurde so konzipiert, dass sie Verkehrsnetzwerke für beliebige Fahrzeugtypen und Länder erzeugen kann. Die generierten Netzwerke berücksichtigen OSM-Attribute wie z.b. Beschränkungen, Einbahnstraßen, Abbiegevorschriften, Barrieren und Höchstgeschwindigkeiten. Durch die zusätzliche Aufnahme von Durchschnittsgeschwindigkeiten, die der Nutzer selbst definiert, kann neben der Länge einer Route auch die Fahrtzeit berechnet werden. Die Anwendung erzeugt zunächst eine Geodatabase, die das Netzwerk enthält. Anschließend wird ein Map Document (*.mxd) erstellt, das die angepassten Network Analyst Solver Layer enthält. Dieses Map Document kann sofort für Netzwerkanalysen verwendet werden. Auf den erzeugten Verkehrsnetzwerken kann im Network Analyst von ArcGIS geroutet sowie Erreichbarkeits- und Standortanalysen durchgeführt werden. Diese Netzwerkanalysen sind durchaus mit anderen Netzwerkanalyse-Diensten vergleichbar. Da OSM-Daten jedoch noch nicht so umfassend attributiert sind wie Netzwerkanalyse-Daten von kommerziellen Datenanbietern, sind die Anwendungsgebiete etwas eingeschränkt. Für einfache Anwendungen wie Auto-, Fahrrad- oder Fußgängerrouting sind die Daten gut geeignet. Ein einigermaßen zuverlässiges LKW-Routing ist dagegen noch nicht möglich, da viele LKW-spezifische Attribute wie Höchstgewichte oder Maximalhöhen noch nicht flächendeckend vorhanden sind. Ob die Nutzung der mit dieser Anwendung erzeugten Netzwerkanalyse-Daten zu empfehlen ist, hängt auch stark vom entsprechenden Land ab. Länder wie Deutschland und England sind schon sehr gut erfasst. Für manche andere Länder enthalten die OSM-Daten aber oft nur Durchfahrtsstraßen durch Orte. Zusammenfassend kann man sagen, dass sich die mit dem Tool erzeugten Netzwerkanalyse-Daten für viele Anwendungszwecke eignen. Der Nutzer sollte jedoch immer zuerst prüfen, ob die Verwendung der OSM-Daten für seinen Anwendungszweck sinnvoll ist. V

6 Executive Summary - Englisch The GIS software company ESRI provides a complete geoinformation system named ArcGIS which is used to collect, edit, manage, analyze, and present geoinformation data. ArcGIS can perform network analyses on transportation networks with the extension Network Analyst. The free project OpenStreetMap (OSM) is becoming a better competitor to other data vendors of geographic data. There are already some possibilities to use OSM data in ArcGIS. Some websites offer OSM data for usage in ArcGIS, but there are also applications which convert data into ESRI formats. This data can then be integrated and observed. Furthermore they can be used for basic analyses. To go one step further and use the data for network analyses in the Network Analyst of ArcGIS, a more complex data preparation would be necessary. In the context of the bachelor thesis, how the usage of OSM data can be simplified for network analyses in ArcGIS was analyzed. A prototypical application which converts OSM data for network analyses was written. This program was designed so it can generate transportation networks for any mode of transportation and any region. The network attributes are based on OSM map features such as restrictions, one-way roads, turn restrictions, barriers, and maximum speed. Not only the length of a route, but also the travel time can be calculated with user defined average speed settings. First, the program builds a geodatabase which contains the network. Then a map document (*.mxd) is created with the adapted Network Analyst solver layers. This map document is ready to perform network analyses. By using the Network Analyst of ArcGIS, a route can be calculated on the generated transportation network. Furthermore, service areas and location studies can be performed. The created networks are absolutely comparable with other network analysis services. The field of application is limited because OSM data don t have as many attributes as other network analysis data from commercial data vendors. The data are adequate for simple applications like car, bicycle, and pedestrian routing, but a reliable truck route cannot yet be generated because truck attributes such as maximum weight and maximum height don t exist all over the country in OSM. Additionally the recommendation for the usage of the generated transportation network data depends on the region. States like Germany and Great Britain are mapped very well. However, some other regions contain only main roads. As a conclusion one can say that the network analysis data generated by the written program are adequate for many purposes, but the user should always check if his usage of OSM data is useful for his intended purpose. VI

7 Inhaltsverzeichnis Aufgabenblatt... III Executive Summary Deutsch... V Executive Summary Englisch... VI Inhaltsverzeichnis... VII 1. Einführung Netzwerkanalysen in Geoinformationssystemen Netzwerk Netzwerkanalyse Network Analyst in ArcGIS Connectivity Network Attributes Turns Directions Neuerungen in ArcGIS OpenStreetMap Einführung Datenmodell Grundlegendes Datenmodell Map Features Verkehrswege Straßen Fahrradwege und von Fahrradfahrern benutzbare Wege Brücken und Tunnel Verkehrsbeschränkungen Beschränkungen der Beförderungsart Baustellen und geplante Straßen Einbahnstraßen Geschwindigkeitsbeschränkungen Größen- und Gewichtsbeschränkungen Zeitliche Beschränkungen Verkehrsberuhigung Barrieren Abbiegevorschriften Eigenschaften des Verkehrsnetzes OSM-Datenbezug OSM in ArcGIS OSM in ESRI-Datenformaten VII

8 Geofabrik CloudMade Tools und Skripte zur OSM-Konvertierung Vergleich zu anderen netzwerkanalysefähige Daten Netzwerkanalysen mit OpenStreetMap Konzept Parameter-Datei Feature Class roads Feature Class turns Feature Class barriers Network Dataset Nicht umgesetzte Map Features Evaluierung von OSM-Daten in ESRI-Datenformaten für Netzwerkanalysen in ArcGIS Geofabrik CloudMade Tools und Skripte zur OSM-Konvertierung Zusammenfassung der Evaluierung Programmiertechnische Umsetzung Vergleich anhand von beispielhaften Netzwerkanalysen Auto-Routing Fahrrad-Routing Erreichbarkeitsanalyse Zusammenfassung Anwendungsgebiete Bewertung und Ausblick Abkürzungsverzeichnis... IX Abbildungsverzeichnis... X Tabellenverzeichnis... XII Listings... XIII Index... XV Glossar... XVIII Literaturverzeichnis... XX Anhang... XXXIII Abbildungen, Tabellen, Listings... XXXIV Installation... LXIII Inhaltsverzeichnis der CD... LXIV VIII

9 1. Einführung Im Jahr 2004 wurde das Projekt OpenStreetMap (OSM) mit dem Ziel ins Leben gerufen eine freie Weltkarte nach dem Wikipedia-Prinzip zu schaffen. Seitdem hat OSM innerhalb nur weniger Jahre mit Hilfe vieler Freiwilliger eine erstaunliche Entwicklung durchgemacht. Vergleicht man heute verschiedene proprietäre Karten mit OSM, stellt man fest, dass OSM in vielen Gebieten besser ist. So enthält OSM Daten, die von kommerziellen Datenanbietern nicht erfasst werden. Dem visuellen Vergleich ist OSM in vielen Ländern gewachsen. Aber wie sieht es mit Daten für Routing- und Netzwerkanalyse-Anwendungen aus? Diese sind i.d.r. nicht auf Karten dargestellt sind. Routingdienste wie von YourNavigation, CloudMade und OpenRouteService sowie Routinganwendungen auf mobilen Geräten zeigen, dass OSM-Daten routingfähig sind. Bisher ist jedoch noch keine Anwendung bekannt, die OSM-Daten für Netzwerkanalysen in ArcGIS aufbereitet. ArcGIS bietet mit der Erweiterung Network Analyst die Möglichkeit Netzwerke zu erstellen und Netzwerkanalysen durchzuführen. Im Rahmen dieser Bachelor-Arbeit wird deshalb untersucht, wie diese Daten für Netzwerkanalysen für die Anwendung im Network Analyst aufbereitet werden können. Der Kern der Arbeit besteht aus der Konzeption und Erstellung einer prototypischen Anwendung, mit der automatisiert OSM-Daten in ein solches Netzwerk konvertiert werden können. Die Anwendung soll so konzipiert werden, dass mit ihr Netzwerke für beliebige Verkehrsmittel und beliebige Länder erstellt werden können. Beispielhaft werden Netzwerke für Autos und Fahrräder erzeugt. Anschließend wird geprüft, ob die erzeugten Daten mit anderen Netzwerkanalyse- und Routingdaten vergleichbar sind. Die Arbeit ist in vier Hauptabschnitte unterteilt: Nach diesem Einführungskapitel folgt ein Kapitel (Kapitel 2) zur Einordnung des in der Arbeit analysierten Netzwerks sowie der in der ArcGIS-Erweiterung Network Analyst möglichen Netzwerkanalysen in die in Geoinformationssystemen verwendeten Netzwerke und Netzwerkanalysen. Im darauffolgenden Kapitel (Kapitel 3) wird das OSM-Projekt und das -Datenformat im Hinblick auf Netzwerkanalysen vorgestellt. Das Kapitel 4 enthält die Konzeption für die prototypische Anwendung und deren Umsetzung. Des Weiteren werden in diesem Kapitel die mit der Anwendung erzeugten Daten mit angebotenen Netzwerkanalyse-Daten und -Services in ArcGIS sowie mit ArcGIS-unabhängigen OSM-Routingdiensten verglichen. Zum Schluss wird in Kapitel 5 die in der Arbeit erstellte Anwendung und die erzeugten Daten bewertet sowie einen Ausblick gegeben, wie die Anwendung zukünftig noch erweitert werden kann. 1

10 2. Netzwerkanalysen in Geoinformationssystemen Dieses Kapitel dient als Einführung in das Thema Netzwerkanalysen in Geoinformationssystemen (GIS). Der Fokus liegt dabei auf Netzwerkanalysen in ArcGIS (siehe Kapitel 2.3). Das Kapitel bildet die notwendige theoretische Grundlage für die Entwicklung der prototypischen Anwendung, deren Konzeption und Umsetzung in Kapitel 4 beschrieben wird Netzwerk Netzwerke werden in vielen verschiedenen Bereichen der Wirtschaft und der Wissenschaft angewendet. Der Begriff Netzwerk wird z.b. in der Informationstechnik, in der Elektrotechnik oder in den Sozialwissenschaften verwendet. Im Geoinformationswesen kommen sie beispielsweise zur Modellierung von Verkehrs-, Versorgungs- und Leitungsnetzwerken zum Einsatz [4] (S. 741). In diesem Zusammenhang werden Netzwerke als zusammenhängende Graphen [4] (S. 741) bezeichnet, die aus einer geometrisch-topologischen Anordnung von Knoten und Kanten [3] (S. 187) bestehen. Mathematisch definiert werden Netzwerke über die Graphentheorie [1] (S. 106). Mit Netzwerken lassen sich Netzwerkanalysen (siehe Kapitel 2.2) durchführen, um Beziehungen innerhalb des Netzwerkes zu berechnen [3] (S. 188). Mathematisch definiert werden Verkehrsnetzwerke über die Graphentheorie [1] (S. 106). VAHRENKAMP & MATTFELD (2007) geben in ihrem Buch Logistiknetzwerke. Modelle für Standortwahl und Tourenplanung einen Überblick über die Graphentheorie [17] (S. 11ff). Wenn nicht anders angegeben, stammen die im Folgenden beschriebenen Eigenschaften aus der Graphentheorie aus diesem Buch. Ein Graph, auch Netzwerk genannt, besteht aus dem Tripel Knoten, Kanten und einer Zuordnungsvorschrift. Kanten und Knoten sind zwei elementfremde Mengen [1] (S. 106). Die Zuordnungsvorschrift, auch Inzidenzabbildung [9] (S. 3) genannt, ordnet jeder einzelnen Kante aus der Menge Kanten zwei Knoten aus der Menge Knoten zu [1] (S. 106). In der Graphentheorie unterscheidet man zwischen ungerichteten und gerichteten Netzwerken. Sind die einer Kante zugewiesenen Knoten nicht geordnet, handelt es sich um einen ungerichteten Graphen [9] (S. 3). In einem gerichteten Graphen sind sie dagegen geordnet [9] (S. 3). Die Kanten werden dann als gerichtete Kanten oder Pfeile bezeichnet. Gerichtete Netzwerke heißen auch Digraphen. In einem ungerichteten Netzwerk werden Knoten, die durch eine Kante miteinander verbunden sind, als benachbart [1] (S. 106) oder adjazent zueinander bezeichnet. Eine Kante ist zu ihren Knoten inzident. In der Graphentheorie wird unter dem Grad eines Knotens die Anzahl seiner Nachbarn verstanden. Ist der Grad eines Knotens 0, so hat er keine Nachbarn und ist damit isoliert. In ungerichteten Graphen wird zwischen Wegen und Pfaden unterschieden. Ein Pfad ist eine Folge von Knoten, wobei Knoten auch mehrmals besucht werden können. In einem Weg dagegen darf ein Knoten nur höchstens einmal durchlaufen werden. Bei Zyklen handelt es sich um Pfade oder Wege, deren Anfangsknoten mit dem Endknoten übereinstimmen. Knoten sind untereinander erreichbar, wenn zwischen ihnen ein Weg besteht. Ein vollständiger Graph ist ein Netzwerk, in dem jeder Knoten mit jedem anderen Knoten durch eine Kante verbunden ist [9] (S. 6). Ein ungerichteter Graph wird als zusammenhängend bezeichnet, wenn von jedem Knoten zu jedem anderen Knoten ein Weg besteht, d.h. wenn die Knoten untereinander erreichbar sind. Sind nicht alle Knoten untereinander erreichbar, dann bilden die Knoten, die untereinander erreichbar sind, Zusammenhangskomponenten. 2

11 Im Gegensatz zu ungerichteten Netzwerken unterscheidet man in gerichteten Netzwerken zwischen Pfeilen, die zu einem Knoten positiv oder negativ inzident sind. Die gerichtete Kante ist zu einem Knoten positiv inzident, wenn er der Anfangsknoten ist. Ist er der Endknoten, so ist die Kante zu diesem Knoten negativ inzident. Während es bei ungerichteten Graphen nur eine Verbindung (Kante) zwischen zwei Knoten geben kann, können in gerichteten Netzwerken Knoten durch bis zu zwei Pfeile miteinander verbunden sein. In gerichteten Graphen wird bei Knoten zwischen Vorgängern und Nachfolgern unterschieden. Verläuft eine Kante von einem Knoten i zu einem Knoten j, so wird i als Vorgänger von j und j als Nachfolger von i bezeichnet. Bei gerichteten Graphen gibt es auch den Begriff Grad. Als positiven Grad wird die Anzahl aller Nachfolger eines Knotens bezeichnet, als negativer die Anzahl aller Vorgänger. Wie auch bei ungerichteten Netzwerken gibt es bei gerichteten Netzwerken Pfade und Wege. Wird die Pfeilrichtung beachtet, spricht man zusätzlich von gerichteten Pfaden bzw. gerichteten Wegen. Eine starke Zusammenhangskomponente in einem gerichteten Graphen ist eine maximale Menge von Knoten, deren Knoten wechselseitig über einen gerichteten Weg erreichbar sind. Bei einer schwachen Zusammenhangskomponenten muss der Weg dabei nicht gerichtet sein. In Netzwerken können die Kanten durch Gewichte bewertet werden. Ein einfaches Beispiel für solch ein Gewicht ist die Länge einer Kante, die auch als Entfernung oder Distanz bezeichnet wird. Ein ungerichteter oder gerichteter Graph wird als planar bezeichnet, wenn er sich in der Ebene so zeichnen lässt, dass sich keine Kanten bzw. Pfeile gegenseitig überschneiden Netzwerkanalyse Netzwerkanalysen sind in GIS wichtige topologische Analyseverfahren [5] (S. 375), die auf Netzwerken (siehe Kapitel 2.1) und damit überwiegend auf linienhaften Phänomenen [2] (S. 99) basieren. Sie werden dazu benutzt, um Nachbarschaftsbeziehungen zu berechnen [5] (S. 375) und damit räumliche Fragestellungen [11] (S. 272) zu klären. Diese Berechnungen sind Optimalitätsberechnungen, die z.b. darauf abzielen die günstigste Route zu ermitteln. Dies geschieht mit Hilfe von Eigenschaften, die für das Netzwerk definiert sind. Dies können beispielsweise Gewichte von Kanten [5] (S. 375) oder auch Beschränkungen sein. Es gibt viele unterschiedliche Typen von Netzwerkanalysen, die von verschiedenen Autoren unterschiedlich klassifiziert werden. Im Folgenden werden die wichtigsten Netzwerkanalysearten genannt und kurz beschrieben. Laut LUPIEN, MORELAND & DANGERMOND (1987) [13] (S. 1417ff) kann man Netzwerkanalysen in folgende drei Hauptgruppen aufteilen: Ermittlung bester Wege Reisendenproblem Ermittlung bester Standorte Ralf BILL fasst (1999) [2] (S. 100f) die Netzwerkanalyseart Beste Wege zusammen: Diese Netzwerkanalyseart hat zur Aufgabe, die optimale Route zwischen zwei gegebenen Orten zu ermitteln. Dies kann beispielsweise der streckenmäßig kürzeste, der zeitlich kürzeste oder topologisch günstigste Weg sein. Beim topologisch günstigsten Weg wird nach dem Weg mit der geringsten Anzahl von Kanten gesucht. Jedoch sind auch andere Gewichtungen von Kanten als Distanz und Zeit möglich. Zur Berechnung des günstigsten Wegs können verschiedene Algorithmen herangezogen werden. 3

12 In seinem Beitrag zum Thema Routing und Navigation im Handbuch Geomarketing (2008) [11] (S. 133) schreibt Mark ZELLER, dass zur Berechnung der optimalen Route häufig der Algorithmus von Dijkstra (benannt nach Edsger W. Dijkstra) verwendet wird. Dieser arbeitet auf dem Verkehrsnetz, das als Graphen mit gewichteten Kanten definiert ist. Die Gewichte, auch Kosten genannt, sind i.d.r. die Entfernung zwischen den beiden Knoten einer Kante und/oder die Durchschnittsfahrtzeit. Es sind aber auch andere Arten von Gewichten möglich. Die beiden Begriffe Routing und Navigation werden in der Praxis oft verwechselt. Im Handbuch Geomarketing (2008) werden diese und verwandte Begriffe in einem Beitrag von Mark ZELLER näher erläutert [11] (S. 133f). Wenn nicht anders gekennzeichnet, beziehen sich die folgenden Erläuterungen auf diese Quelle. Unter Routing versteht man die Berechnung der besten Fahrtroute zwischen zwei oder mehreren Orten auf einem Verkehrsnetz. Verläuft die Route über Zwischenpunkten, wird von Routenplanung gesprochen [11] (S. 133). Die Defintion von Navigation ist der des Routings ähnlich. Die Navigation hat zur Zielsetzung den Nutzer zu einem von ihm gewählten Ziel zu führen. Während der Navigation wird immer wieder die aktuelle Position bestimmt und auf deren Grundlage die optimale Route innerhalb des Verkehrsnetzes neu ermittelt [11] (S. 133). Das Reisendenproblem ist im Prinzip ein Sonderfall der Netzwerkanalyseart Beste Wege. Bei dieser Netzwerkanalyseart fallen Start- und Endpunkt einer Route zusammen [11] (S. 133). In der Literatur wird dieses Problem auch Rundreiseproblem oder Traveling Salesman Problem, zu Deutsch Problem des Handlungsreisenden genannt. Nach Werner DINKELBACH stellt die Tourenplanung eine Verallgemeinerung [4] (S. 1073) des Rundreiseproblems dar. Werner DINKELBACH hat dieses Problem in Vahlens Großes Logistiklexikon definiert [4] (S. 1073f): Im Gegensatz zum Problem des Handlungsreisenden können hier in die Berechnung auch mehrere Fahrzeuge mit unterschiedlichen Ladekapazitäten eingehen. Sowohl die Ausgangsorte dieser Fahrzeuge ( Depots ) als auch deren Kunden können verteilt liegen. Die Tourenplanung hat noch weitere Eigenschaften, auf die hier aber nicht näher eingegangen wird. Ralf BILL definiert die Netzwerkanalyseart Beste Standorte in seinem Buch Grundlagen der Geo- Informationssysteme (Band 2, 1999) [2] (S. 103): Bei dieser Netzwerkanalyseart wird für ein in Planung befindliches Objekt der beste Standort gesucht (Standortplanung). Dabei werden Einflussfaktoren wie Erreichbarkeit des Standortes von anderen Orten (z.b. unter Berücksichtung der Zeit oder der Weglänge), Streckenausbau, Verkehrsaufkommen usw. berücksichtigt. Neben diesen wichtigsten Netzwerkanalysearten gibt es noch viele weitere Analysearten, die meist den genannten untergeordnet werden können, Misch- oder Spezialfälle sind. So können auch Entfernungszonen berechnet oder Einzugs- und Verkaufsanalysen durchgeführt werden. Netzwerkanalysen werden in vielen Gebieten und Branchen eingesetzt. Beispiele hierfür sind die Logistik, insbesondere die Verkehrslogistik, die Verkehrs- und Infrastrukturplanung und die Vertriebssteuerung. Des Weiteren kommen sie in Ver- und Entsorgungsbetrieben, im Katastrophenschutz, zur Koordination von Notdiensten, im Geomarketing für Marktanalysen usw. zum Einsatz. 4

13 2.3. Network Analyst in ArcGIS Die Erweiterung (oder engl. Extension) Network Analyst in ArcGIS dient der Erzeugung, Verwaltung, Darstellung und Analyse von Verkehrsnetzwerken [43]. Mit dem Network Analyst lassen sich Netzwerke realistisch erstellen. So können beispielsweise verschiedene Verkehrsbeschränkungen wie Abbiegevorschriften, Geschwindigkeits- oder Höhenbeschränkungen, Barrieren oder zeitliche Effekte realisiert werden [43]. Außerdem dient der Network Analyst u.a. dazu, auf Netzen zu routen sowie Standort- oder Umgebungsanalysen durchzuführen. Mit der Anwendung der Erweiterung können Fragen beantwortet werden, wie z.b. [12] (S. 388): Welches ist die günstigste Route von einem Ort zum anderen? Welches ist die günstigste Route über mehrere Orte von einem Startpunkt zu einem Zielpunkt? Wo liegt die nächstgelegene Einrichtung? Welche Orte können innerhalb einer bestimmten Distanz erreicht werden? Welche Orte können innerhalb einer vorgegebenen Zeitspanne erreicht werden? Wie lautet die Wegbeschreibung für eine bestimmte Route? Die unterschiedlichen Netzwerkanalysearten sind in ArcGIS in fünf Network Analyst Solvers zusammengefasst, mit denen die Netzwerkanalyse-Probleme gelöst werden können. In der ArcGIS Desktop 9.3 Help sind die verschiedenen Network Analyst Solvern erklärt [22]: Best Route (auch Route genannt) Der Network Analyst Solver Route kann zur Netzwerkanalyseart Beste Wege zugeordnet werden. Dieser Network Analyst Sovler deckt sowohl das einfache Routing zwischen einem Start- und einem Zielpunkt als auch die Routenplanung über mehrere Zwischenpunkte und das Reisendenproblem ab, bei dem Start- und Zielpunkt übereinstimmen. Die Orte werden als Network Locations bezeichnet. Die Reihenfolge der zu durchlaufenden Orte kann entweder festgelegt werden oder es kann dem Network Analyst überlassen werden, die beste Reihenfolge zu finden. Closest Facility Der Network Analyst Solver Closest Facility gehört auch zur Netzwerkanalyseart Bester Wege, löst aber komplexere Problemstellungen als der Network Analyst Solver Route. Wie der Name schon sagt, sucht dieser Solver nach nächstgelegenen Einrichtungen. Bei diesem Solver wird zwischen Incidents (Ereignissen, Begebenheiten) und Facilities (Einrichtungen) unterschieden. Ein Incident kann z.b. ein Autounfall sein, Facilities Krankenhäuser. Mit Hilfe dieses Solvers kann das nächstgelegene Krankhaus oder, wenn mehrere in Frage kommen, auch die nächstgelegenen Krankenhäuser vom Unfallort aus ermittelt werden. Dieser Solver kann auch Netzwerkanalysen mit mehrere Incidents und Facilities lösen. Es muss angegeben werden, ob von oder zu den Facilities geroutet werden soll. Des Weiteren kann z.b. eine Zeitbeschränkung festgelegt werden, innerhalb der die Facilites erreicht werden müssen. Service Area Mit dem Network Analyst Solver Service Area können Erreichbarkeitsanalysen um eine oder mehrere Einrichtungen (Facilities) durchgeführt werden. Als Service Area wird ein Gebiet bezeichnet, das von einem Ort innerhalb einer bestimmten Zeit oder einer bestimmten Distanz auf befahrbaren Straßen erreicht werden kann. 5

14 OD Cost Matrix Der Network Analyst Solver OD Cost Matrix OD steht für Origin-Destination berechnet von einer Menge von Startpunkte zu einer Menge von Zielpunkten die Kosten. Kosten können z.b. die Entfernung oder die Zeit sein. Die Kosten werden in diesem Zusammenhang Impedance (Widerstand) genannt. Die Ergebnisse der Berechnung werden zum einen in einer Tabelle geordnet dargestellt. Grafisch werden die Ergebnisse im Gegensatz zu den anderen bisher vorgestellten Solvern als gerade Linien zwischen den Start- und Zielpunkten dargestellt. Vehicle Routing Problem Der Network Analyst Solver Vehicle Routing Problem (VRP) dient zum Lösen von Flottenmanagement-Problemen. Mit diesem Solver können beispielsweise Kunden zu einer Flotte von Fahrzeugen zugeordnet werden und deren Fahrplan berechnet werden. Zeitbeschränkungen, Fahrgeschwindigkeiten, Arbeitszeiten der Fahrer usw. können in die Berechnung mit einbezogen werden. Alle diese Network Analyst Solvers können auch (punkthafte) Barrieren berücksichtigen. Zur Verwendung der Network Analyst Solvers werden sie als Layer in ArcMap hinzugefügt. In dem Buch Designing Geodatabases for Transportation [6] (S. 265ff) von J. Allison BUTLER wird das logische Datenmodell erklärt, das dem Network Analyst zugrunde liegt. Mit Unterstützung von ESRI (Environmental Systems Research Institute) wurde an der University of California in Santa Barbara das Datenmodell Unified Network for Transportation (UNETRANS) für die Transportindustrie in den Jahren 2000 und 2001 entwickelt [44]. Das anschließend überarbeitete Datenmodell bildet heute die Basis als logisches Datenmodell für den Network Analyst. Der Network Analyst erzeugt die am Netzwerk beteiligten Netzwerkelemente (Network Element Classes) aus Feature Classes. Mindestens wird dafür eine Line Feature Class benötigt, die die Segmente des Netzes enthält. Diese wird auch als Edge Feature Source bezeichnet. Wenn mehrere Edge Feature Sources verwendet werden, handelt es sich um ein multimodales Netz. Beim Erzeugen des Transportnetzes werden sog. Network Junctions erstellt. Dies sind Punkte, die die Endpunkte der Line Features und ihrer Kreuzungspunkte repräsentieren. Zusätzlich können noch Abbiegeverbote in Form von Turn Feature Sources generiert werden. Zum Speichern des Netzwerkes dient z.b. eine Geodatabase (GDB), in der die Features Sources in einem Feature Dataset zusammengefasst sind. Ein Feature Dataset ist ein Container in einer Geodatabase, der für mehrere Feature Classes einen einheitlichen Raumbezug definiert [42]. Eine Geodatabase ist nötig, falls es sich um ein Netzwerk mit mehr als einer Edge Feature Source handelt (multimodales Netz). Wird dagegen nur eine Edge Feature Source und eine Turn Feature Source verwendet, kann man auch Shapefiles verwenden. Im Network Analyst werden Netzwerke mit Hilfe von Network Datasets erstellt. Ein Network Dataset ist eine Sammlung topologisch verbundener Netzwerkelemente mit Knoten, Kanten und Abbiegeregeln in einem ungerichteten Fließsystem wie zum Beispiel einem Verkehrsnetz [42]. Die folgenden Kapitel zu Network Datasets in ArcGIS basieren auf der ArcGIS Desktop 9.3 Help [18] Connectivity Unter Connectivity wird in ArcGIS verstanden, wie Netzwerkelemente miteinander verknüpft sind, beispielsweise an welchen Kreuzungspunkten zweier Edge Sources (Edge Feature Sources), wie z.b. 6

15 Straßen und Bahnlinien, man beim Routen von einem Netz zum anderen Netz wechseln kann (Bahnhöfe). Die Connectivity wird mit Hilfe von Connectivity Groups definiert. Dabei werden den Edge und Junction Sources Connectivity Groups zugewiesen. Jede Edge Source kann nur zu einer Connectivity Group gehören. Junction Sources dagegen können auch zu mehr als einer Connectivity Group zugeordnet sein. Dadurch bilden Junction Sources die einzige Möglichkeit, um zwei oder mehr Edge Sources für verschiedene Verkehrsmittel (multimodales Netz) unterschiedlicher Connectivity Groups miteinander zu verbinden. In Tabelle 1 sind beispielhaft für das oben genannte Beispiel den einzelnen Sources Connectivity Groups zugewiesen, damit an den Bahnhöfen vom Auto in den Zug umgestiegen werden kann. Netzwerkelement Edge Source 1 (z.b. Straßen) Connectivity Groups 1 2 x Junction Source (z.b. Bahnhöfe) x x Edge Source 2 (z.b. Bahnlinien) Tabelle 1: Zuweisung von Connectivity Groups x Durch die Zuordnung von mehreren Connectivity Groups zu Junction Sources ist es möglich ein multimodales Netz mit unterschiedlichen Edge Sources zu erstellen. Zur Verknüpfung unterschiedlicher Sources gibt es sog. Connectivity Policies. Dies sind Regeln, an welcher Stelle eines Lines Features oder wie ein Point Feature verknüpft wird. Bei den Line Features wird zwischen der Endpoint und der Any Vertex Connectivity unterschieden. Ist für ein Line Feature die Endpoint Connectivity Policy gewählt, können die Edges nur an deckungsgleichen Endpunkten miteinander verbunden werden. In Abb. 1 ist die Endpoint Connectivity Policy grafisch dargestellt. Abb. 1: Endpoint Connectivity Policy (aus der ArcGIS Desktop 9.3 Help) 1 Wie man am Beispiel in Abb. 1 sehen kann, sind die beiden Kanten nicht miteinander verbunden, da sie keine gemeinsamen Endpunkte haben. Diesen Fall kann man sich auch anhand eines Beispiels aus der Realität erklären: Falls beide Kanten Straßen wären, wäre es nicht erlaubt, am Schnittpunkt abzubiegen. Vermutlich führt dann eine Straße als Brücke über die andere. Somit lassen sich mit der Endpoint Connectivity Policy Über- und Unterführungen (Overpasses, Underpasses) modellieren. Bei der Any Vertex Connectivity Policy werden nicht nur die Endpunkte der Kanten (Edges) sondern alle Stützpunkte verwendet. Kanten werden dann an deckungsgleichen Stützpunkten miteinander verbunden. An sich kreuzenden Kanten wird aus dem gemeinsamen Sützpunkt ein Kreuzungspunkt, Junction genannt. Abb. 2 zeigt die Any Vertex Connectivity Policy. 1 [24] 7

16 Abb. 2: Any Vertex Connectivity Policy (aus der ArcGIS Desktop 9.3 Help) 1 Während sich die Endpoint und die Any Vertex Connectivity Policies auf Edge Feature Sources beziehen, gibt es für Junction Feature Sources die Connectivity Policies Honor und Override. Wie schon erwähnt, können Edges aus zwei verschiedenen Connectivity Groups nur über Junctions miteinander verknüpft werden. Diese Junctions müssen dann in beiden Connectivity Groups der Edge Sources liegen (siehe Beispiel Tabelle 1). Hat die Junction Source die Connectivity Policy Honor, respektiert sie die Connectivity Policies der Edges Sources. Ist einer Edge Source die Connectivity Policy Endpoint zugeordnet, so kann sie nur über Endpunkte mit Junctions verknüpft werden, auch wenn die Edge Source Stützpunkte (vertices) enthält, die mit Junctions zusammenfallen. Ist die Connectivity Policy der Edge Source Any Vertex, so wird die Edge Source sowohl über Endpunkte als auch über Stützpunkte mit der Junction Source verbunden. Ist der Junction Source dagegen die Connectivity Policy Override zugeordnet, werden die Connectivity Policies der Edge Sources ignoriert. Junction Sources werden dann sowohl mit Endpunkten als auch mit Stützpunkten der Edge Sources verknüpft, auch wenn deren Connectivity Policy Endpoint ist. Damit werden die Connectivity Policies der Edge Sources mit der Any Vertex Connectivity Policy überschrieben. Neben den Connecivity Policies gibt es noch sog. Elevation Fields, mit denen die Connectivity an Endpunkten von Kanten verfeinert werden kann. Für jeden Endpunkt eines Edge Features wird dafür in der Edge Feature Source ein Field erzeugt. Durch Auswertung dieser Elevation Fields kann kontrolliert werden, welche Edges, die der gleichen Connectivity Group angehören, an Kreuzungen miteinander verbunden werden. In Abb. 3 ist ein Beispiel einer solchen Situation gezeigt. Abb. 3: Defintion von Elevation Fields (aus der ArcGIS Desktop 9.3 Help) 2 In dem Beispiel aus Abb. 3 gehören alle Edges der gleichen Connectivity Group an und haben die Connectivity Policy Endpoint. Wären keine Elevation Fields definiert, könnte man an dieser Kreuzung von jeder Edge zu jeder anderen Edge abbiegen. Um dies zu verhindern werden in die Edge Feature 1 [24] 2 [24] 8

17 Sources zwei Fields eingefügt, die die Elevation der beiden Endpunkte der Edges definieren. In diesem Beispiel hat beispielsweise die Kante EF3 am sichtbaren Endpunkt die Elevation 0. Durch die Defintion von Elevations können an Kreuzungen von Endpunkten nur Edges miteinander verbunden werden, die die gleiche Elevation haben. In dem Beispiel trifft das auf die Kanten EF1 und EF2 (Elevation = 1) sowie auf die Kanten EF3 und EF4 (Elevation = 0) zu. Damit wid z.b. verhindert, dass von der Kante EF1 zur Kante EF4 abgebogen werden kann. Elevation Fields können beispielsweise verwendet werden, um Brücken oder Tunnel zu definieren Network Attributes Um das Netzwerk durchlaufen zu können werden den Netzwerkelementen Eigenschaften Network Attributes zugeordnet. Beispiele für Network Attributes sind Fahrtzeit, Fahrtgeschwindigkeit, Straßenlänge, Einbahnstraßen und Sperrungen von Straßen oder Barrieren. Beziehen sich die Network Attributes auf Edge Sources, können sie für jede Fahrtrichtung einzeln definiert werden. Dies wird z.b. bei Einbahnstraßen angewandt. Network Attributes haben folgenden Grundeigenschaften [25]: Name Usage Type Units Data Type Use by Default Über den Usage Type wird definiert, in welcher Form das Network Attribute in Netzwerkanalysen verwendet wird. Dabei wird zwischen folgenden Typen unterschieden: Cost Der Usage Type Cost stellt Kosten bzw. Gewichte von Netzwerkelementen (siehe Kapitel 2.1) dar. Dies können beispielsweise die Straßenlänge oder die Fahrtzeit sein. Beziehen sich Kosten auf Edges, sind sie entlang der Kanten aufteilbar. So kostest die Fahrt entlang der halben Kante nur halb so viel, als wenn die Kante auf der ganzen Länge durchfahren werden würde. Bei einem negativen Wert ist die Edge unpassierbar. Network Attributes, die den U- sage Type Cost haben, können verwendet werden, um Kosten zu minimieren. Dies wird im Network Analyst auch als Impedance (Widerstand) bezeichnet. So kann damit beispielsweise die kürzeste oder schnellste Route berechnet werden. Descriptor Der Usage Type Descriptor ähnelt dem Usage Type Cost. Doch im Gegensatz zum Usage Type Cost ist dieser nicht entlang einer Kante aufteilbar. Damit ist der Wert eines solchen Network Attributes nicht von der Länge einer Kante abhängig, sondern bleibt konstant. Verwendet wird dieser Usage Type z.b. für die Angabe von Höchstgeschwindigkeiten oder maximal erlaubten Fahrzeughöhen. Network Attributes mit diesem Usage Type können nicht als Impedance dienen. Restriction Mit Hilfe des Usage Types Restriction lässt sich das Durchlaufen von Netzwerkelememten unterbinden. Im Kontext des Network Analyst wird von restricted (unpassierbar) und traversable (passierbar) gesprochen. Verwendet wird dieser Usage Type z.b. für Einbahnstraßen, die 9

18 abhängig von der Straßenrichtung gesperrt oder für die Durchfahrt freigegeben sind, für fahrzeugtypabhängige Fahrverbote oder für Barrieren. Hierachy Mit dem Usage Type Hierachy lassen sich Ordnungen definieren. Diese können z.b. verwendet werden, um Straßenklassen zu ordnen, so dass größere Straßen wie Autobahnen vor lokalen Straßen bevorzugt werden. Im Network Analyst werden diese Hierachien über sog. Ranges (Hierachiebereiche) zu einer der folgenden Klassen zugeordnet: Primary Roads, Secondary Roads oder Local Roads. In Tabelle 2 ist aufgelistet, welche Einheiten (Units) und Datentypen (Data Types) die verschiedenen Usage Type haben können. Usage Unit Data Types Type Distance Time Boolean Integer Float Double Cost x x - x x x Descriptor - - x x x x Restriction - - x Hierarchy x - - Tabelle 2: Network Attributes: Erlaubte Units und Data Types pro Usage Type 1 Die Network Attributes können entweder bei der Erzeugung des Netzwerkes oder anschließend nach der Erstellung definiert werden. Die Werte der Network Attributes werden über sog. Evaluators (Bewerter) zugewiesen. Für jede im Netzwerk beteiligte Source, z.b. Straßennetz, Barrieren oder Abbiegeverbote, kann ein eigener Evaluator gesetzt werden. Bei Edge Sources kann zusätzlich noch zwischen der digitalisierten Richtung (Direction) unterschieden werden. Die Direction FROM-TO entspricht dabei der Richtung, in der die Edge erfasst wurde, die Direction TO-FROM ist die Gegenrichtung. In ArcGIS wird zwischen folgenden Evaluators unterschieden [23]: Field Evaluator Um dem Network Attribute einen Wert zuzuweisen wird beim Field Evaluator, wie schon der Name sagt, der Wert aus einem Field (Spalte) der Source ausgelesen. Dies kann beispielsweise die Straßenlänge sein. Field Expression Evaluator Beim Field Expression Evaluator dagegen können zur Bestimmung der Werte Berechnungen mit einem oder mehreren Fields vorgenommen werden. Dazu wird ein VBScript (Visual Basic Script) geschrieben, das auf die Fields der Source zurückgreift, für den der Evaluator definiert ist. Ein Beispiel hierfür ist die Umrechnung von Einheiten. Constant Evaluator Beim Constant Evaluator wird dem Wert eines Network Attributes eine Konstante zugeordnet. Dieser Wert wird dann für alle Datensätze einer Source verwendet. Dieser Evaluator kann beispielsweise für Abbiegeverbote verwendet werden. Function Evaluator Mit dem Function Evaluator können Werte über Multiplikationen/Divisionen oder logische Funktionen mit anderen Network Attributes, Parametern (siehe unten) oder Konstanten be- 1 [25] 10

19 rechnet werden. Hat das Network Attribute einen numerischen Datentyp, so wird der Wert über eine Multiplikation oder Division berechnet. Dies kann beispielsweise verwendet werden, um die Fahrtzeit um einen bestimmten Faktor zu verlängern (Fahrtzeit * 2). Fahrtzeit wäre dann ein anderes Network Attribute, 2 eine Konstante. Ist dem Network Attribute dagegen der Datentyp Boolean zugeordnet (Restriction), so wird der Wert über einen logischen Ausdruck, d.h. Vergleich ermittelt. Dies kann z.b. ein Vergleich zwischen der erlaubten Fahrzeughöhe (Network Attribute) und der aktuellen Fahrzeughöhe (Parameter) sein (erlaubte Fahrzeughöhe < aktuelle Fahrzeughöhe). Ist der Vergleich wahr, so ist das aktuelle Netzwerkelement gesperrt (Restriction = true). Global Turn Delay Evaluator Mit dem Global Turn Delay Evaluator können beim Übergang von einer Edge zu einer anderen Edge, d.h. beim Abbiegen, Kosten berechnet werden. Diese können abhängig sein vom Winkel zwischen den beiden Edges oder deren Hierachien. VBScript Evaluator Der VBScript Evaluator ähnelt dem Field Expression Evaluator. Im Gegensatz zu diesem greift der VBScript Evaluator aber nicht auf Fields zurück, sonderen kann andere Network Attributes oder Parameter (siehe unten) verwenden. Bis auf den VBScript Evaluator werden die Werte der Evaluators während der Erzeugung des Netzwerkes berechnet. Der VBScript Evaluator berechnet sie erst dann, wenn sie im Netzwerk während einer Analyse benötigt werden. Parameter können im Network Analyst für Network Attributes definiert werden, um beispielsweise die aktuelle Fahrzeughöhe oder das Fahrzeuggewicht anzugeben [26]. Diese Parameter können dann in den Evaluators Function Evaluator oder VBScript Evaluator verwendet werden Turns Mit Turns werden im Nework Analyst von ArcGIS Abbiegeverbote modelliert. Die folgenden Informationen zur Modellierung von Abbiegeverboten in ArcGIS stammen aus der ArcGIS Desktop 9.3 Help [21]. Der Network Analyst kann neben einfachen Abbiegeverboten zwischen zwei Edges ( simple turning movement ) auch multiedge turns (mit mehr als zwei beteiligten Edges) bearbeiten. Die Mindestanzahl der Edges liegt bei zwei. Maximal sind 20 Edges erlaubt. Abb. 4 stellt eine Übersicht über die von ArcGIS unterstützten Abbiegeverbote dar. Abb. 4: Abbiegeverbote (Turns) im Network Analyst (aus der ArcGIS Desktop 9.3 Help) 1 1 [21] 11

20 Wie man in Abb. 4 sehen kann, wird zwischen folgenden Abbiegeverboten unterschieden: Links-Abbiegeverbot (Left) Rechts-Abbiegeverbot (Right) Verbot geradeaus zu fahren (Straight transition) Fahrtrichtungswechsel (U-turn) Im Network Analyst werden Abbiegeverbote mit Hilfe von Turn Feature Classes erstellt, die Polyline Features enthält. Um Turn Feature Classes verwenden zu können, müssen sie Teil eines Network Datasets sein. Network Attribute Evaluators (siehe Kapitel 2.3.2) können zur Hilfe genommen werden, um festzulegen, wann ein Feature aus der Turn Feature Class als Abbiegeverbot dient, d.h. gesperrt ist. Tabelle 3 stellt den Aufbau der Turn Feature Class dar. Zu diesen Fields können noch weitere Fields durch den Anwender hinzugefügt. Field Datentyp Beispielwerte Beschreibung OBJECTID Object ID 0, 1, interne Feature ID des Turns Shape Geometry Polyline von ArcGIS automatisch erzeugtes Shape Field Edge1End Text Y, N Über dieses Field wird definiert, durch welches Ende der der ersten Edge das Abbiegeverbot führt (Y = Beginn, N = Ende) Edge1FCID Integer 1, 2, Feature Class ID des Line Features für Edge 1 Edge1FID Integer 34, 78, 299, Feature ID des Line Features für Edge 1 Edge1Pos Double 0, 0.3,, 1 Position auf dem Line Feature, die die erste Edge des Turns repräsentiert Edge2FCID Integer 1, 2, Feature Class ID des Line Features für Edge 2 Edge2FID Integer 12, 90, 429, Feature ID des Line Features für Edge 2 Edge2Pos Double 0, 0.25,, 1 Position auf dem Line Feature, die die zweite Edge des Turns repräsentiert [Edge3FCID] Integer 1, 2, Feature Class ID des Line Features für Edge 3 [Edge3FID] Integer 2, 104, 189, Feature ID des Line Features für Edge 3 [Edge3Pos] Double 0, 0.8,, 1 Position auf dem Line Feature, die die dritte Edge des Turns repräsentiert [ ] Tabelle 3: Schema der Turn Feature Class 1 Möchte der Anwender Abbiegegebote modellieren, müssen diese in Abbiegeverbote umgerechnet werden. Als Global Turns werden alle Abbiegesituationen bezeichnet, für die kein eigenes Turn Feature in einer Turn Feature Class definiert ist. Für diese Global Turns gibt es einen Evaluator mit dem Namen Global Turn Delay Evaluator (siehe Kapitel 2.3.2). 1 [21] 12

21 Directions Im Network Analyst können sog. Directions definiert werden, die zur Wegbeschreibung von Routen verwendet werden. Beispiele für Direction-Eigenschaften sind [20]: Straßenlängen Reisezeit Straßennamen Straßenschilder Grenzinformationen Neuerungen in ArcGIS 10 Mit der neuen Version ArcGIS 10, deren Release im Sommer 2010 ist, gibt es auch einige Neuerung den Network Analyst betreffend. In diesem Kapitel werden einige davon vorgestellt. Die Informationen basieren auf einem Vortrag von Günter DÖRFFEL [10], der im April 2010 in Kranzberg gehalten wurde. Mit ArcGIS 10 kommt ein neuer Solver mit dem Namen Location-Allocation Solver hinzu. Mit diesem können Standort- oder Filialplanungen durchgeführt werden. Dieser Solver sucht aus mehreren Standorten den geeignetsten oder ungeeignetsten heraus. Zu den bisherigen Network Analyst Solvern wurden einige neue Funktionen hinzugefügt. Neben punkthaften Barrieren werden jetzt auch linien- und flächenhafte Barrieren unterstützt. Beim Laden der Standorte (Network Locations) gab es eine wichtige Neuerung. Bisher war es so, dass beim Laden der Network Locations, die Standorte auch auf nicht passierbare Netzelemente fallen konnten. Mit einigem Aufwand konnte man das umgehen. In ArcGIS 10 kann der Nutzer jetzt wählen, ob Netzelemente, die nicht passierbar sind, beim Laden der Network Locations nicht berücksichtigt werden. Des Weiteren wurden in ArcGIS 10 die Performance der Netze sowie die Fahrtzeitberechnungen verbessert. 13

22 3. OpenStreetMap Dieses Kapitel führt in das Thema OpenStreetMap ein. Es werden Idee und Entstehung beschrieben sowie das zugrunde liegende Datemodell und der aktuelle Einsatz von OSM-Daten in ArcGIS erläutert. Das Kapitel dient als Basis für die prototypische Anwendung, deren Konzeption und Umsetzung im nachfolgenden Kapitel beschrieben wird Einführung Das Projekt OpenStreetMap (OSM) wurde im Jahr 2004 von Steve Coast [62] in Großbritannien [15] (S. 3) gegründet aufgrund seiner Unzufriedenheit mit der Lizenzpolitik des Vereinigten Königreiches [16] (S: 18) und den Preisen offizieller Karten [62]. OpenStreetMap wird als freie Weltkarte [15] (S. 3) bezeichnet, zu der jeder beitragen kann. Die Karte entsteht in Gemeinschaftsarbeit ( collaborative effort ) [14] (S. 20) nach dem Wiki-Prinzip und gehört zum Crowdsourcing. Beim Crowdsourcing wird Arbeit auf die Arbeitskraft und Intelligenz von vielen Freizeitarbeitern ausgelagert [172]. Steve Coast äußerte sich dazu in einem Interview mit dem österreichischen derstandard.at im Juli 2009 [40]: Er würde OSM durchaus mit Wikipedia [171] vergleichen. Der Unterschied bestehe aber darin, dass bei OSM Referenzdaten und damit Fakten gesammelt werden würden. Bei der Wikipedia dagegen entstünden Dokumente, die auf einer subjektiven Meinung basieren könnten. Im April 2010 überschritt die Anzahl der Mitglieder die Marke von Personen [119]. Allerdings ist nur ein Bruchteil davon regelmäßig aktiv [8] [66]. Unter einer freien Weltkarte wird verstanden, dass die gesammelten Daten unter einer bestimmten Lizenz stehen, die es jedem erlaubt sie zu nutzen ohne Lizenzgebühren entrichten zu müssen. Die zur OSM-Datenbank beigetragenen Daten stehen unter der Creative Commons Attribution-Share Alike 2.0 -Lizenz [61]. Auf der Internetseite von Creative Commons [37] steht hierzu [38]: Die genannte Lizenz erlaubt dem OSM-Nutzer die Daten zu verbreiten, zu vervielfältigen und öffentlich zugänglich zu machen. Des Weiteren dürfen sie auch verändert und bearbeitet werden [38]. Die Nutzung ist aber nur dann erlaubt, wenn genannt wird, woher die Daten stammen (in diesem Fall OSM), unter welcher Lizenz sie stehen und wenn die (evt. veränderten) Daten bei der Weitergabe unter den gleichen Bedingungen weitergegeben werden. Auf der deutschen OSM-Internetseite wird ergänzt, dass mit dieser Lizenz auch die gewerbliche Nutzung ausdrücklich gestattet ist [61]. Die Erfassung von Daten wird auch als Tagging bezeichnet. Dieser Begriff lehnt sich an die Attributierung von Daten an, die in OSM mit sog. OSM-Tags geschieht (siehe Kapitel 3.2.1). Jeder kann zum Aufbau der freien Weltkarte beitragen. Dies kann beispielsweise dadurch geschehen, dass Daten mit einem GPS-Gerät (Global Positioning System) neuerfasst oder bereits georeferenzierte Daten verbessert oder ergänzt werden. Damit zählen die Daten zum Bereich User Generated Content (UGC), da OSM alle von der OECD (Organisation for Economic Co-operation and Development) definierten Kriterien erfüllt [173]: Die Inhalte müssen veröffentlicht werden und müssen in kreativer Eigenleistung außerhalb von professionellen Routinen entstanden sein. OSM wird auch zu Volunteered Geographic Information (VGI) gezählt, da die Daten von Freiwilligen erfasst werden [7] (S. 50ff). Die zu erfassenden Karteninhalte sind dabei nicht beschränkt oder reglementiert. Das Datenformat (siehe Kapitel 3.2) ist so definiert, dass alle Informationen mit einem geografischen Bezug gleich 14

23 welcher Thematik hinzugefügt werden können. So enthält die Karte im Vergleich zu proprietären Karten auch ungewöhnliche Inhalte, wie z.b. die Tiergehege des Berliner Zoos zeigen (siehe Abb. 51 und Abb. 52 im Anhang). Werden die Daten nicht selbst vor Ort erfasst, sondern werden andere Quellen zur Hilfe hinzugenommen, muss geklärt sein, dass diese ebenfalls unter einer freien Lizenz zur freien Nutzung stehen. So dürfen i.d.r. amtliche Karten, Satalliten- oder Luftbilder nicht digitalisiert werden. Viele Gebiete der Erde sind verglichen mit anderen Karten wie Google Maps [49] bereits detaillierter erfasst. Dabei stechen die Länder mit einer großen, aktiven OSM-Community [15] (S. 17) hervor (z.b. Deutschland und England). In diversen ländlichen Regionen gibt es aber weiterhin noch Erfassungsbedarf [16] (S. 29). Das in Karlsruhe ansässige Unternehmen Geofabrik [46], dessen Geschäftsmodell auf der Bereitstellung von Mehrwertdiensten auf Basis von OSM basiert, stellt das Kartenvergleichstool Map Compare [48] zur Verfügung, mit dem OSM mit Google-Karten verglichen werden kann. Deutlich werden diese Unterschiede in Abb. 5, die Karten von OSM und Google Maps im Vergleich für eine Region in Saudi-Arabien zeigt. Dies ist ein Beispiel dafür, dass manche Orte von der OSM-Community detaillierter erfasst worden sind als von Google und seinen Partnerfirmen. Abb. 5: Vergleich OpenStreetMap - Google Maps, Thuwal, Saudi-Arabien 1 Doch es gibt in OSM noch viele weiße Flecken. Ein Beispiel hierfür ist die Abb. 6. Während in OSM nur die Durchgangsstraßen erfasst sind, bietet Google detaillierte Informationen zu Straßen und Umgebung. Abb. 6: Vergleich OpenStreetMap - Google Maps, Formosa, Brasilien 2 1 [48] 2 [48] 15

24 Ein anderes Tool, um den Karteninhalt und die Lage der Objekte zu vergleichen, ist transparent map [162]. Im Gegensatz zum Vergleichstool von der Geofabrik, sind hier die Karten nicht nebeneinander dargestellt, sondern übereinander gelegt, wobei mit einem Regler die Transparenz eingestellt wird. Mit diesem Tool können OSM-Karten mit Yahoo- [174] und Google-Karten [49] verglichen werden. Wie man schon am oben genannten Beispiel zum Berliner Zoo sehen kann, enthält OSM Daten, die i.d.r. von anderen Datenanbietern nicht erfasst werden (siehe Anhang Abb. 51 und Abb. 52). Damit bildet OSM eine Alternative zu diesen Anbietern. Es muss jedoch im Einzelfall immer geprüft werden, ob die Daten für das gewünschte Gebiet und die gewünschte Anwendung ausreichend sind und eine einheitliche inhaltliche Auflösung und die gewünschte Vollständigkeit haben. Im Gegensatz zu den meisten kommerziellen Geodatenanbietern gibt es bei OSM keine zentral geregelte Qualitätskontrolle. STENGEL & POMPLUN äußern sich dazu [16] (S. 29): Ähnlich wie bei Wikipedia erfolge die Qualitätskontrolle durch die Mitarbeit vieler Mitglieder. Diese Mitglieder kennen sich oft vor Ort aus und seien damit Experten für dieses Gebiet. Bei Unklarheiten fänden Diskussionen und Abstimmungen im OpenStreetMap-Wiki (OSM-Wiki) [71] statt. Das OSM-Wiki ist die offizielle Austausch- und Kommunikations-Plattform für OSM-Nutzer. Dort gibt es auch eine Übersicht über die dargestellten Inhalten sowie Empfehlungen, wie erfasste Daten attributiert werden können [120]. Diese Internet-Seite richtet sich sowohl an Interessierte und Einsteiger, die eine Einführung in das Projekt erhalten wollen, als auch an fortgeschrittene Mitglieder der OSM-Community. Zusätzlich gibt es verschiedene Qualitätstools wie OpenStreetBugs [59], auf der Fehler und Unklarheiten gemeldet werden können. Daneben gibt es auch Tools, die automatisiert nach häufigen Fehlern suchen wie OSM Inspector [67] oder Maplint. Maplint kann auf der OSM- Website [63] als Layer über die Kartenoptionen (blaues Plus links neben der Karte) eingebunden werden. Weitere Qualitätskontrolltools sind im OSM-Wiki unter dem Stichwort Projects#Quality_Control aufgelistet [134]. Für die in der OSM-Datenbank gehaltenen Daten gibt es verschiedene Renderer, mit deren Hilfe die Daten grafisch aufbereitet und präsentiert werden. Die Abbildungen Abb. 51 und Abb. 52 aus dem Anhang zeigen das gleiche Gebiet (Berliner Zoo). Die Karte aus Abb. 51 wurde von Mapnik [53] [126], die Karte aus Abb. 52 von Osmarender [126] gerendert. Die Renderer unterscheiden sich durch die unterschiedlichen Inhalte, die dargestellt werden und durch unterschiedliche Legenden. Eine Auflistung verschiedener OSM-Renderer gibt es im OSM-Wiki [133]. Nachdem sich in den ersten Jahren nach der Projektgründung auf die Datenerfassung konzentriert wurde, werden immer mehr Projekte realisiert, die sich mit der Nutzung der Daten beschäftigen [16] (S. 21). Neben den oben genannten Renderern und Hilfstools zur Qualitätskontrolle [134] gibt es auch noch andere Anwendungen sowohl fürs Internet als auch für mobile Endgeräte, die auf OSM- Daten basieren. Einige davon sind im OSM-Wiki aufgelistet [133]. Ein Beispiel hierfür ist die OpenCycleMap [57] eine Karte, die Inhalte speziell für Fahrradfahrer darstellt. Für diese Arbeit interessante Anwendungen sind Routingdienste, die auf OSM-Daten basieren. Auf diese wird im Kapitel 4.4 näher eingegangen. 16

25 3.2. Datenmodell In diesem Kapitel wird das OSM-Datenmodell im Hinblick auf die allgemeine Verwendung in Netzwerkanalysen dargestellt. Die Erläuterungen zum Datenmodell sind nur ein Ausschnitt, es werden lediglich die für diese Arbeit relevanten Themen dargestellt Grundlegendes Datenmodell Das OSM-Datenmodell bildet die Basis für das Modell der OSM-Datenbank, in dem die Daten gespeichert werden, und für das XML-Format (Extensible Markup Language) (*.osm), das zum Austausch von OSM-Daten dient. Das grundlegende Datenmodell befindet sich zum Zeitpunkt der Erstellung dieser Arbeit in der Version 6 (v0.6) [70] und ist sehr einfach aufgebaut. Es enthält nur drei Datentypen, Nodes, Ways und Relations, die im OSM-XML-Format durch XML-Tags repräsentiert werden(<node>, <way>, <relation>) [15] (S. 49). Abb. 53 aus dem Anhang zeigt eine vereinfachte Darstellung des Datenmodells. Mit Nodes werden punkthafte Objekte dargestellt, wie z.b. Stützpunkte von linienhaften Objekten (Ways) oder auch Points of Interest. Mit Ways werden in erster Linie linienhafte Objekte erstellt. Ways sind aus einer Folge von Stützpunkten (Nodes) aufgebaut. Die Reihenfolge der referenzierten Nodes gibt dabei die Richtung des Ways an. In den meisten Fällen ist die Richtung eines Ways nicht relevant. Sie wird jedoch z.b. verwendet, um die Richtung von Einbahnstraßen zu definieren. Des Weiteren werden Ways auch benutzt, um flächenhafte Objekte zu erzeugen. Dazu muss u. a. der letzte Stützpunkt des Ways mit dem ersten übereinstimmen [15] (S. 51). Mit Relations werden Beziehungen zwischen verschiedenen Objekten wie Nodes, Ways oder Relations selbst definiert [15] (S. 52). Nodes, Ways und Relations, die an einer Relation teilnehmen, werden als Member bezeichnet. Ein Beispiel für Relations sind Abbiegevorschriften. In Listing 47 aus dem Anhang ist ein Auszug aus einer OSM-XML-Datei gezeigt, die über die Exportfunktion von der OSM-Website heruntergeladen wurde [63]. Wie man aus diesen Auszug entnehmen kann, sind die Daten für den angeforderten Ausschnitt (siehe bounds-xml-tag) im osm-xml-tag enthalten. Innerhalb dieses XML-Tags werden standardmäßig zunächst die Nodes, anschließend die Ways und zum Schluss die Relations aufgelistet [15] (S. 53). Die node-, way- und relation-xml-tags enthalten zum einen XML-Attribute (z.b. id ) und evt. eine Menge weiterer XML-Tags (z.b. <nd>) [15] (S ). Tabelle 28 und Tabelle 29 im Anhang enthalten die Definition der OSM-Tags und deren Attribute. Die in diesen Tabellen aufgeführten Eigenschaften zu den primitiven Datentypen sind nicht vollständig. Nähere Informationen zur Definition der grundlegenden Datentypen und des OSM-Datenmodells können in OpenStreetMap Die freie Weltkarte nutzen und mitgestalten von Frederik RAMM und Jochen TOPF [15] und im OSM-Wiki [71] [78] [79] nachgelesen werden. Wie man aus Tabelle 28 und Tabelle 29 entnimmt, kann jedem grundlegenden Datentyp (Node, Way, Relation) eine beliebige Menge an Tags (tag) zugewiesen werden. Zur Unterscheidung von XML-Tags (z.b. <node>, <way>, <relation>, <tag>) werden diese Tags im Weiteren als OSM-Tags bezeichnet. OSM-Tags werden benutzt, um Nodes, Ways und Relations ihre Eigenschaften (siehe Kapitel 3.2.2) zuzuweisen, und bestehen aus einem Key-Value-Paar. Key (k) ist dabei ein Schlüssel und Value (v) der Wert, der sich auf den Schlüssel bezieht. Seit der Version 6 des OSM-Formats ist festge- 17

26 legt, dass in jedem Objekt der gleiche Schlüssel nur einmal vorkommen darf [15] (S. 52). OSM-Tags gelten immer für die gesamte Länge eines Ways. In der Definition dieser OSM-Tags besteht die Flexibilität des OSM-Datenformats, denn jeder, der Daten erfasst, kann frei Schlüssel und Werte erfinden. Dennoch ist es in der Praxis üblich, dass man sich auf Konventionen einigt. Dies ist vor allem deshalb wichtig, da beim Rendern der Karte entschieden werden muss, welche Objekte auf der Karte dargestellt werden [15] (S. 59). Die freie Wahl von Schlüssel und Werten hat somit Vor-, aber auch Nachteile. Der Vorteil besteht darin, dass diejenigen, die die Karte in ihrer Freizeit erweitern, sich nicht um ein kompliziertes Datenmodell kümmern müssen. Andererseits ist es aber auch ein Nachteil für Programme, die OSM-Daten verarbeiten. Denn man kann nicht sichergehen, dass man beispielsweise alle Fahrradwege erkennt, da sie unterschiedlich definiert sein können, deren Definition nicht immer bekannt ist Map Features Map Features sind Eigenschaften der grundlegenden Datentypen (Nodes, Ways und Relations) [87]. Diese Map Features werden mit Hilfe der in Kapite 3.2 erläuterten Key-Value-Paare zugewiesen. Im Folgenden werden Verkehrswege und Verkehrsbeschränkungen vorgestellt, die insbesondere für Netzwerkanalysen interessant sind. Weitere Map Features sind u.a. Orte, Points of Interest, Gebäude, Adressen, Vegetation, Gewässer und Grenzen [120]. Auf diese wird aber in dieser Arbeit nicht näher eingegangen Verkehrswege Im OSM-Datenformat wird zwischen folgenden Verkehrswegen unterschieden: Wege Eisenbahn Seilbahnen Wasserläufe Wege lassen sich zusätzlich in Straßen, Fahrrad- und Wirtschaftswege aufteilen [87]. Da in der Arbeit ein netzwerkfähiges Straßennetz und ein netzwerkfähiges Fahrradnetz erstellt werden soll, beschränken sich die folgenden Erläuterungen zu den Verkehrswegen auf Straßen und Fahrradwege. Informationen zu den anderen Verkehrswegen können im OSM-Wiki [119] nachgelesen werden Straßen Straßen werden in den meisten Fällen mit Hilfe des highway-osm-tags erfasst. Ein Sonderfall bildet die Definition von geplanten und im Bau befindlichen Straßen, der im Kapitel erläutert ist. Bis auf wenige Ausnahmen sind Straßen Ways. Über den Wert des Schlüssels highway wird die Straßenklassifizierung vorgenommen. Um Straßen genau zu definieren werden weitere OSM-Tags verwendet, um z.b. den Straßennamen (OSM-Tag name), die Straßennummer/Referenz (OSM-Tag ref) [116] oder Zugangsbeschränkungen (siehe Kapitel ) zuzuweisen. In Listing 1 ist ein Beispiel für eine Straße dargestellt. 18

27 <way id=" " user="kalle_anka" uid="200015" visible="true" version="4" changeset=" " timestamp=" t22:20:23z"> <nd ref=" "/> <nd ref=" "/> <nd ref=" "/> <tag k="highway" v="residential"/> <tag k="maxspeed" v="30"/> <tag k="name" v="schönbichlstraße"/> <tag k="oneway" v="yes"/> </way> Listing 1: Beispiel für eine Straße (Freising) 1 Dieses Beispiel zeigt eine Einbahnstraße (oneway = yes, siehe Kapitel ) aus einem Wohngebiet (highway = residential) [91], die einer Geschwindigkeitsbegrenzung (maxspeed = 30, siehe Kapitel ) unterliegt. In Tabelle 30 im Anhang sind die wichtigsten Liniengeometrien für das highway-osm-tag bezogen auf Deutschland aufgeführt. Diese Klassifikation basiert auf der Straßen-Klassifikation aus Großbritannien, wo OSM seine Wurzeln hat [15] (S. 63). Je nach Land haben die highway-werte eine andere Bedeutung [108]. Nähere Informationen zur Verwendung des highway-osm-tags für Deutschland und andere Länder können im OSM-Wiki nachgelesen werden [85] [91] [107] [123] Fahrradwege und von Fahrradfahrern benutzbare Wege In diesem Kapitel werden Fahrradwege bzw. von Fahrradfahrern benutzbare Weg vorgestellt. Bei von Fahrradfahrern benutzbaren Wegen wird zwischen folgenden Fällen unterschieden: Straße kann von Fahrradfahrern benutzt werden. Straße enthält einen (oder mehrere) ausgewiesene Fahrradstreifen [122] baulich getrennter Fahrradweg [122] Ob ein Weg von Fahrradfahrern befahren werden darf, hängt von den OSM-Tags eines Ways ab. Wie in Kapitel erläutert, haben Wege das OSM-Tag highway. Für diesen Schlüssel gibt es den Wert cycleway [144], der einen Weg explizit als Fahrradweg ausweist. Je nach Land darf dieser Weg entweder nur von Fahrradfahrern oder auch von anderen Verkehrsteilnehmern benutzt werden. Doch auch andere Werte, wie z.b. primary, secondary oder tertiary lassen Fahrradfahrer zu. Nähere Informationen dazu befinden sich im Kapitel zur Beschränkung der Beförderungsart (Kapitel ). Zusätzlich zum highway-osm-tag kann noch ein cycleway-osm-tag [104] gesetzt werden, mit dem näher beschrieben wird, um was für einen Weg es sich handelt. In Tabelle 4 sind die gebräuchlichsten Werte aufgelistet, die das cycleway-osm-tag annehmen kann. lane track Wert Bedeutung Radfahrstreifen (auf Fahrbahn, mit Markierungen) baulich abgesetzter Radweg (entspricht highway = cycleway)

28 Wert opposite_lane opposite_track opposite Bedeutung Radfahrstreifen entgegen der Fahrtrichtung einer Einbahnstraße baulich abgesetzter Radweg entgegen der Fahrtrichtung einer Einbahnstraße Einbahnstraße ohne eigenen Radweg, die für Radfahrer in Gegenrichtung geöffnet ist Tabelle 4: Fahrradwege (Schlüssel cycleway) 1 Erläuterungen zu Einbahnstraßen befinden sich im Kapitel Neben Radwegen gibt es im OSM-Format auch Radrouten [80]. Radrouten sind i.d.r. touristische, ausgeschilderte bzw. in Karten verzeichnete Radrouten [81], die auch über normale, nicht explizit für Radfahrer ausgeschilderte Straßen führen können. Während Radwege als Ways getaggt werden, werden Radrouten als Relations erfasst [137] Brücken und Tunnel In OSM werden Brücken mit dem OSM-Tag bridge [104] und Tunnel mit dem OSM-Tag tunnel [118] gekennzeichnet. Liegen mehrere Straßen übereinander, kann zusätzlich das OSM-Tag layer verwendet werden [118]. Dieses OSM-Tag gibt die Ebene der Straße an. Als Werte sind Zahlen von -5 bis 5 erlaubt. Straßen mit einem kleineren layer-wert liegen weiter unten. Dieses OSM-Tag wird von den Renderen ausgewertet, um Brücken und Tunnel grafisch richtig darzustellen. Brücken und Tunnel so erfasst werden, dass sie am Kreuzungspunkt mit anderen Straßen oder linienhaften Objekten keinen gemeinsamen Node haben Verkehrsbeschränkungen Ein wichtiger Bereich für das Routing sind die von den Erfassern attributierten Verkehrsbeschränkungen, auch Restrictions genannt [124]. Eine Karte, in der allein Straßen in ihrer geografischen Lage erfasst sind, hat für die Routenplanung nur einen geringen Wert. Was nützt einem Nutzer eine Routenplanung, wenn er auf der Fahrt feststellt, dass er an einer bestimmten Stelle nicht weiterfahren darf, da die Straße für ihn in dieser Richtung gesperrt ist? Er wird über die mangelhafte Routenplanung verärgert sein und einen Umweg in Kauf nehmen müssen vielleicht in einer Gegend, in der er sich nicht auskennt und er sich auf die Routenplanung verlassen wollte. Erst durch die Erfassung von Verkehrsbeschränkungen wie z.b. Einbahnstraßen und Abbiegeverbote wird eine Karte für Routinganwendungen wertvoll. Im Folgenden werden einige der wichtigsten Verkehrsbeschränkungen vorgestellt. Tabelle 5 zeigt eine Übersicht über diese Verkehrsbeschränkungen und der Datentypen, für die sie üblicherweise verwendet werden. Durch die freie Definition des OSM-Formats, können sie jedoch auch von anderen Datentypen verwendet werden. 1 [90] 20

29 Verkehrsbeschränkung verwendet für Datentypen Kapitel Node Way Relation Beschränkung der Beförderungsart x x Baustellen x geplante Straßen x Einbahnstraßen x Geschwindigkeitsbeschränkungen x Höhenbeschränkungen x Breitenbeschränkungen x Längenbeschränkungen x Gewichtsbeschränkungen x zeitliche Beschränkung x Verkehrsberuhigung x x Barrieren x x Abbiegevorschriten x Tabelle 5: Wichtigste Verkehrsbeschränkungen 1 Die Verkehrsbeschränkungen können auch kombiniert werden Beschränkungen der Beförderungsart Mit den Beschränkungen der Beförderungsart ( Transport mode restriction [99] oder auch Access- Restrictions [129]) wird beschrieben, auf welchen Verkehrswegen bestimmte Verkehrsmittel erlaubt sind. Es gibt nicht nur Transportmittel-Beschränkungen für Straßen ( Land based transportation ), sondern auch für Eisenbahnlinien ( Rail based transportation ) oder Wasserstraßen ( Water based transportation ) [99] und sogar für Barrieren [101]. Die folgende Erläuterung beschränken sich auf Straßen, können aber auch auf die anderen Beschränkungsarten übertragen werden. Listing 2 und Abb. 7 zeigen ein Beispiel für eine Zugangsbeschränkung. Dieses Beispiel beschreibt einen Fußweg (footway). <way id=" " user="nelius" uid="212397" visible="true" version="1" changeset=" " timestamp=" t17:51:31z"> <nd ref=" "/> <nd ref=" "/> <nd ref=" "/> <tag k="bicycle" v="yes"/> <tag k="highway" v="footway"/> <tag k="name" v="am Schwimmbad"/> </way> Listing 2: Beispiel für Zugangsbeschränkung (Freising, Fußweg Am Schwimmbad) 2 1 [120]

30 Abb. 7: Beispiel für Zugangsbeschränkung (Freising, Fußweg Am Schwimmbad) 1 Es gibt ein Modell, mit dem Zugangsbeschränkungen für Verkehrsmittel ermittelt werden können. Die Berechnung wird auf Basis eines Algorithmus [74], einer Default-Tabelle für Zugangsbeschränkungen [129] und einer Transportmittel-Hierarchie [76] durchführt. Sowohl die Default-Tabelle als auch der Hierarchiebaum sind länderabhängig [75]. Die Transportmittel-Hierarchie definiert, wie verschiedene Transportmittel unter Oberbegriffen zusammengefasst werden. In Abb. 8 ist ein solcher Hierarchiebaum abgebildet. Abb. 8: Transportmittel-Hierarchie 2 Die Wurzel des Baumes bildet das OSM-Tag access, unter dem alle Transportarten zusammengefasst werden. Ist das Tag access auf no gesetzt, ist der Verkehrsweg für alle Transportmittel gesperrt, da jedes Blatt eines Knotens die Eigenschaften des Knotens erbt. 1 [63] ( ) 2 [73] 22

31 Im Anhang befindet sich die Transportmittel-Hierarchie für Deutschland (Abb. 54). In den länderspezifischen Default-Tabellen für die Zugangsbeschränkungen ist definiert, auf welchen Verkehrswegen, welche Zutrittsbedingungen für bestimmte Transportarten gelten. Abb. 55 aus dem Anhang zeigt eine solche Tabelle für alle Länder. Diese Tabelle muss je nach länderabhängigen Regelungen angepasst werden. In Abb. 9 ist die Default-Tabelle von Deutschland dargestellt. Abb. 9: Deutsche Default-Tabelle für Transportmittelbeschränkungen 1 Durch die Verknüpfung des Hierarchiebaumes mit dieser Tabelle kann mit Hilfe des folgenden Algorithmus [74] ermittelt werden, wie die Zugangsbeschränkungen für bestimmte Verkehrsmittel lauten: 1. Zugangsbeschränkung des access-tags auf unknown setzen. Damit sind die Zugangsbeschränkungen für alle anderen (erbenden) Tags auch unbekannt. 2. Zugangsbeschränkungen aus der Default-Tabelle in den Baum übertragen. 3. Überschreiben der Default-Zugangsbeschränkungen durch die in der OSM-XML-Datei aufgeführten expliziten Zugangsbeschränkungen für diesen Way. 4. Ablesen der Zugangsbeschränkungen für bestimmte Verkehrsmittel. Zum besseren Verständnis wird die Ermittlung der Zugangsbeschränkung für ein bestimmtes Verkehrsmittel anhand des Beispiels aus Listing 2 erläutert: 1. Zunächst werden alle Zugangsbeschränkungen im Hierarchiebaum auf unknown gesetzt. 2. Anschließend werden die Zugangsbestimmungen aus der Default-Tabelle für den Fußweg (footway) in den Baum übertragen. Die Zugangsbestimmungen aus der deutschen Default- Tabelle weichen für diesen Verkehrsweg nicht von denen aus der allgemein für alle Länder gültigen Tabelle ab (siehe Abb. 55 im Anhang): 1 [130] 23

32 access = no foot = designated Daraus ergibt sich, dass für alle Verkehrsteilnehmer die Zugangsbeschränkungen no lautet, außer für Fußgänger designated. Dies ist die allgemeine Definition für einen Fußweg. 3. Im dritten Schritt werden die Default-Zugangsbeschränkungen aus dem Schritt 2 durch die in der OSM-XML-Datei explizit genannten Zugangsbeschränkungen überschrieben. Dies ist in diesem Fall: bicycle = yes Damit sind auf diesem Fußweg auch Fahrräder erlaubt. 4. Aus dem fertigen Hierarchiebaum können jetzt für alle aufgeführten Verkehrsmittel die Zugangsbestimmungen abgelesen werden. In diesem Beispiel gilt, dass bis auf Fußgänger (designated) und Fahrradfahrer (yes) keine weiteren Verkehrsteilnehmer diesen Fußweg benutzen dürfen. Bei den Beschränkungen der Verkehrswege wird nicht nur zwischen einer Sperrung und einer Freigabe für bestimmte Fahrzeugtypen unterschieden. Vielmehr existieren diskrete Abstufungen dazwischen. In Tabelle 31 im Anhang sind einige wichtige Beschränkungsarten aufgelistet und erklärt Baustellen und geplante Straßen Geplante und im Bau befindliche Straßen werden im OSM-Format mit den OSM-Tags construction und proposed getaggt [123]. Geplante Straßen sind Straßen, die sich noch nicht im Bau befinden. Sie sind aber schon erfasst, um sie als geplante Straßen in der Karte darstellen zu können [115]. Listing 3 zeigt ein Beispiel für eine geplante Straße. <way id=" " user="asphaltflechte" uid="69419" visible="true" version="1" changeset=" " timestamp=" t17:21:40z"> <nd ref=" "/> <nd ref=" "/> <tag k="highway" v="proposed"/> <tag k="proposed" v="secondary"/> </way> Listing 3: Geplante Straße mit proposed-osm-tag (Münster) 1 Wie man daraus entnehmen kann, wird dem highway-osm-tag als Wert proposed zugewiesen. Anschließend kann mit Hilfe des proposed-osm-tags spezifiziert werden, um welche Straßenart es sich handelt. Dies ist aber nicht immer der Fall, wie das Beispiel aus Listing 4 zeigt. <way id=" " user="asphaltflechte" uid="69419" visible="true" version="1" changeset=" " timestamp=" t17:21:32z"> <nd ref=" "/> <nd ref=" "/> <tag k="highway" v="proposed"/> </way> Listing 4: Geplante Straße ohne proposed-osm-tag (Münster)

33 Als Werte für das proposed-tag werden die üblichen highway-osm-tag-werte verwendet, die für normale (nicht im Bau befindliche oder geplante) Straßen zur Straßenklassifizierung herangezogen werden (siehe Kapitel ) [115]. Im Fall von Listing 3 ist das der highway-wert secondary. Im Bau befindliche Straßen werden i.d.r. auf die gleiche Art und Weise wie geplante Straßen getaggt. Listing 5 zeigt ein Beispiel für eine im Bau befindliche Straße. <way id=" " user="skyper" uid="152744" visible="true" version="4" changeset=" " timestamp=" t13:21:27z"> <nd ref=" "/> <nd ref=" "/> <nd ref=" "/> <nd ref=" "/> <nd ref=" "/> <nd ref=" "/> <tag k="construction" v="primary"/> <tag k="highway" v="construction"/> <tag k="lanes" v="2"/> </way> Listing 5: Im Bau befindliche Straße (Freiburg) 1 Im Gegensatz zu den geplanten Straßen werden bei den im Bau befindlichen Straßen anstatt des OSM-Tags proposed das OSM-Tag construction verwendet. Werden Straßen auf diese Weise erfasst, sind sie für den öffentlichen Verkehr gesperrt [105]. Bei den im Bau befindlichen Straßen gibt es noch eine alternative Erfassungsart. Bei dieser Erfassungsart wird unterschieden, ob eine Straße aufgrund einer Baustelle grundsätzlich nicht befahrbar ist oder ob sie dennoch etv. unter bestimmten Einschränkungen passierbar ist. Der Wert des highway-osm-tags bleibt dabei wie bei normalen Straßen erhalten. Zusätzlich zum highway-osm- Tag wird das OSM-Tag construction verwendet. Diesem können dann beispielsweise die Werte yes (nicht befahrbar) oder minor (befahrbar) zugewiesen werden. Diese Erfassungsart kommt aber sehr selten vor [105] Einbahnstraßen In OSM werden Einbahnstraßen mit dem OSM-Tag oneway erfasst [112]. Das oneway-osm-tag wird zusätzlich zum OSM-Tag highway gesetzt [113]. In Tabelle 6 sind die wichtigsten Werte, die der Schlüssel oneway annehmen kann, aufgelistet und erklärt. Wert Gebrauch Erklärung yes empfohlen In Richtung der erfassten Nodes besteht eine Einbahnstraße. true nicht empfohlen 1 nicht empfohlen no empfohlen Diese Straße kann in beiden Richtungen befahren werden

34 Wert Gebrauch Erklärung false nicht empfohlen 0 nicht empfohlen -1 empfohlen Entgegen der Richtung der erfassten Nodes besteht eine reverse nicht empfohlen Einbahnstraße. Tabelle 6: Wichtigste Oneway-Werte 1 Für einige OSM-Schlüssel oder auch OSM-Key-Value-Paare muss das oneway-osm-tag nicht explizit gesetzt werden, da der OSM-Schlüssel oder das Key-Value-Paar eine Einbahnstraße in Richtung der erfassten Nodes impliziert. Diese Implikation ist auf der jeweiligen Wiki-Seite des OSM-Tags vermerkt [113]. Beispiel für solche Key-Value-Paare sind: highway = motorway [145] highway = motorway_link [146] highway = trunk_link [98] junction = roundabout [147] In manchen Fällen ergibt sich erst aus der Kombination verschiedener OSM-Tags, ob es sich um eine Einbahnstraße handelt. Besonders kompliziert ist dies bei Fahrrädern (bicycle), denn manchmal kann Radfahren gegen eine Einbahnstraße erlaubt sein [72]. Des Weiteren gibt es noch zeit- [114] und fahrzeugabhängige [86] [99] Regelungen für Einbahnstraßen, wie z.b. für Fahrräder (siehe Kapitel ). Aber diese werden sehr selten benutzt. Selbst in Münster die Fahrradstadt Deutschlands schlechthin sind nur vereinzelt solche Sonderregelungen für Fahrräder in den Daten enthalten Geschwindigkeitsbeschränkungen Bei den Geschwindigkeitsbeschränkungen wird zwischen der Höchst- und der Minimalgeschwindigkeit unterschieden, wobei letztere sehr selten vorkommt. Während bei der statistischen Erhebung im August 2009 etwas über 3600 Minimalgeschwindigkeiten [154] gezählt wurden, waren es über Höchstgeschwindigkeiten [153]. In der Regel beziehen sich die Geschwindigkeitsbeschränkungen auf Ways [120] [153] [154], können aber auch Nodes und Relations als OSM-Tags zugewiesen werden. Da Minimalgeschwindigkeiten in OSM noch so selten vorkommen, werden sie hier nicht näher beleuchtet. Die Definition von Maximalgeschwindigkeiten in OSM ist nicht trivial. Grundsätzlich kann man zwischen folgenden Arten unterscheiden: 1. explizite Definition über Geschwindigkeitszahlen mit oder ohne Einheit 2. Definition über Variablen 3. Verwendung von Default-Maximalgeschwindigkeiten Das OSM-Tag zur Definition von Maximalgeschwindigkeiten heißt maxspeed [110]. Dieses OSM-Tag wird bei der expliziten Definition (1) und bei der Definition über Variablen (2) verwendet. 1 [114] [124] 26

35 Daneben gibt es noch die beiden OSM-Tags maxspeed:forward und maxspeed:backward, um zwischen den Fahrtrichtungen unterscheiden zu können [84]. Diese werden jedoch sehr selten verwendet. Laut der Statistik von OSMDoc [150] kam maxspeed:forward im August 2009 in den OSM- Daten 57 mal [152], maxspeed:backward 45 mal [151], maxspeed jedoch über mal [153] vor. Bei der expliziten Definition der Maximalgeschwindigkeit über eine numerische Zahl wird unterschieden, welche Einheit die Geschwindigkeit hat. Handelt es sich um die Einheit km/h, sollte keine Einheit explizit genannt werden (z.b. maxspeed = 40). In allen anderen Fällen sollte die Einheit, getrennt durch ein Leerzeichen von der Geschwindigkeitszahl, angegeben werden (z.b. maxspeed = 25 mph). Das Dezimaltrennzeichen ist der Punkt [110]. Listing 6 zeigt ein Beispiel für eine explizite Geschwindigkeitsangabe ohne Nennung der Einheit. <way id=" " user="kalle_anka" uid="200015" visible="true" version="4" changeset=" " timestamp=" t16:20:04z"> <nd ref=" "/> <nd ref=" "/> <nd ref=" "/> <nd ref=" "/> <tag k="highway" v="residential"/> <tag k="maxspeed" v="30"/> <tag k="name" v="max-lehner-straße"/> </way> Listing 6: Explizite Geschwindigkeitsbegrenzung in km/h (Freising) 1 In Tabelle 7 sind die wichtigsten Geschwindigkeitseinheiten mit deren Abkürzungen und Faktoren für die Umrechnung in km/h aufgelistet. Einheit Abkürzung Alias-Abkürzungen Umrechnungsfaktor in km/h Kilometer pro Stunde km/h kph, kmph 1 Meilen pro Stunde mph 1,609 Knoten knots 1,852 Tabelle 7: Geschwindigkeitseinheiten 2 Durch die freie Definition des OSM-Formats werden die genannten Regeln jedoch nicht immer eingehalten. Folgende Fälle können u. a. auch vorkommen [153]: kein Leerzeichen zwischen der Geschwindigkeitszahl und der Einheit (z.b. maxspeed = 30mph) explizite Angabe der Einheit km/h (z.b. maxspeed = 30 km/h) Verwendung anderer Abkürzungen (z.b. maxspeed = 45 mi/h) Verwendung anderer Einheiten sonstige Angaben (z.b. maxspeed = 30-40) Neben der numerischen Angabe von Geschwindigkeitsbeschränkungen, können Maximalgeschwindigkeiten auch über Variablen angegeben werden. Dadurch ist es möglich länderspezifische Ge [125] 27

36 schwindigkeitsregelungen für bestimmte Straßentypen oder Gebiete zu definieren. Die folgende Liste zeigt einige in Deutschland (Länderkürzel DE ) [77] verwendete Variablen [111]: DE:motorway DE:urban (innerhalb einer City-Area) [131] DE:rural (außerhalb einer City-Area) [131] DE:walk DE:living_street Listing 7 zeigt ein Beispiel für eine Geschwindigkeitsbegrenzung mit Hilfe der Variablen DE:urban. <way id=" " user="skyper" uid="152744" visible="true" version="10" changeset=" " timestamp=" t12:52:39z"> <nd ref=" "/> <nd ref=" "/> <tag k="highway" v="residential"/> <tag k="lit" v="yes"/> <tag k="maxspeed" v="de:urban"/> <tag k="name" v="feldbergstraße"/> <tag k="oneway" v="yes"/> <tag k="surface" v="asphalt"/> </way> Listing 7: Geschwindigkeitsbeschränkung über Variable (Freiburg) 1 Die Verwendung solcher Variablen bringt den Vorteil, dass bei einer gesetzlichen Änderung der Maximalgeschwindigkeit nicht alle maxspeed-werte angepasst werden müssen. Bei Anwendungen, welche die Maximalgeschwindigkeiten verarbeiten, muss nur der Eintrag in der Lookup-Tabelle geändert werden. Daneben kommt es auch vor, dass andere Werte dem maxspeed-osm-tag zugewiesen werden. Dies können z.b. folgende Werte sein: undefined unknown unlimited unrestricted none no Die Verwendung solcher Werte ist aber umstritten [111]. Falls das maxspeed-osm-tag nicht verwendet wird, gibt es länderspezifische Default- Maximalgeschwindigkeiten. Diese sind i.d.r. vom Wert des highway-osm-tags abhängig. In manchen Ländern spielen aber bei der Ermittlung der Maximalgeschwindigkeit auch noch andere OSM- Tags und Eigenschaften eine Rolle. Beispielsweise kann die Default-Geschwindigkeitsbeschränkung von folgenden Eigenschaften abhängen: Straße befindet sich innerhalb eines städtischen Gebietes (City-Area) oder außerhalb erlaubte Verkehrsmittel Anzahl der Fahrspuren

37 Einbahnstraße Laut der Dokumentation der Geschwindigkeitsbegrenzungen für die verschiedenen Länder sollen die Regelungen besonders für Deutschland kompliziert sein [131] Größen- und Gewichtsbeschränkungen Das OSM-Format enthält Größen- und Gewichtseinschränkungen [84], die gesetzlich verordnet sind. In Tabelle 8 sind die wichtigsten dieser Beschränkungen, bezogen auf das Straßennetz aufgelistet. Kategorie Art der Beschränkung OSM-Tag Höhe Maximalhöhe maxheight Minimalhöhe minheight Breite Maximalbreite maxwidth Länge Maximallänge maxlength Gewicht Maximalgewicht maxweight Maximale Achslast Tabelle 8: Größen- und Gewichtsbeschränkungen 1 maxaxleload Wie auch bei den Geschwindigkeitsbeschränkungen (siehe Kapitel ) sollten hier nur dann Einheiten hinzugefügt werden, wenn sie nicht der Standardeinheit entsprechen. Die Standardeinheit für Höhe, Breite und Länge ist Meter (m), für Gewicht Tonnen (t). Das Dezimaltrennzeichen ist der Punkt [84]. Das Listing 8 ist ein Beispiel für eine maximal erlaubte Fahrzeughöhe auf einer Straße. <way id=" " user="jakobg" uid="168881" visible="true" version="2" changeset=" " timestamp=" t10:49:12z"> <nd ref=" "/> <nd ref=" "/> <nd ref=" "/> <nd ref=" "/> <nd ref=" "/> <nd ref=" "/> <nd ref=" "/> <tag k="highway" v="unclassified"/> <tag k="maxheight" v="3.3"/> <tag k="name" v="lechtenbergweg"/> </way> Listing 8: Beispiel für Maximalhöhe Zeitliche Beschränkungen Zeitliche Zutrittsbeschränkungen (Access time restrictions) [100] werden in OSM beispielsweise mit folgenden OSM-Tags definiert werden: date_on 1 [84] 29

38 date_off day_on day_off hour_on hour_off Diese Beschränkungen können auch in Kombination mit Transportmittelbeschränkungen (siehe Kapitel ), Einbahnstraßen (siehe Kapitel ) und Abbiegvorschriften (siehe Kapitel ) verwendet werden. Des Weiteren gibt es noch das OSM-Tag maxstay für die maximal erlaubte Parkdauer, dessen Einheit Stunden ist Verkehrsberuhigung OSM-Tags für Verkehrsberuhigungsmaßnahmen werden i.d.r. zusätzlich zum highway-osm-tags verwendet [117]. In Tabelle 9 sind einige gebräuchliche Verkehrsberuhigungs-OSM-Tags aufgelistet. Diese können entweder für Nodes oder auch für Ways verwendet werden [87]. yes bump chicane cushion hump Wert rumble_strip table choker Bedeutung Verkehrsberuhigungsmaßnahmen Bodenwelle (kurz) Schikane Bodenwelle (mit Lücken) Bodenwelle (lang) Seitenstreifen (holpernd) Bodenwelle (sehr lang und flach) Fahrbahnverengung Tabelle 9: Verkehrsberuhigung (OSM-Schlüssel: traffic_calming) Barrieren Bei Barrieren wird zwischen zwei Haupttypen unterschieden: punktförmige und linienförmige Barrieren. In Tabelle 32 im Anhang sind die bekanntesten Barrieren aufgelistet, die alle den Schlüssel barrier haben und access = no implizieren [101]. Punktförmige Barrieren werden auf Wegen (highway), linienförmigen Barrieren oder einer Kreuzung von beiden platziert. Die Barrieren-OSM-Tags können mit anderen Zutrittsbeschränkungen kombiniert werden. Für welche Verkehrsteilnehmer Barrieren durchlässig sind, wird anhand des access - Schlüssels und anderer OSM-Tags definiert [103]. In Abb. 10 ist ein Beispiel für eine punktförmige Barriere (Schlagbaum, barrier = lift_gate) dargestellt, die sich zu Beginn eines Privatweges befindet. 1 [91] [117] [123] 30

39 Abb. 10: Barriere Schlagbaum 1 Poller (barrier = bollard) implizieren neben access = no auch foot = yes und bicycle = yes [140]. Linienförmige Barrieren können beispielsweise Grundstücke umgrenzen oder auch seitlich von Straßen liegen. Falls eine linienförmige Barriere einen Weg kreuzt, sollte immer die entsprechende punktförmige Barriere getaggt werden [102]. Die Zugangsbeschränkungen für Drängelgitter (barrier = cycle_barrier) werden über zusätzliche OSM-Tags wie z.b. bicycle = no oder bicycle = yes definiert. Es wird angenommen, dass das OSM-Tag für Drängelgitter die Zutrittsbeschränkung motor_vehicle = no impliziert [142]. Fürs Routing sollte berücksichtigt werden, dass i.d.r. an Drängelgittern die Fahrtgeschwindigkeit reduziert werden muss [141] Abbiegevorschriften Abbiegevorschriften werden mit Hilfe von Relations (relation-osm-tags) erfasst [135]. Listing 9 und Abb. 11 zeigen ein Beispiel für ein Links-Abbiegeverbot. <relation id="405376" user="kalle_anka" uid="200015" visible="true" version="1" changeset=" " timestamp=" t22:20:16z"> <member type="way" ref=" " role="from"/> <member type="way" ref=" " role="to"/> <member type="node" ref=" " role="via"/> <tag k="restriction" v="no_left_turn"/> <tag k="type" v="restriction"/> </relation> Listing 9: Links-Abbiegeverbot (Freising, Goethestraße Plantagenweg) 2 1 [64] [65]

40 Abb. 11: Links-Abbiegeverbot (Freising, Goethestraße Plantagenweg) 1 Wie man an diesem Beispiel sehen kann, werden für eine Abbiegevorschrift im einfachsten Fall mindestens folgende drei Relation-Members, d.h. Teilnehmer einer Relation (siehe Tabelle 28), benötigt [96]: from-way via-node (i.d.r. Kreuzungspunkt zwischen from- und to-way) to-way Bei komplizierteren Abbiegeregelungen kann es auch mehrere via-nodes oder ein via-way geben [93] [96]. Dies kommt jedoch so gut wie nicht vor. Die zwei wichtigsten OSM-Tags für Abbiegvorschriften sind: type = restriction restriction = * Mit type = restriction wird definiert, dass es sich bei dieser Relation um eine Beschränkung handelt. Mit dem Schlüssel restriction wird die Art der Abbiegevorschrift spezifiziert. Dabei wird zwischen Abbiegeverboten und -geboten unterschieden. Die Werte der Abbiegeverbote beginnen stets mit no, die Werte der Abbiegegebote mit only [136]. In Tabelle 10 sind die Werte des OSM- Tags restriction aufgelistet und erklärt. Wert no_left_turn no_right_turn no_straight_on no_u_turn only_left_turn only_right_turn only_straight_on Links-Abbiegeverbot Rechts-Abbiegeverbot Geradeaus-Fahrverbot Wendeverbot Links-Abbiegegebot (nur links) Rechts-Abbiegegebot (nur rechts) Erklärung Geradeaus-Fahrgebot (nur geradeaus) Tabelle 10: Abbiegevorschriften: Werte für das OSM-Tag restriction 2 1 [68] 2 [95] 32

41 Wie auch bei den Einbahnstraßen (siehe Kapitel ) gibt es bei den Abbiegevorschriften zeit- [97] und fahrzeugabhängige [94] Regelungen, die hier aber nicht näher erläutert werden Eigenschaften des Verkehrsnetzes Welche graphentheoretischen Eigenschaften hat das Verkehrsnetzwerk von OSM nun? Basierend auf den vorangegangenen Kapiteln über die Graphentheorie (Kapitel 2.1), das grundlegende Datenmodell von OSM (Kapitel 3.2.1), den Verkehrswegen und Map Features (Kapitel 3.2.2) wird im Folgenden erläutert, welche Eigenschaften das OSM-Verkehrsnetzwerk aufweist. Beim OSM-Netzwerk handelt es sich um ein gerichtetes Netzwerk (Digraph), da den Ways und damit den Straßen (highway) durch die Reihenfolge der referenzierten Nodes eine Richtung zugewiesen ist. Diese wird z.b. zur Definition von Einbahnstraßen genutzt. Ein weiteres Beispiel sind richtungsabhängige Geschwindigkeitsbegrenzungsangaben. Unter der Annahme, dass das Netzwerk nur aus Straßen und den von ihnen referenzierten Nodes besteht, setzt sich das OSM-Netzwerk aus verschiedenen, zumindest schwachen Zusammenhangskomponenten zusammen. Denn da es auch isolierte Straßen geben kann, kann das Netzwerk niemals vollständig sein, ist also aus Zusammenhangskomponenten aufgebaut. Des Weiteren ist auch theoretisch der Fall möglich, dass eine Sackgasse eine Einbahnstraße ist. So kann der Endknoten nur über einen ungerichteten Weg mit allen anderen Knoten der Zusammenhangskompontente verbunden sein. Damit kann die Zusammenhangskomponente niemals stark sein. Das OSM-Netzwerk ist ein gewichtetes Netzwerk, weil jede Straße eine Länge hat. Da Brücken und Tunnel so erfasst werden, dass sie am Kreuzungspunkt mit anderen Straßen oder linienhaften Objekten keinen gemeinsamen Node haben, gibt es Pfeile, die sich überschneiden. Damit ist das OSM-Netzwerk nicht planar. Zählt man zum Netzwerk nicht nur die von Straßen referenzierten Nodes hinzu, sondern auch Points of Interest und andere Nodes, so gibt es isolierte Knoten. Diese Knoten haben dann sowohl einen positiven als auch einen negativen Grad von OSM-Datenbezug OSM-Daten können auf verschiedene Arten bezogen werden. Zum einen können sie direkt von der OSM-Internetseite über die Export-Funktion (Reiter Export ) in verschiedenen Datenformaten heruntergeladen werden, wie z.b. im OSM-Format (*.osm) oder als Bild [63]. Wie man in Abb. 12 sehen kann, wird zur Exportierung ein Gebiet ausgewählt. Bei der Exportierung der Daten im OSM-XML- Format sind jedoch nur Nodes erlaubt. 33

42 Abb. 12: Export von OSM-Daten im OSM-XML-Format 1 Enthält das ausgewählte Gebiet mehr Nodes, wird auf die Datei Planet.osm [132] verwiesen. Diese OSM-XML-Datei wird wöchentlich für die gesamte Welt erstellt und hat momentan eine Dateigröße von 160 GB (unkomprimiert) [132]. Alternativ können auch Daten von anderen Anbietern bezogen werden, die in regelmäßigen Abständen OSM-Daten in verschiedenen Datenformaten bereitstellen. Eine Liste der Anbieter gibt es im OSM-Wiki unter dem Stichwort Planet.osm [132]. OSM-Daten werden u.a. von dem in Karlsruhe ansässigen Unternehmen Geofabrik [46] und von CloudMade [32] angeboten, auf die in späteren Kapiteln noch eingegangen wird (siehe Kapitel und 4.2). Diese bieten OSM-Daten nicht nur im Datenformat *.osm an, sondern auch beispielsweise im ESRI Shape-Format OSM in ArcGIS OSM-Daten können von verschiedenen Anbietern in ESRI-Datenformaten erhalten werden. Des Weiteren gibt es einige Skripte und Tools, mit denen man selbst OSM-Daten in ESRI-Datenformate konvertieren kann. In den folgenden Kapiteln werden die bekanntesten Anbieter und einige Skripte und Tools vorgestellt. 1 [63] 34

43 OSM in ESRI-Datenformaten Die beiden bekanntesten Quellen, von denen man OSM-Daten im ESRI Shape-Format (*.shp) beziehen kann, sind die Geofabrik [46] und CloudMade [32] Geofabrik Die Firma Geofabrik bietet auf ihrer Website für einige Länder und Regionen OSM-Daten zum Download an [47]. Diese Daten können einerseits im OSM-Format (*.osm) und andererseits im ESRI Shape- Format (*.shp) heruntergeladen werden. Tabelle 11 ist eine Übersicht über die von der Geofabrik erzeugten Shapefiles. Zur Erstellung der Shapefiles aus OSM-Dateien verwendet sie das C-Programm osm2shp 1, das von ihr für diese Arbeit zur Verfügung gestellt wurde. Name des Shapefiles Typ Beschreibung roads Line Features Straßen und Wege railways Line Features Eisenbahn waterways Line Features Wasserstraßen points Point Features Points of Interest places Point Features Ortsangaben buildings Polygon Features Gebäude natural Polygon Features Wälder, Parks, Grünanlagen, Gewässer (Flüsse, Seen, Teiche) Tabelle 11: Shapefiles der Geofabrik Die Geofabrik extrahiert nicht alle Daten aus den OSM-Daten. Vielmehr findet eine Auswahl und teilweise eine Uminterpretation statt. Bei der Befüllung der Shapefiles gibt es einige Kritikpunkte: So wird bei der Ermittlung des Straßentyps (highway) nicht berücksichtigt, dass dieser unter Umständen auch im construction- oder im proposed-osm-tag stehen könnte (siehe Kapitel ). Des Weiteren wird nicht beachtet, dass Höchstgeschwindigkeiten (maxspeed) Angaben zur Einheit haben oder über Variablen definiert sein können (siehe ). Bei Straßen wird nur unterschieden, ob es sich um Einbahnstraßen (oneway) handelt oder nicht. Dazu wird das OSM-Tag oneway ausgelesen. Es wird jedoch ignoriert, dass andere OSM-Tags Einbahnstraßen implizieren können. Außerdem wird die Richtung der Einbahnstraßen außer Acht gelassen CloudMade CloudMade wurde u.a. von dem OSM-Gründer Steve Coast im Jahr 2007 gegründet und beschäftigt sich mit freien Karten [33]. Wie auch die Geofabrik bietet CloudMade OSM-Daten u.a. im OSM- Format (*.osm) und auch im ESRI Shape-Format (*.shp) zum Download an [34]. 1 Geofabrik: osm2shp ( ) 35

44 Das Programm, mit dem die Shapefiles erstellt werden, ist nicht bekannt. Deshalb ist nicht klar, wie die Befüllung der Shapefiles genau definiert ist. Aus diesem Grund kann nur anhand von heruntergeladenen Shapefiles [35] die Befüllung analysiert werden. Tabelle 12 ist eine Übersicht über die von CloudMade erzeugten Shapefiles. Name des Shapefiles Typ Beschreibung [Gebietsname]_highway Line Features Straßen und Wege [Gebietsname]_poi Point Features Points of Interest [Gebietsname]_administrative Line Features administrative Grenzen [Gebietsname]_coastline Line Features Küstenlinien [Gebietsname]_water Polygon Features Wasserflächen, Küstenlinien [Gebietsname]_natural Polygon Features Wälder, Parks, Wasserflächen Tabelle 12: Shapefiles von CloudMade 1 Wie auch bei dem Shapefile der Geofabrik wird hier nicht berücksichtigt, dass der Straßentyp unter Umständen auch im construction- oder im proposed-osm-tag stehen könnte. Auch bei den Einbahnstraßen wird wahrscheinlich nur das oneway-osm-tag ausgewertet. Implikationen und andere OSM-Tags werden nicht berücksichtigt Tools und Skripte zur OSM-Konvertierung In Tabelle 13 sind verschiedene Tools und Skripte mit ihren wichtigsten Eingenschaften aufgelistet, mit denen man OSM-Daten in ESRI-Datenformate konvertieren kann. Skript / Tool Sprache Ausgabeformat benutzerdefinierte Quellcode Einstellungen möglich einsehbar OpenStreetMap Loader [30] Python-Skript GDB - x Convert OpenStreetMap Data [29] OSM2Shape [31] C# SHP - x Avenue (ArcView Extension) SHP - x Osmexport [155] Ruby-Gem SHP x x FME [45] z.b. SHP, GDB x - Tabelle 13: Tools und Skripte zur Konvertierung von OSM-Daten in ESRI-Datenformate Das Python-Skript OpenStreetMap Loader, auch OSM Simple Loader genannt, kann in die Arc- Toolbox von ArcGIS eingebunden werden und erzeugt eine Geodatabase. Diese Geodatabase enthält drei Feature Classes für Nodes, Ways und Areas. Im Gegensatz zu anderen Anwendungen findet bei diesem Skript keine Interpretation oder Auswahl der OSM-Tags statt. Sie werden 1:1 übernommen. 1 [34] [35] 36

45 Das Tool Convert OpenStreetMap Data erzeugt ein Shapefile, in dem die Straßen aus den OSM- Daten mit ihren Straßennamen enthalten sind. Beim Testen dieses Tools wurde zwar ein Shapefile erstellt, das erzeugte Straßenbild entsprach aber in keinster Weise der Realität. Dies ist vermutlich auf einen Programmierfehler zurückzuführen. Mit der ArcView Extension OSM2Shape können zwei Shapefiles erzeugt werden eines für Nodes und eines für Ways. Beide Shapefiles enthalten aber keinerlei Informationen über OSM-Tags. Eines der interessantesten Tools zur Generierung von Shapefiles ist Osmexport. Dies ist ein Ruby- Gem [160] eine Speicherform für Programme oder Bibliotheken der Programmiersprache Ruby [159]. Mit diesem Tool können sehr komfortabel aus OSM-Dateien Shapefiles generiert werden. Vor der Ausführung des Programms muss ein sog. Rule File (*.oxr, Osmexport Rule File) [156] geschrieben werden, in dem definiert wird, wie die Shapefiles befüllt werden. Dieses Tool ist jedoch nicht für große Datenmengen geeignet. Mit der FME ein Programm zur Konvertierung und Verarbeitung von Geodaten lassen sich auch OSM-Daten in viele verschiedene Datenformate konvertieren. Wie bei Osmexport kann der Anwender hier benutzerdefinierte Einstellungen zur Konvertierung vornehmen. Bis auf die FME sind alle hier aufgelisteten Programme und Tools kostenlos Vergleich zu anderen netzwerkanalysefähige Daten Routingfähige Daten gibt es vorwiegend von kommerziellen Datenanbietern. Die wichtigsten kommerziellen Datenanbieter sind NAVTEQ [55] und Tele Atlas [163]. Im Folgenden werden die beiden Datenanbieter vorgestellt. Die Informationen dazu stammen von deren Internetseiten. NAVTEQ und Tele Atlas sind die führenden Anbieter von digitalen Karten für Routing- und Navigationsanwendungen. Diese Daten werden von verschiedenen Unternehmen, staatlichen Einrichtungen und Privatkunden bezogen. Typische Anwendungsbereiche sind z.b. in der KFZ-Industrie, in der Logistik, im GIS-Bereich, in Notfallzentralen, bei Versorgungsunternehmen und bei Versicherungen. Zum Einsatz kommen sie u.a. in Navigationssystemen, auf mobilen Geräten und bei ortsbezogenen Diensten (Location Based Services, LBS), in Internet-Routenplanern und GIS-Anwendungen. Die Daten enthalten neben einem Verkehrsnetz auch Points of Interest (POIs) und Daten zur Bodenbedeckung, die für die kartographische Gestaltung der Karten benötigt werden. Sowohl NAVTEQ als auch Tele Atlas bieten eine umfangreiche Attributierung der Verkehrsdaten bzw. die komplette Topologie des Straßennetzes. Typische Attribute sind beispielsweise Zufahrtsbeschränkungen, Sperrungen von Straßen, Einbahnstraßen, Abbiegevorschriften, Wendeverbote, Verkehrszeichen, Durchfahrtshöhen, Gewichtsbeschränkungen, zeitliche Beschränkungen und Gebäudeadressen. Über die interaktive Karte Global Coverage Statistics [56] von NAVTEQ erhält man einen groben Überblick, wie die Abdeckung und die Datenverfügbarkeit von NAVTEQ-Daten ist. In Westeuropa, Nordamerika und Australien sind fast für alle Länder Verkehrsinformationen vorhanden und die Adressdaten vollständig. In Osteuropa dagegen sind noch nicht viele Adressen und Verkehrsdaten erfasst. Bis auf wenige Ausnahmen gibt es für Mittel- und Südamerika, Afrika, Asien und den pazifischen Raum nur wenige Verkehrs- und Adressdaten. Tele Atlas bietet grundlegende routingfähige Daten für über 200 Länder und Regionen an. Laut eigener Aussage soll die Abdeckung des Straßennetzes in 94 Ländern sehr detailliert sein. 37

46 Beide Datenanbieter behaupten qualitativ hochwertige Daten anzubieten, die regelmäßig aktualisiert werden. Sowohl bei NAVTEQ als auch bei Tele Atlas gibt es komplexe Lizenz- und Preismodelle. Neben NAVTEQ und Tele Atlas gibt es noch weitere Datenanbieter, die oftmals deren Daten veredeln. Dazu zählen LOGIBALL [52] und United Maps [168]. LOGIBALL bietet kundenspezifische Navigationslösungen an und richtet sich z.b. an Privatkunden, die Freizeit-Navigationskarten benötigen, aber auch an Geschäftskunden aus der Energieversorgung, der Logistik, dem Handwerk, der Forst- und Landwirtschaft und Institutionen aus dem Sicherheitsbereich. United Maps bezieht seine Grunddaten von NAVTEQ und Tele Atlas und reichert diese an, damit sie auch für die Fußgänger-Navigation und multimodales Routing verwendet werden können. Hinzugefügte Daten sind beispielsweise Gebäudeumrisse, Hausnummern, ÖPNV-Daten und Points of Interest (POIs). Routingfähige Daten sind jedoch noch nicht weltweit vorhanden. Die Karten werden für Navigationssysteme, mobile Geräte und Dienste, Internetanwendungen, zur Verbesserung von Geschäftsprozessen, in der Logistik und in Behörden verwendet. Das Konzept der kommerziellen Datenanbietern unterscheidet sich stark von OSM. Zum einen kosten die Daten etwas und stehen unter verschiedenen Lizenzen, die sich stark von der Lizenz von OSM unterscheiden. Der Kunde eines kommerziellen Datenanbieters erhält als Gegenwert für die Lizenzgebühr ein auf die Anwendung bezogenes Nutzungsrecht. Die Daten bleiben dabei im Eigentum des Datenanbieters, welcher aber mit der Nachführung der Daten die Aufrechterhaltung von Qualität, Vollständigkeit und Aktualität des Datensatzes gewährleistet. Er muss aber gewisse Einschränkungen in Kauf nehmen. So ist das Kopieren, die Weiterverarbeitung und die Verbreitung der Daten im Gegensatz zu OSM für Kunden nicht ohne Weiteres möglich. Die Daten werden hier i.d.r. nur von den Mitarbeitern der Datenanbieter erfasst und bearbeitet (Ausnahme: Tele Atlas Community Input [164] und TomTom Map Share [166], bei denen die Anwender zur Verbesserung der Daten beitragen), während hingegen bei OSM jeder mitmachen kann. Je nach Datenanbieter liegt der Schwerpunkt auf dem Fahrzeugrouting oder auf kundenspezifischen Routinglösungen. Die Datenformate und Erfassungsrichtlinien kommerzieller Anbieter sind streng definiert, was auf OSM nicht zutrifft. Die Abdeckung ist jedoch ähnlich wie bei OSM nicht für alle Länder einheitlich. Kommerzielle Datenanbieter gehen bei der Datenerfassung systematisch vor, OSM jedoch zufällig. Doch die kommerziellen Datenanbieter bieten für einige Länder Daten an, die sie als vollständig bezeichnen. Bei OSM ist es schwierig von Vollständigkeit zu sprechen, da es kaum möglich ist, diese zu kontrollieren. Bei OSM gibt es im Gegensatz zu den Daten der kommerziellen Anbieter keine Vorgaben, dass sich die Daten bestimmte Inhalte haben müssen, an bestimmte Nutzergruppen richten und für definierte Anwendungen erzeugt werden sollen. Auch in der Qualitätssicherung unterscheidet sich OSM von kommerziellen Anbietern. Es gibt keinen definierten Qualitätssicherungsprozess. Stattdessen gibt es einige Tools, die helfen Fehler zu erkennen (siehe Kapitel 3.1). Bei OSM wird sich darauf verlassen, dass durch die Bearbeitung vieler Nutzer, die sich vor Ort auskennen, eine ausreichend gute Qualität gewährleistet ist. Für Qualitätsmängel in OSM kann jedoch keiner haftbar gemacht werden. Zusammenfassend kann man sagen, dass sich die Modelle der kommerziellen Anbieter grundsätzlich von OSM unterscheiden. Möchte man routingfähige Daten beziehen, muss man sich zuerst überlegen, welche der zuvor angesprochenen Aspekte für den jeweiligen Verwendungszweck wichtig sind. Öffentliche Datenanbieter wie Vermessungsämter bieten i.d.r. keine routingfähige Daten an, da dies nicht in deren Aufgabenbereich fällt. Mit NavLog [54] wurde jedoch ein Gemeinschaftsprojekt der Forst- und Holzwirtschaft von verschiedenen Unternehmen und öffentlichen Stellen ins Leben geru- 38

47 fen. Dieses hat zum Ziel für Deutschland einen Datenbestand aufzubauen, mit dem man auf Forstwegen und Straßen navigieren kann. Mit diesen Daten sollen einerseits die Logistik in der Forst- und Holzwirtschaft als auch z.b. Rettungsdienste unterstützt werden. Bis auf OSM sind keine weiteren Datenanbieter von freien netzwerkanalysefähigen Daten bekannt. 39

48 4. Netzwerkanalysen mit OpenStreetMap In diesem Kapitel wird die Entwicklung der prototypischen Anwendung zur automatisierten Datenaufbereitung von OSM-Daten in ein routingfähiges ESRI Network Dataset beschrieben. Die Grundlagen wurden in den vorangegangenen Kapiteln Kapitel 2 und 3 geschaffen Verweise werden genutzt, um dem Leser diese Grundlagen an den jeweiligen Stellen in Erinnerung zu rufen. Mit OSM2NetworkDataset wurde eine möglichst treffende Bezeichnung für das Tool gewählt, um direkt auf die Funktionalität zu referenzieren Konzept OSM ist ein lebendes Datenformat, d.h., es ist nicht starr, sondern entwickelt sich, durch die Mitglieder getrieben, stetig weiter. Es gibt einige Standards, die sich herausgebildet haben, die man bei der Erstellung der OSM-Anwendung beachten sollte. Der Anwender besitzt die Möglichkeit, die OSM- Daten unterschiedlich zu interpretieren. Dafür steht eine Parameter-Datei (siehe Kapitel 4.1.1) zur Verfügung. Mit dieser Parameter-Datei wird das Profil eines Fortbewegungsmittel (z.b. Auto, Fahrrad, Fußgänger, usw.) bezogen auf ein Land und damit sein Verhalten im Netzwerk definiert. Somit ist es möglich, Netzwerkanalysen für verschiedene Fahrzeugtypen durchzuführen, da die Parameter- Datei für den Anwender anpassbar ist. Um ein gutes Routingnetz zu erhalten, werden möglichst viele der aufs Routing bezogenen OSM-Map Features umgesetzt. Es können jedoch nur die Map Feature umgesetzt werden, die im Network Dataset abbildbar sind. Da diese Anwendung nur ein Prototyp darstellt, wird bei der Auswahl der Map Features nicht auf Vollständigkeit geachtet. Vielmehr wird gezeigt, was von den am häufigsten in OSM verwendeten Map Features im Network Analyst von ArcGIS umsetzbar ist. Folgende Map Features werden in die Konzeption mit aufgenommen: komplettes Straßennetz Abbiegevorschriften punkthafte Barrieren Zugangsbeschränkungen für bestimmte Straßentypen (abhängig von der Beförderungsart) Einbahnstraßen in Planung oder im Bau befindliche Straßen maximal erlaubte Fahrzeughöhe maximal erlaubtes Fahrzeuggewicht erlaubte Höchstgeschwindigkeit Durchschnittsgeschwindigkeit Verkehrsberuhigung Wegbeschreibungen Nicht umzusetzende Map Features sind in Kapitel aufgelistet. Mit den oben aufgelisteten Map Features, die in das Netzwerk aufgenommen werden, sollen alle in ArcGIS vorhandene Network Analyst Solvers (siehe Kapitel 2.3) durchgeführt werden können: Route Solver Service Area Solver 40

49 Closest Facility Solver OD Cost Matrix Solver Vehicle Routing Problem Solver Bis auf die Durchschnittsgeschwindigkeit können alle Map Features aus den OSM-Daten extrahiert werden. Die Durchschnittsgeschwindigkeit wird zusätzlich in die Daten aufgenommen, um neben dem kürzesten Weg auch den zeitlich günstigsten Weg zu ermitteln. Diese Durchschnittsgeschwindigkeiten können für die verschiedenen Straßentypen vom Anwender selbst bestimmt werden (siehe Kapitel 4.1.1). Im Folgenden wird eine Möglichkeit beschrieben, wie man die ausgewählten Map Features im Network Dataset abbilden kann. Auf diesem Konzept basiert die prototypische Anwendung (siehe Kapitel 4.3). Man muss sich hierbei bewusst sein, dass dieses Konzept lediglich eine Umsetzungsmöglichkeit neben weiteren Möglichkeiten der Umsetzung darstellt. Wie in Kapitel 2.3 erläutert, kann das Verkehrsnetz entweder mit Hilfe einer Geodatabase oder mit Hilfe von Shapefiles erzeugt werden. Für die Erstellung des OSM-Transportnetzes wurde sich für eine Geodatabase entschieden. Diese hat den Vorteil, dass die Daten kompakt zusammengefasst sind. Außerdem bleibt damit die Möglichkeit offen, später aus dem Verkehrsnetz ohne viel Aufwand ein multimodales Netz erstellen zu können. Als Geodatabase wurde eine File Geodatabase (*.gdb) verwendet. Diese hat im Gegensatz zur Personal Geodatabase u.a. den Vorteil, dass sie auch größere Datenmengen als 2 GB fassen kann und plattformunabhängig ist. Die Geodatabase enthält ein Feature Dataset, in dem das Network Dataset (hier: Network_Dataset_ND ) und die am Netzwerk beteiligten Feature Classes enthalten sind. Abb. 13 und Tabelle 14 zeigen den für dieses Konzept entwickelte Aufbau der Geodatabase. Abb. 13: Struktur der Geodatabase Das OSM-Netzwerk wird mit den in Tabelle 14 aufgelisteten Feature Classes erstellt. Feature Class Name Feature Class Type Beschreibung roads Line Features Straßennetz turns Turn Features Abbiegeverbote barriers Point Features punktförmige Barrieren Tabelle 14: Feature Classes in der GDB Neben den in Abb. 13 und Tabelle 14 aufgelisteten Feature Classes wird noch die Feature Class pois erstellt, in der alle Nodes aus den OSM-Daten enthalten sind. Diese Feature Class hat jedoch für das Network Dataset keinerlei Bedeutung. Sie wird nur deshalb erstellt, um den Nutzer der Anwendung einige Points of Interest zum Testen an die Hand zu geben. Der Aufbau dieser Feature Class wird hier nicht näher beleuchtet. 41

50 Zusätzlich zur Geodatabase wird noch ein Kartendokument, Map Document genannt (*.mxd), automatisch erstellt. Diese enthält die Classes aus dem Feature Dataset sowie für jeden in ArcGIS vorhanden Solver einen Solver Layer. Der Grund für die automatische Erstellung des Map Documents liegt darin, dass an den Solver Layern Anpassungen vorgenommen werden müssen, damit ein korrektes Mapping von Orten zu Network Locations auf das Netz stattfindet. In Abb. 14 ist der Workflow der Anwendung zur Erstellung eines fertigen Netzwerkes abgebildet. OSM Parameters OSM2NetworkDatas et GDB - Feature Dataset - Feature Classes - Network Dataset MXD - Feature Classes - Network Dataset - Solver Layer Abb. 14: Workflow der Anwendung Die Anwendung liest zunächst die beiden Input-Dateien, die OSM-Datei und die Parameter-Datei ein. Auch für die Parameter-Datei wurde das XML-Format gewählt. XML-Dateien haben den Vorteil, dass man mit Hilfe von XML Schemata (XSD) deren Aufbau und Syntax definieren kann. Beim Einlesen von XML-Dateien können sie dann gegen das zugeordnete XML Schema validiert werden. Da es nur für die Version v0.5 von OSM ein XML Schema gibt [148], die aktuelle Version aber v0.6 ist, wurde im Rahmen der Arbeit ein neues Schema erstellt. Beide XML Schemata für die OSM-Datei und für die Parameter-Datei befinden sich im Anhang (siehe Listing 48 und Listing 49). Das hier beschriebene Konzept basiert auf einer manuellen Datenaufbereitung, bei der geprüft wurde, welche Map Features im Network Analyst umgesetzt werden können. Als Gebiet für die manuelle Datenaufbereitung wurde das Stadtgebiet von Münster 1 gewählt, da es eine mittlere Größe hat (die Übersetzung eines großen Gebiets würde die Aufbereitung verlängern) und interessante Fahrrad- Map Features und Abbiegevorschriften enthält. Um die Daten nicht gänzlich von Hand zu konvertieren, wurde das Ruby-Tool Osmexport in der Version (siehe Kapitel 3.4.2) verwendet, mit dem komfortabel Shapefiles aus OSM-Dateien erzeugt werden können. Anschließend wurde im ArcCatalog die Geodatabase mit dem Feature Dataset erstellt. Die zuvor erzeugten Shapefiles wurden verwendet, um die Feature Classes Straßen, Barrieren und Abbiegeverbote zu erzeugen und dem Feature Dataset hinzuzufügen. Zum Schluss wurde im Feature Dataset ein Network Dataset erstellt. Die Feature Classes und das Network Dataset der manuellen Datenaufbereitung entsprechen jedoch nicht 1:1 denen der automatisierten Datenaufbereitung. Während bei der manuellen Datenaufbereitung noch viele Datenmanipulationen im Network Dataset stattfinden, müssen im Network Dataset

51 der automatisierten Datenaufbereitung nur noch wenige Manipulationen durchgeführt werden. Alle Manipulationen, die der Nutzer nicht zwingend selbst vornehmen können muss, wurden in den Schritt ausgelagert, bei dem die OSM-Daten in Feature Classes konvertiert werden. Nach der manuellen Datenaufbereitung wurden zum Testen einige Netzwerkanalysen auf dem erzeugten Netz durchgeführt, die erfolgreich verlaufen sind. Abb. 15 zeigt ein Routing auf dem manuell erstellten Netz, bei dem ein Abbiegeverbot (rot) umgangen wird. Abb. 15: Routing auf manuell erstelltem Netz in Münster (Abbiegeverbot ) 1 Im Folgenden wird zunächst die Parameter-Datei erläutert (siehe Kapitel 4.1.1). Anschließend wird der Aufbau und die Befüllung der Feature Classes (siehe Kapitel 4.1.2, und 4.1.4) und des Network Datasets (siehe Kapitel 4.1.5) beschrieben Parameter-Datei Wie schon zu Beginn des Kapitels 4.1 erwähnt, wird neben der OSM-Datei auch eine Parameter-Datei eingelesen. In dieser Parameter-Datei wird das Verhalten (Profil) eines bestimten Transportmittels bezogen auf ein Land definiert. Damit ist das Konvertierungstool nicht auf bestimmte Transportmittel oder Länder festgelegt. Wie schon erwähnt, ist die Parameter-Datei als XML-Datei definiert. Listing 10 zeigt den prinzipiellen Aufbau dieser Datei. Das XML Schema Parameters.xsd legt die Struktur und die Syntax dieser XML- Datei fest (siehe Anhang Listing 49). <?xml version="1.0" encoding="utf-8"?> <parameters> <transport_mode_hierarchy>...</transport_mode_hierarchy> <access_barrier_restrictions>...</access_barrier_restrictions> <access_barrier_restrictions_interpretation>... </access_barrier_restrictions_interpretation> <slowdown_barrier_restrictions>...</slowdown_barrier_restrictions> <access_highway_restrictions>...</access_highway_restrictions> <access_highway_restrictions_interpretation>... </access_highway_restrictions_interpretation> <oneway_highway_implications>...</oneway_highway_implications> <maxspeed_highway_implications>...</maxspeed_highway_implications> <avspeed_highway_implications>...</avspeed_highway_implications> <speed_highway_variables>...</speed_highway_variables>

52 <speed_highway_units>...</speed_highway_units> <length_highway_units>...</length_highway_units> <weight_highway_units>...</weight_highway_units> <drivetime_slowdown_delay... /> </parameters> Listing 10: Aufbau der Parameter-Datei (XML) Um einen Eindruck der Definition einer Parameter-Datei zu erhalten, befinden sich im Anhang zwei Dateien für Deutschland. Listing 50 ist ein Beispiel für das Transportmittel motorcar (Auto), Listing 51 für bicycle (Fahrrad). Die meisten Parameter sind Listen, die beliebige viele Listenelemente enthalten können. Der Programmanwender ist frei, neue Listenelemente zu definieren. Im Folgenden werden die einzelnen Parameter aus der Parameter-Datei erläutert. Über den Parameter transport_mode_hierarchy wird das Transportmittel definiert. Im gleichen Zug wird die Transportmittel-Hierarchie (siehe Kapitel ) festgelegt. Da wegen der Vererbung für die Berechnung von Access-Restrictions nur der Pfad von der Wurzel (access) des Hierachiebaums zum gewählten Verkehrsmittel interessant ist, stellt der Parameter transport_mode_hierarchy auch nur diesen Pfad als Auszug aus dem Hierarchie-Baum dar. Je nach Land und Transportmittel muss dieser Pfad angepasst werden. Das letzte Element des (geordneten) Pfades stellt das aktuelle Verkehrsmittel dar. Listing 11 zeigt für Deutschland (siehe deutsche Transportmittel-Hierarchie: Anhang Abb. 54) und für den Fahrzeugtyp motorcar diesen Pfad. <transport_mode_hierarchy> <orderelement value="access"/> <orderelement value="vehicle"/> <orderelement value="motor_vehicle"/> <orderelement value="motorcar"/> </transport_mode_hierarchy> Listing 11: Parameter transport_mode_hierarchy für motorcar und Deutschland In Listing 12 ist der Pfad für ein Fahrrad (bicycle) dargestellt. <transport_mode_hierarchy> <orderelement value="access"/> <orderelement value="vehicle"/> <orderelement value="bicycle"/> </transport_mode_hierarchy> Listing 12: Parameter transport_mode_hierarchy für bicycle und Deutschland Der Parameter access_barrier_restrictions definiert die Default-Access-Restrictions für punkthafte Barrieren. Wie in Kapitel erläutert, werden mit Hilfe der Default-Tabelle für Zugangsbeschränkungen, der Transportmittel-Hierarchie (siehe Parameter transport_mode- _hierarchy) und des dazugehörigen Algorithmus die Zugangsbeschränkung berechnet. Dieser Parameter stellt die Default-Tabelle dar. Listing 13 ist ein Beispiel für diesen Parameter. <access_barrier_restrictions> <listelementstring key="cattle_grid" value="yes"/> <listelementstring key="sally_port" value="yes"/> <listelementstring key="toll_booth" value="yes"/> <listelementstring key="bollard" value="no"/> 44

53 <listelementstring key="cycle_barrier" value="no"/> <listelementstring key="block" value="no"/> <listelementstring key="stoneblocks" value="no"/> <listelementstring key="entrance" value="no"/> <listelementstring key="gate" value="no"/> <listelementstring key="lift_gate" value="no"/> <listelementstring key="gate:lift" value="no"/> <listelementstring key="stile" value="no"/> <listelementstring key="yes" value="no"/> <listelementstring key="small_fence" value="no"/> <!--hard-coded: <listelementstring key="else" value="unknown"/>--> </access_barrier_restrictions> Listing 13: Parameter access_barrier_restrictions für motorcar (Beispiel) Der Key eines Listenelements stellt den Value eines barrier-osm-tags dar. Der Value des Listenelements gibt die Default-Access-Restriction an. In Tabelle 31 im Anhang sind einige mögliche Werte aufgelistet. Neben yes und no können dies auch Werte wie unknown, private, permissive usw. sein. Der Benutzer kann beliebig viele Listenelemente festlegen. Falls bei einer Datenaufbereitung kein Listenelement für den aktuellen Node existiert, wird die Default-Access-Restriction unknown verwendet (siehe Listenelement-Key else): <!--hard-coded: <listelementstring key="else" value="unknown"/>--> Durch die Definition des Algorithmus zur Berechnung der Access-Restrictions (siehe Kapitel ) ist der else-wert hartcodiert (erkennbar an hard-coded) und kann damit nicht vom Anwender verändert werden. Da der Network Analyst bei den Restrictions nur zwischen restricted und traversable (siehe Kapitel 2.3.2) unterscheidet, muss festgelegt werden, welcher access-wert als restricted und welcher als traversable gilt. Denn nicht jeder Node mit dem OSM-Tag barrier stellt für jedes Fahrzeug eine unüberwindbare Barriere dar. So können beispielsweise Poller (bollard) von Fahrradfahrern umfahren werden. Mit Hilfe des Parameters access_barrier_restrictions_interpretation wird definiert, wann ein Node mit dem OSM-Tag barrier für das aktuelle Fahrzeug tatsächlich eine Barriere darstellt. Listing 14 ist ein Beispiel für diesen Parameter. <access_barrier_restrictions_interpretation> <listelementnoyes key="no" value="no"/> <listelementnoyes key="destination" value="no"/> <listelementnoyes key="delivery" value="no"/> <listelementnoyes key="agricultural" value="no"/> <listelementnoyes key="forestry" value="no"/> <listelementnoyes key="private" value="no"/> <listelementnoyes key="yes" value="yes"/> <listelementnoyes key="unknown" value="no"/> <listelementnoyes key="designated" value="yes"/> <listelementnoyes key="official" value="yes"/> <listelementnoyes key="permissive" value="yes"/> <!--default: <listelementnoyes key="else" value="no"/>--> </access_barrier_restrictions_interpretation> Listing 14: Parameter access_barrier_restrictions_interpretation für motorcar (Beispiel) 45

54 Der Anwender kann dieser Liste beliebige Listenelemente hinzufügen. Der Key eines Listenelements entspricht dem Value aus dem Parameter access_barrier_restrictions. Der Value eines Listenelements gibt an, ob Barrieren mit der Access-Restriction des Keys restricted (no) oder traversable (yes) sind. Hier sind nur die Werte yes (access = yes) und no (access = no) erlaubt. Um den Parameter access_barrier_restrictions_interpretation besser zu verstehen, folgt ein Beispiel: Angenommen ein OSM-Node hätte u. a. die folgenden beiden Tags: <tag k="barrier" v="gate"/> <tag k="access" v="private"/> Zur Ermittlung, ob dieser Node eine Barriere darstellt, die nicht durchlässig ist ( restricted ), werden die Listelemente des Parameters access_barrier_restrictions_interpretation (siehe Listing 14) nach dem access-value private durchsucht. Dort gibt es das Listenelement: <listelementnoyes key="private" value="no"/> Der Value no bedeut, dass dieser Node nicht durchlässig ist und somit eine echte Barriere für das gewählte Fahrzeug darstellt. Hätte kein Listenelement für die Access-Restriction private existiert, wäre auf den else-wert zurückgegriffen worden. Falls der Anwender keinen anderen Wert definiert, wird auf den in der Anwendung definierte Default-Wert für diesen else-wert zurückgegriffen (erkennbar an default): <!--default: <listelementnoyes key="else" value="no"/>--> Dieser kann jedoch vom Anwender überschrieben werden: <listelementnoyes key="else" value="yes"/> Falls ein Node mit dem OSM-Tag barrier keine echte Barriere ist, kann es aber dennoch sein, dass er ein Hindernis darstellt, wodurch die Reisezeit verlängert werden kann. Um zu definieren, in welchen Fällen sich solch ein Node negativ auf die Reisezeit auswirkt, gibt es den Parameter slow- Down_barrier_restrictions. Listing 15 stellt ein Beispiel für diesen Parameter dar. <slowdown_barrier_restrictions> <listelementnoyes key="bollard" value="yes"/> <listelementnoyes key="cycle_barrier" value="yes"/> <listelementnoyes key="block" value="yes"/> <listelementnoyes key="stoneblocks" value="yes"/> <listelementnoyes key="toll_booth" value="yes"/> <listelementnoyes key="entrance" value="yes"/> <listelementnoyes key="gate" value="yes"/> <listelementnoyes key="lift_gate" value="yes"/> <listelementnoyes key="gate:lift" value="yes"/> <listelementnoyes key="stile" value="yes"/> <listelementnoyes key="sally_port" value="yes"/> <listelementnoyes key="yes" value="yes"/> <listelementnoyes key="small_fence" value="yes"/> <listelementnoyes key="cattle_grid" value="no"/> <!--hard-coded: <listelementnoyes key="else" value="yes"/>--> </slowdown_barrier_restrictions> Listing 15: Parameter slowdown_barrier_restrictions für motorcar (Beispiel) Dieser Liste können vom Anwender weitere Elemente hinzugefügt werden. Wie auch beim Parameter access_barrier_restrictions ist der Key eines Listenelements der Value eines barrier- 46

55 OSM-Tags. Der Value des Listenelements gibt an, ob zur normalen Reisezeit zusätzlich eine Verzögerung addiert werden muss (yes) oder nicht (no). Die Dauer der Verzögerung ist im Parameter drivetime_slowdown_delay definiert (siehe unten). Neben Parametern, die sich auf punkthafte Barrieren beziehen, gibt es auch Parameter, die sich auf eine komplette Straße (highway) beziehen. Analog zu den Parametern access_- barrier_restrictions und access_barrier_restrictions_interpretation gibt es hier auch die Parameter access_highway_restrictions und access_highway_restrictions- _interpretation. Der Parameter access_highway_restrictions stellt die Default-Tabelle der Access-Restrictions für Straßen bezogen auf das gewählte Transportmittel dar (siehe Kapitel ). Listing 16 ist ein Beispiel für diesen Parameter. Diese Liste ist beliebig erweiterbar. <access_highway_restrictions> <listelementstring key="motorway" value="yes"/> <listelementstring key="motorway_link" value="yes"/> <listelementstring key="motorway_junction" value="yes"/> <listelementstring key="trunk" value="yes"/> <listelementstring key="trunk_link" value="yes"/> <listelementstring key="primary" value="yes"/> <listelementstring key="primary_link" value="yes"/> <listelementstring key="secondary" value="yes"/> <listelementstring key="secondary_link" value="yes"/> <listelementstring key="tertiary" value="yes"/> <listelementstring key="tertiary_link" value="yes"/> <listelementstring key="unclassified" value="yes"/> <listelementstring key="residential" value="yes"/> <listelementstring key="road" value="yes"/> <listelementstring key="living_street" value="yes"/> <listelementstring key="path" value="no"/> <listelementstring key="bridleway" value="no"/> <listelementstring key="cycleway" value="no"/> <listelementstring key="footway" value="no"/> <listelementstring key="pedestrian" value="no"/> <listelementstring key="service" value="yes"/> <listelementstring key="track" value="yes"/> <listelementstring key="ford" value="yes"/> <listelementstring key="steps" value="no"/> <listelementstring key="no" value="no"/> <!--hard-coded: <listelementstring key="else" value="unknown"/>--> </access_highway_restrictions> Listing 16: Parameter access_highway_restrictions für motorcar (Beispiel) Dieses Beispiel wurde auf Basis der allgemeinen Default-Tabelle (Abb. 55 im Anhang) und der deutschen Default-Tabelle (siehe Abb. 9) entwickelt. Für einige wenige Werte mussten Annahmen getroffen werden. Der Key eines Listenelements entspricht dem Value eines highway-osm-tags. In einigen Sonderfällen kann hierfür auch der Wert des construction- oder des proposed OSM-Tags verwendet werden (siehe 4.1.2). Der Value eines Listenelements gibt die Default-Access-Restriction an. Im Parameter access_highway_restrictions_interpretation (Listing 17) wird definiert, wie die Values der Listelemente aus dem Parameter access_highway_restrictions interpretiert werden ( restricted oder traversable ). 47

56 <access_highway_restrictions_interpretation> <listelementnoyes key="no" value="no"/> <listelementnoyes key="destination" value="no"/> <listelementnoyes key="delivery" value="no"/> <listelementnoyes key="agricultural" value="no"/> <listelementnoyes key="forestry" value="no"/> <listelementnoyes key="private" value="no"/> <listelementnoyes key="yes" value="yes"/> <listelementnoyes key="unknown" value="yes"/> <listelementnoyes key="designated" value="yes"/> <listelementnoyes key="official" value="yes"/> <listelementnoyes key="permissive" value="yes"/> <!--default: <listelementnoyes key="else" value="yes"/>--> </access_highway_restrictions_interpretation> Listing 17: Parameter access_highway_restrictions_interpretation für motorcar (Beispiel) Zur besseren Verständlichkeit werden die Access-Restrictions einer Straße an einem Beispiel für das Fahrzeug motorcar veranschaulicht: <tag k="bicycle" v="yes"/> <tag k="cycleway" v="opposite"/> <tag k="highway" v="residential"/> <tag k="name" v="turmstraße"/> <tag k="psv" v="yes"/> <tag k="surface" v="cobblestone"/> <tag k="taxi" v="yes"/> <tag k="vehicle" v="delivery"/> Zuerst wird ermittelt, ob diese Straße überhaupt für das gewählte Fahrzeug befahrbar ist. Anschließend wird geprüft, ob es sich um eine Einbahnstraße handelt und in welche Richtung sie geht. Mit Hilfe des Algorithmus zur Berechung der Access-Restrictions aus Kapitel wird die Befahrbarkeit berechnet. Im ersten Schritt wird die Wurzel (access) des Hierachiebaumes (siehe Anhang Abb. 54) auf unknown gesetzt. Alle anderen Blätter des Baumes erben von dieser Wurzel. Dies sind z.b. bicycle, psv, taxi oder vehicle, um die Access-OSM-Tags aus dem Beispiel zu nennen. Damit ist zunächst unbekannt, ob die Straße befahrbar ist. Im zweiten Schritt sollen laut des Algorithmus die Access-Restrictions des Hierachiebaumes mit den Default-Access-Restrictions überschrieben werden. Im Parameter access_highway_restrictions sind die Default-Access-Restrictions für das aktuelle Fahrzeug definiert. Die Default-Access- Restrictions der anderen Transportmittel sind nicht notwendig und deswegen auch nicht als Parameter in der Parameter-Datei definiert. Im Fall des Fahrzeugtyps motorcar und der Straße residential wird das Blatt motorcar des Hierachiebaumes aufgrund des folgenden Listenelementes mit yes überschrieben: <listelementstring key="residential" value="yes"/> Im dritten Schritt werden die expliziten Access-Restrictions aus dem aktuellen OSM-Way ausgelesen und in den Hierachiebaum eingetragen. Dies sind: <tag k="bicycle" v="yes"/> <tag k="psv" v="yes"/> <tag k="taxi" v="yes"/> <tag k="vehicle" v="delivery"/> 48

57 Im vierten Schritt wird nun aus dem Hierarchiebaum abgelesen, wie die Aceess-Restriction für das gewählte Fahrzeug lautet. Da motorcar von vehicle erbt, ist die Access-Restriction delivery. Jetzt ist aber immernoch nicht bekannt, ob die Straße nun befahrbar oder gesperrt ist. Deshalb wird der Parameter access_highway_restrictions_interpretation nach dem access-wert delivery durchsucht. Vom Anwender wurde folgendes Listenelement definiert: <listelementnoyes key="delivery" value="no"/> Dies bedeutet, dass diese Straße für den Fahrzeugtyp motorcar als nicht passierbar ( restricted ) interpretiert wird. Wäre als Ergebnis traversable herausgekommen, müsste jetzt noch überprüft werden, ob die Straße eine Einbahnstraße ist. Damit wird festgelegt, in welche Richtung die Straße tatsächlich passierbar ist. Wie in Kapitel erläutert, werden Einbahnstraßen nicht immer am OSM-Tag oneway erkannt. Je nach Fahrzeugtyp ergibt sich erst aus der Kombination verschiedener OSM-Tags, ob es sich um eine Einbahnstraße handelt, d.h. ob diese OSM-Tags eine Einbahnstraße implizieren. Im Parameter onway_highway_implications werden die dem Anwender bekannten Kombinationsmöglichkeiten von OSM-Tags im Weiteren auch als Fälle bezeichnet aufglistet und definiert, ob diese eine Einbahnstraße implizieren. Prinzipiell ist dieser Parameter wie in Listing 18 aufgebaut. <oneway_highway_implications> <caseoneway interpret_as_oneway="..."> <listelementstring key="..." value="..."/>... <listelementstring key="..." value="..."/> </caseoneway> </oneway_highway_implications> Listing 18: Prinzipieller Aufbau des Parameters onway_highway_implications Die Definition dieses Parameters kann im Anhang anhand der Listing 50 (für motorcar) und der Listing 51 (für bicycle) studiert werden. Diesem Parameter können beliebig viele Fälle hinzugefügt werden. Der Key eines Listenelements entspricht dem Key eines OSM-Tags, der Value eines Listenelements dem Value desselben OSM-Tags. Der Wert des XML-Attributs interpret_as_oneway darf nur die empfohlenen Werte no, yes oder -1 annehmen (siehe Tabelle 6). Alle anderen Werte müssen über die Definition des entsprechenden Falles umgeschlüsselt werden. Durch die Auflistung mehrerer Listenelemente wird die Kombination der OSM-Tags (mit ihren Values) festgelegt, die dann als Einbahnstraße interpretiert wird oder nicht (siehe XML-Attribut interpret_as_oneway). Der Value eines Listenelements kann einerseits wie schon erwähnt einen expliziten OSM-Tag- Value enthalten. Daneben sind noch sog. Wildcards, d.h. Platzhalter für Zeichen, definiert. Wie auch im OSM-Wiki [69] verwendet, bedeutet *, dass das OSM-Tag vorhanden sein muss, aber egal ist, welchen Value es hat. "" ein leerer String wird bei diesem Parameter benutzt, um festzulegen, dass dieses OSM-Tag nicht vorhanden sein darf oder, wenn es vorhanden ist, keinen Wert enthalten darf. Alle OSM-Tags, die nicht aufgeführt sind, werden ignoriert. D. h. sie dürfen vorhanden sein, müssen aber nicht. Bei der Definition des Parameters muss sehr genau darauf geachtet werden, dass die Fälle eindeutig sind. Dies bedeutet, dass es für eine Kombination von OSM-Tags mit ihren Values nur einen Fall geben darf. Andernfalls wird beim Einlesen der Parameter-Datei in die Anwendung eine Meldung aus- 49

58 gegeben, dass sie nicht valide ist. Gibt es keinen explizit definierten Fall, der zur Kombination der OSM-Tags aus der OSM-Datei passt, wird die Straße nicht als Einbahnstraße interpretiert (interpret_as_onway = no). Durch die Art und Weise, wie dieser Parameter definiert ist, können Einbahnstraßen für jedes beliebige Fahrzeug definiert werden. Über den Parameter maxspeed_highway_implications werden vom Anwender Maximalgeschwindigkeiten definiert, die dann verwendet werden, wenn ein maxspeed-osm-tag fehlt (Default- Maximalgeschwindigkeiten, siehe Kapitel ). Listing 19 ist ein Beispiel für diesen Parameter bezogen auf den Fahrzeugtyp motocar und Deutschland. <maxspeed_highway_implications> <listelementstring key="motorway" value="null"/> <listelementstring key="motorway_link" value="80"/> <listelementstring key="motorway_junction" value="80"/> <listelementstring key="trunk" value="50"/> <listelementstring key="trunk_link" value="50"/> <listelementstring key="primary" value="50"/> <listelementstring key="primary_link" value="50"/> <listelementstring key="secondary" value="50"/> <listelementstring key="secondary_link" value="50"/> <listelementstring key="tertiary" value="50"/> <listelementstring key="tertiary_link" value="50"/> <listelementstring key="unclassified" value="50"/> <listelementstring key="residential" value="50"/> <listelementstring key="road" value="50"/> <listelementstring key="living_street" value="4"/> <listelementstring key="service" value="null"/> <listelementstring key="footway" value="null"/> <listelementstring key="steps" value="null"/> <listelementstring key="track" value="null"/> <listelementstring key="pedestrian" value="null"/> <listelementstring key="cycleway" value="null"/> <listelementstring key="bridleway" value="null"/> <listelementstring key="path" value="null"/> <listelementstring key="elevator" value="null"/> <listelementstring key="tunring_circle" value="null"/> <listelementstring key="ford" value="null"/> <listelementstring key="undefined" value="null"/> <!--default: <listelementstring key="else" value="null"/>--> </maxspeed_highway_implications> Listing 19: Parameter maxspeed_highway_implications für motorcar (Beispiel) Wie bei den meisten anderen Parametern aus der Parameter-Datei gibt es hier Listenelemente, über die definiert wird, welcher Straßentyp (highway) welche Maximalgeschwindigkeit impliziert. Diese Liste kann vom Anwender angepasst und erweitert werden. Der Key eines Listenelementes entspricht dem Wert eines highway-osm-tags. Der Value eines Listenelementes repräsentiert die Maximalgeschwindigkeit (in km/h). Falls es auf einer Straße keine Geschwindigkeitsbeschränkung gibt, wird als Value null gesetzt. Dieser Wert ist auch der Default-else-Wert, falls ein Straßentyp nicht aufgelistet sein sollte. Dieser else-wert kann jedoch vom Nutzer überschrieben werden. Wie in Kapitel erläutert können statt Geschwindigkeitszahlen auch Variablen vergeben werden. Diese können auch als Value in das Listenelement eingetragen werden. Die Umschlüsselung in richtige Geschwindigkeitszahlen findet im Paramater speed_highway_variables statt (siehe un- 50

59 ten). Falls neben der eigentlichen Geschwindigekeitszahl noch eine Einheit definiert sein sollte, wird versucht, die Geschwindigkeit über den Parameter speed_highway_units umzurechnen (siehe unten). Die Maximalgeschwindigkeit wird verwendet, um die Reisezeit zu berechnen. Da aber nicht immer eine Maximalgeschwindigkeit definiert sein muss und auch nicht jeder Verkehrsteilnehmer exakt diese Geschwindigkeit fährt, gibt es zusätzlich noch Durchschnittsgeschwindigkeiten. Diese sind in OSM nicht definiert. Analog zum Parameter maxspeed_highway_implications gibt es deshalb den Parameter avspeed_highway_implications (average speed). Listing 20 ist ein Beispiel für die Definition von Durchschnittsgeschwindigkeiten bezogen auf den Fahrzeugtyp motorcar und Deutschland. <avspeed_highway_implications> <listelementstring key="motorway" value="110"/> <listelementstring key="motorway_link" value="90"/> <listelementstring key="motorway_junction" value="90"/> <listelementstring key="trunk" value="90"/> <listelementstring key="trunk_link" value="70"/> <listelementstring key="primary" value="70"/> <listelementstring key="primary_link" value="60"/> <listelementstring key="secondary" value="60"/> <listelementstring key="secondary_link" value="50"/> <listelementstring key="tertiary" value="55"/> <listelementstring key="tertiary_link" value="45"/> <listelementstring key="unclassified" value="50"/> <listelementstring key="road" value="50"/> <listelementstring key="residential" value="40"/> <listelementstring key="living_street" value="4"/> <listelementstring key="service" value="30"/> <listelementstring key="footway" value="5"/> <listelementstring key="steps" value="0"/> <listelementstring key="track" value="10"/> <listelementstring key="pedestrian" value="5"/> <listelementstring key="cycleway" value="15"/> <listelementstring key="bridleway" value="15"/> <listelementstring key="path" value="8"/> <listelementstring key="elevator" value="0"/> <listelementstring key="turning_circle" value="5"/> <listelementstring key="ford" value="5"/> <listelementstring key="undefined" value="50"/> <!--default: <listelementstring key="else" value="50"/>--> </avspeed_highway_implications> Listing 20: Parameter avspeed_highway_implications für motorcar (Beispiel) Bei dieser Festlegung der Durchschnittsgeschwindigkeiten wird sich meist an denen beim OpenRouteService verwendeten Durchschnittsgeschwindigkeiten orientiert [127]. Im Gegensatz zu den Höchstgeschwindigkeiten, darf für kein Feature der Feature Class das avspeed-feld leer (<null>) bleiben, weil sie unbedingt zur Berechnung der Fahrtzeit benötigt wird. Auch hier können Variablen sowie Einheiten verwendet werden, die über die Parameter speed_highway_variables und speed_highway_units umgeschlüsselt werden (siehe unten). Die Standard-Geschwindigkeitseinheit ist km/h. Wie schon bei den Parametern maxspeed_highway_implications und avspeed-_highway- _implications erwähnt, werden über den Parameter speed_highway_variables die Ge- 51

60 schwindigkeitsvariablen in richtige Geschwindigekeitszahlen umgeschlüsselt. Diese dürfen auch Einheiten haben. Listing 21 stellt ein Beispiel für diesen Parameter bezogen auf Deutschland dar. Diese Liste kann angepasst und erweitert werden. <speed_highway_variables> <listelementstring key="de:motorway" value="null"/> <listelementstring key="de:urban" value="50"/> <listelementstring key="de:rural" value="100"/> <listelementstring key="de:walk" value="10"/> <listelementstring key="de:living_street" value="10"/> <listelementstring key="unrestricted" value="null"/> <listelementstring key="none" value="null"/> <listelementstring key="no" value="null"/> </speed_highway_variables> Listing 21: Parameter speed_highway_variables für motorcar (Beispiel) Der Key eines Listenelements entspricht der Variable, die einem maxspeed-osm-tag, einem Value aus dem Parameter maxspeed_highway_implications oder einem Value aus dem Parameter avspeed_highway_implications zugewiesen werden kann. Der Value eines Listenelementes entspricht der Geschwindigkeitszahl (oder null, siehe oben). Einheiten sind auch erlaubt. Wie schon mehrfach erwähnt, werden über den Parameter speed_highway_units mögliche Einheiten definiert. Listing 22 zeigt ein Beispiel für diesen Parameter mit den gebräuchlichsten Einheiten. Diese Liste ist erweiterbar. <speed_highway_units> <listelementfloat key="km/h" value="1"/> <listelementfloat key="kmph" value="1"/> <listelementfloat key="kph" value="1"/> <listelementfloat key="mph" value="1.609"/> <listelementfloat key="knots" value="1.852"/> </speed_highway_units> Listing 22: Parameter speed_highway_units (Beispiel) Der Key eines Listenelements enthält die Einheit, der Value den Umrechnungsfaktor in die Standard- Geschwindigkeitseinheit km/h. Enthält beispielsweise die OSM-Datei folgendes OSM-Tag: <tag k="maxspeed" v="50 mph"/> wird die Geschwindigkeit mit Hilfe des Faktors umgerechnet: Enthält der Parameter speed_highway_units nicht die benötigte Einheit, wird der entsprechende else-value von maxspeed_highway_implications bzw. avspeed_highway_implications verwendet. Neben Geschwindigkeitsbeschränkungen gibt es auch noch Höhen- und Gewichtsbeschränkungen, die ins generierte Netz mit aufgenommen werden. Auch diese können Einheiten haben. Deshalb gibt es die beiden Parameter length_highway_units und weight_highway_units. Der Parameter length_highway_units enthält Umrechnungsfaktoren für Längen (hier Höhen), der Parameter weight_highway_units Umrechnungsfaktoren für Gewichte. Beide Parameter sind erweiterbar. Listing 23 ist ein Beispiel für den Parameter length_highway_units. 52

61 <length_highway_units> <listelementfloat key="m" value="1"/> <listelementfloat key="metre" value="1"/> <listelementfloat key="metres" value="1"/> <listelementfloat key="ft" value="0.3048"/> <listelementfloat key="feet" value="0.3048"/> </length_highway_units> Listing 23: Parameter length_highway_units (Beispiel) Die Standard-Längeneinheit in OSM ist Meter (siehe Kapitel ). Listing 24 stellt ein Beispiel für den Parameter weight_highway_units dar. <weight_highway_units> <listelementfloat key="t" value="1"/> <listelementfloat key="kg" value="0.001"/> </weight_highway_units> Listing 24: Parameter weight_highway_units (Beispiel) Die Standard-Gewichtseinheit hier ist Tonnen (siehe Kapitel ). Als letzten Parameter gibt es noch den Parameter drivetime_slowdown_delay. Listing 25 ist ein Beispiel für diesen Parameter. <drivetime_slowdown_delay barrierdelayconstant="0.1" highwayslowdownfactor="1.25" /> Listing 25: Parameter drivetime_slowdown_delay für motorcar (Beispiel) Dieser enthält die zwei XML-Attribute barrierdelayconstant und highwayslowdownfactor. Über das XML-Attribut barrierdelayconstant wird festgelegt, um welche Zeit (in Minuten) die Reisezeit verlängert wird, wenn ein Fahrzeug eine Barriere passiert (siehe Parameter slow- Down_barrier_restrictions). Das XML-Attribut highwayslowdownfactor dagegen ist ein Faktor, mit dem die Reisezeit verlängert wird, falls eine Straße verkehrberuhigt ist (OSM-Tag traffic_calming, siehe Kapitel ). Dabei wird die normale Reisezeit auf diesem Straßenstück (OSM-Way) mit dem Faktor multipliziert. Die in diesem Kapitel erklärten Parameter werden einerseits zur Befüllung der Feature Classes (siehe Kapitel 4.1.2, und 4.1.4), andererseits auch zur Definition der Network Dataset Evaluators (siehe Kapitel 4.1.5) verwendet. Tabelle 15 zeigt dazu eine Übersicht. Parameter-Name Typ Befüllung der Fields Generierung der Evaluators Source Field Evaluator Source transport_mode_hierarchy Ordnung roads access barriers access access_barrier- _restrictions Liste barriers access access_barrier_- restrictons_interpretation Liste Barrier barriers slowdown_barrier- _restrictions Liste barriers slowdown 53

62 Parameter-Name Typ Befüllung der Fields Generierung der Evaluators Source Field Evaluator Source access_highway- Liste roads access _restrictions access_highway_restrictions_interpretation oneway_highway- _implications oneway_highway- _interpretation maxspeed_highway- _implications avspeed_highway- _implications Liste Access roads Liste roads oneway Fälle roads oneway Liste roads maxspeed Liste roads avspeed speed_highway_variables Liste roads maxspeed avspeed speed_highway_units Liste roads maxspeed avspeed length_highway_units Liste roads maxheight weight_highway_units Liste roads maxweight drivetime_slowdown_delay Werte Slow- Down Tabelle 15: Verwendung der Parameter roads barriers Des Weiteren wird der Parameter access_highway_restrictions_interpretation verwendet, um die Solver Layers anzupassen (siehe Kapitel 4.1.5) Feature Class roads Das Straßennetz wird aus den in der OSM-Datei enthaltenen Ways erzeugt, die ein highway-osm- Tag haben. Alle anderen Ways werden ignoriert. Tabelle 16 zeigt die Struktur und Befüllung der Feature Class roads. Field Datentyp Länge mögliche Werte Inhalt siehe Kapitel OBJECTID Object ID 1, 2, von ArcGIS automatisch erzeugte Feature ID (Primärschlüssel) Shape Geometry Polyline von ArcGIS automatisch erzeugtes Shape Field id Integer 8 Zahl id des Ways partid Integer 8 0 (falls nicht gesplittet), > 0 (falls gesplittet) 54 partid des Ways 4.1.3

63 Field Datentyp Länge mögliche Werte Inhalt siehe Kapitel highway Text 255 motorcar, motorcar_link, trunk, trunk_link, primary, Straßentyp (i.d.r. Wert des highway-osm-tags) name Text 255 Schlossallee, Wert des name-osm-tags (Straßenname) ref Text 255 A 1 Wert des ref-osm-tags (Straßennummer) access Text 255 yes, no, destination, delivery, private, agricultural, Ergebnis der Berechnung der Beförderungsart- Beschränkung oneway Text 255 yes, no, -1 Einbahnstraße maxheight Double 8 3.3, 2.5, Wert des maxheight-osm- Tags in Metern (maximal erlaubte Fahrzeughöhe) maxweight Double 8 3.5, 4.2, Wert des maxweight-osm- Tags in Tonnen (maximal erlaubtes Fahrzeuggewicht) maxspeed Double 8 30, 45.5 Höchstgeschwindigkeit in km/h ohne Angabe der Einheit avspeed Double 8 30, 45.5 Durchschnittsgeschwindigekeit in km/h ohne Angabe der Einheit construct Text 255 yes, no, minor, Baustelle proposed Text 255 yes, no, geplante Straße traffcalm Text 255 yes, bumb, cushion, Art der Verkehrsberuhigung slowdown Text 255 yes, no Verkehrsberuhigung Shape_Length Double 8 0,001907, automatisch erzeugte Länge der Polyline (Einheit Decimal Degrees) Tabelle 16: Feature Class roads Da manche OSM-Ways aufgrund von Abbiegeverboten (Näheres dazu im Kapitel 4.1.3) gesplittet werden müssen, gibt es zusätzlich zum Field id auch noch das Field partid. Der von ArcGIS definierte Primärschlüssel ist das Field OBJECTID. Die Kombination der Fields id und partid kann jedoch auch als Primärschlüssel aufgefasst werden. Sofern aus Tabelle 16 nicht klar hervorgeht, wie die einzelnen Fields befüllt werden, wird die Befüllung im Folgenden erläutert. Dies ist i.d.r. dann der Fall, wenn der Value eines OSM-Tags nicht 1:1 übernommen wird, sondern noch eine Interpretation stattfindet. Dabei werden u.a. die Parameter aus der Parameter-Datei (siehe Kapitel 4.1.1) verwendet. 55

64 Der Wert des highway-fields wird i.d.r. aus dem highway-osm-tag bezogen. Bei im Bau oder in Planung befindlichen Straßen kann es aber vorkommen, dass der Wert aus dem constructionbzw. dem proposed-tag ausgelesen wird (siehe Kapitel ). Wie in Kapitel beschrieben können Baustellen und geplante Straßen auf verschiedene Arten getaggt werden. In Tabelle 17 sind alle theoretisch möglichen Kombinationsfälle der Schlüssel highway, construction und proposed und ihre Umsetzung in die Feature Class-Fields highway, construct und proposed aufglistet. construct-field Fall highway-wert highway-field construc tion- Wert pro- posed- Wert proposed- Field 1 construction unclassified - yes - no 2 * proposed- Wert 3 construction- Wert * - no * proposed- Wert 4 5 proposed unclassified - no - yes 6 * construction- Wert 7 proposed-wert - no * 8 * construction- Wert 9 * highway-wert - no - no 10 * proposed- Wert 11 * construction- - no 12 Wert * proposed- Wert Tabelle 17: Theoretisch mögliche Kombinationsfälle für die Schlüssel highway, construction und proposed Da eine Straße sich i.d.r. nicht gleichzeitig in Planung und im Bau befinden kann (Fälle 2, 4, 6, 8 und 12), wird angenommen, dass beim Erfassen der OSM-Daten ein Fehler unterlaufen sein müsste. Tritt einer dieser Fälle auf, soll eine Warnmeldung vom Programm ausgegeben werden. Zur Ermittlung, ob ein Verkehrsmitel auf den Straßen erlaubt ist (Field access), wird der in Kapitel beschriebene Algorithmus zur Berechnung der Beförderungsart-Beschränkung verwendet. Je nachdem für welches Land das Netz erstellt werden soll, muss auf eine andere Transportmittel- Hierarchie zurückgegriffen werden. Diese wird vom Anwender in der Parameter-Datei unter dem Parameter transport_mode_hierachy definiert. Die Default-Tabelle der Zugangsbeschränkungen wird aus dem Parameter access_highway_restrictions ausgelesen. Der Parameter access_highway_restrictions_interpretation wird erst bei der Definition des Network Dataset (siehe Kapitel 4.1.5) verwendet. 56

65 Zur Befüllung des Fields oneway (Einbahnstraße) werden die Parameter oneway_highway- _restrictions und oneway_highway_restrictions_interpretation verwendet. Somit enthält dieses Field nur die Werte no, yes oder -1. Die Werte der maximal erlaubten Fahrzeughöhe und des maximal erlaubten Fahrzeuggewichts werden aus den OSM-Tags maxheight und maxweight übernommen und falls nötig mit Hilfe der Parameter length_highway_units und weight_highway_units umgerechnet. Das Field maxspeed wird mit Hilfe des OSM-Tags maxspeed und der Parameter maxspeed- _highway_implications, speed_highway_variables sowie speed_highway_units, wie in Kapitel erläutert, befüllt. Gibt es keine Geschwindigkeitsbeschränkung, wird <null> verwendet. Da zur Ermittlung der Fahrtzeit bei Routenberechnungen für jede Straße eine Durchschnittsgeschwindigkeit vorhanden sein muss (siehe oben), wird das Field avspeed (average speed) mit in die Feature Class aufgenommen, obwohl es dazu keine Angaben in der OSM-Datei gibt. Dieses Field wird auf Basis der Parameter avspeed_highway_implications, speed_highway_implications und speed_highway_units befüllt. Zur Beschreibung von Verkehrsberuhigungsmaßnahmen werden die beiden Fields traffcalm und slowdown in die Feature Class aufgenommen. Das Field traffcalm enthält die Art der Verkehrsberuhigung, mit Hilfe des Fields slowdown wird festgehalten, ob an dieser Verkehrsberuhigungsmaßnahme die Geschwindigkeit gedrosselt werden muss. Falls ein Wert für den OSM-Schlüssel traffic_calming existiert, wird er in das Field traffcalm geschrieben und der Wert von slowdown auf yes gesetzt. Anderfalls werden sowohl traffcalm als auch slowdown auf no gesetzt. Wie schon zu Beginn gesagt, werden bei der Befüllung der Feature Class roads alle Ways verwendet, die ein highway-osm-tag haben. Es wird dabei ignoriert, ob ein solcher Way eigentlich als Fläche/Area (area = yes) definiert ist oder nicht, da das Netzwerk aus dem Network Analyst von ArcGIS keine Flächen zulässt. Die einfachste Lösung ist, Flächen (z.b. Plätze) geauso zu behandeln wie linienförmige Straßen. Da Plätze i.d.r. nicht so groß sind, hat das Routing um statt über einen Platz nur eine geringe Fahrtzeit- und Streckenverlängerung, die vernachlässigt werden können. Des Weiteren werden die OSM-Tags bridge, tunnel und layer ignoriert, die von den Renderern zur visuellen Darstellung von Brücken und Tunneln verwendet werden (siehe Kapitel ). Für deren Modellierung im Netzwerk sind diese OSM-Tags aber nicht relevant. Denn in OSM werden Straßen nur an gemeinsamen Nodes (Stützpunkten) verknüpft. Brücken, Tunnel, Unter- und Überführungen haben aber keinen Kreuzungspunkt mit kreuzenden Straßen gemein. Deshalb werden diese im Netzwerk automatisch durch ihre Definition der Stützpunkte modelliert Feature Class turns Die Abbiegegebote und -verbote aus OSM werden aus den Relations ausgelesen, dessen type-osm- Tag den Wert restriction hat. Der Wert des restriction-osm-tags gibt u. a. an, ob es sich um ein Gebot (only_*_*) oder Verbot (no_*_*) handelt. Näheres dazu im Kapitel In dieses Konzept werden nur Abbiegevorschriften aufgenommen, die von einem Way über einen Node zu einem anderen Way gehen. Abbiegevorschriften über mehrere Ways oder/und Nodes werden nicht berücksichtigt, da sie sehr selten vorkommen (siehe Kapitel ). Da aber in ArcGIS keine Abbiegegebote unterstützt werden, müssen alle Gebote in Verbote umgewandelt werden. Dazu muss die Kreuzungs- oder Einmündungssituation analysiert werden. Abb. 16, 57

66 Listing 26 und Listing 27 zeigen ein Beispiel für die Umrechnung eines Abbiegegebots (only_straight_on) in Abbiegeverbote (no_left_turn und no_right_turn). Abb. 16: Umwandlung eines Abbiegegebots in Abbiegeverbote (Relation , Münster) 1 <relation id="303551" user="hugoe" uid="7426" visible="true" version="1" changeset=" " timestamp=" t21:48:58z"> <member type="way" ref=" " role="from"/> <member type="node" ref=" " role="via"/> <member type="way" ref=" " role="to"/> <tag k="restriction" v="only_straight_on"/> <tag k="type" v="restriction"/> </relation> Listing 26: Original-Abbiegegebot (Relation , Münster) 2 <relation id="" user=" " uid="" visible="true" version="1" changeset="" timestamp=""> <member type="way" ref=" " role="from"/> <member type="node" ref=" " role="via"/> <member type="way" ref=" " role="to"/> <tag k="restriction" v="no_left_turn"/> <tag k="type" v="restriction"/> </relation> <relation id="" user=" " uid="" visible="true" version="1" changeset="" timestamp=""> <member type="way" ref=" " role="from"/> <member type="node" ref=" " role="via"/> <member type="way" ref=" " role="to"/> <tag k="restriction" v="no_right_turn"/> <tag k="type" v="restriction"/> </relation> Listing 27: Umgewandeltes Abbiegegebot in Abbiegeverbote (Relation , Münster) 3 Bei der Umwandlung von Abbiegegeboten in -verbote muss die gesamte OSM-Datei nach Ways durchsucht werden, die den Kreuzungsnode (hier: ) enthalten. Neben den beiden am Abbiegegebot beteiligten Ways (from: , Listing 28; to: , Listing 29) sollte mindestens noch ein weiterer Way existieren. (Andernfalls wäre ein Abbiegegebot nicht sinnvoll, da weder

67 eine Einmündung noch eine Kreuzung existiert.) In diesem Beispiel gibt es zwei weitere Ways: (Listing 30) und (Listing 31). <way id=" " user="hugoe" uid="7426" visible="true" version="8" changeset=" " timestamp=" t21:48:59z"> <nd ref=" "/> <nd ref=" "/> <nd ref=" "/> <nd ref=" "/> <nd ref=" "/> <tag k="highway" v="trunk_link"/> <tag k="name" v="weseler Straße"/> <tag k="oneway" v="yes"/> <tag k="source" v="survey"/> </way> Listing 28: from-way des Abbiegegebots der Relation (Münster) 1 <way id=" " user="hugoe" uid="7426" visible="true" version="1" changeset=" " timestamp=" t21:48:57z"> <nd ref=" "/> <nd ref=" "/> <nd ref=" "/> <nd ref=" "/> <nd ref=" "/> <nd ref=" "/> <nd ref=" "/> <nd ref=" "/> <nd ref=" "/> <nd ref=" "/> <nd ref=" "/> <tag k="highway" v="trunk_link"/> <tag k="name" v="weseler Straße"/> <tag k="oneway" v="yes"/> <tag k="source" v="survey"/> </way> Listing 29: to-way des Abbiegegebots der Relation (Münster) 2 <way id=" " user="hugoe" uid="7426" visible="true" version="1" changeset=" " timestamp=" t21:48:57z"> <nd ref=" "/> <nd ref=" "/> <tag k="highway" v="primary"/> <tag k="maxspeed" v="70"/> <tag k="name" v="weseler Straße"/> <tag k="oneway" v="yes"/> <tag k="ref" v="b 219"/> </way> Listing 30: to-way des umgewandelten Abbiegegebots in ein Links-Abbiegeverbot (Relation , Münster) 3 <way id=" " user="hugoe" uid="7426" visible="true" version="1" changeset=" " timestamp=" t21:48:57z">

68 <nd ref=" "/> <nd ref=" "/> <nd ref=" "/> <tag k="highway" v="primary"/> <tag k="maxspeed" v="70"/> <tag k="name" v="weseler Straße"/> <tag k="oneway" v="yes"/> <tag k="ref" v="b 219"/> </way> Listing 31: to-way des umgewandelten Abbiegegebots in ein Rechts-Abbiegeverbot (Relation , Münster) 1 Bei diesem Beispiel ist es nicht unbedingt notwendig, dass das Links-Abbiegeverbot erstellt wird, da der Way eine Einbahnstraße ist und die Richtung des Ways zur Kreuzung hinführt. Aus diesem Grund darf an dieser Kreuzung sowieso nicht links abgebogen werden. Da es aber nicht schaden kann, wenn alle Abbiegegebote in -verbote umgewandelt werden, soll von der Anwendung die Einbahnstraßensituation bei der Erstellung der Abbiegeverbote nicht geprüft und behandelt werden. Da ohne eine zusätzliche Auswertung der geografischen Lage die Topologie der Ways zueinander nicht herausgefunden werden kann, kann nicht ermittelt werden, ob es sich beispielsweise um ein Links- oder Rechts-Abbiegeverbot handelt. Aus diesem Grund wird bei der Umwandlung in Abbiegeverboten statt der restriction-osm-tag-werte no_left_turn, no_right_turn und no_straight_on nur der Wert no verwendet. Wie in Kapitel beschrieben, gibt es in ArcGIS eine spezielle Feature Class namens Turn Feature Class. Da bei den in diesem Konzept berücksichtigten Abbiegevorschriften nur zwei Ways vorkommen, enthält die Turn Feature Class nur Fields für zwei Edges: Edge1End Edge1FCID Edge1FID Edge1Pos Edge2FCID Edge2FID Edge2Pos Für das Field Edge1End wird immer der Wert Y gesetzt, da das Abbiegeverbot durch den Beginn der ersten Edge geht. Die Fields Edge1FCID und Edge2FCID enthalten für jeden Datensatz die Feature Class ID der Feature Class roads (siehe Kapitel 4.1.2). Mit Hilfe der Fields Edge1FID und Edge2FID wird auf die Object IDs der Edges aus der Feature Class roads verwiesen, auf die sich die Abbiegeverbote beziehen. Das Field Edge1FID entspricht der Object ID des from-ways, das Field Edge2FID der Object ID des to-ways. Der Einfachheit halber werden für die Positionen auf den Edges (Edge1Pos und Edge2Pos) die Positionen genommen, die am nächsten zum Kreuzungspunkt sind. In Abb. 17 ist die Zuweisung der Edge-Positionen grafisch dargestellt

69 Abb. 17: Zuweisung der Edge-Positionen Die Pfeile geben an, in welcher Richtung die Line Features digitalisiert sind. Endet oder beginnt eine Edge an der Kreuzung, kommen nur die beiden Werte 0 oder 1 in Frage. Bei den ursprünglich als Abbiegeverbote definierten Abbiegevorschriften (no_left_turn, no_right_turn, no_straight_on und no_u_turn) ist dies auch immer der Fall. Doch bei der Umwandlung von Abbiegegeboten (only_left_turn, only_right_turn, only_straight_on) in Abbiegeverbote (no), kann es vorkommen, dass ein als to-way referenzierter Way nicht an der Kreuzung beginnt oder endet, sondern durchgeht. In diesem Fall müsste ermittelt werden, welche Edge-Position die Kreuzung auf dem to-way hat. Die Abb. 18 zeigt einen solchen Fall. Abb. 18: Theoretische Zuweisung der Edge Positions bei ungesplitteten Edges Da aber die Berechnung dieser Edge-Position kompliziert ist, werden stattdessen die to-ways in den Daten an den Kreuzungen aufgesplittet, die durch sie hindurchgehen. Dieses Verfahren wird hier als Splitting bezeichnet. In Abb. 19 ist eine solche Situation (für eine Kreuzung in Münster) dargestellt. 61

70 Abb. 19: Umwandlung eines Abbiegegebots in Abbiegeverbote mit Splitting (Relation , Münster) 1 Die beiden unteren Grafiken sind der Abbildung hinzugefügt, um zu verdeutlichen, wo die Ways beginnen bzw. enden. In der linken unteren Grafik kann man sehen, dass vor der Umwandlung des Abbiegegebots in zwei Abbiegeverbote der spätere to-way noch durch die Kreuzung läuft. Bei der Umwandlung findet dann eine Aufsplittung des to-ways statt, so dass zwei Edges entstehen. Um die aufgesplitteten Ways eindeutig identifizieren zu können, wird ihnen eine Teil-ID, genannt partid, zugewiesen. Diese partid wird als weiteres Field in die Feature Class roads hinzugefügt und bildet zusammen mit dem Field id theoretisch den Primärschlüssel (siehe Kapitel 4.1.2). (In der Praxis ist das Field OBJECTID der Primärschlüssel.) Ist die partid 0, handelt es sich um einen ungesplitteten Way. Ist sie dagegen größer als 0, wurde der Way mindestens einmal aufgesplittet. In den Daten kann es vorkommen, dass Ways mehrmals aufgesplittet werden, wenn sie durch mehrere Kreuzungen gehen, bei denen Abbiegegebote in verbote umgewandelt werden müssen. Die roten und grünen Pfeile in der Abbildung geben die Richtung der Abbiegevorschriften an, nicht aber die aus den OSM-Daten vorgegebe Digitalisierungsrichtung. Diese wird beibehalten, da sich darauf auch Einbahnstraßen und andere Routing-Attribute beziehen (siehe Kapitel 4.1.5). Die in den vorangegangenen Abschnitten beschriebenden Fields beziehen sich darauf, wie die Abbiegeverbote definiert und mit der Feature Class roads verknüpft sind. Um aber die Abbiegeverbote grafisch zu veranschaulichen, muss auf die Koordinaten der Ways zurückgegriffen werden. Theoretisch könnte man für jedes Abbiegeverbot den kompletten from- als auch den (evt. übersetzten) to- Way verwenden. Da aber diese Ways unter Umständen sehr lang sein können, trägt das nicht zu einer übersichtlichen Darstellung bei. Im Prinzip ist es nur notwendig, das Turn Feature (Line Feature) aus drei Points (Nodes) in der folgenden Reihenfolge aufzubauen:

71 dem der Kreuzung nächstgelegenen Node des from-ways (siehe Field fromnode in Tabelle 18) dem Kreuzungsnode (via-node) (siehe Field vianode in Tabelle 18) dem der Kreuzung nächstgelegenden Node des to-ways (siehe Field tonode in Tabelle 18) In Abb. 20 ist dies grafisch veranschaulicht. Abb. 20: Verwendete Nodes für die grafische Darstellung eines Abbiegeverbots Die Tabelle 18 zeigt als Zusammenfassung die Struktur dieser Turn Feature Class. Neben den von ArcGIS vordefinierten und in den vorangegangenen Abschnitten erläuterten Fields, enthält diese Tabelle noch weitere Fields, die die Abbiegeverbote identifizieren und beschreiben. Die Fields rel_id, fromnode, vianode, tonode, fromway und toway enthalten OSM-IDs, die auf Nodes, Ways oder Relations verweisen. Field Datentyp Länge mögliche Werte Inhalt OBJECTID Object ID 4 1, 2, von ArcGIS automatisch erzeugte Feature ID (Primärschlüssel) SHAPE Geometry 0 Polyline von ArcGIS automatisch erzeugtes Shape Field Edge1End String 1 Y siehe Kapitel Edge1FCID Integer 4 1, 6, siehe Kapitel Edge1FID Integer 4 342, 1907, siehe Kapitel Edge1Pos Double 8 0, 1 siehe Kapitel Edge2FCID Integer 4 1, 6, siehe Kapitel Edge2FID Integer 4 344, 7166, siehe Kapitel Edge2Pos Double 8 0, 1 siehe Kapitel SHAPE_Length Double , automatisch erzeugte Länge der Polyline (Einheit Decimal Degrees) restrict String 255 no_left_turn, no_right_turn, no_u_turn, no 63 Art des Abbiegeverbots rel_id Integer , ID der Relation, auf der das Abbiegeverbot basiert.

72 Field Datentyp Länge mögliche Werte Inhalt fromnode Integer , from-node-id vianode Integer , via-node-id tonode Integer , to-node-id fromway Integer , from-way-id toway Integer , to-way-id Tabelle 18: Feature Class turns Feature Class barriers Die Feature Class barriers enthält punkthafte Barrieren und Verkehrsberuhigungsmaßnahmen. Barrieren werden dabei aus dem barrier-osm-tag, Verkehrsberuhigungsmaßnahmen über das OSM- Tag traffic_calming definiert. Wie schon in Kapitel beschrieben, müssen Barrieren allerdings nicht für jedes Fahrzeug eine richtige Barriere darstellen. In manchen Fällen muss beim Passieren einer Barriere nur die Geschwindigkeit gedrosselt werden, was eine Fahrtzeitverlängerung nach sich zieht. Dies entspricht dann im Prinzip einer Verkehrsberuhigungsmaßnahme. Aus diesem Grund enthält die Feature Class barriers sowohl Barrieren (barrier) als auch Verkehrsberuhigungsmaßnahmen (barrier, traffic_calming). Damit muss nicht jedes Feature dieser Feature Class zwangsläufig eine richtige Barriere sein, die nicht passierbar ist. Dies muss bei der Definition der Network Attributes berücksichtigt werden (siehe Kapitel 4.1.5). Tabelle 19 zeigt die Struktur und Befüllung der Feature Class barriers. Field Datentyp Länge mögliche Werte Inhalt siehe Kapitel OBJECTID Object ID 1, 2, von ArcGIS automatisch erzeugte Feature ID (Primärschlüssel) Shape Geometry Point von ArcGIS automatisch erzeugtes Shape Field id Integer 8 Zahl id des Nodes barrier Text 255 bollard, gate, no, traffcalm Text 255 bump, cushion, yes, no access Text 255 yes, no, destination, delivery, private, agricultural, Art der Barriere, Wert des barrier-osm-tags oder no Art der Verkehrsberuhigung, Wert des traffic_calming- OSM-Tags oder no Ergebnis der Berechnung der Beförderungsart-Beschränkung slowdown Text 255 yes, no Verkehrsberuhigung Tabelle 19: Feature Class barriers In die Feature Class barriers werden alle Nodes aufgenommen, die entweder ein barrier- oder ein traffic_calming-osm-tag haben. Ein Node kann auch beide gleichzeitg haben, wobei das in der 64

73 Praxis kaum vorkommen dürfte. Falls das barrier-osm-tag vorhanden sein sollte, enthält das Field barrier dessen Wert, andernfalls wird der Wert auf no gesetzt. Entsprechendes gilt für das Field traffcalm, das sich auf den Wert des traffic_calming-osm-tags bezieht. Wie auch Straßen (siehe Kapitel 4.1.2) können Barrieren Zugangsbeschränkungen für bestimmte Verkehrsmittel haben. Die Berechnung der Beförderungsart-Beschränkung erfolgt analog zu den Straßen und basiert auf dem in Kapitel beschriebenen Algorithmus. Das Ergebnis der Berechnungen wird in das Field access geschrieben. Je nachdem für welches Land das Netz erstellt werden soll, muss auf eine andere Transportmittel-Hierarchie zurückgegriffen werden. Diese wird vom Anwender in der Parameter-Datei unter dem Parameter transport_mode_hierachy definiert. Die Default-Tabelle der Zugangsbeschränkungen wird aus dem Parameter access_barrier_restrictions ausgelesen. Der Parameter access_barrier_restrictions_interpretation wird erst bei der Definition des Network Dataset (siehe Kapitel 4.1.5) verwendet. Falls nur das OSM-Tag traffic_calming vorhanden sein sollte, wird das Field access immer auf yes gesetzt. Wie schon beschrieben, kann eine Barriere, die passierbar ist, als Verkehrsberuhigung dienen. Dies wird mit Hilfe des Parameters slowdown_barrier_restrictions ermittelt. Der entsprechende Wert (yes oder no) wird verwendet, um das Field slowdown zu befüllen. Ist das aktuelle Feature eine echte Verkehrsberuhigung (traffic_calming), ist dieser Wert immer yes Network Dataset Im Network Dataset werden alle Sources gebündelt und miteinander verknüpft, die zusammen das Netzwerk bilden. Das Network Dataset enthält die in Tabelle 20 aufgelisteten Network Dataset Sources. Während die Feature Class roads Edge Features enthält, sind die Feature Classes barriers und Network_Dataset_ND_Junctions Junctions. Name Element Type Type roads Edge Edge Feature barriers Junction Junction Feature Network_Dataset_ND_Junctions Junction System Junction Tabelle 20: Network Dataset Sources Zusätzlich wird noch die Turn Feature Class turns referenziert. Im OSM-Format stellen die referenzierten Nodes eines Ways die Stützpunkte dar. Nodes, die von mindestens zwei Ways (highway) referenziert werden, sind damit Kreuzungspunkte (Junctions). An solchen Kreuzungen kann von einem Way zum anderen gewechselt werden. Aus diesem Grund wird im Network Dataset für die Feature Class roads die Connectivity Policy Any Vertex (siehe Kapitel 2.3.1) gewählt, da sie Edges über ihre Stützpunkte miteinander verknüpft. Da der Feature Class roads die Connectivity Policy Any Vertex zugewiesen wird, ist es egal, welche Connectivity Policy die Feature Class barriers erhält. Honor würde die Connectivitiy Policy der Feature Class roads respektieren. Override ignoriert die Connectivity Policy der Feature Class roads und behandelt sie, als ob sie die Connectivity Policy Any Vertex hätte. Da sie diese Policy ohnehin schon hat, spielt es keine Rolle, welche Connectivity Policy der Feature Class barriers zugewiesen wird. 65

74 Da in diesem Network Dataset nur eine Feature Class für Edges (roads) und eine Junction Feature Class (barriers) existiert, die miteinander verknüpft werden sollen, gibt es nur eine Connectivity Group (1). In Tabelle 21 sind die verwendeten Connectivity-Einstellungen tabellarisch zusammengefasst. Source Connectivity Policy Connectivity Group roads Any Vertex 1 barriers Override 1 Tabelle 21: Connectivity-Einstellungen Für die Elevation-Einstellungen im Network Dataset werden Voreinstellungen verwendet, da das Network Dataset nur eine Line Feature Class (roads) enthält, dessen Connectivity über die Connectivity Policy und die Connectivity Group schon ausreichend definiert ist. Nachdem die Grundeinstellungen für das Network Dataset definiert sind, wird das eigentliche Kernstück, die Network Attributes, spezifiziert. Diese spielen eine sehr große Rolle im Network Dataset, da sie Restriktionen, Kosten, usw. definieren. In Tabelle 22 sind die umzusetzenden Restriktionen bezogen auf die verschiedenen Sources aufgelistet. Restriction Network Attribute roads barriers turns Zugangsbeschränkungen für bestimmte Access x Straßentypen in Planung oder im Bau befindliche Straßen Closed x Einbahnstraßen Oneway x Abbiegeverbote TurnRestriction x maximal erlaubte Fahrzeughöhe HeightRestriction x maximal erlaubtes Fahrzeuggewicht WeightRestriction x Barrieren Barriers x Tabelle 22: Restriktionen im Network Dataset Tabelle 23 zeigt eine Übersicht über die Kosten. Cost Network Attribute roads barriers turns Straßenlänge Length x Fahrtzeit DriveTime x x Tabelle 23: Kosten im Network Dataset Diese Restriktionen und Kosten werden in Network Attributes umgesetzt. Manche der Network Attributes müssen aus mehreren Network Attributes aufgebaut werden. Dies trifft auf die Fahrtzeit ( DriveTime ), auf die Höhenbeschränkung ( HeightRestriction ) und auf die Gewichtsbeschränkung ( WeightRestriction ) zu. 66

75 In Tabelle 24 sind alle Network Attributes, ihre Unterattribute, die von ihnen verwendeten Fields und Network Dataset Parameters (nicht zu verwechseln mit den Parametern aus der Parameter-Datei) dargestellt. Source Attribute und Unterattribute Fields Network Dataset Parameters roads Access access barriers turns Closed HeightRestriction construct proposed MaxHeight maxheight Height WeightRestriction Oneway Length DriveTime MaxWeight maxweight Weight SlowDown Length Speed DriveTime Barrier SlowDown TurnRestriction AvSpeed MaxSpeed oneway SHAPE slowdown SHAPE avspeed maxspeed slowdown access Tabelle 24: Übersicht über die Network Attributes und ihre Unterattribute In Tabelle 25 sind alle Network Attributes mit ihren Eigenschaften aufgelistet. Der Use by Default - Wert wird bei allen Attributen, die nur als Unterattribute fungieren oder gerade nicht verwendet werden, auf False gesetzt. Unterattribute werden nur indirekt von anderen Attributen verwendet. Name Usage Units Data Type Use by Default True False Access Restriction Unknown Boolean True AvSpeed Descriptor Unknown Double False Barrier Restriction Unknown Boolean True Closed Restriction Unknown Boolean True DriveTime Cost Minutes Double True HeightRestriction Restriction Unknown Double True Length Cost Meters Double False MaxHeight Descriptor Unknown Double False 67

76 Name Usage Units Data Type Use by Default True False MaxSpeed Descriptor Unknown Double False MaxWeight Descriptor Unknown Double False Oneway Restriction Unknown Boolean True SlowDown Descriptor Unknown Boolean False Speed Cost Unknown Double False TurnRestriction Restriction Unknown Booelan True WeightRestriction Restriction Unknown Boolean True Tabelle 25: Network Attributes Das Network Attribute Access definiert die Zugangsbeschränkungen für bestimmte Straßentypen und ist damit eine Restriction. Es bezieht sich auf die Feature Class roads. Der Feature Class roads wird sowohl in (FROM-TO) als auch gegen (TO-FROM) die Digitalisierungsrichtung der gleiche Field Expression Evaluator zugewiesen. Mit Hilfe eines VBScripts wird berechnet, ob die aktuelle Straße passierbar ( traversable ) oder unpassierbar ( restricted ) ist. Dazu wird der Wert des Fields access aus der Feature Class roads mit Hilfe des Parameters access_highway_restrictions- _interpretation (siehe Kapitel 4.1.1) ausgewertet. Das VBScript wird automatisch auf Basis dieses Parameters generiert. Je nachdem, welcher else-wert vom Anwender definiert worden ist, muss das VBScript anders aufgebaut sein. Ist der else-wert yes (passierbar, Default-Wert), ist die Variable restricted zu Anfang auf False (passierbar) gesetzt und kann später mit True überschrieben werden, wenn einer der no-fälle auftritt. Ist der else-wert vom Benutzer auf no gesetzt, verhält es sich genau andersherum. Das Listing 32 ist ein Beispiel für diesen Field Expression Evaluator und basiert auf dem Listing 17 aus Kapitel restricted = False Select Case [access] Case "no", "destination", "delivery", "agricultural", "forestry", "private" restricted = True End Select Listing 32: Network Attribute "Access" Evaluator (roads, FROM-TO und TO-FROM, Beispiel) Das Network Attribute Closed ist wie Access auch eine Restriction. Es bezieht sich auf geplante und im Bau befindliche Straßen und wertet die Fields construct und proposed aus der Feature Class roads aus.wie auch beim Network Attribute Access hat dieses ein Field Expression Evaluator, der für beide Digitalisierungsrichtungen gilt. Im Gegensatz zum Network Attribute Access ist das VBScript statisch. Es verändert sich also nicht in Abhänigkeit von Parametern. In Listing 33 ist dieses VBScript dargestellt. Ist die Straße in Planung oder befindet sie sich momentan im Bau, wird sie gesperrt. restricted = False If [construct] = "yes" OR [proposed] = "yes" Then restricted = True End If Listing 33: Network Attribute "Closed" (roads, FROM-TO und TO-FROM) 68

77 Das Network Attribute Length ist als Cost definiert und gibt die Straßenlänge in der Einheit Meter an. Die Straßenlänge wird für beide Digitalisierungsrichtungen über Field Evaluators bezogen. Diese Field Evaluators lesen das Field SHAPE aus der Feature Class roads aus. Es ist nicht sinnvoll, das Field SHAPE_LENGTH auszulesen, da dieses eine bestimmte Einheit (Decimal Degrees) hat, die zuerst umgerechnet werden müsste. Dieses Network Attribute kann benutzt werden, um eine Route mit der kürzesten Strecke zu berechnen. Wird die Route nach der kürzesten Fahrtzeit ermittelt, kommt das Network Attribute Length als Unterattribut innerhalb des Network Attributes DriveTime zu Anwendung. Die Fahrtzeit pro Straßenstück wird mit Hilfe des Network Attributes DriveTime (Cost) berechnet. Dieses bezieht sich, wie schon erwähnt, auf mehrere Unterattribute. Sowohl die Straßen als auch Barrieren können zur Fahrtzeit beitragen. Wie allgemein bekannt ist, wird die Fahrtzeit über die Straßenlänge und die gefahrene Geschwindigkeit berechnet: Die Straßenlänge wird aus dem Network Attribute Length (Cost) bezogen (siehe oben). Die Geschwindigkeit stammt aus dem Network Attribute Speed und ist als Cost definiert. Sie hat die Standardeinheit von OSM km/h. Wie man der Tabelle 24 entnehmen kann, setzt sich das Network Attribute Speed aus den Unterattributen AvSpeed und MaxSpeed (beide Cost) zusammen. Das Network Attribute AvSpeed hat einen Field Evaluator, der das Field avspeed aus der Feature Class roads ausliest. Entsprechendes gilt für MaxSpeed. Dieses Attribut liest mit Hilfe des Field Evaluators das Field maxspeed aus. Im Network Attribute Speed wird anschließend mit Hilfe des VBScript Evaluators aus den beiden Attributen AvSpeed und MaxSpeed die Geschwindigkeit ermittelt. Hat die aktuelle Straße kein Geschwindigkeitsbegrenzung ( MaxSpeed = null), wird für die Geschwindigkeit die Durchschnittsgeschwindigkeit ( AvSpeed ) verwendet. Gibt es dagegen eine Maximalgeschwindigkeit, wird überprüft, ob dieses kleiner ist als die angegebene Durchschnittsgeschwindigkeit. Ist sie kleiner, wird als Geschwindigkeit die Höchstgeschwindigkeit verwendet. Andernfalls wird auf die Durchschnittsgeschwindigkeit zurückgegriffen. Die Idee dahinter ist, dass es Fahrzeuge gibt, die niemals die erlaubte Höchstgeschwindigkeit erreichen können. Deshalb wird in den Fällen, in denen sie größer ist als die erwartete Durchschnittsgeschwindigkeit für dieses Fahrzeug und diesen Straßentyp, ignoriert. Listing 34 zeigt das VBScript des VBScript Evaluators von Speed. maxspeed = Edge.AttributeValueByName("MaxSpeed") avspeed = Edge.AttributeValueByName("AvSpeed") If maxspeed = null Or maxspeed = 0 Then If avspeed = null Then 'Not allowed speed = 0 Else speed = avspeed End If Else If avspeed = null Then 'Not allowed speed = maxspeed Else If maxspeed < avspeed Then speed = maxspeed Else speed = avspeed End If 69

78 End If End If Listing 34: Network Attribute "Speed" (roads, FROM-TO und TO-FROM) Aus den beiden Network Attributes Length und Speed und unter Berücksichtigung ihrer Einheiten ergibt sich folgende Formel zur Berechung der Fahrtzeit in Minuten (min): [ ] Da die Formel im Network Dataset definiert ist, kann der Anwender sie ändern. Möchte er z.b. die Fahrtzeit statt in Minuten in Stunden berechnet haben, muss die 60 im Zähler entfernt werden. Des Weiteren muss dann die Einheit des Evaluators DriveTime durch Hours ersetzt werden (siehe Tabelle 25). Die oben aufgeführte Formel zur Berechnung der Fahrzeit ist noch nicht ganz vollständig. In ihr fehlt noch die Berücksichtung von Verkehrsberuhigungmaßnahmen. Die Information, ob es sich um eine solche Maßnahme handelt und sie sich dadurch negativ auf die Fahrtzeit auswirkt, erhält man aus dem Network Attribute SlowDown (Restriction). Dieses enthält einen Field Expression Evaluator für beide Digitalisierungsrichtungen und wertet das Field slowdown aus der Feature Class roads aus. Listing 35 zeigt die den VBScript-Code dieses Attribut. slowdown = False If [slowdown] <> "no" Then slowdown = True End If Listing 35: Network Attribute "SlowDown" (roads, FROM-TO und TO-FROM) Im Fall einer Verkehrsberuhigungsmaßnahme wird die Fahrzeit mit dem Faktor highwayslowdown- Factor aus dem Parameter drivetime_slowdown_delay (siehe Kapitel 4.1.1, Listing 25) multipliziert. Listing 36 zeigt ein Beispiel der vollständige Formel zur Berechnung der Fahrtzeit für Straßen (VBScript Evaluator). In diesem VBScript wird noch der Fall behandelt, falls die Geschwindigkeit 0 sein sollte. 'Speed must not be 0 (division by 0). speed = Edge.AttributeValueByName("Speed") If speed = 0 Then speed = End If slowdownfactor = 1 If Edge.AttributeValueByName("SlowDown") = True Then slowdownfactor = 1.25 End If drivetime = slowdownfactor * (Edge.AttributeValueByName("Length") * 60) / (speed * 1000) Listing 36: Network Attribute "DriveTime" (roads, FROM-TO und TO-FROM, Beispiel) Wie schon in Kapitel beschrieben, können Barrieren auch eine Fahrtzeitverlängerung bewirken. Da man aber bei Barrieren keine schon bestehende Fahrtzeit mit einem Faktor multiplizieren kann, 70

79 wird hier eine Konstante zur Gesamtfahrtzeit hinzuaddiert. Diese Konstante (in Minuten) wird aus dem Attribut barrierdelayconstant des Parameters drivetime_slowdown_delay (siehe Kapitel 4.1.1, Listing 25) entnommen. Die Information, ob bei dieser Barriere eine Fahrtzeitverlängerung eintritt, erhält man aus dem Network Attribute SlowDown (Restriction). Dieses hat für die Feature Class barriers einen Field Expression Evaluator, der das slowdown Field aus dieser Feature Class auswertet. Listing 37 zeigt das VBScript dieses Evaluators. slowdown = False If [slowdown] <> "no" Then slowdown = True End If Listing 37: Network Attribute "SlowDown" (barriers) Das Network Attribute SlowDown wird anschließend im VBScript Evaluator (bezogen auf die Feature Class barriers) des Network Attributes DriveTime verwendet. Handelt es sich um eine Barriere, die passierbar ist, aber bei der man die Geschwindigkeit drosseln muss, wird die Fahrtzeit für diese Barriere auf den aus der Parameter-Datei ermittelten Wert gesetzt. Andernfalls is die Fahrzeit 0. Damit kostet das Passieren dieser Barriere nichts. In Listing 38 ist ein Beispiel für die Berechnung der Fahrzeit von Barrieren dargestellt. drivetime = 0 If Junction.AttributeValueByName("SlowDown") = True Then drivetime = 0.1 End If Listing 38: Network Attribute "DriveTime" (barriers, Beispiel) Über das Network Attribute HeightRestriction (Restriction) wird ermittelt, wann eine Straße abhängig von der aktuellen Fahrzeughöhe und der maximal erlaubten Fahrzeughöhe gesperrt ist. Die maximal erlaubte Fahrzeughöhe ist über das Unterattribut MaxHeight (Cost) definiert. Dieses hat für beide Digitalisierungsrichtungen den gleichen Field Evaluator, der auf das Field maxheight aus der Feature Class roads zurückgreift. Die aktuelle Fahrzeughöhe wird über den Network Dataset Parameter Height des Network Attributes HeightRestriction festgelegt. Das Network Attribute HeightRestriction hat für beide Digitalisierungsrichtungen den gleichen Function Evaluator. Dieser ist so definiert, dass die Straße gesperrt ist, sobald der Wert des Unterattributs MaxHeight kleiner ist als der Wert des Parameters Height. Eine Ausnahme stellt der Wert 0 für den Parameter Height dar, der angibt, dass die Fahrzeughöhe unbekannt ist. In diesem Fall ist die Straße immer passierbar (siehe Kapitel 2.3.2). Standardmäßig wird der Wert dieses Parameters Height auf 0 gesetzt. Der Parameter kann nachträglich vom Benutzer sowohl im Network Dataset in ArcCatalog als auch über die Layer Properties eines Solver Layers in ArcMap angepasst werden. Das Network Attribute WeightRestriction (Restriction) ist analog zum Network Attribute HeightRestriction definiert. Das aktuelle Fahrzeuggewicht wird durch den Network Dataset Parameter Weight, das maximal erlaubte Fahrzeuggewicht durch das Network Attribute MaxWeight (Cost) festgelegt. Dieses greift auf das Field maxweight aus der Feature Class roads zurück. Im Function Evaluator des Network Attributes WeightRestriction werden dann Weight und MaxWeight zusammengeführt und ermittelt, ob die Straße gesperrt ist. 71

80 Das Network Attribute Onway (Restriction) wird verwendet, um Einbahnstraßen zu definieren. Dieses Attribute hat für jede Digitalisierungsrichtung einer Straße einen eigenen Field Expression Evaluator. Diese geben an, ob die Straße in die jeweilige Richtung gesperrt ist. Beide Evaluators greifen auf das Field oneway aus der Feature Class roads zurück. Eine Straße ist in Digitalisierungsrichtung befahrbar, wenn der Wert des Fields oneway yes oder no ist. Ist der Wert dagegen -1, ist die Straße gesperrt. Dieser Wert wird im Field Expression Evaluator verwendet (siehe Listing 39). restricted = False If [oneway] = "-1" Then restricted = True End If Listing 39: Network Attribute "Oneway" (roads, FROM-TO) Analog zum gerade beschriebenen Fall, ist die Straße gegen die Digitalisierungsrichtung nur dann gesperrt, wenn der Wert dieses Fields oneway yes ist (siehe Listing 40). restricted = False If [oneway] = "yes" Then restricted = True End If Listing 40: Network Attribute "Oneway" (roads, TO-FROM) Nachdem schon weiter oben erläutert worden ist, wann sich Barrieren auf die Fahrtzeit auswirken, wird hier beschrieben, wann Barrieren eine Straße sperren. Dies funktioniert analog zum Network Attribute Access und wird bei Barrieren über das Network Attribute Barrier (Restriction) definiert. Es bezieht sich auf die Feature Class barriers. Dieser Feature Class wird der Field Expression Evaluator zugewiesen. Mit Hilfe des VBScripts wird berechnet, ob die aktuelle Barriere passierbar ( traversable ) oder unpassierbar ( restricted ) ist. Dazu wird der Wert des Fields access aus der Feature Class barriers mit Hilfe des Parameters access_barrier_restrictions- _interpretation (siehe Kapitel 4.1.1) ausgewertet. Das VBScript wird automatisch auf Basis dieses Parameters generiert. Je nachdem, welcher else-wert vom Anwender definiert worden ist, muss das VBScript anders aufgebaut sein. Ist der else-wert no (unpassierbar, Default-Wert), ist die Variable restricted zu Anfang auf True (unpassierbar) gesetzt und kann später mit False überschrieben werden, wenn einer der yes-fälle auftritt. Ist der else-wert vom Benutzer auf yes gesetzt, verhält es sich genau andersherum. Das Listing 41 ist ein Beispiel für diesen Field Expression Evaluator und basiert auf dem Listing 14 aus Kapitel restricted = True Select Case [access] Case "yes", "designated", "official", "permissive" restricted = False End Select Listing 41: Network Attribute "Barrier" (barriers, Beispiel) Zuletzt gibt es noch das Network Attribute TurnRestriction (Restriction), das Straßen an Kreuzungen oder Einmündungen bei Abbiegeverboten sperrt. Dies ist das einzige Network Attribute aus diesem Konzept, dem der Constant Evaluator zugewiesen ist. Dieser bezieht sich auf die Feature Class turns. Dessen Wert ist immer auf Restricted gesetzt. Somit werden alle in der Feature Class turns aufgeführten Features als Abbiegeverbote interpretiert. In Tabelle 26 sind alle Network Attributes mit ihren Evaluators noch einmal zusammengefasst. 72

81 Attribute Source Direction Type Value Listing Access roads From-To Field <expression> Listing 32 To-From AvSpeed roads From-To Field avspeed To-From Barrier barriers Field <expression> Listing 41 Closed roads From-To Field <expression> Listing 33 To-From DriveTime roads From-To VBScript <expression> Listing 36 To-From barriers VBScript <expression> Listing 38 HeightRestriction roads From-To Function MaxHeight < To-From Height Length roads From-To Field SHAPE To-From MaxHeight roads From-To Field maxheight To-From MaxSpeed roads From-To Field maxspeed To-From MaxWeight roads From-To Field maxweight To-From Oneway roads From-To Field <expression> Listing 39 To-From Field <expression> Listing 40 SlowDown roads From-To Field <expression> Listing 35 To-From barriers Field <expression> Listing 37 Speed roads From-To VBScript <expression> Listing 34 To-From TurnRestriction turns Constant Restricted WeightRestriction roads From-To Function MaxWeight < To-From Weight Tabelle 26: Network Attributes Evaluators (Source Values) Wie schon in Kapitel erwähnt, ist es in ArcGIS möglich, dass Network Locations auf nicht passierbare Netzelemente fallen können. Dies ist beim Testen der Daten aufgefallen, als in einem Verkehrsnetz für Straßen der Standort auf einen Fahrradweg gemappt wurde, da dieser das nächstgelegene Netzelement war. Da aber ein Auto auf Fahrradwegen nicht fahren darf, konnte keine Route berechnet werden. Um zu Umgehen, dass Standorte auf nicht passierbare Network Locations fal- 73

82 len, mussten die Einstellungen der Solver Layer angepasst werden. Dies ist auch der Grund, weshalb ein Map Document erzeugt wird. Die Einstellungen erfolgen in den Layer Properties unter dem Reiter Network Locations. Dort gibt es unter der Rubrik Finding Network Locations eine Liste von Network Sources, zu deren Elementen die Locations gesnappt werden. Über das Kontextmenü der Network Source roads kommt man zum Query Builder. Mit Hilfe dieses Query Builders kann über die WHERE-Clause einer SQL- Anweisung festgelegt werden, zu welchen Netzelementen Network Locations gesnappt werden können: SELECT * FROM roads WHERE Es müssen all die Netzelemente ausgeschlossen werden, die nicht passierbar sind. Dies sind zum einen Straßen, die sich in Planung oder im Bau befinden (siehe Network Attribute Closed ) und Straßen, bei denen der Wert des Fields access als no interpretiert wird (siehe Network Attribute Access ). Diese Interpretation findet über den Parameter access_highway_restrictions- _interpretation statt. Wie schon beim Network Attribute Access erläutert, kann der else- Wert vom Anwender auf yes oder no gesetzt werden. Dies muss bei der Definition der WHERE- Clause berücksichtigt werden. Listing 42 zeigt die WHERE-Clause, die auf Listing 17 basiert. ("access" <> 'no' AND "access" <> 'destination' AND "access" <> 'delivery' AND "access" <> 'agricultural' AND "access" <> 'forestry' AND "access" <> 'private' ) AND "construct" <> 'yes' AND "proposed" <> 'yes' Listing 42: WHERE-Clause der Network Source roads beim Laden der Network Locations Neben den Network Attributes können im Network Datasets auch noch Directions (siehe Kapitel 2.3.4) definiert werden. Diese werden verwendet, um dem Anwender bei einer einem Routing eine Wegbeschreibung mit Streckenlänge und Fahrtdauer ausgeben zu können. Als Längenattribut ( Length Attribute ) wird das Network Attribute Length, als Zeitattribut ( Time Attribute ) das Network Attribute DriveTime festgelegt. Die Längeneinheit ( Display Length Units ) für die Anzeige in der Wegbeschriebung wird auf Kilometer gesetzt. Um in der Wegbeschreibung Straßennamen angeben zu können, wird auf das Field name aus der Feature Class roads verwiesen Nicht umgesetzte Map Features Nicht umgesetzte Map Features sind u.a.: Linien- oder flächenhafte Barrieren (Diese sind erst ab ArcGIS 10 möglich, siehe Kapitel Außerdem sind linienhafte Barrieren in OSM oft am Fahrbahnrand. Dadurch haben sie keinen Einfluss auf den Verkehr.) zeitliche Beschränkungen (noch zu selten in OSM verwendet) Wasserstraßen und -flächen (für Netzwerkanalysen auf dem Straßennetz nicht wichtig) Eisenbahnnetz (für Netzwerkanalysen auf dem Straßennetz nicht wichtig) Routen (Routen, wie z.b. Fahrradrouten sind eher für den Freizeitsport gedacht) richtungsabhängige Höchstgeschwindigkeiten (noch zu selten in OSM verwendet) Adressen (nicht flächendeckend in OSM verwendet) 74

83 4.2. Evaluierung von OSM-Daten in ESRI-Datenformaten für Netzwerkanalysen in ArcGIS In diesem Kapitel wird analysiert, ob die in Kapitel 3.4 beschriebenen OSM-Daten in ESRI- Datenformaten für Netzwerkanalysen in ArcGIS geeignet sind Geofabrik Zur Generierung eines Straßennetzwerkes kann das Shapefile roads verwendet werden. Dieses Shapefile enthält folgende netzwerkrelevante Map Features: Straßentyp (highway) Straßenname (name) für Wegbeschreibungen Referenz (Straßennummer) der Straße (ref) für Webbeschreibungen Einbahnstraßen (oneway) erlaubte Höchstgeschwindigkeit (maxspeed) Die Map Features Straßentyp, Einbahnstraßen und Höchstgeschwindigkeit werden nur unvollständig ermittelt. Im Shapefile roads nicht enthalten sind folgende Map Features, die für Netzwerkanalysen sinnvoll sind: Zugangsbeschränkungen für bestimmte Straßentypen (abhängig von der Beförderungsart) (access, ) maximal erlaubte Fahrzeughöhe (maxheight) maximal erlaubtes Fahrzeuggewicht (maxweight) in Planung oder im Bau befindliche Straßen (construction, proposed) Verkehrsberuhigung (traffic_calming) Des Weiteren gibt es weder Abbiegevorschriften noch Barrieren in den Daten der Geofabrik. Theoretisch wäre es möglich, aus den Daten der Geofabrik ein Straßennetzwerk zu erstellen. Doch dieses hätte viele Mängel. Ohne eine richtige Definition von Einbahnstraßen, verschiedener Beschränkungen, Abbiegevorschriften und Barrieren ist es wertlos CloudMade Zur Erzeugung eines Straßennetzwerkes kann das Shapefile highway verwendet werden. Dieses Shapefile enthält folgende netzwerkrelevante Map Features: Straßentyp (highway) Straßenname (name) für Wegbeschreibungen Einbahnstraßen (oneway) Sowohl der Straßentyp als auch Einbahnstraßen werden nur unvollständig bestimmt. Im Shapefile highway nicht enthalten sind folgende Map Features, die für Netzwerkanalysen sinnvoll sind: 75

84 Referenz der Straße (ref) für Webbeschreibungen Zugangsbeschränkungen für bestimmte Straßentypen (abhängig von der Beförderungsart) (access, ) maximal erlaubte Fahrzeughöhe (maxheight) maximal erlaubtes Fahrzeuggewicht (maxweight) erlaubte Höchstgeschwindigkeit (maxspeed) in Planung oder im Bau befindliche Straßen (construction, proposed) Verkehrsberuhigung (traffic_calming) Außerdem enthalten die anderen Shapefiles weder Abbiegevorschriften noch Barrieren. Im Gegensatz zu den Shapefiles von der Geofabrik (siehe Kapitel 4.2.1) enthalten diese noch weniger netzwerkrelevante Map Features. Man könnte zwar ein Netz aus dem Shapefile highway erzeugen. Da aber bis auf Einbahnstraßen keine weiteren Beschränkungen, Abbiegevorschriften und Barrieren vorhanden sind, ist auch dieses Netz ungeeignet für Netzwerkanalysen, die den Verkehr betreffen Tools und Skripte zur OSM-Konvertierung Die mit dem Python-Skript OpenStreetMap Loader erzeugte GDB kann uneingeschränkt als Basis für ein Netzwerk dienen. Dies liegt daran, dass bei der Erstellung der Feature Classes keine Interpretation oder Auswahl der OSM-Tags vorgenommen wird. Sie werden direkt übernommen. Theoretisch könnte man mit den Daten, die mit dem Programm Convert OpenStreetMap Data erstellt wurden, ein Netzwerk erzeugen. Doch da dieses Tool nur Straßen mit Straßennamen erzeugt, ist es nicht für Netzwerkanalysen geeignet. Auch die Shapefiles, die mit der ArcView Extension OSM2Shape erzeugt werden, sind nicht geeignet als Grundlage für Netzwerkanalysen. Denn diese enthalten keinerlei Informationen zu OSM-Tags. So können nicht einmal Straßen von anderen Ways unterschieden werden. Wie durch die manuelle Datenaufbereitung (siehe Kapitel 4.1) bewiesen wurde, kann man mit dem RubyGem Osmexport Shapefiles erstellen. Diese Shapefiles kann man anschließend mit Hilfe der Tools im ArcCatalog zur Erzeugung eines Netzwerkes verwenden. Dieses Netzwerk ist mit dem automatisch erzeugten Netzwerk vergleichbar. Wie auch mit dem RubyGem Osmexport kann mit der FME eine benutzerdefinierte Konvertierung von OSM-Daten in ESRI-Datenformate vorgenommen werden. Aus diesen erzeugten Daten kann danach mit ArcGIS ein geeignetes Netzwerk erzeugt werden Zusammenfassung der Evaluierung Zusammenfassend kann gesagt werden, dass man theoretisch mit allen OSM-Daten in ESRI- Datenformaten Verkehrsnetzwerke erzeugen kann, da sie Straßen enthalten. Doch dies ist nur ein hinreichendes Kriterium für die Erzeugung eines realistischen Verkehrsnetzwerkes. Ein realistisches Netzwerk kann nur dann erstellt werden, wenn es wichtige Beschränkungen wie Fahrverbote oder Einbahnstraßen enthält und diese auch richtig interpretiert werden. Andernfalls ist das erzeugte routing- und netzwerkanalysefähige Netzwerk wertlos, da es in keinster Weise der Realität nahekommt. 76

85 Die einzigen Tools und Skripte, mit denen man Daten für die spätere Integration in ein realistisches Netzwerk erzeugen kann, sind OpenStreetMap Loader, Osmexport und die FME. Bei dem Skript OpenStreetMap Loader werden gründsätzlich alle OSM-Tags in die Features Classes übernommen. Bei Osmexport und bei der FME ist der Aufbau der konvertierten Daten (z.b. Shapefiles) nicht von vorneherein festgelegt ist. Stattdessen kann der Nutzer selbst bestimmen, wie die Dateien aufgebaut und befüllt werden. Alle anderen vorgestellten OSM-Daten in ESRI-Datenformaten kommen nicht in Frage. Deren Aufbau und Befüllung eignet sich eher für eine kartographische Aufbereitung und für einfache räumliche Analysen, nicht aber für die Erzeugung eines realistischen Verkehrsnetzwerkes Programmiertechnische Umsetzung Um die prototypische Anwendung umzusetzen, wurde die Programmiersprache Java (Version 6) gewählt. Als Gründe können die bereits vorhandenen Erfahrungen der Autorin in dieser Programmiersprache sowie deren Offenheit, Schnittstellen und Eignung im Bezug auf ArcGIS genannt werden. Zusätzlich zur Java 6-API (Application Programming Interface) werden noch zwei weitere Java- Bibliotheken (Libraries) verwendet. Um die OSM-Daten und die Parameter-Datei, beides XML-Dateien, einlesen zu können, wird die Bibliothek JAXB (Java Architecture for XML Binding) in der Version 2.0 benutzt. Mit Hilfe dieser Bibliothek können aus einem XML Schema Java-Klassen erstellt werden. Bei der Durchführung der Anwendung werden die XML-Dateien in Java-Objekte dieser Klassen umgewandelt. Diesen Prozess nennt man Unmarshalling [51]. Zur Erstellung der Geodatabase (mit den Feature Classes und dem Network Dataset) und des Map Documents wird die Java-Bibliothek ArcObjects in der Version verwendet. Diese Bibliothek bietet alle Möglichkeiten, mit denen man auch im ArcCatalog und in ArcMap das Network Dataset erstellen und anpassen kann. Die Anwendung ist mit einer grafischen Oberfläche realisiert. Diese enthält im oberen Bereich eine Maske, über die man die Einstellungen vornehmen kann. Dies sind: Pfad zur OSM-Datei Pfad zur Parameter-Datei Pfad zum Verzeichnis, in das die GDB und das Map Document geschrieben werden sollen Name der Region Pfad zur log-datei (optional) Unterhalb der Maske gibt es den Start-Button, um den Prozess zu starten, und eine Fortschrittsanzeige, um zu sehen, wie weit die Konvertierung schon fortgeschritten ist. Darunter befindet sich ein Fenster, in dem die Nachrichten, die geloggt werden, aufgelistet werden. Es wird zwischen folgenden Kategorien unterschieden: INFO Mitteilung des aktuellen Standes der Konvertierung WARN Warnung, falls das Programm eine Annahme macht, die der Nutzer wissen sollte. Evt. kann der Nutzer daraufhin seine Einstellungsparameter ändern und den Prozess neu starten. ERROR Es ist ein Fehler aufgetreten, wodurch die einwandfreie Konvertierung der Daten nicht möglich ist. Das Programm wird abgebrochen. 77

86 In Abb. 21 ist die grafische Oberfläche dargestellt. Abb. 21: Grafische Oberfläche der Anwendung Der Prozess zur Konvertierung der OSM-Daten in eine Geodatabase und die Erstellung des Map Documents läuft nach folgenden Schritten ab: 1. Parameter-Datei einlesen 2. OSM-Daten einlesen 3. GDB erstellen 4. geografischen Raumbezug (Spatial Reference) festlegen 5. Feature Dataset erstellen 6. Feature Classes roads, barriers und pois initialisieren 7. Network Dataset mit Network Junctions initialisieren (u.a. Referenzierung der Feature Classes roads, barriers und pois sowie Festlegung der Network Attributes) 8. Turn Feature Class turns initialisieren und zum Network Dataset hinzufügen 78

87 9. Network Dataset aktualisieren (Network Attribute TurnRestriction hinzufügen) 10. Abbiegeverbote generieren (mit Umwandlung der Abbiegegebote in verbote und Splitting der Straßen) 11. Feature Class roads mit Straßen (highway) befüllen 12. Turn Feature Class turns mit Abbiegeverboten befüllen 13. Feature Class pois mit OSM-Nodes befüllen 14. Feature Class barriers mit Barrieren befallen 15. Map Document (*.mxd) erzeugen 16. Feature Classes zum Map Document hinzufügen 17. Network Analyst Solver Layer zum Map Document hinzufügen und anpassen Auf den ersten Blick sieht die Reihenfolge der Schritte etwas ungeordnet aus. Doch einige Schritte setzen andere voraus. Im Folgenden werden die einzelnen Schritte im Detail erklärt und an wichtigen Stellen Code-Beispiele gezeigt. Zu jedem der Schritte gibt es ein Flussdiagramm. Diese Diagramme basieren auf der Legende aus Abb. 22. Abb. 22: Legende der Flussdiagramme Zu Beginn der Datenaufbereitung werden in Schritt 1 und 2 zunächst die Parameter- als auch die OSM-Datei eingelesen und in Java-Objekte umgewandelt (Unmarshalling). Das Einlesen der beiden Dateien ist in Abb. 23 und Abb. 24 dargestellt. Abb. 23: Schritt 1: Einlesen der Parameter-Datei Abb. 24: Schritt 2: Einlesen der OSM-Datei Während des Unmarshallings werden die beiden XML-Dateien gegen ihr jeweiliges XML Schema validiert. Bei den Parametern erfolgt zusätzlich noch eine Überprüfung, ob die Parameter vom Anwender inhaltlich richtig gesetzt worden sind. Listing 43 zeigt in stark vereinfachter Form, wie mit Hilfe von JAXB die Parameter-Datei eingelesen und gleichzeitig gegen das XML Schema validiert (unmarshal()) sowie anschließend mit der für dieses Tool geschriebenen Klasse ParametersValidation inhaltlich überprüft wird. 79

88 String packagepath = "de.hska.ziev0011.bac.parameters"; String schemapath = "/resources/parameters.xsd"; JAXBContext jc = JAXBContext.newInstance(packagePath); Unmarshaller unmarshaller = jc.createunmarshaller(); SchemaFactory schemafactory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI); Class<? extends ParametersReader> clazz = getclass(); URL schemaurl = clazz.getresource(schemapath); Schema schema = schemafactory.newschema(schemaurl); unmarshaller.setschema(schema); Parameters parameters = null; try { parameters = (Parameters)unmarshaller.unmarshal(file); } catch(jaxbexception e) { throw new ReaderException("The reading process of the file '" + file.getabsolutepath() + "' failed:\n\t" + "The file could not be unmarshalled. " + "Maybe the file isn't valid.\n\t" + e); } ParametersValidation parametersvalidation = new ParametersValidation(LOG, parameters); try { parametersvalidation.isvalid(); } catch(parameterexception e) { throw new ReaderException("The reading process of the file '" + file.getabsolutepath() + "' failed:\n\t" + "\n\t" + e.getmessage()); } Listing 43: Einlesen und Validierung der Parameter-Datei (stark vereinfacht) Durch den Unmarshalling-Prozess ergeben sich die beiden Java-Klassen Parameters und Osm, die die Daten enthalten. Diese Klassen enthalten weitere Klassen, die die Parameter bzw. Nodes, Ways und Relations repräsentieren. Im Anhang in Abb. 56 und Abb. 57 ist deren Aufbau in Form von UML- Diagrammen dargestellt. UML (Unified Modeling Language) ist eine Sprache, mit der Software modelliert werden kann [167]. Anschließend wird im Schritt 3 (Abb. 25) die GDB erstellt, die zu diesem Zeitpunkt noch kein Feature Dataset enthält. Abb. 25: Schritt 3: Erstellung der GDB In Schritt 4 (Abb. 26) wird der geografische Raumbezug (Spatial Reference) festgelegt. Als geografisches Koordinatensystem wird das geodätische Referenzsystem WGS 1984 (World Geodetic System 1984) verwendet. Zur Ermittlung der XY Domain, d.h. die Begrenzung des Gebietes nach Norden, Süden, Westen und Osten, werden die geografischen Koordinaten aller Nodes ausgewertet. Die Ver- 80

89 wendung der Koordinaten aus dem bounds-xml-tag bzw. aus dem bound-xml-tag ist nicht möglich, da diese nur angeben, in welchem Gebiet die Daten vollständig sind. Der geografische Raumbezug wird anschließend von verschiedenen Objekten verwendet, d.h. referenziert. Abb. 26: Schritt 4: Festlegung des geografischen Raumbezugs Nachdem in Schritt 3 die GDB erstellt und in Schritt 4 der geografische Raumbezug festgelegt wurde, wird nun in Schritt 5 der GDB ein Feature Dataset hinzugefügt, das den geografischen Raumbezug (Spatial Reference) referenziert. Abb. 27: Schritt 5: Erstellung des Feature Datasets Anschließend werden in Schritt 6 (Abb. 28) im Feature Datset die Feature Classes roads, pois und barriers initialisiert. Initialisieren bedeutet hier, dass die Feature Classes zwar erstellt, aber noch nicht befüllt werden. Zur Initialisierung gehört die Festlegung des Geometrietyps (Geometry), der Fields sowie des geografischen Raumbezugs. Abb. 28: Schritt 6: Initialisierung der Feature Classes roads, pois und barriers Im Schritt 7 erfolgt die Initialisierung des Network Datasets mit den Network Junctions. Dem Network Dataset werden zunächst die Feature Classes roads und barriers als Sources hinzugefügt. Es ist nicht notwendig, die Feature Class pois als weitere Source zu referenzieren, da sie im Netzwerk keine Rolle spielt. Denn sie enthält nur Points of Interest (POIs). Mit der Festlegung der Sources wird die Connectivity definiert. Anschließend werden mit Hilfe der Parameter alle Network Attributes bis auf das Network Attribute TurnRestriction erstellt. Das Network Attribute TurnRestriction kann erst erstellt werden, nachdem die Turn Feature Class turns initialisiert worden ist. 81

90 Abb. 29: Schritt 7: Initialisierung des Network Datasets mit den Network Junctions Die Initialisierung der Turn Feature Class turns erfolgt in Schritt 8 mit Hilfe des Geoprocessing Tools [19] Create Turn Feature Class. Als Geoprocessing Tool werden die Tools aus der ArcToolbox bezeichnet. Diese können auch aus ArcObjects aufgerufen werden. In Listing 44 ist die Verwendung dieses Tools dargestellt. IGeoProcessor gp = new GeoProcessor(); gp.setenvironmentvalue("workspace", featuredatasetpath); IVariantArray param = new VarArray(); param.add(featuredatasetpath); param.add("turns"); param.add(2); param.add(name + "_ND"); gp.setoverwriteoutput(true); gp.execute("createturnfeatureclass_na", param, null); Listing 44: Initialisierung der Turn Feature Class turns Wie man Listing 44 entnehmen kann, wird zunächst der Workspace, d.h. das Feature Dataset, definiert, in das anschließend die neue Turn Feature Class geschrieben werden soll. Danach werden Parameter festgelegt (param.add()), die die Struktur und die Eigenschaften der Turn Feature Class beschreiben. Diese werden in genau der gleichen Reihenfolge wie im Tool Create Turn Feature Class aus der ArcToolbox übergeben. Dies sind unter anderem der Name turns, die Anzahl der Edges (2) sowie der Name des Network Datasets (Name der Region + _ND ). Zum Schluss wird über den Befehl execute() das Tool ausgeführt. Da dieses Tool zur Erstellung der Turn Feature Class das Network Dataset benötigt, kann dieser Schritt erst nach Schritt 7 erfolgen. Nach der Durchführung des Geoprocessing Tools werden der erzeugten Turn Feature Class die Fields hinzugefügt. In Abb. 30 ist die Initialisierung der Turn Feature Class turns grafisch dargestellt. 82

91 Abb. 30: Schritt 8: Initialisierung der Turn Feature Class turns Nachdem in Schritt 8 die Turn Feature Class erstellt und damit auch dem Feature Dataset hinzugefügt worden ist, kann in Schritt 9 das letzte Network Attribute TurnRestriction definiert werden (Abb. 31). Abb. 31: Schritt 9: Network Attribute" TurnRestriction" zum Network Dataset hinzufügen Nach der Initialisierung aller Feature Classes, kann jetzt mit der Konvertierung der Daten und der Befüllung der Feature Classes begonnen werden. Zunächst werden in Schritt 10 die Abbiegeverbote berechnet. Dies erfolgt durch das Auslesen der Relations und der Umwandlung der Abbiegegebote in -verbote. Muss bei dieser Umwandlung ein Splitting von Straßen durchgeführt werden, so werden die Ways in den OSM-Daten aktualisiert. Dieser Prozess ist in Abb. 32 dargestellt. Wie man in dieser Abbildung sehen kann, sind die Abbiegeverbote in diesem Schritt zunächst nur in Form von Java-Objekten vorhanden. Abb. 32: Schritt 10: Generierung der Abbiegeverbote (mit Splitting der Straßen) 83

92 Erst nachdem möglicherweise in Schritt 10 einige Ways gesplittet worden sind, kann im nächsten Schritt (11) die Feature Class roads befüllt werden. Dazu wird pro Way (highway) eine Polyline mit Hilfe der Koordinaten der referenzierten Nodes erstellt. Dies ist in Listing 45 dargestellt. Polyline polyline = new Polyline(); polyline.setspatialreferencebyref(spatialreference); List<BigInteger> listofndids = osmway.getndids(); for(biginteger ndid : listofndids) { OSMNode osmnode = osmnodes.getosmnodebyid(ndid); if(osmnode == null) { throw new MissingNodesException("The referenced node '" + ndid.tostring() + "' of the way '" + osmway.getid().tostring() + "' does not exist."); } float latitude = osmnode.getlat(); float longitude = osmnode.getlon(); IPoint point1 = generatepoint(longitude, latitude, spatialreference); polyline.addpoint(point1, null, null); } Listing 45: Erstellung einer Polyline Wie man aus Listing 45 entnehmen kann, wird zuerst ein neues Object vom Datentyp Polyline angelegt und der geografische Raumbezug festgelegt. Anschließend werden alle vom aktuellen Way (OS- MWay) referenzierten Nodes in einer Schleife (for()) in Digitialisierungsrichtung durchgegangen und die geografische Breite (getlat()) sowie Länge (getlon()) ausgelesen. Diese Koordinaten werden zur Erzeugung der Punkte (IPoint) verwendet, die als Stützpunkte mit Hilfe der Methode add- Point() der Polyline hinzugefügt werden. Neben der grafischen Darstellung der Straßen und deren Position im Raum werden in Schritt 11 auch die Fields befüllt. Je nach Definition der Fields werden hierfür Parameter aus der Parameter-Datei verwendet. Nachdem der Wert eines Fields ermittelt wurde, wird er mit Hilfe der Methode insert- FeatureValue() aus Listing 46 dem aktuellen Feature hinzugefügt. protected void insertfeaturevalue(ifeatureclass featureclass, IFeature feature, String fieldname, Object value) throws IOException { if(value!= null) { IFields fields = featureclass.getfields(); int index = fields.findfield(fieldname); feature.setvalue(index, value); } } Listing 46: Befüllung eines Fields In Abb. 33 ist der Schritt 11 grafisch dargestellt. 84

93 Abb. 33: Schritt 11: Befüllung der Feature Class roads Anschließend folgt in Schritt 12 (Abb. 34) die Befüllung der Turn Feature Class turns. Dieser Schritt kann erst jetzt erfolgen, da zur Befüllung der Fields Edge1FCID, Edge2FCID, Edge1FID und Edge2FID die Feature Class ID der Feature Class roads und die Feature IDs der im vorherigen Schritt geschriebenen Ways bekannt sein müssen. Um die Abbiegeverbote grafisch darzustellen, werden wie auch bei der Erstellung der Straßen die Ways und Nodes ausgelesen. Abb. 34: Schritt 12: Befüllung der Turn Feature Class turns In Schritt 13 wird die Feature Class pois befüllt (Abb. 35). 85

94 Abb. 35: Schritt 13: Befüllung der Feature Class pois In Schritt 14 folgt anschließend die Befüllung der Feature Class barriers. Wie auch bei der Befüllung der Feature Class roads werden hier Parameter aus der Parameter-Datei verwendet. Abb. 36 zeigt diesen Schritt. Abb. 36: Schritt 14: Befüllung der Feature Class barriers Nachdem nun alle Feature Classes in der GDB befüllt worden sind, wird in Schritt 15 das Map Document (*.mxd) generiert (Abb. 37). Abb. 37: Schritt 15: Erzeugung des Map Documents In Schritt 38 werden diesem Map Document die Feature Classes roads, pois, barriers, turns, das Network Dataset und die Network Junctions als Layer hinzugefügt (Abb. 38). 86

95 Abb. 38: Schritt 16: Hinzufügen der Feature Classes zum Map Document Zum Schluss werden im letzten Schritt (17) die in ArcGIS vorhanden Network Analyst Solvers erstellt und mit Hilfe der Parameter aus der Parameter-Datei angepasst (Abb. 39). Abb. 39: Schritt 17: Hinzufügen der Network Analyst Solver Layer zum Map Document Mit der Durchführung des Schritts 17 ist der Prozess der Datenaufbereitung beendet. Das generierte Network Dataset kann nun mit Hilfe der im Map Document erzeugten Network Analyst Solvers verwendet werden. Während des Schreibens des Programms wurden immer wieder Tests durchgeführt, um die korrekte Programmierung zu überprüfen Vergleich anhand von beispielhaften Netzwerkanalysen Um die Daten der geschriebenen Anwendung zu testen, wurden beispielhafte Netzwerkanalysen mit verschiedenen Netzwerkanalyse-Daten durchgeführt und verglichen. Die Tests wurden für das Stadtgebiet Münster durchgeführt. 87

96 Auto-Routing Zum Vergleich des Routings auf dem erzeugten Netz werden folgende Netzwerkanalyse-Daten herangezogen: ArcGIS-unabhängige OSM-Routendienste o OpenRouteService [58] o CloudMade [36] o YourNavigation [176] Netzwerkanalyse-Daten für ArcGIS o ESRI StreetMap Premium Teleatlas Netzwerkanalyse-Service in ArcGIS o European Route Finder Tele Atlas [28] ArcGIS- und OSM-unabhängiger Routingdienst o NAVTEQ Map24 Für das Fahrzeug Auto sollte von den verschiedenen Routingdiensten die schnellste Route ermittelt werden. Als Testroute wurde eine Route vom Bahnhof Münster zu einem Park östlich der Weseler Straße und nördlich der Straße Am Kanonengraben gewählt. Es wurde sich deshalb für diesen Startpunkt entschieden, weil es am Bahnhof Einbahnstraßen gibt. Der Zielpunkt liegt in einem Park, weil getestet werden soll, ob die Routingdienste berücksichtigen, dass Autos nicht auf Parkwegen fahren dürfen. Die von den verschiedenen Routendiensten ermittelten Routen können in drei Katogorien aufgeteilt werden. A Start vom Bahnhof aus nach Süden, über Hafenstraße zum Ludgeriplatz, Ziel in Weseler Straße oder in Aegidiistraße B Start vom Bahnhof aus nach Norden, über Urbanstraße zum Ludgeriplatz, dort im Kreisverkehr nach Norden in Ludgeristraße abbiegen, Ziel über Promende nördlich des Parkes erreicht C Start vom Bahnhof aus nach Norden, über Urbanstraße zum Ludgeriplatz, Ziel in Weseler Straße oder in Aegidiistraße In Tabelle 27 sind die Ergebnisse des Vergleichs dargestellt. Die Screenshots der Routen sind in Abb. 40 bis Abb. 46 dargestellt. Die mit der programmierten Anwendung erzeugten Daten enthalten nur das rohe Netzwerk. Um den geographischen Raumbezug zu erhalten, wurde deshalb der OSM-WMS- Dienst (Web Map Service) [170] der WhereGroup [169] in den Hintergrund gelegt. Routingdienst Länge in km Zeit in min Kategorie Abbildung A B C OpenRouteService?? C Abb. 40 CloudMade 1,5 2 A Abb. 41 YourNavigation?? B Abb. 42 OSM2NetworkDataset 1,7 2 A Abb. 43 ESRI StreetMap Premium Teleatlas 1,7 2 C Abb

97 Routingdienst Länge in km Zeit in min Kategorie Abbildung A B C European Route Finder Tele Atlas 1,7 2 C Abb. 45 NAVTEQ Map24 1,61 2 A Abb. 46 Tabelle 27: Vergleich von Routingdiensten Abb. 40: Routing in Münster mit OpenRouteService (Auto, schnellste Verbindung) 1 Abb. 41: Routing in Münster mit CoudMade (Auto, schnellste Verbindung)

98 Abb. 42: Routing in Münster mit YourNavigation (Auto, schnellste Verbindung) 1 Abb. 43: Routing in Münster mit OSM2NetworkDataset (Auto, schnellste Verbindung) 2 Abb. 44: Routing in Münster mit ESRI StreetMap Premium Teleatlas (Auto, schnellste Verbindung)

99 Abb. 45: Routing in Münster mit European Route Finder TeleAtlas (Auto, schnellste Verbindung) 1 Abb. 46: Routing in Münster mit NAVTEQ Map24 (Auto, schnellste Verbindung) 2 Vergleicht man die Ergebnisse des Routings miteinander, stellt man fest, dass sie relativ ähnlich sind. Zeit und Länge der Route sind bei allen Routingdiensten in etwa vergleichbar. Doch bei der kurzen Strecke kommen die Unterschiede nicht zu sehr zum Tragen. Um eine gute Aussage zu machen, sollte zum Testen eine längere Routingstrecke gewählt werden. Bei den betrachteten Routingdiensten gibt es zwei bevorzugte Routen. Die nördliche Route (C) wurde von OpenRouteService, ESRI StreetMap Premium Teleatlas und European Route Finder Tele Atlas, die südliche Route (A) von CloudMade, OSM2NetworkDataset und NAVTEQ Map24 gewählt. Alle Dienste beachteten Einbahnstraßen (siehe Kreisverkehr). Nur YourNavigation ignorierte, dass das Ziel in einem Park liegt, in dem Autos nicht erlaubt sind

100 Fahrrad-Routing Da die Anwendung so konzipiert ist, dass für verschiedene Transportmittel Verkehrsnetzwerke erstellt werden können, wurde zum Test und zur Demonstration ein Fahrradrouting durchgeführt. Dazu eignet sich die Fahrradstadt Münster, da dort die Erfassung von Fahrradattributen schon weit vorgeschritten ist. Im Gegensatz zum Autorouting (siehe Kapitel 4.4.1) wurde hier nicht nach der schnellsten Route sondern nach der kürzesten geschaut. Dies macht aber meistens keinen großen Unterschied, da die Geschwindigkeit von Fahrradfahrern i.d.r. einigermaßen konstant bleibt. Als Startpunkt für die Route wurde der Wienburgpark im Norden Münsters gewählt. Dort gibt es einige Wege, die von Fahrradfahrern befahren werden können. Als Zielpunkt wurde sich für den Südpark entschieden, in dem es nur Fußgängerwege gibt. So kann nicht nur getestet werden, wie sich die Routen der unterschiedlichen Routingdiensten voneinander unterscheiden, sondern auch, ob die Routingdienste Beförderungsartbeschränkungen beachten. Folgende Routingdienste wurden zum Vergleich gewählt, da sie Fahrradrouting unterstützen: ArcGIS-unabhängige OSM-Routendienste o OpenRouteService [58] o YourNavigation [176] Netzwerkanalyse-Daten für ArcGIS o ESRI StreetMap Premium Teleatlas Das Ergebnis des Fahrradroutings ist in den Abbildungen Abb. 47 und Abb. 48 dargestellt. Abb. 47: Routing in Münster mit OpenRouteService und YourNavigation (Fahrrad, kürzeste Verbindung)

101 Abb. 48: Routing in Münster mit ESRI StreetMap Premium Teleatlas und OSM2NetworkDataset (Fahrrad, kürzeste Verbindung) 12 Bei allen Diensten kamen unterschiedliche Routen heraus. Auf dem Netz von OSM2NetworkDataset wurde am längsten auf der Promenade, einer Fahrradstraße, geroutet. Auch der OpenRouteService nutzte die Promenade. YourNavigation dagegen wählte eine Strecke durch die Innenstadt. Am auffälligsten ist jedoch, dass YourNavigation die Beförderungsartbeschränkung im Südpark missachtet. Dort wird trotzdem auf Fußgängerwegen geroutet. OpenRouteService lässt die Fahrradroute an den Punkten enden, bis zu denen ein Fahrradfahrer fahren darf. Anschließend werden Luftlinien zum Start- bzw. Zielpunkt gezeigt. In ESRI StreetMap Premium Teleatlas fehlen viele Fahrradwege, so dass nur bis zu den Parkgrenzen geroutet wird. Auf dem Netz von ESRI StreetMap Premium Teleatlas wurde eine Streckenlänge von 5 km und eine Fahrtzeit von 7 Minuten berechnet. Damit ergibt sich eine durchschnittliche Geschwindigkeit von 42 km/h. Dies ist jedoch sehr unrealistisch für Fahrradfahrer. Auf dem Fahrradnetz der programmierten Anwendung betrug die Streckenlänge 4,4 km und die Fahrtzeit 17 Minuten. Diese Fahrtzeit ergibt sich durch die in der Parameter-Datei festgelegten Durchschnittsgeschwindigkeiten, die meist zwischen 15 und 16 km/h liegen. Nachdem die verschiedenen Routingdiensten betrachtet worden sind, kann man sagen, dass sich im Gegensatz zum Autorouting (siehe Kapitel 4.4.1) die Routen stärker voneinander unterscheiden. Dies liegt sicherlich daran, dass Fahrradattribute nicht immer berücksichtigt werden. 1 ESRI StreetMap Premium Teleatlas: OSM2NetworkDataset:

102 Erreichbarkeitsanalyse Als weitere Netzwerkanalyse wurde eine Erreichbarkeitsanalyse mit dem Network Analyst Solver ServiceArea für die Daten der programmierten Anwendung und für ESRI StreetMap Premium Teleatlas durchgeführt. Es wurde ermittelt, welches Gebiet mit einem Auto innerhalb von drei Minteun vom Bahnhof in Münster erreicht werden kann. Die Ergebnisse dieser Erreichbarkeitsanalyse sind in Abb. 49 und Abb. 50 dargestellt. Abb. 49: Erreichbarkeitsanalyse um den Bahnhof Münster mit OSM2NetworkDataset (Auto, drei Minuten) 1 Abb. 50: Erreichbarkeitsanalyse um den Bahnhof Münster mit ESRI StreetMap Premium Teleatlas (Auto, drei Minuten)

103 Vergleicht man Abb. 49 und Abb. 50, stellt man fest, dass die Gebiete sich unterscheiden. Dies liegt u.a. daran, dass unterschiedliche Geschwindigkeiten für die Straßen in den beiden Netzwerkanalyse- Daten angenommen wurden Zusammenfassung Betrachtet man das Ergbnis der durchgeführten Vergleiche, kommt man zu dem Schluss, dass sich die mit der programmierten Anwendung erzeugten Netzwerkanalyse-Daten durchaus für Netzwerkanalysen eignen. Die Vergleiche sind jedoch nur Stichproben und sagen nichts darüber aus, ob Netzwerkanalysen weltweit und auch für andere Transportmittel genauso gute Ergebnisse liefern. Dazu müsste ein umfassender Vergleich durchgeführt werden, der den Rahmen dieser Arbeit sprengen würde. Es darf auch nicht vernachlässigt werden, dass das Routing-Ergebnis immer von den zugrundeliegenden Daten und deren Interpretation abhängt. Im Fall der programmierten Anwendung spielt hierbei die Parameter-Datei, die der Nutzer für ein Land und ein Transportmittel erstellt, ein große Rolle Anwendungsgebiete Die mit dem geschriebenen Tool erzeugten Netzwerkanalyse-Daten können von allen Network Analyst Solvers (siehe Kapitel 2.3) verwendet werden. So kann auf dem Netz geroutet und es können Erreichbarkeit- und Standortanalysen durchgeführt werden. Werden weitere Daten benötigt, wie beispielsweise zeitliche Beschränkungen, kann der Anwender die Daten nachträglich verändern, anpassen oder erweitern. Es können auch in ArcMap weitere Layer hinzugeladen werden, um z.b. eigene Orte oder Points of Interest, d.h. Network Locations, zu verwenden. Da OSM-Daten jedoch noch nicht so umfassend attributiert sind wie Netzwerkanalyse-Daten von kommerziellen Datenanbietern, sind die Anwendungsgebiete etwas eingeschränkt. Für einfache Anwendungen wie Auto-, Fahrrad- oder Fußgängerrouting sind die Daten sehr gut geeignet. Dies liegt daran, dass die Daten vorwiegend aus der Sicht von Auto-, Fahrradfahrern und Fußgängern erfasst werden. Ein einigermaßen zuverlässiges LKW-Routing ist dagegen noch nicht möglich, da viele LKWspezifischen Attribute wie Höchstgewichte oder Maximalhöhen noch nicht flächendeckend vorhanden sind. Da aber solche Attribute essentiell für ein verlässliches LKW-Routing sind, ist die Verwendung des OSM-Netzes für solche Anwendungen (noch) nicht empfehlenswert. Dies kann sich aber im Laufe der nächsten Jahre noch ändern. Ob die Nutzung der mit dieser Anwendung erzeugten Netzwerkanalyse-Daten zu empfehlen ist, hängt auch stark vom entsprechenden Land ab. Länder wie Deutschland und England sind schon sehr gut erfasst. Für manche anderen Länder enthalten die OSM-Daten aber oft nur Durchfahrtsstraßen durch Orte. Das Tool ist auch nicht für Grenzgebiete geeignet, da die Parameter-Datei (siehe Kapitel 4.1.1) nur für ein Land definiert ist. Möchte man trotzdem ein Verkehrsnetz einer Grenzregion erstellen, kommt man nicht umhin, manuell die Daten nach der Datenaufbereitung anzupassen. Zusammenfassend kann man sagen, dass sich die mit dem Tool erzeugten Netzwerkanalyse-Daten für viele Anwendungszwecke eignen. Der Nutzer sollte jedoch immer zuerst prüfen, ob die OSM- Daten für seinen Anwendungsbereich, sein Vorhaben sinnvoll sind. 95

104 5. Bewertung und Ausblick In dieser Bachelor-Arbeit wurde untersucht, wie OSM-Daten für Netzwerkanalysen im Network Analyst von ArcGIS verwendet werden können. Die erstellte prototypische Anwendung beweist, dass die Daten automatisiert aufbereitet werden können. Durch die Verwendung der Parameter-Datei ist es möglich fahrzeug- und länderunabhängige Netzwerke zu erstellen. Die Anwendung berücksichtigt die am häufigsten vorkommenden Eigenschaften der Straßendaten in OSM. Betrachtet man die schnelle Entwicklung des OSM-Projekts, so ist davon auszugehen, dass in den nächsten Jahren weitere Netzwerkanalyse-Eigenschaften hinzukommen und diese flächendeckender zur Verfügung stehen werden. Es bleibt in dieser Beziehung abzuwarten, welche Standards sich bei der Attributierung entwickeln werden, da hier keine zentrale Steuerung greift, sondern aus der Community heraus eine Weiterentwicklung stattfindet. Die entstandene Anwendung sollte deshalb in regelmäßigen Abständen durch die Implementierung neuer Eigenschaften verfeinert werden. Dies könnten u.a. die in Kapitel aufgelisteten Map Features sein. Eine Idee wäre, zeitliche Beschränkungen oder Adressen hinzuzunehmen. Eine Fahrtzeitverzögerung beim Passieren von Kreuzungen, bestimmten Verkehrsschildern oder Ampeln wäre auch denkbar. Mit der neuen ArcGIS-Version ArcGIS 10 (siehe Kapitel 2.3.5) gab es speziell im Bereich des Network Analysts diverse Neuerungen. So sind jetzt auch linien- und flächenhafte Barrieren möglich. Auch hier muss die Anwendung an die Neuerungen angepasst werden. Eine Möglichkeit, dies zu bewerkstelligen, ist die Veröffentlichung und Freigabe des Quellcodes, was zur Weiterentwicklung durch Internet-Communities von ESRI und OSM führen könnte. Die mit der Anwendung erzeugten Daten können für diverse Anwendungsbereiche eine Alternative zu proprietären Daten für die Netzwerkanalyse darstellen. Eine professionelle Überarbeitung der Anwendung könnte deshalb zu einer Dienstleistung führen, die auf Basis freier Daten einen Mehrwert für diverse Kundengruppen liefert. Geschäftsmodelle, die auf Crowdsourcing und freien Daten basieren sind in der Geo-Branche noch recht neu. Einige Vorbilder, die der Orientierung dienen könnten, gibt es aber schon. 96

105 Abkürzungsverzeichnis API Application Programming Interface ESRI Environmental Systems Research Institute GIS Geoinformationssystem GPS Global Positioning System JAR Java Archive Java VM Java Virtual Machine JAXB Java Architecture for XML Binding LBS Location Based Services POI Point of Interest OECD Organisation for Economic Co-operation and Development ORS OpenRouteService OSM OpenStreetMap OXR Osmexport Rule File UGC User Generated Content UML Unified Modeling Language UNETRANS Unified Network for Transportation VBScript Visual Basic Script VGI Volunteered Geographic Information VRP Vehicle Routing Problem WMS Web Map Service XML Extensible Markup Language XSD XML Schema IX

106 Abbildungsverzeichnis Abb. 1: Endpoint Connectivity Policy (aus der ArcGIS Desktop 9.3 Help)... 7 Abb. 2: Any Vertex Connectivity Policy (aus der ArcGIS Desktop 9.3 Help)... 8 Abb. 3: Defintion von Elevation Fields (aus der ArcGIS Desktop 9.3 Help)... 8 Abb. 4: Abbiegeverbote (Turns) im Network Analyst (aus der ArcGIS Desktop 9.3 Help) Abb. 5: Vergleich OpenStreetMap - Google Maps, Thuwal, Saudi-Arabien Abb. 6: Vergleich OpenStreetMap - Google Maps, Formosa, Brasilien Abb. 7: Beispiel für Zugangsbeschränkung (Freising, Fußweg Am Schwimmbad) Abb. 8: Transportmittel-Hierarchie Abb. 9: Deutsche Default-Tabelle für Transportmittelbeschränkungen Abb. 10: Barriere Schlagbaum Abb. 11: Links-Abbiegeverbot (Freising, Goethestraße Plantagenweg) Abb. 12: Export von OSM-Daten im OSM-XML-Format Abb. 13: Struktur der Geodatabase Abb. 14: Workflow der Anwendung Abb. 15: Routing auf manuell erstelltem Netz in Münster (Abbiegeverbot ) Abb. 16: Umwandlung eines Abbiegegebots in Abbiegeverbote (Relation , Münster) Abb. 17: Zuweisung der Edge-Positionen Abb. 18: Theoretische Zuweisung der Edge Positions bei ungesplitteten Edges Abb. 19: Umwandlung eines Abbiegegebots in Abbiegeverbote mit Splitting (Relation , Münster) Abb. 20: Verwendete Nodes für die grafische Darstellung eines Abbiegeverbots Abb. 21: Grafische Oberfläche der Anwendung Abb. 22: Legende der Flussdiagramme Abb. 23: Schritt 1: Einlesen der Parameter-Datei Abb. 24: Schritt 2: Einlesen der OSM-Datei Abb. 25: Schritt 3: Erstellung der GDB Abb. 26: Schritt 4: Festlegung des geografischen Raumbezugs Abb. 27: Schritt 5: Erstellung des Feature Datasets Abb. 28: Schritt 6: Initialisierung der Feature Classes roads, pois und barriers Abb. 29: Schritt 7: Initialisierung des Network Datasets mit den Network Junctions Abb. 30: Schritt 8: Initialisierung der Turn Feature Class turns Abb. 31: Schritt 9: Network Attribute" TurnRestriction" zum Network Dataset hinzufügen Abb. 32: Schritt 10: Generierung der Abbiegeverbote (mit Splitting der Straßen) Abb. 33: Schritt 11: Befüllung der Feature Class roads Abb. 34: Schritt 12: Befüllung der Turn Feature Class turns Abb. 35: Schritt 13: Befüllung der Feature Class pois Abb. 36: Schritt 14: Befüllung der Feature Class barriers Abb. 37: Schritt 15: Erzeugung des Map Documents Abb. 38: Schritt 16: Hinzufügen der Feature Classes zum Map Document Abb. 39: Schritt 17: Hinzufügen der Network Analyst Solver Layer zum Map Document Abb. 40: Routing in Münster mit OpenRouteService (Auto, schnellste Verbindung) Abb. 41: Routing in Münster mit CoudMade (Auto, schnellste Verbindung) Abb. 42: Routing in Münster mit YourNavigation (Auto, schnellste Verbindung) Abb. 43: Routing in Münster mit OSM2NetworkDataset (Auto, schnellste Verbindung) X

107 Abb. 44: Routing in Münster mit ESRI StreetMap Premium Teleatlas (Auto, schnellste Verbindung). 90 Abb. 45: Routing in Münster mit European Route Finder TeleAtlas (Auto, schnellste Verbindung) Abb. 46: Routing in Münster mit NAVTEQ Map24 (Auto, schnellste Verbindung) Abb. 47: Routing in Münster mit OpenRouteService und YourNavigation (Fahrrad, kürzeste Verbindung) Abb. 48: Routing in Münster mit ESRI StreetMap Premium Teleatlas und OSM2NetworkDataset (Fahrrad, kürzeste Verbindung) Abb. 49: Erreichbarkeitsanalyse um den Bahnhof Münster mit OSM2NetworkDataset (Auto, drei Minuten) Abb. 50: Erreichbarkeitsanalyse um den Bahnhof Münster mit ESRI StreetMap Premium Teleatlas (Auto, drei Minuten) Abb. 51: Renderer Mapnik: Tiergehege im Berliner Zoo... XXXIV Abb. 52: Renderer Osmarender: Tiergehege im Berliner Zoo... XXXIV Abb. 53: Vereinfachte Darstellung des Datenmodells (aus RAMM & TOPF, 2009)... XXXV Abb. 54: Deutsche Transportmittel-Hierachie... XL Abb. 55: Allgemeine Default-Tabelle für Transportmittelbeschränkungen... XL Abb. 56: Java-Klassen der Parameter-Datei... LXI Abb. 57: Java-Klassen der OSM-Datei... LXII XI

108 Tabellenverzeichnis Tabelle 1: Zuweisung von Connectivity Groups... 7 Tabelle 2: Network Attributes: Erlaubte Units und Data Types pro Usage Type Tabelle 3: Schema der Turn Feature Class Tabelle 4: Fahrradwege (Schlüssel cycleway) Tabelle 5: Wichtigste Verkehrsbeschränkungen Tabelle 6: Wichtigste Oneway-Werte Tabelle 7: Geschwindigkeitseinheiten Tabelle 8: Größen- und Gewichtsbeschränkungen Tabelle 9: Verkehrsberuhigung (OSM-Schlüssel: traffic_calming) Tabelle 10: Abbiegevorschriften: Werte für das OSM-Tag restriction Tabelle 11: Shapefiles der Geofabrik Tabelle 12: Shapefiles von CloudMade Tabelle 13: Tools und Skripte zur Konvertierung von OSM-Daten in ESRI-Datenformate Tabelle 14: Feature Classes in der GDB Tabelle 15: Verwendung der Parameter Tabelle 16: Feature Class roads Tabelle 17: Theoretisch mögliche Kombinationsfälle für die Schlüssel highway, construction und proposed Tabelle 18: Feature Class turns Tabelle 19: Feature Class barriers Tabelle 20: Network Dataset Sources Tabelle 21: Connectivity-Einstellungen Tabelle 22: Restriktionen im Network Dataset Tabelle 23: Kosten im Network Dataset Tabelle 24: Übersicht über die Network Attributes und ihre Unterattribute Tabelle 25: Network Attributes Tabelle 26: Network Attributes Evaluators (Source Values) Tabelle 27: Vergleich von Routingdiensten Tabelle 28: Definition von Nodes, Tags und Relations... XXXVII Tabelle 29: Attribute von XML-Tags, wie sie in der OSM-XML-Datei verwendet werden... XXXVIII Tabelle 30: Wege: linienhafte highway-osm-tags bezogen auf Deutschland... XXXIX Tabelle 31: Zutrittsbeschränkungsarten... XLI Tabelle 32: Bekannteste Barrieren (OSM-Schlüssel: barrier)... XLII XII

109 Listings Listing 1: Beispiel für eine Straße (Freising) Listing 2: Beispiel für Zugangsbeschränkung (Freising, Fußweg Am Schwimmbad) Listing 3: Geplante Straße mit proposed-osm-tag (Münster) Listing 4: Geplante Straße ohne proposed-osm-tag (Münster) Listing 5: Im Bau befindliche Straße (Freiburg) Listing 6: Explizite Geschwindigkeitsbegrenzung in km/h (Freising) Listing 7: Geschwindigkeitsbeschränkung über Variable (Freiburg) Listing 8: Beispiel für Maximalhöhe Listing 9: Links-Abbiegeverbot (Freising, Goethestraße Plantagenweg) Listing 10: Aufbau der Parameter-Datei (XML) Listing 11: Parameter transport_mode_hierarchy für motorcar und Deutschland Listing 12: Parameter transport_mode_hierarchy für bicycle und Deutschland Listing 13: Parameter access_barrier_restrictions für motorcar (Beispiel) Listing 14: Parameter access_barrier_restrictions_interpretation für motorcar (Beispiel) Listing 15: Parameter slowdown_barrier_restrictions für motorcar (Beispiel) Listing 16: Parameter access_highway_restrictions für motorcar (Beispiel) Listing 17: Parameter access_highway_restrictions_interpretation für motorcar (Beispiel) Listing 18: Prinzipieller Aufbau des Parameters onway_highway_implications Listing 19: Parameter maxspeed_highway_implications für motorcar (Beispiel) Listing 20: Parameter avspeed_highway_implications für motorcar (Beispiel) Listing 21: Parameter speed_highway_variables für motorcar (Beispiel) Listing 22: Parameter speed_highway_units (Beispiel) Listing 23: Parameter length_highway_units (Beispiel) Listing 24: Parameter weight_highway_units (Beispiel) Listing 25: Parameter drivetime_slowdown_delay für motorcar (Beispiel) Listing 26: Original-Abbiegegebot (Relation , Münster) Listing 27: Umgewandeltes Abbiegegebot in Abbiegeverbote (Relation , Münster) Listing 28: from-way des Abbiegegebots der Relation (Münster) Listing 29: to-way des Abbiegegebots der Relation (Münster) Listing 30: to-way des umgewandelten Abbiegegebots in ein Links-Abbiegeverbot (Relation , Münster) Listing 31: to-way des umgewandelten Abbiegegebots in ein Rechts-Abbiegeverbot (Relation , Münster) Listing 32: Network Attribute "Access" Evaluator (roads, FROM-TO und TO-FROM, Beispiel) Listing 33: Network Attribute "Closed" (roads, FROM-TO und TO-FROM) Listing 34: Network Attribute "Speed" (roads, FROM-TO und TO-FROM) Listing 35: Network Attribute "SlowDown" (roads, FROM-TO und TO-FROM) Listing 36: Network Attribute "DriveTime" (roads, FROM-TO und TO-FROM, Beispiel) Listing 37: Network Attribute "SlowDown" (barriers) Listing 38: Network Attribute "DriveTime" (barriers, Beispiel) Listing 39: Network Attribute "Oneway" (roads, FROM-TO) XIII

110 Listing 40: Network Attribute "Oneway" (roads, TO-FROM) Listing 41: Network Attribute "Barrier" (barriers, Beispiel) Listing 42: WHERE-Clause der Network Source roads beim Laden der Network Locations Listing 43: Einlesen und Validierung der Parameter-Datei (stark vereinfacht) Listing 44: Initialisierung der Turn Feature Class turns Listing 45: Erstellung einer Polyline Listing 46: Befüllung eines Fields Listing 47: Auszug aus einer OSM-XML-Datei (Münster)... XXXVI Listing 48: XML Schema für OSM v0.6 (osm_v_0_6.xsd)... XLV Listing 49: XML Schema für die Parameter-Datei (Parameters.xsd)... XLVIII Listing 50: Beispiel einer Parameter-Datei für motocar (Auto) bezogen auf Deutschland... LIII Listing 51: Beispiel einer Parameter-Datei für bicycle (Fahrrad) bezogen auf Deutschland... LX Listing 52: Aufbau der Batch-Datei... LXIII Listing 53: Beispiel einer Batch-Datei... LXIII XIV

111 Index Access-Restriction Any Vertex Connectivity Policy... Siehe Connectivity API... IX Best Route... Siehe Network Analyst Solver Beste Standorte... Siehe Netzwerkanalyse Beste Wege... Siehe Netzwerkanalyse Closest Facility... Siehe Network Analyst Solver Collaborative Effort... 14, XVIII Connectivity... 6, XVIII Any Vertex Connectivity Policy... 7 Connectivity Group... 7, XVIII Connectivity Policy... 7, XVIII Elevation Field... 8, XVIII Endpoint Connectivity Policy... 7 Connectivity Group... Siehe Connectivity Connectivity Policy... Siehe Connectivity Constant Evaluator... Siehe Evaluator Creative Commons Creative Commons Attribution-Share Alike Creative Commons Attribution-Share Alike Siehe Creative Commons Crowdsourcing... 14, XVIII Directions... 13, XVIII Edge... XVIII Edge (Feature) Source... 6, XVIII Elevation Field... Siehe Connectivity Endpoint Connectivity Policy... Siehe Connectivity ESRI... IX Evaluator... 10, XVIII Constant Evaluator Field Evaluator Field Expression Evaluator Function Evaluator Global Turn Delay Evaluator VBScript Evaluator Feature Dataset... 6, XVIII Field Evaluator... Siehe Evaluator Field Expression Evaluator... Siehe Evaluator Function Evaluator... Siehe Evaluator GIS... IX Global Turn Delay Evaluator... Siehe Evaluator Global Turns... 12, XVIII GPS... IX Graph... 2 Graphentheorie... 2 Heap Size...XVIII, LXIII Impedance... 6, 9, XVIII JAR... IX Java Architecture for XML Binding XV

112 Java VM... IX JAXB... Siehe Java Architecture for XML Binding Junction... Siehe Network Junction Junction (Feature) Source... XVIII LBS... IX Line Feature Class... XVIII Location-Allocation Solver... Siehe Network Analyst Solver Map Compare Maplint Mapnik... Siehe Renderer Multimodales Netz... 6, 7, XVIII Navigation... Siehe Netzwerkanalyse Network Analyst... 5 Network Analyst Solver... 5 Best Route... 5 Closest Facility... 5 Location-Allocation Solver OD Cost Matrix... 6 Service Area... 5 Vehicle Routing Problem... 6 Network Attribute... 9, XIX Network Dataset... 6, XVIII Network Junction... 6, XIX Netzwerkanalyse... 3 Beste Standorte...3, 4 Beste Wege...3, 4 Navigation... 4 Problem des Handlungsreisenden... 4 Reisendenproblem...3, 4 Routenplanung... 4 Routing... 4 Rundreiseproblem... 4 Traveling Salesman Problem... 4 Node OD Cost Matrix... Siehe Network Analyst Solver OECD... IX OpenStreetBugs OpenStreetMap-Wiki ORS... IX OSM... IX OSM Inspector Osmarender... Siehe Renderer OSM-Tag OSM-Wiki... Siehe OpenStreetMap-Wiki POI... IX Point Feature Class... XIX Problem des Handlungsreisenden... Siehe Netzwerkanalyse Reisendenproblem... Siehe Netzwerkanalyse Relation Renderer... 16, XIX XVI

113 Mapnik Osmarender Restriction Routenplanung... Siehe Netzwerkanalyse Routing... Siehe Netzwerkanalyse Ruby RubyGem Rundreiseproblem... Siehe Netzwerkanalyse Service Area... Siehe Network Analyst Solver Shapefile... XIX Tagging... 14, XIX Transport Mode Restriction Traveling Salesman Problem... Siehe Netzwerkanalyse Turn Turn Feature... XIX Turn Feature Class... 12, XIX UGC...Siehe User Generated Content UNETRANS... Siehe Unified Network for Transportation Unified Modeling Language... 80, XIX Unified Network for Transportation... 6, XIX Unmarshalling... 77, XIX User Generated Content... 14, XIX VBScript... IX VBScript Evaluator... Siehe Evaluator Vehicle Routing Problem... Siehe Network Analyst Solver VGI... Siehe Volunteered Geographic Information Volunteered Geographic Information... 14, XIX VRP... IX Way Wildcard... 49, XIX WMS... IX XML... IX XML Schema XSD... Siehe XML Schema XVII

114 Glossar Crowdsourcing Collaborative Effort Connectivity Connectivity Group Connectivity Policy Directions Edge Edge (Feature) Source Elevation Field Evaluator Feature Dataset Global Turns Heap Size Impedance Junction Junction (Feature) Source Line Feature Class Multimodales Netz Network Dataset Auslagerung der Arbeit auf die Arbeitskraft und Intelligenz von vielen Freizeitarbeitern XVIII Gemeinschaftsarbeit Art der Verknüpfung von Netzwerkelmenten im Network Analyst Gruppierung von Netzwerkelementen zur Modellierung der Connectivity im Network Analyst Regel im Network Analyst, wie Line Features mit Point Features verknüpft werden Sammlung von Attributen im Network Analyst zur Erstellung einer Wegbeschreibung Kante/Segment in einem Netzwerk, Netzwerkelement Line Feature Class in ArcGIS, die Edges eines Netzwerks enthält Elevation Fields dienen im Network Analyst zur Verfeinerung der Connectivity an Endpunkten von Edges Bewerter zur Bewertung von Netzwerkelementen im Network Analyst Container für Feature Classes in einer Geodatabase von ArcGIS zur Definition eines einheitlichen Raumbezugs Abbiegesituationen im Network Analyst, für die kein eigenes Turn Feature in einer Turn Feature Class definiert ist allokierter Speicher der Java VM Kosten, Widerstand in einem Netzwerk siehe Network Junction Point Feature Class in ArcGIS, die Junctions eines Netzwerks enthält Feature Class in ArcGIS, die linienhafte Daten enthält Netzwerk mit mehreren Verkehrsmitteln Sammlung von topologisch verbundenen Netzwerkelementen im Network Analyst mit Kanten, Knoten und Abbiegevorschriften in einem ungerichteten Netzwerk

115 Network Attribute Network Junction Point Feature Class Renderer Shapefile Tagging Turn Feature Turn Feature Class Unified Modeling Language Unified Network for Transportation Unmarshalling User Generated Content Volunteered Geographic Information Wildcard Eigenschaft von Netzwerkelementen im Network Analyst, die die Passierbarkeit kontrolliert Endpunkt oder Kreuzungspunkt von Kanten in einem Netzwerk, Netzwerkelement Feature Class in ArcGIS, die punkthafte Daten enthält im Zusammenhang mit OSM: Anwendung zum Rendern/Visualisieren von Kartendaten Geodatenformat von ESRI Erfassung von Geodaten in OSM Feature im Network Analyst, das ein Abbiegeverbot repräsentiert Feature Class, die Turn Features enthält Sprache, die u.a. zur Modellierung von Software verwendet wird Netzwerk-Datenmodell für Transportnetze im Zusammenhang mit XML-Dateien und Java: Umwandlung von XML-Daten in Java-Objekte nutzergenerierter Inhalt Erfassung von Geodaten durch Freiwillige Platzhalter für Zeichen XIX

116 Literaturverzeichnis Das Literaturverzeichnis ist unterteilt in eine Auflistung von Büchern und Internet-Quellen, die zur Erarbeitung der Thesis herangezogen wurden. Bücher [1] BARTELME, Norbert (2005): Geoinformatik. Modelle, Strukturen, Funktionen. Springer-Verlag, Berlin, Heidelberg, New York. [2] BILL, Ralf (1999): Grundlagen der Geo-Informationssysteme. Band 2 Analysen, Anwendungen und neue Entwicklungen. Herbert Wichmann Verlag, Heidelberg. [3] BILL, Ralf & Marco L. ZEHNER (2001): Lexikon der Geoinformatik. Herbert Wichmann Verlag, Heidelberg. [4] BLOECH, Jürgen & Gösta B. IHDE (Hrsg.) (1997): Vahlens Großes Logistiklexikon. Verlag Franz Vahlen GmbH, München. [5] BOLLMANN, Jürgen & Wolf Günther KOCH (2002): Lexikon der Kartographie und Geomatik. Zweiter Band. Spektrum Akademischer Verlag, Heidelberg, Berlin. [6] BUTLER, J. Allison (2008): Designing Geodatabases for Transportation. ESRI Press, Redlands (Kalifornien). [7] COLEMAN, David J. & Yola GEORGIADOU (2010): Why And What Do Individuals Contribute? Volunteered Geographic Information. In: GEOInformatics, März 2010, S CMedia B.V., Emmeloord (Niederlande). [8] DIEZ, Dietrich (2010): OpenStreetMap Unterwegs für eine freie Weltkarte. In: Kartographische Nachrichten. Fachzeitschrift für Geoinformation und Visualisierung. Deutsche Gesellschaft für Kartographie e.v., 60. Jahrgang, April2010, Heft 2, S. 89f. Kirschbaum Verlag, Bonn. [9] DOMSCHKE, Dr. Wolfgang (1981): Logistik: Transport. Grundlagen, lineare Transport- und Umladeprobleme. R. Oldenbourg Verlag GmbH, München. [10] DÖRFFEL, Günter (2010): Network Analyst in ArcGIS 10, Vortrag, Kranzberg, April [11] HERTER, Michael & Karl-Heinz MÜHLBAUER (Hrsg.) (2008): Handbuch Geomarketing. Herbert Wichmann Verlag, Heidelberg, München, Landsberg, Berlin. [12] LIEBIG, Wolfgang (1999): Desktop-GIS mit ArcView GIS. Leitfaden für Anwender. Herbert Wichmann Verlag, Heidelberg. [13] LUPIEN, Anthony E., William H. MORELAND & Jack DANGERMOND (1987): Network analysis in Geographic Information Systems. In: Photogrammetric Engineering and Remote, Vol. 53, No. 10, S [14] NEIS, Pascal (2008): Location Based Services mit OpenStreetMap Daten. Masterarbeit, Fachhochschule Mainz, Fachbereich I, Master-Studiengang Geoinformatik und Vermessung, betreut durch Prof. Dr. Alexander Zipf, Mainz. [15] RAMM, Frederik & Jochen TOPF (2009): OpenStreetMap Die freie Weltkarte nutzen und mitgestalten. Lehmanns Media, Berlin. XX

117 [16] STENGEL, Sabine & Sascha POMPLUN (2010): OpenStreetMap die freie Weltkarte für alle oder Spielerei von Karten-Amateuren?. In: Vermessung Brandenburg, Nr. 1/2010, 15. Jahrgang, S , Ministerium des Inneren des Landes Brandenburg, Potsdam. [17] VAHRENKAMP, Richard & Dirk C. MATTFELD (2007): Logistiknetzwerke. Modelle für Standortwahl und Tourenplanung. Gabler Verlag, Wiesbaden. Internet [18] ArcGIS Desktop 9.3 Help [19] ArcGIS Desktop 9.3 Help Geoprocessing Tools [20] ArcGIS Desktop 9.3 Help Setting Directions [21] ArcGIS Desktop 9.3 Help Turns in the network dataset taset [22] ArcGIS Desktop 9.3 Help Types of network analyses of_network_analyses [23] ArcGIS Desktop 9.3 Help Types of evaluators used by a network _by_a_network [24] ArcGIS Desktop 9.3 Help Understanding connectivity y [25] ArcGIS Desktop 9.3 Help Understanding the network attribute rk_attribute [26] ArcGIS Desktop 9.3 Help Using parameters with network attributes etwork_attributes [27] ArcGIS Online Ressource Centers XXI

118 [28] ArcGIS Online Using standard routing tasks [29] ArcScripts - Convert OpenStreetMap Data [30] ArcScripts - OpenStreetMap Loader [31] ArcSripts OSM2Shape [32] CloudMade [33] CloudMade About [34] CloudMade Downloads [35] CoudMade Downloads: Germany [36] CloudMade Maps [37] Creative Commons [38] Creative Commons Creative Commons Attribution-Share Alike [39] derstandard.at [40] derstandard.at Interview mit Steve Coast [41] ESRI Deutschland XXII

119 [42] ESRI Deutschland Elemente der Geodatabase [43] ESRI Deutschland Erweiterung Network Analyst [44] ESRI Deutschland ArcAktuell Ausgabe 4/2001, Management multimodaler Verkehrssystem [45] FME [46] Geofabrik [47] Geofabrik Download [48] Geofabrik Map Compare [49] Google Maps [50] JAXB [51] JAXB Unmarshalling Data.html#Unmarshalling%20and%20Using%20the%20Data [52] LOGIBALL [53] Mapnik [54] NAVLOG [55] NAVTEQ XXIII

120 [56] NAVTEQ Global Coverage Statistics [57] OpenCycleMap [58] OpenRouteService [59] OpenStreetBugs [60] OSM (de) [61] OSM (de) FAQ, Lizenz [62] OSM (de) Presse [63] OSM (org) [64] OSM (org) Browse, Node [65] OSM (org Browse, Way [66] OSM (org) OpenStreetMap stats report [67] OSM Inspector [68] OSM Restriction Analyser [69] OSM-Wiki XXIV

121 [70] OSM-Wiki API v [71] OSM-Wiki API v0.6/dtd [72] OSM-Wiki Bicycle [73] OSM-Wiki Computing_access_restrictions [74] OSM-Wiki Computing access restrictions, Algorithm [75] OSM-Wiki Computing access restrictions, Parameters [76] OSM-Wiki Computing access restrictions, Transport mode hierarchy hy [77] OSM-Wiki Country code [78] OSM-Wiki Database schema [79] OSM-Wiki Data Primitives [80] OSM-Wiki DE: Bicycle/Wege oder Route [81] OSM-Wiki DE: Bicycle/Wege oder Route, Radroute [82] OSM-Wiki DE: Key: access XXV

122 [83] OSM-Wiki DE: Key: access, Bezogen auf den Transporttyp [84] OSM-Wiki DE: Key: access, Größen- und Gewichtseinschränkungen _und_gewichtseinschr.c3.a4nkungen [85] OSM-Wiki DE: Key: highway [86] OSM-Wiki DE: Key: oneway, Verwendung [87] OSM-Wiki DE: Map Features [88] OSM-Wiki DE: Map Features, Barrieren [89] OSM-Wiki DE: Map Features, Beschränkungen [90] OSM-Wiki DE: Map Features, Fahrradwege [91] OSM-Wiki DE: Map Features, Wege [92] OSM-Wiki DE: Relation: restriction [93] OSM-Wiki DE: Relation: restriction, Anmerkungen [94] OSM-Wiki DE: Relation: restriction, Ausnahme von Fahrzeugtypen [95] OSM-Wiki DE: Relation: restriction, Hinweis zur Beschilderung XXVI

123 [96] OSM-Wiki DE: Relation: restriction, Mindestanforderung [97] OSM-Wiki DE: Relation: restriction, Zeitliche Beschränkungen [98] OSM-Wiki DE: Tag: highway=trunk_link [99] OSM-Wiki Key: access [100] OSM-Wiki Key: access, Access time restrictions [101] OSM-Wiki Key: barrier [102] OSM-Wiki Key: barrier, Linear barriers [103] OSM-Wiki Key: barrier, Node barriers [104] OSM-Wiki Key: bridge [105] OSM-Wiki Key: construction [106] OSM-Wiki Key: cycleway [107] OSM-Wiki Key: highway [108] OSM-Wiki Key: highway, International equivalence XXVII

124 [109] OSM-Wiki Key: layer [110] OSM-Wiki Key: maxspeed [111] OSM-Wiki Key: maxspeed, Disputed tips [112] OSM-Wiki Key: oneway [113] OSM-Wiki Key: oneway, How to Map [114] OSM-Wiki Key: oneway, values [115] OSM-Wiki Key: proposed [116] OSM-Wiki Key: ref [117] OSM-Wiki Key: traffic_calming [118] OSM-Wiki Key: tunnel [119] OSM-Wiki Main Page [120] OSM-Wiki Map Features [121] OSM-Wiki Map Features, Barrier XXVIII

125 [122] OSM-Wiki Map Features, Cycleway [123] OSM-Wiki Map Features, Highway [124] OSM-Wiki Map Features, Restrictions [125] OSM-Wiki Map Features/Units, Speed [126] OSM-Wiki Mapnik Mapnik [127] OSM-Wiki ORS, Used Tags for Routing [128] OSM-Wiki Osmarender [129] OSM-Wiki OSM tags for routing/access-restrictions [130] OSM-Wiki OSM tags for routing/access-restrictions, Germany [131] OSM-Wiki OSM tags for routing/maxspeed [132] OSM-Wiki Planet.osm [133] OSM-Wiki Projects [134] OSM-Wiki Projects, Quality Control XXIX

126 [135] OSM-Wiki Relation, Established uses of Relations [136] OSM-Wiki Relation: restriction, Tags [137] OSM-Wiki Relations/Routes, Cycle routes (also mountain bike) [138] OSM-Wiki Renderer [139] OSM-Wiki Tag: barrier=block [140] OSM-Wiki Tag: barrier=bollard [141] OSM-Wiki Tag: barrier=cycle_barrier, Examples [142] OSM-Wiki Tag: barrier=cycle_barrier, How to tag [143] OSM-Wiki Tag: barrier=hedge [144] OSM-Wiki Tag: highway=cycleway [145] OSM-Wiki Tag: highway=motorway [146] OSM-Wiki Tag: highway=motorway_link [147] OSM-Wiki Tag: junction=roundabout XXX

127 [148] OSM-Wiki XSD [149] OSM-Wiki.osm#Variations [150] OSMDoc (Statistik aus dem August 2009) [151] OSMDoc Key: maxspeed:backward (Statistik aus dem August 2009) [152] OSMDoc Key: maxspeed:forward (Statistik aus dem August 2009) [153] OSMDoc Key: maxspeed (Statistik aus dem August 2009) [154] OSMDoc Key: minspeed (Statistik aus dem August 2009) [155] Osmexport [156] Osmexport Rule File [157] OSMLib auf RubyForge [158] OSM Restriction Analyser [159] Ruby [160] RubyGems [161] Sautter XXXI

128 [162] Sautter transparent map [163] Tele Atlas [164] Tele Atlas Community Input [165] TomTom [166] TomTom Map Share [167] UML [168] United Maps [169] WhereGroup [170] WhereGroup WMS-Dienst OSM_Basic [171] Wikipedia [172] Wikipedia Crowdsourcing [173] Wikipedia User Generated Content [174] Yahoo Maps [175] YourNavigation [176] YourNavigation OpenStreetMap Routing Service XXXII

129 Anhang XXXIII

130 Abbildungen, Tabellen, Listings OSM: Renderer Abb. 51: Renderer Mapnik: Tiergehege im Berliner Zoo 1 Abb. 52: Renderer Osmarender: Tiergehege im Berliner Zoo 2 1 [63] ( ) 2 [63] ( ) XXXIV

131 OSM: Grundlegendes Datenmodell Abb. 53: Vereinfachte Darstellung des Datenmodells (aus RAMM & TOPF, 2009) 1 <?xml version="1.0" encoding="utf-8"?> <osm version="0.6" generator="cgimap 0.0.2"> <bounds minlat="51.912" minlon="7.5442" maxlat="51.998" maxlon="7.69"/> [...] <node id=" " lat=" " lon=" " user="hugoe" uid="7426" visible="true" version="4" changeset=" " timestamp=" t21:48:58z"/> [...] <node id=" " lat=" " lon=" " user="gluko" uid="36745" visible="true" version="3" changeset="845019" timestamp=" t11:53:09z"/> [...] <node id=" " lat=" " lon=" " user="gluko" uid="36745" visible="true" version="4" changeset="845019" timestamp=" t11:54:10z"/> [...] <node id=" " lat=" " lon=" " user="wanmil" uid="109925" visible="true" version="3" changeset=" " timestamp=" t10:42:15z"> <tag k="highway" v="bus_stop"/> <tag k="name" v="p+r Weseler Straße"/> </node> [...] <node id=" " lat=" " lon=" " user="hugoe" uid="7426" visible="true" version="3" changeset=" " timestamp=" t21:48:58z"/> [...] <way id=" " user="hugoe" uid="7426" visible="true" version="13" changeset=" " timestamp=" t21:48:59z"> <nd ref=" "/> 1 [15] (S. 50)) XXXV

132 <nd ref=" "/> <nd ref=" "/> <tag k="highway" v="primary"/> <tag k="maxspeed" v="70"/> <tag k="name" v="weseler Straße"/> <tag k="oneway" v="yes"/> <tag k="ref" v="b 219"/> </way> [...] <way id=" " user="hugoe" uid="7426" visible="true" version="1" changeset=" " timestamp=" t21:48:57z"> <nd ref=" "/> <nd ref=" "/> <tag k="highway" v="primary"/> <tag k="maxspeed" v="70"/> <tag k="name" v="weseler Straße"/> <tag k="oneway" v="yes"/> <tag k="ref" v="b 219"/> </way> [...] <relation id="303554" user="hugoe" uid="7426" visible="true" version="1" changeset=" " timestamp=" t21:48:58z"> <member type="way" ref=" " role="from"/> <member type="way" ref=" " role="to"/> <member type="node" ref=" " role="via"/> <tag k="restriction" v="only_straight_on"/> <tag k="type" v="restriction"/> </relation> [...] </osm> Listing 47: Auszug aus einer OSM-XML-Datei (Münster) 1 XML-Tag- enthalten in XML-Tag(s) Häufigkeit innerhalb Name des XML-Tags node osm 0 n Node Beschreibung way osm 0 n Way relation osm 0 n Relation nd way Stützpunkt eines Ways tag node, way, relation 0 n Tags zur Definition von Eigenschaften (im Weiteren OSM-Tag zur Abgrenzung zu den XML-Tags genannt) member relation Teilnehmer einer Relation bounds osm 0 1 Definiert einen rechteckigen Bereich, für den die XML-Datei erstellt wurde und vollständig sind. Kann alternativ zu bound verwendet werden XXXVI

133 node way relation nd member tag bounds bound osm XML-Tag- enthalten in XML-Tag(s) Häufigkeit innerhalb Beschreibung Name des XML-Tags bound osm 0 1 Definiert einen rechteckigen Bereich, für den die XML-Datei erstellt wurde und vollständig sind. Kann alternativ zu bounds verwendet werden. Tabelle 28: Definition von Nodes, Tags und Relations 1 Name XML-Attribut enthalten in XML-Tag(s) Beschreibung Wert: Wert: Datentyp Länge id Integer 64 x x x ID timestamp Text x x x Zeitpunkt der letzten Änderung user Text 255 x x x Bearbeiter uid Integer 20 x x x Benutzernummer changeset Integer 20 x x x Verweis auf das Changeset visible lat lon Boolean (true/false, yes/now, 1/0) Gleitkommazahl mit 7 Nachkommastellen Gleitkommazahl mit 7 Nachkommastellen x x x false, falls das Objekt in der Datenbank gelöscht wurde, andernfalls true. x x geografische Breite in Grad geografische Länge in Grad ref Integer 64 x x Referenz auf die ID eines Nodes, Ways oder einer Relation k Text 255 x Schlüssel (Key) eines Tags v Text 255 x Wert (Value) eines Tags 1 [15] (S. 49ff) [149] XXXVII

134 node way relation nd member tag bounds bound osm Name XML-Attribut enthalten in XML-Tag(s) Beschreibung Wert: Wert: Datentyp Länge type Text (way, node, relation) - x Typ des Teilnehmers der Relation role Text 255 x Rolle eines Teilnehmers einer Relation minlat minlon maxlat maxlon Gleitkommazahl Gleitkommazahl Gleitkommazahl Gleitkommazahl mit 7 Nachkommastellen mit 7 Nachkommastellen mit 7 Nachkommastellen mit 7 Nachkommastellen x x x x min. geogr. Breite für angeforderten Bereich der Daten min. geogr. Länge für angeforderten Bereich der Daten max. geogr. Breite für angeforderten Bereich der Daten max. geogr. Länge für angeforderten Bereich der Daten box Text 255 x geogr. Koordinaten für angeforderten Bereich origin Text 255 x Quelle version Integer 20 x x x Version des Objekts version Text (0.6) - x Version der Datenbank-API / des XML- Formats generator Text - x Name des Programms, das die XML-Datei erstellt hat Tabelle 29: Attribute von XML-Tags, wie sie in der OSM-XML-Datei verwendet werden 1 1 [15] (S. 50ff, 286) [71] [78] [79] XXXVIII

135 OSM: Straßen Wert Bedeutung in Deutschland motorway Autobahn motorway_link Autobahn-Zubringer, Autobahn-Anschlussstelle trunk Schnellstraße trunk_link Schnellstraßen-Anschlussstelle primary Bundesstraße primary_link Bundesstraßen-Anschlussstelle secondary Land-, Staats- oder sehr gut ausgebaute Kreisstraße secondary_link Auffahrt zu einer Land-, Staats- oder sehr gut ausgebauten Kreisstraße tertiary Kreisstraße, unclassified Nebenstraße, road Straße unbekannter Klassifikation residential Straße an und in Wohngebieten living_street verkehrsberuhigter Bereich service Erschließungsweg track Feld- und Waldweg pedestrian Weg, Platz, Straße (nur für Fußgänger) raceway Rennstrecke bus_guideway Spurbus-Strecke path allgemeiner Weg, Weg mit mehreren vorgegebenen Nutzungsarten, cycleway Radweg footway Fußweg bridleway Reitweg steps Treppen Tabelle 30: Wege: linienhafte highway-osm-tags bezogen auf Deutschland 1 1 [91] XXXIX

136 OSM: Beschränkung der Beförderungsart Abb. 54: Deutsche Transportmittel-Hierachie 1 Abb. 55: Allgemeine Default-Tabelle für Transportmittelbeschränkungen 2 1 [83] 2 [129] XL