OpenStreetMap on Mein Blog

QGIS: "Traveling Salesman"-Routing mit den ORS Tools

Fri, 18 Jul 2025 17:51:00 +0200

Im Umfeld von OpenStreetMap kommt es immer wieder mal vor, dass man eine Reihe von Objekten erkunden möchte, z.B. alle seit Jahren nicht mehr überprüften Geschäfte einer Stadt. Es ist recht einfach, solche Objekte aus der OSM-Datenbank zu extrahieren. Einen GPX-Track zu erstellen, mit dem man alle gefundenen Objekte auf optimale Weise abfahren kann, ist dagegen recht mühsam. Diese Aufgabenstellung, also den optimalen Weg zu ermitteln, auf dem eine Menge von geografischen Punkten besucht werden kann, wird Traveling Salesman Problem genannt, auf deutsch Problem des Handlungsreisenden. Das Problem kann im Prinzip nur durch Ausprobieren aller Möglichkeiten gelöst werden, so dass der Aufwand mit der Zahl der Punkte exponentiell ansteigt. Die meisten verfügbaren Lösungen sind daher nicht perfekt, aber für den Hausgebrauch ausreichend. Neben OsmAnd und QMapShack bietet openrouteservice.org über sein API ein Traveling-Salesman-Routing an. Dieses kann auch über das QGis-Plugin ORS Tools genutzt werden.

Analyse der OSM-Historie nach Benutzer und Attributen

Thu, 08 Jul 2021 09:12:43 +0200

Extrahieren von Objekten anhand der Tag-Historie

Mit dem Werkzeug osmium-tool kann man OSM-Extrakte nach Schlüssel/Wert-Kombinationen filtern. Das funktioniert auch mit History-Dateien. Dabei werden alle Objekte herausgefiltert, bei denen es mindestens eine Version mit der gesuchten Schlüssel-Wert-Kombination gibt. Auf diese Weise ist es z.B. möglich, alle Objekte zu extrahieren, bei denen der Wert eines Schlüssel in der Versionshistorie des Objekts in einer bestimmten Weise geändert wurde, z.B. von highway=track auf highway=service|unclassified|tertiary:

# Create data file from history file to ensure consistency between data and history files:
osmium time-filter extract.osh.pbf -o extract.osm.pbf

# Get all ways with highway=track in any version 
# (Discard nodes in the first step in order to eliminate nodes that are no longer part of the current versions of the ways)
osmium tags-filter --omit-referenced extract.osh.pbf w/highway=track -o track-w.osm.pbf
osmium getid --id-osm-file track-w.osm.pbf --add-referenced extract.osm.pbf -o track.osm.pbf

# Keep only ways that are now service,unclassified or tertiary:
osmium tags-filter track.osm.pbf w/highway=service,unclassified,tertiary -o no-track.osm

Die Datei no-track.osm kann mit JOSM geöffnet werden.

GPX-Track auf OpenStreetMap-Karte anzeigen und ausdrucken

Tue, 09 Jul 2013 08:49:01 +0200

Es gibt eine Reihe von Tools und Online-Diensten, mit denen man GPX-Tracks auf einer OpenStreetMap-Karte anzeigen kann: QLandkarteGT, GpsPrune, gpsies.com,... Beim Ausdrucken bzw. Erzeugen einer Vektorgrafik stößt man allerdings schnell an Grenzen. Die Darstellung der Tracks (Farbe, Breite, Transparenz) ist nicht konfigurierbar und der Zoomlevel wird anhand des Kartenausschnitts gewählt, usw. Dieses Video hat mir einen Weg zur Lösung aufgezeigt: Quantum GIS (QGIS) mit OpenLayers-Plugin.

OpenLayers-Plugin

Installation

Das OpenLayers-Plugin ermöglicht es, OSM-Kacheln und Kacheln aus anderen mit OpenLayers darstellbaren Quellen (Google, Bing) in einem QGIS-Layer anzuzeigen. Dazu muss zunächst das Plugin installiert werden. Bis QGIS 1.8 funktioniert das problemlos mit mit dem Plugin Installer. Zunächst muss im Menü "Erweiterungen" der Plugin Installer installiert werden, dann kann mit diesem das OpenLayers-Plugin installiert werden. QGIS 1.9/2.0 ist mit dem Plugin nicht kompatibel. Es existiert aber ein Workaround, der hier beschrieben ist: [node:254].

