Mathematik und Informatik - Willkommen bei deposit hagen · Kurzfassung Diese Arbeit zeigt, wie...

deposit_hagenPublikationsserver der Universitätsbibliothek

Effiziente Georeferenzierung mit OpenStreetMap-Daten

Mathematik und Informatik

Lehrgebiet Kooperative SystemeMasterarbeit

Markus Weber

Fakultät für Mathematik und Informatik

Lehrgebiet Kooperative Systeme

Effiziente Georeferenzierungmit OpenStreetMap-Daten

Masterarbeit von

Markus Weber

Wintersemester 2015/2016

Erstprüfer: apl. Prof. Dr. Christian Icking

Zweitprüferin: Dr. Lihong Ma

Datum: 31. März 2016

Kurzfassung

Diese Arbeit zeigt, wie Geodaten aus dem freien Projekt OpenStreetMap in mehrerenVerarbeitungsschritten umgeformt und aufbereitet werden können, um auf ihrer Basis einerechenzeiteffiziente Georeferenzierung durchzuführen. Zur Evaluierung wurde das dazuneu entwickelte System mit einem der bereits etablierten Georeferenzierungssystemeverglichen und zeigte dabei deutlich geringere Antwortzeiten. Diese wurden in ersterLinie durch den Verzicht auf Datenbanksysteme sowie durch eine speziell entworfeneAdressdatenstruktur und einen eigenen, darauf aufsetzenden Algorithmus erreicht.

Schlagwörter: Georeferenzierung, Verortung, Adressdaten, Geodaten, OpenStreetMap

Abstract

This thesis shows how to progressively transform geodata taken from the collaborativeproject OpenStreetMap into a data basis which provides foundation for a computation-timeefficient geocoding algorithm. For means of evaluation this newly-developed system hasbeen compared with one of the well-established geocoding systems. In this comparisonthe new system shows much shorter response times. This is—for the most part—becauseit has been implemented using an optimized geocoding algorithm and specialized addressdata structures instead of a database system.

Keywords: geocoding, address data, geodata, OpenStreetMap

Inhaltsverzeichnis

Inhaltsverzeichnis

Abkürzungsverzeichnis 9

1 Einleitung 111.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.2 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.2.1 Anforderungen an die Datenaufbereitung . . . . . . . . . . . . . . . 131.2.2 Anforderungen an die Georeferenzierung . . . . . . . . . . . . . . . 131.2.3 Anforderungen an die Handhabung . . . . . . . . . . . . . . . . . . 13

1.3 Abgrenzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.3.1 Abgrenzung bezüglich des Adressformats . . . . . . . . . . . . . . . 141.3.2 Abgrenzung bezüglich der Datenbasis . . . . . . . . . . . . . . . . . 15

2 Existierende Lösungen 172.1 Online-Dienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.1.1 Nominatim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.1.2 Osmocoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.1.3 OpenCage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.2 Software für Offline-Verwendung . . . . . . . . . . . . . . . . . . . . . . . . 202.2.1 OsmAnd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.3 Einordnung der existierenden Lösungen . . . . . . . . . . . . . . . . . . . . 21

3 Theoretische Grundlagen 233.1 Mathematische Verfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1.1 Quadratwurzel-Implementierung . . . . . . . . . . . . . . . . . . . . 233.1.2 Kosinus-Implementierung . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2 Geografische Verfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2.1 Geografische Vereinfachungen . . . . . . . . . . . . . . . . . . . . . 253.2.2 Bestimmung der Ausdehnung . . . . . . . . . . . . . . . . . . . . . . 273.2.3 Entfernungsbestimmung zwischen Geokoordinaten . . . . . . . . . 283.2.4 Repräsentierende Koordinaten eines geografischen Objekts . . . . . 293.2.5 Zuordnen passender Grenzpolygone . . . . . . . . . . . . . . . . . . 313.2.6 Ausschneiden per Grenzpolygon . . . . . . . . . . . . . . . . . . . . 363.2.7 Finden der nächsten Nachbarn „Nearest Neighbor“ . . . . . . . . . . 36

Effiziente Georeferenzierung mit OpenStreetMap-Daten 5

Inhaltsverzeichnis

3.3 Programmiertechnische Verfahren . . . . . . . . . . . . . . . . . . . . . . . 383.3.1 Wahl der Programmiersprache . . . . . . . . . . . . . . . . . . . . . 383.3.2 Modularisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.3.3 Objektorientierte Programmierung in C . . . . . . . . . . . . . . . . 403.3.4 Parallelisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4 Analyse der relevanten OSM-Datenstrukturen 454.1 OSM-Datentypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.1.1 Knoten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.1.2 Polygonzüge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.1.3 Relationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.1.4 Identifikatoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.1.5 Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.2 Serialisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.2.1 Datenformat XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.2.2 Datenformat PBF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.2.3 Datenformat o5m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.2.4 Objekt-Reihenfolge . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.3 Adressdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.3.1 Diskrete Hausadressen . . . . . . . . . . . . . . . . . . . . . . . . . 524.3.2 Mehrdeutige Hausadressen . . . . . . . . . . . . . . . . . . . . . . . 534.3.3 Unvollständige Hausadressen . . . . . . . . . . . . . . . . . . . . . 544.3.4 Sonderfälle von Hausadressen . . . . . . . . . . . . . . . . . . . . . 554.3.5 Verortung von Straßen . . . . . . . . . . . . . . . . . . . . . . . . . . 564.3.6 Verortung von Gemeinden . . . . . . . . . . . . . . . . . . . . . . . . 57

5 Effiziente Adressdatenstruktur 595.1 Datenumfang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.1.1 Adressen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.1.2 Geokoordinaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.1.3 Zusatzinformationen . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.2 Optimierungsziele für die Adressdatenstruktur . . . . . . . . . . . . . . . . . 605.3 Datenarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5.3.1 Dateninhalt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615.3.2 Datenbeziehung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625.3.3 Rückbeziehung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625.3.4 Einfacher Datenzugriff . . . . . . . . . . . . . . . . . . . . . . . . . . 635.3.5 Kombinierter Datenzugriff . . . . . . . . . . . . . . . . . . . . . . . . 63

5.4 Datenstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645.4.1 Datenstruktur für den Inhalt . . . . . . . . . . . . . . . . . . . . . . . 645.4.2 Datenstruktur für die Beziehungen . . . . . . . . . . . . . . . . . . . 64

6 Effiziente Georeferenzierung mit OpenStreetMap-Daten

Inhaltsverzeichnis

5.4.3 Identifikatoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655.5 Adressdaten-Serialisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . 655.6 Komprimieren der serialisierten Adressdaten . . . . . . . . . . . . . . . . . 67

6 Datenaufbereitung 696.1 Formatumwandlung der Rohdaten . . . . . . . . . . . . . . . . . . . . . . . 696.2 Hausadressen extrahieren – Verarbeitungslinie 1 . . . . . . . . . . . . . . . 706.3 Straßendaten extrahieren – Verarbeitungslinie 2 . . . . . . . . . . . . . . . 726.4 Gemeindepolygone extrahieren – Verarbeitungslinie 3 . . . . . . . . . . . . 726.5 Zusammenführen der Adressdaten . . . . . . . . . . . . . . . . . . . . . . . 746.6 Zuordnen der Gemeindepolygone . . . . . . . . . . . . . . . . . . . . . . . 756.7 Komplettieren der Adressdaten . . . . . . . . . . . . . . . . . . . . . . . . . 76

6.7.1 Einlesen von Zeichenketten und Adress-Tupeln . . . . . . . . . . . . 766.7.2 Dynamische Datenstruktur . . . . . . . . . . . . . . . . . . . . . . . 786.7.3 Vorverarbeitung der Adressdaten . . . . . . . . . . . . . . . . . . . . 796.7.4 Verarbeitung der Adressdaten . . . . . . . . . . . . . . . . . . . . . 806.7.5 Nachverarbeitung der Adressdaten . . . . . . . . . . . . . . . . . . . 816.7.6 Schreiben der Adressdaten . . . . . . . . . . . . . . . . . . . . . . . 82

7 Georeferenzierungsalgorithmus 837.1 Syntax der Eingabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837.2 Syntax der Ausgabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 847.3 Interaktives Verhalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 847.4 Software-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

7.4.1 Einlesen der aufbereiteten Adressdaten . . . . . . . . . . . . . . . . 857.4.2 Parsen der Eingabe . . . . . . . . . . . . . . . . . . . . . . . . . . . 857.4.3 Suche nach Ort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 867.4.4 Suche nach Ort und Straße . . . . . . . . . . . . . . . . . . . . . . . 867.4.5 Berücksichtigung der Hausnummer . . . . . . . . . . . . . . . . . . 877.4.6 Sortieren des Suchergebnisses . . . . . . . . . . . . . . . . . . . . . 88

8 Systemtest 918.1 Testdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 918.2 Testablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

8.2.1 Testinstallation von Nominatim . . . . . . . . . . . . . . . . . . . . . 928.2.2 Datenbank-Initialisierung von Nominatim . . . . . . . . . . . . . . . 928.2.3 Geschwindigkeitsmessung der Nominatim-Georeferenzierung . . . 938.2.4 Geschwindigkeitsmessung der osmposition-Georeferenzierung . . . 94

8.3 Testauswertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

9 Zusammenfassung und Ausblick 97


Inhaltsverzeichnis

Verwendete Software 99

Abbildungsverzeichnis 101

Tabellenverzeichnis 103

Quellenverzeichnis 105

Anhang 107


Abkürzungsverzeichnis


AG Aktiengesellschaft

API application programming interface, Aufrufschnittstelle für eine Menge vonaußen zugänglicher Prozeduren

bzip2 Dateikomprimierungsformat, nutzt blockweise Komprimierung

CC BY-SA freie Creative-Commons-Lizenz mit Copyleft und Namensnennungsklausel

CORDIC Coordinate Rotation Digital Computer, Algorithmus zur Implementierungverschiedener arithmetischer Funktionen auf einem Rechensystem

CPU Central Processing Unit, Prozessor, zentrale Verarbeitungseinheit eines Rech-ners

DV Datenverarbeitung

GNF Gewerbepark Nürnberg-Feucht-Wendelstein

GNU Sammlung von unter GPL stehender Software

GPL GNU General Public License, freie Software-Lizenz des GNU-Projekts

gzip GNU zip, freies Kompressionsformat für Dateien

HTTP Hypertext Transfer Protocol, Datenprotokoll, das hauptsächlich für die Über-tragung von Webseiten im Internet verwendet wird

ID Identifikator

iOS Betriebssystem für mobile Geräte der Firma Apple

LATEX um Makrofunktionen erweitertes interpreterbasiertes Textsystem

Linux Sammelbezeichnung für freie, Unix-ähnliche Rechner-Betriebssysteme

MMIO Memory-mapped I/O, in Sekundärspeicherzugriffe übersetzte Arbeitsspei-cherzugriffe

OBF OsmAnd binary format, Dateiformat für OsmAnd-Landkarten

ODbL Open Database License, freie Datenbank-Lizenz mit Copyleft und Namens-nennungsklausel

ogb OSM Geobase, effizientes Dateiformat für Adressdaten

OSM OpenStreetMap, Projekt für freie Geodaten

o5m OSM-Rohdatenformat, ermöglicht schnelles Lesen und Schreiben

PBF OSM-Rohdatenformat, ermöglicht kompaktes Speichern

PHP PHP Hypertext Preprocessor, Scriptsprache, hauptsächlich verwendet fürdynamische Webseiten



POI point of interest, wichtige Örtlichkeit (z.B. Haltestelle, Sehenswürdigkeit)

POSIX Portable Operating System Interface, standardisiertes API für Betriebssys-temfunktionen

ppm parts per million, ein Millionstel, relative Wertangabe

Qt plattformunabhängige Software-Bibliothek

SQL auch als Structured Query Language bezeichnet, weit verbreitete Manipula-tions- und Abfragesprache für Datenbanken

SSD solid-state drive, Sekundärspeicher ohne bewegliche Bauteile

TEX interpreterbasiertes Textsystem

Unix mehrbenutzerfähiges Rechner-Betriebssystem, dessen Entwicklung bis insJahr 1969 zurückreicht

US United States, Vereinigte Staaten

UTF Unicode Transformation Format, universelles Datenformat zum Übertragenund Speichern von Text

URL Uniform Resource Locator, einheitliches Identifizierungsschema, zum Bei-spiel für Webseiten

XML Extensible Markup Language, im Projekt OSM zum Speichern von Rohdatenin menschenlesbarer Form verwendet


1 Einleitung

Diese Arbeit zeigt, wie postalische Adressen mit Hilfe von aus dem Projekt OpenStreet-Map (OSM) gewonnenen Informationen in Geokoordinaten überführt werden können.Besonderer Wert wird dabei auf rechenzeitoptimierte1 Architektur und Implementierunggelegt.

1.1 Motivation

Beim Umgang mit ortsbezogenen Daten ist es oft notwendig, zu einer gegebenen Haus-Adresse die Geoposition, also die Position nach einem definierten geodätischen Koor-dinatensystem herauszufinden. Dieser Prozess wird als Georeferenzierung (englisch:geocoding) bezeichnet. Die so bestimmten Geokoordinaten bilden die Grundlage für wei-tere Berechnungen, wie beispielsweise die Bestimmung der Luftlinienentfernung. Ebensowerden sie als Eingangsgröße für alle gängigen Routingsysteme verwendet und sind nichtselten Basis für weitere mathematische Verfahren, wie etwa Fahrplanauskunftalgorithmenoder die Lösung des Traveling-Salesman-Problems.

Unabhängig davon lassen sich die errechneten Geokoordinaten zur automatischenPositionierung von computerbasierten Landkarten verwenden. Hierzu wird jeweils nebenden Koordinaten auch die ermittelte geografische Ausdehnung des anzuzeigenden Objektsbenötigt, um die Landkarte nicht nur zu positionieren, sondern auch sinnvoll zu zoomen,also den zu verwendenden Maßstab korrekt vorzugeben (siehe Beispiel in Abbildung 1.1).

Die meisten der verfügbaren Georeferenzierungssysteme stützen sich zur Positionsbe-stimmung auf ausgesuchte Datenbanksysteme mit besonderen Geodatenfunktionalitäten.Das hat den Vorteil, dass dadurch ausreichend getestete und daher zuverlässige Al-gorithmen verwendet werden. Nachteilig ist der erhöhte Verwaltungsaufwand, den dieVerwendung eines Datenbanksystems mit sich bringt. Gerade beim immer populärerwerdenden Einsatz von mobilen Geräten muss auf ressourcensparende Arbeitsweisen ge-achtet werden, weil dort insbesondere die Leistung der CPU begrenzt ist – oder begrenztwerden soll, um durch Energieeinsparung die Betriebszeit zu verlängern.

Ziel dieser Arbeit ist es, eine rechenzeitoptimierte Lösung für die Aufgabe der Georefe-renzierung zu entwerfen und zu implementieren. Dabei soll weitgehend auf alles verzichtetwerden, was zu einem erhöhten Verwaltungsaufwand führen könnte.

1Das Wort „optimiert“ wird in diesem Dokument als Begriff der Informatik im Sinn von „effizienzsteigernd“verwendet, es bezieht sich nicht auf ein mathematisch beweisbares Extremum.


1 Einleitung

(a) Ort „Langensendelbach“ (b) Straße „Kirchweg“ (c) Haus „Nummer 3“

Abbildung 1.1: geografische Ausdehnung unterschiedlicher Objekte [OSMMAP16]

1.2 Anforderungen

Weil die Verringerung der Rechenzeit des Suchalgorithmus im Vordergrund steht, emp-fiehlt es sich, eine eigene Datenstruktur zu entwickeln, die zum einen sicherstellt, dassalle Adressinformationen enthalten sind, und zum anderen schnelle lesende Zugriffe aufdie jeweils gesuchten Informationen erlaubt. Auf diese Weise zerfällt das zu entwerfen-de Gesamtsystem in zwei Teile, nämlich in das Teilsystem Datenaufbereitung, das dieOSM-Rohdaten in die genannte eigene Datenstruktur überführt, und in das TeilsystemGeoreferenzierung, das den eigentlichen Algorithmus zur Georeferenzierung enthält (sieheAbbildung 1.2). Besonders das zweite Teilsystem unterliegt den strengen Anforderungenhinsichtlich der Rechenzeit, während das erste Teilsystem – die Datenaufbereitung – seineAufgabe lediglich im Rahmen von Initialisierungs- oder Aktualisierungs-Phasen wahrnimmtund deswegen nicht im Fokus der Rechenzeitverbesserung liegt.

OSM-Rohdaten

Daten-aufbereitung

aufbereiteteAdressdaten

Georeferen-zierung

Abbildung 1.2: Gesamtsystem-Struktur

Vorstellbar ist, dass die Aufbereitung an zentraler Stelle erfolgt und die so generiertenDaten dann als eigene Einheit an die Anwender verteilt werden. Das hat den Vorteil,dass nur jeweils der zweite Teil der Gesamt-Software auf den Ziel-Geräten installiertwerden muss. Im Fall von mobilen Geräten wird dadurch außerdem die benötigte Betriebs-energie minimiert, was neben verringerter Wärmeentwicklung besonders der maximalenBetriebszeit zugutekommt.


1.2 Anforderungen

1.2.1 Anforderungen an die Datenaufbereitung

Zwar ist der erste Teil der Verarbeitung relativ unkritisch, was die Rechenzeit betrifft,grundsätzlich darf aber auch dieser Teil keine außergewöhnlichen Anforderungen anHardware und Betriebssystem stellen, weil Anwendungsfälle nicht ausgeschlossen werdensollen, bei denen auch die Datenaufbereitung auf Geräten mit geringer Rechenleistungausgeführt wird.

Daher soll auch bei diesem Teilsystem versucht werden, ohne Datenbanksystem undspezielle Bibliotheksfunktionen auszukommen. Besonders strenge, darüber hinausgehen-de Anforderungen existieren nicht.

1.2.2 Anforderungen an die Georeferenzierung

Beim Georeferenzierungsalgorithmus steht die Ressourcenoptimierung im Vordergrund.Das betrifft generell den Speicherplatzbedarf genauso wie die benötigte Rechenleistung.Allerdings stellen heute nicht nur die stationären, sondern auch die mobilen Geräte sowohlHaupt- als auch Sekundärspeicherplatz in großem Umfang zur Verfügung, so dass im Fallder Georeferenzierung der Schwerpunkt der Optimierung bei der Rechenzeitminimierungliegt.

1.2.3 Anforderungen an die Handhabung

Besonders universell einsetzbar sind Programme, die sich zur Verwendung als Unix-Filtereignen. Solche Programme lesen Eingabedaten von der Standard-Eingabe und schreibenErgebnisdaten an die Standard-Ausgabe. Die meisten Betriebssysteme stellen Mechanis-men zur Verfügung, die es erlauben, die Standard-Ein- wie auch Standard-Ausgabe vonund zu beliebigen anderen Programmen, Ein-/Ausgabe-Geräten und Dateien umzulenken.Als Filter arbeitende Programme lassen sich so an beliebigen Stellen in Verarbeitungsket-ten einbinden.

Kirchweg 3,Langensendelbach

Georeferen-zierung

11,07133 Ost49,64169 Nord

Abbildung 1.3: Unix-Filter

Beispiel für ein Linux-Befehlskette:

grep "�Maier;" adr.txt | cut -d";" -f2- | georeferenzierung >pos.txt 2

2In dieser Kommandofolge werden zuerst alle Zeilen aus der Datei adr.txt extrahiert, die mit „Maier;“beginnen. Anschließend sorgt das Kommando cut dafür, dass jeweils nur der Rest einer jeden Zeile übrigbleibt, in diesem Fall die Adresse. Das Programm georeferenzierung schließlich wandelt die Adressen


1 Einleitung

Soweit möglich und sinnvoll soll dieses Konzept für beide Teilsysteme, also sowohl fürdie Datenaufbereitung als auch für die Georeferenzierung, Anwendung finden. Nebeneiner universellen Einsetzbarkeit bringt das auch Vorteile für Test und Bewertung: beideAufgaben lassen sich dadurch relativ leicht automatisieren.

1.3 Abgrenzung

Für die Umsetzung des skizzierten Vorhabens erscheinen Einschränkungen unter zweiGesichtspunkten als sinnvoll: bezüglich des Adressformats und bezüglich der Datenbasis.

1.3.1 Abgrenzung bezüglich des Adressformats

Der strukturelle Aufbau von Adressen unterscheidet sich von Land zu Land, er ist nichtweltweit einheitlich. In Deutschland folgt der Aufbau dem Schema Straße, Hausnummer,Postleitzahl, Ort. Selbst in sehr kleinen Orten, in denen es keine benannten Straßen,sondern nur Hausnummern gibt, werden pro forma Straßennamen verwendet, um Adress-angaben nach diesem Schema zu ermöglichen.

Die Schreibweise deutscher Adressen folgt stets dem Middle-endian-Format, wie manes beispielsweise auch bei US-amerikanischen Datumsangaben findet: January 1st 2016.Das geringstwertige Ordnungskriterium befindet sich in der Mitte, das höchstwertige amEnde.:

Wittelsbacherplatz 2, 80333 München

Dagegen eine französische und eine australische Adresse (Little-Endian-Format):

40 avenue des Fruitiers, 93527 Saint-Denis Cedex

885 Mountain Highway, Bayswater, Victoria 3153

Diese Arbeit legt ihren Fokus auf den Algorithmus der Georeferenzierung an sich undsetzt deshalb als Vereinfachung voraus, dass ausschließlich deutsche Adressen verortetwerden sollen. Die geplante Implementierung als Unix-Filter erleichtert eine möglichespätere Anpassung an andere Adressformate.

in Positionen um und schreibt diese in die Datei pos.txt. Der Pipe-Operator „|“ verbindet jeweils einenVerarbeitungsschritt mit dem nächsten.


1.3 Abgrenzung

1.3.2 Abgrenzung bezüglich der Datenbasis

Betrachtet werden sollen ausschließlich unter freien Lizenzen veröffentlichte Adress- undGeodaten. Die größte so erhältliche Datenbasis wird durch das Projekt OpenStreetMapzur Verfügung gestellt. Auf der einen Seite erleichtert diese Abgrenzung die Lösung desProblems, weil Testdaten in ausreichender Anzahl vorhanden sind. Andererseits müssenDaten aus dem Projekt OpenStreetMap in besonderer Weise vorverarbeitet werden, umsie in eine für den Georeferenzierungs-Algorithmus nutzbare Struktur zu bringen. Das liegtin der Art der Datengewinnung begründet: OpenStreetMap lebt davon, dass Freiwillige ihreUmgebung selbst kartieren. Historisch bedingt existieren dadurch unterschiedliche parallelgenutzte Möglichkeiten zur hierarchischen Strukturierung von Adressdaten. Und natürlichkann auch die Vollständigkeit nicht garantiert werden. Das aber ist ein generelles Problemaller Quellen für Daten, die einer so großen Dynamik unterliegen wie Adressdaten.


2 Existierende Lösungen

Zur Bestimmung von Geokoordinaten auf Basis von Daten des freien Projekts Open-StreetMap existiert bereits eine Reihe von Software-Systemen. Diese lassen sich in zweiKlassen einteilen: Online-Dienste und eigenständige Programme zur Offline-Verwendung.In den folgenden Abschnitten werden die wichtigsten der verfügbaren Systeme vorgestelltund eingeordnet.

2.1 Online-Dienste

„Online“ bedeutet in diesem Fall nicht notwendigerweise, dass der betreffende Dienstnur über das Internet oder eine Datenfernverbindung verfügbar ist. Vielmehr lassen sichsolche Dienste auch lokal installieren und dann zum Beispiel per Internet-Browser oderper anwendungsspezifischem Client-Programm nutzen.

2.1.1 Nominatim

Nominatim1 ist der bekannteste Vertreter der OSM-Georeferenzierungsdienste. Er wirdinsbesondere von der auf der Hauptseite des OpenStreetMap-Projektes verfügbarenLandkarte genutzt. Zum Start der Suche genügt es, die betreffende Adresse in einembeinahe beliebigen Format in ein einzeiliges Eingabefeld zu schreiben. Nicht nur Adressen,sondern auch so genannte POIs – „points of interest“ – lassen sich damit suchen. Dazuzählen beispielsweise Namen von Bahnhöfen, Gaststätten und Museen.

Die zu suchende Adresse wird zwar in der Reihenfolge Lokal–Global erwartet, Nomi-natim wertet jedoch zusätzlich in umgekehrter Richtung aus, wenn die erste Suche, wieetwa im Fall einer vertauschten Eingabe bei „Nürnberg Bahnhofstraße“, nicht zum Erfolgführt. Es werden also zwei Adresssuchen durchgeführt, zuerst

• Straße="Nürnberg" Ort="Bahnhofstraße"

und bei ausbleibendem Erfolg anschließend

• Straße="Bahnhofstraße" Ort="Nürnberg"

Ein Komma als Trennzeichen der Adressbestandteile erleichtert die Auswertung [ND16].Fehlt das Komma, sind auch bei korrekter Eingabereihenfolge mehrere Durchläufe des

1https://nominatim.openstreetmap.org/



Suchalgorithmus notwendig. So lässt die Adresse „Auf der Schied, Schwäbisch Hall“ eineReihe von Interpretationen zu, wenn sie ungegliedert, also ohne das trennende Kommaeingegeben wird, und vergrößert damit den Suchaufwand:

• Straße="Auf" Ort="der Schied Schwäbisch Hall"

• Straße="Auf der" Ort="Schied Schwäbisch Hall"

• Straße="Auf der Schied" Ort="Schwäbisch Hall"

• Straße="Auf der Schied Schwäbisch" Ort="Hall"

• Straße=(nicht bekannt) Ort="Auf der Schied Schwäbisch Hall"

Berücksichtigt man den Fall, dass Straße und Ort möglicherweise in umgekehrter Rei-henfolge eingegeben werden, erhöht sich die Anzahl der Interpretationsmöglichkeiten beidiesem Beispiel auf neun.

Der von Nominatim auf diese Weise angebotene große Suchkomfort schlägt natürlichmit einem erhöhten Bedarf an Rechenleistung zu Buche. Auch kann diese vergrößerteInterpretationsvielfalt in Einzelfällen zu nicht gewünschten Suchergebnissen führen.

Neben der normalen beherrscht Nominatim auch die inverse Georeferenzierung (eng-lisch: reverse geocoding), kann also zu einer vorgegebenen Position die am bestenpassende Adresse herausfinden. Eine Reihe von Zusatzfunktionen steht ebenfalls zurVerfügung, darunter eine Auskunftsfunktion, die Detailinformationen zum Suchergebnisliefert:

Name: Auf der Schied

Type: highway:residential

Last Updated: 2015-02-26 17:41

Admin Level: 15

Rank: Street / Major Landmark

Importance: 0.1 (estimated)

Coverage: Point

Centre Point: 49.1106097,9.7409874

OSM: way 11851081

Besonders interessant ist die dabei ebenfalls angezeigte hierarchische Adressstruktur,welche eine enorme Tiefe aufweist:2

Auf der Schied (Type: highway:residential, way 11851081, 15, 0)

Tullauer Höhe (Type: place:suburb, node 2740375628, 15, 0.0100568012668018)

Schwäbisch Hall (Type: place:town, relation 391370, 8, 0.0198636425365925)

Verwaltungsgemeinschaft Schwäbisch Hall (Type: boundary:administrative,

relation 2960813, 7, 0.0146846012802313)

Landkreis Schwäbisch Hall (Type: boundary:administrative, relation 62582,

6, 0.171409429497281)

Regierungsbezirk Stuttgart (Type: boundary:administrative, relation 22041,

5, 0.149120384918874)

Baden-Württemberg (Type: place:state, relation 62611, 4, 0.898085713724145)

2Die in der Ausgabe referenzierten Datentypen node, way und relation sowie ihre Identifikatoren werden inKapitel 4.1 näher erläutert.


2.1 Online-Dienste

74523 (Type: place:postcode, relation 3378764, 15, 0.0198636425365925)

Deutschland (Type: place:country, relation 51477, 2, 2.29471491212127)

de (Type: place:country_code, 0)

