OpenStreetMap
Die OpenTopoMap feiert am 03.09. seinen fünften Geburtstag! Als Versuch gegründet von zwei Studenten unterschiedlicher Fakultäten entwickelte sich die OTM zu einem Kartenprojekt, das mittlerweile nicht nur innerhalb der OSM-Community ein Begriff ist. Das heutige Kartenbild hat sich im Vergleich zum allerersten Testbild glücklicherweise weiterentwickelt:
Zum Vergleich: OpenTopoMap heute
Auch die Besucherzahlen und damit die Anforderungen an die Hardware stiegen kontinuierlich. Derzeit rufen gut 30.000 Besucher mehr als 90 Mio. Kacheln pro Monat ab. Die Garmin-Downloads, die glücklicherweise auf einem anderen Server liegen, kommen auf 17 TB/Monat.
Möglich ist der Betrieb überhaupt nur durch die Unterstützung der Friedrich-Alexander-Universität Erlangen-Nürnberg (FAU) und dem Regionalen Rechenzentrum Erlangen (RRZE). 2012 finanzierte die Universität dem Projekt einen Server, der dankenswerterweise am RRZE untergebracht und versorgt wird. 2015 finanzierte das Department Geographie eine SSD mit 1,1 TB, die über PCIe angebunden ist. Und erst vor Kurzem wurden von der Universität dankenswerterweise Mittel für weitere HDDs im RAID mit 3,6 TB nutzbarem Speicherplatz bewilligt, um auch die größeren Zoomstufen vorhalten zu können.
Seit Anfang 2016 konnte dank der 1,1TB-SSD der Versuch gewagt werden, den gesamten Planeten abzudecken. Selbst die minütlichen Updates brachten den Server bezogen auf die Rechenzeit nicht mal ansatzweise an seine Grenzen. Die OSM-Datenbank (osm2pgsql ohne HSTORE) wuchs allerdings so stark, dass der automatische Import vor wenigen Wochen gestoppt werden musste. Neben den OSM-Daten (495 GB) liegen nämlich auch 505 GB an Höhenlinien als Datenbank auf der SSD.
Die Konsequenz ist klar: Die Höhenlinien-Datenbank muss um mindestens 100 GB reduziert werden, um der OSM-Datenbank Platz für die nächsten Monate und Jahre zu verschaffen. Auch kartographisch wäre dies sinnvoll: Der weltweite Höhenlinienabstand von 10 Metern ist spätestens in Hochgebirgen alles andere als übersichtlich (Beispiel). Man kann also getrost auf so manche Höhenlinie verzichten. Das Problem ist nur, einen Algorithmus und dessen Parameter zu finden, mit dem automatisiert alle Höhenlinien weltweit ausgedünnt werden können. Übrigens enden Höhenlinien auf professionellen Karten durchaus auch mal im Nichts, wenn zwischen Detailgraden gewechselt wird. Vermutlich muss man nach (evtl. zusammenhängenden) Gebieten suchen, in denen Höhenlinien gelöscht werden.
Derzeit bin ich der einzige technische Entwickler der OpenTopoMap. Glücklicherweise habe ich neben der OTM noch andere schöne Hobbys, wodurch die Entwicklungszyklen allerdings extrem lang werden. Gerne würden wir weitere Entwickler aufnehmen und nach der Höhenlinienproblematik auch weitere Ideen ausprobieren. Sehr willkommen (und sich in einer E-Mail-Flut äußernd) sind natürlich weiterhin Anregungen und Verbesserungsvorschläge. Ohne ein Entwicklerteam, das größer als eine Person ist, stehen die Chancen auf eine schnelle Umsetzung allerdings schlecht.
Lange Rede, kurzer Sinn: Wir suchen nach Entwicklern! Wer sich berufen fühlt, möge sich gerne bei mir per PM oder Mail (stefan@opentopomap.org) melden.
Die Autoren des Projektes möchten nochmals ganz herzlich der FAU und dem RRZE für die Finanzierung und Unterstützung der OpenTopoMap danken.
Discussion
Comment from nebulon42 on 23 August 2016 at 05:55
Ich entwickle bei openstreetmap-carto mit, dort habe ich die meisten Symbole neu gestaltet und auf SVG umgestellt und vor kurzem die Grenzdarstellung auf kleineren Zoomstufen verbessert. Ich bin seit kurzem auch Committer oder “Maintainer” bei Mapbox’ CartoCSS und was mich bisher davon abgehalten hat mich näher mit OpenTopoMap auseinanderzusetzen war, dass der Code in Mapnik XML und nicht in CartoCSS vorliegt.
War das eine bewusste Wahl? Hat Mapnik XML gegenüber CartoCSS Vorteile deiner Meinung nach (fehlende Kaskadierung und dadurch kleinerer Stil?)? Wäre ein Port sinnvoll? Möglicherweise würde das auch mehr Entwickler anziehen, da vielleicht die CSS-artige Syntax von CartoCSS gerade auch Menschen, die sich schon einmal mit Webdesign beschäftigt haben, eher verständlich ist.
Falls du die JavaScript basierte Referenzimplementierung von CartoCSS nicht gut findest, dann gibt es auch noch eine Go Implementierung: Magnacarto von Omniscale, wo ich vor einiger Zeit mitgeholfen habe, die für Mapnik 3 “fit” zu machen.
Nach einem kurzen Überblick hätte ich wahrscheinlich auch kein Problem mit Mapnik XML, aber anderen geht es vielleicht nicht so.
Comment from derstefan on 23 August 2016 at 18:47
Als wir mit der OpenTopoMap begonnen hatten, gab es CartoCSS noch nicht. Durchaus wollen wir Versuche mit CartoCSS machen. Vor allem die Straßen (+Brücken und Tunnel) sind sehr umfangreich und würden deutlich übersichtlicher. Ob man allerdings vollständig auf CartoCSS umstellen kann, hängt davon ab, ob sämtliche Features und “Hacks” funktionieren. Ansonsten ist vielleicht eine Kombination aus klassischen XML-Styles und CartoCSS-Styles möglich.
Mit Vektorgrafiken haben wir natürlich auch experimentiert. Allerdings ist die pixelgenaue Klarheit der Symbole nur mit Rastergrafiken erzielbar. Es spricht aber nichts dagegen, beide Versionen (z.B. mit XML-Entitäten) zu implementieren und je nach Renderer auszuwählen.
Comment from imagico on 23 August 2016 at 21:12
Um da mal wieder Eduard Imhof zu zitieren:
Was eher geht, ist in flachen Gebieten einzelne Zwischenkurven einzufügen, die man in steileren Bereichen weglässt. Auch das geht aber nur, wenn diese in der Darstellung deutlich abgegrenzt und dadurch auf den ersten Blick identifizierbar sind, zum Beispiel durch Strichelung - Verwendet ist dieser Ansatz zum Beispiel hier.
Eine gute Auswahl der Gebiete, wo man Zwichenkurven darstellt und wo nicht ist aber ziemlich schwierig (zumindest wenn das irgendwie auch performant sein soll). Und das ganze kann auch sehr schnell unübersichtlich werden.
Wenn ich mir die Höhenlinien bei euch anschaue sehe ich Einsparpotential eigentlich eher im Flachland, wo vermutlich mindestens 2/3 der Datenmenge Rauschen ist wie hier. Aber natürlich ist die Hauptmenge der Daten im Gebirge und letztendlich sind die 10m-Intervalle dort bei SRTM-Datenbasis weitgehend redundant (d.h. könnten im Prinzip aus den 20m-Linien fast perfekt interpoliert werden).
Im Grunde ist ja auch das Speichern der Höhenlinien in einer PostGIS-Datenbank ziemlich sinnlos, denn sowohl produziert als auch verwendet werden sie ja immer in Kachelform.
Comment from maxbe on 25 August 2016 at 09:11
Mein erster pessimistischer Schnellschuss: Höhenlinien in einzelnen Gebieten löschen wird der Datenbank nicht viel bringen…
So eine Höhenlinie ist ja ein sehr langes Gebilde und kreuzt viele unterschiedliche Gebiete. Die 500-Meter-Linie vor meiner Haustüre ist in meiner Gegend im Flachland und die 510m-Linie ist vielleicht nützlich. Die gleiche Linie läuft aber auch durch das hügelige Inn- und Donautal, umkreist irgendwo die Alpen und taucht in der Lombardei wieder auf, wo die 510m-Linie verzichtbar wäre.
Würde man die dazugehörige 510m-Linie zerstückeln, hätte man statt einer grossen Linie viele kleine Stücke in der Datenbank. Das könnte ein bisschen Platz bei den Linien selbst sparen, dafür wächst der Index. Ich glaube nicht, dass sich der Aufwand lohnt.
Comment from chatelao on 5 September 2016 at 16:17
Kann man irgendwie helfen um das Rendering wieder in die Gänge zu bringen?
Comment from alexanderkappel on 12 September 2016 at 05:14
Was würde dagegen sprechen, eine grössere Festplatte zu verwenden?
Comment from derstefan on 23 September 2016 at 17:40
Das Rendering läuft nun wieder, nachdem ich den billigsten aller billigen Tricks angewandt habe: Die Höhenlinien wurden mit dem Parameter “simplify” vereinfacht, wodurch man 50 GB sparen kann. Alle oben stehenden Ideen sind zwar gut, aber eben nicht in wenigen Stunden implementiert. Was soll’s: Da wir keinen einzigen Cent an der OpenTopoMap verdienen (wollen), braucht man deren Amateurhaftigkeit nicht verstecken. Dem normalen Nutzer ist es vermutlich total egal, wenn irgendwo Höhenlinien-Artefakte sind, sonst hätte sich schon lange eine OTM-Community gebildet. So haben wir nur OTM-Fans. Wobei, halt - vor einer Woche konnten wir den ersten Github-Commit eines Neulings verzeichnen!