Große OpenStreetMap-Karten selbst rendern

Ich bin von den Anforderungen des Renderings selbst ein wenig überrascht gewesen. Es empfiehlt sich ein Computer mit mindestens 8 GiB Arbeitsspeicher, dazu ein möglichst schneller Prozessor. Jedenfalls konnte ich nicht beobachten, dass die Rendering-Software auf meine Graphikkarte zugegriffen hätte, was der benötigten Zeit sicherlich gut getan hätte, so aber sind ein paar Minuten 100%-ige CPU-Auslastung schonmal drin.

Der Import der OSM-Daten in die PostgreSQL/PostGIS-Datenbank erfolgt grundsätzlich mit osm2pgsql. Am konkreten Aufruf des Programms aber scheiden sich die Geister – ich habe es schließlich so aufgerufen, ohne irgendwelche Nachteile feststellen zu können:

$ osm2pgsql --slim -d gis --number-processes 3 ~/Downloads/nordrhein-westfalen-latest.osm.pbf

Dises Prozess dauert relativ lange, bei mir war es relativ genau eine Stunde. Größere Datenmengen benötigen freilich länger.

Für ein erfolgreiches Rendering ist es zunächst wichtig zu verstehen, wie der Prozess eigentlich abläuft. Für Mapnik existieren im Wesentlichen zwei Datenquellen: Shapefiles und Geodaten. Bei letzteren handelt es sich um das, was wir vorhin in PostGIS importiert haben, Shapefiles sind reine Konturdaten. Das kanonische Beispiel sind die Küstenlinien an den Weltmeeren, die OpenStreetMap nicht selbst erfasst, sondern über eine Shapefile von Natural Earth verwaltet. Sowohl von Shapefiles als auch von PostGIS-Daten können beliebig viele (lies: Solange der RAM reicht) in eine Karte importiert werden, man spricht oberbegrifflich von Datenquellen (engl. data sources).

       Datenquelle
      /           \
Shapefile        Geodaten

Diese Datenquellen werden nun als Ebenen in eine bestimmte Reihenfolge gebracht (jede Ebene hat genau eine Datenquelle); beim finalen Rendering werden die Ebenen dann „aufeinander gepresst“. So könnte man beispielsweise ein sehr rohe Straßenkarte erstellen, indem man die Küstenlinien-Shapefile unter den Straßen-Geodaten anordnet:

Straßen-Geodaten
Küsten-Shapefile
      ↓↓
 Gesamtkarte

Die OpenStreetMap-Daten liefern insgesamt sieben Geodatenquellen:

gis=# \d
                Liste der Relationen
 Schema |        Name        |   Typ   | Eigentümer 
--------+--------------------+---------+------------
 public | geography_columns  | Sicht   | postgres
 public | geometry_columns   | Sicht   | postgres
 public | planet_osm_line    | Tabelle | quintus
 public | planet_osm_nodes   | Tabelle | quintus
 public | planet_osm_point   | Tabelle | quintus
 public | planet_osm_polygon | Tabelle | quintus
 public | planet_osm_rels    | Tabelle | quintus
 public | planet_osm_roads   | Tabelle | quintus
 public | planet_osm_ways    | Tabelle | quintus
 public | raster_columns     | Sicht   | postgres
 public | raster_overviews   | Sicht   | postgres
 public | spatial_ref_sys    | Tabelle | postgres

Alle Tabellen, die im obigen Listing mit „planet\_“ anfangen, sind in Mapnik verwertbare Geodatenquellen unterschiedlichen Umfangs. So enthält planet_osm_roads etwa nur Straßen, planet_osm_polygon nur in sich abgeschlossene Objekte (z.B. Gebäude).

Jede Ebene kann zudem gestyled werden (z.B. Wege auf dieser Ebene blau, Hintergrund grün); die gesamte Kartenstruktur wird Mapnik in Form eines komplexen XML-Kontrukts mitgeteilt. Da insbesondere das Styling der verschiedenen Kartenelemente in XML eine ausgesprochen leidige Arbeit ist, hat TileMill hierfür einen Abkömmling von CSS einführt, CartoCSS. CartoCSS ist sehr mächtig und kann zur besonderen individuellen Gestaltung von Karten verwandt werden, für den Moment begnügen wir uns aber mit dem CartoCSS, das das OpenStreetMap-Projekt für seine eigene Online-Karte verwendet, openstreetmap-carto.

Hinweis: TileMill-Projekte können mithilfe des in Tilemill enthaltenden Programms carto (unter node_modules/carto/bin/carto) direkt in Mapnik-XML konvertiert werden. So ist es möglich, ein TileMill-Projekt außerhalb des UIs von TileMill zu bearbeiten, zu stylen und auch zu rendern.

Openstreetmap-Carto kommt als TileMill-Projekt daher, welches in den Projektordner von TileMill kopiert werden muss. Damit dieser überhaupt existiert, muss TileMill wie weiter oben gezeigt zumindest einmal gestartet werden. Dieses TileMill-Projekt ist wie schon weiter oben erwähnt der Grund dafür, dass die Datenbank gis heißen muss – bei einem anderen Datenbanknamen müssten für jede Ebene im TileMill-Projekt, die auf die Geodaten zugreift, die Verbindungsdaten geändert werden. Dies ist zwar möglich, aber ausgesprochen aufwendig.

