Masterthesis OpenStreetMap in der Luftfahrt Stefan Brunner 103234

Masterthesis

OpenStreetMap in der Luftfahrt

Stefan Brunner

103234

1

2

Erklärung der eigenständigen Abfassung der Arbeit

Ich versichere, diese Master Thesis ohne fremde Hilfe und ohne Verwendung anderer als der angeführten Quellen angefertigt zu haben, und dass die Arbeit in gleicher oder ähnlicher Form noch keiner anderen Prüfungsbehörde vorgelegen ist. Alle Ausführungen der Arbeit die wörtlich oder sinngemäß übernommen wurden, sind entsprechend gekennzeichnet.

______________________

Stefan Brunner, 26.06.2017

3

Inhaltsverzeichnis

1. Idee und Entstehung des Projektes ... 4

2. Vorbereitungen und erste Schritte ... 6

3. NextGen Maps Projekt Hard- und Software ... 9

3.1 Hardware ... 9

3.2 Software ... 10

3.2.1 Installation der Datenbank (DB) Software ... 11

3.2.2 Installation von osm2pgsql ... 13

3.2.3 Installation von TileMill ... 13

3.2.4 Installation von QGIS ... 14

3.2.5 Weitere Programme und Libraries ... 14

3.3 Festplatten- und Speichermanagement ... 15

4. NextGen Maps Datenbank ... 18

4.1 Postgresql Konfiguration ... 19

4.2 Planet OSM Import ... 23

4.3 Operativer Betrieb der Datenbank ... 25

4.3.1 Views und Indizes ... 26

4.3.2 Backup der Datenbank... 29

5. NextGen Maps Kartenerstellung ... 29

5.1 Vorüberlegungen ... 29

5.2 Erstellung der Raster Karten ... 36

5.3 Erstellung der Vektor Karten ... 41

5.4 Rendern der Raster Karten ... 42

5.5 Export der Vektor Karten einzelner Länder ... 45

5.6 Export der Vektor Karten für low und mid Detail Maps ... 47

5.7 Produktion eines Country Packages ... 48

5.8 Produktion von Adressdaten aus OSM Daten ... 49

6. NextGen Maps Vertriebskonzept ... 51

7. Ausblick und Reflektion des Projektes ... 53

8. Abbildungsverzeichnis ... 55

9. Literatur- und Quellenverzeichnis ... 57

9.1 Monographien ... 57

9.2 Online Quellen ... 57

10. Inhalt des Datenträgers ... 60

4 1. Idee und Entstehung des Projektes

Die Idee zu dieser Masterthesis entstand während meiner Arbeit bei der Firma EuroAvionics, einem Hersteller von Mission Management- und Navigationssystemen (www.euroavionics.com). Die Firma wurde 1994 gegründet und hat Ihren Hauptsitz in Pforzheim, Deutschland. Weitere Standorte befinden sich in Florida, USA, West Sussex in Großbritannien und Sissach in der Schweiz. Die EuroAvionics GmbH produziert mehrere vollständige Systeme (sowohl Hardware als auch Software) zur Planung und Durchführung von Flügen und Missionen im Rahmen der Sichtflug-Regeln (VFR = Visual Flight Rules).

Für die Missionen werden Kartendaten sowie Geländedaten mit anderen relevanten Informationen wie Wetterdaten oder Flugverkehr auf den unterschiedlichsten Monitoren im Cockpit als auch in der Kabine der Fluggeräte angezeigt. Viele dieser Kartendaten werden von Kunden (z.B. Polizei, Militär) zur Verfügung gestellt, decken dann aber nur immer einen kleineren Bereich, häufig nur ein Bundesland oder weniger ab. Wenige Organisationen haben flächendeckenden Zugriff auf kleinmaßstäbliche Kartenwerke für größere Gebiete oder gar mehrere Länder.

Die typischen aeronautischen Maßstäbe sind 1:250.000 und 1:500.000 oder größer. Diese Karten sind für fast alle Industrieländer mit einer ausreichenden Aktualität verfügbar und werden häufig von den nationalen Flugaufsichtsbehörden vertrieben. Sie bieten so eine verlässliche Quelle für den Flugbetrieb; aber auch hier unterscheiden sich manche Kartenwerke teilweise erheblich voneinander. Den einzigen globalen Ansatz für weltweit einheitliche aeronautische Karten bilden die Kartenserien des US Militärs:

- GNC (Global Navigation & Planning Chart) 1:5.000.000 - JNC (Jet/Joint Navigation Chart) 1:2.000.000

- ONC (Operational Navigation Chart) 1:1.000.000 - TPC (Tactical Pilotage Chart) 1:500.000

- JOG (Joint Operational Graphic) 1:250.000

Problematisch bei diesen Kartenserien ist, dass die aktuellsten Ausgaben für viele Bereiche der Welt militärisch „restricted“ also unter Verschluss der amerikanischen Regierung gehalten werden. Frei verfügbare Karten sind teilweise mehrere Jahrzehnte alt und eignen sich nicht mehr zur sicheren Navigation im Luftraum. Auch fehlen bei vielen dieser Karten teilweise erhebliche Informationen, z.B. aktuelle Grenzverläufe von Kroatien auf den ONC

5 Karten. Da die Karten vor den Balkankriegen erzeugt wurden, und Kroatien zu dieser Zeit schlicht noch nicht existiert hat.

Abb. 1: ONC ohne Grenzverlauf Kroatien

Abb. 2: NextGen Karte 1:1.000.000 mit korrektem Grenzverlauf

Ebenfalls existieren heute noch Karten, auf denen die Grenzen der ehemaligen DDR mit sowjetischen Flugverbotszonen über Ostdeutschland eingezeichnet sind.

6

Abb. 3: JOG mit Grenzverlauf ehemalige DDR

Aus all diesen Gründen und auch aus dem Wunsch, Kunden, die keinen Zugriff auf großmaßstäbliche Karten haben ebenfalls mit einheitlichen und vor allem aktuellen Karten zu versorgen entstand schließlich die Idee, aus freien Geodaten eine Kartenserie zu schaffen welche diese Anforderungen erfüllt.

2. Vorbereitungen und erste Schritte

Zuerst musste bei einem Termin die Geschäftsführung von dem Vorhaben überzeugt werden. Dafür wurden mehrere bestehende Systeme, bei den die o.g. Probleme auftraten vorbereitet und es wurde ein aus freien Geodaten bestehender Datensatz zu Demonstrationszwecken erstellt. Es wurde dazu sowohl auf Daten der OpenStreetMap Foundation¹ als auch auf freie Geodaten des Landes Berlin² zurückgegriffen.

Diese Demonstration verlief äußerst positiv, so dass ab diesem Zeitpunkt (Januar 2015) das Projekt unter dem Titel NextGen Maps, in Anlehnung an das zu diesem Zeitpunkt ebenfalls in der Entwicklung befindliche EuroNav NextGen System, gestartet wurde.

Nach dem offiziellen Projektstart waren die ersten Schritte, ein einfaches Konzept sowie eine Ressourcenplanung aufzustellen. Da das gesamte Projekt so nicht in den täglichen Produktionsablauf einzubinden war wurde schnell klar, dass hierfür eine Stelle geschaffen werden musste. Um die Einarbeitung zu erleichtern und das Verständnis für die EuroNav Systeme besser vermitteln zu können wurde entschieden für das Projekt eine Bachelorarbeit

1 www.openstreetmap.org

2 http://fbinter.stadt-berlin.de/fb/index.jsp

7 auszuschreiben. Ziel dieser Arbeit sollte es sein, bereits bestehende Vektorkarten grundlegend zu überarbeiten und einen ersten freien Vektordatensatz für kleinere Maßstäbe länderübergreifend für Europa zu konvertieren. Die Firma EuroAvionics arbeitet seit fast 15 Jahren mit der Firma HERE³ zusammen, um deren Streetlevel Karten für das EuroNav System zu nutzen und den Kunden so hochdetaillierte Straßenkarten mit Adresssuche zur Verfügung stellen zu können. Allerdings wurden diese Karten bereits vor 13 Jahren in das System integriert. Da zu diesem Zeitpunkt die Ressourcen der Hardware (EuroNav 4 + 5) bei weitem nicht so ausgreift waren wie heute (EuroNav 7 + NextGen) wurde eine sehr einfache Symbologie und Darstellungsweise gewählt, die nicht mehr den heutigen Anforderungen und Erwartungen entspricht. Durch diese Bachelorarbeit sollte sich der Bearbeiter mit dem System sowie dem Konvertierungsprozess selbst näher auseinandersetzen und die Grundlagen für das eigentliche Projekt gelegt werden.

Dazu wurde ein frei verfügbarer Datensatz EuroGlobalMap von Eurogeographics⁴ verwendet. Dieser Datensatz im Maßstab 1:1.000.000 ist frei im Internet verfügbar⁵ und deckt 45 Länder in Europa ab. Um in weniger gut abgedeckten Gebieten einen einheitlichen Hintergrund sowie Vegetationsfläche darstellen zu können wurde zusätzlich auf die CORINE Land Cover Daten 2012⁶ der Europäischen Umweltbehörde (EEA) zugegriffen.

Abb. 4: EuroGlobalMap und CORINE Daten im EuroNav

3 https://here.com/en/products-services/services/here-platform-business

4 http://www.eurogeographics.org/products-and-services/euroglobalmap

5 http://www.eurogeographics.org/form/topographic-data-eurogeographics

6 http://land.copernicus.eu/pan-european/corine-land-cover

8 Damit wurde ein erster Schritt, wie in der Einführung beschrieben, zu einer grenzübergreifenden und einheitlichen Karte gewagt. Angesetzt waren für diese Aufgaben 3 Monate. Titel dieser sehr erfolgreichen Bachelorarbeit war „Integration EuroGlobalMap Daten in Kombination mit CORINE Land Cover Daten in das EuroNav Navigationssystem sowie Neugestaltung der gegenwärtig implementierten Vektordaten“⁷.

Während der Bachelorarbeit wurden die ersten konkreten Anforderungen an das neue Kartenprojekt definiert.

- Weltweit einheitliches Design - Mehrsprachigkeit

- Einfache Austausch- bzw. Updatemöglichkeiten - Abo Modell für Updates zur Kundenbindung - Möglichkeit für kundenspezifische Karten/Designs

- Einfache Kombination mit anderen (kundeneigenen) Datensätzen - Präsentation und Auswahl über WMS

Diese Punkte wurden unter Berücksichtigung produktionstechnischer sowie vertriebstechnischen Gesichtspunkten ausgewählt und festgelegt, was insgesamt mehr Zeit erforderte als ursprünglich geplant. Gerade die Zusammenstellung der Abo Pakete erwies sich als ein schwieriger Aspekt der aber zum Ende hin mit einem für beide Seiten akzeptablen Kompromiss festgeschrieben wurde. Detaillierte Inhalte der einzelnen Pakete folgen im weiteren Verlauf dieser Ausarbeitung im Kapitel 6 sowie im Anhang.

Aus den o.g. Anforderungen ergaben sich weitere Notwendigkeiten der Beschaffung von Hardware, für das Aufsetzen und den Betrieb des WMS (Web Map Service). Für die angedachte Möglichkeit die Updates über das Internet zur Verfügung zu stellen wurde ein Server mit ausreichend Speicherplatz benötigt. Die ersten Ideen liefen darauf hinaus, das Angebot der Karten sowie alle anderen Services (Bestellung, Information, Updates) über eine Subdomain www.maps.euroavionics.com abzuwickeln. Dies ist bis zum heutigen Tag (Juni 2017) allerdings noch nicht umgesetzt.

Weiterhin wurde angemerkt, dass in die Abteilungsinterne Budgetplanung der Raum für neue Hardware vorgemerkt werden muss. Da man aber den Umfang und die technischen Daten noch nicht abschätzen konnte wurden zu diesem Zeitpunkt noch keine Bestellungen ausgeführt.

7 Litterst, 2015

9 Ein weiterer Punkt waren Überlegungen wie die Daten aufgeteilt und verwaltet werden sollten, es war sehr schwer abzuschätzen welches Datenvolumen am Ende für eine weltweite Abdeckung mit mehreren Kartenserien notwendig war, ebenso eventuell anfallende temporäre Daten während des Produktionsprozesses.

All diese Überlegungen fanden während des Sommers 2015 statt. Zu dieser Zeit wurde nochmals eine neue Stelle ausgeschrieben um dann ab Ende Herbst mit der Produktion der Karten zu beginnen. Die Autorin der Bachelorarbeit wurde nach der erfolgreichen Abgabe ihrer Bachelorarbeit ebenfalls bei der EuroAvionics übernommen, so dass ab November 2015 mit einem Team aus drei Personen mit der Produktion der Karten begonnen werden konnte.

3. NextGen Maps Projekt Hard- und Software 3.1Hardware

Zu Beginn des Projektes wurde eine ausreichend performante Workstation mit genügend Reserven für die künftigen Aufgaben gesucht. Das Projektteam entschied sich für folgende Hardware:

DELL Precision Tower 5810 XCTO

- Intel Xeon E5-1650 v3 Prozessor (3,5GHz, 6C, 15MB Cache, Turbo, HT)

- 32GB (4x8GB) 2133MHz DDR4 RDIMM ECC

- Integrated Intel AHCI chipset SATA controller (6 x 6.0Gb/s) - SW RAID 0/1/5/10

- Zwei NVIDIA Quadro K420 1GB (DP, DL-DVI-I) (2DP auf SL-DVI Adapter)

Diese Hardware bietet mit einem 6 Kern Prozessor⁸ und den 32 GB ECC⁹ RAM (error correcting code memory) eine solide Basis um sowohl größere Datenmengen sicher und schnell zu prozessieren, als auch mehrere Prozesse mit ausreichender Geschwindigkeit parallel ablaufen zu lassen. Bei dem o.g. Setup entschied man sich bewusst für die Nutzung eines Software RAIDs, dazu später mehr in Kapitel 3.3. Die Workstation wurde mit zwei magenetischen sowie zwei Solid State Festplatten ausgerüstet. Eine ausreichend performante Grafikkarte vervollständigte das Hardware Setup.

8 https://ark.intel.com/de/products/82765/Intel-Xeon-Processor-E5-1650-v3-15M-Cache-3_50-GHz

9 http://www.elektronik-kompendium.de/sites/com/1504141.htm

10 Neben dieser Workstation, die für die Datenbank sowie die Render- und alle weiteren Prozessierungsschritte gedacht ist, wurde ein weiterer Server für die Speicherung der finalen Daten und die Auslagerung von temporären Daten beschafft. Dabei entschied man sich für folgende Lösung:

Dell PowerEdge R530

- Intel® Xeon® E5-2620 v3 2.4GHz - 32GB RDIMM

- 3.5" Chassis with up to 12 Hot Plug Hard Drives

In dem Server laufen zwölf magnetische NAS Festplatten mit je zwei TB in einem RAID Verbund.

3.2Software

Auf beiden Systemen läuft Ubuntu Server (1404 Trusty Tahr) als Betriebssystem. Dieses war zum Zeitpunkt der Installation die aktuelle Version mit LTS¹⁰ (Long Term Support).

Hierdurch wird eine verlässliche Versorgung mit sicherheitskritischen Updates für 60 Monate gewährleistet.

Abb. 5: LTS Versionen Ubuntu

10 https://wiki.ubuntuusers.de/Long_Term_Support/

11 Zusätzlich wurden folgende Programme/Pakete installiert:

- Postgre SQL, Version 9.6 - PostGIS, Version 2.3 - plPythonU

- plSQL

- PGAdmin, Version 3 - Osm2pgsql

- Tilemill v0.10.1-293-g697c86c - Mapnik, Version 2.3.0

- GDAL, Version 1.10.2 released 2013/08/26 - QGIS, Version 2.10 (Pisa)

3.2.1 Installation der Datenbank (DB) Software

Bevor man mit der Installation der eigentlichen DB Software, in diesem Fall Postgresql, beginnen kann, müssen je nach Linux System und der verwendeten Distrubution einige Dependecies installiert werden. In dem hier vorliegenden Fall handelte es sich um Pakete mit bestimmten Libraries für Schriftarten, Datenformate, Serveranwendungen sowie Koordinatensysteme und Transformationen. Dies geschieht unter Linux in einem Terminal, vergleichbar mit der Kommandozeileneingabe unter Windows.