Layer hinzufügen

Danach erscheint im Menü "Erweiterungen" ein Untermenu "Openlayers Plugin", über das eine Kachelquelle ausgewählt und mit einem Layer verknüpft werden kann. Die Kacheln werden entsprechend dem Zoomlevel geschrumpft bzw, gedehnt, was zu einer unscharfen Darstellung führt. Ein Workaround besteht darin, den Maßstab explizit so einzustellen, dass die Kacheln in Original-Auflösung angezeigt werden. Stellt man den Maßstab 1:2257 ein, erhält man die Kacheln des Zoomlevels 18. Durch Zoomen mit der Maus bekommt man dann die Kacheln in den OSM-Zoomleveln angezeigt.

Weitere Kachelquelle hinzufügen

Eine zusätzliche Kachequelle kann auf einfache Weise Hinzugefügt werden. Im Verzeichnis ~/.qgis2/python/plugins/openlayers_plugin/html existiert für jede Kachelquelle eine HTML-Datei, die den Javascript-Code enthält, mit dem der entsprechende OpenLayers-Layer erzeugt wird. Man erstellt nun eine Kopie einer dieser Dateien und passt den Code entsprechend an. Für OSM-kompatible Kachelquellen genügt es in der Regel, die Datei osm.html zu kopieren und den URL anzupassen. Anschließend muss noch in ~/.qgis2/python/plugins/openlayers_plugin/openlayers_plugin.py, etwa bei Zeile 120, ein Eintrag für die neue Kachelquelle nach diesem Muster eingefügt werden: self.olLayerTypeRegistry.add( OlLayerType(self, 'OpenStreetMap', 'osm_icon.png', 'osm.html', True) ) nach einem Neustart von QGIS ist die neue Kachelquelle verfügbar.

Alternative Methode

Ein anderer Weg zur Anzeige der OSM-Kacheln in QGIS ist hier beschrieben.

GPX-Track

Ein GPX-Track kann als Vektor-Layer angezeigt werden:

Menüpunkt Vektorlayer hinzufügen anwählen
im Dialog die GPX-Datei auswählen und öffen
im anschliessenden Auswahlfenster den Layer tracks und ggf. weitere Layer auswählen und mit OK bestätigen
im Layer-Fenster die Eigenschaften der Track-Linie festlegen: Farbe, Breite,...

Karte drucken / Grafik erzeugen

Hierzu wird der Dialog Neue Druckzusammenstellung geöffnet und mit neue Karte hinzufügen ein Kartenauschnit in das Druckblatt eingefügt. Dabei wird der Kartenausschnitt aus dem Hauptfenster übernommen. Dieser kann im Modus Inhalt verschieben nach Belieben gezoomt und verschoben werden Die so erzeugten Ausdrucke haben eine miserable Qualität. Der Zoomlevel der Kacheln wird entsprechend Auflösung des Ausdrucks und der Größe des Kartenauschnitts automatisch gewählt. Dann werden die Kacheln skaliert um den gewählten Kartenausschnitt zu erhalten. Das Ergebnis ist in den meisten Fällen ziemlich unscharf und für den Druck in der Regel nicht verwendbar. Durch geeignete Wahl der Druckgröße und des Maßstabs des Kartenausschnitts kann man trotzdem eine akzeptable Bildqualität erreichen. Beispiele:

Format	Auflösung (dpi)	Maßstab	Zoomlevel
A4	300	57250	15
A4	150	57250	14
A4	72	57250	13
A1	72	57.250	13
A1	72	144.448	12
A1	300	144.448	14
A1	300	2.311.168	10
A1	72	577.792	10

Das beste Ergebnis erziele ich allerdings mit einer Bildschirmkopie, da die Kacheln auf dem Bildschirm unskaliert dargestellt werden.

Mapping Party in Collioure

Tue, 28 May 2013 21:17:24 +0200

Am 1. Juni 2013 organisieren Annexe21, Perpinux und die OpenStreetMap-Mapper des Departements Pyrénées-Orientales eine Mapping Party in à Collioure. Alles weitere auf https://annexe21.net/cartopartie2013

PostGIS: Daten für den Renderingprozess vorbereiten

Wed, 30 Jan 2013 22:10:31 +0100

Die nachfolgende Anleitung gilt für Debian Wheezy (Stand 01/2013)

Anlegen der PostGIS-Datenbank