Die hierfür benötigte ausführliche Datenanalyse samt Datenhaltung erfordert nicht nurviel Speicherplatz, sondern vor allem auch eine hohe Rechenleistung. Das liegt nichtzuletzt daran, dass sich die komplexen Mechanismen von Nominatim nur mit Hilfe einesDatenbanksystems in überschaubarer Weise verwirklichen lassen.

Zum Einsatz kommt das Open-source-Datenbanksystem PostgreSQL [NQ16], das sichdank spezieller Funktionen wie beispielsweise Schwerpunktbestimmung, Punktabstands-messung und k-Nearest-Neighbors [PG16], besonders gut für Geografie-Anwendungeneignet und daher auch bei vielen anderen Projekten im OpenStreetMap-Umfeld genutztwird.

2.1.2 Osmocoder

Der gewerbliche Internetauftritt 123map.de bietet seit Mitte des Jahres 2015 einen Geo-referenzierungsdienst auf Basis von OSM-Daten an. Dazu wird der Dienst Osmocoder3

eingesetzt.

Als Besonderheit dieses Systems ist die Anwendung eines dort so genannten Geome-triestempels zu nennen. Dabei handelt es sich um eine geografische Schablone, mit derdie Geodaten in einzelne Postleitzahl-Gebiete zerschnitten werden. Das führt allerdingsdazu, dass Straßennamen im Suchergebnis mehrfach erscheinen, wenn die betreffendeStraße durch mehr als ein Postleitzahl-Gebiet verläuft. [OCO16]

Der Quellcode von Osmocoder liegt nicht offen, so dass eine Aussage über die genauereinterne Arbeitsweise nicht möglich ist. Der Dienst ist nur über das Internet verfügbar, eineMöglichkeit der lokalen Installation wird nicht angeboten.

2.1.3 OpenCage

Auch bei OpenCage4 handelt es sich um einen gewerblichen Internetdienst. Laut Eigen-beschreibung arbeitet der Dienst als Meta-Geocoder, das heißt, die Suche wird jeweilsmit unterschiedlichen Georeferenzierungssystemen durchgeführt. Aus der Gesamtmengeder Suchergebnisse werden immer diejenigen ausgewählt, die die beste Trefferquoteversprechen.

Wie Nominatim bietet auch OpenCage Zusatzinformationen zu den Ergebnissen an. Dieso genannte Rohdaten-Antwort („Raw Response“) liefert neben den in unterschiedlichenKoordinatensystemen und Darstellungsarten angegebenen Geokoordinaten zusätzlichdas jeweilige Umgebungsrechteck, die „Bounding box“:

3http://www.osmocoder.de/geocoder.html4http://geocoder.opencagedata.com



"bounds" : {

"northeast" : { "lat" : 49.1110915, "lng" : 9.742161 },

"southwest" : { "lat" : 49.110566, "lng" : 9.7397437 } }

Aus diesem (sphärischen) Rechteck lässt sich die geografische Ausdehnung des ge-fundenen Objekts ableiten. Zwar enthalten die ausgegebenen Daten keine genauerengeometrischen Informationen wie Fläche oder Umfang, für viele Anwendungsfälle sindsie jedoch ausreichend – etwa für die Bestimmung der passenden Größe des anzu-zeigenden Landkartenausschnitts. Als weitere Zusatzinformation gibt die Antwort dieGenauigkeitsklasse zurück:

"confidence" : 10

Dieser Zahlenwert zeigt, mit welcher geografischen Genauigkeit das Ergebnis durch denSuchalgorithmus eingestuft wird.

Intern verwendet OpenCage unter anderem die Suchmaschine Nominatim und nutztdamit ebenfalls das Datenbanksystem PostgreSQL. [OCO16]

2.2 Software für Offline-Verwendung

Wie bereits erwähnt, kann freie Software, die grundsätzlich für Online-Suche bestimmtist, auch offline, also ohne Netzwerkverbindung eingesetzt werden. Server- und Client-Software werden hierzu auf dem gleichen Rechner installiert.

So kann das weiter oben vorgestellte Software-System Nominatim ohne Weiteresauf einem lokalen Rechner installiert und genutzt werden.5 Daneben existieren andereLösungen, die speziell für Offline-Verwendung entwickelt wurden. Als Beispiel hierfür solldie Suchfunktion von OsmAnd betrachtet werden.

2.2.1 OsmAnd

OsmAnd6 ist ein weit verbreiteter mobiler Betrachter für OSM-basierte Landkarten. Verfüg-bar ist er für die Betriebssysteme Android und iOS. Im Gegensatz zu den meisten anderenSmartphone-Kartenapplikationen werden bei OsmAnd Offline-Kartendaten in objektorien-tierter Form und nicht als Rastergrafik vorgehalten. Das Bild des jeweils anzuzeigendenKartenausschnitts wird lokal berechnet. Diese Technik erlaubt es, Landkarten für ein relativgroßes Gebiet – beispielsweise für ganz Europa – auf dem mobilen Gerät bereitzuhaltenund auf Wunsch des Benutzers in einem frei wählbaren Maßstab anzuzeigen.

Bei der Adresssuche lässt sich OsmAnd vom Benutzer eine Hilfestellung geben: Zuerstist das Bundesland auszuwählen, dann der Ort einzugeben und schließlich die Straße.

5Siehe dazu auch Abschnitt 8.2.1.6http://www.osmand.de/


2.3 Einordnung der existierenden Lösungen

Das grenzt den zu durchsuchenden Datenbestand ein und beschleunigt die Suche. Unter-stützt wird diese Vorgehensweise dadurch, dass das Programm die Kartendaten in nachBundesländern gegliederten Dateien speichert, den so genannten OBF-Files7. Danebenexistiert eine deutschlandweite Adresssuche, bei der die Eingabe von Ort und Straßeausreicht. Der dadurch größere Suchaufwand schlägt sich in einer höheren Antwortzeitnieder – die Auswahl eines kleineren Ortes benötigt typischerweise um die 10 Sekunden8.

Diese hohe Antwortzeit lässt vermuten, dass das Programm keine besonderen re-chenzeitoptimierten Verfahren für die Adresssuche verwendet. Der C++-Quellcode zeigt,dass zwar besondere Qt-Bibliotheksfunktionen genutzt werden, jedoch auf ein eigenesDatenbanksystem verzichtet wurde [OAQ16].

2.3 Einordnung der existierenden Lösungen

Bei Betrachtung der in den vorangegangenen Abschnitten vorgestellten Lösungen wirddeutlich, dass die Georeferenzierungsalgorithmen dort in der Regel auf Basis von Daten-banksystemen realisiert wurden. Die Verwendung eines Datenbanksystems widersprichtjedoch auf Grund des damit einhergehenden Verwaltungsaufwands dem angestrebtenrechenzeitminimierten Lösungsweg. In einem der untersuchten Systeme (OsmAnd) wurdekein Datenbanksystem für die Georeferenzierung verwendet, jedoch war dort vermutlichauch nicht die Rechenzeitverbesserung Ziel der Umsetzung.

Die Menge der hier untersuchten Lösungen stellt nur eine Teilmenge aller existierendenGeoreferenzierungssysteme dar. Es ist also nicht belegt, dass es keine rechenzeitmini-mierte Lösung im Sinn dieser Aufgabenstellung gibt. Der Überblick zeigt jedoch, dasssich eine solche Lösung nicht unter den populären Systemen befindet und es sich daherlohnen kann, einen entsprechenden Algorithmus zu entwerfen und zu implementieren.

7OsmAnd binary format8Durchschnittswert auf einem handelsüblichen Smartphone Samsung Galaxy S3


3 Theoretische Grundlagen

Die Aufgabenstellung dieser Arbeit verlangt nach verschiedenen Verfahren aus den Be-reichen Informatik und Geoinformatik. Beide Fachbereiche nutzen Grundlagen aus derMathematik, so dass eine klare Zuordnung zu einem bestimmten Fachbereich nicht immermöglich – und im Grunde auch nicht notwendig ist.

In den folgenden Abschnitten werden die wichtigsten der verwendeten Techniken vorge-stellt und hinsichtlich einer rechenzeitverbesserten Implementierung beschrieben.

3.1 Mathematische Verfahren

Die hier gezeigten mathematischen Verfahren haben jeweils direkt oder indirekt Bezug zurGeografie, da sie für Entfernungsberechnungen unverzichtbar sind.

3.1.1 Quadratwurzel-Implementierung

Wie für etliche andere mathematische Operationen stehen in den gängigen Hochsprachenauch für das Berechnen der Quadratwurzel Bibliotheksfunktionen zur Verfügung. Im Fallder Programmiersprache C ist dies die Funktion sqrt() aus der Bibliothek math.

sqrt() gibt es in drei Varianten, und zwar für die Fließkomma-Datentypen float, dou-ble und long double. Die damit unterstützte hohe Rechengenauigkeit wird hier jedochnicht benötigt. Zudem sind Festkommazahlen für die zu implementierende Anwendungvöllig ausreichend. Aus diesem Grund wurde die Quadratwurzelberechnung neu aufGanzzahlbasis implementiert. Verwendet wird dazu das Heron-Verfahren [He16].

Es handelt sich dabei um eine rekursive Berechnungsvorschrift, die nach wenigenIterationsschritten in einem für den vorliegenden Anwendungsfall ausreichenden Maßkonvergiert. Die C-Implementierung eines solchen Berechnungsschritts sieht so aus:

x= (x+radicand/x)/2;

Versuche haben gezeigt, dass die Anzahl der für das Erreichen einer bestimmtenrelativen Genauigkeit notwendigen Iterationsschritte abhängig ist von der Größe desRadikanden. Die hier verwendete Implementierung der Funktion berücksichtigt das undsieht dafür entsprechende Bereichabfragen vor.1

1Details zur Implementierung sind im Testprogramm „test_sqrt1.c“ zu finden wie auch in der Prozedur„sqrt32()“ in der Quellcode-Datei „osmassignpoly.c“.



Trotz der primitiven Art der Berechnung und der geringen Genauigkeit arbeitet dieImplementierung des Heron-Verfahrens auf handelsüblichen PCs im Vergleich zur sqrt()-Funktion der math-Bibliothek deutlich langsamer.2 Das ist damit zu erklären, dass dieBibliothek-Funktion auf in Hardware implementierte Mechanismen und Tabellen zurück-greift.

Wegen dieses Nachteils wurde die eigene Implementierung nur in einem rechenzeitun-kritischen Abschnitt des Programms „osmassignpoly.c“ eingesetzt und hat dort zumindestden einen Vorteil, dass die Bibliothek math nicht eingebunden werden muss.

3.1.2 Kosinus-Implementierung

Während man aus der Differenz zweier Breitengrade die Entfernung auf der Erdoberflächedurch einfache Multiplikation berechnen kann, wird bei Längengraden für die gleicheAufgabenstellung zusätzlich die Kosinusfunktion benötigt:

Entfernung = (Langengrad2 − Langengrad1) · k · cos Breitengrad

Auch hierfür existiert eine eigene Funktion in der Bibliothek math – mit dem schonfür den Fall der Quadratwurzel beschriebenen Nachteil. Es bietet sich also ebenfallsan, ein numerisches Verfahren eigens zu implementieren, beispielsweise den CORDIC-Algorithmus3.

In der zu realisierenden Anwendung geht es jedoch meist nur darum zu bestimmen, obzwei Geopositionen zueinander „nahe“ liegen oder nicht. Bei der Definition von „nahe“kommt es auf eine Abweichung von wenigen Prozent nicht an. Deswegen wurde dieKosinus-Funktion als einfache Tabelle implementiert. Vom insgesamt benötigten Werte-bereich –90 bis +90 Grad reicht es aus, nur den Teilbereich 0 bis +90 Grad per Tabelleabzubilden; der Teilbereich –90 bis kleiner 0 Grad wird per Absolutwertbildung in denpositiven Bereich umgelegt.

Die Kosinus-Tabelle umfasst 901 Einträge – ein Eintrag je 0,1 Grad. Sie wurde einmaldurch ein sehr einfaches Programm unter Verwendung der C-eigenen math-Bibliothekberechnet und dann direkt im Quellcode des Anwendungsprogramms abgelegt.4 Das zurBerechnung der Tabelle verwendete Programm befindet sich zum Zweck der Dokumentati-on ebenfalls mit in dieser Quellcode-Datei – auskommentiert per Präprozessor-Anweisung.

Kosinus-Werte, die zwischen den Tabelleneinträgen liegen, können durch Interpolationermittelt werden. Es hat sich jedoch gezeigt, dass diese Art der Verbesserung nichtnotwendig ist, weil auch schon die durch die reinen Tabellenzugriffe erhaltene Genauigkeitmehr als ausreichend ist. Der Fehler im mittleren Winkelbereich liegt bei ca. 2 ‰:

2Tests erfolgten mit dem Programm „test_sqrt2.c“; Details siehe dort.3„Coordinate Rotation Digital Computer“4siehe Prozedur „lonadapt()“ in der Quellcode-Datei „osmgeobase.c“


3.2 Geografische Verfahren

cos 45,0◦

cos 45,1◦ = 1, 0017

Da der Kosinus-Wert in Bereichen nahe –90 und und nahe +90 Grad gegen null tendiert,muss dort mit einem deutlich größeren Fehler gerechnet werden:

cos 89,5◦

cos 89,6◦ = 1, 2500

In der Praxis fällt das aber nicht ins Gewicht, da die Gebiete der geografischen Pole nichtZiel der Georeferenzierung im Sinn der Aufgabenstellung sind. Die maximale Abweichungfür Deutschland beträgt etwa cos 55◦/ cos 55, 1◦ − 1 und damit ca. 2,5 ‰


Von den der Geografie zuzuordnenden Verfahren besitzen die Techniken der Vereinfa-chung schon konzeptionell das größte Potenzial zur Einsparung von Rechenzeit. Bei denübrigen Verfahren kommt es eher auf die rechenzeitoptimierte Art der Implementierungan.

3.2.1 Geografische Vereinfachungen

Ziel ist es, ein Modell der Wirklichkeit zu entwerfen, das ihr soweit entspricht wie geradenotwendig und gleichzeitig – unter rechentechnischen Gesichtspunkten – so einfach undeffizient ist wie möglich. Mit „einfach“ verringert sich der Programmieraufwand und mit„effizient“ der anschließend notwendige Rechenaufwand.

3.2.1.1 Geografische Genauigkeit

Je höher die Genauigkeit ist, in der ein Wert verarbeitet werden muss, desto höherist meist auch der dabei zu bewältigende Rechenaufwand. Gerade für die bei mobilenGeräten häufiger zu findenden einfacheren Mikroprozessoren gilt, dass Variablen mitgeringerer Speicherbreite weniger Rechenaufwand verursachen als Variablen mit größererSpeicherbreite. Unabhängig davon ist es bei gegebener linearer Werteverteilung in derRegel wirtschaftlicher, an Stelle von Fließkomma-Datentypen auf die Ganzzahl- oder dieFestkommarepräsentation zurückzugreifen.

Im Fall der im Rahmen des OpenStreetMap-Projekts stets als Längen- und Breitengradvorliegenden Geokoordinaten bietet sich die Ganzzahldarstellung in der Einheit 100 Na-nograd an. Das entspricht in Bezug auf ganze Grad-Zahlen einer Festkommadarstellungmit 7 dezimalen Nachkommastellen. Der Wertebereich von –180 bis +180 Grad (beiden Längengraden) findet auf diese Weise Platz in einer vorzeichenbehafteten 32-Bit-Variablen5. Geht man überschlagsweise davon aus, dass jeweils drei Dezimalstellen in

5Der Wertebereich einer vorzeichenbehafteten 32-Bit-Variablen reicht von –2147483648 bis +2147483647,was dann einem Winkelbereich von rund –214 bis +214 Grad entspricht.



zehn Binärstellen gespeichert werden können, lässt sich die Zuordnung von Ziffern zuSpeicherzellen vereinfacht so darstellen (Beispiel):

Bit 3130 29..20 19..10 9 .. 0

– 1 79,1234567°Für sehr viele Anwendungen ist die dadurch erhaltene Genauigkeit von 100 Nanograd

ausreichend. Diese Art der internen Koordinaten-Darstellung ist bei OSM inzwischen weitverbreitet und wird bei den häufig genutzten binären OSM-Datenformaten „PBF“ und „o5m“als Standard-Zahlenformat verwendet [PBF16] [O5M16].

Der Winkelwert 100 Nanograd entspricht auf der Erdoberfläche bei den Breitengradenca. 1,11 cm und bei den Längengraden auf Grund der Art der Projektion zwischen 0und 1,11 cm Entfernung. Insgesamt wird so eine Auflösung von mindestens 1,11 cmgewährleistet, was für den vorliegenden Anwendungsfall der Georeferenzierung vonAdressdaten mehr als ausreicht.

3.2.1.2 Sphärische Trigonometrie

Als erste und naheliegendste räumliche Vereinfachung wird die Erde als Kugel betrachtet.Tatsächlich unterscheidet sich der Durchmesser der Erde je nach geografischer Lage umbis zu 3,4 ‰ [Erde16]. Ein solch geringer Fehler kann bei der vorliegenden Aufgabenstel-lung aber ohne Weiteres vernachlässigt werden.

Grundsätzlich lässt sich die Entfernung zwischen zwei Punkten der Erdoberflächeals direkte, die Erde durchdringende Strecke, oder entlang der Oberfläche bestimmen– je nachdem, ob die Erdkrümmung berücksichtigt werden soll oder nicht. Für die hiervorliegende Aufgabenstellung ist dieser Unterschied jedoch nicht relevant, weil die Entfer-nungsmessung nur im Rahmen der Bestimmung der nächsten Punkt-Nachbarn benötigtwird, es handelt sich also durchweg um geringe Entfernungen von bis zu 750 Metern. Derrelative Fehler errechnet sich wie folgt:

(750m/2/40000km)sin(750m/2/40000km) − 1 = 1, 4·10−11

Er beträgt also weit unter einem ppm, damit kann die Erdkrümmung ebenfalls vernachläs-sigt werden.

Genauer betrachtet werden muss hingegen die Problematik der verwendeten Projektion.Geopositionen werden im Rahmen des Projekts OpenStreetMap jeweils als Längen-und Breitengrad gespeichert. Zur Vereinfachung der weiteren Verarbeitung können dieseKoordinaten auf die Ebene übertragen werden: der Längengrad wird zur X-Koordinate,der Breitengrad zur Y-Koordinate. Dieses Vorgehen entspricht der normalen Mercator-Projektion. Zwar werden dadurch Winkel korrekt abgebildet, Entfernungen in West-Ost-Richtung aber werden verfälscht und müssen deshalb korrigiert werden (siehe Abbildung3.1).



Abbildung 3.1: sphärisches Rechteck 20°×20° auf der Erdoberfläche

Dazu wird die Winkeldifferenz der Längengrade mit einem vom Wert des jeweiligen Brei-tengrads abhängigen Faktor korrigiert. Verwendet wird die in Abschnitt 3.1.2 beschriebeneImplementierung der Kosinus-Funktion.

3.2.2 Bestimmung der Ausdehnung

Häufig benötigt man neben der Geoposition auch die geografische Ausdehnung des betref-fenden Objekts. Zu solchen Anwendungsfällen gehört die Generierung von Kartenbildern:je nach Ausdehnung eines Objekts muss entschieden werden, ob es beim gewähltenMaßstab sichtbar sein soll oder nicht. Daneben kann aus dieser Information auch ab-geleitet werden, wie relevant ein Objekt ist: ein großer Gebäudekomplex ist wichtigerals ein kleines Haus, eine große Stadt wichtiger als ein Dorf. Auf dieser Basis lassensich beispielsweise die Ergebnisse einer Adresssuche ihrer Bedeutung nach sortieren.Wie bereits erwähnt, hilft die Größenangabe auch beim automatischen Skalieren vonKartenausschnitten: eine Großstadt wird auf dem Bildschirm in einem deutlich kleinerenMaßstab angezeigt als ein einzelnes Haus (siehe Beispiel in Abbildung 1.1 in Abschnitt1.1).

Als Kriterium für die Ausdehnung eines geografischen Objekts kann dessen Flächeherangezogen werden. Diese gibt die gesuchte Größe jedoch oft nur unzureichend wieder.Bei einer Eisenbahnlinie beispielsweise ist nicht ihre Grundfläche von Bedeutung, sondernihre Länge. Entscheidend ist im Allgemeinen der größte Durchmesser des Objekts.

Da die Ermittlung des größten Durchmessers nicht ohne erheblichen Aufwand möglichist, bedient man sich stattdessen des Umgebungsrechtecks (englisch: Bounding box)6.Dieses Rechteck ist durch Minimum-/Maximum-Berechnungen aus den Längen- und Brei-tengraden des betreffenden geografischen Objekts und gegebenenfalls seiner hierarchischuntergeordneten Objekte relativ einfach zu bestimmen.

6Es handelt sich natürlich um ein sphärisches Rechteck, was hier aber ebenfalls vernachlässigt werdenkann.



Auch hier kommt es nicht auf hohe Genauigkeit an. Es reicht eine grobe Einordnung inmehrere Größenstufen, die beispielsweise dadurch erfolgen kann, dass man das Maximumaus West-Ost-Ausdehnung und Süd-Nord-Ausdehnung wählt und davon den Logarithmusbildet. Eine hohe Größendynamik kann so auf einen kleinen Wertebereich abgebildetwerden, zum Beispiel 4 für ein Haus, 9 für eine Straße, 11 für einen Ort.

3.2.3 Entfernungsbestimmung zwischen Geokoordinaten

Lässt man – wie weiter oben begründet – die Erdkrümmung außer Acht, vereinfacht sichdie Entfernungsbestimmung auf Basis der Längen- und Breitengrad-Entfernungen zu zweiMultiplikationen, einer Addition und einer Wurzelberechnung (Satz des Pythagoras):

Entfernung =√dX2 + dY 2

Dabei stehen dX für die Entfernung in West-Ost-Richtung und dY für die Entfernung inSüd-Nord-Richtung.

Gerade die Wurzelberechnung ist jedoch eine im Bezug auf die benötigten Ressourceneine vergleichsweise teure Operation. In Abhängigkeit von der Architektur des Zielsystem-Prozessors kann es günstiger sein, die auf begrenzte Genauigkeit ausgelegte Implemen-tierung des in Abschnitt 3.1.1 vorgestellten Heron-Verfahrens zu verwenden.

Beim Komplettieren der Adressdaten werden im Rahmen der Bestimmung der nächstenNachbarn trotz anderweitiger Optimierungen immer noch ca. sieben Milliarden Entfer-nungsberechnungen notwendig sein (siehe Abschnitt 6.7). Daher lohnt es sich, nachweiteren Möglichkeiten der Optimierung und Vereinfachung zu suchen, die das Ergebnisder Entfernungsbestimmung hinreichend genau approximieren.

Ein primitiver Ansatz besteht darin, an Stelle der Anwendung des Satz des Pythagorasdie in Entfernungen umgewandelten Koordinatendifferenzen der Längengrade und derBreitengrade zu addieren. Als Summe erhält man eine grobe Näherung zur tatsächlichenEntfernung. Der Faktor der Abweichung liegt zwischen 1 und

√2, das Ergebnis ist also

regelmäßig zu groß.Mit einer ähnlich preiswerten Operation, einem Vergleich, gelingt eine Näherung aus ent-

gegengesetzter Richtung. Dazu werden wie oben die Entfernungen in West-Ost-Richtungund in Süd-Nord-Richtung bestimmt und die größere von beiden als Ergebnis ausgewählt.Hier liegt die Abweichung zwischen

√0, 5 und 1.

Für die vorliegende Aufgabenstellung fällt die Wahl auf eine etwas teurere, aber trotz-dem noch sehr ressourcensparende Entfernungsbestimmung. Die soeben vorgestelltenMethoden „Summe“ und „Maximum“ werden dazu miteinander kombiniert:

Entfernung = Maximum(dX, dY ) +Minimum(dX, dY )/4

Gute Ergebnisse lassen sich mit einem Divisor zwischen 3 und 4 erreichen. Im Interesseeiner möglichst einfachen Operation fiel die Wahl auf 4, da hier die Division auch durch diebei manchen Mikroprozessoren preiswertere Verschiebeoperation ersetzt werden kann.



Abbildung 3.2 zeigt die Äquidistanzlinien der drei beschriebenen Methoden im Vergleichzur korrekten Entfernungsberechnung per Satz des Pythagoras.

Abbildung 3.2: Äquidistanzlinien verschiedener Methoden der Entfernungsbestimmung

Man erkennt, dass die hier rot dargestellte achteckige Äquidistanzlinie der kombiniertenMethode der idealen Linie, dem Kreis, relativ nahe kommt. Zum Einsatz kommt dieseArt der Entfernungsermittlung in der Prozedur „geodistance()“ in der Quellcode-Datei„osmgeobase.c“.

Der Vollständigkeit halber muss erwähnt werden, dass diese Art der Entfernungsbe-rechnungen zu Fehlern führt, wenn die zu messende Strecke den 180. Längengradüberschreitet. Dieses Tatsache kann aber außer Acht gelassen werden, da die Anwen-dungsregion weit von der Datumsgrenze entfernt liegt.

3.2.4 Repräsentierende Koordinaten eines geografischen Objekts

Abhängig von der Gestalt des geografischen Objekts kann man dessen Position entwe-der direkt übernehmen oder muss sie erst noch berechnen. Das soll anhand von dreiBeispielen kurz erläutert werden.

• Punkt

Obwohl physische Objekte in der Praxis stets eine Ausdehnung besitzen, werden siehäufig als Punkt kartiert. Das betrifft meist kleine Einrichtungen und Gegenständewie Briefkästen, Telefonzellen oder Sitzbänke. Nur wenige der kartierten Punktehaben tatsächlich keine Ausdehnung, beispielsweise die Anhaltepositionen vonStraßenbahnen.

Im Fall solcher Punkte – egal ob unecht und echt – werden als Position die angege-benen Geokoordinaten direkt übernommen.

• Linie

Bahnlinien, Straßen, Mauern und vergleichbare Objekte werden in der Regel je-weils als Polygonzug kartiert. Sollen sie stellvertretend durch einen als Markierung



gesetzten Punkt in der Karte repräsentiert werden, muss darauf geachtet werden,dass diese Markierung das Objekt direkt berührt. Daher reicht es nicht aus, wiein Abbildung 3.3 für die gelb eingefärbte Straße illustriert, nur den geometrischenMittelpunkt zu bestimmen.

Abbildung 3.3: fehlerhaft repräsentierende Koordinaten einerLinie [OSMMAP16]

Das im Rahmen der Datenaufbereitung verwendete Programm osmconvert [OCQ16]bestimmt als Erstes das Umgebungsrechteck und ermittelt anschließend den Po-lygonpunkt, der dem Mittelpunkt dieses Rechtecks am nächsten liegt. Der Quell-code zeigt, dass dabei die in Abschnitt 3.2.1.2 erläuterte Verzerrung der Mercator-Projektion außer Acht gelassen wird: Längen- und Breitengrad-Differenzen werdenohne vorherige Umrechnung addiert.7 Trotzdem ist das Ergebnis für den vorgese-henen Anwendungsfall akzeptabel, da sichergestellt ist, dass die als Repräsentantberechneten Koordinaten eine Position im mittleren Verlauf der Straße bezeichnen.

• Fläche

Im Gegensatz zu den Linien reicht es bei Flächen-Objekten wie Städten, Gebäudenoder Seen normalerweise aus, wenn sie durch die Mittelpunktkoordinaten ihresjeweiligen Umgebungsrechtecks repräsentiert werden.

Zwar besteht bei konkav gestalteten Flächen trotzdem die Gefahr, dass sich – wieim Beispiel der Abbildung 3.4 gezeigt – eine mittig gesetzte Karten-Markierung nichtim inneren Teil der Fläche befindet, jedoch stellt das für den Anwender meist keineHürde dar, weil das betreffende Objekt trotzdem leicht der Markierung zugeordnetwerden kann.

7siehe Quellcode-Abschnitt „determine the node which has the smallest distance to the center of the bbox“in der Datei „osmconvert.c“