sudo apt-get install libboost-all-dev subversion git-core tar unzip wget bzip2 build-essential autoconf libtool libxml2-dev libgeos-dev libgeos++-dev libpq-dev libbz2-dev libproj-dev munin-node munin libprotobuf-c0-dev protobuf-c-compiler libfreetype6-dev libpng12-dev libtiff4-dev libicu-dev libgdal-dev libcairo-dev libcairomm-1.0-dev apache2 apache2-dev libagg-dev liblua5.2-dev ttf-unifont lua5.1 liblua5.1-dev libgeotiff-epsg node-carto

Nach diesen Vorbereitungen kann das eigentliche Programm installiert werden. Unter Linux werden Programme allerdings nicht wie unter Windows üblich als einzelne Anwendungen installiert sondern es handelt sich um Pakete die Teil von sogenannten Paketquellen¹¹ (Repositories) sind. Diese müssen oftmals erst dem Linux System mitgeteilt werden. Diese Pakete werden dann der Ubuntu-Source-List hinzugefügt und sind dann dauerhafter

11 https://wiki.ubuntuusers.de/Paketquellen/

12 Bestandteil des Systems. Viele dieser Pakete benötigen noch weitere Libraries die oftmals automatisch, manchmal aber auch manuell (s.o.) installiert werden müssen¹².

Oftmals gibt es mehrere Möglichkeiten ein Paket und alle zugehörigen Dependencies zu installieren. In dieser Arbeit wird ein Weg gezeigt der für die hier beschriebenen Fälle erfolgreich war. Um das Hauptprogramm zu installieren wurde wie folgt vorgegangen:

• Das Postgresql-Repositorium wurde der „Ubuntu-Source-Liste“ beigefügt:

sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt trusty-pgdg main" >>

/etc/apt/sources.list'

• Zertifizierung der neuen Quelle:

sudo apt-get install wget ca-certificates

wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add –

• Aktualisierung der Source Liste:

sudo apt-get update

• Prüfen ob es für die installierten Pakete neue Updates gibt:

sudo apt-get update

• Das eigentliche Programm mit Erweiterungen installieren:

sudo apt-get install postgresql-9.6-postgis-2.3 pgadmin3 postgresql-contrib postgresql-plpython-9.6

Mit diesem Befehl wurden die folgenden Programme installiert:

- Postgresql Version 9.6 mit PostGIS 2.3 - PgAdmin 3

- Postgresql-contrib 9.4 (9.4.12-0+deb8u1) - Postgresql-plpython 9.6

Weitere Informationen zur Paketverwanltung und Installation sowie Aktualisierung von Linux Programmen können der offiziellen Dokumentation¹³ von Ubuntu entnommen werden.

12 https://help.ubuntu.com/lts/serverguide/package-management-introduction.html

13 https://wiki.ubuntuusers.de/apt/apt-get/

13 3.2.2 Installation von osm2pgsql

Um die Datenbank mit OpenStreetMap (OSM) Daten zu befüllen wird ein gesondertes Tool benötigt. Bei dem hier beschriebenen Workflow wurde osm2pgsql verwendet. Weitere Tools sind unter anderem Osmosis oder Imposm. Eine Übersicht und weitere Links zu diesem Thema sind im offiziellen OSM Wiki zu finden¹⁴. Um osm2pgsql zu installieren muss zuerst ein Repository zur Ubuntu-Source-List hinzugefügt werden.

sudo add-apt-repository -y ppa:kakrueger/openstreetmap

Anschließend wird die Software Liste aktualisiert:

sudo apt-get update

Dann wird das Programm installiert:

sudo apt-get --no-install-recommends install -y osm2pgsql osmctools

Zum Testen ob das Programm richtig installiert wurde, im Terminal folgenden Befehl eingeben:

osm2pgsql –version

Es sollte folgender Text erscheinen:

Osm2pgsql SVN version 0.85.0 (64bit id space)

3.2.3 Installation von TileMill

Dieser Schritt beschreibt die Installation von TileMill¹⁵, einem Design Studio mit dessen Hilfe aus den OSM Rohdaten fertig gerenderte Raster Karten Tiles hergestellt werden können. „Tilemill ist ein Programm, welches es ermöglicht, Geodaten stilistisch aufzubereiten und anschließend in einem kachelbasierten Rasterbildformat zu speichern.

Die so erstellte Karte kann dann auf einem eigenen Webserver im Internet bereitgestellt werden oder auch über die Server von Mapbox¹⁶.“

Wie zuvor wird zuerst ein Repository eingefügt:

sudo add-apt-repository ppa:developmentseed/mapbox

14 http://wiki.openstreetmap.org/wiki/Mapnik#PostGIS

15 http://tilemill-project.github.io/tilemill/

16 http://bk.dgfk.net/2015/08/05/tilemill-kartendesign-per-cartocss/

14 Anschließend wird die Software Liste aktualisiert:

sudo apt-get update

Dann wird das Programm installiert:

sudo apt-get install tilemill libmapnik nodejs

3.2.4 Installation von QGIS

Da bei einer Ubuntu Standard Installation nicht immer die letzte Version von QGIS installiert ist, wurde manuell die aktuelleste (2.10 Pisa) installiert. Dazu musste die Ubuntu- Source-Liste um folgende Einträge ergänzt werden:

sudo sh -c 'echo "deb http://qgis.org/debian trusty main" >> /etc/apt/sources.list' sudo sh -c 'echo "deb-src http://qgis.org/debian trusty main" >> /etc/apt/sources.list'

Fingerabdruck¹⁷ hinzufügen:

wget -O - http://qgis.org/downloads/qgis-2016.gpg.key | gpg --import gpg --fingerprint 073D307A618E5811

gpg --export --armor 073D307A618E5811 | sudo apt-key add –

Anschließend die Software Liste aktualisieren:

sudo apt-get update

Dann das Programm installieren:

sudo apt-get install qgis python-qgis qgis-plugin-grass

3.2.5 Weitere Programme und Libraries

Für den weiteren Arbeitsablauf wurden noch die Setup Tool von Python sowie zur leichteren Arbeit ein File Explorer (Krusader¹⁸) und ein Texteditor mit einer IDE (Integrated Development Environment) hier: Geany¹⁹, installiert.

sudo apt get install python-setuptools geany krusader

17 https://www.qgis.org/de/site/forusers/alldownloads.html#debian-ubuntu

18 https://krusader.org/

19 https://www.geany.org/

15 Neben diesen Programmen fehlten noch kleinere Tools und Libraries die für den weiteren Workflow notwendig waren. Unidecode²⁰, ein Transliterationsprogramm mit dessen Hilfe ein Unicode codierter Text in „saubere“ ASCII Zeichen umgewandelt werden kann. Nik4²¹ und Nik2Img²² wurden für das spätere rendern der Rasterdaten benötigt.

sudo easy_install nik4 sudo easy_install nik2img sudo pip install unidecode

3.3Festplatten- und Speichermanagement

Ein wichtiger Punkt für den gesamten Produktionsworkflow ist das Festplatten- und Speichermanagement. Für den in dieser Arbeit beschriebenen Ablauf hat man sich für folgende Backup- und Performancestrategie entschieden.

Die beiden Systeme, Workstation für Datenbank und Rendern, sowie der Server für die Auslagerung von größeren Mengen temporärer Dateien und die Datensicherheit, müssen gesondert voneinander betrachtet werden. Beide besitzen zwei seperate Partitionen, allerdings sind diese unterschiedlich ausgerüstet und angeordnet.

Abb. 6: Hardware Konfiguration

Die Kapazitäten (k) der einzelnen RAID Verbunde lassen sich mit folgender Formel berechnen:

= − 1

20 https://launchpad.net/ubuntu/+source/unidecode

21 https://github.com/Zverik/Nik4

22 https://github.com/mapnik/mapnik/wiki/Nik2Img

16 Im Falle des RAID 5 Verbundes mit zehn 2 TB Festplatten im Server bedeutet das, dass eine Speicherkapazität von insgesamt 9 x 2 TB = 18 TB zur Verfügung steht.

Wie in Abb. 6 zu sehen, wurde bei der Konfiguration der Workstation auf schnelle Solid State Festplatten zurückgegriffen, dies soll den Datenbankimport sowie die Renderabläufe im späteren Workflow beschleunigen. Da die Datenbank und die Ausgangsdaten einfach wiederzubeschaffen und zu konfigurieren sind wurde hier bewusst ein RAID 0 Verbund gewählt. Bei diesem Stripeset wird die Schreiblast gleichmäßig auf beide Festplatten verteilt, mit dem Risiko, dass bei einem Ausfall einer Platte die Daten irreparabel verloren gehen.

Abb. 7: Aufbau eines RAID 0 Verbundes

Da die Datenbank immer nur für maximal 12 Monate aufgesetzt wird und hochwertige industrielle SSD`s verwendet werden, überwiegen hier die Vorteile der höheren Performance deutlich gegenüber dem Datenverlustrisiko. Die zweite Partition dient der Speicherung des Betriebssystems sowie aller anderen Konfigurationsdateien die für die Herstellung notwendig sind. Diese sind durch einen einfachen RAID 1 Verbund redundant gesichert, zusätzlich folgt nach neuen Revisionen eine manuelle Datensicherung bei einem externen Hoster.

Der Server dient zum einen zur Speicherung der finalen Datensätze sowie als Backup für sämtliche für den Workflow notwendigen Tools, deshalb wurde hier ein RAID 5 Verbund gewählt, bei dem eine Festplatte ohne Auswirkungen für die Datensicherheit komplett ausfallen kann²³. Da sich der Server im Haus befindet und über moderne Software Überwachungstools verfügt ist davon auszugehen, dass ein Festplattendefekt rechtzeitig erkannt und behoben wird. Die zweite Partition auf dem Server wurde bewusst nur als

23 http://unthought.net/Software-RAID.HOWTO/Software-RAID.HOWTO-5.html#ss5.8

17 sogenannter Scratch-Workspace angelegt. Dieser ist in keiner Sicherung enthalten und dient nur als Auslagerungs- und Testspeicherplatz.

Exemplarisch wird die Einrichtung der ersten Partition der Workstation für die Datenbank als RAID 0 Verbund gezeigt, da es sich hier um die wichtigste Partition im gesamten Arbeitsablauf handelt. Die folgenden Arbeitsschritte werden unter Linux mit dem Tool mdadm²⁴ durchgeführt.

Erstellen des RAID 0 Verbundes bestehend aus 2 Festplatten

sudo mdadm --create /dev/md2 –auto md –level=0 –raid-devices=2 /dev/sdc1 /dev/sdd1

Erstellung des Filesystems und Einbinden in das System

sudo mkfs.ext4 /dev/md2

Verbesserung der Leistung durch Anpassung der „Chunk Size²⁵“ Ermitteln der Chunk Size:

sudo mdadm –D /dev/md2 | grep „Chunk Size“

Ergebnis: Chunk Size: 512 K

Mit dem Raid Stride Calculator²⁶, der Anzahl der Platten, des Raid Levels sowie der Chunk Size und der Anzahl von Filesystem Blocks (= 4KiB) lässt sich die Anzahl der Dateisystem- Parameter berechnen. Danach wird das Dateisystem erstellt:

sudo mkfs.ext4 –b 4096 –E stride=128,stripe-width=256 /dev/md2

Anschließend wird das neu angelegte RAID gemountet

sudo mount /dev/md2 /ssd

Damit der RAID Verbund bei jedem Systemstart automatisch eingehängt wird muss die Konfigurationsdatei fstab²⁷ folgendermaßen bearbeitet werden:

/dev/md2 /ssd ext4 defaults 0 2

24 http://neil.brown.name/blog/mdadm

25 http://unthought.net/Software-RAID.HOWTO/Software-RAID.HOWTO-5.html#ss5.10

26 https://busybox.net/~aldot/mkfs_stride.html

27 https://wiki.ubuntuusers.de/fstab/

18 Zudem muss die mdadm Konfigurationsdatei aktualisiert werden:

sudo su –c “/usr/share/mdadm/mkconf > /etc/mdadm/mdadm.conf”

Damit die Konfiguration beim booten verfügbar ist, muss schließlich noch die Initramfs Konfigurationsdatei aktualisiert werden:

sudo update-initramfs –u –k all

Abschließend muss der gesamte RAID 0 Verbund noch formatiert werden, hierzu wird ein ext4 Dateisystem²⁸ verwendet.

4. NextGen Maps Datenbank

Als Rohdaten dient das sogenannte Planet OSM File²⁹ von Openstreetmap. Dieses File enthält alle Elemente³⁰ (nodes, ways und relations) des gesamten Openstreetmap Projektes und wird einmal wöchentlich aktualisiert. Der Download hatte eine Größe von 33,6 GB (25.11.2016) im PBF³¹ (Protocolbuffer Binary Format) Format. Mit dieser Datei wurde die unter Punkt 3.2.1 beschriebene Datenbank aufgesetzt und alle weiteren Schritte durchgeführt. Geplant ist, einmal im Jahr (Ende November) die Datenbank neu aufzusetzen und dafür immer einen komplett Import aus dem dann jeweils aktuellen Planet File durchzuführen. Es wäre auch möglich die Datenbank mit sog. Changesets die einmal wöchentlich erscheinen aktuell zu halten, allerdings würde dies dazu führen dass dann die gerenderten Karten für jeden Auftrag unterschiedliche Inhalte haben. Dies ist bei diesem Workflow ausdrücklich nicht erwünscht. Es muss sichergestellt werden, dass alle Karten einer Revision immer die gleichen Inhalte aufweisen. Eine Revision ist immer der Zeitraum zwischen dem jährlichen Aufsetzen der Datenbank. Nur so kann garantiert werden, dass eine Karte die im Januar gerendert wurde die gleichen Elemente enthält wie eine Karte aus dem September, da auch alle anderen Abfragen aus der Datenbank nicht während einer Revision abgeändert werden.

28 https://www.thomas-krenn.com/de/wiki/Ext4_Dateisystem

29 http://wiki.openstreetmap.org/wiki/Planet.osm

30 http://wiki.openstreetmap.org/wiki/Elements

31 http://wiki.openstreetmap.org/wiki/PBF_Format

19 4.1Postgresql Konfiguration

Zunächst muss eine neue Datenbank für den Import der OSM Daten angelegt werden. Dazu wird zuvor ein neuer Benutzer mit allen Rechten sowie ein Datenbankcluster erstellt. Um diese Schritte erfoglreich durchführen zu können sollte man nach der Installation von Postgresql den sog. Adminpack aktivieren³².

sudo –u postgres psql

postgres=# CREATE EXTENSION adminpack;

CREATE EXTENSION postgres=# \q

Nach der Aktivierung muss ein Bereich auf der Festplatte für die Datenbank eingerichtet werden, der sog. „Database Cluster“. Es handelt sich dabei allerdings noch nicht um die eigentliche Datenbank, sondern nur um einen reservierten Bereich in dem später die eigentliche Datenbank angelegt wird. Dieser wird auf der Workstation auf der RAID 0 Partition mit den beiden Solid State Festplatten realisiert. Dadurch soll eine maximale Schreib- uns Arbeitsgeschwindgkeit erreicht werden (im Vergleich zu den Partitionen auf magnetischen Platten).

Pfad für den Database Cluster erzeugen:

sudo mkdir –p /ssd/database/osm

Der (neue) Database Cluster Pfad muss dem User postgres ‘gehören’, deshalb muss der Ordner in dem die DB liegen soll dem User postgres „überschrieben“ werden.

sudo chown -R postgres /ssd/database

Jetzt muss der neue Database Cluster initialisiert werden. Dazu müssen als erstes alle existierenden Postgres Instanzen gestoppt werden.

sudo service postgresql stop

32 https://www.postgresql.org/docs/9.6/static/adminpack.html

20 Um sicher zu gehen dass keine Postgresql-Prozesse mehr laufen, sollte man alle Prozesse schließen.

sudo pkill -u postgres

Jetzt als postgres User anmelden:

sudo su - root@osm:~#

su – postgres postgres@osm:~#

Und die Änderungen initialisieren:

/usr/lib/postgresql/9.6/bin/initdb -D /ssd/database/osm exit --postgres-User abmelden

exit -- root-User abmelden

Als nächstes müssen die Änderungen in der postgresql.conf Konfigurationsdatei übernommen werden. Dazu im Terminal die postgresql.conf Datei öffnen:

sudo gedit /etc/postgresql/9.6/main/postgresql.conf

Zur “file locations section” scrollen. Den vorhandenen data_directory auskommentieren (#) und einen neuen hinzufügen.

# data_directory = '/var/lib/postgresql/9.6/main' # default nach der Installation

Neue Zeile darunter einfügen:

data_directory = '/ssd/database/osm' # neu angelegter Cluster

Dokument speichern und Editor schließen, anschließend den Postgres Server (neu-)starten:

sudo service postgresql restart

Testen ob der Database Cluster im richtigen Verzeichnis angelegt wurde:

21

sudo su - root@osm:~#

su – postgres postgres@osm:~#

psql postgres=#

Pfad zum Database Cluster anzeigen lassen:

show data_directory;

Zuletzt wird ein neuer Benutzer angelegt der zukünfig der Hauptnutzer der OSM Datenbank werden soll. In diesem Fall heißt der Benutzer osm und wird als Super User angelegt.³³

CREATE USER osm

WITH SUPERUSER CREATEDB CREATEROLE PASSWORD 'xxx';

CREATE ROLE

\q #Exit von psql exit # Exit von postgres exit # Exit von root

Mit den beiden vorausgegangenen Schritten wurde also ein Bereich für die OSM Datenbank geschaffen und ein Benutzer für tägliche Arbeit angelegt. Jetzt kann die eigentliche Datenbank erstellt werden. Dies geschieht ebenfalls in der psql Kommandozeile:

psql -U osm -d postgres # Jetzt bereits mit dem neu angelegten Benutzer osm postgres=# CREATE DATABASE ngmaps WITH OWNER osm;

CREATE DATABASE

Damit wird eine neue Datenbank mit dem Namen ngmaps erstellt und der Besitzer osm zugewiesen. Jetzt kann dieser sich mit der neuen Datenbank verbinden:

postgres=# \connect ngmaps;

33 https://help.ubuntu.com/community/RootSudo

22 Unter Punkt 3.2.1 wurden bei der Software Installation mehrere Pakete mitinstalliert, die jetzt zur Anwendung kommen bzw. die jetzt aktiviert und so für die Nutzung in der Datenbank verfügbar gemacht werden. Dabei handelt es sich um Extensions. Diese Erweiterungen dienen dazu die PostgreSQL Datenbank um wichtige Funktionen zu erweitern, ein Beispiel hierfür ist PostGIS.

“PostGIS is a spatial database extender for PostgreSQL object-relational database. It adds support for geographic objects allowing location queries to be run in SQL.”³⁴

PostGIS ermöglicht z.B. räumliche Abfragen, Analysen von Vektor- und Rasterdaten sowie Funktionen zur Erstellung von Geometrien³⁵. Eine weitere Extension ist plpythonu. Diese ermöglicht die Arbeit mit der Programmiersprache Python. Die dritte hier installierte Extension ist hstore³⁶, ein neuer Datentyp zur Speicherung von Schlüssel-Wert Paaren (key- values). Diese drei Extensions werden nun fogendermaßen aktiviert:

CREATE EXTENSION postgis;

CREATE EXTENSION hstore;

CREATE EXTENSION plpythonu;

Abschließend muss die Postgresql Datenbank für den Import der OSM einmalig vorbereitet werden, die nachfolgenden Änderungen gelten nur für den Import der Daten und werden nach erfolgreichem Import wieder zurückgestellt. Die hier verwendeten Einstellungen sind speziell für den hier vorliegenden Fall anzuwenden, die Thematik des (Import-) Tunings wird teilweise sehr ausführlich und emotional in diversen Foren und Wikis geführt. Da es aber gerade beim Import auf sehr viele unterschiedliche Variablen (Software, verwendete Hardware, Zweck des Imports, verwendete Tools, …) ankommt, sei auf eine Präsentation³⁷ von Frederik Ramm aus dem Jahr 2012 von der SOTM (State of the Map) in Tokyo verwiesen. Allerdings ist hier auch zu beachten, dass sich in den letzten Jahren enorme Entwicklungen gerade im Hardware Bereich der Solid State Festplatten ergeben haben.

Diese sind mit einer der Hauptfaktoren was die Importdauer bei Datenbanken betrifft.

Deshalb und auf Grund der günstigen Lage zu Karlsruhe wurde vorab ein Trainingstag in den Räumlichkeiten der Geofabrik in Karlsruhe gebucht um zusammen mit Frederik Ramm einige aktuelle Erfahrungen auszutauschen. Aus diesem Training und vielen Tests wurden

34 http://postgis.net/

35 https://de.wikipedia.org/wiki/PostGIS

36 https://www.postgresql.org/docs/current/static/hstore.html

37 https://www.geofabrik.de/media/2012-09-08-osm2pgsql-performance.pdf

23 dann folgende Einstellungen in der postgresql.conf vorgenommen und gelten seither als Referenz für den Import des OSM Planet Files dieses Projektes:

ALTER SYSTEM SET shared_buffers = '2GB';

ALTER SYSTEM SET work_mem = '256MB';

ALTER SYSTEM SET maintenance_work_mem = '4GB';

ALTER SYSTEM SET fsync to 'off';

ALTER SYSTEM SET autovacuum to 'off';

ALTER SYSTEM SET random_page_cost = '1';

ALTER SYSTEM SET effective_cache_size = ‘8GB’;

ALTER SYSTEM SET effective_io_concurrency = ‘1’;

ALTER SYSTEM SET seq_page_cost = '1.1’;

Diese Befehle werden einzelen in der pgsql Kommandozeile ausgeführt die ALTER SYSTEM Befehle ermöglichen es, die Konfigurationsparameter direkt zu ändern da es mehrere postgresql.conf verteilt auf einem System gibt und so sichergestellt wird, dass alle notwendigen Dateien bearbeitet werden. Einen Überblick über die einzelnen Funktionen findet man in der offiziellen Postgresql Dokumentation³⁸.

4.2Planet OSM Import

Nach der Installation aller notwendigen Programme und der Optimierung der Datenbank für den Import großer Datenmengen kann nun der eigentliche Import vorgenommen werden.

Dies geschieht mit dem unter 3.2.2 installierten Tool osm2pgsql.

Neben dem Planet OSM File muss noch eine temporäre Datei (am besten im gleichen Verzeichnis) angelegt werden. Diese Datei hier: flat.tmp dient dazu während des Imports temporäre Tabellen auszulagern. Der eigentliche Importvorgang wird mit folgendem Befehl gestartet:

sudo osm2pgsql --create --slim --cache 24000 --database ngmaps -U osm -W --number- processes 10 --hstore --hstore-match-only --flat-nodes /ssd/raw/flat.tmp --drop -l -style osm_style_rev001.style --multi-geometry planet-latest.osm.pbf

38 https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server

24 Folgende Varaiblen wurden verwendet:

--slim Temporäres Speichern in Datenbank ermöglichen --cache 24000 Größe des --slim Speichers in MB

--number-processes 10 Anzahl der parallel laufenden Prozesse

--hstore Tags ohne Spalte in --hstore Spalte speichern --hstore-match-only Nur key/value Paare ohne NULL Werte speichern --flat-nodes Speichern der --slim Daten

-style osm_style_rev001.style Steuerung welche Tags gespeichert werden sollen --multi-geom Speicherung von Multigeometrien ermöglichen

Mit diesen Einstellungen und den vorher beschriebenen Anpassungen der Postgresql Konfiguration dauert der Import des Plant OSM Files 21 Stunden (November 2016). Im Vergleich mit anderen Import Benchmarks³⁹ ist das ein akzeptabler Wert. Nachfolgend sollte überprüft werden ob dieser erfolgreich durchgeführt wurde. Dies kann z.B. über die grafische Oberfläche von PGAdmin 3 erfolgen.

Abb. 8: Oberfläche PGAdmin 3

39 http://wiki.openstreetmap.org/wiki/Osm2pgsql/benchmarks

25 Folgende Tabellen müssen nach dem Import zwingend vorhanden sein:

planet_osm_line planet_osm_point planet_osm_polygon planet_osm_roads

4.3Operativer Betrieb der Datenbank

Im vorhergegangenen Punkt 4.1 wurde die Konfiguration der Datenbank beschrieben, aber auch spezielle Anpassungen für den Import des OSM Planet Files getroffen. Diese Änderungen müssen nun wieder rückgängig gemacht werden um einen normalen operativen Betrieb der Datenbank zu gewährleisten. Diese Änderungen werden wie zuvor in der postgresql.conf Konfigurationsdatei vorgenommen.

ALTER SYSTEM SET shared_buffers = '16GB';

ALTER SYSTEM SET work_mem = '3GB';

ALTER SYSTEM SET maintenance_work_mem = ‘8GB';

ALTER SYSTEM SET fsync = 'on';

ALTER SYSTEM SET autovacuum = 'on';

ALTER SYSTEM SET random_page_cost = '1';

ALTER SYSTEM SET effective_cache_size = ‘24GB’;

ALTER SYSTEM SET effective_io_concurrency = ‘1’;

ALTER SYSTEM SET seq_page_cost = ‘1.1’;

ALTER SYSTEM SET synchronous_commit = off;

ALTER SYSTEM SET wal_buffers = ‘16MB‘;

ALTER SYSTEM SET checkpoint_completion_target = '0.9';

ALTER SYSTEM SET max_connections = '50';

ALTER SYSTEM SET listen_addresses = '*';

SET postgis.gdal_enabled_drivers = 'GTiff PNG JPEG HGT';

SET postgis.enable_outdb_rasters = ‘true’;

Mit den letzten beiden Befehlen wird die Unterstützung für GeoTiffs, PNG, JPEG und HGT Rasterdaten aktiviert. Dies ist für den weiteren Arbeitsablauf erforderlich. Um diese Änderungen wirksam zu machen muss abschließend die Datenbank neu gestartet werden, dies geschieht mit folgenden Befehlen:

26 Abmelden von der psql-Kommandozeile

\q

sudo service postgresql stop sudo service postgresql start

4.3.1 Views und Indizes

Um die Weiterverarbeitbarkeit für SQL Abfragen zu gewährleisten müssen einige Spaltenname die einen sogenannten namespace⁴⁰ enthalten umbenannt werden.

-- planet_osm_point

ALTER TABLE planet_osm_point RENAME COLUMN "addr:housename" TO addr_housename;

ALTER TABLE planet_osm_point RENAME COLUMN "addr:housenumber" TO addr_housenumber;

ALTER TABLE planet_osm_point RENAME COLUMN "addr:interpolation" TO addr_interpolation;

ALTER TABLE planet_osm_point RENAME COLUMN "generator:source" TO generator_source;

ALTER TABLE planet_osm_point RENAME COLUMN "tower:type" TO tower_type;

-- planet_osm_line

ALTER TABLE planet_osm_line RENAME COLUMN "addr:housename" TO addr_housename;

ALTER TABLE planet_osm_line RENAME COLUMN "addr:housenumber" TO addr_housenumber;

ALTER TABLE planet_osm_line RENAME COLUMN "addr:interpolation" TO addr_interpolation;

ALTER TABLE planet_osm_line RENAME COLUMN "generator:source" TO generator_source;

ALTER TABLE planet_osm_line RENAME COLUMN "tower:type" TO tower_type;

ALTER TABLE planet_osm_line RENAME COLUMN "abandoned:aeroway" TO abandoned_aeroway;

ALTER TABLE planet_osm_line RENAME COLUMN "abandoned:amenity" TO abandoned_amenity;

ALTER TABLE planet_osm_line RENAME COLUMN "abandoned:building" TO abandoned_building;

ALTER TABLE planet_osm_line RENAME COLUMN "abandoned:landuse" TO abandoned_landuse;

ALTER TABLE planet_osm_line RENAME COLUMN "abandoned:power" TO abandoned_power;

ALTER TABLE planet_osm_line RENAME COLUMN "area:highway" TO area_highway;

-- planet_osm_polygon

ALTER TABLE planet_osm_polygon RENAME COLUMN "addr:housename" TO addr_housename;

ALTER TABLE planet_osm_polygon RENAME COLUMN "addr:housenumber" TO addr_housenumber;

ALTER TABLE planet_osm_polygon RENAME COLUMN "addr:interpolation" TO addr_interpolation;

ALTER TABLE planet_osm_polygon RENAME COLUMN "generator:source" TO generator_source;

ALTER TABLE planet_osm_polygon RENAME COLUMN "tower:type" TO tower_type;

ALTER TABLE planet_osm_polygon RENAME COLUMN "abandoned:aeroway" TO abandoned_aeroway;

ALTER TABLE planet_osm_polygon RENAME COLUMN "abandoned:amenity" TO abandoned_amenity;

40 http://wiki.openstreetmap.org/wiki/Namespace

27

ALTER TABLE planet_osm_polygon RENAME COLUMN "abandoned:building" TO abandoned_building;

ALTER TABLE planet_osm_polygon RENAME COLUMN "abandoned:landuse" TO abandoned_landuse;

ALTER TABLE planet_osm_polygon RENAME COLUMN "abandoned:power" TO abandoned_power;

ALTER TABLE planet_osm_polygon RENAME COLUMN "area:highway" TO area_highway;-- planet_osm_roads

ALTER TABLE planet_osm_roads RENAME COLUMN "addr:housename" TO addr_housename;

ALTER TABLE planet_osm_roads RENAME COLUMN "addr:housenumber" TO addr_housenumber;

ALTER TABLE planet_osm_roads RENAME COLUMN "addr:interpolation" TO addr_interpolation;

ALTER TABLE planet_osm_roads RENAME COLUMN "generator:source" TO generator_source;

ALTER TABLE planet_osm_roads RENAME COLUMN "tower:type" TO tower_type;

ALTER TABLE planet_osm_roads RENAME COLUMN "area:highway" TO area_highway;

ALTER TABLE planet_osm_roads RENAME COLUMN "abandonded:aeroway" TO abandondend_aeroway;

ALTER TABLE planet_osm_roads RENAME COLUMN "abandoned:building" TO abandonded_building;

ALTER TABLE planet_osm_roads RENAME COLUMN "abandoned:landuse" TO abandonded_landuse;

ALTER TABLE planet_osm_roads RENAME COLUMN "abandoned:power" TO abandonded_power;

Um die Performance der Datenbank, genauer der SQL Abfragen zu erhöhen, wurden sowohl Indizes als auch Views der einzelnen Tabellen angelegt. „Der Index ist eines der wichtigsten Performance-Instrumente in relationalen Datenbanken. Die Anzahl der Daten, die gelesen werden müssen, um das Ergebnis zu erhalten, lässt sich auf diese Weise signifikant reduzieren.“⁴¹ Ein View hilft bei der Vereinfachung von komplexen SQL Abfragen da direkt ein View abgefragt werden kann der wiederum auf einer komplexen Abfrage basiert.⁴²

Abb. 9: Table View

41 Fröhlich 2013, 201

42 http://www.postgresqltutorial.com/managing-postgresql-views/

28 Diese Indizes und Views werden ebenfalls über die Kommandozeile geladen, die kompletten SQL Abfragen sind als Anhang auf dem Datenträger beigefügt (./indices_views).

\i /nextGen_rev001/build_nextGenDB/sql/3_final_view_and_indices/view_areas_rev001.sql

\i /nextGen_rev001/build_nextGenDB/sql/3_final_view_and_indices/view_label_rev001.sql

\i /nextGen_rev001/build_nextGenDB/sql/3_final_view_and_indices/view_lines_rev001.sql

\i /nextGen_rev001/build_nextGenDB/sql/3_final_view_and_indices/view_point_rev001.sql

\i /nextGen_rev001/build_nextGenDB/sql/3_final_view_and_indices/index_areas_rev001.sql

\i /nextGen_rev001/build_nextGenDB/sql/3_final_view_and_indices/index_label_rev001.sql

\i /nextGen_rev001/build_nextGenDB/sql/3_final_view_and_indices/index_lines_rev001.sql

\i /nextGen_rev001/build_nextGenDB/sql/3_final_view_and_indices/index_point_rev001.sql

Werden während des Imports der Views und Indizes Fehler angezeigt, müssen diese im Nachgang einzeln überprüft werden, da die Fehlermeldungen nicht immer ein Fehlen von Views oder Indizes bedeuten. Werden tatsächlich fehlende Views oder Indizes gefunden, müssen diese manuell über PGAdmin 3 nachgetragen werden.

Abb. 10: Fehler während VIEW Erstellung

29 4.3.2 Backup der Datenbank

Abschließend kann ein Backup der Datenbank erstellt werden um diese Schritte bei einem eventuell vorkommenden Festplattendefekt oder dem versehentlichen Löschen von wichtigen Tabellen nicht erneut ausgeführt werden müssen. In diesem Fall entschied man sich für einen sogenannten SQL Dump, dabei wird eine Textdatei erstellt mit deren Hilfe eine Datenbank komplett oder auch teilweise wiederhergestellt werden kann⁴³. Der Dump wurde folgendermaßen auf einer externen Festplatte erstellt:

pg_dump -o -b -C -f /media/swp/nextgen_ext8tb/ngmaps_backup_01_2017.sql ngmaps

Mit dieser Variante der Sicherung ist zwar keine Point-in-time-Wiederherstellung⁴⁴ möglich, da aber bei diesem Projekt keine Updates der OSM Daten vorgenommen werden ist es auchreichend die einmal im Jahr aufgesetzte Datenbank auf diese Weise offline zu sichern.

5. NextGen Maps Kartenerstellung 5.1Vorüberlegungen

In diesem Kapitel wird nun die eigentliche Erstellung der Karten und Kartenpakete erklärt.

Zunächst allerdings soll die Idee der weltweiten Kartenserien und Kartenpakete detailliert erläutert und die dafür zur Herstellung notwendigen Punkte näher dargelegt werden. In Kapitel 1 wurde bereits beschrieben, dass das Ziel dieses Projektes ein weltweit einheitliches Kartenpaket sein soll. Nach mehreren Diskussionsrunden wurden schließlich folgende Kartenserien beschlossen und wie in Kapitel 6 beschrieben in einem Vertriebskonzept festgehalten. Das Kartenangebot besteht aus drei sogenannten Packages. Jedes dieser Pakete beinhaltet ein genau definiertes Kartenset mit mehreren unterschiedlichen ergänzenden Datensätzen.

Global Package Raster: 1:1.000.000 Vektor: Low Detail Map

Terrain: DTED0

Util: Jeppesen AirNavigation Database

43 Fröhlich 2013, 57

44 Fröhlich 2013, 60

30 Continental Package

Raster: 1:500.000 Raster: 1:250.000 Vektor: Mid Detail Map

Terrain: SRTM3*

Util: Jeppesen Obstacle Database

Country Package Raster: 1:100.000

Raster: 1:50.000

Vektor: Streetlevel High Detail Map Terrain: SRTM1*

Util: Adressdatenbank

Das Country Package kann soweit verfügbar mit Nationalen oder englischen Labels ausgeliefert

werden.

* SRTM Abdeckung nur zwischen 60° N und 60° S.

Jedes dieser Pakete enthält die Daten der vorhergehenden Pakte, diese bauen aufeinander auf. Die Bestellung erfolgt über ein eigens für NextGen Maps erstelltes Bestellformular (siehe letzte Seite des Map Catalogs im Anhang). Bei den Terraindaten handelt es sich um frei zugängliche Daten die mit Hilfe der EuroAvionics eigenen Software Lösung (Map Conversion Suite) in das propriätare EuroNav Format konvertiert werden und im System angezeigt werden können. Bei den AirNavigation und Obstacle Datenbanken handelt es sich um Daten nach dem sog. ARINC 424 Format die von der Firma Jeppesen⁴⁵ geliefert und von EuroAvionics für die eigenen Systeme konvertiert und dem Endkunden zur Verfügung gestellt werden. Die einzelnen Pakete werden nochmals detailliert mit allen Inhalten und Möglichkeiten in einem Kartenkatalog im Anhang beschrieben.

45http://ww1.jeppesen.com/industry-solutions/aviation/government/arinc-424-navigational-data-service.jsp

31 Eine der wichtigsten Anforderungen an das gesamte Projekt war die Möglichkeit einfacher Updates. Dazu wurde die Welt in ein 20° x 20° Raster eingeteilt mit Hilfe dessen die Festlegung der einzelnen Pakete erfolgte. Abbildung 11 zeigt diese Einteilung.

Abb. 11: 20 Grad Raster als Basis aller Karteneinteilungen

Die durch diese Einteilung entstehenden Gebiete ergeben die jeweilligen Continental Packages. Insgesamt gibt es zehn einzeln zu bestellende Gebiete. Das bedeutet, dass bei einem Update nicht immer der komplette globale Datensatz ausgetauscht werden muss, sondern nur die jeweils betroffenen Kacheln.

Abb. 12: Einteilung der Continental Packages

Da aber häufig bei der Lieferung der Festplatte mit den Kartendaten nicht bekannt ist in welchem Gebiet der Kunde später operieren wird, wird immer das komplette Kartenset bestehend aus den Rasterkarten 1:1.000.000, 1:500.000 und 1:250.000 sowie den zugehörigen Vektorkarten low- und mid-Detail ausgeliefert. Nach der Bestellung des Kunden wird nur ein bestimmter kontinentaler Bereich mit Hilfe eines Lizenzschlüssels

32 freigeschaltet. Der Kunde hat dann immer Zugriff auf die weltweite 1:1.000.000 Rasterkarte und den freigeschaltenen Bereich des Continental Packages. Auf diesem Raster basiert auch die spätere Produktion und Konvertierung der Raster Karten. Dieses Basisraster wird nach unten in einem Quad Tree Schema weiter unterteilt. So ist sichergestellt dass immer, egal bei welchem Maßstab, die Zuordnung zur nächstgrößeren Rasterkachel und dem dazugehörgigen Paket gewährleistet ist.

Bei der Erstellung der Karten müssen einige weitere oftmals spezielle Punkte beachtet werden. Die erstellten Kartenserien sind nicht zum Druck auf Papier gedacht, sondern ausschließlich für die Nutzung in digitalen Umgebungen wie dem EuroNav System vorgesehen. Da das EuroNav eine große Anzahl an Hubschraubermustern und daraus resultierend eine große Vielzahl an unterschiedlichen Monitortypen unterstützt, müssen bei der Farbgebung der Karten sowie der Größe der einzelnen Beschriftungen oftmals Kompromisse eingegangen werden, die auf den ersten Blick eventuell unvorteilhaft wirken.

Das EuroNav System wird mit Monitoren die eine analoge VGA Auflösung von 640x480 Pixeln auf einem sog. STANAG⁴⁶ (Analogue Video Standard for Aircraft System Applications) Röhrenmonitor mit einer Größe von 5 Zoll anzeigen genauso verwendet wie auf einem 23 Zoll Full HD Monitor mit einer digitalen Auflösung von 1920x1080 Bildpunkten.

Abb. 13: Unterschiedliche Monitore einer Mil Mi-8

46 http://quicksearch.dla.mil/qsDocDetails.aspx?ident_number=96921

33

Abb. 14: EuroNav (großer Bildschirm) in einem modernen Cockpit

Für ein optimales Bild lassen sich der Displaymodus und andere Einstellungen wie Orientierung und Skalierung im EuroNav einstellen, dies hilft die Lesbarkeit der Karten auf großen wie auf kleinen Monitoren sicherzustellen. Da kleine Monitore in Sachen Bildschärfe oftmals auch größere Monitore übertreffen können, aber dafür durch die geringere Bilddiagonale und die Entfernung zum Piloten oder Benutzer häufig durch einen zu hohen Gehalt an Informationen nur schwer lesbar sind, müssen auch hierfür weitreichende Tests durchgeführt werden um die Lesbarkeit der Karten auf möglichst vielen Systemen sicherzustellen. Um Darstellungsprobleme zu vermeiden war zu Beginn ein zeitaufwendiges Testverfahren notwendig. Dabei wurden auf mehreren Monitoren alle verwendeten Monitorauflösungen getestet um so ein optimales Verhältnis zwischen den angezeigten Elementen und den Monitorauflösungen festzulegen.

34

Abb. 15: Testplatz mit mehreren Monitoren

Zuvor wurden bereits kurz die Datensätze der Firma Jeppesen angesprochen, bei diesen Datenbanken handelt es sich im Vektorkarten die über alle anderen im EuroNav angezeigten Kartendaten gelegt werden. Hierbei muss beachtet werden dass sich durch die Farbgebung und die Anzeige von bestimmten Objekten auf den NextGen Karten nicht der Fall der

„missleading information“ erzeugt wird. Das bedeutet die Farbgebung oder einzelne Objekte wie Flächen oder Punkt Signaturen dürfen nicht mit den gängigen Farbregeln für Aeronautische Karten im VFR (Visual Flight Rules) Betrieb verwechselt werden. Ebenfalls müssen die Karten gut von anderen Overlays wie z.B. Wetterradar oder TCAS (Traffic Collision Avoidance System) zu unterscheiden sein.

Abb. 16: Wetterradar Overlay im EuroNav

35

Abb. 17: TCAS Overlay im EuroNav

Die Farben und das Aussehen der einzelnen Objekte kann detailliert im Aeronautical Chart User Guide⁴⁷ der Federal Aviation Adminstration nachgelesen werden. Bei der Herstellung der NextGen Maps wurde strikt darauf geachtet dass sowohl die Farbgebung als auch typische Signaturen und Punktsymbole eindeutig von offiziellen aeronautischen Karten unterschieden werden können. Die folgenden Abbildungen zeigen einige Beispiele typischer aeronautischer Symbole und Farbgebungen.

Abb. 18: VFR Airspace

47https://www.faa.gov/air_traffic/flight_info/aeronav/digital_products/aero_guide/media/Chart_Users_Guide_12thEd.pdf

36

Abb. 19: VFR Checkpoints

Abb. 20: VFR Flight Restriction Zone

5.2Erstellung der Raster Karten

Die Raster des NextGen Projektes werden alle unter Linux mit dem Programm TileMill (Installation siehe Kapitel 3.2.3) erstellt und anschließend mit dem Tool Mapnik⁴⁸ gerendert.

Nach dem Start des Programmes erscheint eine Übersichtsseite mit allen aktuellen Projekten.

48 http://mapnik.org/

37

Abb. 21: TileMill Projektübersicht

Für neue Projekte muss zunächst ein Projektordner angelegt werden. Dies geschieht über die Einstellungen (Settings) in der linken Auswahlleiste. In diesem Ordner wird dann eine Daten mit dem Namen project.mml angelegt, in der alle benötigten Layer gespeichert werden.

Neben dieser Datei werden die übrigen Stylesheets abgelegt. Diese Dateien enthalten die Beschreibungen und Definitionen der einzelnen Karten.

Abb. 22: Projekteinstellungen in TileMill

38 In der Hauptansicht von TileMill sind folgende Aktionen und Einstellungen möglich.

Oben links befindet sich die Menüleiste, unten links die Bedienleiste mit der Layerauswahl und der CartoCSS-Hilfe. In der Mitte liegt die Karte mit Zoomlevel- Anzeige. Auf der rechten Seite befinden sich die Style-Sheets, in denen das Aussehen der Kartenelemente definiert wird. Oben rechts können Änderungen gespeichert und als XML Dokument exportiert werden (Dropdown Export, Auswahl MapnikXml).

Abb. 23: Hauptansicht TileMill

Das Beispiel in Abb. 23 zeigt bereits einen Ausschnitt einer 1:50.000er Raster Karte eines Country Packages. Die Inhalte dieser Karte sowie die Darstellung jedes einzelnen Elements erfolgt in TileMill im sog. CartoCSS Stil. Um auch hier die Lesbarkeit des Dokuments zu gewährleisten wird im Text nur ein kurzes Beispiel eines einzelnen Layers gezeigt. Eine Vollständige Sammlung aller für dieses Projekt angelegten XML Dateien befinden sich auf dem Datenträger (./xml). Die vollständige Dokumentation der CartoCSS Sprache ist Online unter der URL https://cartocss.readthedocs.io/en/latest/ zu finden.

39 Ein Layer kann durch den Klick auf das Editiersymbol weiterbearbeitet oder durch Klick auf das „+ Add Layer“ Feld neu angelegt werden.

Abb. 24: Layermenü

Folgendes Beispiel zeigt nun die Erstellung und genaue Definition des Layers „landuse- high-50“ .

• Selektion der PostGIS Datenbankverbindung

• Vergabe einer ID -> Unter dieser wird im CartoCSS das Layerelement angesprochen

• Falls nötig eine Class definieren: Hiermit können Elemente aus verschiedenen Layern im CartoCSS gemeinsam angesprochen werden (Werden durch

.Klassenname angesprochen)

• Verbindung zur Datenbank herstellen

• Unter „Table or subquery“ kann die entsprechende SQL Query eingegeben werden

• Geometry field füllen mit „way“

• Ausdehnung definieren, z.B. für die gesamte Welt: Im Dropdown-Menü Custom auswählen und im Textfeld -180,-90,180,90 eintragen

• Projektion auswählen: Im Dropdown-Menü unter SRS WGS84 auswählen

• Mit „Save-Button“ speichern

40

Abb. 25: Layerdefinition in TileMill

Für die Visualisierung wird auch direkt in TileMill eine Hilfe mit mehreren sehr guten Beispielen angeboten. Auf das ofizielle Online Manual wurde bereits hingewiesen.

Abb. 26: CartoCSS Hilfe in TileMill

41 5.3Erstellung der Vektor Karten

Die SQL Abfragen für die einzelnen Vektor Karten Layer entsprechen den jeweilligen TileMill Abfragen und beziehen sich auf die angelegten Views der Tabellen. Jedes zu exportierende Element besteht aus einer eigenen SQL Abfrage. Auch diese finden sich in gesammelter Form im auf dem Datenträger (./sql/streetlevelmap und ./sql/mid-low-detail).

Als Beispiel wird exemplarische je eine Abfrage für einen Punkt, Linien und Polygon Layer hier im Text beschrieben.

Water Areas:

SELECT geom, LEFT(chartrans1(name), 30) AS name, type \ FROM osm.area_water \

WHERE ST_Intersects(osm.area_water.geom, \

(SELECT country.geom_boundary_polygon AS geom FROM country.country where var = '%s')) \

AND type NOT IN ('salt_pond', 'swimming_pool');

Flughäfen Points:

WITH airport_union AS (

SELECT geom, LEFT(chartrans1(name), 30) AS name, icao_code AS icao \ FROM point_airport \

WHERE ST_Intersects(point_airport.geom, \

(SELECT country.geom_boundary_polygon FROM country.country where var = '%s')))

SELECT DISTINCT ON (name) * FROM airport_union

UNION SELECT *

FROM airport_union WHERE name = '';

Kleine Straßen:

SELECT osm.geom, COALESCE(NULLIF(chartrans1(osm.ref),''), LEFT(NULLIF(chartrans1(osm.name),''), 30)) AS name, osm.type \ FROM osm.line_roads_small AS osm, country.country AS country \ WHERE country.var = '%s' \

AND (tunnel!='yes' OR tunnel IS NULL) \

AND ST_Intersects(osm.geom, country.geom_boundary_polygon)

42 5.4Rendern der Raster Karten

Das Rendern der aus TileMill exportierten (Mapnik-)XML Dokumente geschieht nun mit eigenen Programmen, die alle unter Linux mit der Programiersprache Python geschrieben wurden. Die vollständige Auflistung aller Programme und Unterprogramme befindet sich auf dem beigelegten Datenträger im Ordner ./tools.

Das Hauptprogramm „render_tool“ besitzt eine graphische Oberfläche in der alle relevanten Einstellungen vorgenommen werden können. Mit diesem Tool lassen sich Rasterkarten aller Maßstäbe sowohl global als auch für einzelne Länder erzeugen.

Abb. 27: Render Raster Tool GUI der NextGen Karten

In der GUI gibt es drei Einträge die ausgefüllt werden müssen (Kachelnummer, XML und Language) sowie einen optionalen Eintrag (Massstab).

Masstab (optional): Es stehen 6 Checkboxen zur Verfügung (25k, 50k, 100k, 250k, 500k, 1000k). Wird hier eine Auswahl getroffen werden die im Feld „Kachelnummer“

eingetragenen Kacheln auf den ausgewählten Massstab übertragen (Bsp: Massstab 500k, Kachelnummer B10 = es werden alle 500k Kacheln in der Kachel B10 gerendert, also die b101, b102, b103, b104). Wichtig: Werden zwei oder mehr Maßstäbe ausgewählt, soll der xml-Eintrag auf „auto“ stehen.