Hochschule Karlsruhe – Technik und Wirtschaft Fakultät

Transcrição

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
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
Aufgabenstellung für die Bachelor-Thesis
von Eva Zimmermann
Fakultät für Geomatik – Studiengang Kartographie und Geomatik
Thema
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 OpenStreetMap-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 OpenStreetMapDaten für Netzwerkanalysen in ArcGIS vereinfacht werden kann. Dazu soll eine prototypische Anwendung geschrieben werden, mit der OpenStreetMap-Daten automatisiert für Network AnalystAnwendungen 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

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 OpenStreetMap-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):
Zweitprüfer (ESRI):
Bearbeitungszeit:
Tag der Ausgabe:
Tag der Abgabe:
Prof. Dr. Anne Rauner
Dipl.-Ing. (FH) Kathrin Gobitz-Pfeifer
3 Monate
01. April 2010
30. Juni 2010
Anschrift der Bachelorandin:
Eva Zimmermann
Giggenhauser Straße 25a
85354 Freising
[email protected]
Ort, Datum:
Unterschrift:
________________________ ____________________________________
(Erstprüfer)
________________________ ____________________________________
(Zweitprüfer)
IV
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
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
Inhaltsverzeichnis
Aufgabenblatt ......................................................................................................................................... III
Executive Summary – Deutsch ................................................................................................................ V
Executive Summary – Englisch ............................................................................................................... VI
Inhaltsverzeichnis .................................................................................................................................. VII
1. Einführung ........................................................................................................................................ 1
2. Netzwerkanalysen in Geoinformationssystemen ........................................................................... 2
2.1. Netzwerk ................................................................................................................................. 2
2.2. Netzwerkanalyse ..................................................................................................................... 3
2.3. Network Analyst in ArcGIS ...................................................................................................... 5
2.3.1. Connectivity ................................................................................................................. 6
2.3.2. Network Attributes ...................................................................................................... 9
2.3.3. Turns .......................................................................................................................... 11
2.3.4. Directions................................................................................................................... 13
2.3.5. Neuerungen in ArcGIS 10 .......................................................................................... 13
3. OpenStreetMap ............................................................................................................................. 14
3.1. Einführung ............................................................................................................................. 14
3.2. Datenmodell .......................................................................................................................... 17
3.2.1. Grundlegendes Datenmodell..................................................................................... 17
3.2.2. Map Features ............................................................................................................. 18
3.2.2.1. Verkehrswege............................................................................................. 18
3.2.2.1.1. Straßen..................................................................................... 18
3.2.2.1.2. Fahrradwege und von Fahrradfahrern benutzbare Wege ...... 19
3.2.2.1.3. Brücken und Tunnel ................................................................. 20
3.2.2.2. Verkehrsbeschränkungen .......................................................................... 20
3.2.2.2.1. Beschränkungen der Beförderungsart .................................... 21
3.2.2.2.2. Baustellen und geplante Straßen ............................................ 24
3.2.2.2.3. Einbahnstraßen........................................................................ 25
3.2.2.2.4. Geschwindigkeitsbeschränkungen .......................................... 26
3.2.2.2.5. Größen- und Gewichtsbeschränkungen .................................. 29
3.2.2.2.6. Zeitliche Beschränkungen ........................................................ 29
3.2.2.2.7. Verkehrsberuhigung ................................................................ 30
3.2.2.2.8. Barrieren .................................................................................. 30
3.2.2.2.9. Abbiegevorschriften ................................................................ 31
3.2.3. Eigenschaften des Verkehrsnetzes ............................................................................ 33
3.3. OSM-Datenbezug .................................................................................................................. 33
3.4. OSM in ArcGIS ....................................................................................................................... 34
3.4.1. OSM in ESRI-Datenformaten ..................................................................................... 35
VII
3.4.1.1. Geofabrik .................................................................................................... 35
3.4.1.2. CloudMade ................................................................................................. 35
3.4.2. Tools und Skripte zur OSM-Konvertierung ................................................................ 36
3.5. Vergleich zu anderen netzwerkanalysefähige Daten ............................................................ 37
4. Netzwerkanalysen mit OpenStreetMap ....................................................................................... 40
4.1. Konzept.................................................................................................................................. 40
4.1.1. Parameter-Datei ........................................................................................................ 43
4.1.2. Feature Class roads.................................................................................................... 54
4.1.3. Feature Class turns .................................................................................................... 57
4.1.4. Feature Class barriers ................................................................................................ 64
4.1.5. Network Dataset ........................................................................................................ 65
4.1.6. Nicht umgesetzte Map Features ............................................................................... 74
4.2. Evaluierung von OSM-Daten in ESRI-Datenformaten für Netzwerkanalysen in ArcGIS ....... 75
4.2.1. Geofabrik ................................................................................................................... 75
4.2.2. CloudMade ................................................................................................................ 75
4.2.3. Tools und Skripte zur OSM-Konvertierung ................................................................ 76
4.2.4. Zusammenfassung der Evaluierung ........................................................................... 76
4.3. Programmiertechnische Umsetzung ..................................................................................... 77
4.4. Vergleich anhand von beispielhaften Netzwerkanalysen ..................................................... 87
4.4.1. Auto-Routing ............................................................................................................. 88
4.4.2. Fahrrad-Routing......................................................................................................... 92
4.4.3. Erreichbarkeitsanalyse............................................................................................... 94
4.4.4. Zusammenfassung ..................................................................................................... 95
4.5. Anwendungsgebiete.............................................................................................................. 95
5. Bewertung und Ausblick ................................................................................................................ 96
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
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
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.
2.1. 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
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.
2.2. 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
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 GeoInformationssysteme“ (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
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 9.3.1 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

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].
2.3.1. 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
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)
Junction Source (z.B. Bahnhöfe)
Connectivity Groups
1
2
x
x
x
Edge Source 2 (z.B. Bahnlinien)
x
Tabelle 1: Zuweisung von Connectivity Groups
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
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
2
[24]
[24]
8
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.
2.3.2. 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 Usage 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
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 Type1
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]:
1

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-
[25]
10
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.
2.3.3. 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
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.
OBJECTID
Field
Datentyp
Object ID
0, 1, …
Beispielwerte
Beschreibung
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, …
Edge2FID
Integer
12, 90, 429, …
Edge2Pos
Double
0, 0.25, …, 1
Position auf dem Line Feature, die die zweite Edge
[Edge3FCID]
Integer
1, 2, …
[Edge3FID]
Integer
2, 104, 189, …
[Edge3Pos]
Double
0, 0.8, …, 1
Position auf dem Line Feature, die die dritte Edge
[…]
Tabelle 3: Schema der Turn Feature Class1
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
2.3.4. 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
2.3.5. 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
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.
3.1. 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 250.000 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
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-Arabien1
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, Brasilien2
1
2
[48]
[48]
15
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 OSMWebsite [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 OSMDaten 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
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.
3.2.1. 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. 50-52).
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 festge17
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.
3.2.2. 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.
3.2.2.1.
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.
3.2.2.1.1.
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 3.2.2.2.2 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 3.2.2.2) zuzuweisen.
In Listing 1 ist ein Beispiel für eine Straße dargestellt.
18
<way id="29434397" user="Kalle_Anka" uid="200015" visible="true"
version="4" changeset="3836598" timestamp="2010-02-09T22:20:23Z">
<nd ref="25591858"/>
<nd ref="26368891"/>
<nd ref="26368890"/>
<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 3.2.2.2.3) aus einem Wohngebiet (highway = residential) [91], die einer Geschwindigkeitsbegrenzung (maxspeed = 30, siehe
Kapitel 3.2.2.2.4) 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].
3.2.2.1.2.
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 3.2.2.1.1 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 3.2.2.2.1).
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
Wert
Bedeutung
Radfahrstreifen (auf Fahrbahn, mit Markierungen)
track
baulich abgesetzter Radweg (entspricht highway = cycleway)
1
27.05.2010
19
opposite_lane
Wert
Bedeutung
Radfahrstreifen entgegen der Fahrtrichtung einer Einbahnstraße
opposite_track
baulich abgesetzter Radweg entgegen der Fahrtrichtung einer Einbahnstraße
opposite
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 3.2.2.2.3.
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].
3.2.2.1.3.
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.
3.2.2.2.
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
Verkehrsbeschränkung
Beschränkung der Beförderungsart
verwendet für Datentypen
Node
Way
Relation
x
x
Kapitel
3.2.2.2.1
Baustellen
x
3.2.2.2.2
geplante Straßen
x
3.2.2.2.2
Einbahnstraßen
x
3.2.2.2.3
Geschwindigkeitsbeschränkungen
x
3.2.2.2.4
Höhenbeschränkungen
x
3.2.2.2.5
Breitenbeschränkungen
x
3.2.2.2.5
Längenbeschränkungen
x
3.2.2.2.5
Gewichtsbeschränkungen
x
3.2.2.2.5
zeitliche Beschränkung
x
3.2.2.2.6
Verkehrsberuhigung
x
x
3.2.2.2.7
Barrieren
x
x
3.2.2.2.8
Abbiegevorschriten
Tabelle 5: Wichtigste Verkehrsbeschränkungen
x
3.2.2.2.9
1
Die Verkehrsbeschränkungen können auch kombiniert werden.
3.2.2.2.1.
Beschränkungen der Beförderungsart
Mit den Beschränkungen der Beförderungsart („Transport mode restriction“ [99] oder auch „AccessRestrictions“ [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="49707433" user="Nelius" uid="212397" visible="true" version="1"
changeset="3807317" timestamp="2010-02-06T17:51:31Z">
<nd ref="420305408"/>
<nd ref="420305409"/>
<nd ref="626771247"/>
<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
2
[120]
27.05.2010
21
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-Hierarchie2
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
2
[63] (27.05.2010)
[73]
22
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änkungen1
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 DefaultTabelle 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
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.
3.2.2.2.2.
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="54727615" user="Asphaltflechte" uid="69419" visible="true" version="1" changeset="4365822" timestamp="2010-04-08T17:21:40Z">
<nd ref="689071064"/>
<nd ref="689071060"/>
<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="54727608" user="Asphaltflechte" uid="69419" visible="true" version="1" changeset="4365822" timestamp="2010-04-08T17:21:32Z">
<nd ref="689070974"/>
<nd ref="689070938"/>
<tag k="highway" v="proposed"/>
</way>
Listing 4: Geplante Straße ohne proposed-OSM-Tag (Münster)2
1
2
20.04.2010
20.04.2010
24
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 3.2.2.1.1) [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="38640134"
user="skyper"
uid="152744"
visible="true"
version="4"
changeset="3255667"
timestamp="2009-11-30T13:21:27Z">
<nd ref="337279873"/>
<nd ref="461363068"/>
<nd ref="575947915"/>
<nd ref="461363073"/>
<nd ref="457699408"/>
<nd ref="21895201"/>
<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-OSMTag 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].
3.2.2.2.3.
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.
yes
Wert
Gebrauch
empfohlen
true
nicht empfohlen
1
nicht empfohlen
no
empfohlen
1
Erklärung
In Richtung der erfassten Nodes besteht eine Einbahnstraße.
Diese Straße kann in beiden Richtungen befahren werden.
14.04.2010
25
false
Wert
Gebrauch
nicht empfohlen
0
nicht empfohlen
-1
empfohlen
reverse
nicht empfohlen
Erklärung
Entgegen der Richtung der erfassten Nodes besteht eine
Einbahnstraße.
Tabelle 6: Wichtigste Oneway-Werte1
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 3.2.2.1.2). 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.
3.2.2.2.4.
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
560.700 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
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 OSMDaten 57 mal [152], maxspeed:backward 45 mal [151], maxspeed jedoch über 500.000 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="8039990" user="Kalle_Anka" uid="200015" visible="true" version="4"
<nd ref="25591972"/>
<nd ref="26403325"/>
<nd ref="26403324"/>
<nd ref="26403323"/>
<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
1
Kilometer pro Stunde
km/h
Meilen pro Stunde
mph
1,609
Knoten
knots
1,852
kph, kmph
Tabelle 7: Geschwindigkeitseinheiten2
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 Ge1
2
27.05.2010
[125]
27
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="42220651" user="skyper" uid="152744" visible="true" version="10"
<nd ref="338147602"/>
<nd ref="338151966"/>
<tag k="lit" v="yes"/>
<tag k="maxspeed" v="DE:urban"/>
<tag k="name" v="Feldbergstraße"/>
<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 DefaultMaximalgeschwindigkeiten. 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 OSMTags und Eigenschaften eine Rolle. Beispielsweise kann die Default-Geschwindigkeitsbeschränkung
von folgenden Eigenschaften abhängen:
1

Straße befindet sich innerhalb eines städtischen Gebietes (City-Area) oder außerhalb

erlaubte Verkehrsmittel

Anzahl der Fahrspuren
14.04.2010
28

