OpenStreetMap-Daten zu eigenen Topo-Karten — Workflow ohne Cloud
Schritt für Schritt: Geofabrik-Extracts, QGIS, PostGIS, tippecanoe — wie man aus OSM-Rohdaten eine eigene Topo-Karte druckt, vollständig lokal, ohne Cloud-Service. Plus: warum manche Vermesser ihre Karten heute selbst rendern.
Eine selbst gerenderte topographische Karte gehört nicht in die Romantik-Abteilung der Kartografie. Sie gehört in die Praxis, und zwar genau dann, wenn die handelsüblichen Karten – die ADAC-Wanderkarten, die Falk-Stadtpläne, die Kompass-Tourenkarten – aus drei Gründen nicht mehr ausreichen: weil sie zu alt sind, weil sie im falschen Maßstab vorliegen, oder weil man die Daten, die der Karte zugrundeliegen, dauerhaft besitzen möchte. Wer 2026 als Vermesserin, Geländekundlerin, Wegplaner oder Forstwirt eine Karte braucht, die das eigene Arbeitsgebiet im Detail trifft, der kommt mit ein paar Werkzeugen, einer halbwegs aktuellen Maschine und vielleicht einem Wochenende Konzentration zu einem Ergebnis, das die meisten Verlagsprodukte schlägt.
Im Folgenden ein dokumentierter Workflow, vollständig lokal, ohne Cloud-Service. Wer mitliest, hat am Ende eine druckfähige PDF-Karte im Maßstab 1:25.000 für ein selbst gewähltes Gebiet.
Datenquellen
OpenStreetMap ist die Basis. Aber OSM ist kein Datensatz im klassischen Sinne, sondern eine ständig wachsende Datenbank. Wer mit OSM arbeitet, lädt einen Extract – einen Schnitt durch die Datenbank zu einem bestimmten Zeitpunkt – und arbeitet damit.
Die zuverlässigste Quelle für Deutschland ist Geofabrik (geofabrik.de), eine Karlsruher Firma, die seit 2007 OSM-Auszüge in den Formaten .osm.pbf (Protobuf, kompakt) und .osm.bz2 (XML, komprimiert) zum freien Download anbietet. Die Datei germany-latest.osm.pbf liegt im Mai 2026 bei etwa 4,2 GB, die Bundeslandauszüge bei 200 bis 800 MB. Geofabrik aktualisiert die Extracts täglich, was für die meisten Zwecke ausreicht. Wer minutiöse Aktualität braucht – etwa bei einer aktiven Wege-Kartierung im Wald – nutzt direkt das OSM-Replikations-Feed (planet.openstreetmap.org/replication/minute/), das alle 60 Sekunden ein Diff-File bereitstellt.
Für administrative Grenzen, Höhenlinien und Topo-Layer, die OSM nicht vollständig abdeckt, ergänzt man BKG-Daten (Bundesamt für Kartographie und Geodäsie, geodatenzentrum.de) – etwa die Verwaltungsgebiete 1:25.000 (VG25) oder die Digitalen Geländemodelle DGM5 und DGM25, beide unter DL-DE→BY-2.0-Lizenz frei verfügbar. Wer noch granularere Topo-Inhalte braucht, greift auf ATKIS-Daten (Amtliches Topographisch-Kartographisches Informationssystem) der jeweiligen Landesvermessung zu; die Datenpolitik ist Bundesland-spezifisch, einige Länder (Niedersachsen, Nordrhein-Westfalen, Berlin) sind weitgehend offen, andere (Bayern, Baden-Württemberg) restriktiver.
Der QGIS-Workflow
QGIS 3.40 oder neuer ist Pflicht. Es ist quelloffen, ressourcenfreundlich, und mit einem Plugin-Ökosystem versehen, das die meisten kommerziellen GIS-Pakete in ihrer Funktionsbreite übertrifft.
Erstens, OSM-Import. Die heruntergeladene .osm.pbf-Datei lässt sich in QGIS direkt über Layer → Datenquellen-Manager → Vektor einbinden, ist aber bei größeren Extracts träge. Empfehlenswerter ist ein vorgeschalteter Filter- und Konvertierungsschritt mit dem Kommandozeilen-Tool osmium-tool: osmium tags-filter input.osm.pbf nwr/highway nwr/waterway -o filtered.osm.pbf reduziert den Datensatz auf die Layer, die für eine topographische Karte tatsächlich gebraucht werden, und beschleunigt den späteren Render-Vorgang um Faktor 5 bis 10.
Zweitens, Symbolisierung. Hier kommt der eigentliche kartografische Anteil ins Spiel. QGIS unterstützt zwei Wege zur Symbolisierung: manuell über das Eigenschaften-Fenster jedes Layers, oder über importierte QML-Stylesheets. Wer die Arbeit nicht mehrfach machen will, lädt sich von GitHub ein gepflegtes Stylesheet-Repo herunter. Das qgis-osm-style-Repo von Klas Karlsson (Update zuletzt März 2026) ist ein solider Ausgangspunkt; das ältere OSM-Bright-Style von Mapbox lässt sich mit dem Konverter-Skript mapbox-style-qml.py (auf GitHub verfügbar) in QGIS-kompatibles QML übersetzen.
Eine Bemerkung zur kartografischen Hierarchie: Die Standardfehler bei selbst gerenderten Karten liegen fast immer in der visuellen Hierarchie. Zu kräftige Straßenlinien, zu blasse Höhenlinien, zu viele Beschriftungen in zu kleinem Schriftgrad. Eine brauchbare Faustregel: Hauptstraßen 0,8 mm Strichstärke im Druckmaßstab, Nebenstraßen 0,4 mm, Wege 0,2 mm, Höhenlinien (Haupt-) 0,3 mm, Höhenlinien (Zwischen-) 0,15 mm, Beschriftungen mindestens 6 pt (Wegnamen) bis 14 pt (Ortsnamen). Wer das einmal kalibriert hat, hat eine Karte, die lesbar ist.
Drittens, Print Composer Layout (in QGIS 3 Layoutmanager). Das eigentliche Layout-Werkzeug. Hier wird der Druckrahmen aufgesetzt, der Kartenausschnitt im gewünschten Maßstab (etwa 1:25.000 für Wanderkarten, 1:50.000 für regionalen Überblick, 1:10.000 für Geländedetails) platziert, und es werden die kartografischen Pflichtelemente eingefügt: Maßstabsleiste (typisch dreiteilige Skala mit 0/500/1000/2000 m Marken bei 1:25.000), Nordpfeil, Legendenkasten, Quellenangabe.
Die Lizenz-Pflichten der OSM-Daten (ODbL, Open Database License) verlangen eine Quellenangabe der Form „© OpenStreetMap-Mitwirkende, ODbL” auf jeder veröffentlichten Karte. Wer das vergisst, verstößt – auch im privaten Druck, sobald die Karte weitergegeben wird.
Render-Performance: PostGIS und Vector-Tiles
Bei größeren Gebieten – sagen wir einer kompletten Wanderregion von 50 × 50 km im Maßstab 1:25.000 – wird die Render-Performance von QGIS schnell zur Engstelle. Hier hilft eine vorgelagerte PostGIS-Datenbank.
Der Workflow: Mit osm2pgsql wird der OSM-Extract in eine PostgreSQL-Datenbank mit PostGIS-Extension importiert. Befehl in seiner einfachsten Form: osm2pgsql -d osm -U osm -W -S default.style germany-latest.osm.pbf. Auf einem mittelschnellen Laptop (16 GB RAM, SSD) dauert der Import des Deutschland-Extracts etwa 90 Minuten. Das Ergebnis ist eine indizierte Datenbank, aus der QGIS Layer-Anfragen in Millisekunden bedient – statt der Sekunden bis Minuten, die der direkte PBF-Zugriff braucht.
Für Web-Ausgabe (zur Vorschau am Bildschirm oder für eine begleitende digitale Karte) empfiehlt sich zusätzlich das Vorrendern in Vector-Tiles mit tippecanoe, dem von Mapbox entwickelten und seit 2024 unter dem Felt-Dach weitergepflegten Tool. Tippecanoe nimmt eine GeoJSON- oder FlatGeobuf-Datei und erzeugt daraus ein .mbtiles-Archiv – einen SQLite-Container mit allen Zoom-Stufen vorgerechnet. Der typische Aufruf für eine Topo-Region: tippecanoe -o region.mbtiles -z 16 -Z 10 region.geojson, der die Zoomstufen 10 bis 16 erzeugt. Render-Zeit für einen Bundesland-Auszug: 2 bis 4 Stunden, einmalig.
Wer die Vector-Tiles dann lokal anzeigen will, nutzt einen kleinen TileServer (tileserver-gl-light, martin, oder den eingebauten tileserver-gl), der auf Port 8080 die Tiles ausliefert. Datenpfad bleibt vollständig lokal, keine Cloud, keine externen Anfragen.
Ausgabe als PDF
Aus dem QGIS-Layout-Manager lässt sich die fertige Karte als PDF exportieren, mit allen Pflichtelementen, in der gewählten Druckauflösung (300 dpi für Plotter-Druck, 600 dpi für hochwertige Reproduktionen). Eine 1:25.000-Karte im DIN A2-Format (420 × 594 mm) bei 300 dpi ergibt eine PDF-Datei von typisch 60 bis 120 MB, je nach Detailfülle.
Wer den Plotter-Druck nicht selbst hat: Kommerzielle Plot-Services für Architektur und Vermessung (Repromax, Reprolux und vergleichbare Anbieter) drucken im Format A2 oder A1 zu Preisen zwischen €12 und €25 pro Karte, mit Lieferzeit von 1 bis 3 Werktagen.
Eine Alternative: PrintMaps
Wer den vollen QGIS-Workflow nicht aufsetzen mag, sich aber dennoch lokal eine gute Topo-Karte rendern will, der findet in PrintMaps von Klaus Tockloth (auf GitHub verfügbar, Stand März 2026 in Version 5.3) eine ausgereifte Open-Source-Lösung. PrintMaps ist eine REST-API in Go, die OSM-Daten lokal entgegennimmt und über einen mitgelieferten Mapnik-Renderer ein PDF erzeugt. Konfiguration erfolgt über YAML-Dateien, in denen Stiloptionen, Layout und Quellenangabe festgelegt werden. Output-Format: PDF mit eingebetteten Vektoren, kein Bild-Embedding. Druckqualität ist exzellent.
Lizenz: ODbL und die CC-BY-SA-Klausel
Ein Punkt, der gerne unterschätzt wird: Die OSM-Daten stehen unter der Open Database License (ODbL) 1.0, einer Lizenz, die zwei Pflichten festlegt. Erstens: Quellenangabe (Attribution). Zweitens: Share-Alike, also die Pflicht, abgeleitete Datensätze unter der gleichen Lizenz zu veröffentlichen. Für die kartografische Darstellung – das eigentliche Druckbild – gilt zusätzlich die CC-BY-SA-Klausel, die eine namentliche Nennung der OSM-Mitwirkenden verlangt.
Konkret heißt das für eine selbst gerenderte Karte, die man druckt und verteilt: Im Kartenrand muss die Formel „Karte: © OpenStreetMap-Mitwirkende, ODbL 1.0” oder eine vergleichbare Wendung erscheinen. Bei einer privaten Karte, die man nur selbst nutzt, ist die Pflicht weicher, aber spätestens beim Teilen mit Dritten greift die Lizenz. Wer ergänzend BKG-Daten verwendet, muss die Formel „© GeoBasis-DE / BKG 2026, dl-de/by-2-0” hinzufügen, und bei DGM-Daten der Landesvermessungen die jeweilige Quelle.
Warum Vermesser heute selbst rendern
Drei Gründe, in der Praxis dokumentiert. Erstens, Aktualität. Eine 2024 gedruckte ADAC-Wanderkarte enthält Wegdaten, die im Herbst 2023 letztmals editiert wurden. Eine selbst aus aktuellem OSM-Extract gerenderte Karte enthält Wegdaten, die im Mai 2026 noch vorgestern aktualisiert wurden, weil die OSM-Community sehr schnell auf Veränderungen vor Ort reagiert.
Zweitens, Maßstabs-Freiheit. Kommerzielle Karten werden in festen Maßstäben verlegt. Wer eine 1:18.000-Karte braucht, weil das Arbeitsgebiet so groß ist, dass 1:25.000 zu detailarm wird, aber 1:10.000 zu großformatig, der findet keine kommerzielle Lösung. Selbst rendern ist die einzige Option.
Drittens, Datensatz-Eigentum. Vermesser, die regelmäßig Außendienst-Karten erstellen, bauen sich über die Jahre einen Bestand an gepflegten QGIS-Projekten und Stylesheets auf, der mit jedem Druck reichhaltiger wird. Eine kommerzielle Karte ist ein Verbrauchsgut. Ein eigenes Stylesheet, einmal kalibriert, ist ein Werkzeug, das mit der Praxis wächst.
Wer den Workflow einmal beherrscht, kehrt selten zu den Verlagsprodukten zurück. Nicht weil sie schlecht wären – sie sind oft solide gemacht – sondern weil das eigene Rendering eine Karte erzeugt, die den eigenen Arbeitszweck genau trifft. Und das ist, am Ende, was eine gute Karte ausmacht.