Abbildung 3.4: repräsentierende Koordinaten einer Fläche [OSMMAP16]

3.2.5 Zuordnen passender Grenzpolygone

Die Datensammlung von OpenStreetMap stellt für kommunale Verwaltungseinheiten je-weils das zugehörige Grenzpolygon (englisch: border polygon) zur Verfügung. Im Rahmender Datenaufbereitung muss für jedes geografische Objekt herausgefunden werden, aufwelchem Gemeindegebiet es sich befindet. In vielen Fällen ist diese Information nicht aufdirektem Weg mit dem Objekt verbunden, sondern kann nur durch gesonderte Berechnungermittelt werden. Die Strahl-Methode des Punkt-in-Polygon-Tests nach Jordan hilft bei derBewältigung dieser Aufgabe [Jo16].

Dazu bestimmt man die Anzahl der Schnittpunkte zwischen einem vom betrachtetenPunkt ausgehenden Strahl und dem jeweils untersuchten Grenzpolygon. Der Punkt liegtgenau dann innerhalb des Polygons, wenn eine ungerade Anzahl an Schnitten ermitteltwurde. Wie Abbildung 3.5 veranschaulicht, gilt das unabhängig von der Richtung desStrahls und unabhängig davon, ob das Grenzpolygon Enklaven enthält.

Abbildung 3.5: Strahl-Methode des Punkt-in-Polygon-Tests nach Jordan

Der geringste Rechenaufwand entsteht, wenn man den Strahl genau entlang der Rich-tung der Längen- oder Breitengrade führt. Bei dem im Rahmen dieser Arbeit implemen-tierten Algorithmus wurde die Nordrichtung gewählt.

Der Sonderfall, dass der Strahl das Grenzpolygon nicht nur schneidet, sondern entlangeiner seiner Kanten verläuft – was in Abbildung 3.5 bei einem genau nordwärts führendenStrahl der Fall wäre – muss näher betrachtet werden. Hier ist darauf zu achten, dass eine



solche in Süd-Nord-Richtung verlaufende Kante entweder ignoriert oder als doppelterSchnitt gezählt wird. Das gilt jedoch nur dann, wenn die direkt daran anschließendenKanten beide Richtung Westen oder beide Richtung Osten verlaufen. Führen sie inunterschiedliche Richtungen, muss die in Süd-Nord-Richtung verlaufende Kante als genauein Schnitt gezählt werden.

Der für die Datenaufbereitung entwickelte Algorithmus berücksichtigt diesen Sonderfalldadurch, dass er Süd-Nord-Kanten generell ignoriert und bei allen übrigen Kanten jeweilsnur das westliche Ende als zur Kante gehörend ansieht.8 Abbildung 3.6 zeigt dieseSonderfallbehandlung in Form von drei Beispielen.

Abbildung 3.6: Sonderfälle bei Verwendung der Strahl-Methode

Auch bei diesem Algorithmus lohnt es sich, nach weiteren Optimierungsmöglichkeitenzu suchen, denn bei der Aufbereitung der Adressdaten muss der Punkt-in-Polygon-Testsonst ca. 150 Milliarden Mal ausgeführt werden.9 Verbesserungen lassen sich unabhängigvoneinander auf drei verschiedene Wege erreichen: Beschleunigung der Schnittpunkt-suche, Reduzierung der Anzahl an Grenzpolygon-Kanten und Vorauswahl der jeweils inFrage kommenden Polygone. Das im Rahmen der Datenaufbereitung verwendete Modul„poly“ nutzt jeden dieser Wege.10

3.2.5.1 Beschleunigung der Schnittpunktsuche

Aus geometrischer Sicht ist für jede Kante des Grenzpolygons zu prüfen, ob ein Schnitt-punkt mit dem Nordstrahl des zu betrachtenden Punktes existiert:

(y − y1) · (x2 − x1) < (x− x1) · (y2 − y1)

Diese Prüfung ist trivial, sie benötigt mit vier Subtraktionen, zwei Multiplikationen undeinem Vergleich aber trotzdem ein gewisses Maß an Rechenzeit und sollte nur dannerfolgen, wenn es wirklich notwendig ist. Von Vorteil ist es daher, eindeutige Fälle schonvorher auszusortieren:

8Details siehe Prozedur „poly_querypolygon()“ in der Quellcode-Datei „osmassignpoly.c“.9Für etwa 13 Millionen Punkte muss geprüft werden, in welchen der ca. 11400 Grenzpolygone sie liegen.

10Der Quellcode hierzu befindet sich im Abschnitt „poly_“ in der Datei „osmassignpoly.c“.



a) Liegen beide Enden der zu prüfenden Polygonkante westlich des betrachteten Punktes,kann es keinen Schnittpunkt mit dem Nordstrahl geben. Gleiches gilt, wenn beideEnden östlich des Punkts liegen.

b) Liegen beide Enden der Polygonkante südlich des betrachteten Punkts, kann esebenfalls keinen Schnittpunkt geben.

c) Treffen a) und b) nicht zu und sind beide Enden der Polygonkante nördlich des Punkts,dann schneidet der Nordstrahl diese Kante.

Die tatsächliche Schnittpunktberechnung braucht nur dann zu erfolgen, wenn wedera) noch b) noch c) zutreffen, das heißt, wenn ein Ende der Polygonkante westlich, dasandere östlich des zu betrachtenden Punkts liegt – und zugleich – eines der Endensüdlich, das andere nördlich. Oder anders ausgedrückt: wenn sich der Punkt innerhalbdes Umgebungsrechtecks dieser Kante befindet.

Um nicht alle der durchschnittlich etwa 500 Kanten eines jeden Grenzpolygons nachdiesem Muster prüfen zu müssen, werden sie vorab jeweils nach Längengraden sor-tiert. Für jeden Längengrad-Abschnitt, in dem die Menge der dazu gehörenden Kantengleichbleibend ist, wird eine Liste angelegt und die betreffenden Kanten werden in dieseeingetragen. Dadurch brauchen für einen Punkt-in-Polygon-Test nur noch der richtigeLängengrad-Abschnitt ermittelt und die dort gelisteten Kanten – in der Regel nur zwei odervier – untersucht zu werden. Abbildung 3.7 veranschaulicht die Zuordnung von Kanten zuLängengradabschnitten in Form eines Beispiels.

Abbildung 3.7: Längengradabschnitte bei Verwendung der Strahl-Methode

Die Prüfung reduziert sich also auf durchschnittlich etwa drei Kanten, zuzüglich ca. zehnIterationen eines binären Suchalgorithmus, mit dessen Hilfe der betroffene Längengrad-Abschnitt ermittelt wird.11 Setzt man bezüglich des Rechenaufwands eine Iteration miteiner Schnittpunktbestimmung gleich, verringert sich die Gesamtrechenzeit um mehr als97 %.

11Der binäre Logarithmus von 500·2 beträgt ungefähr 10.



Zu berücksichtigen ist allerdings, dass dafür die Kanten der etwa 11400 Polygonevorsortiert werden müssen. Dieser Aufwand fällt jedoch vor dem Hintergrund mehrererMillionen zuzuordnender Punkte kaum ins Gewicht.

Die zur Beschleunigung der Schnittpunktsuche beschriebenen Techniken wurden zuwesentlichen Teilen aus dem Programm osmconvert [OCQ16] übernommen.

3.2.5.2 Polygonvereinfachung

Bei genauerer Betrachtung der Thematik des vorhergehenden Abschnitts wird deutlich,dass der Rechenaufwand auch dann sinkt, wenn es gelingt, die Anzahl der Polygonkantengenerell zu reduzieren. Vom Grundsatz her fällt eine solche Maßnahme zumindest zumTeil in den Bereich der geografischen Vereinfachungen (siehe Abschnitt 3.2.1.1).

Das heißt, es muss auch in diesem Fall abgeschätzt werden, bis zu welcher Größe derdurch eine Polygon-Vereinfachung entstehende Fehler akzeptiert werden kann. Dazu istzuerst festzulegen, wie eine solche Abweichung gemessen wird.

Bei dem im OpenStreetMap-Umfeld für Polygon-Vereinfachungen eingesetzten Perl-Script „simplify-poly.pl“ [SP16] lässt sich der maximale Fehler durch drei unterschiedlicheParameter vorgeben: maximale Pfadverkürzung, Mindest-Kantenlänge und Reduktionsfak-tor für die Kantenzahl. Bei Verwendung des letzten Parameters wird solange jeweils derPunkt mit dem flachsten Winkel zwischen zwei Kanten entfernt, bis sich die Gesamtzahlder Kanten auf den vorgegebenen Wert reduziert hat.

Einfacher in der Handhabung und realistischer für die Fehlerbestimmung ist es aber,wenn man als Maß für den entstehenden Fehler die Größenänderung der Polygonflächeheranzieht, die jeweils durch einen einzelnen Vereinfachungsschritt verursacht wird (sieheBeispiel in Abbildung 3.8). Denn auch ein sehr flacher Winkel zwischen zwei Polygonkan-ten kann im Fall von besonders langen Kanten beim Entfernen des dazwischen liegendenPunkts zu einer beachtlichen Verschiebung der Grenzlinie führen.

Abbildung 3.8: Polygonvereinfachung per Flächen-Kriterium

Der im Rahmen dieser Arbeit im Programm „osmrelpoly.c“ implementierte Vereinfa-chungsalgorithmus nutzt daher die Flächendifferenz als Kriterium. Über den Parameter



��simplify wird die maximale Größe einer solchen Flächenänderung vorgegeben. DasProgramm prüft Polygonkante für Polygonkante, ob die Flächenänderung bei Weglassendes jeweils dazwischen liegenden Punkts im zulässigen Rahmen bleibt. Zusätzlich wirdbeim Entfernen unmittelbar hintereinander liegender Punkte darauf geachtet, dass auchdie Summe dieser Flächenänderungen nicht über dem vorgegebenen Grenzwert liegt.Damit wird verhindert, dass sich der im Fall von mehreren direkt aufeinanderfolgendenVereinfachungsmaßnahmen entstehende Fehler kumuliert.

Mit Verweis auf den Abschnitt 4.3.6 zum Thema „Verortung von Gemeinden“ musserwähnt werden, dass die hier beschriebene Vereinfachung bereits auf Polygonzugebeneund nicht erst auf Polygonebene durchgeführt wird. Damit werden Überschneidungen undLücken zwischen Gemeindegebieten vermieden.

3.2.5.3 Polygon-Vorauswahl

Wie schon in Abschnitt 3.2.5.1 dargestellt, braucht der Punkt-in-Polygon-Test nicht durch-geführt zu werden, wenn schon im Vorhinein klar ist, dass der betrachtete Punkt gar nichtim Polygon liegen kann. Das ist stets dann der Fall, wenn eindeutig ist, dass er sich fernabder äußeren Polygongrenzen befindet.

Der entwickelte Algorithmus führt deshalb grundsätzlich eine Vorprüfung durch. Dereigentliche Punkt-in-Polygon-Test kommt nur dann zur Anwendung, wenn sich der zuuntersuchende Punkt innerhalb des Umgebungsrechtecks des jeweiligen Grenzpolygonsbefindet. Um diese einfache Vorprüfung gegen Umgebungsrechtecke durchführen zukönnen, wird vorab zu jedem Polygon das Umgebungsrechteck durch Maximum- undMinimumermittlung der Koordinatenwerte all seiner Knoten berechnet.

Auch mit dieser Vereinfachung wären für jeden zu testenden Punkt zumindest dieUmgebungsrechtecke aller ca. 11400 Grenzpolygone zu prüfen. Um das zu vermeiden,wird das geografische Gesamtgebiet mit einem Koordinaten-Gitter überzogen. JederGitterzelle werden all die Grenzpolygone, deren Umgebungsrechteck eine gemeinsameSchnittfläche mit der Zelle besitzt, in Form einer Liste zugeordnet.12

Der Prüf-Algorithmus bestimmt für jeden zu testenden Punkt zuerst die Gitterzelle, inder er liegt. Anschließend werden nur die Grenzpolygone betrachtet, auf die die zu dieserGitterzelle gehörende Liste verweist. Der Rechenaufwand reduziert sich dadurch von ca.11400 auf durchschnittlich 3,5 zu prüfende Polygone je Punkt. Hinzu kommen jeweils zweiDivisionen zur Bestimmung der Gitterzelle.

12Genaueres siehe Struktur „poly__poly_t“ in der Datei „osmassignpoly.c“.



3.2.6 Ausschneiden per Grenzpolygon

Das OpenStreetMap-Projekt stellt weltweite Geodaten bereit. Benötigt wird hier jedochnur ein vergleichsweise kleiner geografischer Ausschnitt, nämlich der Bereich innerhalbder Grenzen von Deutschland. Für das daher erforderliche Zurechtschneiden der erd-umfassenden Rohdaten – des so genannten „Planet file“ – kann man wieder auf dieStrahl-Methode des Punkt-in-Polygon-Tests nach Jordan zurückgreifen. Auch die in denletzten Abschnitten vorgestellten Techniken der Polygonvereinfachung und der Beschleu-nigung der Schnittpunktsuche können genutzt werden.

Verschiedene Anbieter stellen jedoch vorportionierte OSM-Rohdaten tagesaktuell zumDownload zur Verfügung. Einer der bekanntesten ist die Firma Geofabrik [GF16], vonderen Download-Server auch die in diesem Projekt verwendeten Rohdaten stammen.

3.2.7 Finden der nächsten Nachbarn „Nearest Neighbor“

Nicht immer liefert das Zuordnen der passenden Grenzpolygone alle für die Adressbildungnoch fehlenden relevanten Informationen (siehe auch Abschnitt 4.3.5 „Verortung vonStraßen“). Daher ist es in einigen Fällen notwendig, nach gültigen Adressinformationenvon nahe gelegenen geografischen Objekten zu suchen und diese mit zu berücksichtigen.„Nahe gelegen“ bezieht sich in diesem Fall auf wenige hundert Meter und verlangt bei derEntfernungsmessung nach keiner besonderen Genauigkeit.

Deshalb ist es völlig ausreichend, die in Abschnitt 3.2.3 vorgestellte kombinierte Me-thode der Entfernungsberechnung anzuwenden. Dennoch müssten zur Bestimmung derNachbarn eines Punktes jeweils die Entfernungen zu allen etwa 13 Millionen anderenPunkten berechnet werden.

Dieser enorme Aufwand lässt sich vermeiden, wenn man alle Punkte nach ihrer Geo-position sortiert und anschließend die tatsächliche Entfernungsberechnung nur zu denPunkten durchführt, die im Bezug auf ihre Speicherposition in der näheren Umgebungliegen. Dabei ergibt sich die Schwierigkeit, dass Speicher eindimensional organisiert sindund das gleichzeitige Ordnen nach Längen- und Breitengrad nicht möglich ist. Zwar ließensich dafür – wie bei Datenbanksystemen üblich – getrennte Indexe anlegen, das jedochwürde den Suchaufwand deutlich erhöhen.

Der im Teilsystem „Datenaufbereitung“ implementierte Algorithmus kombiniert deshalbdie Werte von Längen- und Breitengrad zu einer gemeinsamen Größe und verwendet dieseals Sortierkriterium. Dazu wird jeweils der 32-Bit-Zahlenwert des Breitengrads um seinegesamte Länge nach links verschoben und zum Zahlenwert des Längengrads addiert.13

Tabelle 3.1 zeigt die auf diese Weise entstehende 64-Bit-Koordinatenkombination, die alsSuchkriterium verwendet werden kann.

13Die Implementierung dazu ist in der Prozedur „data__coco_calc()“ in der Quellcode-Datei „osmgeobase.c“zu finden.



63..46 45..32 31..00001 1010 1110 0101 01 00 0000 0000 0000 0110 1010 1100 0100 0001 0010 0000 0111

45,1231744 179,1234567Breitengrad Längengrad

Tabelle 3.1: für Binärsuche kombinierte Geokoordinaten

Damit eine binäre Suche auch innerhalb der Längengrade zumindest abschnittsweisenoch möglich bleibt, werden die Breitengrade vorher portioniert: der kombinierte Ko-ordinatenwert enthält also nicht den exakten, sondern einen gerundeten Wert für denBreitengrad. Das Runden erfolgt durch Löschen der Bits 0 bis 13 des Breitengradwerts,gleichbedeutend mit den Bits 32 bis 45 des kombinierten Koordinatenwerts. Das entsprichteiner Portionsgröße von 16384 mal 100 Nanograd und somit ca. 182 Meter Entfernung.

Abbildung 3.9: Suchgitter zur Ermittlung der nächsten Nachbarn

Abbildung 3.9 zeigt grob die Arbeitsweise des Suchalgorithmus: Zuerst werden dierelevanten Breitengrad-Portionen ermittelt und anschließend innerhalb von diesen dierelevanten Längengradbereiche bestimmt.14 Dadurch wird es möglich, die Suchvorgängeals Binärsuchen zu implementieren, was im Bezug auf die Rechengeschwindigkeit vonVorteil ist.

Eingesetzt wird dieses Verfahren bei der Ortsnamen-Ermittlung für Straßen. Siehe dazuauch Abschnitt 6.7.4.3.

14Der genaue Ablauf ist in den Prozeduren „data__coco_center()“ und „data__coco_next()“ in der Quellcode-Datei „osmgeobase.c“ beschrieben.



3.3 Programmiertechnische Verfahren

Im Vergleich zu Verbesserungen im Bereich der Algorithmen fallen Effizienz-Steigerungendurch rein programmiertechnische Verfahren in der Regel geringer aus. Trotzdem lohnt essich, diese näher zu betrachten. Die folgenden Abschnitte zeigen deshalb ausgewählteAspekte aus programmiertechnischer Sicht.

3.3.1 Wahl der Programmiersprache

Heute existiert eine große Vielfalt an Programmiersprachen. Einige dieser Sprachensetzen Schwerpunkte bezüglich der jeweils unterstützten Anwendungsgebiete wie Ex-pertensysteme, Maschinensteuerungen oder Datenbanken. Unterscheiden lassen sichProgrammiersprachen auch hinsichtlich ihrer Maschinennähe. So kann man die SpracheAssembler zweifellos als maschinennah bezeichnen, da es sich dabei letztlich nur umeine in leicht merkbare Bezeichner überführte Sprache der Maschine selbst – also eineMaschinensprache – handelt.

Bei der Entscheidung für eine Programmiersprache, die für die gegebene Aufgaben-stellung geeignet ist, spielt die Maschinennähe eine wesentliche Rolle. Je größer dieNähe zur Hardware, desto leichter lässt sich durch die Programmierung Einfluss nehmenauf eine möglichst effiziente Programmausführung. Gleichzeitig erfährt dieser EinflussGrenzen durch die verwendeten Übersetzungsprogramme: je nach den dort aktiviertenOptimierungsfunktionen ändern sich Zusammenstellung und Ausführungsreihenfolge dereinzelnen Anweisungen eines Programms. Zudem greifen die meisten modernen Pro-zessoren durch eigene in Hardware implementierte Optimierer in den Programmablaufein.

Auch wenn Assembler das Kriterium der Maschinennähe besonders gut erfüllt, sprichteiniges gegen die Verwendung dieser Sprache: der Quellcode besitzt keine hierarchischeGliederung und er ist architekturabhängig, das heißt, ein für einen Prozessortyp entwi-ckeltes Programm läuft nicht ohne umfangreiche Anpassungen des Quellcodes auf einemanderen Typ.

Von den verbleibenden populären Sprachen, wie zum Beispiel C, C++, C#, Java oderPython, besitzt C die größte Maschinennähe. Auch bietet diese Sprache eine große Vielfaltmaschinennaher Datentypen und unterscheidet – im Gegensatz etwa zu Java – zwischenvorzeichenbehafteten und vorzeichenlosen Datentypen15.

Aus diesem Grund und auch, weil C für beinahe alle Plattformen verfügbar ist, fiel dieWahl auf diese Sprache.

15Seit Version 8 bietet Java zwar Funktionen an, mit denen vorzeichenbehaftete Variablen hilfsweise in vorzei-chenloser Form verarbeitet werden können, jedoch weiterhin keine entsprechenden Datentypen [Java16].



3.3.2 Modularisierung

Komplexe Programmsysteme lassen sich kaum in ihrer Gesamtheit erfassen, so dass esin der Regel notwendig ist, sie in mehrere Teilsysteme oder noch kleinere Einheiten, sogenannte Software-Module, aufzugliedern. Jedes dieser Module besitzt klar definierteSchnittstellen, über die die Kommunikation mit anderen Modulen, der Hardware oder demAnwender stattfindet.

Die meisten Programmiersprachen bieten eigene Mechanismen an, die eine entspre-chende Modularisierung unterstützen. Bei der Sprache C ist es üblich, den Rumpf einesjeden Moduls in eine eigene Quellcode-Datei zu fassen und die dazu gehörende Schnitt-stellendefinition als eigene Header-Datei zur Verfügung zu stellen. Damit ein modulari-siertes und in viele Dateien zergliedertes Programm übersetzt werden kann, werden dieAbhängigkeiten der Modulhierarchie in einer so genannten Make-Datei festgehalten.

Übersetzer und Binder überwachen neben der Einhaltung der Syntax auch das Modul-geheimnis. Dieses stellt sicher, dass modulinterne Daten nur über die in der jeweiligenHeader-Datei definierten Schnittstellen gelesen oder verändert werden können.

Bedingt durch die bei C nur zur Übersetzungszeit stattfindenden Prüfungen kanndie Einhaltung des Modulgeheimnisses nicht vollumfänglich garantiert werden. Wie beivielen anderen Programmiersprachen auch, bezieht sich diese Schwäche vor allem aufdie Alias-Problematik16. Daher ist neben der klaren Definition der Modulstruktur auchProgrammierdisziplin erforderlich, um die Prinzipien des Modulgeheimnisses nicht zuunterlaufen.

Die im Rahmen dieser Arbeit angepassten oder neu erstellten Quellcodes verzichtenin der Regel auf eine Aufspaltung in unterschiedliche Dateien. Stattdessen werden je-weils mehrere Module in dieselbe Quellcode-Datei aufgenommen. Die Einhaltung desModulgeheimnisses wird durch erweiterte Syntaxvorschriften unterstützt:

• Jedes Modul besitzt einen eindeutigen Namen, der für alle seine Prozeduren undnichtlokalen Variablen als Präfix verwendet wird.

• Alle Objekte (Prozeduren wie Variablen), auf die von außerhalb des Moduls zuge-griffen werden darf, erhalten zusammengesetzte Namen in der FormModulname_Objektname.

• Alle internen Objekte eines Moduls, die Teil des Modulgeheimnisses sind, er-halten ebenfalls zusammengesetzte Namen, jedoch mit doppeltem Unterstrich:Modulname__GeheimerObjektname.

16Sobald einem Client-Modul als Datensatz-Referenz die tatsächliche Speicheradresse übergeben wird, kanndieses Modul in der Regel auch unter Umgehung der Set- und Get-Prozeduren des Server-Moduls auf diegekapselten Daten zugreifen.



• Für lokale Variablen innerhalb von Prozeduren eines Moduls ist es nicht notwendig,dieser Namenskonvention zu folgen, da das Modulgeheimnis in diesem Fall durchden Compiler überwacht wird.

Die erweiterten Vorschriften sollen anhand eines Beispiels für ein Modul mit dem Namen„speicher“ verdeutlicht werden:

int speicher__zahl;

int speicher__doppelt(int x) { return 2*x; }

void speicher_rein(int z) { speicher__zahl= z; }

int speicher_raus2() { return speicher__doppelt(speicher__zahl); }

Nur auf die beiden Prozeduren speicher_rein() und speicher_raus2() darf vonaußerhalb des Moduls zugegriffen werden, sie sind Teil der Schnittstellendefinition des Mo-duls. Sowohl die Variable speicher__zahl als auch die Prozedur speicher__doppelt()

werden als Teil des Modulgeheimnisses betrachtet, da in ihren Bezeichnern nach demModulnamen jeweils ein doppelter Unterstrich folgt.

Auf diese Weise ist es möglich, mehrere Module in einer einzigen Quellcode-Dateiunterzubringen, was den Übersetzungsvorgang erheblich vereinfacht. Sollte sich späterdie Notwendigkeit ergeben, diese Module auf mehrere Dateien zu verteilen, muss dieGesamtdatei an den Modulgrenzen aufgespaltet werden. Zusätzlich sind Header-Dateienanzulegen, die jeweils die Schnittstellendefinition des betreffenden Moduls in Form vonProzedur-Prototypen enthalten. Für das obige Beispiel sieht der Inhalt der Header-Dateidann so aus:

void speicher_rein(int);

int speicher_raus2();

3.3.3 Objektorientierte Programmierung in C

Effiziente Programmausführung und objektorientierte Programmierung stehen nicht sel-ten im Widerspruch zueinander. Das liegt an den besonderen Mechanismen, die fürdie Ausführung objektorientierten Quellcodes verwendet werden. Einerseits ist es fürProgrammierer komfortabel, dass sie sich um den zusätzlich notwendigen Verwaltungs-und Rechenaufwand keine Gedanken zu machen brauchen, andererseits fehlt dadurchder Überblick, welcher der für die Objektorientierung genutzten Mechanismen wie vielzusätzliche Rechenzeit kostet.

Dieses Problem besteht bei Verwendung einer rein prozeduralen Sprache wie C nicht.Trotzdem kann man damit sogar – wenn auch etwas umständlicher – objektorientiertprogrammieren. Über das oben vorgestellte Modulkonzept lassen sich Objekttypen (alsModule) und Methoden (als öffentliche Prozeduren von Modulen) erstellen. Benötigt man



mehrere Instanzen eines Objekttyps, muss für jede Instanz ein eigener modulinternerVariablensatz angelegt werden. Die Prozeduren des Moduls identifizieren die referenzierteInstanz über einen Adresszeiger oder ein Handle und finden so den jeweils zuständigenVariablensatz.

Ähnlich verfahren einfache objektorientierte Sprachen, wie beispielsweise C++ oder C#– mit dem Unterschied, dass der die jeweilige Instanz referenzierende Adresszeiger ohneZutun und Wissen des Programmierers übergeben und verarbeitet wird.

Will man eine Klasse definieren und diese Definition anschließend als Schablonenutzen, um mehrere Module zu erstellen, ist das bei objektorientierten Sprachen einfach,weil dieser Vorgang durch die Sprache selbst unterstützt wird. C hingegen bietet dieseMöglichkeit nicht, man kann sich jedoch anders behelfen: Klassen-Schablonen lassensich in Form von Header-Dateien definieren und für jedes damit zu erstellende Modulin den Quellcode einbinden. Per Präprozessor-Direktive wird der jeweilige das Modulidentifizierende Name als Makro definiert und an die Header-Datei übergeben. Dieseverwendet den Namen als Suffix für die eigenen Identifikatoren.

Ein Quellcode-Beispiel soll veranschaulichen, wie Hauptprogramm und Schablonezusammenwirken. Zuerst das Hauptprogramm:

#include <stdio.h>

// Instanz mit dem Namen "apfel"

#define I apfel

#include "obst.h"

#undef I

// Instanz mit dem Namen "birne"

#define I birne

#include "obst.h"

#undef I

int main(int argc,char** argv) {

speicher_rein_apfel(12);

speicher_rein_birne(34);

printf("Obstsalat: %i\n",

speicher_raus_apfel()+speicher_raus_birne());

return 0;

}

In der Header-Datei "obst.h" befindet sich das Modul speicher als Schablone:

#define TEMPLATEM(f,a) f##_##a

#define T(f,a) TEMPLATEM(f,a)

int T(speicher__zahl,I);



void T(speicher_rein,I)(int z) { T(speicher__zahl,I)= z; }

int T(speicher_raus,I)() { return T(speicher__zahl,I); }

Der Präprozessor von C bietet sogar die Möglichkeit, die Definition der Schablone in dasHauptprogramm zu integrieren, also auf eine eigene Header-Datei zu verzichten. Dabeihilft das vordefinierte Präprozessor-Makro __FILE__, das den Namen der eigenen Dateirepräsentiert.

In eine gemeinsame Quellcode-Datei gepackt, sieht das obige Beispiel folgendermaßenaus:

#ifndef I // from here: main program