Einbahnstraße
Laut der Dokumentation der Geschwindigkeitsbegrenzungen für die verschiedenen Länder sollen die
Regelungen besonders für Deutschland kompliziert sein [131].
3.2.2.2.5.
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
Maximalhöhe
maxheight
Minimalhöhe
minheight
Breite
Maximalbreite
maxwidth
Länge
Maximallänge
maxlength
Gewicht
Maximalgewicht
maxweight
Maximale Achslast
maxaxleload
Höhe
OSM-Tag
Tabelle 8: Größen- und Gewichtsbeschränkungen1
Wie auch bei den Geschwindigkeitsbeschränkungen (siehe Kapitel 3.2.2.2.4) 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="25275349" user="JakobG" uid="168881" visible="true" version="2"
<nd ref="275362039"/>
<nd ref="275362040"/>
<nd ref="275362041"/>
<nd ref="275362042"/>
<nd ref="275362043"/>
<nd ref="275362044"/>
<nd ref="275362045"/>
<tag k="highway" v="unclassified"/>
<tag k="maxheight" v="3.3"/>
<tag k="name" v="Lechtenbergweg"/>
</way>
Listing 8: Beispiel für Maximalhöhe
3.2.2.2.6.
Zeitliche Beschränkungen
Zeitliche Zutrittsbeschränkungen (Access time restrictions) [100] werden in OSM beispielsweise mit
folgenden OSM-Tags definiert werden:

1
date_on
[84]
29

date_off

day_on

day_off

hour_on

hour_off
Diese Beschränkungen können auch in Kombination mit Transportmittelbeschränkungen (siehe Kapitel 3.2.2.2.1), Einbahnstraßen (siehe Kapitel 3.2.2.2.3) und Abbiegvorschriften (siehe Kapitel
3.2.2.2.9) verwendet werden.
Des Weiteren gibt es noch das OSM-Tag maxstay für die maximal erlaubte Parkdauer, dessen Einheit Stunden ist.
3.2.2.2.7.
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
Wert
Bedeutung
Verkehrsberuhigungsmaßnahmen
bump
Bodenwelle (kurz)
chicane
Schikane
cushion
Bodenwelle (mit Lücken)
hump
Bodenwelle (lang)
rumble_strip
Seitenstreifen (holpernd)
table
Bodenwelle (sehr lang und flach)
choker
Fahrbahnverengung
Tabelle 9: Verkehrsberuhigung (OSM-Schlüssel: traffic_calming)1
3.2.2.2.8.
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
Abb. 10: Barriere Schlagbaum1
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].
3.2.2.2.9.
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="3836598" timestamp="2010-02-09T22:20:16Z">
<member type="way" ref="38299874" role="from"/>
<member type="way" ref="5230467" role="to"/>
<member type="node" ref="26404836" 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
2
[64] [65]
27.05.2010
31
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 OSMTags restriction aufgelistet und erklärt.
Wert
Erklärung
no_left_turn
Links-Abbiegeverbot
no_right_turn
Rechts-Abbiegeverbot
no_straight_on
Geradeaus-Fahrverbot
no_u_turn
Wendeverbot
only_left_turn
Links-Abbiegegebot (nur links)
only_right_turn
Rechts-Abbiegegebot (nur rechts)
only_straight_on
Geradeaus-Fahrgebot (nur geradeaus)
Tabelle 10: Abbiegevorschriften: Werte für das OSM-Tag restriction2
1
2
[68]
[95]
32
Wie auch bei den Einbahnstraßen (siehe Kapitel 3.2.2.2.3) gibt es bei den Abbiegevorschriften zeit[97] und fahrzeugabhängige [94] Regelungen, die hier aber nicht näher erläutert werden.
3.2.3. 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 0.
3.3. 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-XMLFormat sind jedoch nur 50.000 Nodes erlaubt.
33
Abb. 12: Export von OSM-Daten im OSM-XML-Format1
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
3.4.1 und 4.2). Diese bieten OSM-Daten nicht nur im Datenformat *.osm an, sondern auch beispielsweise im ESRI Shape-Format.
3.4. 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
3.4.1. 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].
3.4.1.1.
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 ShapeFormat (*.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 osm2shp1, das von ihr für diese Arbeit zur
Verfügung gestellt wurde.
roads
Name des Shapefiles
Line Features
Typ
Beschreibung
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 3.2.2.2.2). Des Weiteren wird nicht beachtet, dass
Höchstgeschwindigkeiten (maxspeed) Angaben zur Einheit haben oder über Variablen definiert sein
können (siehe 3.2.2.2.4). 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.
3.4.1.2.
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 OSMFormat (*.osm) und auch im ESRI Shape-Format (*.shp) zum Download an [34].
1
Geofabrik: osm2shp (14.01.2010)
35
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.
[Gebietsname]_highway
Name des Shapefiles
Line Features
Typ
Beschreibung
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
1
Tabelle 12: Shapefiles von CloudMade
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.
3.4.2. 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
OpenStreetMap Loader [30]
Python-Skript
Ausgabeformat
GDB
Convert OpenStreetMap
Data [29]
C#
OSM2Shape [31]
Osmexport [155]
FME [45]
benutzerdefinierte
Einstellungen möglich
-
Quellcode
einsehbar
x
SHP
-
x
Avenue
(ArcView
Extension)
SHP
-
x
Ruby-Gem
SHP
x
x
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 ArcToolbox 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
Das Tool „Convert OpenStreetMap Data“ erzeugt ein Shapefile, in dem die Straßen aus den OSMDaten 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 RubyGem [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.
3.5. 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
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 geru38
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
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.
4.1. 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 OSMDaten 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 ParameterDatei 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 4.1.6 aufgelistet.
Mit den oben aufgelisteten Map Features, die in das Netzwerk aufgenommen werden, sollen alle in
ArcGIS 9.3.1 vorhandene Network Analyst Solvers (siehe Kapitel 2.3) durchgeführt werden können:

Route Solver

Service Area Solver
40

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.
roads
Feature Class Name
Feature Class Type
Line Features
Beschreibung
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
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 9.3.1
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ünster1 gewählt, da es eine mittlere Größe hat (die
Übersetzung eines großen Gebiets würde die Aufbereitung verlängern) und interessante FahrradMap Features und Abbiegevorschriften enthält. Um die Daten nicht gänzlich von Hand zu konvertieren, wurde das Ruby-Tool „Osmexport“ in der Version 0.1.4 (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
1
20.04.2010
42
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 306923)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, 4.1.3 und 4.1.4) und des Network Datasets (siehe Kapitel 4.1.5) beschrieben.
4.1.1. 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 XMLDatei 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>
1
20.04.2010
43
<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 3.2.2.2.1) 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.
<orderElement value="bicycle"/>
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 3.2.2.2.1 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
<listElementString
<listElementString
<listElementString
<listElementString
<listElementString
<listElementString
<listElementString
<listElementString
<listElementString
<listElementString
key="cycle_barrier" value="no"/>
key="block" value="no"/>
key="stoneblocks" value="no"/>
key="entrance" value="no"/>
key="gate" value="no"/>
key="lift_gate" value="no"/>
key="gate:lift" value="no"/>
key="stile" value="no"/>
key="yes" value="no"/>
key="small_fence" value="no"/>

</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):
Durch die Definition des Algorithmus zur Berechnung der Access-Restrictions (siehe Kapitel 3.2.2.2.1)
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"/>

Listing 14: Parameter access_barrier_restrictions_interpretation für motorcar
(Beispiel)
45
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:
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):
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 slowDown_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="small_fence" value="yes"/>
<listElementNoYes key="cattle_grid" value="no"/>

</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 barrier46
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 3.2.2.2.1). 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"/>
</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
<access_highway_restrictions_interpretation>
<listElementNoYes key="unknown" value="yes"/>

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
<tag
<tag
<tag
<tag
<tag
<tag
<tag
k="bicycle" v="yes"/>
k="cycleway" v="opposite"/>
k="highway" v="residential"/>
k="name" v="Turmstraße"/>
k="psv" v="yes"/>
k="surface" v="cobblestone"/>
k="taxi" v="yes"/>
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 3.2.2.2.1 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-AccessRestrictions 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:
Im dritten Schritt werden die expliziten Access-Restrictions aus dem aktuellen OSM-Way ausgelesen
und in den Hierachiebaum eingetragen. Dies sind:
<tag
<tag
<tag
<tag
k="bicycle" v="yes"/>
k="psv" v="yes"/>
k="taxi" v="yes"/>
k="vehicle" v="delivery"/>
48
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:
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 3.2.2.2.3 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-TagValue 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 aus49
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 (DefaultMaximalgeschwindigkeiten, siehe Kapitel 3.2.2.2.4). 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"/>

</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 3.2.2.2.4 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 un50
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="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"/>