Nach dem erstmaligen Start sollte ein Ordner ~/Documents/MapBox/project existieren (sic, von XDG hat TileMill bisher noch nicht gehört), in den das Openstreetmap-Projekt geklont werden kann:

$ cd ~/Documents/MapBox/project
$ git clone git://github.com/gravitystorm/openstreetmap-carto.git
$ cd openstreetmap-carto

Die Instruktionen in der README können größtenteils ignoriert werden, weil wir die notwendigen Vorbereitungen bereits getroffen haben. Insbesondere entfällt der Fix von ne_10m_populated_places, weil aktuelle Versionen von Mapnik das Problem bereits behoben haben. Stattdessen können wir nun den Fix fixen, d.h. in der Datei get_shapefiles.sh folgende Zeilen auskommentieren:

#process populated places
echo "processing ne_10m_populated_places..."
rm -f data/ne_10m_populated_places/ne_10m_populated_places_fixed.*
ogr2ogr --config SHAPE_ENCODING UTF8 data/ne_10m_populated_places/ne_10m_populated_places_fixed.shp data/ne_10m_populated_places/ne_10m_populated_places.shp

und den darauf folgenden shapeindex-Befehl wie folgt abändern:

shapeindex --shape_files \
data/simplified-land-polygons-complete-3857/simplified_land_polygons.shp \
data/land-polygons-split-3857/land_polygons.shp \
data/ne_10m_populated_places/ne_10m_populated_places.shp \
data/ne_110m_admin_0_boundary_lines_land/ne_110m_admin_0_boundary_lines_land.shp

Jetzt kann man das Skript ausführen, das einige Shapefiles herunterladen wird, die Openstreetmap-Carto als Datenquellen dienen. Danach kann das Projekt in TileMill geöffnet werden, indem es einfach auf der Startseite von TileMill ausgewählt wird. Sollte TileMill beim Öffnen des Projekts „file-not-found“-Fehlermeldungen zeigen, sollten die Dateinamen im Verzeichnis „data“ überprüft werden – wenn auch nur eine Datenquelle nicht gefunden wird, verweigert TileMill komplett die Arbeit und zeigt nur eine leere Karte ohne weiteren Kommentar.

In TileMill kann man nun ganz normal arbeiten; das Benutzerinterface ist recht intuitiv, die genaue Bedienung kann in der Anleitung nachgelesen werden. Wichtig ist insbesondere, beim Export eine Zoomstufe auszuwählen – Zoomlevel 0 erzeugt nur leere Karten (jedenfalls dann, wenn man nicht das gesamte (!) OSM-Datenmaterial in der PostGIS-Datenbank hat). Je nach Verwendungszweck kann man sich für ein passendes Export-Format entscheiden; der besseren Weiterverarbeitung wegen habe ich mich für SVG entschieden.

Die exportierte Karte ist in der Regel völlig unförmig, d.h. liegt in einem Seitenformat vor, das man so überhaupt nicht drucken kann. Mithilfe von Inkscape kann man die Karte jedoch etwa auf A1 herunterschneiden, indem man zunächst ein neues Dokument anlegt, danach in den Dokumenteneinstellungen das Seitenformat A1 + Querformat auswählt und anschließend das aus TileMill exportierte SVG importiert. Dieses Prozess dauert sehr lange und benötigt große Mengen Arbeitsspeicher, daher sollte man für diesen Schritt Geduld mitbringen. Nach erfolgtem Import kann die Karte auf der Seite platziert werden, wobei Überschüssiges ruhig über den Rand hinausragen darf. Über „Datei → Kopie speichern unter“ kann man nun nur den Seitenbereich (also das A1-Blatt) als PDF exportieren, wobei Teile außerhalb des Seitenbereichs abgeschnitten werden. Das Ergebnis sieht etwa so wie hier aus und ist druckfertig. Selbstverständlich kann man in Inkscape auch noch weitere Nachbearbeitungen machen, z.B. ein Gitter über die Karte legen oder eine Legende hinzufügen. Dies sei der Kreativität des Lesers überlassen – allerdings mit dem Hinweis, dass die Lizenzbedingungen von OpenStreetMap vorschreiben, dass irgendwo der Hinweis „© OpenStreetMap-Mitwirkende“ angebracht wird.

OpenStreetMap ist ganz große Klasse. Neben Online- lassen sich damit auch prima Druckkarten anfertigen, allerdings kränkt das Projekt in dieser Hinsicht an fehlender und zuweilen sogar widersprüchlicher, weil veralteter Dokumentation. Große Teile der im Internet (sogar im OSM-Wiki) auffindbaren Informationen beziehen sich auf Mapnik Version 0.x, mittlerweile jedoch ist die Software schon zwei Major-Releases weiter und damit schlicht nicht mehr kompatibel. Die alternativen Renderer neben TileMill werden nicht mehr entwickelt, und CartoCSS hat seinen Vorgänger MapCSS abgelöst. Auch PostgreSQL und PostGIS sind nicht stehengeblieben, insbesondere ist es zur Verwendung von PostGIS nicht mehr erforderlich, irgendwelche SQL-Skripte aus dem contrib/-Pfad von PostgreSQL auszuführen. Insgesamt bewegt sich die OSM-Software sehr schnell, sodass ich hoffe, mit diesem Artikel ein wenig Ordnung in dieses verwirrende Durcheinander gebracht zu haben. Wie lange er freilich aktuell bleiben wird, weiß ich nicht zu sagen.