#include <stdio.h>

// Instanz mit dem Namen "apfel"

#define I apfel

#include __FILE__

#undef I

// Instanz mit dem Namen "birne"

#define I birne

#include __FILE__

#undef I

int main(int argc,char** argv) {

speicher_rein_apfel(12);

speicher_rein_birne(34);

printf("Obstsalat: %i\n",

speicher_raus_apfel()+speicher_raus_birne());

return 0;

}

#else // from here: procedure templates

#define TEMPLATEM(f,a) f##_##a

#define T(f,a) TEMPLATEM(f,a)

int T(speicher__zahl,I);

void T(speicher_rein,I)(int z) { T(speicher__zahl,I)= z; }

int T(speicher_raus,I)() { return T(speicher__zahl,I); }

#endif

Dabei sorgt das Makro T(f,a) jeweils dafür, dass der Prozedur- bzw. Variablen-Namemit dem Instanz-Namen zu einem gemeinsamen Identifikator kombiniert wird.

Diese Art der Klassen-Instanziierung in C birgt im Vergleich zu objektorientierten Pro-grammiersprachen eine Besonderheit: es wird tatsächlich für jede Instanz ein eigener



Objektcode erzeugt.17 Dadurch kann auf die sonst notwendigen Adresszeiger für die In-stanzvariablen verzichtet werden, was die Effizienz – wenn auch nur in geringem Umfang– erhöht.

Zur Anwendung kommt diese Technik unter anderem im Rahmen der Datenaufberei-tung im Programm „osmgeobase.c“. Dort wird eine Klassenschablone verwendet, umdavon die als Behälter für bestimmte Adress-Datentypen verwendeten Instanzen „region“,„subregion“, „city“, „street“ und „housenumber“ abzuleiten.

3.3.4 Parallelisierung

Nicht nur bei Arbeitsplatzrechnern, sondern auch bei mobilen Geräten wie Tablets oderSmartphones sind heute oft Mehrkernprozessoren im Einsatz. Bei Verwendung parallelerAlgorithmen darf daher erwartet werden, dass die Georeferenzierung in deutlich geringererZeit erfolgt. Gleichzeitig steigt durch die parallele Verarbeitung die Leistungsaufnahme,weil beispielsweise zwei Prozessorkerne für eine Dauer von einer Sekunde an Stelle voneinem Prozessorkern für zwei Sekunden betrieben werden. Hinzu kommt der in Abbildung3.10 blau dargestellte Verwaltungsaufwand, der durch die Aufteilung der Aufgabe aufmehrere Prozesse und das anschließend notwendige Zusammenfassen der Ergebnisseentsteht. Beides hat zusätzlichen Energiebedarf zur Folge.

Abbildung 3.10: Leistungsaufnahme ohne Parallelität und bei zwei parallelen Prozessen

Auch wenn es auf den ersten Blick scheint, dass die Parallelisierung unter Energie-Gesichtspunkten keinen Vorteil bringt, kann es sich lohnen, dieses Thema im Nachganggenauer zu untersuchen. Dazu sind detaillierte Messungen der Leistungsaufnahme erfor-derlich, was im Rahmen dieser Arbeit jedoch nicht geleistet werden kann.

17Vorausgesetzt, dem Compiler wurde als Optimierungsziel nicht die Speicherplatzminimierung vorgegeben,denn dann wäre es wahrscheinlich, dass er die betreffenden Objektcodeabschnitte zusammenlegt.


4 Analyse der relevantenOSM-Datenstrukturen

Das Projekt OpenStreetMap (OSM) wurde im Juli 2004 in London gegründet [OSM16].Vergleichbar etwa zu Wikipedia, ist es Ziel des Projekts, freies Wissen zu sammeln, zuspeichern und jedem zur Verfügung zu stellen. Im Gegensatz zu Wikipedia geht es beiOSM ausschließlich um Geodaten oder zumindest um Daten mit engem geografischenBezug.

4.1 OSM-Datentypen

Die im Rahmen von OSM gesammelten Daten werden in einer zentralen Datenbankgespeichert und stehen dort unter einer freien Lizenz1 zum Download zur Verfügung.Die weltweiten Geodaten besitzen einen Umfang von zurzeit ca. 30 GiB, der AusschnittDeutschland umfasst etwa 2,6 GiB (jeweils gepackt). Zu den weltweiten Daten stehenminütliche Änderungsdateien, so genannte Changefiles bereit, mit denen lokale Datenbe-stände stets aktuell gehalten werden können. Für den Ausschnitt Deutschland existiert einvergleichbares Angebot, jedoch mit nur täglicher Aktualisierung.

Die Struktur der Geodaten kennt genau drei Datentypen, welche bei OSM auch „Ele-mente“ genannt werden: Knoten, Polygonzug und Relation. Die Instanzen dieser Typenwerden im weiteren Verlauf auch als Objekte bezeichnet. Jedes dieser Objekte kann mitAttributen versehen werden.

Alle drei Datentypen werden für geografische Objekte verwendet, die als solche naturge-mäß einen Bezug zu Geopositionen besitzen. Trotzdem enthält nur der Datentyp Knoteneigene Koordinaten, für Objekte der anderen beiden Datentypen wird der Ortsbezugjeweils über Verweise auf Objekte des Typs Knoten hergestellt.

Die Besonderheiten der unterschiedlichen Datentypen werden in den folgenden Ab-schnitten erläutert.

4.1.1 Knoten

Beim Datentyp Knoten, oft englisch als node bezeichnet, handelt es sich um die Repräsen-tation eines geografischen Punkts. Als notwendige Information besitzt ein solches Objekt

1Open Database License (ODbL), freie Lizenz mit Copyleft und Namensnennungsklausel, ähnlich CC BY-SA [OD16]


4 Analyse der relevanten OSM-Datenstrukturen

deshalb Geokoordinaten. Meist wird dieser Datentyp genutzt, um kleine Gegenstände wieBriefkästen, Parkuhren, Verkehrszeichen oder Ähnliches zu speichern. Daneben dienenKnoten als Behälter für die Geopositionen der übergeordneten Datentypen Polygonzugund Relation.

Abbildung 4.1: Datstellungsbeispiel für einen Knoten [OSMMAP16]

Wie schon in Abschnitt 3.2.1.1 erläutert, wird der Ortsbezug über Geokoordinaten inForm von Längen- und Breitengrad hergestellt. Die OSM-Webseite zeigt diese Positionals Markierung in der Karte und informiert gleichzeitig über die zum Knoten gespeichertenAttribute – hier die eines Briefkastens (siehe Abbildung 4.1).

4.1.2 Polygonzüge

Ein Polygonzug, auch Weg oder englisch way genannt, wird verwendet, um eine geo-grafische Linie abzubilden. Zu unterscheiden ist zwischen offenen und geschlossenenPolygonzügen. Offene Polygonzüge stellen beispielsweise Straßen, Stromleitungen oderMauern dar, geschlossene werden für Plätze, Gebäudeumrisse oder Gemeindegrenzenverwendet.

Der Ortsbezug wird ausschließlich über eine Liste referenzierter Knoten hergestellt, dader Datentyp Polygonzug selbst keine Geokoordinaten enthält.2 Offene und geschlosse-ne Polygonzüge können aus Datensicht leicht unterschieden werden: Verweisen ersterund letzter Eintrag der Referenzliste auf denselben Knoten, handelt es sich um einengeschlossenen Polygonzug.

Abbildung 4.2 zeigt als Beispiel für einen Polygonzug die Darstellung einer Hochspan-nungsleitung in der OSM-Hauptkarte. Links sind wieder die zu diesem Objekt gespeicher-ten Attribute zu sehen.3 Unterhalb dieser Attribute wird eine Liste der Identifikatoren allerdurch diesen Polygonzug referenzierten Knoten angezeigt.

2Dieser Nachteil wird regelmäßig innerhalb der OpenStreetMap-Gemeinschaft diskutiert. Bisher konntensich entsprechende Änderungsvorschläge nicht durchsetzen, weil die Vorteile der bestehenden einfachenDatenstruktur stets höher bewertet wurden.

3Die Attribute werden hier in rein alphabetischer Reihenfolge dargestellt. Deswegen befindet sich diewichtigste Information, nämlich, dass es sich um eine Hochspannungsleitung handelt, nicht an ersterStelle: power=line.


4.1 OSM-Datentypen

Abbildung 4.2: Datstellungsbeispiel für einen Polygonzug [OSMMAP16]

4.1.3 Relationen

Der dritte OSM-Objekttyp, die Relation, wurde erst drei Jahre nach Projektgründung,nämlich im Jahr 2007 mit der Verabschiedung der OSM-Protokoll-Version 0.5 geschaf-fen [OSMAPI16].

Relationen verwendet man als hierarchische Klammern, um Beziehungen zwischenKnoten, Polygonzügen und anderen Relationen herzustellen. In der Praxis werden siehäufig eingesetzt, um Informationen aufzunehmen, die nur mittelbar geografischer Art sind.Dazu gehören etwa Linienverläufe von Bussen und Straßenbahnen sowie die logischeVerbindung von Polygonen zu Multipolygonen – das sind zusammengesetzte Polygone,manche davon auch mit Exklaven oder Enklaven.



Abbildung 4.3: Datstellungsbeispiel für eine Relation [OSMMAP16]

Ein Beispiel für ein solches Multipolygon ist in Abbildung 4.3 zu sehen. Die betreffendeRelation verweist auf zwei geschlossene Polygonzüge, denen die Rollen outer und innerzugewiesen wurden. In Kombination repräsentieren diese drei Objekte ein Waldstück mitLichtung.

Abbildung 4.4: Verknüpfungen zwischen OSM-Objekten

Abbildung 4.4 zeigt ein grundsätzliches Beispiel von Verknüpfungen zwischen Knoten,Polygonzügen und Relationen.

4.1.4 Identifikatoren

Jede Instanz der drei OSM-Datentypen besitzt einen eigenen Identifikator. Dabei handeltes sich um eine positive ganze Zahl, die zentral vom OSM-Projekt-Server vergebenwird und innerhalb des jeweiligen Datentyps weltweit eindeutig ist. Externe Kartierungs-Anwendungen vergeben für neue Instanzen negative Zahlen als temporäre Identifikatoren.


4.2 Serialisierung

Bei der Übertragung in die zentrale OSM-Datenbank werden diese durch den Projekt-Server in eindeutige (positive) Identifikatoren umgewandelt.

Da es drei Objekttypen gibt, kommt der gleiche Identifikator bis zu dreimal vor. Dasbedeutet beispielsweise, es gibt einen Knoten 42, einen Polygonzug 42 und eine Relation42. Benötigt man einen typunabhängig eindeutigen Objekt-Identifikator, kann man ihn umdie Datentypinformation ergänzen, indem man ihn als Variable fester Länge speichert undin die höchstwertigen Bits den Datentyp schreibt.4

Anfangs war es üblich, für Identifikatoren 32-Bit-Variablen einzusetzen. Durch dasenorme Datenwachstum im Projekt OSM wurde jedoch bei den Knoten-IdentifikatorenAnfang 2013 der zulässige Wertebereich von vorzeichenbehafteten 32-Bit-Variablen (± ca.2,147 Mrd.) verlassen. In der Folge musste bei vielen Anwendungen der Programmcodeangepasst werden. Heute ist es üblich, nicht nur für Knoten- sondern auch für Polygonzug-und Relations-Identifikatoren 64-Bit-Variablen einzusetzen, um weitere Anpassungsmaß-nahmen zu vermeiden.

Mit Stand März 2016 umfasst der genutzte Wertebereich für Knoten-Identifikatorenden Zahlenraum von 1 bis 4,0 Mrd., für Polygonzug-Identifikatoren bis 0,4 Mrd. und fürRelations-Identifikatoren bis ca. 6 Millionen.

4.1.5 Attribute

Den Instanzen aller drei OSM-Datentypen können Attribute zugeordnet werden. Dabeihandelt es sich um Paare in der Form Schlüssel=Wert. OSM kennt hunderte verschiedenesolche Schlüssel, wie die betreffende Projektseite „Map Features“ zeigt [OSMMF16].

Innerhalb desselben Objekts ist der Name eines Attribut-Schlüssels stets eindeutig.Dadurch lassen sich Attribute nicht mehrfach zuordnen, weswegen hilfsweise auf dieVerwendung von Trennzeichen – wie beispielsweise den Strichpunkt im Fall von Öffnungs-zeitangaben – ausgewichen wird:

opening_hours=Mo-Do 10:00-17:00; Fr 10:00-12:00; Sa 08:00-14:00

Im Rahmen dieser Arbeit interessieren vor allem Attribute wie addr:city oderaddr:street. Genaueres dazu folgt im Rahmen der Analyse der OSM-Adressdatenin Abschnitt 4.3.

4.2 Serialisierung

Übertragen werden Geodaten aus dem Projekt OpenStreetMap üblicherweise in seria-lisierter Form. Auch zum Archivieren wird diese Datenform verwendet. Die folgendenAbschnitte stellen drei der hierzu am häufigsten genutzten Datenformate vor.

4Das Datenkonvertierungsprogramm osmconvert verfährt im Rahmen der Prüfung der Objektreihenfolgenach diesem Prinzip [OCQ16].



4.2.1 Datenformat XML

Bei XML („Extensible Markup Language“) handelt es sich im Grunde um ein Rahmenformat.Dementsprechend existieren für das Speichern von OSM-Geodaten Detailvorschriften.OSM-Datentypen werden zu XML-Elementen, und OSM-Attribute zu XML-Attributen. DerAufbau lässt sich am besten durch ein vereinfachtes Beispiel beschreiben:

<?xml version='1.0' encoding='UTF-8'?>

<osm version="0.6">

<node id="287676" lat="49.5105871" lon="10.4147365"/>

<node id="287677" lat="49.5101217" lon="10.41463">

<tag k="name" v="Erkenbrechtallee"/>

<tag k="highway" v="bus_stop"/>

</node>

<way id="2293021">

<nd ref="287676"/>

<nd ref="287677"/>

<tag k="highway" v="residential"/>

<tag k="surface" v="asphalt"/>

</way>

<relation id="2772">

<member type="node" ref="287676" role=""/>

<member type="way" ref="2293021" role=""/>

<tag k="name" v="Senefelderstraÿe"/>

<tag k="type" v="street"/>

</relation>

</osm>

Man erkennt die klar unterschiedenen Datentypen Knoten, Polygonzug und Relationmit den XML-Element-Bezeichnungen „node“, „way“ und „relation“.

Als einziges der drei vorgestellten Datenformate ist XML mit einem normalen Texteditorlesbar und veränderbar. Nachteilig ist der vergleichsweise hohe Speicherplatzbedarf,weswegen OSM-XML-Dateien in der Regel mit einem universellen Packer – üblicherweisemit bzip2 – komprimiert werden.

4.2.2 Datenformat PBF

Auch PBF („Google Protocol Buffers“) ist lediglich ein Rahmenformat. Es wurde alskompakte Alternative zu XML entwickelt [GPBF16].

Hervorzuheben ist die Möglichkeit, Zahlen längenunabhängig zu speichern. Verwendetwird dazu das Little-Endian-Format, wobei jeweils ein gesetztes Bit 7 darauf hinweist, dassauch das nächste Byte noch zur gleichen Zahl gehört. Dadurch werden – von dem nichtfür andere Zwecke verfügbaren Bit 7 abgesehen – für Zahlen immer nur so viele BytesSpeicherplatz belegt, wie unbedingt benötigt. Die Zahl 16384 (214) beispielsweise wird inForm von drei Bytes gespeichert: 0x80 0x80 0x01 (0 + 0·27 + 1·214).


4.2 Serialisierung

Die für OSM verwendete PBF-Variante nutzt zusätzlich das Packformat gzip und er-reicht so ein sehr gutes Komprimierungsverhältnis. Da die Komprimierung jedoch nichtdateiweit, sondern nur blockweise erfolgt, benötigen Programme, die OSM-PBF-Dateienverarbeiten, eigene Komprimierungs- bzw. Dekomprimierungsfähigkeiten. Daneben er-weist sich die blockweise Komprimierung auch dann als nachteilig, wenn Abschnitte einerDatei im Rahmen der Verarbeitung mehrfach gelesen werden müssen, weil dann derDekomprimierungsvorgang mehrfach erfolgt.

Zwar existiert auch eine Formatvariante ohne blockweise Komprimierung, diese wirdjedoch nicht von allen Programmen unterstützt. Sie wird auch deswegen selten verwendet,weil Dateien in dieser Form deutlich mehr Speicherplatz belegen.

4.2.3 Datenformat o5m

Im Vergleich zu den beiden eben beschriebenen Formaten ist das Datenformat o5mweniger verbreitet. Es ist weder menschenlesbar wie XML noch bietet es eine so hoheKomprimierung wie PBF. Der Vorteil von o5m liegt darin, dass die Daten sehr schnellgelesen und geschrieben werden können. Die durch das Format selbst erreichbareKomprimierung kann als mittelmäßig bis gut bezeichnet werden.

Intern ähnelt das Format dem im letzten Abschnitt vorgestellten PBF. Zahlen werdenauf genau die gleiche Weise gespeichert. Im Gegensatz zu PBF geschieht das Schreibenvon Zeichenketten grundsätzlich paarweise in Form von Schlüssel=Wert. Mehrfach vor-kommende Paare werden ab dem zweiten Mal nur referenziert und führen dadurch auchohne zusätzliche Komprimierung zu einer deutlichen Platzeinsparung.

Besonders wegen der hohen Verarbeitungsgeschwindigkeit wird das Datenformat o5mim Rahmen dieser Arbeit genutzt. Weil die aus dem Projekt OpenStreetMap bezogenenRohdaten allerdings nicht originär in diesem Format verfügbar sind, müssen sie als Erstesvom komprimierten PBF-Format in das o5m-Format umgewandelt werden. Da dafür dieeinzeln komprimierten PBF-Datenblöcke nur einmal gelesen werden müssen, nimmt dieserVorgang insgesamt nicht viel Zeit in Anspruch.

4.2.4 Objekt-Reihenfolge

In allen drei vorgestellten Serialisierungs-Formaten können die einzelnen Objekte (Knoten,Polygonzüge, Relationen) in jeder beliebigen Reihenfolge gespeichert werden. Da diehierarchische Struktur der Daten aber Verweise von Polygonzügen auf Knoten und vonRelationen auf Objekte aller Datentypen vorsieht, ist es von Vorteil, zuerst alle Knoten,als Nächstes alle Polygonzüge und erst dann die Relationen zu lesen. Aus diesem Grundgeschieht auch das Speichern grundsätzlich in dieser Reihenfolge.

Innerhalb eines jeden der Datentypen sind die einzelnen Instanzen nach ihren Identifi-katoren geordnet. Das erleichtert das Vergleichen und das duplikatfreie Zusammenführen



unterschiedlicher OSM-Dateien, weil sie – wie in Abbildung 4.5 gezeigt – rein seriell nachdem Reißverschlussprinzip verarbeitet werden können.

Abbildung 4.5: duplikatfreies serielles Zusammenführen von OSM-Objekten

Für die Datenaufbereitung im Rahmen der Georeferenzierung wird diese Art der Zu-sammenführung am Ende der einzelnen Verarbeitungslinien genutzt. Genaueres dazufolgt in Abschnitt 6.5.

4.3 Adressdaten

Wie schon im Abschnitt 1.3.2 erwähnt, existieren innerhalb von OpenStreetMap mehrereVarianten, wie Adressen erfasst werden können. Dementsprechend vielschichtig mussdaher die Auswertung gestaltet werden.

Aus den Rohdaten zu extrahieren sind neben vollständigen Hausadressen auch diePositionen von Orten5 und Straßen. Die folgenden Abschnitte zeigen die unterschiedlichenAdressformate aus Sicht der Rohdaten.

4.3.1 Diskrete Hausadressen

Am einfachsten für die Auswertung ist es, wenn Adressangaben diskret und vollständigvorliegen. Bei OSM existieren dafür die so genannten Adress-Tags. Das sind für Adressenvorgesehene Objektattribute, deren Schlüssel das Präfix addr: tragen.

addr:city

addr:street

addr:housenumber

Zu erwähnen ist, dass addr:city den Namen der Gemeinde enthält und nicht denNamen eines Stadtteils oder Ortsteils. Für diese existieren die Attribute addr:suburb

und addr:place.5Die Bezeichnung „Ort“ steht im Rahmen dieser Arbeit für den „offiziellen Ortsnamen“ im Sinn des Bestand-

teils einer Adressangabe und nicht für eine geografische Position.


4.3 Adressdaten

Die genannten Attribute können grundsätzlich an Objekten jedes OSM-Datentyps haf-ten: Knoten, Polygonzüge, Relationen. Wie schon im Abschnitt 4.1 dargestellt, werdenGeopositionen nur von Knoten direkt referenziert, im Fall von Polygonzügen und Relatio-nen müssen daher zuerst die jeweils hierarchisch untergeordneten Objekte ausgewertetwerden.

Abbildung 4.6: diskrete Hausadresse [OSMMAP16]

Abbildung 4.6 zeigt das Beispiels eines Polygonzugs, an dem Adressinformationenhaften. Um an die zugehörigen Geokoordinaten zu gelangen, müssen die Daten der durchden Polygonzug referenzierten Knoten ausgewertet werden.

4.3.2 Mehrdeutige Hausadressen

Grundsätzlich handelt es sich bei dem Tripel (Ort, Straße, Hausnummer) um eine eindeuti-ge Adressangabe; dazu gibt es jedoch Ausnahmen: In den beiden Metropolen Berlin undKöln kommen Straßennamen mehrfach vor – jeweils in unterschiedlichen Stadtteilen. Sogibt es in Berlin beispielsweise acht Goethestraßen und sechs Schillerstraßen. Hamburg –obgleich deutlich größer als Köln – kennt eine solche Mehrdeutigkeit nicht.

Nicht zuletzt wegen der Gefahren durch fehlgeleitete Rettungsfahrzeuge sorgen fastalle Gemeinden für eindeutige Adressangaben. Unterstützt wird das durch entsprechendeVerordnungen der Länder.6

Dennoch muss im Rahmen der Georeferenzierung eine Strategie entwickelt werden,mit diesem Problem umzugehen. Eine einfache Lösung kann darin bestehen, Städte wieBerlin und Köln als eine Menge von mehreren Gemeinden zu verstehen.

Ein zweiter, ebenfalls naheliegender Ansatz besteht darin, die Postleitzahl als Selekti-onskriterium mit einzubeziehen. Die Aufteilung in Postleitzahlgebiete erfolgt jedoch seitLangem nicht mehr durch eine Postbehörde, sondern durch ein Wirtschaftsunterneh-

6„Gleiche Straßennamen in unterschiedlichen Ortsteilen sind gemäß § 5 Abs. 3 Satz 2 der ThüringerKommunalordnung unzulässig (...)“ [ABLLW16]



men – die Deutsche Post AG – und fast ausschließlich mit dem Ziel, den Postlauf zuvereinfachen. Daher stimmen die Grenzen dieser Gebiete in vielen Fällen nicht mit denGemeindegrenzen überein. Oft haben Gebiete verschiedener Gemeinden dieselbe Post-leitzahl. Beispielsweise besitzt der Ortsteil Biberau der Gemeinde 98666 Masserberg diePostleitzahl 98667, welche grundsätzlich für das Gebiet der Gemeinde Schleusegrundsteht [PLZ16]. Solche Abweichungen führen in Einzelfällen sogar dazu, dass innerhalbdesselben Postleitzahlgebiets verschiedene Straßen gleichen Namens existieren.

Beim dem später beschriebenen Extrahieren von Gemeindepolygonen wird daher nichtauf Postleitzahlen zurückgegriffen, sondern der weiter oben vorgestellte Lösungsansatzverfolgt: Sonderfall-Gemeinden wie Berlin und Köln werden jeweils als eine Menge vonmehreren Stadtteil-„Gemeinden“ verstanden.7

4.3.3 Unvollständige Hausadressen

Nicht immer sind die Tripel (Ort, Straße, Hausnummer) vollständig. Ein unvollständigesTripel bedeutet allerdings nicht automatisch, dass die betreffende Adressinformationnicht verwendet werden kann. Vielmehr muss differenziert werden, welche Bestandteilevorhanden sind und welche nicht. Tabelle 4.1 zeigt alle sieben möglichen Kombinationen,bei denen mindestens eines der drei Attribute bekannt ist. Diese Kombinationen sollen imFolgenden genauer betrachtet werden.

Ort Straße Hausnummer interpretieren ggf. notwendigeFall bekannt? bekannt? bekannt? als Posit. von VorverarbeitungA nein nein ja nichts Objekt ignorierenB nein ja nein Straße Gemeindepolygon

→ OrtC nein ja ja Haus Gemeindepolygon

→ OrtD ja nein nein OrtE ja nein ja Ort Hausnr. ignorierenF ja ja nein StraßeG ja ja ja Haus

Tabelle 4.1: Fallunterscheidung bei unvollständigen Hausadressen

Es fällt auf, dass das Fehlen des Orts allein keinen Einfluss auf die Verwendbarkeitder Adresse, wohl aber auf die dann notwendige zusätzliche Vorverarbeitung hat. In denFällen B und C muss die Ortsangabe aus dem jeweils umgebenden Gemeindepolygonermittelt werden. Dafür kann die in Abschnitt 3.2.5 vorgestellte Punkt-in-Polygon-Methodeverwendet werden.

Fehlt die Straßenangabe, kann die Adressinformation bestenfalls als Ortsangabe ge-nutzt werden (Fälle D und E). Hausnummern ohne Straßenangabe werden grundsätzlich

7Eine detaillierte Beschreibung dazu folgt in Abschnitt 6.4.


4.3 Adressdaten

ignoriert (Fälle A und E). Bei Straßenangaben ohne Hausnummer kann die Informationzumindest zum Auffinden der Straße verwendet werden (Fälle B und F). Fall A zeigt, dassAdresssätze, die nur eine Hausnummer enthalten, nicht sinnvoll verwendet werden könnenund deshalb ignoriert werden müssen.

4.3.4 Sonderfälle von Hausadressen

Bei Verwendung deutscher Adressen müssen drei Sonderfälle näher betrachtet werden.

Als Erstes existieren viele kleine Ortsteile, in denen die Straßen nicht eigens benanntsind. Als Adresse wird dort an Stelle des Straßennamens der Ortsteilname verwendet.Die Hausnummer ist innerhalb des jeweiligen Ortsteils eindeutig, so dass man als gültigePostanschrift beispielsweise „Vorderpfeinach 7, Uffenheim“ erhält.

Abbildung 4.7: Ortsteilname mit Hausnummer [OSMMAP16]

Konsequenterweise enthalten die Adressangaben bei einigen solcher Ortsteile keinenEintrag für addr:street. Stattdessen wird – wie im Beispiel der Abbildung 4.7 zu sehen– das Attribut addr:place verwendet.

Für die Auswertung der OSM-Adressdaten bedeutet das, dass bei fehlendem Straßen-namen grundsätzlich das Attribut addr:place beachtet werden muss.

Ein zweiter Sonderfall entsteht durch die mehrfache Zuordnung von Hausnummern zuein und demselben Gebäude. Die betreffenden Hausnummern werden bei OSM in derRegel durch Strichpunkte getrennt (siehe Beispiel in Abbildung 4.8).

Abbildung 4.8: mehrfach zugeordnete Hausnummer [OSMMAP16]

Es handelt sich also genau genommen nicht um einen Adressdatensatz, sondern ummehrere, die auf die gleiche geografische Position zu verortet sind.



Die Stadt Mannheim – auch als „Quadratestadt“ bekannt – sorgt für einen drittenSonderfall. Ihre Innenstadt ist in zumeist rechteckige Zellen unterteilt. Diese Zellen sindnach einem eigenen Koordinatensystem nummeriert.

Abbildung 4.9: Hausadresse in einem Mannheimer Quadrat [OSMMAP16]

Hausadressen enthalten an Stelle von Straßennamen die Koordinaten der jeweiligenZelle, beispielsweise „T3“. die Adresse des in Abbildung 4.9 gezeigten Hauses mit derNummer 4 lautet „T3 4, Mannheim“.8 Da die Zellen-Koordinaten in der OSM-Datenbankin manchen Fällen als addr:street und in manchen als addr:place zu finden sind,müssen auch hier beide Attribute ausgewertet werden.