</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 Ge51
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
<listElementFloat
<listElementFloat
<listElementFloat
<listElementFloat
</speed_highway_units>
key="km/h" value="1"/>
key="kmph" value="1"/>
key="kph" value="1"/>
key="mph" value="1.609"/>
key="knots" value="1.852"/>
Listing 22: Parameter speed_highway_units (Beispiel)
Der Key eines Listenelements enthält die Einheit, der Value den Umrechnungsfaktor in die StandardGeschwindigkeitseinheit 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
<length_highway_units>
<listElementFloat
<listElementFloat
<listElementFloat
<listElementFloat
<listElementFloat
</length_highway_units>
key="m" value="1"/>
key="metre" value="1"/>
key="metres" value="1"/>
key="ft" value="0.3048"/>
key="feet" value="0.3048"/>
Listing 23: Parameter length_highway_units (Beispiel)
Die Standard-Längeneinheit in OSM ist Meter (siehe Kapitel 3.2.2.2.5).
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 3.2.2.2.5).
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 slowDown_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 3.2.2.2.7). 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, 4.1.3 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
Source
transport_mode_hierarchy
Field
Ordnung
roads
access
barriers
access
access_barrier_restrictions
Liste
barriers
access
access_barrier_restrictons_interpretation
Liste
slowDown_barrier_restrictions
Liste
Generierung der Evaluators
Evaluator
Source
Barrier
barriers
53
slowDown
barriers
Parameter-Name
Typ
Befüllung der Fields
Source
Field
access_highway_restrictions
Liste
access_highway_restrictions_interpretation
Liste
oneway_highway_implications
Liste
roads
oneway
oneway_highway_interpretation
Fälle
roads
oneway
maxspeed_highway_implications
Liste
roads
maxspeed
avspeed_highway_implications
Liste
roads
avspeed
speed_highway_variables
Liste
roads
maxspeed
roads
Generierung der Evaluators
Evaluator
Source
access
Access
roads
SlowDown
roads
avspeed
speed_highway_units
Liste
roads
maxspeed
avspeed
length_highway_units
Liste
roads
maxheight
weight_highway_units
Liste
roads
maxweight
driveTime_slowDown_delay
Werte
barriers
Tabelle 15: Verwendung der Parameter
Des Weiteren wird der Parameter access_highway_restrictions_interpretation verwendet, um die Solver Layers anzupassen (siehe Kapitel 4.1.5).
4.1.2. Feature Class roads
Das Straßennetz wird aus den in der OSM-Datei enthaltenen Ways erzeugt, die ein highway-OSMTag 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
OBJECTID
Object ID
1, 2, …
von ArcGIS automatisch erzeugte Feature ID (Primärschlüssel)
Shape
Geometry
Polyline
id
Integer
8
Zahl
id des Ways
partID
Integer
8
0 (falls nicht
gesplittet),
> 0 (falls gesplittet)
partID des Ways
54
siehe
Kapitel
4.1.3
Field
Datentyp
Länge
mögliche Werte
Inhalt
siehe
Kapitel
3.2.2.1.1
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)
3.2.2.1.1
ref
Text
255
A1
Wert des ref-OSM-Tags
(Straßennummer)
3.2.2.1.1
access
Text
255
yes, no, destination, delivery, private,
agricultural, …
Ergebnis der Berechnung der
BeförderungsartBeschränkung
3.2.2.2.1
oneway
Text
255
yes, no, -1
Einbahnstraße
3.2.2.2.3
maxheight
Double
8
3.3, 2.5, …
Wert des maxheight-OSMTags in Metern (maximal erlaubte Fahrzeughöhe)
3.2.2.2.5
maxweight
Double
8
3.5, 4.2, …
Wert des maxweight-OSMTags in Tonnen (maximal erlaubtes Fahrzeuggewicht)
3.2.2.2.5
maxspeed
Double
8
30, 45.5
Höchstgeschwindigkeit in
km/h ohne Angabe der Einheit
3.2.2.2.4
avspeed
Double
8
30, 45.5
Durchschnittsgeschwindigekeit
in km/h ohne Angabe der Einheit
construct
Text
255
yes, no, minor,
…
Baustelle
3.2.2.2.2
proposed
Text
255
yes, no, …
geplante Straße
3.2.2.2.2
traffCalm
Text
255
yes, bumb,
cushion, …
Art der Verkehrsberuhigung
3.2.2.2.7
slowDown
Text
255
yes, no
Verkehrsberuhigung
3.2.2.2.7
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
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 3.2.2.2.1).
Wie in Kapitel 3.2.2.2.1 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.
Fall
1
2
highway-Wert
construction
highway-Field
unclassified
construc
tion-
Wert
-
construct-Field
proposed-
proposed-
Field
Wert
yes
-
no
*
proposed-
Wert
3
construction-
*
Wert
-
no
*
proposed-
Wert
4
5
6
proposed
unclassified
-
no
*
construction-
-
yes
Wert
7
8
proposed-Wert
-
no
*
construction-
*
Wert
9
10
*
highway-Wert
-
no
-
no
*
proposed-
Wert
*
11
12
construction-
-
no
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
3.2.2.2.1 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 TransportmittelHierarchie 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
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 4.1.1 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 3.2.2.1.3). 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.
4.1.3. Feature Class turns
Die Abbiegegebote und -verbote aus OSM werden aus den Relations ausgelesen, dessen type-OSMTag 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 3.2.2.2.9.
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 3.2.2.2.9).
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
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 303551, Münster)1
<relation id="303551" user="hugoe" uid="7426" visible="true" version="1"
<tag k="restriction" v="only_straight_on"/>
</relation>
Listing 26: Original-Abbiegegebot (Relation 303551, Münster)2
<relation id="" user=" " uid="" visible="true" version="1" changeset=""
timestamp="">
<tag k="restriction" v="no_left_turn"/>
</relation>
<relation id="" user=" " uid="" visible="true" version="1" changeset=""
timestamp="">
<tag k="restriction" v="no_right_turn"/>
</relation>
Listing 27: Umgewandeltes Abbiegegebot in Abbiegeverbote (Relation 303551, Münster)3
Bei der Umwandlung von Abbiegegeboten in -verbote muss die gesamte OSM-Datei nach Ways
durchsucht werden, die den Kreuzungsnode (hier: 277738640) enthalten. Neben den beiden am
Abbiegegebot beteiligten Ways (from: 5105730, Listing 28; to: 43181292, Listing 29) sollte mindestens noch ein weiterer Way existieren. (Andernfalls wäre ein Abbiegegebot nicht sinnvoll, da weder
1
20.04.2010
20.04.2010
3
20.04.2010
2
58
eine Einmündung noch eine Kreuzung existiert.) In diesem Beispiel gibt es zwei weitere Ways:
42181298 (Listing 30) und 43181293 (Listing 31).
<way id="5105730" user="hugoe" uid="7426" visible="true" version="8" changeset="2960899" timestamp="2009-10-26T21:48:59Z">
<nd ref="277727457"/>
<nd ref="34924699"/>
<nd ref="34924698"/>
<nd ref="277727508"/>
<nd ref="277738640"/>
<tag k="highway" v="trunk_link"/>
<tag k="name" v="Weseler Straße"/>
<tag k="source" v="survey"/>
</way>
Listing 28: from-Way des Abbiegegebots der Relation 303551 (Münster)1
<way id="43181292" user="hugoe" uid="7426" visible="true" version="1"
<nd ref="277738640"/>
<nd ref="277727511"/>
<nd ref="471016555"/>
<nd ref="277727487"/>
<nd ref="277727489"/>
<nd ref="277727491"/>
<nd ref="277727492"/>
<nd ref="277727495"/>
<nd ref="277727499"/>
<nd ref="277727502"/>
<nd ref="277727506"/>
<tag k="highway" v="trunk_link"/>
<tag k="source" v="survey"/>
</way>
Listing 29: to-Way des Abbiegegebots der Relation 303551 (Münster)2
<nd ref="277738641"/>
<nd ref="277738640"/>
<tag k="highway" v="primary"/>
<tag k="ref" v="B 219"/>
</way>
Listing 30: to-Way des umgewandelten Abbiegegebots in ein Links-Abbiegeverbot (Relation
303551, Münster)3
1
20.04.2010
20.04.2010
3
20.04.2010
2
59
<nd ref="277738640"/>
<nd ref="471016558"/>
<nd ref="277727444"/>
<tag k="ref" v="B 219"/>
</way>
Listing 31: to-Way des umgewandelten Abbiegegebots in ein Rechts-Abbiegeverbot (Relation
303551, Münster)1
Bei diesem Beispiel ist es nicht unbedingt notwendig, dass das Links-Abbiegeverbot erstellt wird, da
der Way 43181298 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 2.3.3 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.
1
20.04.2010
60
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
Abb. 19: Umwandlung eines Abbiegegebots in Abbiegeverbote mit Splitting (Relation 303554,
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) toWay 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:
1
20.04.2010
62

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.
OBJECTID
Field
Datentyp
Object ID
Länge
4
1, 2, …
mögliche Werte
SHAPE
Geometry
0
Polyline
von ArcGIS automatisch erzeugtes
Shape Field
Edge1End
String
1
Y
siehe Kapitel 2.3.3
Edge1FCID
Integer
4
1, 6, …
siehe Kapitel 2.3.3
Edge1FID
Integer
4
342, 1907, …
siehe Kapitel 2.3.3
Edge1Pos
Double
8
0, 1
siehe Kapitel 2.3.3
Edge2FCID
Integer
4
1, 6, …
siehe Kapitel 2.3.3
Edge2FID
Integer
4
344, 7166, …
siehe Kapitel 2.3.3
Edge2Pos
Double
8
0, 1
siehe Kapitel 2.3.3
SHAPE_Length
Double
8
0.00036, …
automatisch erzeugte Länge der Polyline (Einheit Decimal Degrees)
restrict
String
255
no_left_turn,
no_right_turn,
no_u_turn, no
Art des Abbiegeverbots
rel_id
Integer
8
303551, …
ID der Relation, auf der das Abbiegeverbot basiert.
63
Inhalt
von ArcGIS automatisch erzeugte
Feature ID (Primärschlüssel)
fromnode
Field
Datentyp
Integer
Länge
8
277727508, …
mögliche Werte
from-Node-id
Inhalt
vianode
Integer
8
277738640, …
via-Node-id
tonode
Integer
8
277738641, …
to-Node-id
fromway
Integer
8
5105730, …
from-Way-id
toway
Integer
8
43181298, …
to-Way-id
Tabelle 18: Feature Class turns
4.1.4. 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 OSMTag traffic_calming definiert. Wie schon in Kapitel 4.1.1 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
OBJECTID
Object ID
1, 2, …
von ArcGIS automatisch erzeugte Feature ID (Primärschlüssel)
Shape
Geometry
Point
id
Integer
8
Zahl
id des Nodes
barrier
Text
255
bollard, gate, no,
…
traffCalm
Text
255
bump, cushion,
yes, no
Art der Barriere,
Wert des barrier-OSM-Tags
oder no
Art der Verkehrsberuhigung,
siehe Kapitel
3.2.2.2.8
3.2.2.2.7
Wert des traffic_calmingOSM-Tags oder no
access
Text
255
yes, no, destination, delivery,
private, agricultural, …
Ergebnis der Berechnung der
Beförderungsart-Beschränkung
slowDown
Text
255
yes, no
Verkehrsberuhigung
3.2.2.2.5
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
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 3.2.2.2.1 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.
4.1.5. 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
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.
roads
Source
Connectivity Policy
Any Vertex
1
Connectivity Group
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
Zugangsbeschränkungen für bestimmte
Straßentypen
Network Attribute
Access
roads
x
in Planung oder im Bau befindliche Straßen
Closed
x
Einbahnstraßen
Oneway
x
Abbiegeverbote
TurnRestriction
maximal erlaubte Fahrzeughöhe
HeightRestriction
x
maximal erlaubtes Fahrzeuggewicht
WeightRestriction
x
Barrieren
Barriers
barriers
turns
x
x
Tabelle 22: Restriktionen im Network Dataset
Tabelle 23 zeigt eine Übersicht über die Kosten.
Cost
Straßenlänge
Network Attribute
Length
Fahrtzeit
DriveTime
roads
x
barriers
x
x
turns
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
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
roads
Fields
Access
access
Closed
construct
proposed
Network Dataset
Parameters
HeightRestriction
MaxHeight
maxheight
Height
maxweight
Weight
WeightRestriction
MaxWeight
Oneway
oneway
Length
SHAPE
DriveTime
SlowDown
slowDown
Length
SHAPE
Speed
barriers
AvSpeed
avspeed
MaxSpeed
maxspeed
DriveTime
SlowDown
slowDown
Barrier
turns
access
TurnRestriction
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
Access
Restriction
Unknown
Boolean
AvSpeed
Descriptor
Unknown
Double
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
Use by Default
True
False
True
False
Name
Usage
Units
Data Type
Use by Default
True
False
False
MaxSpeed
Descriptor
Unknown
Double
MaxWeight
Descriptor
Unknown
Double
Oneway
Restriction
Unknown
Boolean
SlowDown
Descriptor
Unknown
Boolean
False
Speed
Cost
Unknown
Double
False
TurnRestriction
Restriction
Unknown
Booelan
True
WeightRestriction Restriction
Unknown
Boolean
True
False
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 4.1.1.
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
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
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 highwaySlowDownFactor 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 = 0.001
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 4.1.1 beschrieben, können Barrieren auch eine Fahrtzeitverlängerung bewirken.
Da man aber bei Barrieren keine schon bestehende Fahrtzeit mit einem Faktor multiplizieren kann,
70
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
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 4.1.1.
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
Attribute
Access
Source
roads
Direction
From-To
Type
Field
Value
<expression>
Listing
Listing 32
Field
avspeed
Field
<expression>
Listing 41
Field
<expression>
Listing 33
VBScript
<expression>
Listing 36
VBScript
<expression>
Listing 38
Function
MaxHeight <
Height
Field
SHAPE
Field
maxheight
Field
maxspeed
Field
maxweight
From-To
Field
<expression>
Listing 39
To-From
Field
<expression>
Listing 40
From-To
Field
<expression>
Listing 35
Field
<expression>
Listing 37
VBScript
<expression>
Listing 34
Constant
Restricted
Function
MaxWeight <
Weight
To-From
AvSpeed
roads
From-To
To-From
Barrier
barriers
Closed
roads
From-To
To-From
DriveTime
roads
From-To
To-From
barriers
HeightRestriction
roads
From-To
To-From
Length
roads
From-To
To-From
MaxHeight
roads
From-To
To-From
MaxSpeed
roads
From-To
To-From
MaxWeight
roads
From-To
To-From
Oneway
SlowDown
roads
roads
To-From
barriers
Speed
roads
From-To
To-From
TurnRestriction
turns
WeightRestriction roads
From-To
To-From
Tabelle 26: Network Attributes Evaluators (Source Values)
Wie schon in Kapitel 2.3.5 erwähnt, ist es in ArcGIS 9.3.1 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 fal73
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 SQLAnweisung 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 elseWert vom Anwender auf yes oder no gesetzt werden. Dies muss bei der Definition der WHEREClause 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.
4.1.6. 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 2.3.5.
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
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 ESRIDatenformaten für Netzwerkanalysen in ArcGIS geeignet sind.
4.2.1. 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:

(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.
4.2.2. 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

Referenz der Straße (ref) für Webbeschreibungen

(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.
4.2.3. 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.
4.2.4. Zusammenfassung der Evaluierung
Zusammenfassend kann gesagt werden, dass man theoretisch mit allen OSM-Daten in ESRIDatenformaten 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
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.
4.3. 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 JavaBibliotheken (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 9.3.1 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
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
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
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 UMLDiagrammen 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 Ver80
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
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
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
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 (OSMWay) 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 addPoint() 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 insertFeatureValue() 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
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
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
Abb. 38: Schritt 16: Hinzufügen der Feature Classes zum Map Document
Zum Schluss werden im letzten Schritt (17) die in ArcGIS 9.3.1 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.
4.4. 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
4.4.1. 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-WMSDienst (Web Map Service) [170] der WhereGroup [169] in den Hintergrund gelegt.
Routingdienst
Länge in km
Zeit in min
?
?
Kategorie
A
B
C
C
1,5
2
A
?
?
OSM2NetworkDataset
1,7
2
1,7
2
OpenRouteService
CloudMade
YourNavigation
88
Abbildung
Abb. 40
Abb. 41
B
Abb. 42
A
Abb. 43
C
Abb. 44
Routingdienst
Länge in km
Zeit in min
European Route Finder Tele Atlas
1,7
2
Kategorie
A
B
C
C
NAVTEQ Map24
1,61
2
A
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)2
1
2
14.06.2010
14.06.2010
89
Abbildung
Abb. 45
Abb. 46
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)3
1
14.06.2010
20.04.2010
3
2009
2
90
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.
1
2
14.06.2010
14.06.2010
91
4.4.2. 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
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)1
1
14.06.2010
92
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
2
ESRI StreetMap Premium Teleatlas: 2009
OSM2NetworkDataset: 20.04.2010
93
4.4.3. 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)2
1
2
20.04.2010
2009
94
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 NetzwerkanalyseDaten angenommen wurden.
4.4.4. 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.
4.5. 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 OSMDaten für seinen Anwendungsbereich, sein Vorhaben sinnvoll sind.
95
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
4.1.6 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
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
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) .................... 11
Abb. 5: Vergleich OpenStreetMap - Google Maps, Thuwal, Saudi-Arabien .......................................... 15
Abb. 6: Vergleich OpenStreetMap - Google Maps, Formosa, Brasilien ................................................ 15
Abb. 7: Beispiel für Zugangsbeschränkung (Freising, Fußweg Am Schwimmbad) ................................ 22
Abb. 8: Transportmittel-Hierarchie ....................................................................................................... 22
Abb. 9: Deutsche Default-Tabelle für Transportmittelbeschränkungen ............................................... 23
Abb. 10: Barriere Schlagbaum ............................................................................................................... 31
Abb. 11: Links-Abbiegeverbot (Freising, Goethestraße – Plantagenweg)............................................ 32
Abb. 12: Export von OSM-Daten im OSM-XML-Format ........................................................................ 34
Abb. 13: Struktur der Geodatabase....................................................................................................... 41
Abb. 14: Workflow der Anwendung ...................................................................................................... 42
Abb. 15: Routing auf manuell erstelltem Netz in Münster (Abbiegeverbot 306923) ........................... 43
Abb. 16: Umwandlung eines Abbiegegebots in Abbiegeverbote (Relation 303551, Münster) ............ 58
Abb. 17: Zuweisung der Edge-Positionen.............................................................................................. 61
Abb. 18: Theoretische Zuweisung der Edge Positions bei ungesplitteten Edges .................................. 61
Abb. 19: Umwandlung eines Abbiegegebots in Abbiegeverbote mit Splitting (Relation 303554,
Münster) ................................................................................................................................................ 62
Abb. 20: Verwendete Nodes für die grafische Darstellung eines Abbiegeverbots ............................... 63
Abb. 21: Grafische Oberfläche der Anwendung .................................................................................... 78
Abb. 22: Legende der Flussdiagramme ................................................................................................. 79
Abb. 23: Schritt 1: Einlesen der Parameter-Datei ................................................................................. 79
Abb. 24: Schritt 2: Einlesen der OSM-Datei........................................................................................... 79
Abb. 25: Schritt 3: Erstellung der GDB .................................................................................................. 80
Abb. 26: Schritt 4: Festlegung des geografischen Raumbezugs ............................................................ 81
Abb. 27: Schritt 5: Erstellung des Feature Datasets .............................................................................. 81
Abb. 28: Schritt 6: Initialisierung der Feature Classes roads, pois und barriers.................................... 81
Abb. 29: Schritt 7: Initialisierung des Network Datasets mit den Network Junctions .......................... 82
Abb. 30: Schritt 8: Initialisierung der Turn Feature Class turns............................................................. 83
Abb. 31: Schritt 9: Network Attribute" „TurnRestriction" zum Network Dataset hinzufügen ............. 83
Abb. 32: Schritt 10: Generierung der Abbiegeverbote (mit Splitting der Straßen)............................... 83
Abb. 33: Schritt 11: Befüllung der Feature Class roads ......................................................................... 85
Abb. 34: Schritt 12: Befüllung der Turn Feature Class turns ................................................................. 85
Abb. 35: Schritt 13: Befüllung der Feature Class pois ........................................................................... 86
Abb. 36: Schritt 14: Befüllung der Feature Class barriers ..................................................................... 86
Abb. 37: Schritt 15: Erzeugung des Map Documents ............................................................................ 86
Abb. 38: Schritt 16: Hinzufügen der Feature Classes zum Map Document .......................................... 87
Abb. 39: Schritt 17: Hinzufügen der Network Analyst Solver Layer zum Map Document .................... 87
Abb. 40: Routing in Münster mit OpenRouteService (Auto, schnellste Verbindung) ........................... 89
Abb. 41: Routing in Münster mit CoudMade (Auto, schnellste Verbindung) ....................................... 89
Abb. 42: Routing in Münster mit YourNavigation (Auto, schnellste Verbindung) ................................ 90
Abb. 43: Routing in Münster mit OSM2NetworkDataset (Auto, schnellste Verbindung) ..................... 90
X
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) .... 91
Abb. 46: Routing in Münster mit NAVTEQ Map24 (Auto, schnellste Verbindung) ............................... 91
Abb. 47: Routing in Münster mit OpenRouteService und YourNavigation (Fahrrad, kürzeste
Verbindung) ........................................................................................................................................... 92
Abb. 48: Routing in Münster mit ESRI StreetMap Premium Teleatlas und OSM2NetworkDataset
(Fahrrad, kürzeste Verbindung) ............................................................................................................ 93
Abb. 49: Erreichbarkeitsanalyse um den Bahnhof Münster mit OSM2NetworkDataset (Auto, drei
Minuten) ................................................................................................................................................ 94
Abb. 50: Erreichbarkeitsanalyse um den Bahnhof Münster mit ESRI StreetMap Premium Teleatlas
(Auto, drei Minuten).............................................................................................................................. 94
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
Tabellenverzeichnis
Tabelle 1: Zuweisung von Connectivity Groups ...................................................................................... 7
Tabelle 2: Network Attributes: Erlaubte Units und Data Types pro Usage Type .................................. 10
Tabelle 3: Schema der Turn Feature Class ............................................................................................ 12
Tabelle 4: Fahrradwege (Schlüssel cycleway) ................................................................................... 20
Tabelle 5: Wichtigste Verkehrsbeschränkungen ................................................................................... 21
Tabelle 6: Wichtigste Oneway-Werte ................................................................................................... 26
Tabelle 7: Geschwindigkeitseinheiten................................................................................................... 27
Tabelle 8: Größen- und Gewichtsbeschränkungen ............................................................................... 29
Tabelle 9: Verkehrsberuhigung (OSM-Schlüssel: traffic_calming) ............................................ 30
Tabelle 10: Abbiegevorschriften: Werte für das OSM-Tag restriction ........................................ 32
Tabelle 11: Shapefiles der Geofabrik .................................................................................................... 35
Tabelle 12: Shapefiles von CloudMade ................................................................................................. 36
Tabelle 13: Tools und Skripte zur Konvertierung von OSM-Daten in ESRI-Datenformate.................... 36
Tabelle 14: Feature Classes in der GDB ................................................................................................. 41
Tabelle 15: Verwendung der Parameter ............................................................................................... 54
Tabelle 16: Feature Class roads ............................................................................................................. 55
Tabelle 17: Theoretisch mögliche Kombinationsfälle für die Schlüssel highway, construction
und proposed..................................................................................................................................... 56
Tabelle 18: Feature Class turns ............................................................................................................. 64
Tabelle 19: Feature Class barriers ......................................................................................................... 64
Tabelle 20: Network Dataset Sources ................................................................................................... 65
Tabelle 21: Connectivity-Einstellungen ................................................................................................. 66
Tabelle 22: Restriktionen im Network Dataset ..................................................................................... 66
Tabelle 23: Kosten im Network Dataset ................................................................................................ 66
Tabelle 24: Übersicht über die Network Attributes und ihre Unterattribute ....................................... 67
Tabelle 25: Network Attributes ............................................................................................................. 68
Tabelle 26: Network Attributes Evaluators (Source Values) ................................................................. 73
Tabelle 27: Vergleich von Routingdiensten ........................................................................................... 89
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
Listings
Listing 1: Beispiel für eine Straße (Freising) .......................................................................................... 19
Listing 2: Beispiel für Zugangsbeschränkung (Freising, Fußweg Am Schwimmbad) ............................. 21
Listing 3: Geplante Straße mit proposed-OSM-Tag (Münster) ......................................................... 24
Listing 4: Geplante Straße ohne proposed-OSM-Tag (Münster) ....................................................... 24
Listing 5: Im Bau befindliche Straße (Freiburg) ..................................................................................... 25
Listing 6: Explizite Geschwindigkeitsbegrenzung in km/h (Freising) ..................................................... 27
Listing 7: Geschwindigkeitsbeschränkung über Variable (Freiburg) ..................................................... 28
Listing 8: Beispiel für Maximalhöhe ...................................................................................................... 29
Listing 9: Links-Abbiegeverbot (Freising, Goethestraße – Plantagenweg)............................................ 31
Listing 10: Aufbau der Parameter-Datei (XML) ..................................................................................... 44
Listing 11: Parameter transport_mode_hierarchy für motorcar und Deutschland ............ 44
Listing 12: Parameter transport_mode_hierarchy für bicycle und Deutschland............... 44
Listing 13: Parameter access_barrier_restrictions für motorcar (Beispiel).................. 45
Listing 14: Parameter access_barrier_restrictions_interpretation für motorcar
(Beispiel) ................................................................................................................................................ 45
Listing 15: Parameter slowDown_barrier_restrictions für motorcar (Beispiel) ............. 46
Listing 16: Parameter access_highway_restrictions für motorcar (Beispiel).................. 47
Listing 17: Parameter access_highway_restrictions_interpretation für motorcar
(Beispiel) ................................................................................................................................................ 48
Listing 18: Prinzipieller Aufbau des Parameters onway_highway_implications..................... 49
Listing 19: Parameter maxspeed_highway_implications für motorcar (Beispiel) ............. 50
Listing 20: Parameter avspeed_highway_implications für motorcar (Beispiel) ............... 51
Listing 21: Parameter speed_highway_variables für motorcar (Beispiel) ........................... 52
Listing 22: Parameter speed_highway_units (Beispiel) .............................................................. 52
Listing 23: Parameter length_highway_units (Beispiel) ............................................................ 53
Listing 24: Parameter weight_highway_units (Beispiel) ............................................................ 53
Listing 25: Parameter driveTime_slowDown_delay für motorcar (Beispiel) ......................... 53
Listing 26: Original-Abbiegegebot (Relation 303551, Münster)............................................................ 58
Listing 27: Umgewandeltes Abbiegegebot in Abbiegeverbote (Relation 303551, Münster) ............... 58
Listing 28: from-Way des Abbiegegebots der Relation 303551 (Münster) ......................................... 59
Listing 29: to-Way des Abbiegegebots der Relation 303551 (Münster) .............................................. 59
Listing 30: to-Way des umgewandelten Abbiegegebots in ein Links-Abbiegeverbot (Relation 303551,
Münster) ................................................................................................................................................ 59
Listing 31: to-Way des umgewandelten Abbiegegebots in ein Rechts-Abbiegeverbot (Relation
303551, Münster) .................................................................................................................................. 60
Listing 32: Network Attribute "Access" Evaluator (roads, FROM-TO und TO-FROM, Beispiel) ............ 68
Listing 33: Network Attribute "Closed" (roads, FROM-TO und TO-FROM) ........................................... 68
Listing 34: Network Attribute "Speed" (roads, FROM-TO und TO-FROM) ............................................ 70
Listing 35: Network Attribute "SlowDown" (roads, FROM-TO und TO-FROM)..................................... 70
Listing 36: Network Attribute "DriveTime" (roads, FROM-TO und TO-FROM, Beispiel) ....................... 70
Listing 37: Network Attribute "SlowDown" (barriers)........................................................................... 71
Listing 38: Network Attribute "DriveTime" (barriers, Beispiel) ............................................................. 71
Listing 39: Network Attribute "Oneway" (roads, FROM-TO) ................................................................ 72
XIII
Listing 40: Network Attribute "Oneway" (roads, TO-FROM) ................................................................ 72
Listing 41: Network Attribute "Barrier" (barriers, Beispiel) .................................................................. 72
Listing 42: WHERE-Clause der Network Source roads beim Laden der Network Locations ................. 74
Listing 43: Einlesen und Validierung der Parameter-Datei (stark vereinfacht) ..................................... 80
Listing 44: Initialisierung der Turn Feature Class turns ......................................................................... 82
Listing 45: Erstellung einer Polyline....................................................................................................... 84
Listing 46: Befüllung eines Fields........................................................................................................... 84
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
Index
Access-Restriction ................................................................................................................................................. 21
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 ................................................................................................................................................ 14
Creative Commons Attribution-Share Alike 2.0 ................................................................................................ 14
Creative Commons Attribution-Share Alike 2.0 ................................................................ 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 ........................................................................................................................................... 10
Field Evaluator .................................................................................................................................................. 10
Field Expression Evaluator ................................................................................................................................ 10
Function Evaluator ............................................................................................................................................ 10
Global Turn Delay Evaluator ............................................................................................................................. 11
VBScript Evaluator ............................................................................................................................................ 11
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 ........................................................................................................................ 77
XV
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 ....................................................................................................................................................... 15
Maplint .................................................................................................................................................................. 16
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 ................................................................................................................................ 13
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 ...................................................................................................................................................................... 17
OD Cost Matrix ........................................................................................................... Siehe Network Analyst Solver
OECD ...................................................................................................................................................................... IX
OpenStreetBugs .................................................................................................................................................... 16
OpenStreetMap-Wiki ............................................................................................................................................ 16
ORS ......................................................................................................................................................................... IX
OSM........................................................................................................................................................................ IX
OSM Inspector....................................................................................................................................................... 16
Osmarender ...................................................................................................................................... Siehe Renderer
OSM-Tag ................................................................................................................................................................ 17
OSM-Wiki ....................................................................................................................... Siehe OpenStreetMap-Wiki
POI .......................................................................................................................................................................... IX
Point Feature Class ............................................................................................................................................... XIX
Problem des Handlungsreisenden ....................................................................................... Siehe Netzwerkanalyse
Reisendenproblem ............................................................................................................... Siehe Netzwerkanalyse
Relation ................................................................................................................................................................. 17
Renderer ........................................................................................................................................................ 16, XIX
XVI
Mapnik .............................................................................................................................................................. 16
Osmarender ...................................................................................................................................................... 16
Restriction ............................................................................................................................................................. 20
Routenplanung ..................................................................................................................... Siehe Netzwerkanalyse
Routing ................................................................................................................................. Siehe Netzwerkanalyse
Ruby ...................................................................................................................................................................... 37
RubyGem ............................................................................................................................................................... 37
Rundreiseproblem................................................................................................................ Siehe Netzwerkanalyse
Service Area ............................................................................................................... Siehe Network Analyst Solver
Shapefile............................................................................................................................................................... XIX
Tagging ........................................................................................................................................................... 14, XIX
Transport Mode Restriction .................................................................................................................................. 21
Traveling Salesman Problem ................................................................................................ Siehe Netzwerkanalyse
Turn ....................................................................................................................................................................... 11
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 ....................................................................................................................................................................... 17
Wildcard ......................................................................................................................................................... 49, XIX
WMS ....................................................................................................................................................................... IX
XML ........................................................................................................................................................................ IX
XML Schema .......................................................................................................................................................... 42
XSD .............................................................................................................................................. Siehe XML Schema
XVII
Glossar
Crowdsourcing
Auslagerung der Arbeit auf die Arbeitskraft und
Intelligenz von vielen Freizeitarbeitern
Collaborative Effort
Gemeinschaftsarbeit
Connectivity
Art der Verknüpfung von Netzwerkelmenten
im Network Analyst
Connectivity Group
Gruppierung von Netzwerkelementen zur Modellierung der Connectivity im Network Analyst
Connectivity Policy
Regel im Network Analyst, wie Line Features mit
Point Features verknüpft werden
Directions
Sammlung von Attributen im Network Analyst zur
Erstellung einer Wegbeschreibung
Edge
Kante/Segment in einem Netzwerk,
Netzwerkelement
Edge (Feature) Source
Line Feature Class in ArcGIS,
die Edges eines Netzwerks enthält
Elevation Field
Elevation Fields dienen im Network Analyst
zur Verfeinerung der Connectivity an Endpunkten
von Edges
Evaluator
Bewerter zur Bewertung von
Netzwerkelementen im Network Analyst
Feature Dataset
Container für Feature Classes in einer Geodatabase von ArcGIS zur Definition eines einheitlichen
Raumbezugs
Global Turns
Abbiegesituationen im Network Analyst, für die
kein eigenes Turn Feature in einer Turn Feature
Class definiert ist
Heap Size
allokierter Speicher der Java VM
Impedance
Kosten, Widerstand in einem Netzwerk
Junction
siehe Network Junction
Junction (Feature) Source
Point Feature Class in ArcGIS,
die Junctions eines Netzwerks enthält
Line Feature Class
Feature Class in ArcGIS,
die linienhafte Daten enthält
Multimodales Netz
Netzwerk mit mehreren Verkehrsmitteln
Network Dataset
Sammlung von topologisch verbundenen Netzwerkelementen im Network Analyst mit Kanten,
Knoten und Abbiegevorschriften in einem ungerichteten Netzwerk
XVIII
Network Attribute
Eigenschaft von Netzwerkelementen im Network
Analyst, die die Passierbarkeit kontrolliert
Network Junction
Endpunkt oder Kreuzungspunkt von Kanten
in einem Netzwerk, Netzwerkelement
Point Feature Class
Feature Class in ArcGIS,
die punkthafte Daten enthält
Renderer
im Zusammenhang mit OSM:
Anwendung zum Rendern/Visualisieren
von Kartendaten
Shapefile
Geodatenformat von ESRI
Tagging
Erfassung von Geodaten in OSM
Turn Feature
Feature im Network Analyst,
das ein Abbiegeverbot repräsentiert
Turn Feature Class
Feature Class, die Turn Features enthält
Unified Modeling Language
Sprache, die u.a. zur Modellierung von Software
verwendet wird
Unified Network for Transportation
Netzwerk-Datenmodell für Transportnetze
Unmarshalling
im Zusammenhang mit XML-Dateien und Java:
Umwandlung von XML-Daten in Java-Objekte
User Generated Content
nutzergenerierter Inhalt
Volunteered Geographic Information
Erfassung von Geodaten durch Freiwillige
Wildcard
Platzhalter für Zeichen
XIX
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. 50-52. 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 2010.
[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.
1417-1421.
[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
[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.
18-32, 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
http://webhelp.esri.com/arcgisdesktop/9.3/
[19] ArcGIS Desktop 9.3 Help – Geoprocessing Tools
http://webhelp.esri.com/arcgisdesktop/9.3/index.cfm?TopicName=Geoprocessing_tools
21.06.2010
[20] ArcGIS Desktop 9.3 Help – Setting Directions
http://webhelp.esri.com/arcgisdesktop/9.3/index.cfm?TopicName=Setting_directions
21.06.2010
[21] ArcGIS Desktop 9.3 Help – Turns in the network dataset
http://webhelp.esri.com/arcgisdesktop/9.3/index.cfm?TopicName=Turns_in_the_network_da
taset
28.04.2010
[22] ArcGIS Desktop 9.3 Help – Types of network analyses
http://webhelp.esri.com/arcgisdesktop/9.3/index.cfm?id=4427&pid=4426&topicname=Types_
of_network_analyses
11.06.2010
[23] ArcGIS Desktop 9.3 Help – Types of evaluators used by a network
http://webhelp.esri.com/arcgisdesktop/9.3/index.cfm?TopicName=Types_of_evaluators_used
_by_a_network
24.03.2010
[24] ArcGIS Desktop 9.3 Help – Understanding connectivity
http://webhelp.esri.com/arcgisdesktop/9.3/index.cfm?TopicName=Understanding_connectivit
y
12.06.2010
[25] ArcGIS Desktop 9.3 Help – Understanding the network attribute
http://webhelp.esri.com/arcgisdesktop/9.3/index.cfm?TopicName=Understanding_the_netwo
rk_attribute
24.03.2010
[26] ArcGIS Desktop 9.3 Help – Using parameters with network attributes
http://webhelp.esri.com/arcgisdesktop/9.3/index.cfm?TopicName=Using_parameters_with_n
etwork_attributes
24.03.2010
[27] ArcGIS Online – Ressource Centers
http://resources.esri.com/arcgisonlineservices/
XXI
[28] ArcGIS Online – Using standard routing tasks
http://resources.esri.com/help/9.3/arcgisonline/about/start.htm#free_routing.htm#
14.06.2010
[29] ArcScripts - Convert OpenStreetMap Data
http://arcscripts.esri.com/details.asp?dbid=16531
17.06.2010
[30] ArcScripts - OpenStreetMap Loader
17.06.2010
[31] ArcSripts – OSM2Shape
17.06.2010
[32] CloudMade
http://cloudmade.com/
07.06.2010
[33] CloudMade – About
http://cloudmade.com/about
17.06.2010
[34] CloudMade – Downloads
http://downloads.cloudmade.com/
17.06.2010
[35] CoudMade – Downloads: Germany
http://downloads.cloudmade.com/europe/germany/germany.shapefiles.zip
08.03.2010
[36] CloudMade – Maps
http://maps.cloudmade.com/
14.06.2010
[37] Creative Commons
http://creativecommons.org/
05.06.2010
[38] Creative Commons – Creative Commons Attribution-Share Alike 2.0
http://creativecommons.org/licenses/by-sa/2.0/de/
05.06.2010
[39] derStandard.at
http://derstandard.at/
[40] derStandard.at – Interview mit Steve Coast
http://derstandard.at/1246542045463/Ja-ich-wuerde-OpenStreetMap-mit-Wikipediavergleichen
13.07.2009
[41] ESRI Deutschland
http://www.esri-germany.de/
XXII
[42] ESRI Deutschland – Elemente der Geodatabase
http://www.esri-germany.de/products/arcgis/geodatabase/elements.html
25.06.2010
[43] ESRI Deutschland – Erweiterung Network Analyst
http://www.esri-germany.de/products/arcgis/extensions/networkanalyst/index.html
11.06.2010
[44] ESRI Deutschland – ArcAktuell Ausgabe 4/2001, Management multimodaler Verkehrssystem
http://www.esri-germany.de/downloads/arcaktuell/aa_4_2001.pdf
[45] FME
http://www.conterra.de/de/software/fme/index.shtm
17.06.2010
[46] Geofabrik
http://www.geofabrik.de/
07.06.2010
[47] Geofabrik – Download
http://download.geofabrik.de/
http://www.geofabrik.de/data/download.html
07.06.2010
[48] Geofabrik – Map Compare
http://tools.geofabrik.de/mc/
05.06.2010
[49] Google Maps
http://maps.google.de/
05.06.2010
[50] JAXB
https://jaxb.dev.java.net/
[51] JAXB – Unmarshalling
https://jaxb.dev.java.net/tutorial/section_3_1-Unmarshalling-and-Using-theData.html#Unmarshalling%20and%20Using%20the%20Data
13.06.2010
[52] LOGIBALL
http://www.logiball.de/
16.06.2010
[53] Mapnik
http://mapnik.org/
05.06.2010
[54] NAVLOG
http://www.navlog.de/
22.06.2010
[55] NAVTEQ
http://www.navteq.com/
XXIII
http://corporate.navteq.com/deutsch/index.html
16.06.2010
[56] NAVTEQ – Global Coverage Statistics
http://corporate.navteq.com/globalcoveragestats/index.html
16.06.2010
[57] OpenCycleMap
http://www.opencyclemap.org/
05.06.2010
[58] OpenRouteService
http://www.openrouteservice.org/
14.06.2010
[59] OpenStreetBugs
http://openstreetbugs.appspot.com/
13.06.2010
[60] OSM (de)
http://www.openstreetmap.de/
[61] OSM (de) – FAQ, Lizenz
http://www.openstreetmap.de/faq.html#lizenz
05.06.2010
[62] OSM (de) – Presse
http://www.openstreetmap.de/presse/2008-06-25-mapmaker.html
05.06.2010
[63] OSM (org)
http://www.openstreetmap.org/
[64] OSM (org) – Browse, Node 500098704
http://www.openstreetmap.org/browse/node/500098704
07.04.2010
[65] OSM (org – Browse, Way 41036076
http://www.openstreetmap.org/browse/way/41036076
07.04.2010
[66] OSM (org) – OpenStreetMap stats report
http://www.openstreetmap.org/stats/data_stats.html
07.06.2010
[67] OSM Inspector
http://tools.geofabrik.de/osmi/
13.06.2010
[68] OSM Restriction Analyser
http://osm.virtuelle-loipe.de/restrictions/
27.05.2010
[69] OSM-Wiki
http://wiki.openstreetmap.org/wiki/
XXIV
[70] OSM-Wiki – API v0.6
http://wiki.openstreetmap.org/wiki/API_v0.6
08.04.2010
[71] OSM-Wiki – API v0.6/DTD
http://wiki.openstreetmap.org/wiki/API_v0.6/DTD
08.04.2010
[72] OSM-Wiki – Bicycle
http://wiki.openstreetmap.org/wiki/Bicycle
01.06.2010
[73] OSM-Wiki – Computing_access_restrictions
http://wiki.openstreetmap.org/wiki/Computing_access_restrictions
31.03.2010
[74] OSM-Wiki – Computing access restrictions, Algorithm
http://wiki.openstreetmap.org/wiki/Computing_access_restrictions#Algorithm
31.03.2010
[75] OSM-Wiki – Computing access restrictions, Parameters
http://wiki.openstreetmap.org/wiki/Computing_access_restrictions#Parameters
31.03.2010
[76] OSM-Wiki – Computing access restrictions, Transport mode hierarchy
http://wiki.openstreetmap.org/wiki/Computing_access_restrictions#Transport_mode_hierarc
hy
31.03.2010
[77] OSM-Wiki – Country code
http://wiki.openstreetmap.org/wiki/Country_code
16.04.2010
[78] OSM-Wiki – Database schema
http://wiki.openstreetmap.org/wiki/Database_schema
08.04.2010
[79] OSM-Wiki – Data Primitives
http://wiki.openstreetmap.org/wiki/Data_Primitives
08.04.2010
[80] OSM-Wiki – DE: Bicycle/Wege oder Route
http://wiki.openstreetmap.org/wiki/DE:Bicycle/Weg_oder_Route
12.04.2010
[81] OSM-Wiki – DE: Bicycle/Wege oder Route, Radroute
http://wiki.openstreetmap.org/wiki/DE:Bicycle/Weg_oder_Route#Radroute
12.04.2010
[82] OSM-Wiki – DE: Key: access
http://wiki.openstreetmap.org/wiki/DE:Key:access
31.03.2010
XXV
[83] OSM-Wiki – DE: Key: access, Bezogen auf den Transporttyp
http://wiki.openstreetmap.org/wiki/DE:Key:access#Bezogen_auf_den_Transporttyp
19.04.2010
[84] OSM-Wiki – DE: Key: access, Größen- und Gewichtseinschränkungen
http://wiki.openstreetmap.org/wiki/DE:Key:access#Gr.C3.B6.C3.9Fen_und_Gewichtseinschr.C3.A4nkungen
07.06.2010
[85] OSM-Wiki – DE: Key: highway
http://wiki.openstreetmap.org/wiki/DE:Key:highway
09.04.2010
[86] OSM-Wiki – DE: Key: oneway, Verwendung
http://wiki.openstreetmap.org/wiki/DE:Key:oneway#Verwendung
31.03.2010
[87] OSM-Wiki – DE: Map Features
http://wiki.openstreetmap.org/wiki/DE:Map_Features
09.04.2010
[88] OSM-Wiki – DE: Map Features, Barrieren
http://wiki.openstreetmap.org/wiki/DE:Map_Features#Barrieren
07.04.2010
[89] OSM-Wiki – DE: Map Features, Beschränkungen
http://wiki.openstreetmap.org/wiki/DE:Map_Features#Beschr.C3.A4nkungen
31.03.2010
[90] OSM-Wiki – DE: Map Features, Fahrradwege
http://wiki.openstreetmap.org/wiki/DE:Map_Features#Fahrradwege
08.04.2010
[91] OSM-Wiki – DE: Map Features, Wege
http://wiki.openstreetmap.org/wiki/DE:Map_Features#Wege
09.04.2010
[92] OSM-Wiki – DE: Relation: restriction
http://wiki.openstreetmap.org/wiki/DE:Relation:restriction
01.04.2010
[93] OSM-Wiki – DE: Relation: restriction, Anmerkungen
http://wiki.openstreetmap.org/wiki/DE:Relation:restriction#Anmerkungen
01.04.2010
[94] OSM-Wiki – DE: Relation: restriction, Ausnahme von Fahrzeugtypen
http://wiki.openstreetmap.org/wiki/DE:Relation:restriction#Ausnahme_von_Fahrzeugtypen
01.04.2010
[95] OSM-Wiki – DE: Relation: restriction, Hinweis zur Beschilderung
http://wiki.openstreetmap.org/wiki/DE:Relation:restriction#Hinweis_zur_Beschilderung
01.04.2010
XXVI
[96] OSM-Wiki – DE: Relation: restriction, Mindestanforderung
http://wiki.openstreetmap.org/wiki/DE:Relation:restriction#Mindestanforderung
01.04.2010
[97] OSM-Wiki – DE: Relation: restriction, Zeitliche Beschränkungen
http://wiki.openstreetmap.org/wiki/DE:Relation:restriction#Zeitliche_Beschr.C3.A4nkungen
01.04.2010
[98] OSM-Wiki – DE: Tag: highway=trunk_link
http://wiki.openstreetmap.org/wiki/DE:Tag:highway%3Dtrunk_link
31.03.2010
[99] OSM-Wiki – Key: access
http://wiki.openstreetmap.org/wiki/Key:access
31.03.2010
[100] OSM-Wiki – Key: access, Access time restrictions
http://wiki.openstreetmap.org/wiki/Key:access#Access_time_restrictions
07.06.2010
[101] OSM-Wiki – Key: barrier
http://wiki.openstreetmap.org/wiki/Key:barrier
31.05.2010
[102] OSM-Wiki – Key: barrier, Linear barriers
http://wiki.openstreetmap.org/wiki/Key:barrier#Linear_barriers
07.04.2010
[103] OSM-Wiki – Key: barrier, Node barriers
http://wiki.openstreetmap.org/wiki/Key:barrier#Node_barriers
07.04.2010
[104] OSM-Wiki – Key: bridge
http://wiki.openstreetmap.org/wiki/Key:bridge
22.06.2010
[105] OSM-Wiki – Key: construction
http://wiki.openstreetmap.org/wiki/Key:construction
14.04.2010
[106] OSM-Wiki – Key: cycleway
http://wiki.openstreetmap.org/wiki/Key:cycleway
09.04.2010
[107] OSM-Wiki – Key: highway
http://wiki.openstreetmap.org/wiki/Key:highway
09.04.2010
[108] OSM-Wiki – Key: highway, International equivalence
http://wiki.openstreetmap.org/wiki/Key:highway#International_equivalence
09.04.2010
XXVII
[109] OSM-Wiki – Key: layer
http://wiki.openstreetmap.org/wiki/Key:layer
22.06.2010
[110] OSM-Wiki – Key: maxspeed
http://wiki.openstreetmap.org/wiki/Key:maxspeed
16.04.2010
[111] OSM-Wiki – Key: maxspeed, Disputed tips
http://wiki.openstreetmap.org/wiki/Key:maxspeed#Disputed_tips
16.04.2010
[112] OSM-Wiki – Key: oneway
http://wiki.openstreetmap.org/wiki/Key:oneway
31.03.2010
[113] OSM-Wiki – Key: oneway, How to Map
http://wiki.openstreetmap.org/wiki/Key:oneway#How_to_Map
31.03.2010
[114] OSM-Wiki – Key: oneway, values
http://wiki.openstreetmap.org/wiki/Key:oneway#values
31.03.2010
[115] OSM-Wiki – Key: proposed
http://wiki.openstreetmap.org/wiki/Key:proposed
14.04.2010
[116] OSM-Wiki – Key: ref
http://wiki.openstreetmap.org/wiki/Key:ref
24.06.2010
[117] OSM-Wiki – Key: traffic_calming
http://wiki.openstreetmap.org/wiki/Key:traffic_calming
07.04.2010
[118] OSM-Wiki – Key: tunnel
http://wiki.openstreetmap.org/wiki/Key:tunnel
22.06.2010
[119] OSM-Wiki – Main Page
http://wiki.openstreetmap.org/wiki/Main_Page
25.06.2010
[120] OSM-Wiki – Map Features
http://wiki.openstreetmap.org/wiki/Map_Features
07.06.2010
[121] OSM-Wiki – Map Features, Barrier
http://wiki.openstreetmap.org/wiki/Map_Features#Barrier
07.04.2010
XXVIII
[122] OSM-Wiki – Map Features, Cycleway
http://wiki.openstreetmap.org/wiki/Map_Features#Cycleway
09.04.2010
[123] OSM-Wiki – Map Features, Highway
http://wiki.openstreetmap.org/wiki/Map_Features#Highway
14.04.2010
[124] OSM-Wiki – Map Features, Restrictions
http://wiki.openstreetmap.org/wiki/Map_Features#Restrictions
31.03.2010
[125] OSM-Wiki – Map Features/Units, Speed
http://wiki.openstreetmap.org/wiki/Map_Features/Units#Speed
16.04.2010
[126] OSM-Wiki – Mapnik
http://wiki.openstreetmap.org/wiki/ Mapnik
05.06.2010
[127] OSM-Wiki – ORS, Used Tags for Routing
http://wiki.openstreetmap.org/wiki/ORS#Used_OSM_Tags_for_Routing
24.04.2010
[128] OSM-Wiki – Osmarender
http://wiki.openstreetmap.org/wiki/Osmarender
05.06.2010
[129] OSM-Wiki – OSM tags for routing/Access-Restrictions
http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions
31.03.2010
[130] OSM-Wiki – OSM tags for routing/Access-Restrictions, Germany
http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#Germany
25.04.2010
[131] OSM-Wiki – OSM tags for routing/Maxspeed
http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Maxspeed
16.04.2010
[132] OSM-Wiki – Planet.osm
http://wiki.openstreetmap.org/wiki/Planet.osm
07.06.2010
[133] OSM-Wiki – Projects
http://wiki.openstreetmap.org/wiki/Projects
05.06.2010
[134] OSM-Wiki – Projects, Quality Control
http://wiki.openstreetmap.org/wiki/Projects#Quality_Control
05.06.2010
XXIX
[135] OSM-Wiki – Relation, Established uses of Relations
http://wiki.openstreetmap.org/wiki/Relation#Established_uses_of_Relations
01.04.2010
[136] OSM-Wiki – Relation: restriction, Tags
http://wiki.openstreetmap.org/wiki/Relation:restriction#Tags
01.04.2010
[137] OSM-Wiki – Relations/Routes, Cycle routes (also mountain bike)
http://wiki.openstreetmap.org/wiki/Relations/Routes#Cycle_routes_.28also_mountain_bike.2
9
12.04.2010
[138] OSM-Wiki – Renderer
http://wiki.openstreetmap.org/wiki/Renderer
05.06.2010
[139] OSM-Wiki – Tag: barrier=block
http://wiki.openstreetmap.org/wiki/Tag:barrier%3Dblock
07.04.2010
[140] OSM-Wiki – Tag: barrier=bollard
http://wiki.openstreetmap.org/wiki/Tag:barrier%3Dbollard
07.04.2010
[141] OSM-Wiki – Tag: barrier=cycle_barrier, Examples
http://wiki.openstreetmap.org/wiki/Tag:barrier%3Dcycle_barrier#Examples
07.04.2010
[142] OSM-Wiki – Tag: barrier=cycle_barrier, How to tag
http://wiki.openstreetmap.org/wiki/Tag:barrier%3Dcycle_barrier#How_to_tag
07.04.2010
[143] OSM-Wiki – Tag: barrier=hedge
http://wiki.openstreetmap.org/wiki/Tag:barrier%3Dhedge
07.04.2010
[144] OSM-Wiki – Tag: highway=cycleway
http://wiki.openstreetmap.org/wiki/Tag:highway%3Dcycleway
09.04.2010
[145] OSM-Wiki – Tag: highway=motorway
http://wiki.openstreetmap.org/wiki/Tag:highway%3Dmotorway
31.03.2010
[146] OSM-Wiki – Tag: highway=motorway_link
http://wiki.openstreetmap.org/wiki/Tag:highway%3Dmotorway_link
31.03.2010
[147] OSM-Wiki – Tag: junction=roundabout
http://wiki.openstreetmap.org/wiki/Tag:junction%3Droundabout
31.03.2010
XXX
[148] OSM-Wiki – XSD
http://wiki.openstreetmap.org/wiki/XSD
01.06.2010
[149] OSM-Wiki – .osm#Variations
http://wiki.openstreetmap.org/wiki/.osm#Variations
22.06.2010
[150] OSMDoc (Statistik aus dem August 2009)
http://osmdoc.com/
19.04.2010
[151] OSMDoc – Key: maxspeed:backward (Statistik aus dem August 2009)
http://osmdoc.com/en/tag/maxspeed:backward/
19.04.2010
[152] OSMDoc – Key: maxspeed:forward (Statistik aus dem August 2009)
http://osmdoc.com/en/tag/maxspeed:forward/
19.04.2010
[153] OSMDoc – Key: maxspeed (Statistik aus dem August 2009)
http://osmdoc.com/en/tag/maxspeed/
07.06.2010
[154] OSMDoc – Key: minspeed (Statistik aus dem August 2009)
http://osmdoc.com/en/tag/minspeed/
07.06.2010
[155] Osmexport
http://osmlib.rubyforge.org/osmlib-export/
17.06.2010
[156] Osmexport – Rule File
http://osmlib.rubyforge.org/osmlib-export/rdoc/index.html
17.06.2010
[157] OSMLib auf RubyForge
http://osmlib.rubyforge.org/
[158] OSM Restriction Analyser
http://osm.virtuelle-loipe.de/restrictions/
[159] Ruby
http://www.ruby-lang.org/de/
17.06.2010
[160] RubyGems
http://docs.rubygems.org/
17.06.2010
[161] Sautter
http://sautter.com/map/
XXXI
[162] Sautter – transparent map
http://sautter.com/map/
07.06.2010
[163] Tele Atlas
http://www.teleatlas.com/
16.06.2010
[164] Tele Atlas‘ Community Input
http://www.teleatlas.com/stellent/groups/public/documents/content/ta_ct039180.pdf
22.06.2010
[165] TomTom
http://www.tomtom.com/
16.06.2010
[166] TomTom – Map Share
http://www.tomtom.com/page/mapshare
22.06.2010
[167] UML
http://www.uml.org/
25.06.2010
[168] United Maps
http://unitedmaps.net/
16.06.2010
[169] WhereGroup
http://www.wheregroup.com/
[170] WhereGroup – WMS-Dienst OSM_Basic
http://osm.wheregroup.com/cgi-bin/osm_basic.xml?SERVICE=WMS&&
14.06.2010
[171] Wikipedia
http://de.wikipedia.org/
[172] Wikipedia – Crowdsourcing
http://de.wikipedia.org/wiki/Crowdsourcing
25.06.2010
[173] Wikipedia – User Generated Content
http://de.wikipedia.org/wiki/User_Generated_Content
05.06.2010
[174] Yahoo – Maps
http://de.maps.yahoo.com/
[175] YourNavigation
http://www.yournavigation.org/
[176] YourNavigation – OpenStreetMap Routing Service
http://www.yournavigation.org/
14.06.2010
XXXII
Anhang
XXXIII
Abbildungen, Tabellen, Listings
OSM: Renderer
Abb. 51: Renderer Mapnik: Tiergehege im Berliner Zoo1
Abb. 52: Renderer Osmarender: Tiergehege im Berliner Zoo2
1
2
[63] (08.06.2010)
[63] (08.06.2010)
XXXIV
OSM: Grundlegendes Datenmodell
Abb. 53: Vereinfachte Darstellung des Datenmodells (aus RAMM & TOPF, 2009)1
<osm version="0.6" generator="CGImap 0.0.2">
<bounds minlat="51.912" minlon="7.5442" maxlat="51.998" maxlon="7.69"/>
[...]
<node id="277727445" lat="51.9350154" lon="7.6018375"
user="hugoe" uid="7426"
visible="true" version="4" changeset="2960899"
timestamp="2009-10-26T21:48:58Z"/>
[...]
<node id="277727511" lat="51.9351405" lon="7.6019756"
user="Gluko" uid="36745"
timestamp="2009-03-22T11:53:09Z"/>
[...]
<node id="277729693" lat="51.9352891" lon="7.6021678"
user="Gluko" uid="36745"
timestamp="2009-03-22T11:54:10Z"/>
[...]
<node id="337883591" lat="51.9362535" lon="7.6030824"
user="WanMil" uid="109925"
visible="true"
version="3" changeset="1648278"
timestamp="2009-06-27T10:42:15Z">
<tag k="highway" v="bus_stop"/>
<tag k="name" v="P+R Weseler Straße"/>
</node>
[...]
<node id="471016556" lat="51.9350267" lon="7.6018503"
timestamp="2009-10-26T21:48:58Z"/>
[...]
<way id="4064461"
timestamp="2009-10-26T21:48:59Z">
<nd ref="277727445"/>
1
[15] (S. 50))
XXXV
<nd ref="471016556"/>
<nd ref="277727511"/>
<tag k="ref" v="B 219"/>
</way>
[...]
<way id="43181297"
timestamp="2009-10-26T21:48:57Z">
<nd ref="277727511"/>
<nd ref="277729693"/>
<tag k="ref" v="B 219"/>
</way>
[...]
<relation id="303554"
timestamp="2009-10-26T21:48:58Z">
<tag k="restriction" v="only_straight_on"/>
</relation>
[...]
</osm>
Listing 47: Auszug aus einer OSM-XML-Datei (Münster)1
XML-TagName
node
osm
Häufigkeit innerhalb des XML-Tags
0…n
way
osm
0…n
Way
relation
osm
0…n
Relation
nd
way
2…2000
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
0…1000
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.
1
enthalten in XML-Tag(s)
20.04.2010
XXXVI
Beschreibung
Node
XML-TagName
bound
Häufigkeit innerhalb des XML-Tags
0…1
osm
Beschreibung
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 Relations1
Beschreibung
x
x
x
Zeitpunkt der
letzten Änderung
255
x
x
x
Bearbeiter
Integer
20
x
x
x
Benutzernummer
changeset
Integer
20
x
x
x
Verweis auf das
Changeset
visible
Boolean
(true/false,
yes/now,
1/0)
x
x
x
false, falls das
Objekt in der
Datenbank gelöscht wurde,
andernfalls true.
lat
Gleitkommazahl
mit 7
Nachkommastellen
x
geografische
Breite in Grad
lon
Gleitkommazahl
mit 7
Nachkommastellen
x
geografische
Länge in Grad
ref
Integer
64
k
Text
255
x
Schlüssel (Key)
eines Tags
v
Text
255
x
Wert (Value)
eines Tags
timestamp
Text
user
Text
uid
1
x
[15] (S. 49ff) [149]
XXXVII
x
osm
ID
bound
x
64
bounds
x
Integer
tag
x
id
nd
relation
member
Wert:
Länge
way
XML-Attribut
Wert:
Datentyp
node
Name
Referenz auf die
ID eines Nodes,
Ways oder einer
Relation
osm
Beschreibung
bound
bounds
tag
member
nd
relation
Wert:
Länge
way
XML-Attribut
Wert:
Datentyp
node
Name
type
Text
(way, node, relation)
role
Text
255
minlat
Gleitkommazahl
mit 7
Nachkommastellen
x
min. geogr.
Breite für angeforderten Bereich der Daten
minlon
Gleitkommazahl
mit 7
Nachkommastellen
x
min. geogr.
Länge für angeforderten Bereich der Daten
maxlat
Gleitkommazahl
mit 7
Nachkommastellen
x
max. geogr.
Breite für angeforderten Bereich der Daten
maxlon
Gleitkommazahl
mit 7
Nachkommastellen
x
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
version
Text (0.6)
-
x
Version der
Datenbank-API /
des XMLFormats
generator
Text
-
x
Name des Programms, das die
XML-Datei erstellt hat
-
x
x
x
Typ des Teilnehmers der
Relation
x
Rolle eines Teilnehmers einer
Relation
x
Version des
Objekts
Tabelle 29: Attribute von XML-Tags, wie sie in der OSM-XML-Datei verwendet werden1
1
[15] (S. 50ff, 286) [71] [78] [79]
XXXVIII
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 Deutschland1
1
[91]
XXXIX
OSM: Beschränkung der Beförderungsart
Abb. 54: Deutsche Transportmittel-Hierachie1
Abb. 55: Allgemeine Default-Tabelle für Transportmittelbeschränkungen2
1
2
[83]
[129]
XL
Zutrittsbeschränkung
Erklärung
yes
öffentlicher Weg
no
Zutritt nicht erlaubt
unknown
Zutrittsbedingungen sind unbekannt oder unklar (Default-Wert)
designated
für bestimmte Verkehrsmittel vorgesehen
official
bestimmten Verkehrsmitteln gesetzlich gewidmet
private
Privatweg, Zutritt kann von Grundstückseigentümer erlaubt werden
permissive
Grundstückseigentümer erlaubt die öffentliche Benutzung
destination
Zutritt nur erlaubt, wenn das Ziel nicht auf eine andere Weise erreicht werden kann, z.B. „Anlieger frei“
delivery
Zutritt für Warenanlieferungen
agricultural
Zutritt für „landwirtschaftlichen Verkehr“
forestry
Zutritt für „forstwirtschaftlichen Verkehr“
Tabelle 31: Zutrittsbeschränkungsarten1
Hecke
x
x
x
fence
Zaun
x
x
x
wall
Mauer
x
x
x
ditch
Graben
x
x
x
retaining_wall
Stützmauer,
Stützwand
x
x
x
city_wall
Stadtmauer
x
x
x
bollard
Poller, Pfosten,
Bake
x
cycle_barrier
Drängelgitter,
Umlaufsperre
für Fahrräder
oder Motorräder
block
x
foot = yes,
bicycle = yes
x
x
Fußgänger
Block
x
x
access=*
cattle_grid
Weiderost für
Huftiere
x
toll_booth
Mautstelle
x
entrance
Durchlass durch
x
1
x
Sperrung /
Durchlass
verkehrsmittelabhängig
Durchlass
hedge
Node
(Closed)
Area
Bedeutung
Way
Wert
Sperrung
OSM: Barrieren
Huftiere
x
x
x
[89]
XLI
access=*
x
x
lift_gate
Schlagbaum
stile
sally_port
Sperrung /
Durchlass
verkehrsmittelabhängig
Durchlass
Tor, Schranke
Sperrung
gate
(Closed)
Area
Way
Bedeutung
Node
Wert
Barriere
x
access=*
x
x
access=*
Tritt über Zaun
x
x
Fußgänger
Ausfalltor,
Durchgangsschleuse
x
x
Tabelle 32: Bekannteste Barrieren (OSM-Schlüssel: barrier)1
XML Schema für OSM
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
version="0.6" >
<xs:element name="osm">
<xs:complexType >
<xs:sequence>
<xs:element ref="bounds"
minOccurs="0"
maxOccurs="1" />
<xs:element ref="bound"
minOccurs="0"
maxOccurs="1" />
<xs:element ref="node"
minOccurs="0"
maxOccurs="unbounded" />
<xs:element ref="way"
minOccurs="0"
<xs:element ref="relation"
minOccurs="0"
</xs:sequence>
<xs:attribute name="version"
use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="0.6" />
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="generator"
type="xs:string"
use="required" />
</xs:complexType>
</xs:element>
<xs:element name="bounds">
<xs:complexType>
<xs:attribute name="minlat"
1
[88] [121] [139] [140] [143]
XLII
type="xs:float"
use="required" />
<xs:attribute name="minlon"
type="xs:float"
use="required" />
<xs:attribute name="maxlat"
type="xs:float"
use="required" />
<xs:attribute name="maxlon"
type="xs:float"
use="required" />
</xs:complexType>
</xs:element>
<xs:element name="bound">
<xs:complexType>
<xs:attribute name="box"
type="xs:string"
use="required" />
<xs:attribute name="origin"
type="xs:string"
use="required" />
</xs:complexType>
</xs:element>
<xs:element name="tag">
<xs:complexType >
<xs:attribute name="k"
type="xs:string"
use="required" />
<xs:attribute name="v"
type="xs:string"
use="required" />
</xs:complexType>
</xs:element>
<xs:element name="nd">
<xs:complexType>
<xs:attribute name="ref"
type="xs:integer"
use="required" />
</xs:complexType>
</xs:element>
<xs:element name="member">
<xs:complexType>
<xs:attribute name="type"
use="required">
<xs:simpleType>
<xs:enumeration value="way" />
<xs:enumeration value="node" />
<xs:enumeration value="relation" />
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ref"
type="xs:integer"
use="required" />
<xs:attribute name="role"
type="xs:string" />
</xs:complexType>
</xs:element>
<xs:element name="node">
<xs:complexType>
<xs:sequence>
XLIII
<xs:element ref="tag"
minOccurs="0"
</xs:sequence>
<xs:attribute name="id"
type="xs:integer"
use="required" />
<xs:attribute name="timestamp"
type="xs:string" />
<xs:attribute name="user"
type="xs:string" />
<xs:attribute name="uid"
type="xs:integer" />
<xs:attribute name="changeset"
<xs:attribute name="visible"
type="xs:string" />
<xs:attribute name="lat"
type="xs:float"
use="required" />
<xs:attribute name="lon"
type="xs:float"
use="required" />
<xs:attribute name="version"
</xs:complexType>
</xs:element>
<xs:element name="way">
<xs:complexType mixed="true">
<xs:sequence>
<xs:choice minOccurs="0" maxOccurs="unbounded" >
minOccurs="0"
<xs:element ref="nd"
minOccurs="2"
maxOccurs="2000" />
</xs:choice>
</xs:sequence>
type="xs:integer"
use="required" />
<xs:attribute name="timestamp" type="xs:string" />
<xs:attribute name="user" type="xs:string" />
<xs:attribute name="uid" type="xs:integer" />
<xs:attribute name="changeset" type="xs:integer" />
<xs:attribute name="visible" type="xs:string" />
<xs:attribute name="version" type="xs:integer" />
</xs:complexType>
</xs:element>
<xs:element name="relation">
<xs:complexType>
<xs:sequence>
<xs:choice minOccurs="0" maxOccurs="unbounded" >
minOccurs="0"
<xs:element ref="member"
minOccurs="0"
maxOccurs="1000" />
</xs:choice>
</xs:sequence>
XLIV
type="xs:integer"
use="required" />
<xs:attribute name="timestamp" type="xs:string" />
<xs:attribute name="user" type="xs:string" />
<xs:attribute name="uid" type="xs:integer" />
<xs:attribute name="changeset" type="xs:integer" />
<xs:attribute name="visible" type="xs:string" />
<xs:attribute name="version" type="xs:integer" />
</xs:complexType>
</xs:element>
</xs:schema>
Listing 48: XML Schema für OSM v0.6 (osm_v_0_6.xsd)
XML Schema der Parameter-Datei
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="parameters">
<xs:complexType >
<xs:sequence>
<xs:element ref="transport_mode_hierarchie"
minOccurs="1" maxOccurs="1" />
<xs:element ref="slowDown_barrier_restrictions"
<xs:element ref="access_barrier_restrictions"
<xs:element
ref="access_barrier_restrictions_interpretation"
<xs:element ref="access_highway_restrictions"
<xs:element
ref="access_highway_restrictions_interpretation"
<xs:element ref="oneway_highway_implications"
<xs:element ref="maxspeed_highway_implications"
<xs:element ref="avspeed_highway_implications"
<xs:element ref="speed_highway_variables"
<xs:element ref="speed_highway_units"
<xs:element ref="length_highway_units"
<xs:element ref="weight_highway_units"
<xs:element ref="driveTime_slowDown_delay"
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="transport_mode_hierarchie">
<xs:complexType>
<xs:sequence>
<xs:element ref="orderElement"
minOccurs="1" maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
XLV
</xs:element>
<xs:element name="slowDown_barrier_restrictions">
<xs:complexType>
<xs:sequence>
<xs:element ref="listElementNoYes"
minOccurs="0" maxOccurs="unbounded"
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="access_barrier_restrictions">
<xs:complexType>
<xs:sequence>
<xs:element ref="listElementString"
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="access_barrier_restrictions_interpretation">
<xs:complexType>
<xs:sequence>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="access_highway_restrictions">
<xs:complexType>
<xs:sequence>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="access_highway_restrictions_interpretation">
<xs:complexType>
<xs:sequence>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="oneway_highway_implications">
<xs:complexType>
<xs:sequence>
<xs:element ref="caseOneway"
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="maxspeed_highway_implications">
<xs:complexType>
<xs:sequence>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="avspeed_highway_implications">
<xs:complexType>
<xs:sequence>
XLVI
/>
/>
/>
/>
/>
/>
/>
/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="speed_highway_variables">
<xs:complexType>
<xs:sequence>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="speed_highway_units">
<xs:complexType>
<xs:sequence>
<xs:element ref="listElementFloat"
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="length_highway_units">
<xs:complexType>
<xs:sequence>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="weight_highway_units">
<xs:complexType>
<xs:sequence>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="driveTime_slowDown_delay">
<xs:complexType>
<xs:attribute name="barrierDelayConstant"
type="xs:float" use="required" />
<xs:attribute name="highwaySlowDownFactor"
</xs:complexType>
</xs:element>
<xs:element name="orderElement">
<xs:complexType >
<xs:attribute name="value"
type="xs:string" use="required" />
</xs:complexType>
</xs:element>
<xs:element name="listElementString">
<xs:complexType >
<xs:attribute name="key"
</xs:complexType>
</xs:element>
<xs:element name="listElementNoYes">
<xs:complexType >
<xs:attribute name="value" use="required" >
XLVII
/>
/>
/>
/>
<xs:simpleType>
<xs:enumeration value="no" />
<xs:enumeration value="yes" />
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:element name="listElementFloat">
<xs:complexType >
</xs:complexType>
</xs:element>
<xs:element name="caseOneway">
<xs:complexType >
<xs:sequence>
minOccurs="1" maxOccurs="unbounded" />
</xs:sequence>
<xs:attribute name="interpret_as_oneway" use="required" >
<xs:simpleType>
<xs:enumeration value="no" />
<xs:enumeration value="yes" />
<xs:enumeration value="-1" />
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
</xs:schema>
Listing 49: XML Schema für die Parameter-Datei (Parameters.xsd)
Parameter-Datei für Autos
<parameters>
<orderElement value="motor_vehicle"/>
<orderElement value="motorcar"/>
<listElementString key="bollard" value="no"/>
<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"/>
XLVIII
<listElementString key="small_fence" value="no"/>

<listElementNoYes key="bollard" 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="sally_port" value="yes"/>
<listElementString key="motorway" value="yes"/>
<listElementString key="motorway_link" value="yes"/>
<listElementString key="motorway_junction" value="yes"/>
<listElementString key="path" value="no"/>
<listElementString key="ford" value="yes"/>
XLIX


<caseOneway interpret_as_oneway="yes">
<listElementString key="highway" value="motorway"/>
<listElementString key="oneway" value=""/>
<listElementString key="junction" value=""/>
</caseOneway>
<listElementString key="highway" value="motorway_link"/>
</caseOneway>
<listElementString key="highway"
value="motorway_junction"/>
</caseOneway>
<listElementString key="highway" value="trunk_link"/>
</caseOneway>
<listElementString key="highway" value="roundabout"/>
</caseOneway>
value="mini_roundabout"/>
</caseOneway>
<listElementString key="highway" value="*"/>
<listElementString key="junction" value="roundabout"/>
</caseOneway>
<caseOneway interpret_as_oneway="no">
L
<listElementString key="oneway" value="no"/>
</caseOneway>
<listElementString key="oneway" value="false"/>
</caseOneway>
<listElementString key="oneway" value="0"/>
</caseOneway>
<listElementString key="oneway" value="yes"/>
</caseOneway>
<listElementString key="oneway" value="true"/>
</caseOneway>
</caseOneway>
<caseOneway interpret_as_oneway="-1">
<listElementString key="oneway" value="-1"/>
</caseOneway>
<listElementString key="oneway" value="reverse"/>
</caseOneway>

LI
<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"/>
<listElementString key="DE:urban" value="50"/>
<listElementString key="DE:rural" value="100"/>
<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"/>
<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"/>
LII
</parameters>
Listing 50: Beispiel einer Parameter-Datei für motocar (Auto) bezogen auf Deutschland
Parameter-Datei für Fahrräder
<parameters>
<orderElement value="bicycle"/>
<listElementString key="bollard" value="yes"/>
<listElementString key="cycle_barrier" value="yes"/>
<listElementString key="block" value="yes"/>
<listElementString key="stoneblocks" value="yes"/>
<listElementString key="entrance" value="yes"/>
<listElementString key="gate" value="yes"/>
<listElementString key="lift_gate" value="yes"/>
<listElementString key="gate:lift" value="yes"/>
<listElementString key="stile" value="no"/>
<listElementString key="yes" value="no"/>
<listElementString key="small_fence" value="no"/>
<listElementNoYes key="delivery" value="yes"/>
<listElementNoYes key="agricultural" value="yes"/>
<listElementNoYes key="forestry" value="yes"/>
<listElementNoYes key="bollard" value="no"/>
<listElementNoYes key="block" value="no"/>
<listElementNoYes key="stoneblocks" value="no"/>
<listElementNoYes key="toll_booth" value="no"/>
<listElementNoYes key="entrance" value="no"/>
<listElementNoYes key="sally_port" value="no"/>
LIII
<listElementString key="motorway" value="no"/>
<listElementString key="motorway_link" value="no"/>
<listElementString key="motorway_junction" value="no"/>
<listElementString key="path" value="yes"/>
<listElementString key="cycleway" value="yes"/>
<listElementString key="ford" value="yes"/>
<listElementNoYes key="delivery" value="yes"/>
<listElementNoYes key="agricultural" value="yes"/>
<listElementNoYes key="forestry" value="yes"/>


<listElementString key="cycleway" value="yes"/>
<listElementString key="cycleway:left" value=""/>
<listElementString key="cycleway:right" value=""/>
<listElementString key="oneway:bicycle" value=""/>
</caseOneway>
LIV
</caseOneway>
<caseOneway interpret_as_oneway="yes">
<listElementString key="cycleway" value="track"/>
</caseOneway>
<listElementString key="cycleway" value="lane"/>
</caseOneway>
<listElementString key="cycleway" value=""/>
<listElementString key="cycleway:left" value="lane"/>
<listElementString key="cycleway:right" value="lane"/>
</caseOneway>
</caseOneway>
</caseOneway>
<listElementString key="oneway:bicycle" value="no"/>
</caseOneway>
<listElementString key="cycleway"
value="lane;opposite_lane"/>
LV
</caseOneway>
</caseOneway>
</caseOneway>
<listElementString key="cycleway" value="opposite_lane"/>
</caseOneway>
<listElementString key="cycleway"
value="opposite_track"/>
</caseOneway>
</caseOneway>
</caseOneway>
<listElementString key="highway" value="cycleway"/>
</caseOneway>
LVI
<listElementString key="cycleway" value="track"/>
</caseOneway>
<listElementString key="cycleway" value="opposite"/>
</caseOneway>
<listElementString key="highway" value="motorway"/>
</caseOneway>
<listElementString key="highway" value="motorway_link"/>
</caseOneway>
value="motorway_junction"/>
</caseOneway>
<listElementString key="highway" value="trunk_link"/>
</caseOneway>
<listElementString key="highway" value="roundabout"/>
</caseOneway>
LVII
value="mini_roundabout"/>
</caseOneway>
<listElementString key="junction" value="roundabout"/>
</caseOneway>
<listElementString key="oneway" value="no"/>
</caseOneway>
<listElementString key="oneway" value="false"/>
</caseOneway>
</caseOneway>
</caseOneway>
<listElementString key="oneway" value="true"/>
</caseOneway>
LVIII
</caseOneway>
<listElementString key="oneway" value="-1"/>
</caseOneway>
<listElementString key="oneway" value="reverse"/>
</caseOneway>

LIX
<listElementString
<listElementString
<listElementString
<listElementString
<listElementString
<listElementString
<listElementString
<listElementString
<listElementString
<listElementString
<listElementString
<listElementString
<listElementString
<listElementString
<listElementString
<listElementString
<listElementString
<listElementString
<listElementString
<listElementString
<listElementString
<listElementString
<listElementString
<listElementString
<listElementString
key="trunk" value="16"/>
key="trunk_link" value="16"/>
key="primary" value="16"/>
key="primary_link" value="16"/>
key="secondary" value="16"/>
key="secondary_link" value="16"/>
key="tertiary" value="16"/>
key="tertiary_link" value="16"/>
key="unclassified" value="16"/>
key="road" value="16"/>
key="residential" value="16"/>
key="living_street" value="4"/>
key="service" value="16"/>
key="footway" value="5"/>
key="steps" value="5"/>
key="track" value="10"/>
key="pedestrian" value="5"/>
key="cycleway" value="15"/>
key="bridleway" value="15"/>
key="path" value="8"/>
key="elevator" value="5"/>
key="turning_circle" value="5"/>
key="ford" value="5"/>
key="undefined" value="16"/>
key="else" value="16"/>

<listElementString key="DE:urban" value="null"/>
<listElementString key="DE:rural" value="null"/>
<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"/>
<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"/>
</parameters>
Listing 51: Beispiel einer Parameter-Datei für bicycle (Fahrrad) bezogen auf Deutschland
LX
Java-Klassen der Parameter-Datei
Abb. 56: Java-Klassen der Parameter-Datei
LXI
Java-Klassen der OSM-Datei
Abb. 57: Java-Klassen der OSM-Datei
LXII
Installation
Zur Ausführung des in Java geschriebenen Programmes müssen folgende Voraussetzungen erfüllt
sein:

installierte Java-Version (z.B. Java Runtime Environment)

ArcGIS in der Version 9.3.1 mit ArcObjects für Java
Die programmierte Anwendung ist einer JAR-Datei (Java Archive) zusammengefasst. Von dieser Anwendung werden Klassen und Schnittstellen von ArcObjects verwendet, die ebenfalls in einer JARDatei gebündelt sind. Die JAR-Datei von ArcObjects liegt bei Windows i.d.R. in folgendem Verzeichnis:
C:\Program Files\ArcGIS\java\lib\arcobjects.jar
Zur Ausführung des Programmes ist es am einfachsten, wenn eine Batch-Datei erstellt wird. Diese
Batch-Datei kann durch ein Doppelklick ausgeführt werden. Der Aufbau der Batch-Datei ist in Listing
52 dargestellt.
<Pfad zu Java> -cp <Pfad zu arcobjects.jar>;<Pfad zu OSM2NetworkDatasetx.x.x.jar> de.hska.ziev0011.bac.core.Main <Pfad zur OSM-Datei> <Pfad zur
Parameter-Datei> <Pfad zum Ausgabe-Verzeichnis> <Name der Region> <Pfad zur
log-Datei>
PAUSE
Listing 52: Aufbau der Batch-Datei
Zunächst wird der Pfad zu Java angegeben. Nach dem Aufrufparameter -cp (CLASSPATH) folgen die
Pfade zu den JAR-Dateien (ArcObjects und OSM2NetworkDataset). Anschließend wird der Packagepfad zur Main-Klasse des Programmes angegeben. Optional können nachfolgend noch die in Kapitel
4.3 aufgeführten Argumente übergeben werden. Dabei muss die Reihenfolge beachtet werden. Diese
Argumente werden nach dem Starten des Tools in die Maske eingetragen.
Listing 53 zeigt ein Beispiel einer Batch-Datei.
"C:\Program Files\Java\jre6\bin\java" -cp "C:\Program Files\ArcGIS\java\lib\arcobjects.jar;C:\tmp\OSM2NetworkDataset\OSM2NetworkDat
aset-0.2.0.jar" de.hska.ziev0011.bac.core.Main C:\tmp\Muenster\Muenster.osm
C:\tmp\Muenster\Parameters.xml Muenster C:\Data tmp\Muenster\Muenster
C:\tmp\Muenster\Muenster.log
PAUSE
Listing 53: Beispiel einer Batch-Datei
Es kann vorkommen, dass der standardmäßig von Java allokierte Speicher (Heap Size) nicht ausreicht.
Dies ist der Fall, wenn das zu konvertierende Gebiet zu groß ist. In diesem Fall kann der Anwender
manuell den maximalen Heap Size anpassen. Dazu wird vor den Aufrufparameter -cp durch ein
Leerzeichen getrennt z.B. -Xmx1024m eingefügt. Dies entspricht einer maximalen Heap Size-Größe
von 1024 MB. Es ist vom System abhängig, welches die höchstmögliche Heap Size ist.
LXIII
Inhaltsverzeichnis der CD
Die CD enthält folgende Ordner (fett) und Daten (regular):
1_Daten
Freiburg.osm
Freising.osm
Muenster.osm
2_Manuelle_Datenaufbereitung
1_Abbiegeverbote
Muenster_turns_manuell.osm
2_Rulefiles
barriers.oxr
roads.oxr
turns.oxr
3_Zwischenergebnis
barriers.shp
roads.shp
turnsSHP.shp
4_Ergebnis
Muenster.gdb
Muenster.mxd
3_Automatisierte_Datenaufbereitung
1_Parameter
Parameters_Bicycle.xml
Parameters_Motorcar.xml
2_Ergebnis
Muenster_Bicycle.gdb
Muenster_Bicycle.mxd
Muenster_Motorcar.gdb
Muenster_Motorcar.mxd
4_OSM2NetworkDataset
Anwendung
OSM2NetworkDataset.bat
OSM2NetworkDataset.jar
readme.txt
Quellcode
*.java
JavaDoc
*.html
5_Dokumente
Bachelor-Thesis_Eva_Zimmermann.docx
Bachelor-Thesis_Eva_Zimmermann.pdf
Handout.pdf
Poster.pdf
LXIV

Hochschule Karlsruhe – Technik und Wirtschaft Fakultät

Transcrição

Documentos relacionados

Artikel als PDF herunterladen

Managerportrait: Li Ka-Shing

Florida-Tour 22. April – 06. Mai 2017 Die besten

Alles so schön great hier

Vertriebsingenieur/-in für das Internationale Key Account

HONEYMOON TRIP TIPP – FLORIDA KEYS

Wi FiZONE - Mannheim

Flughafen München GmbH

hot spot key west

Markus Drews, Im-mobilis GmbH, Duisburg