Implementierung einer Routensuche anhand von OHDM Karten unter Berücksichtigung der zu dem Zeitalter verwendeten
Transportwege und – Mitteln
Abschlussarbeit
zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.)
an der
Hochschule für Technik und Wirtschaft Berlin Fachbereich IV
Studiengang Angewandte Informatik
1. Prüfer: Prof. Dr.-Ing. Thomas Schwotzer 2. Prüfer: Prof. Dr. Alexander Huhn
Eingereicht von: Kirill Mishin Immatrikulationsnummer: s0552087
Eingereicht am: 27.01.2020
Inhaltsverzeichnis
1 Einleitung 1
1.1 Zielsetzung . . . 2
1.2 Heutiger Stand der Wissenschaft . . . 2
1.3 Vorgehensweise und Aufbau der Arbeit . . . 2
2 Grundlagen 4 2.1 OHDM . . . 4
2.2 Begriffsklärungen . . . 4
2.2.1 Transportmittel . . . 5
2.2.2 Transportwege . . . 5
2.2.3 Personenklassen . . . 5
2.2.4 Historische Ereignisse . . . 6
2.2.5 Historischer Kontext . . . 6
2.3 Koordinatenreferenzsysteme . . . 6
2.3.1 epsg:4326 . . . 6
2.3.2 epsg: 3857 . . . 7
2.4 Routing-Tool . . . 7
3 Analyse 8 3.1 Allgemeine Analyse . . . 8
3.2 OHDM Datenbank . . . 9
3.3 Technische Analyse (Routing Tool) . . . 9
3.4 Topologie . . . 10
3.4.1 pgr_analyzeGraph() . . . 10
3.4.2 pgr_nodeNetwork() . . . 11
3.5 Problemstellungen . . . 11
4 Konzeption 12 4.1 Anforderungen an das zu entwickelnden System(Prototyp) . . . 12
4.2 Konzeptentwurf . . . 12
4.3 Interpretierung der historischen Ereignisse . . . 14
4.4 Kantengewichtung . . . 14
Inhaltsverzeichnis ii
4.5 Interpretation von Klassifikationen . . . 15
4.5.1 Interpretation von highway_lines . . . 15
4.5.2 Interpretation von waterway_lines . . . 16
5 Implementierung 18 5.1 Die Grundvoraussetzungen für die OHDM-Datenbank . . . 18
5.2 Aufbau des Prototyps . . . 19
5.3 Konfigurationsparameter . . . 20
5.3.1 Konfigurationsdatei zum Aufbau der Verbindung . . . 20
5.3.2 Suchparameter-Konfigurationdatei . . . 21
5.4 Parameter für historischen Kontext . . . 21
5.4.1 Transportmittel . . . 22
5.4.2 Personenklassen . . . 22
5.4.3 Unzugängliche Gebiete . . . 23
5.5 Aufbau der Topologie . . . 25
5.6 Gewichtung . . . 26
5.7 Ausschließen der Gebiete . . . 26
5.8 Ermittlung der Start- und Endknoten . . . 27
5.9 Berechnung einer Route mithilfe von pgr_dijkstra()und Befüllung der Ta- belleresult_way_table . . . 28
5.10 Berechnung der Reisezeit und Befüllung der Tabelleresult_time_table. . . 29
5.11 Auswertung der Ergebnistabellen . . . 29
5.11.1 Interpretation der Spalten der Tabelle result_way_table . . . 29
5.11.2 Interpretation der Spalten der Tabelle result_time_table . . . 30
6 Test 31 6.1 Der Weg für die Personenklasse Bauer . . . 32
6.2 Der Weg für die Personenklasse Adliger . . . 34
6.3 Auswertung der Ergebnisse . . . 36
7 Fazit 37
Abbildungsverzeichnis I
Tabellenverzeichnis II
Source Code Content III
Literaturverzeichnis IV
Inhaltsverzeichnis iii
Onlinereferenzen V
Anhang A VI
A.1 Inhalt der beiliegenden CD . . . VI
Eigenständigkeitserklärung VII
Kapitel 1 Einleitung
Die Route, die man einschlägt, kann massiv auf den Ausgang von Vorhaben einwirken.
Welche Bedeutung ein strategisch günstiger Transportweg in Zeiten des Kriegs haben kann, zeigt die Ludendorff-Brücke zwischen Remagen und Erpel [Pal85]. Bei der Brücke, auch als Brücke von Remagen bekannt, handelt es sich um eine militärische zweigleisige Eisen- bahnbrücke. Diese soll maßgeblich zur Beschleunigung des Kriegsfortgangs beigetragen haben. Denn der Rhein diente als strategische Barriere, die Europa und das Ruhrgebiet, als Zugang zum Landesinneren voneinander trennte. Die Wehrmacht plante dessen Sprengung, aber unzulängliche Sprengstoffe führten zu einem Misserfolg. Die Brücke blieb intakt und verhalf den Westalliierten so schneller in Richtung Ruhrgebiet vorzustoßen. Die Zerstörung dieses strategisch günstigen Transportwegs für die Westalliierten seitens der Wehrmacht blieb erfolglos. In einem Artikel [Kel18] der Welt-Zeitung gibt Historiker Stefan Gerber (2015) an, dass die Eroberung den Vormarsch vermutlich um Wochen verkürzt habe. "Das Wunder von Remagen"veranschaulicht, welche Rolle eine bestimmte Route spielt und wie historische Ereignisse auf die Nutzbarkeit solcher Routen einwirken. Vor der Einführung des Flugzeugs bestand nur die Möglichkeit, mit dem Schiff interkontinental zu verreisen.
Dieses Transportmittel ist mit strengen Vorgaben an das Wetter verbunden. Unwetter und suboptimale Witterungsverhältnisse sind nicht die einzigen Faktoren, die das Reisen beeinflussen. Hiesige Kriege, religiöse Konflikte und die Kosten der Reise erschwerten die Mobilität. Reisen war mühsam und sogar lebensbedrohlich [Wie39]. Motorbetriebene Transportmittel waren nicht verbreitet. Eben jene Mittel, angetrieben von Verbrennungs- motoren, wurden erst nach dessen Entdeckung 1862 von Nikolaus August Otto eingeführt.
Die Wasserwege ließen durch schwankende Wasserströmungen und Windrichtungen nur eine eingeschränkte Nutzung zu [Lot11].
Kapitel 1 Einleitung 2
1.1 Zielsetzung
Die vorliegende Arbeit setzt sich primär mit der Frage auseinander, welchen Einfluss zeitgeschichtliche Ereignisse auf die Dauer einer bestimmten Strecke haben. Der Fokus liegt dabei auf der Entwicklung eines Systems zur Routenfindung. Auf die Zurücklegung von Strecken wirken verschiedene Faktoren ein. Hauptaugenmerk liegt auf den Trans- portwegen, die sich im Laufe der Zeit verändert haben. Diese Transportwege variieren durch Auflösung territorialer Grenzen, wetterbedingt eingeschränkter Nutzung, Kriegen und personenbezogene Einschränkung. Das hier vorzustellende Programm soll es ermög- lichen, eine Route, anhand historischer Karten unter Berücksichtigung eben genannter Einflussfaktoren, anzufertigen. Die Implementierung soll dabei erweiterbar bleiben, um die Ergebnisse auszuweiten und zu optimieren.
1.2 Heutiger Stand der Wissenschaft
Der Gegenstand ist zu diesem Zeitpunkt weitgehend unerforscht. Als primäre Grundlage der vorliegenden Arbeit dient das Open Historical Data Map (OHDM) Projekt von Prof.
Dr.-Ing. Schwotzer an der Hochschule für Technik und Wirtschaft Berlin [Sch19]. Es wurde 2015 im Zuge der fakultären Lehre an der HTW ins Leben gerufen. Bei diesem handelt es sich um ein Open-Source Projekt, das Karten und historische Daten liefert. Das Projekt schafft einen zeitgeschichtlichen Verlauf von offenen Kartendaten, die editierbar bleiben sollen. Das Projekt von Prof. Dr.-Ing. Schwotzer befasst sich mit der Erstellung solcher Karten, aber nicht mit Routenplanung. Diese Routensuche soll das hier vorgestellte Pro- gramm leisten und somit ergänzend zum Open Historical Data Map Projekt funktionieren.
Ziel ist es durch diese historisch-orientierten Routen, zu einem besseren Verständnis für ein Leben in einer anderen Zeit zu verhelfen.
1.3 Vorgehensweise und Aufbau der Arbeit
Zunächst soll das OHDM-Projekt in seinen Grundlagen vorgestellt werden. Anhand der von dem Projekt zur Verfügung gestellten Karten sollen nun Routen kalkuliert werden. Das Kal- kulieren soll mithilfe eines Open Source Routingtools erfolgen. Innerhalb der Grundlagen bleibt es zunächst bei einer grundsätzlichen Klärung des Open Source Routingtool-Begriffs.
Um welches es sich genau handelt, wird in der Analyse besprochen.
Kapitel 1 Einleitung 3
Der anhand der Transportmittel und -wege zu errechnenden Route liegen fest umgrenzte Parameter zugrunde. Innerhalb der Begriffsklärung werden die bestimmten Transportmit- tel und -wege festgelegt. Die einzelnen reisenden Personen werden in zwei verschiedene Gruppen klassifiziert. Die Klassifizierung erfolgt exemplarisch und steckt lediglich den Geltungsbereich dieser Arbeit fest. Mithilfe dieser Parameter entsteht ein Prototyp des Systems, der greifbare Ergebnisse liefert. Für diese Ergebnisse sind exemplarische Parame- ter unabdingbar. Erst eine beispielhafte Einteilung gewährleistet die Visualisierung einer historischen Routenplanung. Als letzter grundlegender Aspekt wird im nächsten Schritt auf das Koordinatenreferenzsystem eingegangen. Für diese Arbeit spielen zwei bestimmte Koordinatensysteme eine Rolle, die zunächst nur erklärt werden. Durch die Klärung der Grundlagen ist das Fundament der Arbeit gelegt. Darauf aufbauend erfolgt nun der ana- lytische Bereich. Um die vorgesehene Routensuche im Rahmen dieser Arbeit theoretisch durchzuführen, erfolgt eine hypothetische Skizze eines mittelalterlichen Zeitraums. Obwohl keine etwaigen Daten zur Verfügung stehen, lassen sich Parallelen des vom Autor konstru- ierten Zeitalters zum Mittelalter feststellen. Die Gegebenheiten dieses Zeitalters werden innerhalb der Analyse genauer beleuchtet. Ferner werden die für die Arbeit relevanten Aspekte des OHDM-Projekts hervorgehoben. Mit der Analyse erfolgt auch die Festlegung des Routing-Tools. Daraus kristallisiert sich, dass eine Topologie für die Berechnung einer Route notwendig ist. Aus dem Kapitel Topologie ergibt sich, dass bestimmte Funktio- nen des Routing-Tools sich als wichtig erweisen. Die Zusammenführung der Teilaspekte der Analyse birgt einige Probleme, die abschließend erläutert werden. Die Konzeption be- spricht zunächst die Anforderungen des zu entwickelnden System-Prototyps. Nun kann der Konzeptentwurf präsentiert werden. Der historische Kontext setzt sich hier aus verschie- denen Faktoren zusammen. Einzelne Informationen verschiedener Datenbank-Tabellen ergeben zusammen einen historischen Kontext. Mit der Konzeption sollen Lösungsansätze vorgestellt werden, die die Erstellung eines Prototyps ermöglichen. Dessen Umsetzung erfolgt nun im Implementierungskapitel der vorliegenden Arbeit. Neben der Umsetzung der Konzeption des vorangegangenen Kapitels, werden die technischen Details des Proto- typs herausgearbeitet. Die technische Vorgehensweise wird nun genau dargelegt. Einzelne technische Prozesse werden darüber hinaus genauer erläutert. Mit dem Test-Kapitel wer- den nun konkrete Fallbeispiele durchgeführt und ausgewertet. In einem konklusiven Fazit findet diese Arbeit ihren Abschluss.
Kapitel 2 Grundlagen
2.1 OHDM
Das Open Historical Data Map Projekt von Prof. Dr.-Ing. Schwotzer ist an der HTW Berlin entstanden [Sch19]. Das Ziel ist es, historische Karten und weitere zeitabhängi- ge Informationen im Open-Street-Map Format zu speichern und darstellen zu können.
Die Kartendaten liefert die PostGIS-Datenbank, die, als Erweiterung der PostgreSQL- Datenbank, Daten als Vektorgeometrien speichert und darstellt [Pos20]. In dieser Arbeit werden die von OHDM generierten Datenbanktabellen verwendet. Somit dient das OHDM- Projekt als Vorlage zur Implementierung des zu entwickelnden Systems, da die Daten und Geometrien von OHDM-Datenbank entstammen. Davon ausgehend, ist diese Arbeit eine Erweiterung des bestehenden Systems.
2.2 Begriffsklärungen
Im folgenden Abschnitt erfolgt die Klärung bestimmter Begriffe, die keine eindeutigen De- finitionen implizieren. Daraus resultiert, dass keine allgemeingültige Erklärung vorgesehen ist, sondern stattdessen eine explizite Deutung der Begriffsauslegung erfolgt. Die Begriff- lichkeiten werden innerhalb des Geltungsbereichs definiert und sind relativ zueinander und zur Arbeit selbst.
Kapitel 2 Grundlagen 5
2.2.1 Transportmittel
Transportmittel umfasst in Relation zur Arbeit eine bestimmte Anzahl verschiedener Möglichkeiten, sich fortzubewegen. Für die durchzuführende Analyse sind Pferd, mit und ohne Kutsche, der Mensch zu Fuß oder mit dem Auto vorgesehen. Darüber hinaus wird der Wasserweg mit Schiff berücksichtigt. Alle weiteren Transportmöglichkeiten sind für diese Arbeit irrelevant. Erweiterungen der Transportmittel sind denkbar, da das System erweiterbar ist.
2.2.2 Transportwege
Unter Transportwegen sind die nutzbaren Wege zu verstehen, die bei der Berechnung der Route eine grundlegende Rolle spielen. Zur Berechnung der Routen, die mit verschiedenen Transportmittel zurückgelegt werden, ist es von Interesse, auch die Wege zu kategorisieren.
Die Beschaffenheiten des zurückzulegenden Wegs entscheiden darüber, welche Transport- mittel zulässig sind. Beispielsweise qualifiziert sich ein Highway, dass Fahrzeuge schneller unterwegs sein können, während ein Feldweg bloß einen Fußgänger oder Pferd zum Ziel bringen kann. Es ist ausreichend zu bemerken, dass die Wege bekannt und entsprechend in den benutzten Datenbanken als Geometrien angelegt sind. Erst daraus lassen sich mög- liche Behinderungen und Begrenzungen herausfinden und entsprechend historisch korrekte Routen errechnen.
2.2.3 Personenklassen
Um hervorzuheben, dass die Klassifizierung des Menschen einen Einfluss auf das Rout- energebnis hat, muss eine möglichst große Diskrepanz der Klasse vorliegen. Um diese Diskrepanz im Rahmen dieser Arbeit bestmöglich zu veranschaulichen, sind die gewählten Klassen an den mittelalterlichen Bauer und Adligen angelehnt. Die Einteilung in solche Klassen ist willkürlich und ist kein unumstößlicher Faktor des zu entwickelnden Systems.
Die Definition basiert auf den gesellschaftlichen Gegebenheiten des Mittelalters, die verein- fachend gesagt eine solche Unterteilung vorgenommen haben. Einem Bauer standen nicht die gleichen Transportmöglichkeiten zur Verfügung, wie einem Adligen. Der Bauer besitzt weniger Ressourcen, um eine Reise zu unternehmen. Typischerweise werden Routen zu Fuß zurückgelegt. Das Reiten eines Pferds ist den wohlhabenden Adligen vorbehalten.
Mehr Ressourcen und klassenabhängige Vorteile ermöglichen dem Adligen eine größere
Kapitel 2 Grundlagen 6
Reichweite und eine höhere Reisefrequenz. Auch Zeit spielt eine Rolle. Dem Bauern bleibt bei allen anfallenden Aufgaben weit weniger Zeit zum Verreisen.
2.2.4 Historische Ereignisse
Bestimmte Ereignisse prägen das historische Routenbild. Aus Konflikten, Eroberungen, Seuchen und Machtausübungen bilden sich Grenzen und trennen geografische Gebiete voneinander. Im Zusammenhang der Routenplanung sind historische Ereignisse somit für den zeitabhängigen Wegverlauf mitverantwortlich. Eine genauere Deutung erfolgt im späteren Verlauf der Arbeit.
2.2.5 Historischer Kontext
Der historische Kontext setzt sich aus mehreren Faktoren zusammen. Hierzu gehören sowohl die Transportmittel als auch die Transportwege. Zudem tragen die Personenklassen zu dem historischen Kontext bei. Die historischen Ereignisse und die Wege-Geometrien aus der OHDM-Datenbank komplettieren eben jenen.
2.3 Koordinatenreferenzsysteme
Da in dieser Arbeit mit Geometrien gearbeitet wird, ist es wichtig, deuten zu können, in welchen Koordinatensystemen sie beschrieben werden. Die meistverbreiteten Indexe der Koordinatenreferenzsysteme sind 3857 und4326, die durch epsg.io definiert werden.
[Pri07] Während Ersteres mit der Einheit in Metern arbeitet, wird beim Zweiten die Einheit in Grad verwendet.
2.3.1 epsg:4326
Das Koordinatensystem gehört zu WGS84 (World Geodetic System 1984). Dieses System wird vor allem für die Verwendung von GPS benötigt. Die Einheit ist in Grad, was dem üblichen Tupel aus Längen und -Breitengrad entspricht.
Kapitel 2 Grundlagen 7
2.3.2 epsg: 3857
Das Koordinatensystem gehört ebenfalls zu WGS84 (World Geodetic System 1984) und findet den Einsatz in Visualisierungsanwendungen, OSM, Google Maps und ähnlichen Pro- grammen. Die Einheit in diesem System ist in Meter.[Pri07] Der Unterschied zu 4326 be- steht darin, dass4326 die gesamte Welt umfasst, während das3857-Koordinatenreferenzsystem nur einen Teil der Welt zwischen 85.06 Grad S. und 85.06 Grad N. beinhaltet. [Pri07] Die Geometrien aus der OHDM-Datenbank, die im weiterem für den Topologieaufbau dienen, werden im3857-Koordinatensystem hinterlegt. Deswegen wird dieses Koordinatensystem für spätere Berechnungen benutzt, um die Fehler bei der Koordinatenumwandlung oder bei der Interpretation der Daten zu vermeiden.
2.4 Routing-Tool
Unter Routing-Tool versteht man in dieser Arbeit ein externes Programm oder eine Biblio- thek, die das Routing-Problem angehen. Im Bereich Routing gibt es mehrere Lösungen, die das Problem einer Routensuche auf verschiedene Weise beheben.
Kapitel 3 Analyse
3.1 Allgemeine Analyse
Für die historische Routensuche gilt es zunächst, sich den damaligen Gegebenheiten zu nä- hern. Da die Globalisierung als Makroprozess das Reiseverständnis maßgeblich verändert hat, sollten die Reisebedingungen und -voraussetzungen in der Zeit vor der Globalisierung genauer betrachtet werden. Wer das Privileg genoss, Reisen anzutreten, wurde maßgeblich durch den sozialen Status bestimmt. Grundsätzlich kann gesagt werden, dass sich die Gesellschaft in eine obere Klasse und eine untere Klasse unterteilt, während das Privileg des Reisens zumeist der Oberen vorbehalten war. Darüber hinaus sind auch der infrastruk- turelle Ausbau und der gefahrlose Zugang von Bedeutung. Territoriale Konflikte führen zu umleitenden Routen, die Auswirkungen auf die Dauer der Reise haben. Restriktio- nen, die kultureller oder religiöser Natur sein können, wirken auf die Reiseplanung und -umsetzung ein. Im Zusammenspiel mit dem Wohlstand einzelner Personen bestimmt es, wohin und mit welchem Transportmittel verreist werden kann. Als Teil des Adels sind weiter entfernte Ziele schneller zu erreichen, da die Route mit Pferd zurückgelegt werden kann. Bei der hypothetischen Routensuche wird davon ausgegangen, dass lediglich ein ein- ziges Transportmittel eingesetzt wird. Ein Wechsel des Mittels während der Zurücklegung einer bestimmten Distanz ist nicht miteinbezogen. Die Kombination von Schiff und einem Überlandtransportmittel ist als Einziges zulässig. Es soll möglich sein, eine Route mit einem Transportmittel berechnen zu können bei der man die Möglichkeit hat, Wasserwege integrieren aber auch ausschließen zu können.
Kapitel 3 Analyse 9
3.2 OHDM Datenbank
Mithilfe des OSMImportUpdate-Tools [Sch17] ist man in der Lage, eine OSM-Datei in die OHDM-Datenbank zu importieren.[Sch19] Dort werden 3 Schemata angelegt:
• intermediate
• ohdm
• rendering
Das ohdm-Schema ist für diese Arbeit interessant, da es dort die Tabelle classification gibt. Diese enthält alle Klassen und Subklassen von Geometrien, die in der Datenbank gespeichert sind. Anhand von diesen Daten kann man Objekte-Geometrien von einander unterscheiden (z. B. highway, railway, waterway). Unter anderem wird das rendering- Schema erstellt, das alle wesentlich für diese Arbeit benötigte Informationen speichert und darstellt. D.h für jede Klasse aus ohdm.classification werden 3 Tabellen angelegt:
• *_lines
• *_points
• *_polygons
Die Tabelle *_lines beinhaltet alle Liniengeometrien, die sich auf die ausgewählte Klassifi- kation beziehen. Die Liniengeometrien allein sind nicht ausreichend, um Routen zu berech- nen. Hierfür wird eine Topologie, die auch als Graph bezeichnet wird, benötigt.[Tan12]
Konkret bedeutet das, einen Graph aus den zur Verfügung stehenden Geometrien zu erstellen. Damit lässt sich im Anschluss eine Route berechnen.
3.3 Technische Analyse (Routing Tool)
Im Bereich des Routing existieren verschiedene Lösungsansätze, die sich über die Jahre eta- bliert haben. Es ist festzustellen, dass die Auswahl des Routing-Tools an eine Reihe Anfor- derungen gekoppelt ist. Hierbei sind Lizenzfreiheit und einfache Integration zu nennen. Die Routing-ToolspgRouting undGraphHopper stehen zunächst in der engeren Auswahl.Gra- phHopper bietet ein breites Funktionalitätsspektrum und Customize-Möglichkeiten.[Gmb]
Es besteht allerdings keine Lizenzfreiheit und kann so bei näherer Betrachtung ausge- schlossen werden. Bei pgRouting handelt es sich um eine Open-Source Bibliothek.[Com19]
Kapitel 3 Analyse 10
Sie erweitert funktionell die PostGIS-Datenbank.[Pos20] Die Bibliothek ist über die freie GPLv2-Lizenz verfügbar. Alle Anforderungen sind mit diesem Tool getroffen und es eignet sich dementsprechend als primäres Routing-Tool. Unter anderem verwendet die Biblio- thek den Dijkstra-, A*- und Shooting Star Algorithmus. Für das Vorgehen innerhalb der Arbeit ist der Dijkstra-Algorithmus von zentraler Bedeutung. Da dieser in der Lage ist, den kürzesten Weg zwischen zwei Knoten innerhalb eines kantengewichteten Graphen zu berechnen, wird er als einziger genauer betrachtet und implementiert. Für die Weiter- entwicklung des Systems soll es in der Zukunft möglich sein, das Projekt mit weiteren Suchalgorithmen auszubauen.
3.4 Topologie
Für die Verwendung des Dijkstra-Algorithmus ist zunächst die Topologie beziehungsweise der Graph Voraussetzung. PgRouting bietet die Methode pgr_createTopology(), die aus Geometrien das Topologie-Netzwerk aufbaut.[Com19] Die Methode bekommt eine Tabel- le mit Geometrien (Kanten), die durch Knoteninformationen erweitert werden. Danach besitzt jede Geometrie eine Id des Startknotens und des Endknotens. Die Informationen über Knoten werden in der separat angelegten Tabelle *_vertices_pgr gespeichert. Den daraus entstandenen Graph kann man theoretisch zum Berechnen einer Route benutzen.
Nun besteht das Problem bei der Vernetzung von Knoten. Es kann vorkommen, dass die Geometrien nicht den eigentlichen Straßen und Wegen entsprechen. Diese Problematik lässt sich auf inkorrekt verbundene Geometrien, auf Isolation bestimmter Geometrien vom restlichen Graph oder fehlende Verbindungen, die vorhanden sein sollten, zurückführen.
Beispielsweise könnten überschneidende Liniengeometrien keinen gemeinsamen Knoten be- sitzen. Die Geometrien sind stark abhängig von der Qualität der importierten OSM-Daten.
Aus diesem Grund wird der Graph in der vorliegenden Arbeit als ungerichtet betrachtet.
Für spätere Weiterentwicklungen wäre es möglich, die gerichteten Graphen einzuführen.
3.4.1 pgr_analyzeGraph()
Die Methodepgr_analyzeGraph() kann eine existierende Topologie nach isolierten Kanten oder Überschneidungen prüfen.[Com19] Dabei spielt der Parameter tolerance mit dem Typfloat8 eine besonders wichtige Rolle. Er ist in der Lage, die Fangtoleranz von nicht
Kapitel 3 Analyse 11
verbundenen Kanten zu beschreiben. Darüber hinaus besitzt er die gleiche Projektionsein- heit, wie die Geometrien aus der Topologie. Ist der Abstand zwischen Knoten geringer als die Toleranz, so werden diese als ein Knoten betrachtet. Da mit der Begriffsklärung das 3857-Koordinatenreferenzsystem als Basiskoordinatensystem festgelegt wurde, erfolgt die Berechnung der Geometrien in der Einheit Meter. Entsprechend definiert eine Toleranz von 1, einen Meter. In diesem Fall würden Knoten, dessen Abstände weniger als 1 Meter sind, als ein gemeinsamer Knoten interpretiert.
Es hat sich ergeben, dass die erzeugten Topologien von pgr_createTopology() meistens nicht sauber sind. Knoten sind oft fälschlicherweise nicht mit einander verbunden oder überschneidende Kanten besitzen kein gemeinsamen Knoten.
3.4.2 pgr_nodeNetwork()
Um das eben genannte Kanten-Problem lösen zu können, gibt es die Methode pgr_nodeN- etwork().[Com19] Sie wandelt die existierende Topologie mit dem vorgegebenen Toleranz- parameter um. Dabei beschreibt die Toleranz genau wie bei pgr_analyzeGraph() den Abstand in der Projektionseinheit der Geometrien (Meter). Die Knoten werden zusam- mengefasst und als ein Knoten dargestellt. Außerdem werden die Knoten und Kanten gelöscht, die keine Verbindung zu dem Graph besitzen.
3.5 Problemstellungen
Reisen in der Vergangenheit birgt einige Probleme. Da auch historische Ereignisse in dem System eine Rolle spielen, müssen sie auch dementsprechend beim Berechnen von Wegen miteinbezogen werden. Es gibt viele Arten von Ereignissen die dadurch abgebildet werden können, z. B. Kriege, Pandemien, aber auch gesellschaftliche Verurteilungen, aufgrund dessen Weiterbewegung nicht immer möglich war. Außerdem stellt sich die Frage, wie die Topologie aussehen wird und welche Informationen dort enthalten werden, um eine Route korrekt zu berechnen. Da in dieser Arbeit kantengewichtete Graphen betrachtet werden, muss entschieden werden, wie die Gewichtsverteilung in den Kanten aussehen soll.
Die bereits beschriebenen Probleme werden im Kapitel Konzeption erläutert und genauer angegangen.
Kapitel 4 Konzeption
Das folgende Kapitel basiert auf den Informationen, die innerhalb der Analyse gewonnen wurden.
4.1 Anforderungen an das zu entwickelnden System(Prototyp)
Das System muss in der Lage sein, anhand verschiedener Informationen eine Route berech- nen zu können. Dabei spielt zunächst das Transportmittel eine wichtige Rolle. Anhand dessen wird bestimmt, welche Art Weg für eine Route genutzt werden kann. Ist es zum Beispiel naheliegend ein Schiff zu benutzen, kann bestimmt werden, ob Wasserwege den Routenweg optimieren könnten. Zudem müssen die Koordinaten des Startziels und Endziels festgelegt sein. Ist ein genaues Datum bestimmt, an dem die Routenplanung durchgeführt werden soll, kann anhand von genaueren Informationen diese Route weiter ausgebaut werden. Diese sind wie bereits erwähnt, die Personenklasse (z. B. der soziale Status des Menschen) und wichtige historische Ereignisse, die dem eingegebenen Datum entsprechen.
Das Ergebnis der Weg-Zeit-Berechnung muss in Tabellenform gespeichert werden.
4.2 Konzeptentwurf
Aus diesem Kapitel lässt sich ein Konzeptentwurf erstellen. Das System besteht aus Personenklassen, Wege-Geometrien der OHDM-Datenbank, Transportmitteln und Gebiete, das den historischen Kontext beinhaltet. In ihrer Gesamtheit repräsentiert es historische
Kapitel 4 Konzeption 13
Ereignisse. Eben jenes ist in der Abbildung 4.1 dargestellt. Aus den jeweiligen historischen Kontexten wird eine Topologie gebildet, da es andernfalls von Ineffizienz zeugt, mehrere Topologien als Datenbanktabellen für unterschiedliche Zeiten und Systemkonstellationen gespeichert zu halten.
Abbildung 4.1: Historischer Kontext
Die Wege-Geometrien werden vom OHDM bearbeitet und zur Verfügung gestellt. Im Gegensatz zu den Wegen werden Transportmittel, Personenklassen und Gebiete exempla- risch aufgefüllt. Da der Autor über keine historische Qualifikation verfügt, werden nicht alle Transportmittel oder Personenklassen aus der ganzen Menschengeschichte genommen.
Es wird an einer Beispielanwendung die Vorgehensweise und Funktionalität erklärt. Das Systems bleibt dabei optimierungsfähig und weiterentwickelbar, was die Erweiterung der Tabellen für Transportmittel, Personenklassen und Gebiete ermöglicht. Da es sich in dieser Arbeit um eine Vorführung der Funktionsweise des System handelt, stellt das Beispiel eine von geofabrik.de zur Verfügung gestellte Karte von Berlin aus dem Jahr 2019 im OSM-Format dar. Die Daten von geofabrik.de [Geo] dienen zur Bildung eines historischen Kontextes, an dessen Beispiel der Prototyp gezeigt wird. Im Kapitel Implementierung werden die nur für diese Arbeit geltenden Daten für Transportmittel, Personenklassen und Gebiete genauer erklärt. Zusammen mit Wegegeometrien von Straßen der Stadt Berlin aus dem Jahr 2019 stellen sie einen historischen Kontext dar, der nur für diese Zeitkonstellation gilt.
Kapitel 4 Konzeption 14
4.3 Interpretierung der historischen Ereignisse
Die historischen Ereignisse spielen eine große Rolle bei der Berechnung einer Route in der Vergangenheit. Die Ereignisse sind immer ortsbezogen und lassen sich auch als Bereiche darstellen. Deswegen besteht die Möglichkeit die Ereignisse als Geometrien zu speichern.
In der Zeit von Kriegen oder anderen menschenfeindlichen Ereignissen(wie z. B. Pest oder Naturkatastrophen) war alleine die Entscheidung des Menschen durch solche Gebiete zu reisen. Die Sicherheit war nicht gewährleistet und somit war der Weg mehr als gefährlich.
Außerdem gab es Gebiete, die für bestimmte Sozialschichten aus verschiedenen Gründen nicht zugänglich waren. Nicht außer Acht zu lassen ist, dass die Ländergrenzen auch darunter fallen. Somit kann man mit den Gebieten auch die Staatsgrenzen beschreiben.
In dieser Arbeit werden diese Gebiete als unzugänglich für bestimmte Personenklassen erklärt. Somit kann eine Route ein Kriegsgebiet oder eine Ländergrenze umgehen. Man darf auch nicht vergessen, dass die historischen Ereignisse immer ein Zeitfenster darstellen.
Aus diesem Grund wird es zwischen Gebieten für verschiedene Zeiten unterschieden. Es werden nur die Gebiete genommen, die für den in der Konfigurationsdatei bestimmten Tag gültiges Zeitfenster aufweisen. Wie es im Konzeptentwurf schon besprochen wurde, werden Gebiete in dieser Arbeit exemplarisch befüllt.
4.4 Kantengewichtung
Da Dijkstra-Algorithmus mit kantengewichteten Graphen arbeitet, muss ein Weg gefun- den werden, die Kanten so zu bewerten, dass Routing allgemein möglich ist. Dabei darf nicht vergessen werden, wie es schon in der Analyse angesprochen wurde, sind die Geome- trien in verschiedene Klassifikationen eingeteilt, die verschiedene Eigenschaften besitzen.
Es ist möglich, alle nützlichen Klassifikationen, die die Straßen und Wege betreffen, in die Gruppen zu unterteilen. Die entstandenen Gruppen werden nun den Transportmit- teln zugewiesen. Damit kann man mit einem Transportmittel nur bestimmte, passende Straßen und Wege benutzen. Vor der Entstehung einer Topologie werden nur die zu dem Transportmittel passenden Geometrien verwendet. Somit kann man innerhalb dieses Topologie-Netzwerks die Länge der jeweiligen Geometrie als Gewichtung nehmen.
Kapitel 4 Konzeption 15
4.5 Interpretation von Klassifikationen
Wie in der Analyse besprochen, werden im Schema rendering drei Tabellen pro Klasse aus der Tabelle classification des Schemas ohdm erstellt. Die für diese Arbeit relevante Tabellen heißen highway_lines und waterway_lines. In der highway_lines werden alle Wege und Straßen abgebildet, die eine Hauptklasse namens highway besitzen. Die Tabelle waterway_linesbildet alle Wasserwege ab, die eine Hauptklasse namenswaterway besitzen.
Eine Klasse wird in Subklassen unterteilt, die die Eigenschaften des Streckenabschnitts aufweisen. Außerdem ist es wichtig deuten zu können, dass die Existenz des Schemas rendering mit den Tabellen highway_lines und waterway_lines die Grundvoraussetzung für eine korrekte Arbeitsweise des Prototyps darstellt.
4.5.1 Interpretation von highway_lines
Jede Geometrie besitzt außer einer Hauptklasse(highway in diesem Fall) eine Subklasse.
Wie schon im Kapitel Grundlagen gesagt wurde, werden in dieser Arbeit ausschließlich folgende Transportmittel betrachtet:
• Mensch zu Fuß
• Kutsche
• Pferd
• Auto
• Schiff
Dies ermöglicht die Zuweisung von Subklassen zu den Transportmitteln. So kann definiert werden, für welche Transportmittel die subklassifizierten Streckenabschnitte zugänglich sind. Nach einer logischen Analyse, ist folgende Tabelle rausgekommen.
Subklasse Transportmittel
motor_way Alle
trunk Alle
primary Alle
secondary Alle
tertiary Alle
Fortsetzung auf der nächsten Seite
Kapitel 4 Konzeption 16
Subklasse Transportmittel unclassified Alle
residential Alle
living_street Alle
pedestrian ’Fuss’ und ’Pferd’
motorway_link Alle
trunk_link Alle
primary_link Alle
secondary_link Alle
service Alle
track Alle
track_grade1 Alle
track_grade2 Alle
track_grade3 Alle
track_grade4 Alle
track_grade5 ’Fuss’ und ’Pferd’
bridleway ’Fuss’ und ’Pferd’
cycleway ’Fuss’ und ’Pferd’
footway ’Fuss’ und ’Pferd’
path ’Fuss’
steps ’Fuss’
unkwown ’Fuss’
undefined ’Fuss’
Tabelle 4.1: Zuweisung der Subklassen
Die Tabelle zeigt, welche Subklassen welche Transportmittel erlauben. Um die Eigenschaf- ten der Subklassen genauer anzuschaen, ist folgende OSM-Dokumentation zu empfehlen [Com18].
4.5.2 Interpretation von waterway_lines
Die Hauptklasse waterway hat ebenfalls einige Subklassen, wie es in der Tabelle 4.2 zu sehen ist.
Kapitel 4 Konzeption 17
Hauptklasse Subklasse
waterway river
waterway stream
waterway canal
waterway drain
Tabelle 4.2: Subklassen der Hauptklasse waterway
Um die Eigenschaften der Subklassen genauer anzuschaen, ist folgende OSM-Dokumentation zu empfehlen [Com18]. In dieser Arbeit wird Reisen mit dem Schiff als zusätzliche Mög- lichkeit, sich fortzubewegen, angeboten. Die Wasserwege werden entweder zur Verfügung gestellt oder einfach ignoriert.
Kapitel 5
Implementierung
Im folgenden Kapitel werden die gewonnenen Erkenntnisse aus der Konzeption umgesetzt und genauer betrachtet. Außerdem wird der Aufbau und die Funktionsweise des Prototyps erklärt.
5.1 Die Grundvoraussetzungen für die OHDM-Datenbank
Da es sich bei dieser Arbeit um eine Erweiterung des Projekts OHDM handelt, müssen folgende Bedingungen erfüllt werden. Sie stellen die Grundvoraussetzungen für korrekte fehlerfreie Arbeitsweise des Prototyps dar.
• Das Schema rendering ist in der Datenbank angelegt und beinhaltet Tabellen high- way_lines und waterway_lines.
• Das Schema routing ist in der Datenbank angelegt.
• Die Datenbank musspgRouting Erweiterung besitzen. Da es in dieser Arbeit OHDM- Datenbank als Grundlage genutzt wird, wird es davon ausgegangen, dass die Daten- bank hstore und postgis Erweiterungen schon besitzt.
Kapitel 5 Implementierung 19
5.2 Aufbau des Prototyps
Für die Implementierung des Systems ist die Wahl auf die Java Programmiersprache und Eclipse Nano als Entwicklungsumgebung gefallen, da es dafür die meisten Vorkenntnisse gibt.
Der Prototyp ist eine Konsolenanwendung, die sequenziell Parameter einliest und benötigte Tabellen zur Berechnung einer Route erstellt. Am Ende einer Rechnung werden zwei Tabellen result_way_table und result_time_table mit dem Ergebnis einer Routensuche angelegt, sodass die gewünschte Route und die aufgewendete Zeit veranschaulicht werden können. Ist es nicht möglich, einen Weg zwischen zwei Knoten zu finden, beinhalten die Ergebnistabellen keine Einträge.
Wie in der Abbildung 5.1 gezeigt, bekommt die Anwendung zwei Dateien mit Konfigura- tionsparametern, eine zum Aufbau der Verbindung mit der Datenbank und eine weitere zur Definition der Suchparameter. Danach werden die Tabellen für unzugängliche Gebie- te, Transportmittel, Personenklassen angelegt und befüllt. Davon ausgeschlossen ist die Tabelle für unzugängliche Gebiete, da das Befüllen später nach dem Anlegen der Tabelle routing_topology_noded_vertices_pgr erfolgt. Als Nächstes wird eine Geometrien-Tabelle routing_topology erstellt und mit ausgewählten Informationen aufgefüllt. Daraus wird ein Topologie-Netzwerk kreiert, das die dazugehörige von pgRouting erzeugte Tabelle rou- ting_topology_vertices_pgr umfasst. Da die Knoten in der Topologie nicht immer korrekt verbunden sind, wird eine weitere Tabelle routing_topology_noded erstellt, die die Kno- ten miteinander zusammenschweißt und unerreichbare Knotenpunkte entfernt. Aus der routing_topology_noded-Tabelle wird eine Topologie mit der zugehörigen routing_topo- logy_noded_vertices_pgr-Tabelle erstellt. Daraus resultiert die Anlegung und Befüllung zweier Tabellen, result_way_table undresult_time_table, die das Ergebnis der durchge- führten Suche beinhalten. Die Tabelle result_way_table enthält die Information über den Weg, Geometrien und Knoten der Topologie. Die Tabelle result_time_table liefert Infor- mationen über die benötigte Reisedauer. Spaltefull_time beschreibt die gesamte Reisezeit im Format HH-MM-SS. Die Länge der zurückgelegten Strecke wird in zwei Abschnitte un- terteilt. Die Abschnitte werden als Strecke auf dem Land (distance_without_water-Spalte) und als Strecke auf dem Wasser (distance_water-Spalte) in Meter interpretiert.
Kapitel 5 Implementierung 20
Abbildung 5.1: Sequenzdiagramm zum Aufbau des Prototyps
5.3 Konfigurationsparameter
Die Konfigurationsdateien sind zwei .txt-Dateien, die mit folgenden Präfixen ausgelesen werden:
• -r [filename] (Beschreibt die Verbindung zur Datenbank und Schema, in dem die erstellten Tabellen angelegt werden)
• -s [filename] (Beschreibt die Suchparameter für das System)
5.3.1 Konfigurationsdatei zum Aufbau der Verbindung
Die Textdatei besteht aus folgenden Parametern die zum Aufbau der Verbindung dienen:
Kapitel 5 Implementierung 21
• servername:[Name des Servers mit der OHDM-Datenbank]
• portnummer:[Portnummer]
• username:[Username für den Zugang zum Server]
• pwd:[Passwort für den Zugang zum Server]
• dbname:[Name der Datenbank]
• schema:[Name des Schemas, in dem die Tabellen angelegt werden(im Falle dieser Arbeit heißt es routing]
5.3.2 Suchparameter-Konfigurationdatei
Die Textdatei besteht aus folgenden Parametern, die die Suchrahmen definieren:
• classofperson:[ID aus der people-Tabelle]
• transporttype:[ID aus der transport_mittel-Tabelle]
• waterwayincl:[true/false]
• startpoint:[Längengrad Breitengrad]
• endpoint:[Längengrad Breitengrad]
• day:[YYYY-MM-DD]
5.4 Parameter für historischen Kontext
Nachdem die Konfigurationsdateien ausgelesen sind, werden Tabellen für Transportmittel, Personenklassen und unzugängliche Gebiete in einem separaten Schema aus der Kon- figuration angelegt und befüllt. Die Befüllung erfolgt, wie es schon im Konzeptentwurf beschrieben wurde, exemplarisch und kann nach Bedürfnis optimiert werden. Die Belegung der restricted_area Tabelle erfolgt nicht an dieser Stelle, sondern nachdem die Topologie erstellt ist. Die knotenbezogene Erzeugung der Geometrie für das entsprechende Gebiet macht dies an dieser Stelle notwendig.
Kapitel 5 Implementierung 22
5.4.1 Transportmittel
Die Datenbanktabelle transport_mittel ist in drei Spalten unterteilt:
• id serial PRIMARY KEY
• type VARCHAR (255) UNIQUE NOT NULL
• speed INTEGER
Sie legt die Kriterien für die Transportmittel fest. Die Spalte type beschreibt den Namen für ein Transportmittel, wobei speed eine konstante Geschwindigkeit definiert. Diese Ta- belle legt die Transportmöglichkeiten für eine bestimmte Konstellation des Systems fest.
Im Kapitel Grundlagen wurde das Thema Transportmittel schon angesprochen und die nur für diese Arbeit geltende Transportmittel beschrieben. Wie die Datenbank-Tabelle transport_mittel belegt wird, kann man in der folgenden Tabelle nachschauen:
id type speed
1 Fuss 6
2 Pferd 50
3 Kutsche 9
4 Auto 60
5 Schiff 12
Tabelle 5.1: transport_mittel Datenbanktabelle
Die Geschwindigkeiten werden als Konstanten definiert und werden in km/h betrachtet.
Daraus ergibt sich die Annahme, dass die Fortbewegungsgeschwindigkeit immer konstant bleibt. Das bietet eine Grundlage für eine spätere Erweiterung des Systems, um die Geschwindigkeit dynamisch zu berechnen.
5.4.2 Personenklassen
Für die Datenbanktabelle person ergeben sich zwei Spalten:
• id serial PRIMARY KEY
• titel VARCHAR (255) UNIQUE NOT NULL
Kapitel 5 Implementierung 23
Die Spaltetitel beschreibt den Namen für eine Personenklasse. Darunter kann man verschie- dene Personenklassen einführen. Eine solche Klassifizierung kann beispielsweise anhand des sozialen Status einer Person erfolgen. Die Daten müssen historisch korrekt sein und den Menschen der jeweiligen Zeit entsprechen, um sie zu repräsentieren. In dieser Arbeit werden zwei Klassen der Personen eingeführt, um die Funktionsweise des Systems zu zeigen. In der Tabelle werden die nur für diese Arbeit definierten Daten gezeigt:
id titel
1 Bauer
2 Adliger
Tabelle 5.2: person Datenbanktabelle
Die Personenklasse Bauer mit der ID ’1’ soll einen einfachen Bauer darstellen. Die Perso- nenklasse Adliger mit der ID ’2’ stellt im Gegenteil zur Klasse Bauer eine höher in der Gesellschaft gestellten Person dar.
5.4.3 Unzugängliche Gebiete
Die Datenbanktabelle restricted_area besitzt fünf Spalten:
• id INTEGER PRIMARY KEY
• area geometry
• closedfor INTEGER
• valid_since DATE
• valid_until DATE
Die Spalte area beschreibt die Geometrie des gespeicherten Polygons. Das Polygon stellt in diesem Fall ein Gebiet dar, deren Grenzen für bestimmte Personenklassen nicht über- schritten werden dürfen. Die Spalte closedfor bezieht sich auf die ID der Personenklasse aus der person-Tabelle. Somit werden bestimmte Bereiche, dessenclosedfor-Wert gleich der ID der Klasse des reisenden Menschen ist, für Routing irrelevant erklärt. Die Werte der Spalten valid_since und valid_until rahmen den Gültigkeitsbereich in ein Zeitfenster ein.
Da die Daten in dieser Anwendung exemplarisch befüllt werden, wird ein Beispielgebiet im Zentrum der Stadt Berlin im Jahr 2019 eingeführt. Dieses Gebiet repräsentiert einen
Kapitel 5 Implementierung 24
hypothetischen Pestausbruch. Es wird angenommen, dass der Zugang zu dem Gebiet für einen Reisenden mit der Personenklasse Adliger verweigert wird. Die Person mit der PersonenklasseBauer dagegen das Gebiet betreten, weil es ihm nicht bewusst ist, dass die Pest in diesem Bereich ausgebrochen ist. Das Zeitfenster des Gebiets des exemplarischen Falls wird so angepasst, dass es mit dem Gültigkeitsbereich der Straßen und Wege aus der importierten OSM-Datei übereinstimmt. Die befüllterestricted_area-Tabelle zeigt die folgende Tabelle:
id area clodsedfor valid_since valid_until
1 0103000020110F0000010000000500... 2 2018-11-01 2019-12-10 Tabelle 5.3:restricted_area Datenbanktabelle
Die Abbildung 5.2 zeigt die exemplarische Polygongeometrie der restricted_area, die das
"Pestgebiet"repräsentieren soll.
Abbildung 5.2: Exemplarische Polygongeometrie der restricted_area-Tabelle
Kapitel 5 Implementierung 25
5.5 Aufbau der Topologie
Im ersten Schritt wird die Tabelle routing_topology mit der Struktur der Tabelle high- way_lines angelegt.[Sch19] Folgende Spalten sind für diese Arbeit von Relevanz:
• line – [geomentry] beschreibt die Geometrie
• classid – [bigint] beschreibt die ID der Subklasse der Geometrie
• subslassname – [character varying] beschreibt den Namen der Subklasse der Geome- trie
• valid_since – [date] beschreibt das Datum, seit wann die Geometrie gültig ist
• valid_util – [date] beschreibt das Datum, bis wann die Geometrie gültig ist
Nach Anlegung der routing_topology-Tabelle wird sie mit Geometrien befüllt. Wie schon im Kapitel Konzeption besprochen, werden die Geometrien genommen, die eine zu dem ausgewählten Transportmittel passende Subklasse aufweisen. Die Auswahl der Geome- trien richtet sich nach den valid_since und valid_until Werten, die den Tag aus der Suchparameter-Konfigurationsdatei eingrenzen. Nachdem die Basistabelle routing_topolo- gy mit Geometrien, entsprechend dem in der Konfigurationsdatei definierten Transport- mittel und dem Datum, aufgefüllt ist, wird sie um zwei Spalten erweitert :
• source – [bigint]
• target – [bigint]
Die zwei hinzugefügten Spalten dienen dem späteren Aufbau der Topologie. Im Anschluss wird die Tabellerouting_topology um die Spalte ID mit dem Typ Serial erweitert, sodass jede Geometrie aus der Tabelle eine eindeutige ID bekommt.
Als Nächstes wird die Topologie erstellt, indem manpgr_createTopology() Funktion über existierende Geometrie-Tabelle laufen lässt. Als Parameter müssen der Name der Tabel- le und die Toleranzgrenze übergeben werden. Weicht der Spaltenname, in diesem Fall der Geometriespalte, vom dokumentierten Namen ab, muss die Übergabe des abweichen- den Namens nach Eingabe der Toleranzgrenze erfolgen.[Com19] Die pgr_createTopology() Funktion verbindet die Knoten unter der Toleranzgrenze und befüllt die Spaltensourceund target der Tabellerouting_topologymit den IDs aus der neu angelegten Tabellerouting_to- pology_vertices_pgr. Dierouting_topology_vertices_pgr Tabelle enthält die Information
Kapitel 5 Implementierung 26
über Knoten im Topologie-Netzwerk und wird nach dem Ablauf der pgr_createTopology() Funktion angelegt und aufgefüllt.
Nach der Erstellung der Topologie kommt die pgr_nodeNetwork() Funktion zum Einsatz.
Wie schon im Kapitel Konzeption erwähnt, erzeugt die Funktion eine neue Geometrien- Tabelle, bei der die Knoten, im Abstand weniger als die Toleranzgrenze, als ein Knoten interpretiert werden und die unerreichbare Segmente der Topologie entfernt werden. Die Funktion bekommt den Namen der Topologie-Tabelle als Parameter, die Toleranzgrenze in Meter und Namen der Spalten, falls einige sich von in der Dokumentation beschriebenen Namen unterscheiden. Nach dem Ablauf der Funktion entsteht eine neue Tabelle rou- ting_topology_noded. Diese Tabelle übernimmt für jede neue entstandene Geometrie eine neue ID. Die Spalte old_id speichert den Verweis auf alte IDs, die derrouting_topology Tabelle entstammen.
In der Folge wird die pgr_createTopology() Funktion für die neue Tabelle routing_topolo- gy_noded aufgerufen. Die Funktion erstellt eine neue Tabellerouting_topology_noded_ver- tices_pgr, die Informationen über Knoten der neu entstandenen Topologie aufweist. Außer- dem werden die Spalten source und target mit ID’s der Knoten aus der neu angelegten routing_topology_noded_vertices_pgr Tabelle belegt.
5.6 Gewichtung
Um Routing in der Topologie zu ermöglichen, fehlt es an dieser Stelle an Gewichtung. Wie im Kapitel Konzeption schon beschrieben, wird die Topologie mit der Länge der einzelnen Geometrien ausrouting_topology_noded bewertet. Es wird eine neue Spalte namenslength mit dem Typen double precision angelegt. Mittels MethodeST_Length()von postgis wird die Spalte length mit den Längen der entsprechenden Geometrien in Meter befüllt.[Pos20]
Im weiteren Ablauf der Arbeit wird es bei den mit ST beginnenden Funktionen auf die gleiche Dokumentation verwiesen.
5.7 Ausschließen der Gebiete
An dieser Stelle erfolgt die exemplarische Auffüllung der Tabellerestricted_area. Da die Anlegung der Geometrien für diese Tabelle Topologie-Knoten-orientiert ist, darf diese erst
Kapitel 5 Implementierung 27
nach der Entstehung der Topologie erfolgen. Das Gebiet wird anhand von Informationen über Knoten der Topologie gebildet.
In dieser Arbeit werden keine wirklichen historischen Ereignisse dargestellt, sondern nur ein vordefiniertes Beispiel, um die Funktions- und Arbeitsweise des Systems zu zeigen.
Es wird angenommen, dass ein Gebiet in Berlin-Mitte existiert, das den Zustand eines Pestausbruchs repräsentiert. Dieses Gebiet wird für die Personenklasse Adlige mit der ID
= 2 als unzugänglich erklärt. Begründet ist diese Zugangssperre mit der Angst um ihre Ge- sundheit. Der PersonenklasseBauer ist dagegen der Zutritt gewährt, da die Bauern-Klasse über den Pestausbruch nicht informiert wird. Außerdem werden die Gültigkeitsdaten für die Geometrie belegt. Die Spaltenvalid_since undvalid_until beschreiben das Zeitfenster, in dem das Gebiet gültig ist.
Um das Ausschließen der Gebiete zu ermöglichen, werden die innerhalb der Gebiete aus der restricted_area liegenden Geometrien für bestimmte Personenklasse und für bestimm- tes Reisedatum aus der Topologie entfernt. Das erfolgt durch die Suche nach den ID’s der Knoten aus der routing_topology_noded_vertices_pgr Tabelle. Mithilfe der Funkti- on ST_Intersects() werden Punkte-Geometrien aus der routing_topology_noded_verti- ces_pgr Tabelle gesucht, die innerhalb von Geometrien aus der restricted_area Tabelle liegen. Die ID’s von den gefundenen Punkten werden in den Spalten source und target der routing_topology_noded Tabelle gesucht. Falls solche Eintrage in der routing_topolo- gy_noded Tabelle gefunden werden, werden diese gelöscht. So werden die Geometrien aus der Topologie gelöscht, deren Anfangs- und Endknoten innerhalb der Geometrien aus der restricted_area Tabelle liegen.
5.8 Ermittlung der Start- und Endknoten
Um die Start- und Endknoten zu ermitteln, werden im ersten Schritt die aus der Konfigu- rationsdatei ausgelesenen Start- und Endkoordinaten bearbeitet. Gesucht sind Punkte aus der routing_topology_noded_vertices_pgr Tabelle, deren Abstände jeweils zu den Start- und Endpunkten aus der Konfiguration am kleinsten sind. Das erfolgt mithilfe von Funk- tion ST_Distance(), wobei jeweils nach genau einem Eintrag für Start- und Endpunkten gesucht wird. Es ist wichtig anzumerken, dass das Eingabeformat der Koordinaten nicht dem Format der gespeicherten Geometrien entspricht. Die Start- und Endkoordinaten werden im Format [Längengrad Breitengrad] eingegeben. Daraus ergibt sich, dass die Punkte-Geometrie mit Längen- und Breitengrad als Geometrie des Koordinatensystems
Kapitel 5 Implementierung 28
mit dem epsg-Index 4326 eingegeben werden müssen und danach mithilfe der Funktion ST_Transform() in das Koordinatensystem mit dem epsg-Index 3857 umgewandelt wer- den müssen. Die gefundenen Elemente sind ID’s der Knoten der Topologie, die den Start- und Endpunktekoordinaten aus der Konfiguration am nächsten liegen.
5.9 Berechnung einer Route mithilfe von
pgr_dijkstra() und Befüllung der Tabelle result_way_table
Zum Schluss wird der eigentliche Weg berechnet und die Ergebnisse in separat angelegten Tabellen result_time_table und result_way_table einsehbar gespeichert.
Zum Berechnen von Routen wird die Funktion pgr_dijkstra()verwendet. Dabei ist wichtig zu erwähnen, dass die Funktion die Tabelle mit der Topologie routing_topology_noded als Eingabeparameter bekommt. Die Spalte length wird als Spaltecost interpretiert, um die Gewichtung zu ermöglichen. Die in Ermittlung der Start- und Endknoten gefundenen Knotenpunkte werden ebenso als Parameter für die Suche übergeben. Außerdem muss der Parameter directed auf false gesetzt werden, um aufzuzeigen, dass es sich in dem Fall um keinen gerichteten Graphen handelt. Die Ergebnisse werden nach Ablauf der Funktion pgr_dijkstra mithilfe von INNER JOIN-SQLOperator um weitere Spalten aus der rou- ting_topology_noded Tabelle erweitert und in der angelegten Tabelle result_way_tablege- speichert.[Pos19] Wichtig ist dabei, dass dieid-Spalte der Tabellerouting_topology_noded der neuentstandenen edge-Spalte entspricht. Die beiden Spalten beziehen sich auf die gleiche ID der jeweiligen Geometrie.
Falls die Tabelle result_way_table keine Einträge besitzt, gibt es keine Wege zwischen zwei ausgewählten Punkten.
Um eine zusätzliche Information darstellen zu können, wird eine neue Spaltesubclassfür die Ergebnistabelleresult_way_table eingeführt. Nach dem erfolgreichen Ablauf der Funktion wird die Spalte angelegt und mit der Information über die Subklasse der Geometrie aus der routing_topology Tabelle befüllt. Mit vorliegenden Informationen ist es möglich, die einzelnen Abschnitte des Weges zwischen verschiedener Subklassen zu unterscheiden.
Kapitel 5 Implementierung 29
5.10 Berechnung der Reisezeit und Befüllung der Tabelle result_time_table
In der result_way_table Tabelle wird der eigentliche Weg gespeichert und dargestellt.
Die Tabelle besitzt aber keine Informationen über die Reisedauer. Um die Reisezeit zu ermitteln, müssen die Längen der Abschnitte auf dem Land und Wasser berechnet werden.
Das ist notwendig, weil die Fortbewegungsgeschwindigkeiten auf dem Land und Wasser sich unterscheiden. Aus der Tabelle result_way_table werden die Längen der jeweiligen Reiseabschnitte für Land und Wasser anhand von Informationen aus der Spalte subclass ermittelt und in den Spalten distance_without_water und distance_water der Tabelle result_time_table gespeichert. Um die Gesamtreisezeit darstellen zu können, wird die Spalte full_time mit der Information über die gebrauchte Reisezeit belegt. Es erfolgt, indem man die Streckenlängen auf dem Land und Wasser durch die Geschwindigkeiten der jeweiligen Transportmittel teilt. Die ermittelten Zeiten für die Wege auf dem Land und Wasser werden addiert und in der full_time Spalte im Format HH:MM:SS gespeichert.
5.11 Auswertung der Ergebnistabellen
5.11.1 Interpretation der Spalten der Tabelle result_way_table
Die folgende Tabelle soll einen Überblick der Ergebnistabelleresult_way_tableverschaffen.
Dort werden die einzelnen Spalten zusammengefasst und ihre Bedeutungen erklärt.
Spaltenname Interpretation
id neu generierte ID der Geometrie nach dem Ablauf der pgr_nodeNetwork() old_old alte ID der Geometrie vor dem Ablauf der pgr_nodeNetwork()
path_seq ID des Wegabschnitts
source Startknoten des Wegabschnitts
target Zielknoten des Wegabschnitts
edge ID der Geomentrie
cost Länge des Abschnitts
agg_cost Gesamtlänge der zurückgelegten Strecke bis zum ausgewählten Knoten
line Geometrie des Wegabschnitts
Tabelle 5.4: Interpretierung derresult_way_table Datenbankrabelle
Kapitel 5 Implementierung 30
5.11.2 Interpretation der Spalten der Tabelle result_time_table
Die Tabelle zeigt ebenfalls wie die Tabelle aus der Interpretation der Spalten der Tabelle result_way_table eine Übersicht der Spalten der Ergebnistabelle result_time_table und ihre Bedeutungen:
Spaltenname Interpretation
id ID der berechenden Route
distance_without_water zurückgelegte Strecke auf dem Land distance_water zurückgelegte Strecke auf dem Wasser
full_time Gesamtdauer
Tabelle 5.5: Interpretierung der result_time_table Datenbankrabelle
Kapitel 6 Test
In dieser Arbeit wurde die Arbeitsweise des entwickelten Systems an einem konkreten Beispiel von Berlin aus dem Jahr 2019 gezeigt. Da der Autor kein ausgebildeter Historiker ist, wäre es schwer zu beurteilen, ob die Durchführung der Routensuche mit den histori- schen Ereignissen im Einklang steht. Aus der Sicht des Autors wäre ein Test dann möglich, wenn die Daten zum Befüllen vontransport_mittel, person,restricted_area Tabellen auf einer historisch bewiesenen Grundlage basieren. Außerdem muss die Person, die den Test auswertet, ausreichende Kenntnisse im Bereich Geschichte besitzen. Ein solcher Test erfor- dert einen enormen Aufwand, da die Daten fast nur händisch zu prüfen sind. Aus diesen Gründen wird es in dieser Arbeit auf Unit-Tests verzichtet. Es werden im Gegenzug zwei stichprobenartigen Test betrachtet. In der Konzeption wurde festgelegt, dass die Tabelle person zwei Personenklassen Bauer und Adliger besitzt. Am Beispiel der Routensuche mit diesen zwei Personenklassen in Berlin 2019 wird die Arbeitsweise des entwickelten Systems vorgestellt.
Für beide Beispiele gelten allgemeine Kriterien. Der Bauer undAdliger reisen in der glei- chen Zeit und haben gleiche Start- und Endpunkte ihrer Reise. Für beide Personenklassen gelten gleiche Straßen und Wege. Es kann sich aber an die Wahl des Transportmittels und Benutzung der Wasserwege unterscheiden. Der hypothetische Pestausbruch im dar- gestellten Gebiet zeigt die Unterschiede beim Berechnen einer Route für unterschiedliche Personenklassen auf. Die hier verwendeten Start- und Endpunkte aus der Konfigurations- datei werden mithilfe vom gpskoordinaten.de [gpsnd] Online-Service ermittelt.
Kapitel 6 Test 32
6.1 Der Weg für die Personenklasse Bauer
Da angenommen wird, dass der Bauer sich nur zu Fuß("transporttype:1") und ohne Benutzung der Wasserwege("waterwayincl:false") fortbewegen kann, sieht die im Code Snippet 6.1 dargestellte Suchparameter-Konfigurationsdatei für die Personenklasse Bau- er("classofperson:1") wie folgt aus:
1 classofperson:1 2 transporttype:1 3 waterwayincl:false
4 startpoint:13.441565508422855 52.46982751967408 5 endpoint:13.396332735595706 52.59831599013319 6 day:2019-12-10
Code snippet 6.1: Suchparameter-Konfigurationsdatei für die PersonenklasseBauer
Die Abbildung 6.1 zeigt die Topologie für die Personenklasse Bauer mit dem Transport- mittel Fuss:
Abbildung 6.1: Topologie für die Personenklasse Bauer mit dem Transportmittel Fuss
Kapitel 6 Test 33
Wie es in der Abbildung 6.2 zu sehen ist, lässt sich eine Route für die Personenklasse Bauer aus der result_way_table-Tabelle im Geometrieform darstellen:
Abbildung 6.2: Das Ergebnis der Routensuche für PersonenklasseBauer im Geometrieform
Die Abbildung 6.3 zeigt die result_time_table-Ergebnistabelle. Daraus lassen sich die Informationen über die Länge des Weges vom Startknoten zum Endknoten am Land(di- stance_without_water) und auf dem Wasser(distance_water) jeweils in Meter, sowie die Gesamtzeit für die komplette Route(full_time) im HH:MM:SS Format ablesen.
Kapitel 6 Test 34
Abbildung 6.3: Das Ergebnis der Routensuche für PersonenklasseBauer als Weg auf dem Land und Wasser und die gesamte Reisezeit
6.2 Der Weg für die Personenklasse Adliger
Für die Personenklasse Adlige("classofperson:2") werden andere als fürBauer Konfigurati- onsparameter genommen, um den Unterschied einer Routensuche darzustellen. Unterande- rem wird es der Person mit der Personenklasse Adliger Reisen mit einem Pferd("transport- type:2") und Benutzung der Wasserwege("waterwayincl:true") erlaubt. Das Code Snippet 6.2 zeigt die Suchparameter-Konfigurationsdatei für die Personenklasse Adliger.
1 classofperson:2 2 transporttype:2 3 waterwayincl:true
4 startpoint:13.441565508422855 52.46982751967408 5 endpoint:13.396332735595706 52.59831599013319 6 day:2019-12-10
Code snippet 6.2: Suchparameter-Konfigurationsdatei für die Personenklasse Adliger
Kapitel 6 Test 35
Die Abbildung 6.4 zeigt die Topologie für die Personenklasse Adliger mit dem Trans- portmittel Pferd. Darin ist ein Loch erkennbar. Dieses Loch markiert das ausgeschlossene Gebiet, das einen Pestausbruch darstellen soll.
Abbildung 6.4: Topologie für die Personenklasse Adliger mit dem Transportmittel Pferd
In der Abbildung 6.5 wird die Ergebnisroute für die Personenklasse Adliger aus der result_way_table-Tabelle präsentiert.
Abbildung 6.5: Das Ergebnis der Routensuche für PersonenklasseAdliger im Geometrie- form
Kapitel 6 Test 36
In der Abbildung 6.6 wird die result_time_table-Ergebnistabelle dargestellt:
Abbildung 6.6: Das Ergebnis der Routensuche für Personenklasse Adliger als Weg auf dem Land und Wasser und die gesamte Reisezeit
6.3 Auswertung der Ergebnisse
Da die Struktur des Tests für die Personenklasse Bauer und Adliger sich nicht unterschei- den, erfolgt grundsätzlich der gleiche Test. Da die Einflussfaktoren auf die Routensuche für die PersonenklasseBauer nicht den des Adligen gleichen, ergeben sich unterschiedliche Resultate.
Wie die zwei vorangegangenen Tests gezeigt haben, unterscheiden sich die Ergebnisse der Routensuche. Der Bauer muss die Strecke zu Fuß überwinden und kann durch das Pestgebiet problemlos reisen. Der Adlige reist auf einem Pferd und darf das Pestgebiet im Gegensatz zum Bauer nicht betreten und ist gezwungen, einen Umweg zu nehmen. Die Geschwindigkeit, mit der man zu Fuß unterwegs ist, beträgt 6 km/h. Die Geschwindigkeit eines Pferdes wird als 50 km/h definiert. Die Strecke, die der Bauer gemäß der Routensu- che zurücklegen würde, ist in ihrer Gesamtlänge kürzer als die des Adligen. Während der Adlige eine Gesamtstrecke von 40,919 km zu bewerkstelligen hat, beträgt die Gesamtlänge der Strecke für den Bauern nur 26,714 km. Da dem Bauern aber keine Pferde oder etwaige Transportmittel zur Verfügung stehen, ist er nichtsdestotrotz 4 Stunden, 27 Minuten und 8 Sekunden zu Fuß unterwegs. Obwohl die Strecke für den Adligen um einiges länger ist, braucht dieser lediglich 49 Minuten und 6 Sekunden. Diese Diskrepanz ist darauf zurück- zuführen, dass der Adlige sich mit dem Transportmittel Pferd und einer Geschwindigkeit von 50 km/h auf den Weg machen kann.
Kapitel 7 Fazit
Abschließend kann gesagt werden, dass mithilfe des entwickelten Systems eine Antwort auf die Suche nach einer Möglichkeit der Routenplanung im Rahmen eines historischen Kontextes gefunden wurde. Das ergänzend zum OHDM-Projekt entwickelte System kann als angemessene Antwort auf die Frage nach einer möglichen Implementierung verstanden werden. In Konklusion wurde das Problem der Routensuche in Anbetracht historischer Karten unter Berücksichtigung verschiedener Einflussfaktoren und Transportmittel er- kannt und gelöst. Die vorliegende Arbeit hat einen Weg gefunden, historische Ereignisse in der Datenbank zu speichern und zu interpretieren. Die Möglichkeit, verschiedene Per- sonengruppen zu klassifizieren gewährleistet eine individualisierte Routensuche. Obwohl die Differenzierung der einzelnen Transportwege im Rahmen dieser Arbeit eher ungenau erfolgt, lässt sich bereits erkennen, dass eine solche Klassifizierung von enormer Bedeutung ist. Unter ungenau ist in diesem Zusammenhang zu verstehen, dass die Gegebenheiten des Wegs hier nur grundsätzlich unterschieden werden. Detailliertere Distinktionen wä- ren denkbar und würden die Ergebnisse einer spezifischeren Fragestellung optimieren. Es bleibt anzumerken, dass die Einflussfaktoren variabel sind. Sie können demnach genau an Fragestellungen angepasst werden. Auch die Transportmittel sind nicht auf die hier angegebenen Fortbewegungsmittel beschränkt. Sie können nach Belieben erweitert und spezifiziert werden. Die beispielhafte Distinktion der Personen in Bauern und Adligen ist angemessen, da es größtmögliche Unterschiede innerhalb eines zu betrachtenden Faktors aufzeigt, ohne unnötige Verständnisschwierigkeiten zu schaffen.
Da damit gerechnet wird, dass das System weiterentwickelt und ausgebaut wird, wurde der Prototyp mit diesen Gedanken implementiert. Die Definitionstabellen person,trans- port_mittel und restricted_area lassen sich leicht ändern und anpassen. Damit ist man nicht an eine Zeit gebunden. Das macht das System flexibel und anpassbar. Die größte
Kapitel 7 Fazit 38
Schwierigkeit stellten die Transportwege und -mittel dar. Es musste ein Weg gefunden werden, Transportwege zu klassifizieren und in Verbindung mit verschiedenen Transport- mitteln zu setzen, wie in der Konzeption vorgesehen. Mit der gelungenen Überwindung dieser Schwierigkeit ist die unterschiedliche Berechnung der benötigten Zeiten für Wege auf dem Land und dem Wasser gewährleistet.
In dieser Arbeit sind die Geschwindigkeiten der Transportmittel als Konstanten definiert.
Wie sich am Ende der Arbeit herausgestellt hat, ist die dynamische Berechnung der je- weiligen Transportmittel-Geschwindigkeit möglich. Die Grundlage dafür soll die Spalte tags mit dem Typ hstore der Tabelle routing_topology liefern.[Pos19] Dort werden die zusätzlichen Informationen zu dem Wegabschnitt definiert, wobei maxSpeed und surface die maximal erlaubte Geschwindigkeit und die Art der Oberfläche des Abschnittes be- stimmen. Die Einträge sind nicht flächendeckend belegt, was eine genaue Auswertung der Daten behindert. Deswegen wird hier die dynamische Berechnung der Geschwindigkeit als nächstmögliche Erweiterung des Systems betrachtet. Abschließend kann gesagt werden, dass der hier vorgestellte Prototyp des entwickelten Systems die Brücke zwischen den historischen Karten und einer fragenspezifischen Routenplanung schlagen kann.
Abbildungsverzeichnis
4.1 Historischer Kontext . . . 13 5.1 Sequenzdiagramm zum Aufbau des Prototyps . . . 20 5.2 Exemplarische Polygongeometrie der restricted_area-Tabelle . . . 24 6.1 Topologie für die Personenklasse Bauer mit dem Transportmittel Fuss. . . 32 6.2 Das Ergebnis der Routensuche für Personenklasse Bauer im Geometrieform 33 6.3 Das Ergebnis der Routensuche für Personenklasse Bauer als Weg auf dem
Land und Wasser und die gesamte Reisezeit . . . 34 6.4 Topologie für die Personenklasse Adliger mit dem Transportmittel Pferd . 35 6.5 Das Ergebnis der Routensuche für Personenklasse Adliger im Geometrieform 35 6.6 Das Ergebnis der Routensuche für PersonenklasseAdliger als Weg auf dem
Land und Wasser und die gesamte Reisezeit . . . 36
Tabellenverzeichnis
4.1 Zuweisung der Subklassen . . . 16
4.2 Subklassen der Hauptklassewaterway . . . 17
5.1 transport_mittel Datenbanktabelle . . . 22
5.2 person Datenbanktabelle . . . 23
5.3 restricted_area Datenbanktabelle . . . 24
5.4 Interpretierung der result_way_table Datenbankrabelle . . . 29
5.5 Interpretierung der result_time_table Datenbankrabelle . . . 30
Source Code Content
6.1 Suchparameter-Konfigurationsdatei für die Personenklasse Bauer . . . 32 6.2 Suchparameter-Konfigurationsdatei für die Personenklasse Adliger . . . 34
Literaturverzeichnis
[Lot11] W. Lotz. Verkehrsentwicklung in Deutschland 1800-1900. BoD-Books on De- mand, 2011.
[Pal85] R. Palm. Die Brücke von Remagen: der Kampf um den letzten Rheinübergang:
ein dramatisches Stück deutscher Zeitgeschichte. München, Stuttgart: Deutscher Bücherbund, 1985.
[Tan12] A.S. Tanenbaum. Computernetzwerke. 5th. München: Pearson Studium, 2012.
[Wie39] K. Wiedenfeld. Die Standorte der Wirtschaftsformen im Spiegel der Verkehrs- mittel. In: Die Raumbeziehungen im Wirtschaften der Welt. Berlin, Heidelberg:
Springer, 1939.
Onlinereferenzen
[Com18] Creative Commons. Open Street Map Data Extracts. 2018. url: https : / / download.geofabrik.de/osm-data-in-gis-formats-free.pdf.
[Com19] Creative Commons.pgRouting Manual. 2019.url:https://access.crunchydata.
com / documentation/ pgrouting / 2 . 6 . 2 / pdf / pgrouting . pdf (besucht am 28. 01. 2019).
[Geo] Geofabrik. Geofabrik.de. url:https://www.geofabrik.de/.
[Gmb] GraphHopper GmbH. GraphHopper. url:https://www.graphhopper.com/.
[gpsnd] gpskoordinaten.de.GPS Koordinaten. n.d.url:https://www.gpskoordinaten.
de.
[Kel18] S.F. Kellerhoff. Diese Brücke verkürzte den Zweiten Weltkrieg. 2018. url: https://www.welt.de/geschichte/zweiter-weltkrieg/article176177840/
Rheinbruecke - von - Remagen - Diese - Bruecke - verkuerzte - den - Zweiten - Weltkrieg.html (besucht am 09. 05. 2018).
[Pos19] PostgreSQL.PostgreSQL Global Development Group. 2019.url:https://www.
postgresql.org/docs/12/ (besucht am 19. 11. 2019).
[Pos20] PostGIS. PostGIS. 2020. url: https : / / postgis . net / docs/ (besucht am 15. 01. 2020).
[Pri07] MapTiler Team Pridal Pohanka. EPSG.io:Find Coordinate Systems worldwide.
2007.url: https://epsg.io (besucht am 27. 08. 2007).
[Sch17] T. Schwotzer. Open Historical Data Map. OSMImportUpdate-Tool. 2017. url: https://github.com/OpenHistoricalDataMap/OSMImportUpdate/wiki (be- sucht am 05. 10. 2017).
[Sch19] T. Schwotzer. Open Historical Data Map. 2019. url: https://github.com/
OpenHistoricalDataMap/OHDM-Documentation/wiki(besucht am 24. 10. 2019).
Anhang A
A.1 Inhalt der beiliegenden CD
• Verzeichnis Bachelorarbeit-PDF
Diese Arbeit in digitaler Version als PDF-Dokument
• Verzeichnis Source-Code
Der Source-Code des entwickelten Prototyps
Eigenständigkeitserklärung
Hiermit versichere ich, dass ich die vorliegende Bachelorarbeit selbstständig und nur unter Verwendung der angegebenen Quellen und Hilfsmittel verfasst habe. Die Arbeit wurde bisher in gleicher oder ähnlicher Form keiner anderen Prüfungsbehörde vorgelegt.
Berlin, den 27.01.2020
Kirill Mishin