Installation der PostgreSQL-Pakete:

aptitude install postgresql-9.1 postgresql-9.1-postgis postgresql-contrib-9.1 postgis

Installation des Pakets postgis. Wheezy enthält PostGIS 1.5. Wenn, wie in meinem Fall, Funktionen benötigt werden, die erst ab PostGIS 2.0 verfügbar sind, kann diese Version problemlos aus den Quellen installiert werden.

Anlegen eines Users und einer Datenbank. Als Superuser:

su - postgres
createuser <username>
Soll die neue Rolle ein Superuser sein? (j/n) j
#psql --command "ALTER USER <username> WITH SUPERUSER";
psql --command "ALTER USER <username> WITH ENCRYPTED PASSWORD 'osm'";

Als User <username>:

createdb osm
psql -d osm --command "CREATE EXTENSION hstore;"
#createlang plpgsql osm
psql -d osm -f /usr/share/postgresql/9.1/contrib/postgis-1.5/postgis.sql
psql -d osm -f /usr/share/postgresql/9.1/contrib/postgis-1.5/spatial_ref_sys.sql

Importieren der OpenStreetMap-Daten mit osm2pgsql

Mit Osm2pgsql können OpenStreetMap-Daten in eine PostGIS-Datenbank importiert werden. Im Wesentlichen werden dabei die OSM-Objekte (Ways, Nodes, Relations), ihre Attribute (Tags) und Geometrie in Datenbanktabellen übernommen. Nodes werden nach planet_osm_nodes, Ways nach planet_osm_line und geschlossene Ways nach planet_osm_polygon importiert. Welche Attribute übernommen werden sollen, wird in einer Konfigurationsdatei (Import Style) festgelegt. Relationen vom Typ Multipolygon, Boundary und Route werden nach planet_osm_rels importiert. In diese Tabelle werden nur die Attribute der Relation und Verweise auf ihre Members eingetragen. Über die Konfigurationsdatei kann festgelegt werden, dass für Relationen mit bestimmten Attributen auch die Geometrie nach planet_osm_polygon bzw. planet_osm_line importiert werden. Daten importieren:

osm2pgsql -c -m -s -d osm -U <username> -W -H localhost --bbox <bbox> <osmdatei>

<osmdatei> ist die Datei OSM-Format (.osm, .osm.bz2 ou .pbf), welche die zu importierende Daten enthält.

Nachbearbeiten der importierten Daten

Die mit osm2pgsql und dem Default-Importstyle erzeugte Datenbank enthält alle Daten, die man für das Rendern einer Karte im OSM-Mapnik-Standard benötigt. Für einen Karte in einem davon wesentlich abweichenden Stil kann es sinnvoll bzw. notwendig sein, die importierten Daten mit SQL nachzubearbeiten. Ein einfaches Anwendungsbeispiel ist das Ersetzen der Werte "yes", "true", "1" durch "yes", um Abfragen in Mapnik oder Tilemill zu vereinfachen:

UPDATE planet_osm_line 
    SET  tunnel = (CASE WHEN tunnel IN ('yes','true','1') 
                        THEN 'yes'::text 
                        ELSE tunnel::TEXT 
                        END);

Dies kann natürlich auch in der Datenbankabfrage in Mapnik/Tilemill gemacht werden. Erledigt man das bereits im Vorfeld, dann werden die Abfragen in Mapnik/Tilemill kompakter und lesbarer. Komplexere Anwendungsfälle werden in einem separaten Beitrag behandelt.

Rendern und Veröffentlichen einer OSM-Karte - Auswahl der Werkzeuge

Wed, 30 Jan 2013 16:45:33 +0100

In diesem und den folgenden Beiträgen beschreibe ich meine Erfahrungen mit dem Rendern und Veröffentlichen einer Karte auf der Basis der OpenStreetMap-Daten.

Anforderungen und Randbedingungen

Ausgangspunkt waren folgende Randbedingungen:

Die Karte soll ein Gebiet von mindestens 80 km2 abdecken, mit den Zoomleveln von 12 bis 18
Die Karte soll auf einer Webseite veröffentlicht werden. Der Kostenrahmen liegt bei < 5 Euro pro Monat.
Arbeitsumgebung ist Linux (Debian Wheezy)
Freie Gestaltung des Kartendesigns, insbesondere soll es möglich sein, parallel versetzte Linien zu rendern, z.B. für straßenbegleitende Radwege und -spuren.

