Wir hatten ein Ferienhaus komplett für das Wochenende gemietet, mit genug (Doppel-)Zimmern, einer voll ausgestatteten Küche und mehreren Gemeinschaftsräumen, sodass man sich ausbreiten konnte, zur Arbeit, zum Spielen, oder zum Ausruhen. Das Haus steht auf dem Gipfel des Ungerbergs, genau da, wo sich mehrere Wanderwege treffen. Es war daher die perfekte Basis für unsere Unternehmungen. Ursprünglich hatten einige von uns geplant, in Zelten zu übernachten. Aber nachdem es vorher zwei Tage lang (mehr oder weniger) durchgängig geregnet hatte, erschien das nicht mehr so als die passende Option. Aber wir haben es geschafft, alle Teilnehmer im Haus unterzubringen.

Nach der Ankunft am Freitagnachmittag fanden sich schnell einige Helfer für den Küchendienst. Hanna und Thomas waren schon Einkaufen gewesen und stapelweise Kisten und Tüten voll mit Essen und Getränken wurden in Regale und Kühlschränke einsortiert und dann gemeinsam ein Essen zubereitet. Das anschließende Abendessen und der Rest des Abends gaben dann allen die Chance zum Kennenlernen und Ausruhen nach der teilweise recht langen Anreise.

Mapping-Fähigkeiten verbessern geht am Besten in der Gruppe

Samstag morgen ging es los mit einem herzhaften Frühstück mit frischen Brötchen, heißem Kaffee und viel Planung. Sarah, unsere Wanderwegexpertin und Betreiberin der Waymarkedtrails-Webkarte, zeigte uns, wo es Lücken im Wanderwegenetz in der Gegend gibt. Und trotz schlechten Wetters machten sich dann fast alle in drei Gruppen auf, um die umliegenden Wanderwege neu zu mappen oder zu überprüfen. Der Rest hielt die Stellung, sorgte für Nachschub und fungierte als Taxi-Dienst, um die Wanderer wieder heim zu bringen.

Zusammen sind wir ungefähr 60km gelaufen, die meisten GPS-Tracks sind in diesem Bild.

Die Gruppen „Norden“ und „Westen“ waren am frühen Nachmittag zurück, die „Süd“-Gruppe konnte anscheinend nicht anhalten, bevor sie den Fluss erreicht hatte, der diesem Treffen seinen Namen gibt. Sie waren dann erst etwas später da. Der Rest des Tages ging mit Kochen, Grillen und Essen vorbei, und Mappern, die vor Ihren Notebooks den „Fang“ des Tages eintrugen. Das ging natürlich einher mit vielen Diskussionen über die richtige Art und Weise, wie man Umwege in Wanderwegen mappt, oder Wegweiser oder Reitwege. Diese Diskussionen (abwechselnd auf Deutsch, Tschechisch, meist aber auf Englisch gehalten) sind das, was so ein Treffen so wichtig für OSM macht. Ja, das Mappen selbst macht mehr Spaß in der Gruppe, aber man kann es auch alleine machen. Aber voneinander zu lernen, zu sehen, was man besser (oder auch einfach nur anders) machen kann, das geht so nur in der Gruppe. Aber natürlich war nicht alles nur Arbeit, der Billiard-Tisch sah auch einiges an Aktivitäten…

Der zweite Tag sah wieder drei Gruppen, die ausschwärmten, um weitere Lücken zu füllen. Die Gruppe „Ungerberg“ kümmerte sich um einige Details in der direkten Umgebung „unseres“ Gipfels, wo einige Wanderrouten erst kürzlich verlegt worden waren. Die Gruppe „Neustadt“ suchte und fand die Verbindungen zwischen offenen Enden einiger Routen in der nahen Stadt. Und die Gruppe „Lehrpfad“ ging einem schlecht ausgeschilderten Waldlehrpfad nach. Auch diese Daten wurden (mit den notwendigen Diskussionen) bei OSM eingetragen. Nach dem Mittagessen wurden dann noch die letzten Edits durchgeführt, die Taschen gepackt und Butterbrote geschmiert und dann löste sich die Gruppe langsam auf.

Waymarkedtrails-Karte vor…

…und nach der Veranstaltung (Hintergrund: OpenTopoMap).

60 Kilometer Wanderwege überprüft