4.3.5 Verortung von Straßen

Straßennamen kommen nicht nur in regulären Adressbezeichnungen vor, sondern auchals Name der Polygonzüge von Straßen-Objekten (siehe Beispiel in Abbildung 4.10).

Abbildung 4.10: Straßenname als OSM-Attribut [OSMMAP16]

Folglich ist zur Verortung von Straßen grundsätzlich neben dem Attribut addr:street

auch das Attribut name auszuwerten. Beinahe keiner der Straßen-Polygonzüge enthälteine Information über den Ortsnamen, so dass dieser hier besonders häufig aus demumgebenden Gemeindepolygon gelesen werden werden muss.

Trotzdem führt diese Vorgehensweise nicht immer zur korrekten Adresse, denn inEinzelfällen weichen die für Adressen maßgeblichen Grenzen von den Gemeindegrenzenab. Als Beispiel soll hier das Gebiet des Gewerbepark Nürnberg-Feucht-Wendelstein(GNF) näher betrachtet werden. Die drei Gemeinden Nürnberg, Feucht und Wendelsteinhaben 1996 einen Zweckverband gegründet und ein Gewerbegebiet auf gemeinsamer

8Daneben existieren die alternativen Schreibweisen „T 3 4, Mannheim“ „T 3, 4, Mannheim“, „T-3 4, Mannheim“und „T-3, 4, Mannheim“.


4.3 Adressdaten

Grundfläche ausgewiesen [GNF16]. Abbildung 4.11 zeigt, dass die Gemeindegrenzenquer durch dieses Gewerbegebiet verlaufen.

Abbildung 4.11: Gemeindegrenzen im Gewerbepark [OSMMAP16]

Um die Anschriften innerhalb des GNF einheitlich zu halten, haben sich die Gemeindendarauf geeinigt, das Gebiet im Bezug auf die Adressen der Stadt Nürnberg zuzuordnen.

Für die Georeferenzierung bedeutet das, dass es nicht ausreichend ist, bei fehlenderAngabe des Ortes nach dem passenden Gemeindepolygon zu suchen. Vielmehr ist fürjede Straße eine Umgebungssuche erforderlich. Dabei ist jeweils zu prüfen, ob eine nahegelegene Hausadresse existiert, die den Namen dieser Straße als Adress-Attribut besitzt.Von dieser Hausadresse kann dann ein gegebenenfalls vorhandenes Orts-Attribut als Ortfür die Straße übernommen werden.

Zur Umgebungssuche eignet sich das in Abschnitt 3.2.7 beschriebene Nearest-Neighbor-Verfahren.

4.3.6 Verortung von Gemeinden

Für die Kennzeichnung von Städten, Großstädten, Dörfern, Weilern, Märkten, Ortsteilen,Stadtteilen usw. existiert bei OpenStreetMap das Attribut place. Für die Adressbestim-mung ist diese Attributierung jedoch nicht geeignet, weil darin keine Aussage darübergetroffen wird, ob der jeweils zugeordnete Name auch als Ortsname für Adressen dient.Unabhängig davon existiert zu einem solchen place-Attribut oft auch kein Bezug zu einementsprechenden Grenzpolygon, das das zu der jeweiligen Gemeinde gehörende geografi-sche Gebiet umschließen würde. Ein solches Gebietspolygon ist jedoch erforderlich, umAdress-Objekte ergänzen zu können, bei denen die Angabe des Ortsnamens fehlt.

Die hier benötigten Gebietspolygone sind im OSM-Datenbestand verfügbar. Sie existie-ren normalerweise als Relationen und nicht direkt als geschlossene Polygonzüge. Grunddafür ist, dass Gemeindegebiete in der Regel aneinandergrenzen und deshalb der jeweilsumschließende Polygonzug in mehrere offene Polygonzüge aufgeteilt werden muss. Dieseoffenen Polygonzüge gehören dann jeweils gleichzeitig zu zwei Gebietsgrenzen. Abbildung4.12 zeigt zur Veranschaulichung die zu den Grenzen der Gemeinde Egloffstein gehören-den Polygonzüge. Der rot dargestellte Polygonzug beispielsweise gehört gleichzeitig zurGrenze der Gemeinde Gräfenberg.



Abbildung 4.12: Gemeindegrenzen als Kombination von Polygonzügen [OSMMAP16]

Für die Adressermittlung gilt es also, genau die Relationen herauszufinden, die Grenzenvon Gemeinden repräsentieren, und anschließend jeweils die referenzierten Polygonzügezu einem Gemeinde-Grenzpolygon zusammenzusetzen.

Relations-Objekte von Grenzen besitzen bei OSM das Attribut type=boundary. Dasses sich um eine Verwaltungsgrenze handelt, wird mit boundary=administrative fest-gelegt. Deutsche Gemeindegrenzen kann man daran erkennen, dass ein achtstelligeramtlicher Gemeindeschlüssel eingetragen wurde. Für die Gemeinde Egloffstein ist diesdas Attribut de:amtlicher_gemeindeschluessel=09474124.

TMC:cid_58:tabcd_1:Class = AreaTMC:cid_58:tabcd_1:LCLversion = 9.00TMC:cid_58:tabcd_1:LocationCode = 4158admin_level = 8boundary = administrativede:amtlicher_gemeindeschluessel = 09474124de:regionalschluessel = 094740124124is_in:continent = Europeis_in:country = Bundesrepublik Deutschlandis_in:county = Forchheimis_in:region = Oberfrankenis_in:state = Bayernname = Egloffsteintype = boundarywikidata = Q503026wikipedia = de:Egloffstein

Tabelle 4.2: Beispiel für Attribute einer Gemeinde-Relation [OSMMAP16]

Von den vielen Informationen, über die eine Gemeinde-Relation in der Regel Auskunftgibt (siehe Beispiel in Tabelle 4.2), werden für die Georeferenzierung nur die Polygonzug-Verweise zur Positionsbestimmung sowie der offizielle Name benötigt.


5 Effiziente Adressdatenstruktur

Bei dem zu realisierenden Georeferenzierungssystem steht – wie mehrfach erwähnt – dasThema Effizienz im Vordergrund. Daher ist es wichtig, dass der Georeferenzierungsal-gorithmus nicht nur entsprechend gestaltet wird, sondern auch auf einer dahingehendoptimierten Datenstruktur aufsetzt. Dieses Kapitel beschäftigt sich mit Aufbau und genau-em Inhalt dieser Datenstruktur.

5.1 Datenumfang

Zunächst ist zu klären, welche Daten für den Such-Algorithmus der Georeferenzierungbenötigt werden.

5.1.1 Adressen

Zu den notwendigen Daten gehören zweifellos die eigentlichen Adressdaten. Im en-geren Sinn handelt es sich dabei um Instanzen der drei Datentypen Ort, Straße undHausnummer. Wie bereits weiter oben dargestellt, muss jeweils auch der Bezug zu demumgebenden Grenzpolygon einer Gemeinde verfügbar sein. Im Fall von Orten, bei denenzur eindeutigen Adressbestimmung die Ortsteil-Namen relevant sind (hier Berlin undKöln), gilt das zusätzlich für das Grenzpolygon des Ortsteils. In Summe führt das zu fünfAdressbestandteilen:

• Gemeinde – aus Datensicht im Folgenden auch als „Region“ bezeichnet

• Ortsteil – aus Datensicht im Folgenden auch als „Subregion“ bezeichnet

• Ort – Name der für die Adresse relevanten Gemeinde

• Straße

• Hausnummer

5.1.2 Geokoordinaten

Im Gegensatz zu den obigen Bestandteilen einer Adresse wird auf die zu ihr gehören-den Geokoordinaten nicht suchend zugegriffen, sie stellen lediglich das Ergebnis derGeoreferenzierung dar. Da das bei OpenStreetMap verwendete Koordinatensystem derMercator-Projektion für viele gegebenenfalls nachgeschaltete Anwendungen wie auchfür die rein numerische Ergebnisanzeige gut geeignet ist, kann auf die Umrechnung in



ein anderes Koordinatensystem verzichtet werden. Sollte sich später ein Anwendungsfallergeben, bei dem das Ergebnis beispielsweise grundsätzlich in Gauß-Krüger-Koordinatenbenötigt wird, empfiehlt es sich, diese Umrechnung schon vorab durchzuführen und diePositionen gleich in dem geforderten Koordinatensystem abzuspeichern.

Neben den oben genannten Adressdaten im engeren Sinn werden also benötigt:

• Längengrad (oder alternativ beispielsweise der Gauß-Krüger-Rechtswert)

• Breitengrad (oder alternativ beispielsweise der Gauß-Krüger-Hochwert)

5.1.3 Zusatzinformationen

Zur Einordnung der Wichtigkeit einer Adresse können zusätzliche Informationen her-angezogen werden. Bei Orten kann dies beispielsweise ihre Einwohnerzahl sein, beiStraßennamen die Anzahl ihrer Erwähnungen im Datenbestand. Im Rahmen der hierimplementierten Georeferenzierung dient die geografische Ausdehnung als Beispiel füreine solche Zusatzinformation. Wie schon in Abschnitt 3.2.2 dargestellt, lassen sich mitHilfe der Ausdehnung DV-gestützte Landkarten passend auf das gesuchte Objekt zoomen.

Verwendet wird hier die logarithmische Repräsentation der Ausdehnung, die im Folgen-den auch als „Gewicht“ des geografischen Objekts bezeichnet wird:

• Gewicht – Logarithmus der Länge der größten Kante des Umgebungsrechtecks

log2 max(West-Ost-Ausdehnung,Süd-Nord-Ausdehnung)

Im Gegensatz zu Polygonzug- und Relations-Objekten besitzen Knoten keine Ausdeh-nung. In solchen Fällen wird der Zahlenwert null als Gewicht angenommen.

5.2 Optimierungsziele für die Adressdatenstruktur

Da auch mobile Geräte als Zielplattform dienen, muss die Gesamtgröße der Adressdatenunter den üblicherweise zur Verfügung stehenden Sekundärspeichergrößen bleiben. Fürdie Verarbeitungsgeschwindigkeit ist es von Vorteil, wenn die Adressdaten darüber hinausnicht größer sind als der Hauptspeicher.

Moderne Prozessoren nutzen für Hauptspeicherzugriffe eigene Zwischenspeicher, sogenannte Caches. Diese nehmen kleine Portionen der Hauptspeicherdaten auf und ermög-lichen sehr schnelle Schreib- und Lesezugriffe auf diese Portionen. Für die zu schaffendeAdressdatenstruktur bedeutet das, dass die Größe der jeweils zu verarbeitenden Da-tenportionen möglichst der Portionsgröße der Prozessor-Caches entsprechen oder einVielfaches davon sein sollte.

Da die Prozessor-Cache-Architektur aber nicht einheitlich ist und oft von Prozessortyp zuProzessortyp wechselt, kann als Sollgröße für die Verarbeitungsportionen der Adressdatennur festgehalten werden, dass sie einer Byte-Zweierpotenz entspricht, denn auch dieGrößen der Prozessor-Caches halten sich – aus praktischen Gründen – an diese Regel.


5.3 Datenarchitektur


Großen Einfluss auf den Aufbau einer Datenstruktur hat die Frage, ob die Daten statischsind oder ob sie jederzeit verändert werden können, also dynamisch sind. Zwar unterliegenAdressdaten grundsätzlich einer sehr großen Dynamik, der hohe Aufwand einer tatsächlichdynamischen Datenhaltung kann jedoch vermieden werden, wenn die Adressdaten nichtlaufend, sondern in festgelegten Zeitabständen aktualisiert und dann komplett als Blockstatischer Daten an den Georeferenzierungsalgorithmus übergeben werden.

Der Aufbau der dazu verwendeten Adressdatenstruktur soll im Folgenden unter ver-schiedenen Gesichtspunkten genauer betrachtet werden.

5.3.1 Dateninhalt

Um eine höhere Effizienz beim Zugriff auf die Daten zu erreichen, werden Inhalt undBeziehungen in unterschiedlichen Behältnissen gespeichert. Als Inhalt werden hier dieZeichenketten verstanden, die beispielsweise Orte, Straßen oder Hausnummern benen-nen. Einmal gespeichert, werden diese Zeichenketten nur noch referenziert, das heißt,es wird jeweils nur noch ihr Identifikator verwendet – das ist die laufende Nummer derSpeicherposition (siehe Beispiel in Tabelle 5.1).

ID Zeichenkette1 Jupiterstadt

2 Marshausen

3 Saturndorf

(a) Domäne „Ort“

ID Zeichenkette1 Abweg

2 Goethestraÿe

3 Querstraÿe

(b) Domäne „Straße“

ID Zeichenkette1 99

2 101

3 107

(c) Domäne „Hausnummer“

Tabelle 5.1: Behälter für Dateninhalt

Innerhalb derselben Domäne (Orte, Straße, Hausnummer usw.) werden Zeichenkettengleichen Inhalts nur einmal gespeichert. Das spart Platz und vereinfacht Vergleiche,weil statt Zeichenketten mit bis zu 40 Byte Länge nur noch Identifikatoren miteinanderverglichen werden müssen.

Um den Aufwand bei der Suche zu reduzieren, werden die Zeichenketten in alphabetischsortierter Folge vorgehalten. Der Zugriff auf eine bestimmte Zeichenkette kann dann jeweilsper Binärsuche erfolgen.

Bezüglich des Zeichenformats fällt die Wahl auf UTF-81. Grund hierfür ist, dass zumeinen die so gespeicherten Daten mit den unter der Programmiersprache C verfügbarenMethoden für nullterminierte Zeichenketten effizient verarbeitet werden können und zumanderen, dass die OSM-Rohdaten ohnehin in diesem Format vorliegen.

1„8-Bit Universal Character Set Transformation Format“, ein weit verbreitetes Byte-orientiertes Zeichenformat



5.3.2 Datenbeziehung

Der Dateninhalt erlangt erst über die ebenfalls gespeicherten Beziehungen seine Bedeu-tung. Diese Beziehungen werden als Tupel von Zeichenketten-Identifikatoren gespeichert.Die Zusatzinformationen Geoposition und Gewicht nehmen dabei eine Sonderstellung ein.Streng genommen handelt es sich bei ihnen um Dateninhalt, trotzdem werden sie direktin das Adress-Tupel mit aufgenommen. Eine solche kompakte Art des Speicherns stelltkeinen Nachteil dar, denn auf diese beiden Kriterien braucht nicht suchend zugegriffen zuwerden.

Das Beispiel in Tabelle 5.2 zeigt – zusammen mit den Tabellen 5.1 (a) bis (c) – wie die bei-den Adressen Goethestraÿe 107, Jupiterstadt und Querstraÿe 107, Saturndorf

gespeichert werden.

ID Ort Straße Hausnummer Geoposition Gewicht1 1 2 3 11,5; 49,5 52 3 3 3 9,0; 51,1 4

Tabelle 5.2: Behälter für Datenbeziehungen

Auch hier ist es von Vorteil, ein Ordnungskriterium festzulegen und die Beziehungstupelgenau in dieser Reihenfolge zu speichern.2 Werden dann zusätzlich auch die im nächstenAbschnitt beschriebenen Rückbeziehungen einer jeden Zeichenkette nach demselbenKriterium sortiert, vereinfacht dies den kombinierten Datenzugriff deutlich. In Abschnitt5.3.5 wird ein solcher kombinierter Suchvorgang genauer beschrieben.

5.3.3 Rückbeziehung

Während Inhalt und Beziehung alle gespeicherten Adressinformationen in vollem Umfangrepräsentieren, lässt sich der Zugriff darauf mit zusätzlichen Verweisen erheblich beschleu-nigen. Dazu gehören die Rückbeziehungen von den Zeichenketten zu den Adress-Tupeln.Damit werden genau die Tupel referenziert, in denen jeweils ein Verweis zu der betreffen-den Zeichenkette enthalten ist. Tabelle 5.3 zeigt die Rückbeziehungen für die Domäne„Hausnummer“ aus obigem Beispiel.

ID Zeichenkette Rückbeziehungen1 99

2 101

3 107 1, 2

Tabelle 5.3: Rückbeziehungen von Dateninhalt zu Datenbeziehung

2Die letztlich verwendeten Ordnungskriterien werden im Zuge der Nachverarbeitung der Adressdaten inAbschnitt 6.7.5 beschrieben.



Die Rückbeziehungen reduzieren den Aufwand für die Suche nach Adressdaten. Sollenbeispielsweise alle Adress-Tupel ermittelt werden, für die als Straßenname „Querstraße“eingetragen ist, braucht nur in den Zeichenketten der Domäne „Straße“ nach diesemNamen gesucht zu werden. Die dort gespeicherten Rückbeziehungen enthalten bereitsgenau die Identifikatoren der gesuchten Adress-Tupel.

5.3.4 Einfacher Datenzugriff

Auch ohne besondere Techniken ist die gleichzeitige Suche nach unterschiedlichen Kriteri-en möglich. So kann etwa nach Ort, Straße und Hausnummer gleichzeitig und auf binäremWeg gesucht werden, wenn die Adressdaten vorher nach genau diesen Kriterien sortiertwurden – das heißt, sortiert nach Ort, bei gleichem Ort nach Straße und bei gleicherStraße nach Hausnummer.

Nur mit großem Aufwand möglich wäre dann aber die kombinierte Suche, beispielsweisenach der „Goethestraße“ in allen Orten, deren Name mit „Neustadt“ beginnt. Dazu müsstenentweder alle passenden Ortsnamen danach ausgewertet werden, ob es dort jeweilseine „Goethestraße“ gibt, oder alle Adress-Tupel, die auf die Zeichenkette „Goethestraße“referenzieren, müssten dahingehend geprüft werden, ob der zugehörige Ortsname mit„Neustadt“ beginnt.

5.3.5 Kombinierter Datenzugriff

Die gleichzeitige Suche nach zwei voneinander unabhängigen Kriterien ist im Allgemeinenkeine einfache Aufgabe, das wurde schon im Rahmen des Themas „Nearest Neighbor“ imBezug auf Geokoordinaten dargestellt (siehe Abschnitt 3.2.7). Für die Adressdaten gelingtdie häufig benötigte gleichzeitige und unabhängige Suche nach Ort und Straße im Falldes obigen Beispiels auf die folgende Weise:

Zuerst wird innerhalb der Mitglieder der alphabetisch sortierten Domäne „Ort“ nach derersten und letzten Zeichenkette gesucht, die mit „Neustadt“ beginnt. Über die Rückbe-ziehungen zu den Adress-Tupeln werden der Identifikator des ersten Adress-Tupels derersten Zeichenkette und der Identifikator des letzten Adress-Tupels der letzten Zeichen-kette ermittelt. Alle auf Grund der Ortsauswahl in Frage kommenden Adress-Tupel liegennun zwischen diesen beiden Identifikatoren.

Als Nächstes erfolgt unter den Mitgliedern der Domäne „Straße“ die Suche nach demNamen „Goethestraße“. Aus den Rückbeziehungen der so gefundenen Zeichenkettewerden all die Verweise selektiert, die innerhalb des durch die beiden vorher ermitteltenAdress-Tupel-Identifikatoren definierten Bereichs liegen. Diese Verweise führen direkt zuden Adress-Tupeln des gesuchten Ergebnisses.

Im Grunde realisiert diese Vorgehensweise einen Datenbank-Join, dessen Ausführungauf die vorliegende Aufgabenstellung hin optimiert wurde.



5.4 Datenstruktur

Die genauere Implementierung der eben beschriebenen Datenarchitektur soll in diesemAbschnitt vorgestellt werden. Noch detailliertere Informationen dazu sind in der Quellcode-Datei „osmposition.c“ zu finden.

5.4.1 Datenstruktur für den Inhalt

Wie oben schon dargestellt, sollten die Rückbeziehungen dem Dateninhalt beigefügt wer-den. Die folgende Struktur, die für die Zugriffsinformationen jeder Zeichenkette verwendetwird, berücksichtigt das:

struct dat__idx_struct {

const char* string;

// pointer to start of string (zero-terminated)

uint32_t* usedp; // pointer to used-by information;

// it starts with the number of references and continues with

// the references themselves

} __attribute__((__packed__));

Wie aus den Kommentaren ersichtlich, verweist die Struktur zum einen auf die Zeichen-kette selbst und zum anderen auf eine Liste mit Rückbeziehungen. Diese Liste beginntstets mit der Anzahl der nachfolgend gespeicherten Rückbeziehungen.

Über die Direktive __attribute__((__packed__)) wird erreicht, dass die Länge derStruktur nicht durch den Optimierer des Compilers verändert wird. Sie beträgt 8 Byteunter einer 32-Bit-Architektur und 16 Byte unter einer 64-Bit-Architektur. Sie entsprichtdamit den in Abschnitt 5.2 aufgestellten Anforderungen hinsichtlich der Eignung für dietemporäre Ablage im Prozessor-Cache.

5.4.2 Datenstruktur für die Beziehungen

Für jedes Adress-Tupel existiert ein eigenes Element der folgenden Datenstruktur:

struct dat__addr_struct { // (length 32 bytes)

int32_t x,y; // geocoordinates (unit 10^-7 degree)

uint32_t region; // index of region string

uint32_t subregion; // index of subregion string

uint32_t city; // index of city string

uint32_t street; // index of street string

uint32_t housenumber; // index of housenumber string

uint16_t housenumeric; // numeric representation of housenumber

int8_t weight; // geographical extend:

// binary logarithm of bounding-box width (meters)

// as provided by 'osmconvert --add-bboxwidthweight';

uint8_t work; // temporary variable, for internal use;



5.5 Adressdaten-Serialisierung

Es fällt auf, dass zusätzlich zu den in Abschnitt 5.3.2 beschriebenen Informationen zweiweitere Datenfelder aufgenommen wurden: Das Feld work wird bei der Datenaufberei-tung für temporäre Zwecke genutzt, das Feld housenumeric enthält die Hausnummer innumerischer Repräsentation. Dieser Zahlenwert wird für Hausnummer-Vergleiche verwen-det, weil hier eine rein alphabetische Sortierung nicht die gewünschten Ergebnisse liefernwürde.3

Die Gesamtlänge der Datenstruktur beträgt 32 Byte. Sie entspricht damit ebenfalls denin Abschnitt 5.2 aufgestellten Anforderungen. Da es sich bei dieser Länge – wie bei derStruktur-Länge im vorherigen Abschnitt auch – um eine 2er-Potenz handelt, gelingt dieUmrechnung von Identifikatoren in Speicheradressen mit sehr geringem Aufwand. Je nachProzessor und Befehlssatz kann dafür statt einer Multiplikation auch die Verschiebeopera-tion verwendet werden.

5.4.3 Identifikatoren

Obwohl Beziehungen zwischen Daten durch die Verwendung von Zeigervariablen effizien-ter implementiert werden könnten, verwenden die beschriebenen Strukturen stets 32 Bitbreite Identifikatoren als Index.

Hauptgrund dafür ist, dass der Platzbedarf je Verweis dann einheitlich 4 Byte beträgt,während Zeiger im Fall von 64-Bit-Prozessoren jeweils 8 Byte Speicherplatz benötigen. Beiden ca. 13 Millionen Adress-Tupeln für Deutschland und 2 mal 5 Zeigern je Adresstupel(jeweils 5 Verweise auf Zeichenketten plus 5 Rückbeziehungen) entspräche das einemSpeicherplatz-Mehrbedarf von über 500 MByte.

Unabhängig davon müssten bei der Verwendung von Zeigern die Speicherpositionenfür die erforderliche Serialisierung der aufbereiteten Adressdaten zuerst in Identifikatorenumgerechnet und später wieder in neue Speicherpositionen zurückverwandelt werden.

Mit einer Bereichsüberschreitung braucht bei 32 Bit breiten Identifikatoren nicht ge-rechnet zu werden, da dem heute genutzten Wertebereich von 0 bis ca. 13 Millionenein technisch maximal verfügbarer Wertebereich von 0 bis ca. 4 Milliarden (C-Datentypuint32_t) gegenübersteht.

Dem Wert null wurde eine besondere Bedeutung zugewiesen. Im Fall von Zeichenketten-Identifikatoren bedeutet null, dass die betreffende Information (z.B. Straßenname, Haus-nummer) nicht bekannt ist. Für Identifikatoren von Adress-Tupeln bedeutet null als Ergeb-nis, dass kein Adress-Tupel bekannt ist, das den vorliegenden Suchvorgaben entspricht.

5.5 Adressdaten-Serialisierung

Wie schon bei den Anforderungen in Abschnitt 1.2 dargestellt, ist daran gedacht, dieAdressdaten zentral aufzubereiten und dann auf dezentrale – vorzugsweise mobile –

3Bei einem rein alphabetischen Vergleich käme beispielsweise die Zahl 100 vor der Zahl 90.



Geräte zu verteilen. Für die Übergabe an diese Geräte müssen die Daten in eine kompakteForm gebracht werden. Das hierfür zu Grunde gelegte Datenformat wird im Folgendenbeschrieben.

Der generelle Aufbau dieser so genannten .ogb-Dateien ist in Tabelle 5.4 zu sehen, erbesteht aus insgesamt 17 einzelnen Abschnitten.

Abschnitts- Dateiabschnittidentifikator

0xe0 Dateiformat0x40 Adressdaten0x51 Region-Statistik0x61 Region-Zeichenketten0x71 Region-Rückbeziehungen0x52 Subregion-Statistik0x62 Subregion-Zeichenketten0x72 Subregion-Rückbeziehungen0x53 Ort-Statistik0x63 Ort-Zeichenketten0x73 Ort-Rückbeziehungen0x54 Straßen-Statistik0x64 Straßen-Zeichenketten0x74 Straßen-Rückbeziehungen0x55 Hausnummer-Statistik0x65 Hausnummer-Zeichenketten0x75 Hausnummer-Rückbeziehungen

Tabelle 5.4: Aufbau einer .ogb-Datei

Jeder dieser Abschnitte wird durch einen Abschnittsidentifikator eingeleitet. Anschlie-ßend folgt jeweils die Länge des Abschnitts. Dadurch können lesende Programme, diedie Daten bestimmter Abschnitte nicht interpretieren können oder nicht benötigen, solcheAbschnitte einfach überspringen.

Der Dateiformat-Abschnitt gibt Auskunft über die Art der Datei. Anhand der Zeichenketteosmgeobase0000 kann das lesende Programm erkennen, dass es sich um die in diesemKapitel beschriebenen „aufbereiteten Adressdaten“ handelt.

Im Adressdaten-Abschnitt sind alle Adress-Tupel gespeichert. Das Innere entsprichtder in Abschnitt 5.4.2 vorgestellten Datenstruktur.

Die nächsten drei Dateiabschnitte existieren fünffach, und zwar jeweils für die Da-tentypen Region, Subregion, Ort, Straße und Hausnummer. Statistik-Abschnitte gebenAuskunft über die Anzahl der Zeichenketten, ihre Länge in Summe, die Gesamtzahlder Rückbeziehungen und Ähnliches. Zeichenketten-Abschnitte enthalten die Inhalte derZeichenketten und Rückbeziehungs-Abschnitte die Referenzen auf die Adress-Tupel, indenen die Zeichenketten verwendet werden.


5.6 Komprimieren der serialisierten Adressdaten

Die genaue Beschreibung des Serialisierungsformats ist jeweils als Quellcode-Kom-mentar bei den Prozeduren abgelegt, die solche Dateien schreiben oder lesen; das sinddie Prozeduren „data_write()“ und „dat_ini()“ in den Quellcode-Dateien „osmgeobase.c“und „osmposition.c“.

5.6 Komprimieren der serialisierten Adressdaten

Zum Zweck der Datenübertragung und auch für die Archivierung ist es vorteilhaft, wenndie serialisierten Adressdaten in komprimierter Form vorliegen. Hierzu gilt sinngemäß dasGleiche wie bei der Serialisierung der Rohdaten (siehe Abschnitt 4.2).

Eine inhaltliche Komprimierung kann auf Adress-Tupel-Ebene beispielsweise durchVerwendung des Protobuf-Zahlenformats erfolgen, welches auch für die bereits vorge-stellten Datenformate .pbf und .o5m genutzt wird. Nachteilig ist, dass in diesem Falldie PBF-Dekomprimierungsprozeduren auch auf dem Zielgerät implementiert werdenmüssten.

Bei den Zeichenketten lässt sich die Tatsache ausnutzen, dass diese in alphabetischerReihenfolge vorliegen. Wie in Tabelle 5.5 beispielhaft für Straßennamen gezeigt, brauchtimmer nur die Änderung gegenüber der jeweils vorhergehenden Zeichenkette gespeichertzu werden.

Zeichenkette gleiche Zeichen Rest-ZeichenketteAach 0 Aach

Aachener Ende 4 ener Ende

Aachener Glacis 9 Glacis

Aachener Gracht 10 racht

Aachener Landstraÿe 9 Landstraÿe

Aachener Pfad 9 Pfad

Aachener Straÿe 9 Straÿe

Aachener Weg 9 Weg

Aachener-Straÿe 8 -Straÿe

Tabelle 5.5: komprimieren durch Änderungsfortschreibung

Übersetzt man zusätzlich die häufig vorkommenden Endungen wie „Straße“, „Weg“ usw.in eine wenige Bits breite Kurzform, lässt sich noch einmal Speicherplatz einsparen (sieheTabelle 5.6).

Ein Versuch mit allen deutschen Adress-Zeichenketten des OSM-Datenbestands zeigt,dass sich ihre Gesamtlänge durch die vorgestellten Maßnahmen von 6,2 MByte auf2,8 MByte verringert.4 Trotzdem ist fraglich, ob sich der Aufwand der Komprimierung lohnt,

4Die zur statistischen Auswertung verwendete Prozedur „dat__statistics()“ befindet sich in der Quellcode-Datei „osmposition.c“.



Zeichenkette gleiche Zeichen Rest-Zeichenkette EndungAach 0 Aach

Aachener Ende 4 ener Ende

Aachener Glacis 9 Glacis

Aachener Gracht 10 racht

Aachener Landstraÿe 9 Land sAachener Pfad 9 Pfad

Aachener Straÿe 9 SAachener Weg 9 WAachener-Straÿe 8 - S

Tabelle 5.6: komprimieren durch Änderungsfortschreibung und Endungsabkürzung

denn die Zeichenketten machen nur einen sehr kleinen Teil der mehrere hundert MByteumfassenden Adressdaten aus.

Da außerdem die serialisierten Adressdaten nur selten geschrieben oder gelesenwerden, erscheint es sinnvoller, in diesem Fall Standard-Komprimierungsprogramme ein-zusetzen. Deswegen wurde auf die Implementierung der oben vorgeschlagenen Strategienverzichtet.


6 Datenaufbereitung

Die schrittweise Umwandlung der OpenStreetMap-Rohdaten bis hin zu der im vorausge-henden Kapitel beschriebenen Datenstruktur erfolgt zum Teil parallel in mehreren Verarbei-tungslinien. Im Folgenden wird der prinzipielle Ablauf eines jeden dieser Schritte erläutert.Weitere Details können den jeweils referenzierten Quellcode-Dateien entnommen werden.

6.1 Formatumwandlung der Rohdaten

Wie schon im Abschnitt 4.2 zu den Serialisierungsformaten der OSM-Rohdaten erläutert,nutzt das Teilsystem Datenaufbereitung das Format o5m. Die gängigen Quellen fürRohdaten bieten jedoch nur die Datenformate XML und PBF an, wovon PBF das effizienterkomprimierte ist.

Heruntergeladen werden die Rohdaten deshalb im Format PBF.1 Die Umwandlung indas benötigte Format o5m erfolgt im gleichen Zug per nachgeschaltetem Prozess.

wget http://download.geofabrik.de/europe/germany-latest.osm.pbf -O -

| osmconvert - --drop-version -o=rawgermany.o5m

Das für viele Betriebssysteme verfügbare HTTP-Programm wget sorgt für das Herunter-laden, das nachgeschaltete Konvertierungsprogramm osmconvert [OCQ16] übernimmtdie Formatumwandlung. Durch die Angabe --drop-version werden nicht benötigteVerwaltungsinformationen entfernt – das sind Versionsnummern und Angaben zu denAutoren eines jeden OSM-Objekts.

Aus den heruntergeladenen Rohdaten bedienen sich drei Verarbeitungslinien (sieheAbbildung 6.1). Diese werden in den nächsten Abschnitten vorgestellt und sind dort als„Verarbeitungslinie 1“ bis „Verarbeitungslinie 3“ gekennzeichnet.

1Genutzt wird hierzu das Web-Angebot der Firma Geofabrik. Siehe dazu auch Abschnitt 3.2.6.


6 Datenaufbereitung

OSM-Rohdaten

Straßendaten extrahieren– Verarbeitungslinie 2 –

Hausadressen extrahieren– Verarbeitungslinie 1 –

Gemeindepolygone extrahieren– Verarbeitungslinie 3 –

Abbildung 6.1: Start der Verarbeitungslinien der Datenaufbereitung

6.2 Hausadressen extrahieren – Verarbeitungslinie 1

Geografische Objekte, die die in Abschnitt 4.3.1 vorgestellten diskreten Hausadressenenthalten, können direkt aus den Rohdaten gefiltert werden. Diese Arbeit übernimmt dasProgramm osmfilter [OFQ16]:

FA="addr:city addr:street addr:place addr:housenumber"

TA="all addr:city addr:street addr:place addr:housenumber"

osmfilter raw.o5m --keep="$FA" --keep-tags="$TA" -o=adra.o5m

Über die Variablen FA und TA werden die Filterkriterien für Objekte und Attribute fest-gelegt. Die Details zu den verwendeten Schaltern können der Programmdokumentationentnommen werden.2

Das Ergebnis besteht aus Geodaten unterschiedlicher OSM-Datentypen: Knoten, Poly-gonzüge und Relationen. Da Polygonzüge und Relationen keine eigenen Positionsinfor-mationen enthalten, müssen die benötigten Koordinaten aus der Menge der jeweils direktoder indirekt untergeordneten Knoten ermittelt werden. Die Grundlagen hierzu wurden inden Abschnitten 3.2.4 und 4.1 erläutert.

Übernommen wird diese Aufgabe von der Funktion --all-to-nodes des Programmsosmconvert. Alle Objekte der Datentypen Polygonzug und Relation werden damit inKnoten-Objekte mit Ortsbezug umgewandelt. Die jeweils zugeordneten Adress-Attributebleiben dabei erhalten:

osmconvert adra.o5m --all-to-nodes --add-bboxwidthweight-tags

--max-objects=80000000 -o=adrn.o5m

Über den Schalter --max-objects= wird zusätzlicher Hauptspeicherplatz reserviert,der auf Grund der großen Rohdatenmenge benötigt wird.

Der Schalter --add-bboxwidthweight-tags sorgt dafür, dass für jedes Objekt, daseine Ausdehnung besitzt, die Kantenlänge des zugehörigen Umgebungsrechtecks be-rechnet und als Attribut hinzugefügt wird. Diese Zusatzinformation wird für die spätere

2Programmdokumentation zu osmfilter: wiki.openstreetmap.org/wiki/osmfilter


6.2 Hausadressen extrahieren – Verarbeitungslinie 1

Bewertung der Objekte benötigt (siehe auch Abschnitte 3.2.2 und 5.1.3). Da eine solcheFunktionalität im Programm osmconvert ursprünglich nicht vorhanden war, wurde sie imRahmen dieser Arbeit nachgerüstet.

Anschließend muss noch einmal gefiltert werden, um die Objekte zu entfernen, dieselbst nicht zu den Adressdaten zählen, sondern nur durch Polygonzüge und Relationenreferenziert wurden, welche ihrerseits Adress-Attribute enthalten.

osmfilter adrn.o5m --keep="$FA" --keep-tags="$TA"" bBoxWidthWeight"

--ignore-dependencies -o=adr1.o5m

Das Programm osmfilter berücksichtigt normalerweise die Abhängigkeiten zwischen denOSM-Objekten. Erfüllt beispielsweise ein Polygonzug das Filterkriterium, werden auch dievon diesem Polygonzug aus referenzierten Knoten mit in die Ausgabedatei geschrieben.Bei rein serieller Verarbeitung muss dazu die Eingabedatei mehrfach gelesen werden, dadort standardkonform zuerst die Knoten und erst danach die Polygonzüge gespeichertsind.

Beim zuletzt beschriebenen Filtern der Adressdaten brauchen die eben erwähntenObjekt-Abhängigkeiten nicht berücksichtigt zu werden, weil die zu filternde Datei nur nochObjekte des Typs Knoten enthält und zwischen diesen keine durch OSM-Datentypendefinierten Beziehungen existieren können (siehe Abschnitt 4.1 zu den OSM-Datentypen).

Mit dem Schalter --ignore-dependencies wird das Programm darüber informiert,dass es keine Rücksicht auf Abhängigkeiten zwischen Objekten zu nehmen braucht. Dasbeschleunigt die programminterne Verarbeitung, weil in diesem Fall die Eingabedatei nureinmal gelesen wird.

Die Ergebnisdatei enthält die Knotenrepräsentationen aller Objekte aller Datentypen, dieAdress-Attribute wie addr:city, addr:street, addr:place oder addr:housenumber

besitzen.

OSM-Rohdaten

Hausadressen extrahieren

– Verarbeitungslinie 1 –

FilternUmwandelnin Knoten

Nach-filtern

Abbildung 6.2: Verarbeitungslinie 1 der Datenaufbereitung

Abbildung 6.2 fasst die drei Schritte dieser Verarbeitungslinie zusammen. Die im nächs-ten Abschnitt beschriebene zweite Verarbeitungslinie geht nach dem gleichen Schemavor.


6 Datenaufbereitung

6.3 Straßendaten extrahieren – Verarbeitungslinie 2

Parallel zu den Hausadressen werden in einer eigenen Verarbeitungslinie die Straßendatenextrahiert. Dabei ist unerheblich, ob dieser Vorgang tatsächlich zeitlich parallel ausgeführtwird. Die strukturelle Aufteilung in mehrere Verarbeitungslinien soll hier nur verdeutlichen,dass die Aufgaben nicht abhängig voneinander sind und daher auch zeitlich parallelabgewickelt werden können.

Ähnlich dem Extrahieren der Hausadressen werden auch hier zuerst die Rohdatengefiltert:

FS="( highway=primary =secondary =tertiary =unclassified =residential

=service =living_street =pedestrian =track =road =footway =path

=construction =proposed ) and name"

TS="all addr:city addr:street addr:place name"

osmfilter raw.o5m --keep="$FS" --keep-tags="$TS"" highway"

-o=stra.o5m

Anschließend erfolgen ebenfalls wieder die Umwandlung von Polygonzügen und Rela-tionen in Knoten sowie das finale Entfernen der dadurch nicht mehr benötigten Objekte:

osmconvert stra.o5m --all-to-nodes --add-bboxwidthweight-tags

--object-type-offset=100000000000000 --max-objects=50000000

-o=strn.o5m

osmfilter strn.o5m --keep="$FS" --keep-tags="$TS"" bBoxWidthWeight"


Das Ergebnis dieser Verarbeitungslinie enthält alle Objekte, die Straßen repräsentieren,deren Name bekannt ist, das heißt, das Attribut „name“ muss vorhanden sein.

OSM-Rohdaten

Straßendaten extrahieren


FilternUmwandelnin Knoten

Nach-filtern


Der prinzipielle Ablauf ist in Abbildung 6.3 dargestellt, er gleicht dem der Verarbeitungder Hausadressen in Verarbeitungslinie 1.

6.4 Gemeindepolygone extrahieren – Verarbeitungslinie 3

Auch die dritte Verarbeitungslinie startet mit dem Filtern der Rohdaten. Wie in Abschnitt4.3.6 erläutert, dient das Attribut de:amtlicher_gemeindeschluessel als Erkennungs-zeichen für Relations-Objekte mit Gemeindegrenzen. Daneben müssen die Sonderfälle


6.4 Gemeindepolygone extrahieren – Verarbeitungslinie 3

der mehrdeutigen Hausadressen in Berlin und Köln berücksichtigt werden (siehe auchAbschnitt 4.3.2). Aus diesem Grund sind die als Variablen übergebenen Filterkriterienbesonders umfangreich:

FG="( de:amtlicher_gemeindeschluessel>=1000000 or (

name:prefix=Ortsteil and admin_level=10 and wikipedia=de:Berlin-*

) or ( admin_level=9 and wikipedia=de:Köln-* and (

name=Innenstadt name=Rodenkirchen name=Lindenthal name=Ehrenfeld

name=Nippes name=Chorweiler name=Porz name=Kalk name=Mülheim

) ) ) and boundary=administrative and admin_level and name"

TG="all de:amtlicher_gemeindeschluessel boundary name:prefix name

admin_level wikipedia"

osmfilter raw.o5m --keep= --keep-relations="$FG" --keep-tags="all _"

--keep-relation-tags="$TG" -o=agsa.o5m

In der Ergebnisdatei befinden sich danach die gesuchten Gemeinde-Relationen – ein-schließlich aller jeweils untergeordneten Polygonzug- und Knoten-Objekte. Das ebenfallsim Rahmen dieser Arbeit erstellte Programm osmrelpoly extrahiert die Grenzpolygoneund schreibt sie im Grenzpolygon-Format3 in eine eigene Datei.

osmrelpoly agsa.o5m --simplify=10

--add-admin-levels=";;;admin_level=" -o=adr.poly

osmrelpoly geht dabei schrittweise vor:

Schritt 1: Für jedes Knoten-Objekt werden Identifikator und Position gespeichert.

Schritt 2: Für jedes Polygonzug-Objekt werden der eigene Identifikator und diePositionen aller referenzierten Knoten gespeichert. Dazu wird auf die inSchritt 1 gespeicherten Koordinaten zurückgegriffen. Die Reihenfolgeder Referenzen bleibt dabei auch für die nun gespeicherten Positionenerhalten. Um offene und geschlossene Polygonzüge unterscheiden zukönnen, werden jeweils zusätzlich die Identifikatoren von erstem undletztem referenzierten Knoten gespeichert.

Schritt 3: Für jedes Relations-Objekt wird ein Grenzpolygon geschrieben. Re-ferenzierte Polygonzug-Objekte werden dabei in Abhängigkeit derIdentifikatoren des jeweils ersten und letzten Knotens verarbeitet:

a) Sind die Identifikatoren von erstem und letztem Knoten gleich, han-delt es sich um einen geschlossenen Polygonzug, der als unabhän-giges Polygon betrachtet wird und deshalb einen eigenen Polygon-Abschnitt in der Ausgabedatei erhält.

b) Sind die Identifikatoren von erstem und letztem Knoten verschieden,bildet das Programm aus allen geografisch anschließenden offenen

3Es handelt sich um ein bei OSM weit verbreitetes Format für Grenzpolygone; eine genaue Beschreibung istim OSM-Wiki zu finden: wiki.openstreetmap.org/wiki/.poly


6 Datenaufbereitung

Polygonzügen eine Kette und schreibt diese in die Ausgabedatei.Voraussetzung ist, dass die beteiligten Polygonzüge die gleicheRolle besitzen (inner bzw. outer, siehe Abschnitt 4.1.3) und dassdie so entstehende Kette ein geschlossenes Polygon darstellt.

Die aktivierte Programmfunktion --simplify=10 bewirkt, dass die einzelnen Polygon-züge vor dem Verarbeiten im Sinn einer Punktreduktion vereinfacht werden. Das hierzuverwendete Verfahren wurde im Abschnitt 3.2.5.2 beschrieben. Weitere Details zu diesemProgramm können dem Hilfetext sowie der Quellcode-Datei „osmrelpoly.c“ entnommenwerden.

Neben dem Generieren der Grenzpolygone werden deren repräsentierenden Koordina-ten bestimmt. Diese Aufgabe übernimmt auch hier das Programm osmconvert :

osmconvert agsa.o5m --all-to-nodes --add-bboxwidthweight-tags

--object-type-offset=300000000000000 --max-objects=25000000

-o=agsn.o5m

Schließlich werden – analog zu den Verarbeitungslinien 1 und 2 – alle nicht mehrbenötigten untergeordneten Objekte entfernt:

osmfilter agsn.o5m --keep="$FG" --keep-tags="$TG"" bBoxWidthWeight"


Die Verarbeitungslinie 3 liefert also zwei Ergebnisse: zum einen die Polygon-Datei mitallen Gemeindepolygonen, zum anderen eine Menge von Knoten-Objekten, die die reprä-sentierenden Koordinaten der Gemeindepolygone enthalten. Die einzelnen Arbeitsschrittedieser Verarbeitungslinie sind in Abbildung 6.4 dargestellt.

OSM-Rohdaten

Gemeindepolygone extrahieren


Filtern nachGemeinde-schlüssel

Umwandelnin Knoten

Nach-filtern

Umwandelnin Polygone

Gemeinde-polygone


6.5 Zusammenführen der Adressdaten

Nach dem Arbeitsende der drei Verarbeitungslinien werden deren Ergebnisdateien, dienun alle adressrelevanten Objekte enthalten, zu einer Datei zusammengeführt (sieheAbbildung 6.5).


6.6 Zuordnen der Gemeindepolygone

Straßendaten extrahieren– Verarbeitungslinie 2 –

Hausadressen extrahieren– Verarbeitungslinie 1 –

Gemeindepolygone extrahieren– Verarbeitungslinie 3 –

Zusammenführender Adressdaten

Abbildung 6.5: Ende der Verarbeitungslinien der Datenaufbereitung

Diese Aufgabe übernimmt wieder das Programm osmconvert :

osmconvert adr1.o5m adr2.o5m adr3.o5m -o=adr.o5m

Wie bereits in Abschnitt 4.2.4 beschrieben, macht sich das Programm dabei die Tatsachezunutze, dass die OSM-Objekte der Eingangsdateien in sortierter Folge vorliegen.

6.6 Zuordnen der Gemeindepolygone

Für jedes OSM-Knotenobjekt muss ermittelt werden, innerhalb welchen Gemeindepo-lygons es sich befindet. In manchen Fällen können das auch zwei Gemeindepolygonesein: Für Berlin und Köln existieren jeweils ein Polygon für die Gesamtstadt und mehrerePolygone für die einzelnen Stadtteile.

Zusammenführender Adressdaten

Zuordnen derGemeindepolygone

Gemeinde-polygone

Abbildung 6.6: Zuordnen der Gemeindepolygone

Das im Rahmen dieser Arbeit entwickelte Programm osmassignpoly prüft jedes Kno-tenobjekt der zusammengeführten Adressdaten und ergänzt es um ein Attribut mit demNamen des umgebenden Polygons. Handelt es sich um mehrere umgebende Polygone,wird das mit dem kleinsten Wert des zum Polygon gehörenden Attributs „admin_level“ alsdas äußere betrachtet und das mit dem größten Wert als das innere.4

4Das Attribut „admin_level“ spiegelt die administrative Hierarchieebene des jeweiligen Grenzpolygons wider.Eine genaue Beschreibung ist hier zu finden: wiki.openstreetmap.org/wiki/Tag:boundary_administrative


6 Datenaufbereitung

osmassignpoly adr.o5m -B=adr.poly -b=5.86,47.27,15.05,55.06

--use-admin-levels=";;;admin_level=" --region-key=region

--subregion-key=subregion --keep-boundary-nodes --export-strings

-o=adrr.o5m

Das neue hinzugefügte Attribut mit dem Namen der Gemeinde lautet „region“; etwaigePolygone für Stadtteile – das sind die so bezeichneten „inneren“ Polygone – werden unterdem Attribut „subregion“ gespeichert.

Der Schalter --export-strings weist das Programm an, alle in Adressen verwende-ten Zeichenketten nach Datentyp getrennt in einzelne Dateien zu schreiben. Diese Dateienwerden im nachfolgenden Verarbeitungsschritt verwendet; sie erleichtern die Initialisierungdes im nächsten Abschnitt beschriebenen Programms osmgeobase.

Detail-Informationen zu dem für das Zuordnen der Gemeindepolygone verwendetenAlgorithmus können dem Abschnitt 3.2.5 sowie der Quellcode-Datei „osmassignpoly.c“entnommen werden.

6.7 Komplettieren der Adressdaten

Das im Folgenden beschriebene Komplettieren der Adressdaten wird durch das neuerstellte Programm osmgeobase erledigt. Es liest zunächst sieben Eingabedateien. An-schließend folgt eine Reihe von Verarbeitungsschritten, die sich – wie in Abbildung 6.7gezeigt – in die Stufen Vorverarbeitung, Verarbeitung und Nachverarbeitung gliedern lässt.

Komplettieren der Adressdaten

Verar-beitung

Vorverar-beitung

Nachver-arbeitung

ZuordnenGemeinde-polygone


Abbildung 6.7: Komplettieren der Adressdaten

Am Ende werden die komplettierten Adressdaten in dem in Abschnitt 5.5 vorgestelltenSerialisierungsformat in eine .ogb-Datei geschrieben.

6.7.1 Einlesen von Zeichenketten und Adress-Tupeln

Alle in den Adressdaten verwendeten Zeichenketten werden in Form einzelner Dateienerwartet. Für jeden Attributtyp muss eine eigene solche Datei existieren: „strings_region“,„strings_subregion“, „strings_city“, „strings_street“, „strings_housenumber“.

Genau diese Zeichenkettendateien wurden bereits durch das Programm osmassignpolyerstellt.5 Ihr Inhalt ist allerdings nicht sortiert und enthält Zeichenketten-Duplikate. Daher

5Verantwortlich dafür ist der Programmschalter --export-strings, siehe auch Abschnitt 6.6



müssen diese Dateien zuerst sortiert und entsprechend bereinigt werden. Das geschiehtmit dem Betriebssystem-Kommando „sort“:

export LC_ALL=C ; sort -zu osmstrings_region >strings_region

export LC_ALL=C ; sort -zu osmstrings_subregion >strings_subregion

export LC_ALL=C ; sort -zu osmstrings_city >strings_city

export LC_ALL=C ; sort -zu osmstrings_street >strings_street

export LC_ALL=C ; sort -zu osmstrings_housenumber >strings_housenumber

Die Umgebungsvariable LC_ALL wählt als Sortierreihenfolge die interne binäre Codie-rung, die auch den später erfolgenden Vergleichen per C-Funktion strcmp() zu Grunde liegt.Der Schalter -z bestimmt das Null-Byte als Trennzeichen zwischen den Zeichenketten,und -u weist das Kommando sort an, alle Duplikate zu entfernen.6

Die fünf so erzeugten Zeichenketten-Dateien werden jeweils zweimal gelesen. Beimersten Durchlauf wird lediglich die Anzahl der enthaltenen Zeichenketten ermittelt. Siedient der Reservierung einer genau passenden Menge an Hauptspeicherplatz. Der zweiteDurchlauf überträgt die Zeichenketten dann in den reservierten Hauptspeicherbereich.7

Die Haupt-Eingabedatei mit den Adressdaten in Form von OSM-Knoten liegt im .o5m-Format vor. Damit vor dem Einlesen dieser mehr als 300 MByte großen Datei die passendeMenge an Hauptspeicherplatz für Adressdaten, Rückbeziehungen und kombinierte Koordi-naten8 reserviert werden kann, gibt die siebte Eingabedatei, die Datei „strings_nodecount“,Auskunft über die Anzahl der Knoten.9

Koordinate bzw. Attribut Bedeutung DatenfeldLängengrad,Breitengrad Geokoordinaten x,yregion umgebendes Gemeindepolygon regionsubregion ggf. umgebendes Stadtteilpolygon subregionaddr:city Gemeindename cityaddr:street Straßenname streetaddr:place Ortsteilname bei manchen Dörfernaddr:housenumber Hausnummer housenumbername Straßenname bei Straßen-Objektenboundary Kennzeichnung von Grenz-ObjektenbBoxWidthWeight Gewicht des Objekts weight

Tabelle 6.1: beim Komplettieren zu verarbeitende Attribute

Von den Koordinaten und Attributen der eingelesenen OSM-Knoten werden lediglichdie in der Tabelle 6.1 grün hinterlegten in die im letzten Kapitel beschriebene „effizienteAdressdatenstruktur“ überführt. Die Informationen der übrigen, hier grau hinterlegten

6In der effizienten Adressdatenstruktur darf jede Zeichenkette nur einmal vorkommen (siehe Abschnitt 5.3.1).7Zu den Details siehe Prozedur „data_ini_I()“ in der Quellcode-Datei „osmgeobase.c“.8Die kombinierten Geokoordinaten werden zur Ermittlung der nächsten Nachbarn verwendet (siehe Abschnitt

3.2.7).9Zur Implementierung siehe Prozedur „data_ini()“ in der Quellcode-Datei „osmgeobase.c“.


6 Datenaufbereitung

Daten helfen beim Komplettieren. Die rechte Tabellenspalte gibt Auskunft über die Namender zugeordneten Datenfelder in der Adressdaten-Struktur. Der genauere Aufbau dieserStruktur wurde in Abschnitt 5.4.2 beschrieben.

6.7.2 Dynamische Datenstruktur

Während in die in Abschnitt 5.4.2 erläuterte Datenstruktur für die Adress-Tupel direktgeschrieben werden kann, müssen die Datenstrukturen für die Rückbeziehungen derZeichenketten dynamisch gefüllt werden. Das bedeutet, die Anzahl der Rückbeziehungenje Zeichenkette muss Schritt für Schritt wachsen können. Für diesen Zweck wurde eineentsprechend geeignete Datenstruktur geschaffen.

Zur Beschleunigung der Zugriffe befinden sich Zeichenketten und Rückbeziehungen inderselben Struktur:

// container for strings and their used-by references

#define data__strstringM 40

#define data__strusedM 5