Auswahl der Tools

Für das Rendern der Karte standen Maperitive und Mapnik zur Auswahl. Da Mapnik grundsätzlich den Einsatz einer PostGis-Datenbank erfordert und mir dies zu aufwändig erschien und zudem der erste Versuch einer PostGis-Installation scheiterte, habe ich zunächst Maperitive eingesetzt, weil es direkt mit den OSM-Daten im OSM-XML-Format arbeitet. Maperitive ist eine .Net-Anwendung, lässt sich aber unter Linux mit Mono installieren und betreiben. Die Performance ist weniger gut als unter Windows aber auf meinem Phenom II X2 sind die Reaktionszeiten beim interaktiven Arbeiten im akzeptablen Bereich. Unschön ist allerdings, dass Schriften unter Linux auf Grund einer Einschränkung von Mono nicht immer sauber gerendert werden. Der große Vorteil von Maperitive ist die integrierte Entwicklungsumgebung, mit der Änderungen in den Stil-Dateien ohne große Verzögerung in die gerenderte Karte übernommen werden. Mit den zahlreichen verfügbaren Beispiel-Stilen kann auf diese Weise in kurzer Zeit eine individuelle Karte erzeugt werden. Ebenfalls von Vorteil sind die vielen grafischen Gestaltungsmöglichkeiten, z.B. zum Erzeugen von Mustern und Symbolen. Trotzdem war ich mit dem Endergebnis nicht zufrieden, das Kartenbild machte irgendwie einen unprofessionellen Eindruck. Das soll nicht als Kritik an Maperitive verstanden werden, möglicherweise habe ich zu früh auf andere Tools umgeschwenkt. Vor dem Umstieg auf Mapnik musste zunächst PostgreSQL und PostGis installiert werden. Das geht recht einfach, da hierfür Debian-Pakete existieren. Wheezy enthält PostGIS 1.5., wegen eines Versuchs mit der Funktion ST_UnaryUnion habe ich nachträglich PostGIS 2.0 aus den Quellen installiert. Obwohl diese Funktion letzendlich nicht verwendet wird, bin ich bei 2.0 geblieben. Schwieriger war der Import der OSM-Daten in die PostGIS-Datenbank. Das lag hauptsächlich daran, dass ich das Tool osm2pgsql erst nach ein paar Fehlversuchen mit anderen Tools gefunden habe. Beim anschließenden Test der damit erzeugten Datenbank mit QGis habe ich festgestellt, dass sich dieses mit der neuen Symbologie hervorragend zum Rendern einsetzen lässt. Leider unterstützen die Tools zum Erzeugen von TMS-Kacheln nicht die neue Symbologie, so dass diese Spur nicht weiter verfolgt wurde, aber langfristig könnte dies eine komfortable Lösung sein. Mapnik ist in Debian Wheezy in der Version als Paket in der Version 2.0 verfügbar und funktioniert ohne Probleme. Da ich zum Rendern parallel versetzter Linien den LineSymbolizer-Parameter offset benötige, der erst in Mapnik 2.1 verfügbar ist, habe ich die Version 2.1. aus den Quellen installiert. Das Arbeiten mit dem XML-Format der Mapnik-Stildateien ist recht mühsam, da es keinerlei Möglichkeit von Verschachtelung oder Vererbung gibt. Das bläht die Datei enorm auf, sie wird unübersichtlich und fehleranfällig. Ich habe mich nach Alternativen umgeschaut und bin zunächst auf Cascadenik gestoßen, das mit Stylesheets in CSS-Syntax arbeitet. Obwohl die Arbeit mit Cascadenik sehr positiv verlief, bin ich nach kurzer Zeit auf Tilemill umgestiegen, welches mit einer ähnlichen Stil-Syntax arbeitet. Für die Veröffentlichung habe ich mich für OpenLayers entschieden. Es hätte aber genau so gut Leaflet sein können. Somit ergibt sich die folgende Tool Chain:

Importieren der OSM-Daten nach PostGIS mit osm2pgsql
Nachbearbeiten der PostGIS-Daten
Rendern der Karte mit Tilemill
Anzeige der Karte mit OpenLayers

Erstellen eines GPX-Tracks aus einer OSM-Relation (Perl-Skript)

Fri, 03 Sep 2010 10:00:53 +0200