Was hat das Wochenende gebracht? Alle zusammen haben wir ungefähr 60 Kilometer Wanderwege eingetragen oder kontrolliert. Viele Lücken konnten geschlossen werden, viele Details ergänzt oder korrigiert. Dadurch, dass wir so viele Leute waren, konnten wir die Arbeit gut aufteilen, aber trotzdem immer noch gute Gruppengrößen haben, dass das Wandern Spaß gemacht hat. Und jeder sieht und erinnert sich an Details, die andere übersehen haben, sodass man dann gemeinsam viele Fälle lösen kann, wo der Verlauf eines Wanderweges verwirrend ist oder die Bedeutung eines Wegweisers unklar ist. Natürlich ist immer noch eine Menge zu tun, aber wir hinterlassen die Karte in einem viel besseren Zustand als wir sie vorgefunden haben.

Falls Du bisher noch nicht denkst, dass Du eine tolle Veranstaltung verpasst hast, dann schau Dir unser Filmchen an.

Vielen Dank an alle Teilnehmer, die das Meeting zu so einer großartigen Veranstaltung gemacht haben, besonders an die Mapper aus Tschechien, die unserer Einladung von weither gefolgt sind und die die Veranstaltung vielfältiger und interessanter gemacht haben. Ein extra Dankeschön an Hanna und Thomas, die den Großteil der Organisation und den ganzen Einkauf übernommen haben, und natürlich auch an den Wikimedia e.V., der den Event gesponsort hat. Wir hoffen auf eine ähnliche Veranstaltung nächstes Jahr, vielleicht dann in Tschechien …

Unter den Bewerbern wurde auch das Projekt zu mehrsprachigen Karten ausgewählt. Initiiert wurde es von Tim Alder, der sich seit Jahren mit der Zusammenarbeit von OpenStreetMap und Wikipedia beschäftigt. Für die programmiertechnische Umsetzung hat er sich an mich, Jochen Topf, gewandt. Ich habe mich als Hauptautor von Tirex, das bei der Wikipedia eingesetzt wird, schon lange mit dem Thema Webkarten beschäftigt.

Ziel des Projektes ist es, die technischen Grundlagen zu schaffen, dass OpenStreeMap-Karten in allen Sprachen angezeigt werden können, in denen es die Wikipedia gibt. Derzeit gibt es Karten in etwa zehn Sprachen. Das ist aber nur ein kleiner Teil der circa 270 Sprachen, die derzeit von der Wikipedia abgedeckt werden. Die Wikipedia sieht sich in ihren Artikeln zu geographischen Objekten durchaus auch als Reiseführer und auch als Alternative zum Schulatlas (selbsterklärter Bildungsauftrag). Bei diesen beiden Anwendungen sind Übersetzungen der Karte in die jeweilige Sprache des Nutzers absolut üblich.

Zur Anzeige im Web werden Karten in Kacheln (Tiles) zerlegt, die jeweils 256×256 Punkte umfassen. Derzeit ist es so, dass die Kacheln für jede Sprache völlig getrennt betrachtet werden. Aber viele Kacheln sind natürlich in allen Sprachen gleich (weil gar kein Name darauf vorkommt). Und viele Kacheln gibt es nur in einigen wenigen Varianten, zum Beispiel wird man für die meisten Kacheln in Deutschland auf einer englischen Karte die gleichen Namen drucken, nur einige Orte wie München haben auch einen besonderen Namen im Englischen (Munich).

Die derzeitige Lösung ist ineffizient und mit vertretbarem Hardwareaufwand nicht für so viele Sprachen umzusetzen. Um eine bessere Lösung zu finden, muss sich das Projekt mit verschiedene Fragen beschäftigen. Zuerst muss man irgendwie erkennen, in welchen Sprachen eine Kachel überhaupt vorliegen könnte. Wir wollen nicht mühsam 200 Mal eine Kachel in Patagonien berechnen, wenn wir nachher feststellen, dass es es nur zwei Sprachvarianten davon gibt. Dafür muss irgendeine Art von Datenbank eingerichtet werden, die einem angibt, wo überhaupt welche Sprachen verwendet werden.

Dann muss der Mapnik-Renderer entsprechend konfiguriert werden, damit er die Namen in der richtigen Sprache in die Kacheln hineinrendert. Derzeit ist das etwas problematisch, weil die ganze riesige Konfiguration für den Mapnik für jede Sprache vorgehalten werden muss, obwohl nur kleine Teile eigentlich verschieden sind.