struct data__str_struct {

char string[data__strstringM]; // string (including terminator);

// if maximum string length, the terminator is omitted;

uint32_t usedn; // number of backreferences for this string

union {

uint32_t used[data__strusedM];

// backreferences for this string;

// these backreferences are stored as 32-bit indexes;

// unused backreferences need not to be zeroed:

// array elements are valid in dependence of 'usedn';

// if there are more than 'data__strusedM' backreferences,

// they are entered as external references (see below);

struct { uint32_t filler; data__strref_t* usedref,*usedlast; };

// if there are more than 'data__strusedM' backreferences,

// these two pointers refer to elements of data__strref;

// .usedref: first element in chain;

// .usedlast: last element of the chain;

// (this substructure should not exceed 20 bytes in length

// to keep the container length at 64 bytes;

};


Um die Größe dieser Datenstruktur einheitlich zu gestalten und damit eine einfacheUmrechnung zwischen Identifikator und Speicheradresse zu ermöglichen, war es not-wendig, für die Zeichenketten eine maximale Länge festzulegen. Um diese Länge zubestimmen, wurden – wie hier beispielhaft für die Straßennamen dargestellt – alle verwen-deten Zeichenketten in eine Liste geschrieben und diese anschließend nach Zeilenlängensortiert:

osmconvert raw.o5m --csv="addr:street" | sort -u |

awk '{ print length(), $0 | "sort -n" }' | less



Als längste Zeichenkette unter den in OSM verfügbaren deutschen Adressdaten fandsich der Straßenname „Carl-Friedrich-Wilhelm-Borgward-Straße“. Er umfasst 38 Zeichenund belegt wegen der 2 Byte langen UTF-8-Codierung für das scharfe S insgesamt 39 Byte.Somit ist der in der Struktur vorgesehene maximale Speicherplatz von 40 Byte ausreichend.Selbst wenn es in Zukunft eine noch längere Zeichenkette in den Adressdaten gebensollte, hätte das keinen wesentlichen Einfluss auf die Funktionsfähigkeit des Programms.Es besteht dann nur die Einschränkung, dass ausschließlich die ersten 40 Byte für dieErkennung der Zeichenkette verwendet werden können.

Die verbleibenden 24 Byte der Struktur bieten Platz für die Anzahl der gespeichertenRückbeziehungen und für bis zu fünf der zugehörigen Adress-Identifikatoren. Diesemaximal fünf Rückbeziehungen reichen für die überwiegende Zahl aller Zeichenkettenaus. In den Fällen, in denen dieses Maximum überschritten wird, werden die betreffendenAdress-Identifikatoren in eine gesonderte Struktur ausgelagert:

// container for externally stored used-by references

#define data__strrefusedM 64

struct data__strref_struct {

uint32_t used[data__strrefusedM];

// indexes for used-references;

struct data__strref_struct* next;

};

Reicht der dann vorhandene Platz von 64 Rückbeziehungen nicht, werden mehrereInstanzen dieser Struktur miteinander verkettet. Für das Hinzufügen von Rückbeziehungen– einschließlich der eben beschriebenen Datenstruktur-Verwaltung – wird die Prozedur„data__addused()“ verwendet.

6.7.3 Vorverarbeitung der Adressdaten

Unmittelbar nach dem Einlesen der Adressdaten erfolgen ein einfacher Plausibilitätstestund eine primitive Adressdaten-Komplettierung.

Im Rahmen der Plausibilitätsprüfung werden Adress-Tupel, die keinen Straßennamenenthalten, jedoch Ortsangabe und Hausnummer besitzen, aussortiert und ignoriert.10

Grund dafür ist, dass der Straßenname bei Hausadressen als Pflichtparameter gilt undsie ohne diesen für die weitere Verarbeitung als Hausadresse wertlos sind.

Zur primitiven Komplettierung gehören drei Vorgänge: Zuerst wird bei allen Adress-Tupeln, bei denen das Attribut addr:place, existiert, aber das Attribut addr:street

fehlt, der Wert von addr:place auch als Wert von addr:street übernommen. Dasheißt, bei kleinen Ortsteilen ohne eigene Straßenbezeichnungen tritt der jeweilige Ortsteil-name an die Stelle des Straßennamens.

Als Zweites werden alle Adress-Tupel daraufhin untersucht, ob das Attribut boundary

mit dem Wert administrative vorliegt, ob es sich also um die Knoten-Repräsentation10Zur Berücksichtigung unvollständiger Hausadressen siehe auch Tabelle 4.1 in Abschnitt 4.3.3.


6 Datenaufbereitung

eines Grenzpolygons handelt. In diesen Fällen wird das Gewicht um 64 erhöht. Dadurchwird erreicht, dass die Adress-Tupel, die Gemeinden als Ganzes repräsentieren, nachdem späteren Sortieren der Adressdaten stets an erster Stelle der jeweiligen Ortsdatenstehen.

Und schließlich separiert die Vorverarbeitung die in Abschnitt 4.3.4 beschriebenenkombinierten Hausnummern, so dass am Ende für jede Hausnummer ein eigenes Adress-Tupel existiert.

Details zur Implementierung können dem Quellcode der Prozedur „oo_main()“ in derDatei „osmgeobase.c“ entnommen werden.

6.7.4 Verarbeitung der Adressdaten

Der Hauptteil der Adressdatenkomplettierung umfasst vier Aufgaben: Verarbeitung vonGemeindedaten, Ortsnamen-Ermittlung für Hausadressen, Ortsnamen-Ermittlung fürStraßen sowie die Ortsnamen-Korrektur.

6.7.4.1 Verarbeitung von Gemeindedaten

Die Adress-Tupel, die Gemeinden repräsentieren, sind dadurch gekennzeichnet, dass beiihnen als einziges Adress-Attribut das Attribut region (und ggf. das Attribut subregion )existiert. In diesen Fällen wird der Name der Gemeinde in das Datenfeld city kopiert.Dadurch brauchen später nur drei Suchkriterien behandelt zu werden: Ort, Straße undHausnummer.

6.7.4.2 Ortsnamen-Ermittlung für Hausadressen

Für alle Hausadressen, die keine Information über den Ort besitzen, wird das Attributregion als Ortsname übernommen. Dass es sich jeweils um eine Hausadresse und nichtum eine Straße handelt, wird daran erkannt, dass das Attribut housenumber existiert.

6.7.4.3 Ortsnamen-Ermittlung für Straßen

Bei Straßen gestaltet sich das Ermitteln des passenden Ortsnamens wegen des inAbschnitt 4.3.5 beschriebenen Zuordnungsproblems deutlich aufwändiger als bei denHausadressen.

Wie bereits erläutert, muss die Umgebung nach Hausadressen mit gleichnamigenStraßen abgesucht werden. Aus der Menge der gefundenen Hausadressen wird dienächstgelegene ausgewählt, die einen Ortsnamen besitzt. Dieser Ortsname wird fürdie betreffende Straße übernommen. Als Suchradius wurde 750 Meter festgelegt.11 Ein

11Zur programmiertechnischen Umsetzung siehe Aufruf der Prozedur „data__coco_center()“ in der Quellcode-Datei „osmgeobase.c“. Das Verfahren selbst wurde in Abschnitt 3.2.7 beschrieben.



größerer Radius würde das Risiko erhöhen, dass eine zufällig gleichnamige Straße einerfremden Gemeinde ausgewählt wird.

Findet das Programm innerhalb des Suchradius keine nach diesen Kriterien passendeHausadresse, übernimmt es das Attribut region als Ortsname.

6.7.4.4 Ortsnamen-Korrektur

Im letzten Schritt der Adressdaten-Verarbeitung werden falsch geschriebene Ortsnamenkorrigiert. Dadurch, dass nicht alle innerhalb des Projekts OpenStreetMap freiwillig Mitwir-kenden das gleiche Wissen um die Adressdaten-Standards besitzen, kommt es vielfach zunicht korrekt oder nicht vollständig eingetragenen Ortsnamen. Beispielsweise findet manhäufig „Neustadt“ statt „Neustadt an der Weinstraße“ oder „Rothenburg“ statt „Rothenburgob der Tauber“.

Deshalb werden die mit Ortsnamen erfassten Adressen dahingehend geprüft, ob derOrtsname dem ersten Teil des Namens der Region entspricht. Falls ja, wird der vollständigeName der Region als Ortsname übernommen.

Falls nein, wird geprüft, ob der eingetragene Ortsname dem Namen irgendeiner Regionentspricht. Wenn nicht, betrachtet das Programm den Ortsnamen als unplausibel undersetzt ihn durch den Namen der zum jeweiligen Adress-Tupels gehörenden Region.

Für die Sonderfälle wie Köln oder Berlin wird geprüft, ob der Name der Subregionmit dem Namen des Orts beginnt. Falls ja, wird der Name der Subregion als Ortsnameübernommen. Dadurch gelingt die in Abschnitt 4.3.2 beschriebene Untergliederung dieserStädte in mehrere virtuelle Gemeinden.

Weitere Details zur Adressdaten-Verarbeitung können dem Quellcode der Prozedur„data_addrcomplete()“ in der Datei „osmgeobase.c“ entnommen werden.

6.7.5 Nachverarbeitung der Adressdaten

Um bei der späteren Georeferenzierung das binäre Suchen zu ermöglichen, müssen dieAdressdaten sortiert werden. Dazu wird die Bibliotheksfunktion „qsort()“12 verwendet. Überdie in der Callback-Funktion „data__addr_qsort()“ (siehe Quellcode-Datei „osmgeobase.c“)implementierten Vergleiche wird die insgesamt sechs Kriterien umfassende und in Tabelle6.2 gezeigte Sortierreihenfolge festgelegt.

Beim zweiten Sortierkriterium werden Werte, die kleiner sind als 64, als null interpretiert.Dieses Kriterium wurde eingefügt, um zu erreichen, dass das erste Adress-Tupel einesjeden Orts das zugehörige Gemeindepolygon repräsentiert.

Im nächsten Schritt werden alle Duplikate unter den Adress-Tupeln entfernt. Da dieAdressen zu diesem Zeitpunkt bereits sortiert vorliegen, können sich Duplikate nur in

12Der Name „qsort()“ stammt von dem für diese Funktion anfangs ausschließlich verwendeten AlgorithmusQuicksort, einem sehr schnellen, nicht-stabilen Sortierverfahren.


6 Datenaufbereitung

Kriterium Sortierfolge Sortierrichtungcity alphabetisch aufsteigendweight>=64 numerisch absteigendstreet alphabetisch aufsteigendhousenumeric numerisch aufsteigendhousenumber alphabetisch aufsteigendweight numerisch absteigend

Tabelle 6.2: Sortierreihenfolge für Adress-Tupel

benachbarten Tupeln befinden. Deshalb ist nur ein einziger Durchlauf zum Entfernennotwendig.

Danach wird für jede in den Adress-Tupeln vorkommende Zeichenketten-Referenz dieentsprechende Rückbeziehung in der Datenstruktur der Zeichenkette hinzugefügt.

Anschließend werden ungenutzte Zeichenketten entfernt. Diese sind leicht daran zuerkennen, dass für sie keine Rückbeziehungen existieren.

Bei jeder der verbleibenden Zeichenketten werden die zugehörigen Rückbeziehungensortiert. Sortierkriterium hierzu ist die Nummer des referenzierten Adress-Tupels, alsoder jeweilige Adressidentifikator. Das ermöglicht die spätere Binärsuche sowie einfachereVergleiche innerhalb der Rückbeziehungen.

Genaueres zur Nachverarbeitung kann ebenfalls dem Quellcode der Prozedur „da-ta_addrcomplete()“ in der Datei „osmgeobase.c“ entnommen werden.

6.7.6 Schreiben der Adressdaten

Die aufbereiteten Adressdaten werden in dem in Abschnitt 5.5 vorgestellten Serialisie-rungsformat in eine so genannte OSM-Geobase-Datei geschrieben. Details hierzu sind imQuellcode der Prozeduren „data_write()“ und „data__write_I()“ in der Datei „osmgeobase.c“zu finden. Die Datenaufbereitung ist damit abgeschlossen.


7 Georeferenzierungsalgorithmus

Auf den im Zuge der Datenaufbereitung zusammengestellten „aufbereiteten Adressdaten“setzt das eigentliche Georeferenzierungsprogramm auf. Wie im Abschnitt 1.2.3 zu den An-forderungen skizziert, ist eine Textschnittstelle vorgesehen, die sowohl direkt per Tastaturund Bildschirm als auch durch andere Programme genutzt werden kann.

In den folgenden Abschnitten wird diese Textschnittstelle einschließlich der Implemen-tierung der intern verwendeten Suchalgorithmen genauer beschrieben. Weitere Detailsdazu können dem Quellcode der Prozedur „geoc_main()“ in der Datei „osmposition.c“entnommen werden.

7.1 Syntax der Eingabe

Erwartet wird die zu verortende Adresse in der üblichen Schreibweise „Straße, Hausnum-mer, Komma, Ort“. Sonderfälle wie bei der Quadratestadt Mannheim (siehe Abschnitt4.3.4) werden vom Programm erkannt und entsprechend behandelt. Auch unvollständigeAdresseingaben können zu einem verwertbaren Suchergebnis führen. Dabei sind die inTabelle 7.1 aufgeführten Fälle zu unterscheiden.

Ort Straße Hausnummer erfolgende Ausgabeangegeben angegeben angegeben

Fall 1 ja nein nein Position der GemeindeFall 2 ja ja nein Position der StraßeFall 3 ja ja ja Position des Hauses

Tabelle 7.1: zu unterscheidende Fälle der Adresseingabe

Adresseingaben dieser drei erlaubten Kombinationen können zum Beispiel so aussehen:

Fall 1: Nürnberg

Fall 2: Bahnhofstraÿe, Nürnberg

Fall 3: Bahnhofstraÿe 5, Nürnberg

L2 11, Mannheim

L 2, 11-13, Mannheim

Ein Stern am Ende eines der Suchbegriffe Ort oder Straße dient als Platzhalter. Mit derEingabe Nür* findet man beispielsweise alle Orte, deren Name mit „Nür“ beginnt. Groß-und Kleinbuchstaben werden unterschieden.



7.2 Syntax der Ausgabe

Nach erfolgreicher Verortung einer Adresse werden Längen- und Breitengrad zurückgege-ben. Da in manchen Fällen mehrere passende Ergebnissen existieren – insbesondre beider unscharfen Suche mit Platzhaltern – enthält die Ausgabe grundsätzlich auch die zuden jeweiligen Positionen gespeicherte Adressen. Die Syntax soll im Folgenden anhandvon Beispielen dargestellt werden. Dabei stellt jeweils die erste Zeile die Eingabe dar, diefolgenden Zeilen zeigen die Ausgabe.

Beispiel 1: Nürnberg

1 Nürnberg [11.1356641,49.4360936,15,Nürnberg]

Beispiel 2: Bahnhofstraÿe, Nürnberg

1 Bahnhofstraÿe, Nürnberg [11.0873148,49.4472729,8,Nürnberg]

Beispiel 3: Bahnhofstraÿe 5, Nürnberg

1 Bahnhofstraÿe 5, Nürnberg [11.0832702,49.4476398,0,Nürnberg]

Beispiel 4: Nür*

1 Nürnberg [11.1356641,49.4360936,15,Nürnberg]

2 Nürtingen [9.3484518,48.6164660,14,Nürtingen]

3 Nürburg [6.9448912,50.3395024,12,Nürburg]

Innerhalb eckiger Klammern werden Längengrad, Breitengrad, Gewicht und der Namedes zugehörigen Gemeindepolygons ausgegeben. Im Fall mehrerer passender Ergebnisseist die Liste nach Gewicht sortiert, so dass die Ergebnisse mit dem größten Gewicht ganzoben angezeigt werden.

Führt eine Suche zu keinem Ergebnis, gibt das Programm den Text No result for

city xyz bzw. No result for street xyz zurück.Passt die Eingabe auf zu viele Adressen – beispielsweise die Suche nach N* – erhält

man als Ausgabe Too many results for city N*: 499.

7.3 Interaktives Verhalten

Aus den jeweils zuletzt angezeigten Suchergebnissen kann per Zahleneingabe eine Zeileausgewählt werden. Sofern eine Internetverbindung besteht und auf dem verwendetenRechner ein Internetbrowser verfügbar ist, wird dieser durch das Georeferenzierungs-programm per Betriebssystemaufruf gestartet. Geokoordinaten und Ausdehnung desgewählten Suchergebnisses werden als Parameter übergeben, so dass sich ein Land-kartenausschnitt an der gewünschten Position und mit passender Vergrößerungsstufeöffnet.

Das Kommando für den Browser-Start ist voreingestellt auf:

firefox http://www.openstreetmap.org/?mlat=<Breitengrad>

&mlon=<Längengrad>#map=<Zoom>/<Breitengrad>/<Längengrad>


7.4 Software-Architektur

Wie zu erkennen ist, werden die Geokoordinaten zweifach übergeben. Das rechteKoordinatenpaar dient dem Positionieren der Karte, das linke dem Setzen einer Markierungan die referenzierte Stelle.


In den nachfolgenden Abschnitten wird der in Abbildung 7.1 grob dargestellte interneAblauf des Georeferenzierungsprogramms näher beschrieben.

Eingabe Parsen Suche nachOrt

Ergebnissortieren

Ausgabe

Suche nachOrt und Straße

Suche nachHausnummer


Abbildung 7.1: Datenfluss innerhalb des Georeferenzierungsprogramms

7.4.1 Einlesen der aufbereiteten Adressdaten

Vor dem Start des eigentlichen Georeferenzierungsalgorithmus werden die aufbereitetenAdressdaten eingelesen. Dazu müssen sie von dem in Abschnitt 5.5 beschriebenenSerialisierungsformat in die in Abschnitt 5.4 ausführlicher behandelten Zielstrukturenübertragen werden.

Diese Aufgabe wird von der Prozedur „dat_ini()“ übernommen, welche ihrerseits diedatentypspezifischen Instanzen der Prozedur „dat_ini_I()“ benutzt. Der wesentliche Ablaufist eher trivial, er besteht aus dem Reservieren von Speicherplatz und dem schrittweisenUmkopieren von Daten. Näheres kann dem Quellcode der genannten Prozeduren in derDatei „osmposition.c“ entnommen werden.

7.4.2 Parsen der Eingabe

Der Parser des Programms zerlegt die Adresseingabe in ihre Bestandteile Ort, Straßeund Hausnummer. Dabei werden alle in Abschnitt 7.1 beschriebenen Formen der Eingabeberücksichtigt. Etwaige zusätzliche Angaben zwischen einem doppeltem Schrägstrich unddem Ortsnamen werden entfernt.1 Gleiches gilt für eine etwaig angegebene Postleitzahl.

1Gemäß den Vorgaben zu automationsfähigen Anschriften sind Stockwerk, Wohnungsnummer und Ähnliches„durch doppelten Schrägstrich getrennt hinter der Hausnummer anzugeben.“ [DP16]



Nach dem Parsen stehen Ortsname, Straßenname und Hausnummer als Zeiger aufnullterminierte Zeichenketten zur Verfügung. Zur möglichen Kennzeichnung fehlenderKomponenten dienen Nullzeiger. Die Prozedur „geoc_main()“ in der Quellcode-Datei„osmposition.c“ enthält die Implementierung dieses Parsers.

7.4.3 Suche nach Ort

Enthält die eingegebene Adresse einen Ortsnamen, aber keine Angabe zur Straße, reichtder in Abschnitt 5.3.4 vorgestellte „einfache Dateizugriff“, um das zugehörige oder diezugehörigen Adress-Tupel zu finden.

Zunächst werden die alphabetisch erste und die alphabetisch letzte zum Ortsnamen pas-sende Zeichenkette ermittelt. Das übernimmt die Prozedur „dat_indexrange_city()“. Fallseine Zeichenkette existiert, die genau zum Ortsnamen passt, sind die zurückgegebenenIdentifikatoren für erste und letzte Zeichenkette identisch.

Die relevanten Adress-Tupel werden durch die jeweils erste Rückbeziehung der ge-fundenen Zeichenketten referenziert.2 Die entsprechenden Adress-Tupel-Identifikatorenwerden in die Ergebnisliste eingetragen.

7.4.4 Suche nach Ort und Straße

Die gleichzeitige und unabhängige Suche nach Ort und Straße ist nur mit größeremAufwand leistbar. Das wurde in Abschnitt 5.3.5 zum kombinierten Datenzugriff genauererläutert.

Analog zur alleinigen Suche nach dem Ort werden auch hier zuerst die alphabetischerste und die alphabetisch letzte zum Ortsnamen passende Zeichenkette ermittelt. DerBereich der aus Sicht des Ortsnamens relevanten Adress-Tupel liegt zwischen der erstenRückbeziehung der ersten und der letzten Rückbeziehung der letzten dieser Zeichenket-ten.

Auch für den eingegebenen Straßennamen werden die alphabetisch erste und diealphabetisch letzte passende Zeichenkette bestimmt.

Für jede der in diesem Bereich liegenden Zeichenketten der Straßennamen wird dieMenge der Rückbeziehungen selektiert, die auf ein Adress-Tupel verweist, dessen Iden-tifikator innerhalb des bereits über den eingegebenen Ortsnamen ermittelten Bereichsliegt. Für jeden Ort wird der erste der so selektierten Adress-Tupel-Identifikatoren derErgebnisliste hinzugefügt.

Dieser Ablauf soll am Beispiel der Adress-Eingabe Bahnhofstraÿe, Landau verdeut-licht werden.

Tabelle 7.2 zeigt eine vereinfachte Darstellung der Inhalts-Domänen „Ort“ und „Straße“,sowie der Beziehungs-Domäne „Adress-Tupel“ einschließlich der verbindenden Verweise.

2Wie schon in Abschnitt 6.7.5 bei der Nachverarbeitung der Adressdaten gezeigt, stellt die Sortierfolgesicher, dass die jeweils erste Rückbeziehung den Verweis auf den betreffenden Ort als Ganzes erhält.



ID Zeichenkette Rückbeziehungen50 Landau an der Isar 799, 800, 801, 802, ..., 86751 Landau in der Pfalz 868, 869, 870, 871, ..., 90952 München 910, 911, 912, 913, ..., 940

(a) Domäne „Ort“

ID Zeichenkette Rückbeziehungen1 Amselweg 420, 869, 9102 Bahnhofstraÿe 110, 800, 870, 9903 Poststraÿe 220, 871

(b) Domäne „Straße“

ID Ort Straße ... Position Gewicht800 50 2 ... 12.6942787, 48.6822556 10... ... ... ... ... ... ...

870 51 2 ... 8.0770110, 49.2072481 8(c) Adress-Tupel

Tabelle 7.2: Beispiel einer Suche nach Ort und Straße

Die Suche nach dem Ort Landau ermittelt als erste und letzte Zeichenketten-Identifika-toren 50 und 51 und damit als erste Rückbeziehung den Adress-Tupel-Identifikator 799und als letzte Rückbeziehung den Adress-Tupel-Identifikator 909.

Für die Bahnhofstraÿe liefert die Suche den Zeichenketten-Identifikator 2. Durchdie Prozedur „dat_usedafter_street()“ wird das erste Vorkommen der Rückbeziehungbestimmt, das auf ein Adress-Tupel mit einem Identifikator von mindestens 799 verweist.Gefunden wird die Rückbeziehung zum Adress-Tupel 800. Dieses Adress-Tupel wird indie Ergebnisliste aufgenommen.

Die Suche in den Straßen-Rückbeziehungen wird fortgesetzt mit der ersten Rück-beziehung der nächsten Orts-Zeichenkette, in diesem Fall also mit 868. Sie führt zumAdress-Tupel-Identifikator 870. Auch dieses Adresstupel wird in die Ergebnisliste aufge-nommen. Die nächste Suche beginnt wieder mit der ersten Rückbeziehung der folgendenOrts-Zeichenkette, in diesem Fall dann mit 910. Dadurch wird der eingangs bezüglich desOrts festgelegte Wertebereich (799 bis 909) verlassen, die Suche ist abgeschlossen.

Für den Fall, dass nicht nach einem konkreten Straßennamen, sondern nach einemNamensbereich gesucht wird, setzt sich die Suche jeweils mit der nächsten passendenZeichenkette aus der Domäne „Straße“ fort.

7.4.5 Berücksichtigung der Hausnummer

Bei der eben beschriebenen Suche nach Ort und Straße blieb die Hausnummer stetsunberücksichtigt. Gefunden wurde also nicht das Adress-Tupel einer Hausadresse, son-



dern immer nur das der Straße. Im vereinfachten Beispiel der Tabelle 7.3 ist das das gelbeingefärbte Tupel mit dem Identifikator 800.

ID Zeichenkette Rückbeziehungen70 1 450, 600, 801, 87171 3 452, 802, 94072 3a 803, 93373 3b 804

(a) Domäne „Hausnummer“

ID Ort Straße Hausnummer (ID) Hausnr. numerisch800 50 2 0 0801 50 2 70 1802 50 2 71 3803 50 2 72 3804 50 2 73 3

(b) Adress-Tupel

Tabelle 7.3: Beispiel einer Suche nach der Hausnummer

Für die hausnummernscharfe Suche – beispielsweise nach der hier grün hinterlegtenNummer 3a – müssen nun die nachfolgenden Adress-Tupel untersucht werden. Dazu wirdeine mehrstufige numerische Schritt-Suche durchgeführt:

Das Programm prüft jeweils, ob das Adress-Tupel mit einem um 10 höheren Identifikatorimmer noch zur gleichen Straße gehört und eine Hausnummer besitzt, die kleiner odergleich der gesuchten ist. Falls ja, werden jeweils der neue Identifikator übernommen unddie Prüfung von diesem Adress-Tupel aus wiederholt.

Daran schließt eine eine Nahfeld-Suche nach dem gleichen Prinzip an. Der Ablauf istbis auf die nun geltende Identifikator-Schrittweite von 1 der gleiche.

Wurde eine numerisch passende Hausnummer gefunden, heißt das nicht, dass auchdie als Zeichenkette vorliegende Hausnummer der gesuchten entspricht. Daher folgt dernumerischen eine alphanumerische Nahfeld-Suche.

Auf diese Weise wird jedes durch Ort- bzw. Straßennamen ermittelte Adress-Tupel derErgebnisliste – soweit möglich – durch ein aus Hausnummern-Sicht besser passendesTupel ersetzt. Falls eine gesuchte Hausnummer nicht im Datenbestand gefunden wird,wählt das Programm die numerisch benachbarte.

Details zur Implementierung können dem Quellcode der Prozedur „dat_addrhousenum-ber()“ in der Datei „osmposition.c“ entnommen werden.

7.4.6 Sortieren des Suchergebnisses

Als Letztes werden die Ergebnisse ihrer Wichtigkeit nach sortiert. Ziel ist es, genaudie Ergebnisse ganz oben anzuzeigen, die die größten Geoobjekte repräsentieren, weil



von ihnen angenommen wird, dass sie vom Anwender am häufigsten gesucht werden.Sortierkriterium ist daher die geografische Ausdehnung, das so genannte Gewicht.

Für das Sortieren wird die Bibliotheksfunktion „qsort()“ zusammen mit der individuel-len Vergleichsfunktion „geoc__uint64_qsort()“ verwendet. Als Sortierkriterium dient einetemporäre Liste mit 64-Bit-Zahlen, deren Elemente sich jeweils aus dem Adress-Tupel-Identifikator und dem betreffenden Gewicht zusammensetzen. Auf diese Weise reichtein einziges Sortierkriterium aus, daher brauchte die Vergleichsfunktion nicht mehrstufigimplementiert zu werden.


8 Systemtest

Das neu entwickelte Georeferenzierungssystem muss funktional und auch hinsichtlichseiner Antwortzeit getestet werden.

Der funktionale Test wurde auf Basis von ca. 150 Adress-Stichproben durchgeführt,welche jeweils einer der drei Formen der in Abschnitt 7.1 erläuterten Syntax entsprachen.Die Validität der Ausgaben wurde einzeln anhand einer Internet-Landkarte geprüft.

Die Bestimmung der Effizienz des Algorithmus stellt den bedeutenderen Teil des System-tests dar. Hierzu ist dessen Arbeitsgeschwindigkeit zu messen. Da diese Geschwindigkeitin Abhängigkeit der aktuellen CPU- und Hauptspeicher-Cache-Auslastung stark schwan-ken kann, ist es notwendig, die Messung über einen längeren Zeitraum und mit sehr vielenunterschiedlichen Adresseingaben durchzuführen.

8.1 Testdaten

Die für den Geschwindigkeitstest zu verwendenden Adressen werden dem OSM-Daten-bestand entnommen. So ist garantiert, dass alle Suchen zu einem Ergebnis führen undnicht zum Teil die Antwortzeiten von Fehlerbehandlungen zum Tragen kommen.

Die Auswahl der Testdaten geschieht auf der Basis von Pseudozufallszahlen. Zur Erle-digung dieser Aufgabe wurde das Georeferenzierungsprogramm „osmposition“ um dieProzedur „geoc_random()“ erweitert. Der Parameter --random-address= bestimmt dieAnzahl der zu generierenden Adress-Datensätze. Damit die Reihe der Adressen vonProgrammaufruf zu Programmaufruf nicht gleich bleibt, wird der Pseudozufallszahlenge-nerator mit einem Uhrzeit-Wert initialisiert.

Jeder Testlauf wird mit einer Million Adressen durchgeführt. Zur Erstellung einer ent-sprechend großen Eingabedatei dient das folgende Kommando:

osmposition adr.ogb --random-address=1000000 >testadressen.txt

8.2 Testablauf

Bei der Durchführung des Tests werden die per Zufall ausgewählten Adressen aus derDatei „testadressen.txt“ Zeile für Zeile gelesen. Das verwendete Georeferenzierungspro-gramm bestimmt für jede dieser Adressen die zugehörige Geoposition und schreibt diese


8 Systemtest

– jeweils zusammen mit der Adresse – in die Standard-Ausgabe. Diese kann vorab perBetriebssystem-Mechanismus in eine beliebige Datei umgeleitet worden sein.

Bei den hier durchgeführten Geschwindigkeitsversuchen besteht für den Inhalt derAusgabe keine Verwendung. Deshalb wird die Standard-Ausgabe ins Leere umgeleitet.Im Fall des Betriebssystems Linux steht für diesen Zweck das virtuelle Ausgabe-Gerät„/dev/null“ zur Verfügung.

Das Messen der Ausführungszeit des Programms übernimmt das Betriebssystem-Kommando „time“.

8.2.1 Testinstallation von Nominatim

Um die durchzuführenden Geschwindigkeitsmessungen am Ende bewerten zu können,wird ein Referenzsystem benötigt. Dafür eignet sich die in Abschnitt 2.1.1 genauer be-schriebene populäre Suchmaschine Nominatim, welche zu diesem Zweck lokal installiertwurde.1

Als Testumgebung diente eine virtuelle Maschine2, weil dort Vorgaben zur nutzbarenphysischen Hardware leicht individuell angepasst werden können. Für die Testläufe wurdendie folgenden Einstellungen verwendet:

• ein Prozessorkern eines Intel i7

• 4 GiB Hauptspeicher

• Zugriff auf SSD-Sekundärspeicher

8.2.2 Datenbank-Initialisierung von Nominatim

Nach der Software-Installation muss die Datenbank der Suchmaschine gefüllt werden.Dieser Vorgang ist von der Intention her vergleichbar mit der in Kapitel 6 beschriebenenDatenaufbereitung.

Für das Verwendungsgebiet Deutschland sind dazu diese beiden Schritte durchzufüh-ren:

wget http://download.geofabrik.de/europe/germany-latest.osm.pbf

-O rawgermany.pbf

./utils/setup.php --osm-file rawgermany.pbf --all

--osm2pgsql-cache 3000 2>&1 | tee setup.log

Das Programm „wget“ übernimmt das Herunterladen, und das PHP-Script „setup.php“kümmert sich um den Datenbank-Import.

1Die Installation von Nominatim verlief gemäß Standard-Anleitung der zugehörigen Webseite:wiki.openstreetmap.org/wiki/Nominatim/Installation

2Zum Einsatz kommt die Virtualisierungssoftware VirtualBox der Firma Oracle, als Gast-Betriebssystemwird Ubuntu 14.04 verwendet.


8.2 Testablauf

Während das Herunterladen der Rohdaten nach weniger als 15 Minuten abgeschlossenwar, lief der Import mehrere Stunden, ohne dass ein deutlicher Fortschritt erkannt werdenkonnte. Eine grobe Abschätzung prognostizierte eine voraussichtliche Gesamtdauer vonetwa 4 bis 5 Tagen, weshalb die Menge der zu importierenden Daten stark reduziertwurde: statt der Rohdaten von ganz Deutschland wurden die Daten von Mittelfrankenimportiert, das sind weniger als 5 % des ursprünglichen Datenumfangs. Der Import konntedadurch nach ca. 2 Stunden abgeschlossen werden.

Bei den späteren Testläufen mit der Suchmaschine Nominatim war zu beachten, dassauch die Testdaten nur aus mittelfränkischen Adressen bestehen dürfen, da es sonst inder Mehrzahl der Fälle zu Ausnahmesituationen auf Grund nicht gefundener Adressenkommt. Deshalb wurde die Datenaufbereitung mit dem neu entwickelten System zusätzlichauch für diesen reduzierten Datenbestand durchgeführt. Aus der so erzeugten .ogb-Dateiwurden anschließend mit dem Programm „osmposition“ eine Million Adressen aus demmittelfränkischen Datenbestand zufällig ausgewählt. Da die Rohdaten dieses kleinerenGebiets deutlich weniger als eine Million unterschiedliche Adressen umfassen, enthaltendie auf diese Weise erzeugten Testdaten deutlich häufiger mehrere Exemplare derselbenAdresse.

8.2.3 Geschwindigkeitsmessung der Nominatim-Georeferenzierung

Nominatim läuft normalerweise als PHP-Anwendung auf einem Web-Server. Zum Zweckder Geschwindigkeitsmessung wurde der eigentliche Aufruf der Georeferenzierung ausge-koppelt und in das folgende PHP-Script gepackt:

<?php

require_once('../Nominatim/lib/init.php');

require_once('../Nominatim/lib/Geocode.php');

if(!isset($argv[1]))

{ echo "(no input)\n"; exit; }

ini_set('memory_limit','200M');

$oGeocode=& new Geocode(getDB());

$oGeocode->setLanguagePreference(getPreferredLanguages());

$oGeocode->setReverseInPlan(true);

$oGeocode->setPolygonSimplificationThreshold('0.0');

$oGeocode->loadParamArray('');

$oGeocode->setQueryFromParams('');

$oGeocode->setQuery($argv[1]);

// search or dummy search

$aSearchResults= $oGeocode->lookup();

//$aSearchResults[0]['name']= "Irgendein Ort";

//$aSearchResults[0]['lon']= 49.1234567;

//$aSearchResults[0]['lat']= 10.1234567;

if($aSearchResults==NULL)

{ echo "(unknown address)\n"; exit; }

echo $aSearchResults[0]["name"]." [".

$aSearchResults[0]["lon"].",".

$aSearchResults[0]["lat"]."]\n";


8 Systemtest

Das PHP-Script wird für jeden Georeferenzierungs-Vorgang, also für jede der eineMillionen Zeilen der Test-Adressdatei einmal aufgerufen. Diese Aufgabe übernimmt dasShellscript „nominatim_batch.sh“.

Der dadurch verursachte Interpretations- und Initialisierungsaufwand hat mit der ei-gentlichen Georeferenzierung nichts zu tun und muss deshalb herausgerechnet werden.Aus diesem Grund sind zwei Testläufe notwendig – einer mit und einer ohne Georeferen-zierung. In obigem PHP-Script werden deshalb beim ersten Testlauf die rot markiertenBefehlszeilen auskommentiert, beim zweiten Testlauf wird stattdessen die grün markierteauskommentiert. Tabelle 8.1 zeigt beide Messergebnisse einschließlich deren Rückrech-nung auf einen einzelnen Georeferenzierungsvorgang.

1 Mio. Durchläufe mit Georeferenzierung 804 min1 Mio. Durchläufe ohne Georeferenzierung 376 min1 Mio. Durchläufe, nur Georeferenzierung 428 min

1 Durchlauf, nur Georeferenzierung (im Durchschnitt) 26 ms

Tabelle 8.1: Geschwindigkeit der Nominatim-Georeferenzierung

Ohne Einbeziehung des Initialisierungsaufwands beträgt der Zeitbedarf je Georeferen-zierung also etwa 26 Millisekunden.

8.2.4 Geschwindigkeitsmessung der osmposition-Georeferenzierung

Auch bei der Georeferenzierung mit dem Programm osmposition wird ein Teil des Re-chenaufwands darauf verwendet, einmalig die Datenbasis und danach Zeile für Zeile dieTest-Adressen einzulesen. Der Aufwand zum Einlesen der Datenbasis fällt bei längerandauernden Geschwindigkeitstests allerdings kaum ins Gewicht, er beträgt einmalig etwa150 Millisekunden. Das Lesen der Datei mit den per Zufall ausgewählten Test-Adressengeschieht ebenfalls innerhalb des C-Programms und benötigt nur sehr wenig Rechenzeit.

Der aus dem genannten Initialisierungs- bzw. Leseaufwand resultierende Zeitverlustsoll deshalb unberücksichtigt bleiben.

Der Umfang der Testdaten braucht nicht reduziert zu werden, weil die Daten des ge-samten vorgesehenen geografischen Gebiets auf dem Testsystem innerhalb von wenigerals 10 Minuten und damit in vertretbarer Zeit aufbereitet werden können.

Der anschließend gestartete Testlauf der Georeferenzierung führte zu dem in Tabelle8.2 dargestellten Ergebnis.

1 Mio. Durchläufe mit Georeferenzierung 4 s

1 Durchlauf, nur Georeferenzierung (im Durchschnitt) 4 µs

Tabelle 8.2: Geschwindigkeit der osmposition-Georeferenzierung


8.3 Testauswertung

Das Programm benötigt im Durchschnitt ungefähr 4 Mikrosekunden je Georeferenzie-rungsvorgang.

8.3 Testauswertung

Die Zeitmessungen haben gezeigt, dass das neu entwickelte System die Georeferenzie-rung deutlich schneller durchführt als das Referenzsystem – 4 Mikrosekunden statt 26Millisekunden je Vorgang. Hätte man für beide Systeme die gleiche Datenbasis verwendet– also ganz Deutschland für beide oder Mittelfranken für beide – wäre der Unterschiedmöglicherweise noch deutlicher ausgefallen.

Das darf aber nicht darüber hinwegtäuschen, dass es sich bei dem Referenzsystem No-minatim – wie schon in Abschnitt 2.1.1 dargestellt – um ein deutlich mächtigeres Werkzeughandelt, das dem neu entwickelten Programm osmposition insbesondre im „Verstehen“nicht standardkonformer Adress-Eingabe wie auch hinsichtlich der Ausführlichkeit derAusgabe deutlich überlegen ist.

Mit einem Faktor von 6500 fällt der gemessene Geschwindigkeitsunterschied trotz-dem um einiges größer aus als erwartet. Das lässt sich damit erklären, dass für dieNeuentwicklung kein fertiges Datenbanksystem eingesetzt wurde und die Mehrzahl derverwendeten Algorithmen speziell an die Aufgabenstellung angepasst sowie in einerrechenzeiteffizienten Programmiersprache implementiert werden konnte.


9 Zusammenfassung und Ausblick

Ziel dieser Arbeit war es, ein ressourcensparendens und effizientes Georeferenzierungs-system zu entwickeln, das ohne Datenbanksystem arbeitet.

Zunächst wurde die Struktur der Ausgangsdaten analysiert. Dabei handelt es sichum freie, im Rahmen des Projekts OpenStreetMap verfügbare Daten von Adressenund Geopositionen. Wegen der nicht einheitlichen Art der Datengewinnung innerhalbdieses Crowdsourcing-Projekts war eine umfangreiche Vorverarbeitung zu planen und zuimplementieren. Dabei kam eine Reihe geometrischer Methoden zum Einsatz, welchezum Teil an die Aufgabenstellung angepasst werden mussten.

Um besonders schnelle lesende Zugriffe auf die Adressdaten zu ermöglichen, wurdeeine entsprechend ausgerichtete Datenstruktur entwickelt. Die Suchzugriffe erfolgenvorrangig per binärer Schachtelung. Zu lösen war dabei das Problem der gleichzeitigenSuche nach voneinander unabhängigen Kriterien wie Orts- und Straßenname.

Das Programm des auf dieser Datenstruktur aufsetzenden Georeferenzierungsalgo-rithmus wurde als Unix-Filter implementiert, so dass es sowohl per direkter manuellerEingabe als auch durch andere Anwendungen innerhalb eines automatisierten Systemsgenutzt werden kann.

Zum Zweck der Bewertung waren für den neuen Algorithmus Geschwindigkeitstestdurchzuführen. Für Laufzeit-Vergleiche wurde das populäre, datenbankgestützte Georefe-renzierungssystem Nominatim herangezogen.

Nach diesen Tests und deren abschließender Bewertung kann festgehalten werden,dass das aufgestellte Ziel der Effizienz erreicht wurde. Der relative Geschwindigkeitsun-terschied im Vergleich zu dem etablierten System Nominatim lag überraschend sogar imvierstelligen Bereich, er betrug durchschnittlich 4 µs gegenüber 26 ms je Georeferenzie-rungsvorgang.

Dennoch gibt es Ansätze für weitere Verbesserungen, deren nähere Untersuchung sichlohnen könnte. Im Folgenden soll kurz auf die jeweiligen Vorschläge eingegangen werden.

• Hash-Tabelle

Die entwickelte Anwendung verwendet vorzugsweise die Binärsuche. Bei größe-ren Datenmengen ist Hashing der Binärsuche bezüglich der Geschwindigkeit imAllgemeinen überlegen. Allerdings wird dafür auch mehr Speicherplatz benötigt.Trotzdem könnte es sinnvoll sein, diese Alternative genauer zu untersuchen undentsprechende Tests durchzuführen.



• Parallelisierung

Wie bereits in Abschnitt 3.3.4 dargestellt, bringt die Parallelisierung unter demAspekt des Energieverbrauchs auch Nachteile. Es gibt jedoch Anwendungsfälle,bei denen darauf nicht geachtet werden muss. Für diese Fälle sollte eine möglicheParallelisierung der Algorithmen angestrebt werden.

• Betriebssystem-Befehl „sort“

Im Rahmen der Datenaufbereitung wurde der Betriebssystem-Befehl „sort“ ver-wendet, um Listen von Zeichenketten zu sortieren und Duplikate aus ihnen zuentfernen. Hier wäre zu untersuchen, ob eine eigene Implementierung innerhalbdes Programms „osmgeobase“ Geschwindigkeitsvorteile bringt. Verwendet werdenkönnte die Bibliotheksfunktion „qsort()“ mit anschließendem einmaligen Durchlaufzur Duplikatentfernung.

• Suchergebnis-Sortierfolge

Als Sortierkriterium für die Suchergebnisse dient die Ausdehnung des jeweiligengeografischen Objekts, sein so genanntes Gewicht. Diese Größe liegt als ganzzahli-ger binärer Logarithmus vor. Bei Objekten, die eine ähnliche Ausdehnung besitzen,kann das deshalb zu einer Reihenfolge führen, die nicht ganz der Realität entspricht.Hier könnte es sinnvoll sein, den binären Logarithmus nicht als Ganzzahl, sondernals Festkommazahl vorzuhalten.

• Hausnummer-Suche

Die Suche nach der numerischen wie nach der alphabetischen Repräsentation vonHausnummern wurde als zweistufige serielle Suche implementiert. Effizienter wärehier möglicherweise eine binäre Suche mit offenem Ende.

• Memory-mapped I/O

Der derzeit implementierte Ansatz sieht vor, die Adressdaten als Ganzes in denArbeitsspeicher zu laden. Die Georeferenzierung kann dadurch mit einer sehr ge-ringen Antwortzeit erfolgen. Es gibt jedoch Fälle, in denen diese Vorgehensweisenachteilig oder nicht möglich ist: nur sporadisch benötigte einzelne Georeferen-zierungsvorgänge, begrenzter Arbeits- oder Hauptspeicherplatz. Als Ausweg kannPlatz im Sekundärspeicher reserviert werden, auf denn dann per MMIO1zugegriffenwird. Einfacher wird es jedoch sein, mehr Platz für den Auslagerungsspeicher zureservieren und die Arbeit dem Betriebssystem zu überlassen. In beiden Fällenbräuchte an den verwendeten Suchalgorithmen nichts geändert zu werden.

1Memory-mapped I/O, Dateizugriff per Arbeitsspeicherzugriff, evtl. per POSIX-Bibliotheksfunktion „mmap()“


Verwendete Software

Die nachfolgend aufgeführte Software wurde im Rahmen dieser Arbeit eingesetzt, verän-dert oder neu entwickelt. Die Quellcodes von veränderten oder neu entwickelten Program-men befinden sich auf dem beiliegenden Datenträger.

A Unverändert eingesetzte Software

• gcc, C-Compiler der GNU Compiler Collection, Version 4.8.4,Webseite: gcc.gnu.org

• Gummi, LATEX-Editor, Version 0.6.5,Webseite: github.com/alexandervdm/gummi

• Inkscape, grafischer Editor, Version 0.48.4,Webseite: inkscape.org

• LibreOffice Writer, Textsystem, Version 4.2.8.2,Webseite: de.libreoffice.org

• Mozilla Firefox, Internet-Browser, Version 44.0.2,Webseite: www.mozilla.org/de/firefox

• Nemiver, grafischer Debugger, Version 0.9.5,Webseite: wiki.gnome.org/Apps/Nemiver

• Nominatim, Georeferenzierungssoftware2, Version 2.5.0,Webseite: wiki.openstreetmap.org/wiki/Nominatim/Installation

• osmfilter, Filtern von OpenStreetMap-Dateien, Version 1.4.0,Webseite: wiki.openstreetmap.org/wiki/osmfilter

• Ubuntu, Betriebssystem, Version 14.04,Webseite: ubuntu.com

• VirtualBox, Virtualisierungssoftware, Version 4.3.36,Webseite: virtualbox.org

B Modifizierte Software

• osmconvert, Umformen von OpenStreetMap-Dateien, Version 0.8.5,Quellcode-Datei: osmconvert.cWebseite: wiki.openstreetmap.org/wiki/osmconvert

2Die Georeferenzierungssoftware Nominatim wurde nur für Geschwindigkeitsvergleiche verwendet.



C Neu entwickelte Software

• osmassignpoly, Zuordnung von Grenzpolygonen,Quellcode-Datei: osmassignpoly.c3

• osmgeobase, Komplettieren von Adressdaten,Quellcode-Datei: osmgeobase.c3

• osmposition, Georeferenzierung,Quellcode-Datei: osmposition.c3

• osmrelpoly, Umwandlung von OSM-Relationen in Grenzpolygone,Quellcode-Datei: osmrelpoly.c3

• Werkzeugkette der Datenaufbereitung für die Georeferenzierung,Script-Datei: preparation.sh

3Das Grundgerüst dieses Programms sowie verschiedene Prozeduren allgemeiner Art wurden dem Quell-code des Programms osmconvert entnommen.


Abbildungsverzeichnis


0.1 Logo der FernUniversität in Hagen [FU16] . . . . . . . . . . . . . . . . . . . 1

1.1 geografische Ausdehnung unterschiedlicher Objekte [OSMMAP16] . . . . . 121.2 Gesamtsystem-Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.3 Unix-Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1 sphärisches Rechteck 20°×20° auf der Erdoberfläche . . . . . . . . . . . . 273.2 Äquidistanzlinien verschiedener Methoden der Entfernungsbestimmung . . 293.3 fehlerhaft repräsentierende Koordinaten einer Linie [OSMMAP16] . . . . . 303.4 repräsentierende Koordinaten einer Fläche [OSMMAP16] . . . . . . . . . . 313.5 Strahl-Methode des Punkt-in-Polygon-Tests nach Jordan . . . . . . . . . . 313.6 Sonderfälle bei Verwendung der Strahl-Methode . . . . . . . . . . . . . . . 323.7 Längengradabschnitte bei Verwendung der Strahl-Methode . . . . . . . . . 333.8 Polygonvereinfachung per Flächen-Kriterium . . . . . . . . . . . . . . . . . 343.9 Suchgitter zur Ermittlung der nächsten Nachbarn . . . . . . . . . . . . . . . 373.10 Leistungsaufnahme ohne Parallelität und bei zwei parallelen Prozessen . . 43

4.1 Datstellungsbeispiel für einen Knoten [OSMMAP16] . . . . . . . . . . . . . 464.2 Datstellungsbeispiel für einen Polygonzug [OSMMAP16] . . . . . . . . . . . 474.3 Datstellungsbeispiel für eine Relation [OSMMAP16] . . . . . . . . . . . . . 484.4 Verknüpfungen zwischen OSM-Objekten . . . . . . . . . . . . . . . . . . . 484.5 duplikatfreies serielles Zusammenführen von OSM-Objekten . . . . . . . . 524.6 diskrete Hausadresse [OSMMAP16] . . . . . . . . . . . . . . . . . . . . . . 534.7 Ortsteilname mit Hausnummer [OSMMAP16] . . . . . . . . . . . . . . . . . 554.8 mehrfach zugeordnete Hausnummer [OSMMAP16] . . . . . . . . . . . . . . 554.9 Hausadresse in einem Mannheimer Quadrat [OSMMAP16] . . . . . . . . . 564.10 Straßenname als OSM-Attribut [OSMMAP16] . . . . . . . . . . . . . . . . . 564.11 Gemeindegrenzen im Gewerbepark [OSMMAP16] . . . . . . . . . . . . . . 574.12 Gemeindegrenzen als Kombination von Polygonzügen [OSMMAP16] . . . . 58

6.1 Start der Verarbeitungslinien der Datenaufbereitung . . . . . . . . . . . . . 706.2 Verarbeitungslinie 1 der Datenaufbereitung . . . . . . . . . . . . . . . . . . 716.3 Verarbeitungslinie 2 der Datenaufbereitung . . . . . . . . . . . . . . . . . . 726.4 Verarbeitungslinie 3 der Datenaufbereitung . . . . . . . . . . . . . . . . . . 746.5 Ende der Verarbeitungslinien der Datenaufbereitung . . . . . . . . . . . . . 75



6.6 Zuordnen der Gemeindepolygone . . . . . . . . . . . . . . . . . . . . . . . 756.7 Komplettieren der Adressdaten . . . . . . . . . . . . . . . . . . . . . . . . . 76

7.1 Datenfluss innerhalb des Georeferenzierungsprogramms . . . . . . . . . . 85


Tabellenverzeichnis

Tabellenverzeichnis

3.1 für Binärsuche kombinierte Geokoordinaten . . . . . . . . . . . . . . . . . . 37

4.1 Fallunterscheidung bei unvollständigen Hausadressen . . . . . . . . . . . . 544.2 Beispiel für Attribute einer Gemeinde-Relation [OSMMAP16] . . . . . . . . 58

5.1 Behälter für Dateninhalt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615.2 Behälter für Datenbeziehungen . . . . . . . . . . . . . . . . . . . . . . . . . 625.3 Rückbeziehungen von Dateninhalt zu Datenbeziehung . . . . . . . . . . . . 625.4 Aufbau einer .ogb-Datei . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665.5 komprimieren durch Änderungsfortschreibung . . . . . . . . . . . . . . . . . 675.6 komprimieren durch Änderungsfortschreibung und Endungsabkürzung . . . 68

6.1 beim Komplettieren zu verarbeitende Attribute . . . . . . . . . . . . . . . . . 776.2 Sortierreihenfolge für Adress-Tupel . . . . . . . . . . . . . . . . . . . . . . . 82

7.1 zu unterscheidende Fälle der Adresseingabe . . . . . . . . . . . . . . . . . 837.2 Beispiel einer Suche nach Ort und Straße . . . . . . . . . . . . . . . . . . . 877.3 Beispiel einer Suche nach der Hausnummer . . . . . . . . . . . . . . . . . 88

8.1 Geschwindigkeit der Nominatim-Georeferenzierung . . . . . . . . . . . . . 948.2 Geschwindigkeit der osmposition-Georeferenzierung . . . . . . . . . . . . . 94


Quellenverzeichnis

[ABLLW16] Amtsblatt für die Stadt Leinefelde-Worbis vom 18.12.2014, Nr. 30, Jahrgang2014

[DP16] Broschüre „Automationsfähige Briefsendungen“, Deutsche Post AG, Bonn, StandJanuar 2016

[Erde16] Wikipedia-Artikel „Erde“, Wikipedia, de.wikipedia.org/wiki/Erde, abgerufen2016-02-15

[FU16] Logo der FernUniversität in Hagen, fernuni-hagen.de, abgerufen 2016-03-16

[GF16] Download-Server der Firma „Geofabrik“, download.geofabrik.de, abgerufen2016-01-29

[GNF16] Webseite des „Gewerbepark Nürnberg-Feucht-Wendelstein“,gewerbepark-nuernberg-feucht.de/zweckverband.htm, abgerufen 2016-02-09

[GPBF16] Google Protocol Buffers, Google, developers.google.com/protocol-buffers,abgerufen 2016-02-07

[He16] Wikipedia-Artikel „Heron-Verfahren“, Wikipedia,de.wikipedia.org/wiki/Heron-Verfahren, abgerufen 2016-02-15

[Java16] Java-Dokumentation, ORACLE, Redwood Shores,docs.oracle.com/javase/8/docs/api/java/lang/Integer.html, abgerufen 2016-02-15

[Jo16] Wikipedia-Artikel „Punkt-in-Polygon-Test nach Jordan“, Wikipedia,de.wikipedia.org/wiki/Punkt-in-Polygon-Test_nach_Jordan, abgerufen 2016-03-10

[ND16] Nominatim-Dokumentation, Projekt OpenStreetMap und Mitwirkende,wiki.openstreetmap.org/wiki/Nominatim, abgerufen 2016-02-29, Lizenz: CC BY-SA

[NQ16] Nominatim-Quellcode, Projekt OpenStreetMap und Mitwirkende,github.com/twain47/Nominatim, abgerufen 2016-02-29

[OAQ16] OsmAnd-Quellcode, OsmAnd-Mitwirkende, github.com/osmandapp, abgerufen2016-02-15

[OCA16] OpenCage-Beschreibung, Opencage Data Ltd., geocoder.opencagedata.com,abgerufen 2016-02-15


Quellenverzeichnis

[OCO16] Osmocoder-Beschreibung, Firma 123map.de,www.osmocoder.de/geocoder.html, abgerufen 2016-02-15

[OCQ16] osmconvert-Quellcode, Markus B. Weber, m.m.i24.cc/osmconvert.c, abgerufen2016-01-27

[OD16] Wikipedia-Artikel „Open Data Commons“, Wikipedia,de.wikipedia.org/wiki/Open_Data_Commons, abgerufen 2016-02-20

[OFQ16] osmfilter-Quellcode, Markus B. Weber, m.m.i24.cc/osmfilter.c, abgerufen2016-02-16

[OSM16] Wikipedia-Artikel „OpenStreetMap“, Wikipedia,de.wikipedia.org/wiki/OpenStreetMap, abgerufen 2016-02-04

[OSMAPI16] OSM-Wiki-Artikel „API v0.5“, Projekt OpenStreetMap und Mitwirkende,wiki.openstreetmap.org/wiki/API_v0.5, abgerufen 2016-02-04

[OSMMAP16] OSM-Karte, zum Teil nachträglich bearbeitet, Projekt OpenStreetMap undMitwirkende, openstreetmap.org, abgerufen Januar bis März 2016

[OSMMF16] OSM-Wiki-Artikel „Map_Features“, Projekt OpenStreetMap und Mitwirkende,wiki.openstreetmap.org/wiki/Map_Features, abgerufen 2016-02-20

[O5M16] OSM-Wiki-Artikel „O5M“, Projekt OpenStreetMap und Mitwirkende,wiki.openstreetmap.org/wiki/o5m, abgerufen 2016-03-10

[PBF16] OSM-Wiki-Artikel „PBF“, Projekt OpenStreetMap und Mitwirkende,wiki.openstreetmap.org/wiki/PBF_Format, abgerufen 2016-03-10

[PG16] PostgreSQL-Beschreibung, Wikipedia (englisch),en.wikipedia.org/wiki/PostgreSQL, abgerufen 2016-02-15

[PLZ16] Postleitzahlenverzeichnis, Internetauftritt der Firma „Deutsche Post AG“,www.postdirekt.de/plzserver, abgerufen 2016-02-15

[SP16] simplify-polygon.pl-Quellcode, Polygon-Vereinfachung im Projekt OpenStreetMap,https://trac.openstreetmap.org/browser/subversion/applications/utils/osm-extract/polygons/simplify-poly.pl,abgerufen 2016-01-28


Anhang

Anhang

Beigefügt wurde ein Datenträger mit dem folgenden Inhalt.

• Ordner Text mit diesem Dokument in den Formaten PDF und TEX:

„georef.pdf“, „georef.tex“ (inklusive Unterordner „bild“ mit den enthaltenen Abbildun-gen), „datenfluss.pdf“, „datenfluss.odt“.

• Ordner Datenaufbereitung mit dem Quellcode der Programme der Datenaufberei-tung, einschließlich der verwendeten Werkzeugkette:

„osmconvert.c“, „osmfilter.c“, „osmrelpoly.c“, „osmassignpoly.c“, „osmgeobase.c“,„preparation.sh“.

• Ordner Georeferenzierung mit dem Quellcode des Programms der Georeferenzie-rung, einschließlich neuer Quelldateien des Referenzsystems:

„osmposition.c“, „nominatim_batch.sh“, „nominatim_search.php“.

• Ordner Testdaten mit den verwendete Roh- und Testdaten:

„raw.o5m“, „raw_mfr.o5m“, „testadressen.txt“, „testadressen_mfr.txt“.

• Ordner Testprogramme mit dem Quellcode sonstiger Testprogramme für mathema-tische Methoden:

„test_sqrt1.c“, „test_sqrt2.c“.


Mathematik und Informatik - Willkommen bei deposit hagen · Kurzfassung Diese Arbeit zeigt, wie...

Documents

Transcript of Mathematik und Informatik - Willkommen bei deposit hagen · Kurzfassung Diese Arbeit zeigt, wie...