PostGis

In der OpenStreetMap-Datenbank sind die Informationen über Verwaltungseinheiten (Gemeinden, Kreise, Länder) meist auf die Grenzrelation und den Knoten mit der Rolle admin_centre verteilt. Will man zum Rendern der Grenze oder Fläche einer Verwaltungseinheit auf Informationen zurückgreifen, die beim Knoten gespeichert sind, z.B. das Attribut population oder name:xx, dann stellt man fest, dass üblichen Werkzeuge diese Informationen nicht bereit stellen. Nachfolgend werden Methoden beschrieben, wie man dieses Problem bei mit osm2pgsql erstellten Datenbanken und bei aus OSM erzeugten Shape-Dateien lösen kann. PostGis / osm2pgsql osm2pgsql überträgt zwar Attribute der äußeren Wege, also der Wege mit Rolle outer, auf das für die Relation erzeugte Polygon, für den Knoten mit der Rolle admin_centre wird nichts vergleichbares gemacht. Es wird auch kein Link vom Polygon zum Knoten erzeugt. Die im Slim-Modus von osm2pgsql erzeugte Tabelle <prefix>_rels enthält zwar in der Spalte members sämtliche Mitglieder der Relation und deren OSM-ID, aber leider in einer nicht direkt und effizient mit SQL auswertbaren Form. Beispiel: psql -d osm -c "select members from planet_osm_rels\ where hstore(tags)->'name'='Corneilla-la-Rivière';" members ---------------------------------------------------------------------------- {w121772197,outer,w100006391,outer,w121772204,outer,n287557758,admin_centre} Die Member der Relation werden also in einem Array abgelegt, zwei aufeinander folgende Array-Elemente pro Member. Mit einer kleinen Funktion kann man die Node-Id des Admin_Centre extrahieren: CREATE OR REPLACE FUNCTION admin_centre(anyarray) RETURNS bigint LANGUAGE sql AS $function$ SELECT cast(substring($1[i] from 2) as bigint) FROM generate_series(array_lower($1,1),array_upper($1,1),2) i WHERE $1[i+1]='admin_centre';$function$ Damit kann man nun die Polygone der Verwaltungsgrenzen zusammen mit den Attributen des Admin_Centre abfragen: select poly.name, point.name, point."name:ca", point.population from planet_osm_rels r, planet_osm_polygon poly, planet_osm_point point where poly.admin_level='8' and admin_centre(r.members) = point.osm_id and r.id = -poly.osm_id ; Je nach Anwendungsfall und Performanceanforderung kann man damit auch die benötigten Attribute in die jeweils andere Tabelle übertragen oder eine Tabelle mit der Zuordnung von Knoten zu Relationen erstellen: create table admin_rel as select -id as rel_id, admin_centre(members) as admin_centre from planet_osm_rels where hstore(tags)->'boundary'='administrative' and hstore(tags)->'admin_level' in ('8','6','4'); Shape-Dateien Hierfür wird die Osmium-Bibliothek, das darauf basierende Javascript-Tool osmjs und QGis benutzt. Mit osmjs können auf einfache Weise Shape-Dateien aus den Objekten einer OSM-Datei zu erzeugt werden. Wie bei osm2pgsql werden dabei zwar Polygone aus Grenzrelationen erstellt, aber ohne Bezug zum admin_centre. Es ist jedoch möglich, eine CSV-Datei zu erstellen, welche diesen Bezug enthält: /* Osmium Javascript Example: shape_export.js run with: osmjs -2 -m -l sparsetable -j shape_export.js OSMFILE */ var shp_places = Osmium.Output.Shapefile.open('./places', 'point'); shp_places.add_field('id', 'string', 12); shp_places.add_field('type', 'string', 32); shp_places.add_field('name', 'string', 32); var shp_boundaries = Osmium.Output.Shapefile.open('./boundaries', 'polygon'); shp_boundaries.add_field('id', 'integer', 10); shp_boundaries.add_field('type', 'string', 32); shp_boundaries.add_field('boundary', 'string', 255); shp_boundaries.add_field('admin_level', 'string', 255); var csv_file = Osmium.Output.CSV.open("./rels.csv"); var node_tags = { place: { village: 'villaget', city: 'city', town: 'town'} //, //shop: { supermarket: 'supermarket' } } Osmium.Callbacks.init = function() { print("Init"); } Osmium.Callbacks.node = function() { for (var key in this.tags) { if (node_tags[key]) { var type = node_tags[key][this.tags[key]]; if (type) { shp_places.add(this.geom, { id: this.id, type: type, name: this.tags.name }); } } } } Osmium.Callbacks.area = function() { if (this.tags.boundary) { shp_boundaries.add(this.geom, { id: this.id, type: this.tags.boundary, admin_level: this.tags.admin_level}); } } Osmium.Callbacks.relation = function() { for (var key in this.members) { for (var key2 in this.members[key]) { if (key2=='role' && this.members[key].role=='admin_centre'){ csv_file.print(this.id*2+1, this.members[key].ref, this.members[key].role, this.members[key].type); } } } } Osmium.Callbacks.end = function() { shp_places.close(); shp_boundaries.close(); csv_file.close(); print("Done"); } Das Skript erstellt eine Shape-Datei mit den Grenzpolygonen, eine Shape-Datei mit den Place-Knoten und eine CSV-Datei, welche die Ids der Grenzpolygone und der zugehörigen Place-Knoten enthält. Dabei wird berücksichtigt, dass osmjs den Polygonen eine Pseudo-ID mit dem Wert [2 * OSM-ID der Relation + 1 zuweist. Diese drei Dateien lädt man als Layer in QGis. Dann verknüpft man den CSV-Daten-Layer über die Knoten-ID mit dem Knoten-Layer und anschliessend den Polygon-Layer über die Pseudo-ID mit dem Knoten-Layer. Will man die Daten mit Tilemill / Mapnik verenden, kann man die Polygon-Layer als Shape-Datei speichern.

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.

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