Sind die Kacheln dann gerendert müssen sie effizient gespeichert werden, zusammen mit der Information für welche Sprachen sie verwendet werden können. Dabei wird es sich häufig nicht vermeiden lassen, dass doch mal zwei Kacheln berechnet werden, die sich als gleich herausstellen. Wir sollten also auch feststellen, wenn Kacheln gleich sind, damit wir sie dann nur einmal speichern, um nicht zu viel Plattenplatz zu verbrauchen.

Bei all diesen Stufen ist auch noch zu berücksichtigen, dass sich die OSM-Daten häufig ändern und die Kacheln daher immer wieder neu berechnet werden müssen. Dabei kann es zum Beispiel sein, dass eine Kachel, die bisher nur in einer Sprache vorlag, jetzt in zwei Sprachen vorliegt und es müssen dann alle nötigen Anpassungen vorgenommen werden.

Die Lösung sollte auch möglichst flexibel sein, sodass man dann im Betrieb experimentieren kann, zum Beispiel damit, wann welche Kacheln neu gerendert werden.

Und trotz dieser vielen komplexen Komponenten muss es auch noch schnell gehen. Die Wikipedia wird von sehr vielen Leuten verwendet und die Kacheln müssen schnell und effizient an den Browser ausgeliefert werden. Und um so weniger Ressourcen das verbraucht, um so besser, weil Hardware in Anschaffung und Betrieb viel Geld kostet.

Eine denkbare Alternative wäre es natürlich, komplette auf Vektordaten umzustellen, also erst im Browser die Karten aus den Rohdaten zu zeichnen und dabei die gewünschte Sprache zu berücksichtigen. Ebenfalls denkbar wäre ein Hybridmodell, bei dem die Karten weiterhin auf dem Server gezeichnet werden, die Namen von Orten, Straßen, usw. aber erst im Browser dazugezeichnet werden. Beide Ansätze gehen aber möglicherweise zu Lasten der Darstellungsqualität und sie erfordern moderne Browser und schnelle Rechner, womit man noch nicht überall rechnen kann. Die Wikimedia muss vorallem auch auf ärmere Länder Rücksicht nehmen, wo viele das Internet über ihr Mobiltelefon oder mit älteren Rechnern nutzen. Außerdem sind die Techniken zum Kartenrendering im Browser noch recht neu und es liegen lange nicht so viele Erfahrung damit vor wie der bewährten „Bitmap-Kachel-Technik“. Wir haben uns daher entschlossen, in diesem Projekt die bewährte Technik fortzuführen und auszubauen.

Das Projekt bringt nicht nur die Wikipedia vorran, sondern hilft allen, die OpenStreetMap-Karten verwenden. Größere und robustere Tileserver brauchen wir auch an anderer Stelle. Und die hier zu entwickelnde Software ist auch über den Bereich der mehrsprachigen Karten hinaus interessant. Will man zum Beispiel Autobahnen entsprechend der in einem Land üblichen Farbe zeichnen und mit den passenden Symbolen versehen, so hat man eigentlich ein vergleichbares Problem: Karten, die für verschiedene Gegenden etwas anders aussehen als in anderen Bereichen. Die Lösung sollte sich also auf andere Anwendungen erweitern lassen, auch wenn das nicht im Fokus dieses Projektes ist.

Das Projekt wird vom Wikimedia e.V. mit 20.000 EUR gefördert. Das erlaubt es mir mehrere Monate lang konzentriert daran zu arbeiten. In der ersten Phase geht es jetzt darum einen Plan zu entwickeln, wie das ganze aussehen soll. Welche vorhandene Software soll zum Einsatz kommen? Welche Komponenten müssen neu programmiert werden? Eine mögliche Komponente ist dabei natürlich der Tileserver Tirex, aber noch sind keine endgültigen Entscheidungen getroffen worden, welche Software verwendet wird.

Hier sind wir auch auf Euren Input angewiesen. Wir wollen insbesondere von denjenigen unter Euch hören, die bereits große Tileserver oder Tileserver mit mehreren Stilen betreiben. Aber auch sonst gibt es sicher Ideen, wie man zum Beispiel die vielen Kacheln effizient speichern oder wie man die Zuordnung von Sprachen zu Kacheln realisieren könnte.

Anregungen, Ideen und Diskussionen sind am besten auf der OSM-Developer-Liste aufgehoben. Ihr könnt Euch aber auch direkt an mich wenden. Koordiniert wird das Projekt über das OSM-Wiki.

Am Mittwoch, den 21. März 2012 werden wir im Rahmen der FOSSGIS-Konferenz in Dessau auch eine Community-Session dazu veranstalten.