In der OpenStreetMap-Datenbank sind viele Wanderwege und Radtouren als Relationen erfasst. Dieses Perl-Skript erzeugt aus einer solchen Relation einen GPX-Track für die Verwendung in einem GPS-Navigationsgerät. Daneben werden viele nützliche Informationen ausgegeben, die als Grundlage für eine Verbesserung der Relation in der OSM-Datenbank dienen können. Die meisten Touren sind nicht vollständig erfasst sondern in Teilsegmenten mit mehr oder weniger großen Lücken dazwischen. Das Skript versucht die Teilsegmente nach Möglichkeit vernünftig zu sortieren. Das Skript berücksichtigt auch Kreisverkehre, die in OSM mit "roundabout" getaggt sind. Diese geschlossenen Wege können nicht direkt in den GPX-Track übernommen werden. Sie werden deshalb durch einen Weg quer über den Kreisverkehr ersetzt. Am Ende der der Bearbeitung wird eine Liste der Teilsegmente mit statistischen Daten ausgegeben. Dies gibt bereits einen Hinweis auf die Qualität des erzeugten Tracks. In vielen Fällen ist trotzdem eine manuelle Nachbearbeitung erforderlich. Optional wird eine HTML-Datei erzeugt. Diese Datei enthält die statistischen Daten der Segmente (Länge, Abstand zum nächsten Segment) und für jedes Segment einen JOSM-Remotecontrol-Link. Ein Klick auf diesen Link öffnet in JOSM den Bereich, in dem sich das Ende des Segments und der Beginn des folgenden Segments befinden, zur Bearbeitung. Das Skript gibt auch eine Reihe von Hinweisen auf Probleme mit der Relation, wie z.B. doppelte Punkte und Wege. Installation

Voraussetzungen:
- Perl muss installiert sein
- Benötigte Module: LWP::Simple, IO::Scalar, XML::Parser, Math::Trig
- Ab Version 0.2 wird für den Zugriff auf lokale XML-Dateien das Modul OSM::osm.pm benötigt. Dieses kann von https://wiki.openstreetmap.org/wiki/Osm.pm heruntergeladen werden. Das Modul muss in einem der Perl-Modul-Verzeichnisse im Unterverzeichnis OSM installiert werden. Eine Liste dieser Verzeichnisse kann mit perl -V ausgegeben werden. Alternativ kann man das Modul in einem Benutzerverzeichnis installieren und dies beim Perl-Aufruf mit der Option -I angeben (ohne /OSM).
Die angehängte Datei herunterladen und entpacken.
Unter Linux: Datei in einem Verzeichnis aus PATH ablegen oder explizit mit perl pfad/rel2gpx.pl aufrufen

Bedienung

Aufruf: rel2gpx {optionen} {Relation-Id}
Parameter und Optionen:

Relation-Id
Id der zu bearbeitenden Relation. Siehe auch Option -f

-i datei
Lese OSM-Daten aus lokaler Datei. Wenn diese Option nicht angegeben wird, dann werden die Daten von openstreetmap.org geladen

-x datei
schreibe eine XML-Datei im osm-Format, welche die Daten aller Objekte der Relation enthält (nur zusammen mit -i).

-r typ
Bearbeite alle Relationen mit type=route und route=typ (nur zusammen mit -i). Mögliche Werte für typ: bicycle, hiking, train.

-f datei
Lese Relation-Ids aus der Datei (nur zusammen mit -i). In der Textdatei kann pro Zeile eine Id angegeben werden. Zeilen, die mit "#" beginnen, werden nicht ausgewertet. Auch in den Datenzeilen können Kommentare eingefügt werden.

-g
Erzeuge eine GPX-Trackdatei

-p
Aktiviere die Ausgabe diverser Plausibilitätsprüfungen

-s
Aktiviere Statistikausgaben auf STDOUT

-w
Ausgabe von Statistikdaten und Plausibilitätshinweisen in eine HTML-Datei

-o
Berücksichtigen der Fahrtrichtung (oneway, forward/backward).
Der Name der GPX- und HTML-Datei wird aus dem Namen der Relation in der OSM-Datenbank gebildet. Existiert dieser nicht, wird die Relation-Id als Name verwendet. Bei Verwendung der Optionen -f oder -i wird der Dateiname aus dem Namen der Relationsliste bzw. der Osm-Datei gebildet.

Download
rel2gpx_v027.tgz rel2gpx_v026.tgz