© saicle/Shutterstock.com
Rendering von Karten mit lokal bereitgestellten Geodaten

Karten malen nach Zahlen


Zu Zeiten von Google Maps oder OpenStreetMap ist die Integration von Kartendarstellungen in Webanwendungen sehr einfach. Jedoch bringt der herkömmliche Weg über das Kartenmaterial der genannten Anbieter diverse Nachteile und Abhängigkeiten mit sich. Um diese zu umgehen, können Geodaten in einer lokalen Datenbank bereitgestellt und zum Rendern benutzerdefinierter Karten verwendet werden. Das Aussehen der eigenen Karten kann dabei sogar in Abhängigkeit zu Businessdaten gestaltet werden und für verschiedene Anwender unterschiedlich sein.

Möchte man Kartendarstellungen in eine Webanwendung einbinden, so hat man heutzutage einfache Möglichkeiten. Zum Beispiel benutzt man das Kartenmaterial von Google zusammen mit ihrem JavaScript-API oder das freie Kartenmaterial von OpenStreetMap (OSM), das von diversen JavaScript-APIs wie OpenLayers oder Leaflet angezeigt werden kann. Dabei ist das grundlegende Darstellen der Karte in Kacheln, den so genannten Tiles, denkbar einfach und mit nur wenigen Zeilen Code umzusetzen. Zudem werden beim Zoom oder der Verschiebung (Panning) der Karte die Tiles schnell nachgeladen, da sie bereits vorgerendert auf dem jeweiligen Server zur Verfügung stehen.

Dies offenbart allerdings auch die größte Schwachstelle dieser Variante: die Notwendigkeit einer bestehenden Internetverbindung. Diese macht es unmöglich, die Kartendarstellung in eine Webanwendung, die lediglich im lokalen Netzwerk ohne Internet genutzt werden soll, zu integrieren. Ein weiterer Nachteil ist das vorgegebene Material, das sich grafisch nicht mehr weiter bearbeiten lässt. Möchte man zum Beispiel Datenmengen mit geografischem Bezug grafisch aufbereitet auf einer Karte darstellen, so bliebe zur Abbildung weiterer Informationen lediglich die Einblendung von Overlays oder Vektorgrafiken mit JavaScript. Dies hätte allerdings eine Belastung der Views mit Businesslogik zur Folge. Weitere Nachteile sind mögliche Kosten im Falle der Verwendung von Google Maps sowie eventuelle Verstöße gegen den Datenschutz durch die Übermittlung personenbezogener Daten, etwa beim Setzen von Markern. Dieser Artikel beschreibt einen Weg, um allen diesen Nachteilen aus dem Weg zu gehen.

Bezug von OSM-Geodaten und ihre Struktur

Um eigene Karten zu rendern, benötigt man Geodaten. OSM bietet die eigens verwendeten Daten als so genanntes „Planet File“ im hauseigenen .osm-Format an. Braucht man nur die Informationen eines Kontinents oder einzelner Staaten, so gibt es diese ebenfalls zum Download, etwa bei download.geofabrik.de. Der einzige Nachteil der OSM-Daten besteht darin, dass detailliertere und spezielle Informationen wie Hausnummern oder die Tiefe einer Position im Ozean nicht vollständig oder gar nicht vorhanden sind. Daher muss abgewogen werden, ob diese Geodaten für den vorgesehenen Zweck vollständig genug sind.

Eine .osm-Datei ist nichts weiter als eine XML-Datei, bestehend aus Tags für Nodes, Ways und Relations. Dabei repräsentieren Nodes einzelne geografische Punkte, Ways sind eine Menge von Nodes und Relations sind eine Menge von Nodes und Ways, die in Relation zueinander stehen. Nimmt man zum Beispiel eine U-Bahnlinie, so werden die Haltestellen als Nodes, die Strecken zwischen den Haltestellen als Ways und die gesamte ­ U-Bahnlinie als Relation zwischen Haltestellen und Strecken definiert. Listing 1 zeigt eine U-Bahnhaltestelle in Form einer Node, deren geografische Position über die Attribute lat und lon angegeben ist.

Listing 1: U-Bahnhaltestelle St.Pauli

<node id="1456997274" lat="53.5507099" lon="9.9701915"> <tag k="name" v="St. Pauli" /> <tag k="public_transport" v="stop_position" /> <tag k="railway" v="station" /> </node>

Hier sieht man zudem drei Tags, name, public_transport und railway, die von OSM benutzt werden, um die Geodaten mit Informationen zu bestücken. Welche Tags es gibt, ist in [1] recherchierbar.

Bereitstellung der Geodaten

Die später diskutierten Renderingtools können Geodaten aus einer PostgreSQL-Datenbank mit der so genannten PostGIS-Erweiterung verarbeiten. PostGIS erweitert die Datenbank um geometrische Objekte und Methoden, wie etwa die Vereinigung oder den Schnitt von Polygonen, um diese zu bearbeiten. Für den Import der Daten in die Datenbank wird zudem die Erweiterung „hstore“ benötigt, die lediglich einen Datentyp zum Speichern von Schlüssel-Wert-Paaren bereitstellt (vgl. [2]).

Für den Datenimport gibt es diverse Kommandozeilentools. Hier im Beispiel wird mit osm2pgsql gearbeitet. Dieses Tool benötigt eine .style-Datei, auf deren Basis die zu importierenden Daten gefiltert werden. Ihr Aufbau ist in Listing 2 dargestellt.

Listing 2: Auszug aus einer Importstyledatei für „osm2pgsql“

# OsmType Tag DataType Flags node,way boundary text linear node,way building text polygon node capital text linear way area:highway text phstore node,way highway text linear node,way note text delete

Der OsmType ist node, way oder node,way und gibt an, welche der OSM-Strukturen über das jeweilige Tag verfügen. Relationen ...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang