Das Darstellen von Landkarten in einem WordPress-Blog funktioniert am einfachsten als Bild – wie ein herkömmliches Foto. Das mag eigenartig klingen, ist aber in vielen Fällen für die Anforderung ausreichend. Es muss kein Plugin installiert werden und auch die Ladezeit der Seite wird nicht beeinflusst.

Möchte man aber eine Karte haben, die stets auf dem aktuellen Stand ist und auch Navigieren und Zoomen in der Karte erlaubt, dann muss eine Plugin installiert werden.  WordPress unterstützt ohne Erweiterung das Einbinden von Kartendiensten (z.B. OpenStreetMap, OpenSeaMap …) nicht.

Die Qual der Wahl

Sucht man im WordPress Plugin Directory nach „map“, dann erhält man als Resultat mehr als 1.000 Plugins – spätestens jetzt sollte man ein Bier öffnen. Die meisten Ergebnisse konzentrieren sich auf Karten mit strengen Lizenzen und laden zusätzlich Softwarekomponenten von Drittherstellern oder sind nur eine Lite-Version mit starken Einschränkungen. Häufig wird für die volle Funktion auf eine  kostenpflichtige Pro-Version verwiesen.
Im Jahr 2004 hatten wir nach einem Karten-Plugin für das offene Fotoprojekt www.Fotomobil.at gesucht. Anforderungen waren:

• eine Karte mit freier Lizenz
• Open-Source-Plugin ohne externe SW Komponenten
• kostenlos, da kein Budget
• eigene Daten per Standardformat in der Karte darstellen

Zu diesen Anforderungen gab es kein Plugin, also haben wir mit der Entwicklung von WordPress OSM Plugin begonnen. Bald gab es Rückmeldung aus der WordPress-Gemeinschaft und das Plugin wurde über das offizielle WordPress Plugin Directory zur Verfügung gestellt. Steve Coast – der Gründer von OpenStreetMap – kündigt die Version 0.9 des WP-OSM-Plugins auf OpenStreetMap.org an. Das freie Plugin ist unter der GPL lizenziert und wird unter anderem von professionellen Bloggern für Reiseberichte mit Routen, Übersichtskarten oder nur für die aktuelle Position benutzt:

Tigerbus.de von Martin verwendet das WP-OSM-Plugin, um mit GPX-Tracks seine Bulli-Reisen zu zeigen. Die Karte zeigt die Tour und kann über einen Button in den Fullscreen-Modus geschaltet werden.

Screenshot Tigerbus mit Karte und Fotos

Fotomobil.at ist ein offenes Fotoprojekt und verwendet das WP-OSM-Plugin, um den Ort des aktuellen Beitrages zu zeigen. Ein Widget liest die Geodaten automatisch aus und zeigt sie mit dem Marker zum Beitrag an.

Sabine leitet einen Blog, der aktuell ca. 530 verortete Beiträge enthält. Die einzelnen Beiträge stellen Brücken in Hamburg vor. Jeder Beitrag wird automatisch in einer Übersichtskarte mit einem Icon dargestellt. Beim Klick auf das Icon in der Karte wird die Kurzfassung und der Link zum Beitrag in einem Popup gezeigt.

Mapping als Philosophie statt einem Businessplan zu folgen

Es gibt hunderttausende aktive OSM Mapper um den Globus verteilt, mit dem gemeinsamen Ziel einer freien Karte. Das OSM Projekt ist ein Meisterstück der Aussage von Antoine de Saint-Exupery:

Wenn Du ein Schiff bauen willst, dann trommle nicht Männer zusammen um Holz zu beschaffen, Aufgaben zu vergeben und die Arbeit einzuteilen, sondern lehre die Männer die Sehnsucht nach dem weiten, endlosen Meer.

Das WP-OSM-Plugin knüpft daran an und ist als Open Source unter einer freien Lizenz veröffentlicht. Ohne Pro-Version und ohne Businessplan. Das WP-OSM-Plugin ist ein freies Plugin einer freien Karte!

Die Funktionen des WP-OSM-Plugin sind:

• Verorten von Beiträgen und Seiten (Geotagging)
• Anzeige von GPX- und KML-Dateien oder auch nur einfache Marker
• Einfügen von Karten mit shortcode oder mit Widget
• Vollbild-Karte, Karten mit Markern für Beiträge/Seiten mit geotags.
• Verschiedene Karten: OpenStreetMap, OpenSeaMap, Stamen maps, basemap, …
• …

Hast Du jemals daran gedacht ein Foto zu machen, das nur mit WordPress – oder sogar nur mit einem WordPress Plugin – angezeigt werden kann?

Die aktuelle Version des WP-OSM-Plugins verwendet OpenLayers 3 mit Schwerpunkt auf der Darstellung in mobilen Geräten und das Anzeigen von persönlichen Daten in Standardformaten. Hast Du jemals daran gedacht ein Foto nur für WordPress – oder sogar nur ein Plugin in WordPress – zu machen? Warum sollte man es dann für Daten in einer Karte akzeptieren. Evtl möchte man die Karte auch einmal in Joomla darstellen oder einfach nur in einem klassichen alten Fotoalbum. Deshalb sind XML-Dateien wie z.B. GPX und KML eine gute Möglichkeite, um persönliche Daten in einer Karte darzustellen. Man kann nicht nur das Karten-Plugin wechseln, sondern sich auch für ein anderes Content-Management-System entscheiden, ohne die persönlichen Daten zu verlieren.

Das folgende Beispiel zeigt unsere Italienreise mit dem VW Bulli – die Route und Stellplätze sind als KML-Datei eingebracht. Erstellt wurde die Route mit dem freien Editor Viking und Inkscape wurde verwendet, um Vektor-Icons zu erstellen. Das WP-OSM-Plugin bringt aber auch Icons unter CC0 – Lizenz mit. Für das Erstellen der GPX-Datei oder Markerlisten gibt es auch viele freie Onlinedienste. Hat man seine Geodaten als KML oder GPX Datei vorliegen, ist noch darauf zu achten, dass alle Pfadangaben relativ sind, um auch eine sichere Verbindung per HTTPS zu vermöglichen:

[]

Der WordPress-Shortcode sieht für diese Karte wie folgt aus:

[*osm_map_v3 map_center="44,14.4" zoom="6" width="75%" height="450" file_list="../../../../wp-uploads//2015/11/2015_It_Camping_01.kml" control="fullscreen"]

Dieser Shortcode muss nicht händisch erstellt werden, sonder kann mit dem Shortcode-Generator beim Erstellen des Beitrages automatisch erzeugt werden. Man justiert die Karte und klickt dann für das Erstellen des Shortcode in die Karte:

WordPress-OSM-Plugin-Shortcode-Generator

Dateien, die mit einem GPS-Logger oder einem Smartphone erstellt wurden können sehr groß werden und sich negativ auf die Ladezeit der Seite auswirken. Man sollte daher auf Tools wie beispielsweise das großartige GPSBabel zurückgreifen, um die Daten für die Darstellung zu optimieren. Eine Anleitung dazu findet man hier. Und am Schluss sollte man noch sicherstellen, dass alle Marker in den Files auch relativ adressiert werden.

Dein Beitrag beim WP-OSM-Plugin

Das WP-OSM-Plugin hat keine kostenpflichtige Version und man kann auch nicht spenden. Wer aber die Entwicklung unterstützen möchte oder einfach nur motivieren will, der kann:

• Eine Übersetzung korrigieren oder neu erstellen
• Icons unter der CC0-Lizenz zur Verfügung stellen
• Eine Bewertung abgeben: WordPress.org
• Eigene Entwicklungen beim Plugin für alle zur Verfügung stellen.

Links mit Bezug zum WP-OSM-Plugin:

• Download im WordPress Directory
• Blog, Forum and Dokumentation
• WP OSM Plugin @ Twitter
• WP-OSM-Plugin auf facebook
• Privater Blog von MiKa
• Kontakt mit MiKa
• WordPress
• OpenLayers 3

Wichtiges Element der neuen Version ist, dass erstmals ein Feature nicht von mir selbst entwickelt worden ist, sondern von Mmd beigetragen worden ist. An dieser Steller erst einmal ein herzliches Dankeschön dafür.

Es handelt sich dabei um einen neuen Ausgabemodus, „out:csv“. Wie der Name vermuten lässt, gibt eine Abfrage wie

[out:csv(::id,::type,"name")];
area[name="Bonn"]->.a;
( node(area.a)[railway=station];
way(area.a)[railway=station];
rel(area.a)[railway=station]; );
out;


alle Bahnhöfe in Bonn mit ihren jeweiligen Namen als Tabelle aus. So könnten die Daten direkt in LibreOffice übernommen werden. Dabei kann über die angegebenen Parameter in der Klammer gesteuert werden, welche Tags oder Sonderelemente wie Id und Co ausgegeben werden. Es gibt folgende spezielle Bezeichner:

• id
• type
• version
• timestamp
• changeset
• uid
• user
• lat
• lon

Dabei ergeben „lat“ und „lon“ nur dann sinnvolle Angaben, wenn Nodes abgefragt oder der Modus „center“ zur Ausgabe verwendet wird. Weitere einstellbare Parameter sind das Trennzeichen zwischen zwei Datenzellen und ob es Überschriften geben soll.

Der Modus ist aber noch nicht abschließend fertig: CSV ist kein so klar umrissenes Dateiformat wie XML oder JSON. Die Tücke liegt dabei in Detailfragen, z. B. welche Zeichen auf welche Weise escaped werden sollen, ob man Anführungszeichen um Einträge mit Leerzeichen oder gleich für alle Einträge braucht. Oder auch nur, wie Fehlermeldungen eingebaut werden sollen. Daher bitte ich um Rückmeldung, am besten als Issues auf Github, oder als Mail an talk@ oder talk-de@.

Eine weitere große Neuerung ist, dass jetzt auch nach Keys mit regulären Ausdrücken gesucht werden kann:

rel[~"^name"~"^Schweiz$"];
out;

untersucht gleich alle Tags, deren Key mit „name“ beginnt, darauf, ob sie den Wert „Schweiz“ haben – der Wert steht in der Tat hier nur im „name:de“-Tag.

Weitere Verbesserungen sind, dass die Suche nach seltenen Tags auf großen Flächen jetzt schneller geht. Dieser Wunsch kam speziell von den Machern der Wochenaufgabe, und ich erfülle ihn gerne.

Zurück zu den holprigen Umständen der Einführung: wie bei jedem längeren Ausfall der Overpass API möchte ich gerne ein paar Worte zur Erklärung liefern. Dieses Mal hat es nicht einen schicksalhaften Hardware-Ausfall oder äußere Umstände gegeben, sondern schlicht ein gewisses Maß an Ungeschicklichkeit bei mir. Ich muss ein wenig ausholen.

Die Datenbank besteht neben einer großen Menge Dateien vor allem aus zwei Prozessen, „dispatcher“ genannt, die die Schreib- und Lesezugriffe miteinander koordinieren. Damit ist sichergestellt, dass jede Leseabfrage immer den gleichen konsistenten Zustand der Datenbank wie zum Startzeitpunkt sieht, auch wenn in der Zwischenzeit ein Schreibprozess Änderungen geschrieben hat. Es gibt zwei Arten von Schreibprozessen, solche, die die Daten von der Hauptinstanz übernehmen, und den Schreibprozess, der aus den Ways und Relations Areas berechnet. Beide sind voneinander unabhängig und daher gibt es zwei getrennte Dispatcher, die jeweils eine Art von Schreibprozess koordinieren sollen.

Leider habe ich zwar den „dispatcher“ für die Hauptdatenbank richtig konfiguriert, aber dem „dispatcher“ für die Areas irrtümlich mitgegeben, er solle sich auch um Metadaten kümmern. Das hat dann dazu geführt, dass er sämtliche Metadaten gelöscht hat, wann immer er mit den Areas fertig geworden ist. Daher habe ich den letzten erhaltenen vollständigen Stand der Datenbank vom 22. Oktober aus dem Clone zurückkopiert. Leider dauert es dann ungefähr einen Tag, bis die Änderungen aus den letzten 11 Tagen wieder eingepflegt sind. Nun sollte die Overpass API wieder voll einsatzfähig sein, sogar mit erweiterter Funktionalität.

CC-BY 3.0 Constantin Müller (ubahnverleih)

Es gibt zwar gerade kein Hochwasser (das letzte kürzlich in Sachsen und Sachsen-Anhalt war kein großes), aber dennoch wollen wir, angeregt von Constantin Müller (aka ubahnverleih) dazu aufrufen, Pegelmesser zu mappen. Doch lest seinen Aufruf einfach selbst:

Die meisten schauen zwar wahrscheinlich eher online nach aktuellen Pegelständen, trotzdem denke ich dass es interessant sein könnte, die Pegelmesser in der Umgebung zu mappen. (Kann ja sein dass man wirklich mal raus geht um auf den Pegel zu schauen, falls die Wasserstands-Server wegen großer Nachfrage wieder down sind.)

Gemappt wird das ganze mit man_made=monitoring_station und monitoring:water_level=yes – weitere Tags zur genaueren Beschreibung sind im Wiki zu finden. Eine Overpass-Abfrage gibts natürlich auch. Wenn die Pegelstände jetzt noch Open-Data wären, könnte man super Apps draus bauen.

Die folgende  Tabelle werden wir jeden Abend zu unterschiedlichen Zeiten aktualisieren.

Wir wollen den Wochenaufruf als regelmäßige Serie etablieren. Daher suchen wir auch für die kommende Woche wieder einen Wochenaufruf. Wer eine Idee hat, schreibt uns einfach eine Mail. Wir freuen uns besonders über Vorschläge mit vorformulierten Texten.

Am 28. Mai wird die Overpass API ein kleines Jubiläum erreichen: seit dann fünf Jahren versorgt sie die Nutzer von OpenStreetMap mit genau dem Teil der Daten, den sie wollen.

Das tut sie mit durchaus Erfolg: allein im letzten Jahr ist die durchschnittliche tägliche Nutzerzahl von 700 auf 4500 gestiegen (Vergleich März 2012 bis März 2013 gegenüber März 2013 bis März 2014).

Auch die Anzahl der Anfragen ist auf mittlerweile durchschnittlich 180.000 pro Tag gewachsen, die abgefragte Datenmenge auf 45 GB pro Tag.

Kehrseite des Wachstums ist, dass nun doch so langsam die Kapazitätsgrenze der Festplattengeschwindigkeit auf dem Server erreicht ist. Statt den Mangel zu verwalten, würde ich gerne die Kapazität erhöhen: mit einer SSD statt einer traditionellen Festplatte ist etwa eine Verzehnfachung der Kapazität möglich.

Dies schafft dann auch die Kapazitätsreserve, um demnächst auch alte Daten archiviert anbieten zu können und dann endlich unerwünscht gelöschte Daten in der OpenStreetMap-Datenbank leicht wiederfinden zu können.

Das kostet allerdings Geld, auf eine Sicht von 2 Jahren etwa 1300 EUR. Nach Rücksprache mit dem FOSSGIS würde ich gerne im Wege von Spenden an den FOSSGIS

FOSSGIS e.V.
BLZ: 551 900 00
Mainzer Volksbank
Kto.: 415938026
IBAN: DE93 5519 0000 0415 9380 26
BIC: MVBM DE 55

mit Betreff „Overpass API“ dieses Geld sammeln. Für alle, die gerade eine Steuererklärung gemacht haben: Spenden an den FOSSGIS sind nach derzeitigem Stand von der Einkommenssteuer befreit, wenn man sie in der Steuererklärung angibt und eine Kopie des Kontoauszugs beilegt. Ich selbst werde 50 EUR spenden, aber auch eine Spende von 5 EUR finanziert die Erweiterung bereits für 3 Tage.

Sollte mehr Geld zusammenkommen, werden wir den Betrieb der Overpass API einschließlich der SSD-Erweiterung für mehr als zwei Jahre im Voraus finanzieren können. Sollte weniger Geld zusammenkommen, entsprechend kürzer.

Beobachtungen

Wie man im Munin für die Overpass API unter Lese-/Schreibauslastung sehen kann, sind die Festplatten an etwa 16 Stunden des Tages über 95 Prozent aktiv, d.h. an ihrer definitiven Leistungsgrenze.

Ein Testlauf (danke dafür an Malcom Herring) mit einer leider nicht Server-tauglichen SSD hat für das weltweite Auslesen von Seezeichen die Laufzeit von 30 Minuten auf 2 Minuten reduziert. Daher die Hoffnung, dass eine SSD eine Kapazitätserweiterung um den Faktor 10 tatsächlich erbringen kann.

Die Statsitiken zu Nutzerzahl, Datenmenge und Abfragenzahl sind leider etwas schwierig zu lesen, da ich sie nicht groß aufbereite: Der komplette Datensatz wird als JSON übertragen und kann dann client-seitig im Browser untersucht werden.

Mit dem ersten Dropdown-Feld kann gewählt werden, ob alle Abfragen oder nur die auf /api/interpreter bzw. nur die auf /api/xapi usw. berücksichtigt werden. Mit dem nachfolgenden Testfeld kann auf ein einzelnes Land mit ISO-Ländercodes eingeschränkt werden.

Zu „Ltr“ oder „Rtl“ ist etwas mehr Erklärung notwendig: Jedes Diagramm stapelt die Zahlen segmentiert nach total abgefragter Datenmenge pro IP-Adresse pro Tag. So lässt sich unterscheiden, ob sehr viele Nutzer jeweils wenig Daten herunterladen (z.B. eine neue Smartphone-App), sehr wenige Nutzer sehr viele Daten (Massennutzer) oder viele Benutzer mittlere Datenmenge (Wachstum der normalen Nachfrage). Die Stufen sind: unter 1 KB, 1 KB – 10 KB, dann weiter mit Zehnerpotenzen bis 100 MB bis 1 GB, danach über 1 GB. Die graue Kurve zählt z.B. Nutzer, die insgesamt weniger als 1 KB Daten heruntergeladen haben. Die grüne Kurve liegt bei 1 MB bis 10 MB, die rote Kurve kennzeichnet die höchste Stufe über 1 GB. „Ltr“ stapelt klein auf groß, „Rtl“ stapelt groß auf klein.

Mit dem nächsten Zahlenfeld kann man das anzuzeigende Maximum automatisch bestimmen lassen (Wert „0“) oder manuell setzen (anderer Wert). Danach folgen zwei Felder für minimales und maximales Datum. Das letzte Feld erlaubt, über mehr als einen Tag zu mitteln; es wird dann der Mittelwert der letzten entsprechend vielen Tage angegeben. Z.B. habe ich obige Werte mit dem Jahreswert 360 berechnen lassen.

Und eben damit die Kurve auch in Zukunft Wachstum zeigen kann: Vielleicht schaffen wir es ja gemeinsam, zum fünfjährigen Jubiläum die Kapazität per SSD bereits vervielfacht zu haben.

Daten zu OpenStreetMap beitragen ist einfach. Daten von OpenStreetMap zurück zu erhalten ist vergleichsweise kompliziert und aufwändig.[1] Bis jetzt.

overpass turbo

Das Tool overpass turbo erhebt seit etwa einem Jahr [2] den Anspruch, jedem Normal-Mapper eine einfache Möglichkeit zu bieten, direkt auf alle OpenStreetMap-Daten zuzugreifen und damit Visualisierungen, Auswertungen, Analysen, usw. zu erstellen.

Das Tool basiert grundsätzlich auf der sogenannten Overpass API, einer Datenbank speziell für OpenStreetMap, die es mit Hilfe einer speziellen Abfragesprache ermöglicht, OSM-Daten zu filtern.

Der Ablauf ist dabei immer der Folgende: Für ein spezielles Problem stellt man sich eine meist kurze Abfrage zusammen (diese definiert, welche Daten man erhalten möchte), lässt diese dann vom Overpass API Datenbankserver ausführen, und erhält schließlich die gewünschten OSM-Daten zurück. Diese Daten werden dann auf einer Karte visualisiert und stehen für eine eventuelle Weiterverarbeitungen als Export zur Verfügung.

Ein Beispiel: Man möchte die Positionen aller Trinkbrunnen wissen, um die nächste Fahrrad-Tour besser planen zu können. Die dazu passende Abfrage sieht in etwa folgendermaßen aus:

<query type="node">
<has-kv k="amenity" v="drinking_water" />
  <bbox-query {{bbox}} />
  </query>
<print />

Query Wizard

Leider ist das Erstellen solcher Abfragen immer noch etwas für IT-affine Menschen, denn nicht jeder Mapper kann sofort etwas mit der XML-Syntax anfangen. Außerdem muss man immer für jede Objektkategorie das entsprechende OSM-Tag und die Feinheiten der Overpass-Abfragesprache im Kopf haben. Noch dazu ist das Eintippen oft recht mühsam und aus eigener Erfahrung tendenziell etwas lästig.

1. Wizard im Menu starten – 2. Gewünschtes Eingeben – 3. Button anklicken

Genau hier setzt der seit Kurzem verfügbare „Query Wizard“ – ein Assistent für Overpass-Abfragen – an. Er ermöglicht es ohne Vorkenntnis der Overpass Abfragesprache, für die meisten Problemstellungen die richtige Abfrage zu formulieren. Der Wizard erstellt aus einer kurzen, lesbaren Beschreibung des Problems die entsprechende Abfrage und führt diese direkt aus.

Um auf das vorangehende Beispiel zurückzukommen, genügt es jetzt einfach das entsprechende Tag für die Trinkbrunnen anzugeben:

amenity=drinking_water

Einfacher, oder?

Intelligenter Wizard

Was aber, wenn man gerade das Tag der gewünschten Objekte nicht weiß – „War der Schlüssel ‚amenity‘ oder ‚leisure‘ oder doch ‚tourism‘?“ Sicherlich helfen das OSM-Wiki oder Taginfo weiter, aber eigentlich sollte es doch genügen dem Wizard nur mitzuteilen, dass man eben an Trinkbrunnen interessiert ist:

Trinkbrunnen

Stimmt, das genügt. Der Assistent wandelt solche Begriffe dann selbstständig in die entsprechenden OSM-Tags um.

Das funktioniert, weil der Assistent eine Liste von Vorlagen – sogenannte Presets – kennt: Und zwar genau jene, die auch im iD-Editor zum Mappen verwendet werden können. Glücklicherweise sind diese Presets auch bereits in viele Sprachen übersetzt, somit funktioniert das auch automatisch in der jeweiligen Sprache des Benutzers.

Was kann er noch?

Der Assistent kann nicht nur einfache Abfragen für einzelne Tags oder Suchbegriffe ausführen. Es gibt auch noch eine Reihe von weiteren Filterkriterien (z. B. nach OSM-Datentyp, Bearbeitungsdatum, usw.) welche beliebig miteinander kombiniert werden können:

Restaurant and (cuisine=pizza or cuisine=italian)

Außerdem kann angegeben werden, in welchem Gebiet die Daten gesucht werden sollen. Standardmäßig wird nämlich im jeweils Aktuellen Kartenausschnitt gesucht, alternativ kann aber beispielsweise auch innerhalb einer bestimmten Stadt gesucht werden:

Museum in Wien

Die Möglichkeiten von overpass turbo hören hier natürlich noch lange nicht auf, jedoch ist hier kein Platz mehr um jedes einzelne Feature zu beschreiben. Ich hoffe aber, dass man bereits an diesem Punkt seiner Phantasie und Kreativität freien Lauf lassen kann, und sich viele tolle neue Anwendungen für die Daten von OpenStreetMap finden werden.

Fußnoten

[1] Bei OpenStreetMap mitzuarbeiten hat sicher viele Gründe. Einer der wichtigsten davon ist es wohl, die von einem selbst beigetragenen Daten in der Einen oder Anderen Form in einer Karte, einem Navigationsprogramm oder einer anderen Anwendung wiederzufinden. Was aber, wenn es für eine bestimmte Kategorie von Dingen noch keine solche Auswertung gibt? „Selbst programmieren”, hieß die Devise bisher in solchen Fällen. Leider lohnt sich der Aufwand aber nicht unbedingt immer, und außerdem ist nicht jeder ein Programmierer und damit überhaupt in der Lage so ein Projekt umzusetzen.

[2] Im vergangenen Jahr wurden ca. 200.000 Abfragen von täglich bis zu 250 Benutzern aus der ganzen Welt getätigt.

Home Sweet Home – neue OSM WordPress Plugin Seite

Zur Entstehung des OSM Plugin gibt es hier schon einen Bericht. Die OSM Plugin Seite ist nun vom Fotoprojekt Fotomobil.at zu einer eigenen exklusiven Seite übergesiedelt:

WP-OSM-Plugin.HanBlog.net

Neben einem Blog findet sich dort vor allem auch ein Bereich für Beispiele, wie man das Plugin in die eigene Seite einbinden kann.

Simplification – Kartenerstellen direkt beim Beitragschreiben

Die OpenStreetMap Karten werden über OSM Shortcodes in den Artikel eingetragen – bislang konnte man diese im Blogbackend unter Settings=>OSM generieren. Mit der V2.0 gibt es nun direkt beim Schreiben des Beitrages einen Shortcode Generator mit vordefinierten OSM Themes (Controls und Kartenrand) und einer Dropdownbox für die Markerauswahl.

WordPress OpenStreetMap Plugin OSM Shortcode Generator

Zur Auswahl stehen aktuell drei OSM Themes in den Farben Blau, Schwarz und Orange. Das Theme kann für jede Karte extra gesetzt werden:

WordPress OpenStreetMap Plugin OSM – Control Themes

Reiseblog – mit OSM den Verlauf einer Reise darstellen

Neu ist auch, dass man direkt beim Schreiben von Beiträgen mit dem OSM Shortcode Generator den Beitrag über ein Customfield verorten (geotaggen) kann. Das OSM Plugin kann dann automatisiert für den gesamten Blog oder z.B. nur für eine Kategorie eine Karte erstellen, auf der alle verorteten Plätze mit einem Marker und Link zum Artikel gekennzeichnet sind – auf Wunsch wird die Reiseroute auch zusätzlich als Linie dargestellt:

Das OpenStreetMap Plugin OSM für Reiseblogs

Feel it – Live Demo

Die Liste der OSM Plugin Features ist sehr umfangreich. Den aktuellen Stand findet man im offiziellen WordPress Plugin Directory. Das OSM Plugin ist mit der OpenLayers Bibliothek umgesetzt, damit ist auch das Einblenden von geometrischen Objekten leicht möglich. Folgendes Beispiel zeigt die Karte mit einem KML File und drei Kreisen, die man per Shortcode-Argument mit Mittelpunkt und Kreisdurchmesser setzen kann:

Der Shortcode (ohne Stern), mit dem diese Karte eingebunden wurde, sieht so aus :
[*osm_map lat=“38.713″ long=“-9.136″ zoom=“16″ width=“450″ height=“300″ control=“mouseposition,scaleline“ map_border=“thin solid orange“ theme=“ol_orange“ disc_center_list=“-9.13875 38.71198, -9.13568 38.71308, -9.13289 38.71117″ disc_radius_list=“80, 200, 70″ kml_file=“/wp-uploads//2013/05/OSM_02.kml“]

Nützliche Links:

• PLUGIN DOWNLOAD
• PLUGIN SEITE
• WORDPRESS
• OPENLAYERS

OsmAnd Navigation auf Android

Für den Jahreswechsel 2012/2013 hatte ich mir vorgenommen, OsmAnd einmal ausgiebig zu testen. Anlas bot die Version 1.0, mit welcher auch ein Offline-Routing möglich ist. Dieses ist besonders im Ausland interessant, um Roaming-Gebühren zu umgehen.

Ursprünglich sollte der Test auf Urlauber abzielen, um OpenStreetMap bekannter zu machen. Im Laufe der Zeit haben sich aber Punkte ergeben, die mich zu dem Entschluss kommen ließen, mein Ergebnis zunächst nur projektintern zu posten. Wenn man damit auf „Werbetour“ gehen will, dann sollten diese Punkte behoben sein. Ansonsten schauen sich die Touristen OsmAnd zwar an, aber werden es wieder verwerfen.

Einige werden jetzt vielleicht anmerken: Warum wird jetzt bei blog.openstreetmap.de gepostet und nicht in einem der Foren? Der Blog ist aus meiner Sicht „breiter“ aufgestellt als die Foren und die Mailingliste. Dort lesen auch Interessierte mit, die aus anderen Bereichen kommen und somit über den Tellerrand schauen. Denen sind die aufgeführten Mängel noch soweit vertretbar, um das Tool nicht gleich als „unfertig“ abzustempeln. Der Enduser wird sicherlich anders reagieren. Einen Enduser-Testbericht kann dann immer noch folgen.

Komme ich jetzt also zu meinem Test. Grundlage bildete ein Overpass-Datenextrakt (Stand 26-12-2012) für den Bereich der Costa del Sol in Spanien. In diesem Bereich habe ich sehr viel selber erfasst und somit kenne ich die Datenqualität im großen und ganzen. Das Straßennetz im Bereich der Küste ist hier schon sehr detailliert erfasst. Leider fehlen hier noch viele Straßennamen und Restriktionen, insbesondere Einbahnstraßendefinitionen. Aus diesem Grunde lag mein Augenmerk auch mehr auf der optischen Ausgestaltung und der Suchfunktion.

Routing

Die Routing-Funktion habe ich ortsintern für den Ort Nerja getestet, da mir die Wegeverbindungen sehr gut bekannt sind. Das Ergebnis war in Ordnung. Manchmal habe ich mich allerdings über die Vorschläge gewundert. Vermutlich lagen die Differenzen zwischen dem Routingvorschlag und dem von mir gewählten Weg im Meterbereich. Daher habe ich diese nicht nachgerechnet.

Suche-Funktion

Die Suche-Funktion hat mich leider nicht so überzeugt. Wenn ich als Urlauber diese Funktion nutze, dann habe ich in der Regel eine Adresse aus Ort und Straßennamen. (Die sprachüblichen Sonderzeichen vernachlässige ich an dieser Stelle, ebenso die Bezeichnung Edificio in Spanien). OsmAnd ermittelt die Straßennamen eines Ortes, so meine bisherigen Recherchen, aus dem Grenzpolygon des Hauptortes und dessen Namen. Als Ortsfremder verfüge ich aber nicht über die erforderlichen Ortskenntnisse, um Ortsteile genauer zuordnen zu können und so die Ortssuche richtig anwenden zu können. Hierzu zwei Beispiele:

Zum Ort Nerja gehört auch der Ort Maro und in beiden Orten gibt es die Calle Nueva [Nerja bzw. Maro]. Sucht man in Maro nach Straßen, dann werden keine Straßen gelistet. In Nerja werden alle Straßen innerhalb der „Verwaltungsgrenzen von Nerja“ gelistet. Die Calle Nueva für Maro wurde dabei mit einem Ortsverweis, in Klammern, versehen. Normalerweise würde man daraus schließen, dass alle Straßen für Maro mit einem Querverweis versehen werden. Dies ist aber leider nicht der Fall.

Einige Kilometer weiter westlich gibt es den Ort Torrox, mit dem Ortsteil Torrox-Costa. Hier gibt es solche Querverweise für keine der gelisteten Straßen. Als Ortsfremder könnte man unter Umständen noch auf den Gedanken kommen unter Torrox zu suchen. Aber in anderen Regionen und Orten ist so etwas, ohne fundiertes Ortswissen nur schwer möglich.

An dieser Stelle sollte zumindest ebenfalls ein Verweis auf den Hauptort (mit Verlinkung in der Suche-Funktion) vorhanden sein. Diese Gedanken habe ich im forum.openstreetmap.org bereits einmal veröffentlicht.

Ende 2012 gab es in Deutschland die Diskussion über einen Bot, der deutsche Bezeichnungen in Lagebezeichnungen vereinheitlichen sollte (ausgeschriebene Langform). Auch für andere Weltsprachen trifft dieses Problem sicherlich zu. So hat sich bei der Suche-Funktion schon gezeigt, dass im untersuchten Bereich alleine in Malaga 5 verschiedene Schreibweisen für die Avenida vorhanden sind. Dieses hat zwar nicht direkt etwas mit OsmAnd zu tun, es wäre aber sicherlich sinnvoll, für Begriffe, mit einer landesüblichen Abkürzung, diese auch zu verwenden. Ich habe den Bezug zum deutschen Bot angeführt, da es sicherlich einfacher und sinnvoller ist, Begriffe OSM-weit zu vereinheitlichen, als dass dies jedes Programm machen muss. So kann auch schneller auf neue Sonderfälle reagiert werden. OsmAnd sollte die Namen dann in der Karte wie auch der Suche als Kurzform anbieten.

Karteninhalt

Die Kartendarstellung in OsmAnd halte ich im Wesentlichen für gelungen und übersichtlich. Auch die Schärfe der Objekte ist sehr gut. Dennoch gibt es einige Punkte, was die Darstellung der Ortschaften betrifft. Schließlich ist man in einem fremden Land und muss sich erst einmal orientieren. Dieses bedeutet in erster Linie, dass man die Hauptorte sucht und dann weiter ins Detail geht. Hierbei ist mir aufgefallen, dass nicht immer die Namen der wichtigen Orte angezeigt werden.

So werden in der Zoomstufe 10 nicht einmal die Namen von Granada, Malaga etc. angezeigt. Namen, die auf jeden Fall angezeigt werden sollten.

links: Granda, rechts: Vélez-Málaga

Betrachtet man die Zoomstufe 11, dann wird nicht einmal der große Orte Valez-Malaga angezeigt. Gleiches gilt für die Zoomstufe 12 bei Nerja und Frigiliana. Stattdessen findet man immer wieder Ortsnamen von Punkten, die mit place=locality getaggt sind. Der kleine Ort Maro hingegen wird angezeigt. Sicherlich ist es nicht möglich, jedem seine individuelle Bedeutung zukommen zu lassen und jeder hat andere Gesichtspunkte. Aber wie anfangs geschrieben: den place=town und place=city sollte so eine Gewichtung zugewiesen werden, dass diese angezeigt werden.

Dass Granada erst bei Zoomlevel 10 (nicht in jedem Ausschnitt) angezeigt wird, hängt vermutlich mit einer anderen Besonderheit zusammen. Dort ist fast jeder Berg mit natural=peak getaggt. Hier müsste die Konfiguration vermutlich noch etwas angepasst werden, so jedenfalls werden Berggipfel zu lasten von Ortsnamen übergewichtigt angezeigt. Das kann auch bei den anderen Ortsbezeichnung eine mögliche Ursache sein. Dort gibt es sehr viele place=locality durch einen Import. Ein „besseres“ Ergebnis lässt sich unter Umständen erreichen, wenn die Karte im Querformat verwendet wird. Bleibt zu überlegen, ob eine ausrichtungsabhängige Gewichtung der Darstellung möglich wäre.

POI-Informationen

Die Darstellung von geplanten beziehungsweise im Bau befindlichen Straßen ist etwas dominant und könnte sicherlich dezenter sein.

Unter dem Gesichtspunkt, dass Android weiter Verbreitung finden wird und somit durch das Fußgängerrouting auch für den Wanderer weiter Verbreitung finden wird, wären weithin sichtbare Objekte für die Orientierung sicherlich sehr sinnvoll. Ich denke hierbei an (Funk)Masten und Windkraftanlagen. Letztere könnten in niederen Zoomstufen sicherlich auch geclustert werden.

Zurückblickend wird der eine oder andere sicher anmerken, dass ich nur Negatives gelistet habe. Das ist richtig. Sind diese Punkte verbessert, dann liegt hier ein wirklich gutes Programm vor.

Nun hätte ich den Test auch im heimischen Bereich machen können. Aber dann wäre zum Beispiel eine Problematik nicht aufgefallen, die schon in der GoogleGroup diskutiert wurde. Es geht um die Umlaute, die wir in den deutschen Straßennamen vermissen. Das ist aus deutschsprachiger Sicht richtig. Wenn ich nun allerdings als Deutscher im Spanischen bewege, dann hätte ich garantiert ein Problem bei der Suche mit deren Sonderzeichen (Á, ñ, ú, …). Wie dieses für beide Seiten (dem Einheimischen und dem Auswärtigen) vertretbar in Griff zu bekommen ist… dafür fehlt mir noch eine passende Idee. Vielleicht ein Optionsschalter IngoreLanguageSpecifyLetters.

Ich hoffe mit diesem Beitrag etwas Diskussionsstoff geliefert zu haben, für ein Programm, das bei einer weiteren Verbesserung sicherlich ein breites Publikum finden wird und somit unser Projekt weiter bekannt macht.

Zum Schluss noch dieses. Kürzlich war ich in einem großen Mobilfunkanbieter-Shop und wir kamen auf das Thema Routing im Ausland ohne Roaming. Da wurde der Mitarbeiter sehr aufmerksam. Es besteht wohl hoher Bedarf in dieser Richtung. Zumindest werden immer wieder diese Fragen an den Verkäufer herangetragen.

Jeder kennt sie, die Sprüche darüber, was OpenStreetMap vor allem fehle: Adressen. Normalerweise sage ich jedem, der findet, dass OSM für irgendeinen Zweck unbenutzbar sei: „Dann benutze es halt nicht.“ – Schliesslich gibt es weiss Gott genügend Zwecke, für die OpenStreetMap ausgezeichnet nutzbar ist, und wenn unsere Mapper finden, dass Adressen eine gute Sache sind, dann kommen die schon auch dazu.

Trotzdem fiel mir auf, dass auch erfahrene Mapper immer mal wieder resigniert sagten: „Wir kriegen nie einen kompletten Adressdatensatz, zumindest nicht ohne einen großen Datenimport.“ – ganz untypisch für ein Projekt wie unseres, in dem man eigentlich eher die Ärmel hochkrempelt und loslegt. Also stellte ich eine kleine Rechnung auf. In Deutschland gibt es vielleicht so 40 Millionen Adressen. Und ungefähr 40.000 Leute haben in Deutschland schon gemappt. Wenn nun jeder davon 1.000 Adressen erfassen würde…

Normalerweise mappe ich Adressen nur selten, aber jetzt beschloss ich, doch etwas systematischer vorzugehen. Kann ja nicht so schwer sein! Wie in alten Zeiten, als wir noch fehlende Straßen mit dem GPS hinzugefügt haben, druckte ich mir jedesmal einen kleinen Kartenausschnitt aus, wenn mich mein Weg in eine Gegend ohne Hausnummern führte, und zeichnete Hausnummern auf. Oder ich machte einen kleinen Umweg… und wie in alten Zeiten waren meine Standard-Gegenden natürlich bald fertig, und ich freute mich, wenn mich eine Besorgung mal woandershin führte, wo es noch keine Hausnummern gab. (Ich habe auch ein bisschen gemogelt und einige Ausdrucke an Freunde und Familie gegeben, mit der Bitte, beim nächsten Spaziergang ein paar Nummern einzutragen.)

Entgegen meiner Erwartung war es gar nicht langweilig. Manche Straßen sind zwar fein säuberlich im Zweier-Abstand numeriert, aber ziemlich oft gibt es dann doch ein Kleinod oder eine Besonderheit zu entdecken – die 7a im Hinterhof, die 126 mit dem Eingang von der Rückseite, oder die 38, die eigentlich schon an der anderen Straße liegt.

Es dauerte etwa drei Wochen, bis ich mit dieser Art von „Nebenbei-Mapping“ meine 1.000 Adressen zusammenhatte – natürlich nur, weil ich auf der Arbeit von anderen OSMern aufbauen konnte,  die vor mir schon Straßen und meistens auch die Hausumrisse eingetragen hatten.

Ich glaube zwar immer noch nicht, dass Adressen wirklich so wichtig sind, wie einige sagen. Aber ich denke, ich werde weiterhin nebenbei Hausnummern aufzeichnen und ab und zu auch mal Freunde mit einem Ausdruck behelligen, und sei es nur, um zu beweisen, dass die Befürchtung „das kriegen wir mit Crowdsourcing nie hin“ falsch ist.

Es ist wie in alten Zeiten, als die Leute sagten: „Das mit OSM, das kann doch gar nicht gehen.“

Hast Du schon Deine 1.000 Hausnummern?

(Dieser Artikel ist auf Englisch am 12.12.2012 in Frederiks Blog auf osm.gryph.de erschienen.)

Warum sollte man das Aussehen der Karte im Arbeitsbereich überhaupt verändern wollen? Zum einen ist es wohl Geschmackssache: Der Standardstil mit seinem schwarzen Hintergrund und den dünnen hellen Linien ist auf möglichst effizientes Bearbeiten der Daten hin optimiert. Einen etwas anderen Ansatz verfolgt der Online-Editor Potlatch 2, bei dem die Arbeitsfläche schon deutlich mehr nach einer ausgestalteten Karte aussieht. Diese Art der Darstellung kann auch in JOSM genutzt werden, was Einsteigern mit Potlatch 2-Erfahrung möglicherweise mehr zusagt.

Zum anderen können durch Erweiterung des Kartenstils gezielt Eigenschaften wie beispielsweise Höchstgeschwindigkeit (maxspeed=*) oder Straßenbeschaffenheit (surface=* & smoothness=*) visualisiert werden. Wer an der Erfassung entsprechender Eigenschaften interessiert ist, kann so auf direkte und einfache Weise die Vollständigkeit und Korrektheit der Daten überprüfen.

Die Standard-Kartenstile

Wechsel des Kartenstils in JOSM

Nach der Installation bietet JOSM standardmäßig drei verschiedene Kartendarstellungen an. Um zwischen den Stilen zu wechseln, aktiviert man den Kartenzeichenstil-Dialog mit einem Klick auf das Palette-Symbol links unten. (Auf kleineren Bildschirmen ist das Symbol möglicherweise versteckt, dann kann der untere Bereich der Werkzeugleiste mit dem Mausrad oder über den kleinen Pfeil heran geholt werden.)

Der Kartenstil-Dialog im rechten Bereich listet alle installierten Stile auf. Mit einem Klick auf das Kästchen links vom jeweiligen Namen wird der Stil aktiviert oder deaktiviert. Prinzipiell können mehrere Stile gleichzeitig aktiv sein. In diesem Fall werden die Darstellungsregeln kombiniert, wobei die unteren Einträge die darüber liegenden überschreiben. Dies ist vor allem dann sinnvoll, wenn ein Zeichenstil sich einem ganz speziellen Aspekt in der Kartendarstellung widmet und damit einen Basisstil ergänzt.

Standardstil in JOSM

Potlatch 2-Stil in JOSM

Drahtdarstellung in JOSM

Herunterladen weiterer Stile

Aufrufen der Einstellungen für Kartenstile

Weitere Stile können bequem heruntergeladen werden: Bewegt man den Mauszeiger über den Kartenzeichenstil-Dialog, so erscheint eine Reihe von Schaltflächen im unteren Bereich. Ein Klick auf die rechte Schaltfläche (Einstellungssymbol) öffnet den Dialog zur Konfiguration der Zeichenstile.

Karten-Einstellungen

Verfügbare Stile finden sich in der linken Liste, die erst ausgewählt und dann über die mittlere Schaltfläche (Pfeil nach rechts) übernommen werden.

Verfügbare Stile (kleine Auswahl)

Nicht zu verwechseln mit: „Coloured Addresses“.

Adress-Validator-Stil

Der Adressvalidator-Stil unterstützt beim Mappen von Adressen. Häuser und Straßenbeschriftungen werden entsprechend dem Anfangsbuchstaben des Straßennamens eingefärbt. Damit sollte eine falsche Zuordnung direkt ins Auge fallen. Bauwerke mit fehlender Hausnummer und/oder fehlendem Straßennamen werden optisch hervorgehoben (siehe Abbildung). Von der Darstellung ausgenommen sind Garagen und Hütten, es sei denn, sie tragen bereits Adressinformation.

Nicht zu verwechseln mit: „Höchstgeschwindigkeit“ (engl. „Maxspeed“) und „Geschwindigkeitsbegrenzungszeichen“ (engl. „Speedlimit Signs“).

„BesideTheRoad_Speed“-Stil zur Anzeige von Höchstgeschwindigkeiten

Dieser Stil dient der Anzeige von Höchstgeschwindigkeiten. (Nicht vom etwas merkwürdigen Namen verwirren lassen!) Eine Kombination mit anderen Stilen ist problemlos möglich, zur besseren Übersicht kann man die Darstellung aber auch einmal (wie in der Abbildung) einzeln wirken lassen.

Werte der maxspeed-Eigenschaft werden farblich codiert und als Umrandung der Straße visualisiert. Insbesondere werden auch Straßen mit verschiedenen Höchstgeschwindigkeiten in Hin- und Rückrichtung korrekt eingezeichnet.

Nicht zu verwechseln mit: „Surface - Data Entry“.

Stil Oberflächenbeschaffenheit

Im Stil Oberflächenbeschaffenheit werden die Werte der Eigenschaften surface=* und smoothness=* visualisiert. Die Darstellung hängt vom Zoomlevel ab: Bei kleinen Maßstäben wird nur angezeigt, ob entsprechende Eigenschaften vorhanden sind, sobald man näher heran zoomt, werden die Farben differenzierter und es erscheint eine Beschriftung entlang der Linie. Objekte, die sowohl mit surface=* als auch mit smoothness=* getaggt sind, erkennt man an der stärkeren Linienbreite (nicht in der Abbildung).

Der Stil „Mapnik (true)“ stellt die Daten möglichst so dar, wie sie das Programm Mapnik mit dem entsprechenden OpenStreetMap-Stil erzeugen würde. Dies kann also als eine Art Vorschau auf das Resultat in der OSM-Hauptkarte angesehen werden. Zum Editieren ist diese Kartendarstellung weniger geeignet, da Linien und Punkte je nach Eigenschaften zum Teil nicht angezeigt werden.

In der Abbildung kann man erkennen, dass die Imitation noch nicht perfekt ist. Beispielsweise werden Gebäude von Landnutzungsflächen verdeckt und Straßennummern wie B 254 werden nicht in der gewohnten Form als Plakette angezeigt.

Diese Auswahl an Stilen war natürlich sehr subjektiv und je nach Interessengebiet finden sich weitere Stile, die bei der Erfassung bestimmter Merkmale unterstützen können. So gibt es zum Beispiel Kartendarstellungen zu den folgenden Themen: Seezeichen, verschiedene Arten von Parkmöglichkeiten, Stromversorgungseinrichtungen, Bürgersteige, beleuchtete Straßen, Hervorhebung von Objekten mit FIXME=*-Eigenschaft, Hervorhebung von Objekten, die vom Benutzter gerade neu erstellt oder modifiziert wurden und noch einige mehr.

Mapdata: © OpenStreetMap contributors
Mapnik tiles: CC-BY-SA 2.0

Im Folgenden möchte ich die Konfiguration beschreiben und beschreiben welche Erfahrungen gesammelt wurden. Durch die Limitierung der Hardware konnte nur mit einem Ausschnitt gearbeitet werden. Bei entsprechend mehr Ressourcen funktioniert das Setup jedoch auch für den gesamten Planeten. Die Extrakte gibt es für einzelne Gebiete bei der Geofabrik oder für individuelle Gebiete beim Extraktdienst von BBBike. Das Grundsystem bestand aus einer Standardinstallation eines 64Bit-Ubuntu Precise Penguin Pangolin. Eingebunden wurden folgende PPAs

• http://ppa.launchpad.net/mapnik/nightly-trunk/ubuntu
• http://ppa.launchpad.net/ubuntugis/ubuntugis-unstable/ubuntu
• http://ppa.launchpad.net/kakrueger/openstreetmap/ubuntu

Außerdem wurde noch PostgreSQL 9.1 mit Postgis 2.0 sowie Apache installiert. Von den Mapnik-Utils wurde nik2img und cascadenik installiert. Hilfreich beim PostgreSQL-Tuning waren Frederiks Folien der SotM 2012. Folgende Einstellungen wurden gemacht:

shared_buffers = 24MB
work_mem = 32MB
maintenance_work_mem = 4096MB
autovacuum = off
fsync = on 
synchronous_commit = on

Gegebenenfalls muss noch der Parameter shmmax angepasst werden, falls die obigen Parameter zu groß gewählt werden:

sysctl -w kernel.shmmax = 4294967296  #4GB

Die virtuelle Maschine wurde mit 12GB RAM und 100GB HDD großzügig dimensioniert, außerdem lief sie von einer SSD.

Für das Rendern der Karte wurde MapServer und Mapnik eingesetzt. Der Kartenstil für Mapnik setzte auf dem osm2pgsql-Schema auf, wohingegen MapServer das Imposm-Schema verwendete. Im basemaps-Repository von MapServer gibt es ein Skript, das aus dem osm2pgsql-Schema ein Imposm-Schema erzeugt. Beim Import mit osm2pgsql wurde die Datei „default.style“ des deutschen Kartenstils benutzt sowie auch eine hstore-Spalte mit allen Tags erzeugt.

Am Anfang wurde nur mit dem Deutschland-Extrakt gearbeitet. Da es aber Anfragen für Österreich gab, wollte ich die Daten einfach hinzuladen. Beim Import habe ich jedoch die Hilfstabellen gelöscht, also musste ein Neuimport gemacht werden. So wurde zuerst wieder Deutschland importiert, ohne das Löschen der Hilfstabellen. Beim Import von Österreich gab es jedoch constraint-Verletzungen, da doppelte Einträge vorkamen. Letztendlich entschied ich mich für einen neuen Extrakt von bbbike der Deutschland und Österreich enthielt und die Hilfstabellen konnten wieder gelöscht werden.

osm2pgsql -c -d print -E 3857 -C 6096 -r pbf --drop --hstore --hstore-match-only --unlogged --number-processes 6 -p osm --slim -S /home/fossgis/build/styles/mapnik-german/default.style germany_austria.osm.pbf

Für den MapServer wurde ein WMS-Dienst erzeugt, der in drei Kartenstilen verfügbar war. Diese ähneln dem Aussehen von Google Maps, Bing Maps bzw. dem Michelin Atlas.

Das Rendern der Mapnik-Karten erfolgte mit dem Tool nik2img.py und es standen der internationale und der deutsche Kartenstil zur Verfügung.

Für die Verwendung auf dem Messe-Stand habe ich eine JavaScript-Anwendung erstellt, die auf OpenLayers und GeoExt aufbaut. So konnten über eine Web-GUI die Parameter und der gewünschte Kartenausschnitt bequem am Bildschirm eingestellt werden.

In der Oberfläche wird die Breite und Höhe des Kartenbildes in Pixeln angegeben. Durch den eingebundenen WMS des MapServer konnte das Ergebnis vorab im Browser betrachtet werden. Bildausschnitt und Kartenstil gaben exakt das Ergebnis wieder, nur in einer geringeren Auflösung. Durch einen Klick auf den „gooo-Button“ erfolgte das eigentliche Rendern in der hohen Auflösung. Dazu werden alle Parameter an ein Python-Skript übergeben. Dieses holt sich entweder das Bild vom MapServer oder, wenn entsprechend eingestellt, durch einen Aufruf von nik2img. Das Rendern des Kartenbildes erfolgte innerhalb weniger Minuten, oftmals sogar unterhalb einer Minute. Anschließend wurde noch eine Infobox mit Lizenzangabe und Quellennachweis per ImageMagick auf das Kartenbild gerendert. Dieser Schritt könnte auch vom MapServer direkt und wahrscheinlich auch durch Mapnik mit einem zusätzlichen Layer realisiert werden. Ein ImageMagick-Aufruf war hier jedoch einfacher.

Die hohe Auflösung wurde erreicht durch die Umrechnung der Höhe und Breite. Hier sind zwei Beispielaufrufe, die ein Bild mit 800×600 Pixeln für einen Ausdruck mit 360 dpi erzeugen:

• http://printbox/cgi-bin/mapserv?LAYERS=default&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&STYLES=&EXCEPTIONS=application%2Fvnd.ogc.se_inimage&SRS=EPSG%3A900913&BBOX=1467870.6369923,6882377.556746,1488984.3755909,6897485.2569212&WIDTH=3990&HEIGHT=2855&format=agga&map_resolution=360

• nik2img.py /home/fossgis/build/styles/mapnik/osm.xml mapnik_2012-10-11-11-28.png --scale-factor=3  -e 1467870.6369923 6882377.556746 1488984.3755909 6897485.2569212 -d 3990 2855 --no-open

Das fertige Bild konnte jetzt zum Plotter geschickt werden. Hier kann es kompliziert werden. Durch die Verwendung von Photoshop und Mirage (das bevorzugte Epson Druckwerkzeug) bestand der Aufwand lediglich im Öffnen des Bildes und der Einstellung der Ausrichtung (Hoch- /Querformat). Hat man nur den Standard-Druckertreiber muss man die Breite und Höhe des Bildes sowie des Papierformats, die Ausrichtung, die Auflösung und die Positionierung einstellen.

Gedruckt wurde auf einer 44-Zoll-Rolle mit Fotopapier und auf einer 36-Zoll Rolle mit Normalpapier. Die Druckdateien waren zwischen 50 und 120 MB groß und gedruckt wurde mit 360dpi. Der Druck auf Fotopapier dauerte ca. 20 Minuten im B0-Format, auf Normalpapier waren es 7-10 Minuten.

Das Setup funktionierte auf dem OSM-Stand sehr gut. Insgesamt wurden zwei Rollen Fotopapier (44″) und eine Rolle Normalpapier (36″) verbraucht. Am zweiten Tag lief der Plotter fast ununterbrochen und produzierte für viele Interessenten ihr Kartenposter. Die exakte Anzahl der Ausdrucke kann leider nicht mehr angegeben werden.

Natürlich gibt es immer Platz für Verbesserungen. Zum einen war die Web-GUI nur ein Prototyp, der noch deutlich verbessert werden kann. Die direkte Auswahl des Papierformats würde dem Benutzer die ganze Umrechnung mit Breite/Höhe, DPI und Pixel ersparen. Das Kartenbild selbst könnte noch durch einen Rahmen, ein zusätzliches Gradnetz oder Elemente wie Nordpfeil, Maßstabsleiste und Legende ansehnlicher gestaltet werden. Einige Kartenstile der frei zugänglichen OSM-Karten sind öffentlich. Einige benutzen zusätzliche Daten wie z.B. Höhenlinien oder Schummerungen. Andere basieren auf einem eigenen Datenbankschema, wie z.B. die ÖPNV-Karte. Es ist nicht so einfach die diversen Kartenstile in das Setup zu integrieren, aber auch nicht unmöglich. Die Kartenstile können für den Druck noch angepasst werden. So sind z.B. bei den erzeugten Deutschlandkarten nicht alle Hauptstädte der Bundesländer beschriftet. Wenn dann letztendlich das druckbare Bild erzeugt wurde, wird auch ein großformatiger Drucker benötigt oder ein Copyshop. Eine Deutschlandkarte kann hier (ca. 90MB) heruntergeladen werden.  Aktuelle Downloadlinks am Ende des Artikels.

Die Druckwerkstatt auf der Intergeo war jedenfalls ein Erfolg. Es gab viele Interessenten, die sich das Setup erklären ließen und Anregungen für Verbesserungen gaben. Viele Besucher wollten ihren Wohn- oder Arbeitsort großformatig ausgedruckt haben. Ob und wenn ja, in welchem Umfang es eine Druckwerkstatt auch auf anderen Veranstaltungen geben wird, ist noch nicht entschieden. Alle aktiv Beteiligten können sich ähnliche Aktionen gut vorstellen. Meinungen und Ideen aus der OSM-Community sind auf jeden Fall erwünscht.

Update: Das Problem der Städtebeschriftung wurde inzwischen gelöst. Eine aktuelle Version kann für folgende Länder heruntergeladen werden: Deutschland (ca. 80MB), Österreich (ca. 40MB) und Schweiz (ca. 40MB)