Imagico.de

blog

carto-path_980

26. Oktober 2017
von chris
6 Kommentare

Linien zeichnen

Nachdem ich das, was ich ursprünglich für das letzte Hack-Weekend in Karlsruhe geplant hatte, bereits vorher erledigt hatte, hab ich am letzten Wochenende dann an etwas anderem gearbeitet – was allerdings durchaus im Zusammenhang dazu steht.

Die Darstellung von Linien in Karten ist etwas, was auf den ersten Blick ziemlich einfach erscheint. In der Realität jedoch muss man dabei eine ganze Menge Dinge berücksichtigen, damit die Karte am Ende gut lesbar ist. Eine wichtige Erkenntnis ist insbesondere, dass gestrichelte oder gepunktete Linien meist deutlich schwieriger zu handhaben sind als durchgezogene.

Der OSM-Standardstil verwendet verschiedene Strichelungen, um Feld- und Waldwege (tracks) nach tracktype zu differenzieren sowie Fuß- und Radwege nach Oberflächen-Material (surface). Das funktioniert bei den hohen Zoomstufen ganz leidlich, aber es versagt, wenn man weiter herauszoomt bis zu dem Punkt, dass die Linien oft komplett unleserlich werden, insbesondere in Gebieten mit einem dichten Wege-Netz. Hier einige Beispiele:

Man kann nun versuchen, an der Gestaltung herumzudoktern indem man helle Umrahmungen verwendet, den Kontrast verstärkt oder die Linienbreite ändert aber am Ende muss man einfach erkennen, dass die Strichelung es immer schwierig macht, die Wege in Gebieten mit viel Details als durchgehende Linien zu erkennen. Eine grundsätzlich andere und möglicherweise bessere Lösung wäre, bei diesen Maßstäben nur die wichtigeren Wege einzuzeichnen. Hierfür bräuchte man jedoch einen passende Bewertung, die die Daten nicht unbedingt hergeben und die letztendlich recht subjektiv und vermutlich oft nicht sehr intuitiv wäre. Für manche Kartennutzer wäre es zum Beispiel vielleicht nützlich, wenn man nur die Wege einzeichnet, die Bestandteil von Fern-Wanderwegen sind. Ein lokaler Kartennutzer jedoch hält vielleicht einen anderen Weg für wichtiger, weil er die Kürzeste, bequemste und meistgenutzte Verbindung zwischen zwei Orten in der Gegend darstellt.

Eine Lösung für die Zoomstufen z13 und z14, die ich bereits vor einiger Zeit mal getestet hatte, besteht darin, die Strichelung aufzugeben und die Wege bei diesen Maßstäben als durchgezogene Linien zu zeichnen. Das schränkt die Möglichkeiten stark ein, verschiedene Klassen von Wegen zu unterscheiden – denn man kann dann letztendlich nur noch die Farbe und die Linienbreite variieren und die Farbe ist bei sehr schmalen Linien nur schwer zu differenzieren, denn alle Pixel bestehen am Ende aus einer Mischung zwischen Linienfarbe und Hintergrundfarbe.

Was die Umsetzung dieser Idee bisher verhindert hat ist die Tatsache, dass Radwege im Standardstil traditionell in blauer Farbe dargestellt werden und eine durchgehende blaue Linie einfach intuitiv zu sehr nach einem Wasserlauf aussieht. Die Verwendung von Blau für die Radwege war immer schon ein wunder Punkt aber Versuche das zu ändern sind in der Vergangenheit an den begrenzten Möglichkeiten für die Farben gescheitert. Insbesondere begrenzt die Verwendung von Purpur für die administrativen Grenzen die farblichen Möglichkeiten enorm. Da ich die Purpur-farbenen Grenzen jedoch losgeworden bin, hab ich da jetzt etwas mehr Freiraum.

Die richtige Balance zu finden mit Farben, Linienbreiten und – bei den höheren Zoomstufen – der Strichelung der Linien, ist schwierig aber ich denke, dass das Ergebnis ganz akzeptabel ist. Die Änderung gibt den Fußwegen und Radwegen eine stärkere Gewichtung in der Karte, was in meinen Augen jedoch im Wesentlichen eine Kompensation für die Unter-Gewichtung ist, die sie im Standardstil im Moment haben.

Bei z13 sind alle Linien durchgezogen und variieren in der Breite leicht in Abhängigkeit vom tracktype. Wenngleich diese Unterschiede wohl im Allgemeinen nicht zuverlässig differenzierbar sind kann man wohl zumindest grade1 von grade4 unterscheiden. Fuß- und Radwege sind beide in Rot dargestellt, was man in jedem Fall vom Braun der Fahrwege unterscheiden können sollte.

(die selben Stellen im Standardstil: hier, hier und hier)

Insgesamt ist die Karte damit wesentlich klarer und weniger unruhig. Man kann die einzelnen Wege und ihre Verläufe und Verbindungen deutlich besser identifizieren, insbesondere in dicht erfassten Gebieten. Man verliert dafür allerdings zum Teil die Möglichkeit in weniger dicht erfassten Gebieten die unterschiedlichen Typen von Wegen zu unterscheiden.

Bei z14 ist die Darstellung recht ähnlich, die Unterschiede in der Linienbreite bei Fahrwegen sind etwas stärker und ich verwende eine Strichelung für Wege ohne tracktype – was dem Mapper zeigt, dass hier wichtige Informationen fehlen.

(die selben Stellen im Standardstil: hier, hier und hier)

Bei z15 kommt dann der helle Rahmen hinzu, wie man ihn aus dem Standardstil kennt. Fahrspuren sehen damit genauso aus wie im Standardstil, Radwege sind jetzt jedoch in Purpur gezeichnet und sowohl Rad- als auch Fußwege sind kräftiger und werden deutlicher nach Oberflächen-Material unterschieden – mit langer Strichelung für gepflasterte/asphaltierte Wege, kurzer Strichelung für nicht asphaltierte Wege und abwechselnd langer/kurzer Strichelung für Wege ohne Oberflächen-Information.

(die selben Stellen im Standardstil: hier und hier)

Ich habe auch überlegt, eine dritte Klasse von Wegen zu differenzieren. Der Standardstil hat dies vor einiger Zeit abgeschafft, was zu der etwas merkwürdigen Situation geführt hat, dass highway=path + foot=designated + bicycle=designated in Radweg-Farbe dargestellt wird, highway=path ohne foot/bicycle-Tags jedoch als Fußweg. Aber leider ist die Erfassung in diesem Bereich oft recht inkonsistent so dass eine solche Differenzierung den Nutzen nicht unbedingt verbessert. Die Bedeutung der Farben ist jetzt im Wesentlichen:

  • Purpur: für Radfahrer, üblicherweise auch für Fußgänger geeignet
  • Rot: für Fußgänger, möglicherweise auch für Radfahrer

Bei den höheren Zoomstufen wird dann die Linienbreite der Fuß- und Radwege wie bei den Fahrwegen langsam vergrößert und auch die Strichelung entsprechend verlängert, was die Lesbarkeit weiter verbessern soll.

Die gezeigten Änderungen finden sich hier.

Ich hoffe, dass diese Erläuterungen einen kleinen Einblick darin geben, wie Kartenstil-Entwicklung auf Grundlage systematischer Analyse und Lösung der Probleme funktioniert. Die eigentliche Implementierung der Änderungen ist im Grunde nicht sehr viel Arbeit, aber die Analyse der bestehenden Situation, herauszufinden woran es liegt, dass gewisse Dinge schlecht lesbar sind und die anschließende Justierung der Parameter und die Beobachtung und Analyse, welchen Einfluss diese auf die Lesbarkeit der Karte haben und wie die verschiedenen Farben und Darstellungformen miteinander wechselwirken – und das in unterschiedlichen Gegenden bei unterschiedlichen geographischen Breiten und damit Maßstäben – das ist das, was wirklich Arbeit macht.

Wer sich fragt, was man als Mapper tun kann, um eine besser lesbare Darstellung von Wegen zu fördern:

  • man sollte tracktype und surface erfassen, so weit man davon Kenntnis hat.
  • Nutzungsbeschränkungen, insbesondere foot=* and bicycle=* sind wichtig.
  • auch wenn die derzeit in Karten kaum verwendet wird ist die Erfassung zusätzlicher Informationen, insbesondere width=*, smoothness=* und sac_scale=* für eine bessere Differenzierung in der Zukunft ebenfalls ratsam.

Fahrwege, Fußwege und Radwege sind nicht die einzigen Bereiche, wo im Standardstil gestrichelte Linien verwendet werden und auch anderswo führt dies teils zu Problemen. Dies betrifft insbesondere administrative Grenzen und teilweise trockene Wasserläufe. Es gibt im alternative-colors-Stil auch dafür schon einige Verbesserungen. Vielleicht ein Thema für einen zukünftigen Beitrag.

nz_980

19. Oktober 2017
von chris
Keine Kommentare

Neuseeland-Mosaik und 3d-Ansichten

Ich möchte hier ein neues Satellitenbild-Mosaik von Neuseeland vorstellen.

Dieses ist produziert auf Grundlage von Sentinel-2-Daten von 2015 bis 2017 und ähnelt in vielerlei Hinsicht meinen zuvor produzierten Zusammenstellungen, insbesondere was den hohen Grad an Wolken-Freiheit, die nahtlose Darstellung des Meeres und die Optimierung auf die Darstellung des Schnee-Minimums und des Vegetations-Maximums angeht.

Neu sind einige deutliche Verbesserungen im Verfahren zur Atmosphären-Korrektur, welche ich hier erstmals für ein größeres Projekt eingesetzt habe. Diese führen zu einer gleichmäßigeren und ausgeglicheneren Farbdarstellung. Und es ist das erste Mal, dass ich die passende Vegetations-Karte in der Sentinel-2-Auflösung von 10m erzeugt habe.

Hier einige Beispielausschnitte, mehr Beispiele findet man auf der Seite des Mosaiks auf services.imagico.de.



Ich hab auch ein paar neue 3D-Ansichten auf Grundlage dieser Bildzusammenstellung produziert, hier zwei davon:


Weitere 3d-Ansichten finden sich im Katalog auf services.imagico.de.

osm-name_980

12. Oktober 2017
von chris
Keine Kommentare

Den Dingen einen Namen geben – wie man geographische Vielfalt bei Namen abbilden kann

Es hat vor Kurzem ein bisschen Diskussion in OpenStreetMap zum Thema Namen und Beschriftungen gegeben, da einige Leute den Wunsch geäußert haben, die geographisch neutrale Beschriftung im OpenStreetMap-Standardstil abzuschaffen. Eines der Dinge, die die Diskussion mal wieder gezeigt hat ist, dass die Art und Weise, wie in OpenStreetMap Namen erfasst werden, einige grundsätzliche Probleme mit sich bringt und ich möchte dies hier mal kurz erläutern.

Das System der Namens-Erfassung in OpenStreetMap basiert auf der Idee, dass die Elemente in der Datenbank jeweils einen lokalen Namen haben können, das ist der Name, welcher am häufigsten lokal für das Objekt verwendet wird. Zusätzlich gibt es dann noch eine beliebige Zahl von weiteren Namen in verschiedenen Sprachen. Der lokale Name wird im name-Tag erfasst, die übrigen Namen in name:<language>-Tags wo <language> meist der Zwei-Buchstaben-Code der Sprache des Namens ist. Es gibt daneben noch andere Namens-Attribute wie alt_name (ein anderer lokaler Name, welcher auch verwendet wird) oder old_name (ein historischer Name, welcher nicht mehr in aktiver Verwendung ist).

Der OpenStreetMap-Standardstil stellt den Inhalt des name-Tags dar in der Absicht, den lokal verwendeten Namen darzustellen. Das ist eine der charakteristischen und herausragendsten Eigenschaften der Karte und demonstriert deutlich sichtbar die Verwurzelung von OpenStreetMap in lokalem Wissen und die Wertschätzung für die geographische und kulturelle Vielfalt. Dass es natürlich eine Menge Leute gibt, die mehr Wert darauf legen, dass es noch eine weitere Karte gibt (neben den hunderten kommerziellen Karten auf OSM-Basis, die man finden kann), wo sie die Namen alle lesen können, als darauf, dass es zumindest eine einzige Karte gibt, die für jeden lokalen Mapper auf der Welt im jeweiligen lokalen Gebiet lesbar ist, ist selbstverständlich – das ist aber nicht mein Thema hier.

Das Problem damit, den angezeigten Namen aus einem einzelnen Namens-Attribut für den lokalen Namen abzuleiten, liegt darin, dass es den lokalen Mapper oft in einen Konflikt stürzt zwischen dem Wunsch, tatsächlich den lokal dominierenden Namen einzutragen und dem Wusch, eine bestimmte Beschriftung in der Karte sehen zu wollen. Dies kann beeinflusst werden zum Beispiel von dem Wunsch nach einer Beschriftung in einheitlicher Form oder dem Ziel, die Karte besser für Fremde lesbar zu machen. Als Ergebnis dieses Konfliktes enthält das name-Tag oft zusammengesetzte Zeichenketten aus mehreren Namen in verschiedenen Sprachen, insbesondere in Regionen, wo lokal mehrere Sprachen verwendet werden und es eventuell gar keinen einzelnen lokal dominierenden Namen gibt.

Beschriftungen in mehreren Sprachen in Marokko

Beschriftungen in mehreren Sprachen in Korea

Die Lösung für dieses Problem besteht darin, die Illusion aufzugeben, dass es immer einen einzelnen lokalen Namen gibt, der überprüfbar erfasst werden kann. Stattdessen könnte man einfach wie jetzt auch schon die Namen in den verschiedenen Sprachen erfassen und daneben eine Formatierungs-Formel (format string), welche die lokal übliche Form der Namens-Darstellung wiedergibt. Der Schlüssel ist hier die mehrsprachige Erfassung der Namen von der Information über die lokal übliche Namens-Darstellung zu trennen.

Die Formatierungs-Formel müsste man dabei meist gar nicht für jedes einzelne Objekt angeben, denn meist werden ja die verschiedenen Namen in einem Gebiet alle gleich dargestellt. Die einzelnen Elemente würden also zweckmäßigerweise ihre Formatierungs-Formel von der administrativen Einheit, in der sie sich befinden, erben, es sei denn, es ist eine abweichende individuelle Formel erfasst.

Im Fall von Deutschland würde zum Beispiel die Grenzrelation für admin_level 2 (51477) so etwas wie language_format=$de erhalten – und es gäbe im Wesentlichen keine Notwendigkeit, in Deutschland weitere Objekte mit einer Formatierungs-Formel zu versehen – mit Ausnahme vielleicht einiger kleinerer Gebiete mit abweichender Sprache und einigen einzelnen Objekten, die ausschließlich in anderen Sprachen einen Namen haben. Die Schweiz (51701) bekäme language_format=$de/$fr/$it/$rm und für die verschiedenen Kantone gäbe es unterschiedliche Formeln je nach lokal verwendeten Sprachen.

Der Schlüssel-Wert und die Form der Formatierungs-Formel sind hierbei lediglich Beispiele, um die grundsätzliche Idee zu illustrieren – man könnte diese auch anders wählen.

Ich denke, dass dieses Konzept eine Reihe offensichtlicher Vorteile hätte:

  • Die Regeln für die Attribute der Namen in den einzelnen Sprachen sind deutlich klarer und besser definiert, so dass es weniger Raum für Willkür gibt und folglich die Daten verlässlicher für den Datennutzer werden, als wenn man das name-Tag interpretiert.
  • Der Wunsch lokaler Mapper nach einer bestimmten Darstellungsform in der Karte würde sich ausschließlich in der Formatierungs-Formel artikulieren und würde nicht auf die eigentlichen Namens-Daten abfärben.
  • Die Formatierungs-Formel bietet dem Daten-Nutzer eine deutlich größere Flexibilität – man kann sie komplett ignorieren, modifizieren oder durch eine eigene und global einheitliche Formel oder eine komplexere Funktion mit Fallbacks oder Transliteration ersetzen. Oder der Datennutzer kann sich entscheiden, entweder die individuellen Formatierungs-Formeln zu verwenden oder auschließlich jene, welche von den administrativen Einheiten geerbt wurden.
  • Das Problem mit den verschiedenen Schrift-Varianten für die selben Unicode-Zeichen in verschiedenen Sprachen (zum Beispiel bei Chinesisch/Japanisch/Koreanisch) würde ganz nebenbei hierdurch gelöst.
  • Die Namen in den einzelnen Sprachen als Datenquelle für die Beschriftung zu verwenden anstatt eines separat erfassten Beschriftungs-Attributes hat den Vorteil, für diese Namen eine Qualitätskontrolle über die Karte zu ermöglichen – was letztendlich zu weniger Fehlern und Inkonsistenzen in den Namens-Daten führen würde.
  • Man hätte eine einfache Fallback-Lösung für den Übergang: Wenn es entweder keine gültige Formatierungs-Formel gibt oder irgendeine der Sprachen in der Formel nicht verfügbar ist, könnte man auf das klassische name-Tag zurückgreifen.

Aber ich möchte auch die wichtigsten Nachteile dieses Ansatzes erwähnen:

  • Die Datennutzer erhalten keine bereits vom Mapper quasi handgemalte Beschriftung, die sie direkt verwenden können, sondern sie müssen stärker strukturierte Informationen in Form der Namen in verschiedenen Sprachen und der Formatierungs-Formel auswerten.
  • Damit die einzelnen Elemente ihre Formatierungs-Formel von den administrativen Einheiten erben können, muss man die räumlichen Beziehungen ermitteln und das ist zu aufwändig, um es jeweils bei Bedarf ad hoc zu machen. Man bräuchte folglich Unterstützung dafür bei den Daten-Konvertierungs-Werkzeugen, insbesondere denen für die Kartendarstellung (wie osm2pgsql, Imposm). Dies ist nicht trivial, insbesondere wenn man berücksichtigen möchte, dass eine Änderung der Formatierungs-Formel einer administrativen Einheit alle Elemente mit Namen innerhalb dieser Einheit potentiell beeinflusst.

Ein anderer möglicher Kritikpunkt wäre, dass die Formatierungs-Formel nicht überprüfbar ist. Aber es sollte recht offensichtlich sein, dass wenn das derzeitige name-Tag diese Anforderung erfüllt, dieses auch für die Formatierungs-Formel gilt, welche ja nur das selbe in abstrakter Form beschreibt.

alaska_autumn_crop1.ann

5. Oktober 2017
von chris
Keine Kommentare

Herbstfarben 2017

Es ist Herbst und das Laub beginnt sich zu verfärben – hier dazu passend ein paar Eindrücke vom Herbst im hohen Norden aus der Satelliten-Perspektive.

Das erste Bild zeigt den Yukon River an der Grenze zwischen Alaska und Yukon:

Hier zwei vergrößerte Ausschnitte daraus:

Das zweite Bild zeigt den südlichen Teil des Werchojansker Gebirge in Sibirien um den Tompo mit frischem Schnee in den Bergen. Die Gegend ist übrigens auch in meinem Herbstfarben-Mosaik vom letzten Jahr enthalten.

Auch hier zwei vergrößerte Ausschnitte:

Diese beiden Bilder sind auf Grundlage von Sentinel-2-Daten produziert. Das nächste Bild zeigt eine spät-herbstliche Ansicht vom Westen Spitzbergens um den Isfjord, aufgenommen von Landsat 8. Trotz der nördlichen Lage hält sich das warme Wetter dort teils noch bis recht spät in den Herbst so dass der Mitte September schon gefallene Schnee in dieser Ansicht vom 2. Oktober schon wieder fast weg getaut ist.

Und zum Abschluss eine großräumigere Ansicht vom Nordwesten Kanadas auf Basis von Sentinel-3-OLCI-Daten:

Die ersten drei Ansichten mit höherer Auflösung sind jetzt im Katalog auf services.imagico.de verfügbar: Alaska/Yukon, Sibirien und Spitzbergen.

lz_980

1. Oktober 2017
von chris
6 Kommentare

Über die Darstellung von Landbedeckung bei kleinen Maßstäben

Was ich hier vorstelle ist eigentlich was, an dem zu arbeiten ich für das OSM-Hack-Weekend diesen Herbstes geplant hatte aber ich habe beim ersten Vorbereiten davon recht schnell gute Fortschritte gemacht so dass ich entschieden habe gleich weiterzumachen. Wen das Thema interessiert der kann natürlich trotzdem gerne beim Hack-Weekend vorbeischauen um darüber zu reden.

In vielerlei Hinsicht knüpft dies an meine Arbeit vom letzten Jahr an der Darstellung der Wasserflächen bei den niedrigen Zoomstufen an, etwas, was bis jetzt leider noch keine weitere Verbreitung gefunden hat, vermutlich weil das Ganze für den typischen Karten-Entwickler ein ziemlich merkwürdiger und verwirrender Ansatz ist und ich mir auch nie die Mühe gemacht habe, eine echte Demonstration aufzusetzen. Auf der technischen Ebene ist das was ich hier vorstelle in gewisser Hinsicht eine Weiterentwicklung der Arbeit an den Wasserflächen, allerdings auch kombiniert mit einigen Gestaltungs-Ideen, die mir die letzten Monate gekommen sind.

Wasserflächen-Darstellung vom letzten Jahr

Die Erfassung von Landbedeckung (und ich verstehe als solche hier alles, wo in OSM ein Teil der Erdoberfläche aufgrund seiner physikalischen Eigenschaften oder seiner primären menschlichen Nutzung erfasst wird – Wälder, Ackerland, bebaute Flächen und so weiter) ist ein wichtiger Teil von OpenStreetMap und ein bedeutendes Alleinstellungsmerkmal des Projektes. Daten für Dinge wie Gebäude, Straßen oder Adressen sind – auch wenn es dies alles natürlich in OpenStreetMap gibt – in weiten Teilen der Welt auch aus anderen Quellen erhältlich und oft sogar in vergleichbarer Qualität. Alternative Quellen für Landbedeckungs-Daten von außerhalb von OSM jedoch sind gewöhnlich entweder ziemlich veraltet, basieren auf automatischer Klassifikation von Satellitendaten, was nicht immer zuverlässig funktioniert und worüber viele Unterschiede nicht erfassbar sind, oder die Daten stellen einen Soll-Zustand aus Perspektive lokaler Behörden und weniger einen Ist-Zustand dar.

Viele Karten auf OSM-Basis stellen Landbedeckung bei den hohen Zoomstufen dar – entweder in einheitlicher Farbe oder über Muster. Bei kleineren Maßstäben ist die Darstellung der Landbedeckung auch oft nützlich, insbesondere um urbane und ländliche Gebiete abzugrenzen und damit der Kartennutzer verschiedene Naturräume identifizieren kann, gerade auch dann wenn die Karte kein Relief darstellt. Bei kleinen Maßstäben geht es dabei meist nicht um die konkrete Form eines einzelnen Landbedeckungs-Polygons, sondern um die allgemeine Verteilung der verschiedene Flächen-Klassen. Und durch den variablen Maßstab der Mercator-Projektion treten bestimmte Anforderungen an die Darstellung bei recht unterschiedlichen Zoomstufen auf, je nachdem wo auf der Erde man hinschaut.

Auf Grundlage dieser Anforderungen gibt es bei der Darstellung in einheitlicher Farbe dann mehrere Möglichkeiten, wie man beim Herauszoomen vorgehen kann:

  1. Man lässt sukzessive einzelne Klassen der Landbedeckung weg. Dies ist was der OSM-Standardstil seit langem macht. Wasserflächen und Gletscher werden ab z6 gezeigt, Wälder ab z8 und die meisten übrigen Klassen ab z10. Das ist hochproblematisch aufgrund der subjektiven geographischen Präferenzen, die dadurch zum Ausdruck kommen. Auch wird durch das Weglassen die Lesbarkeit nicht unbedingt besser, insbesondere wenn die lokal dominierenden Landbedeckungen nicht weggelassen werden.
  2. Man lässt die Farben verblassen (vorzugsweise in einer farbneutralen und gleichmäßigen Form – nicht wie neuerdings in OSM-Carto) – ich würde sagen das ist das kartographische Equivalent zu give up and use tables.
  3. Man führt eine geometrische Generalisierung der Flächen durch. Dies ist schwierig, wenn das Ergebnis gut aussehen soll, insbesondere auf den sehr niedrigen Zoomstufen und wenn man eine größere Anzahl von Landbedeckungs-Klassen darstellen möchte und es ist letztendlich eine recht subjektive Darstellungsform und unvermeidbar recht spezifisch für den jeweiligen Verwendungszweck der Karte. Hier ein Beispiel einer rudimentären Visualisierung generalisierter Wald- und Siedlungsflächen sowie Gewässer.

Beispiel für generalisierte Landbedeckungs-Flächen

  1. Man stellt die Landbedeckung weiter genau wie auf den hohen Zoomstufen dar.
  2. Man kann die Landbedeckungs-Klassen für die niedrigen Zoomstufen in eine geringere Anzahl von Klassen zusammenfassen.

Die letzten beiden Möglichkeiten sind das, was ich hier demonstrieren möchte. Dies sind im Grunde keine praktisch verwendbaren Möglichkeiten, wenn man mit Mapnik oder vergleichbaren Renderern arbeitet, da man hierbei bei den niedrigen Zoomstufen sukzessive Probleme mit der Performance der Berechnung und mit Darstellungs-Artefakten bekommt (wie ich letztes Jahr im Zusammenhang mit den Wasserflächen erläutert habe). Man kann natürlich auch mit Mapnik & Co. ein Ergebnis für einen solchen Ansatz erhalten, das ist dann jedoch nicht wirklich noch eine Visualisierung der Daten, sondern das abstrakte Ergebnis eines Algorithmus, welcher für etwas verwendet wurde, wofür er eigentlich nicht gedacht ist.

Die Demonstration, die ich hier vorstelle, stellt die Landbedeckungs- und Gewässer-Flächen separat mit einer eigens dafür entwickelten Methode dar und ich kombiniere das dann mit dem separat und konventionell gerendertem Rest der Karte. Das ganze funktioniert nicht direkt, denn verschiedene Techniken im OSM-Standard-Kartenstil funktionieren nur, wenn auch die Landbedeckung in der selben Darstellung produziert wird. Ich musste deshalb einige Änderungen vornehmen, insbesondere verwende ich vorverarbeitete Daten für die Grenzen – was es auch erlaubt, endlich auf die Natural-Earth-Daten bei den ganz niedrigen Zoomstufen zu verzichten und die falschen Grenzen am 180-Grad-Meridian zu entfernen.

Landbedeckungs- und Wasser-Flächen allein in OSM-Carto-Farben bei z9

Die Karte zeigt die Zoomstufen 1 bis 9. Von z10 aufwärts stellt der Standardstil die meisten Landbedeckungen aus OSM dar obwohl die aktuelle Version dies unschön in verblassten und verzerrten Farben tut – eine Version ohne diese verblasste Darstellung bekommt man bei der Geofabrik. Für den alternative-colors-Stil hab ich derzeit keine Demo für die höheren Zoomstufen.

Ich könnte noch eine ganze Menge zu den Unterschieden im alternative-colors-Stil sagen, aber das würde hier ein bisschen am Thema vorbeigehen – vielleicht ein Thema für einen zukünftigen Beitrag. Für die Landbedeckung verwendet dieser Stil den Ansatz, beim Herauszoomen Landbedeckungs-Klassen zusammenzufassen. Hier eine Illustration dieses Zusammenfassungs-Schemas:

Wie die Landbedeckungs-Klassen zusammengefasst werden

Bei z9 und darunter gibt es vier Landbedeckungs-Klassen (zusätzlich zur Hintergrundfarbe für Gegenden ohne Landbedeckungs-Daten natürlich). Dazu zwei Gletscher- und drei Wasserflächen-Farben. Daneben noch die Farbe für Watt-Bereiche im Meer, welche separat dargestellt werden. Die Zusammenfassung der Klassen geschieht natürlich letztendlich nach subjektiven Maßstäben und was für Klassen in eine neue Über-Klasse eingehen ist oft keine einfache Entscheidung. Ich habe Friedhöfe zum Beispiel bei niedriger Vegetation eingeordnet auch wenn solche auch mit Bäumen bewachsen oder vegetations-frei eine können.

Da ich die Darstellung in separaten Ebenen produziert habe kann man die einzelnen Ebenen an und ausschalten und so die verschiedenen Varianten mit und ohne Landbedeckungs-Darstellung betrachten.

Landbedeckungs- und Wasserflächen für den alternative-colors-Stil

Mit Linien und Beschriftungen

Es gibt daneben auch eine Fallback-Ebene für die Landbedeckung im alternative-colors-Stil auf Basis der Green-Marble-Vegetationskarte. Diese Darstellung passt natürlich nicht perfekt zu der Definition der zusammengefassten Landbedeckungs-Klassen aber sie ist recht nahe dran. Dort wo die Landbedeckungs-Erfassung in OSM Lücken aufweist kann man diese Ebene zur Ergänzung nutzen und erhält so ein global gleichmäßigeres Kartenbild, welches weniger von der Vollständigkeit der Erfassung in OSM abhängt. Man könnte dies als potentielles Bild einer zukünftigen perfekten OSM-Datenbank interpretieren. Man sollte dabei jedoch beachten, dass die Landbedeckungs-Erfassung in OpenStreetMap nicht auf der Idee basiert, dass jeder Quadratmeter der Erdoberfläche in irgendeiner Form erfasst und klassifiziert werden soll – geschweige denn, dass alles was so erfasst wird auch sinnvoll in einer Karte wie dieser dargestellt werden könnte.

Normale Darstellung ausschließlich aus OSM-Daten

Mit Fallback-Ebene

Ich hab noch nicht über die technische Seite des Ganzen geschrieben, aber wie gesagt lässt sich diese Art der Darstellung nicht intern in Mapnik oder ähnlichen Programmen produzieren. Die Landbedeckung und Wasser-Flächen sind mit einem Supersampling-Ansatz gerendert, ein Verfahren, welches ich detaillierter schon bei den Wasserflächen erläutert habe. Das Verfahren ist im Grunde ein Gegenpol zur konventionellen Darstellung mit Programmen wie Mapnik – es funktioniert dort sehr gut wo etwas mit Mapnik extrem schwierig oder unmöglich ist während dort wo Mapnik glänzt dieser Ansatz meist nicht besonders geeignet ist. Das schöne an diesem Ansatz ist daneben, dass der aufwändige Teil des Darstellungs-Prozesses, das Erstellen des Sample-Caches, generisch ist, d.h. unabhängig ist von der eigentlichen Gestaltung mit den Farben und unabhängig von der Zoomstufe. Die beiden unterschiedlichen Farb-Schemata sind für alle Zoomstufen auf Grundlage des selben Renderings produziert. Ich habe im Moment keinen Veröffentlichungs-fähigen Code, denn die Implementierung ist recht rudimentär ohne eine wirkliche Schnittstelle, über die man die Parameter des Stils definieren kann. Einen Aspekt sollte ich noch erwähnen – da die Landbedeckungs-Daten mit Osmium verarbeitet wurden fehlen eine ganze Reihe defekter Geometrien, welche normalerweise in einer Darstellung aus einer osm2pgsql-Datenbank vorhanden wären.

Zur Demo-Karte – am Ende ist das natürlich für die meisten Anwendungen keine wirklich tolle Karte – dafür versucht sie, wie der OSM-Standardstil auf dem sie basiert auch – einfach zu viele Dinge gleichzeitig zu tun. Der Hauptzweck ist hier, eine Implementierung der Ansätze 4 und 5 in der Liste oben in solider Qualität zu zeigen. Meine eigene Meinung ist, dass dies die Ansätze 1 und 2 mit Leichtigkeit schlägt, insbesondere in Hinblick auf die Rückmeldung an Mapper und eine neutrale und unvoreingenommene Darstellungsform aber letztendlich muss das jeder selbst entscheiden. Auf jeden Fall ist das Ergebnis jedoch besser als jeder Versuch, Ansatz 4 oder 5 durch irgendwelche Tricks mit Mapnik zu implementieren.

Um die Demo-Karte zu sehen kann man auf jedes der gezeigten Beispiele klicken und kommt so zu der Karte in der jeweils im Beispiel sichtbaren Ebenen-Konfiguration. Da die Karte aus mehreren teiltransparenten Ebenen aufgebaut ist, müssen für die Anzeige deutlich mehr Daten geladen werden als bei anderen Karten, so dass die Darstellung etwas langsamer sein dürfte.

20. September 2017
von chris
Keine Kommentare

Umfrage zu organisiertem Mapping in OpenStreetMap

Die Data Working Group der OSMF hat eine Umfrage zum Thema organisiertes Mapping in OpenStreetMap gestartet.

Die Umfrage ist nur der erste Schritt im Prozess zu einer möglichen Regulierung organisierter Mapping-Aktivitäten und soll ein Meinungsbild der OSM-Community zum Thema produzieren, jedoch nicht direkt zu Entscheidungen führen. Die Idee, eine Regelung zu solchen Aktivitäten zu einwickeln ist ein recht wichtiger Schritt für das Projekt.

Ganz allgemein gibt es in OpenStreetMap nur sehr wenige feste Regeln, wie man Daten zu editieren hat. Es gibt einen allgemeinen Richtlinien-Satz mit grundlegenden Prinzipien in how we map und good practice – das ist jedoch mehr eine allgemeine Verfassung des Projektes und weniger konkrete praktische Gesetze, wie man sich zu verhalten hat, und auch mehr Regeln dazu, wie eingetragenen Informationen beschaffen sein sollen. Die einzige feste Verfahrens-Regel, die seit Beginn des Projektes Bestand hat, ist eigentlich, dass man nicht aus anderen Karten abzeichnen darf und nur erlaubte Quellen verwenden soll.

Dieses recht anarchische System funktioniert erstaunlich gut und macht Mapping damit zu einem weitgehend selbstorganisierten Prozess. Daten-Nutzer beschweren sich natürlich oft über die fehlende Konsistenz in den Daten, aber restriktivere prozedurale Regeln zu Mappen würden dies nicht unbedingt verbessern. Das bemerkenswerte ist nicht nur, dass das Ganze funktioniert, sondern vor allem auch, dass das im Prinzip global egalitärer und weniger kulturell voreingenommen ist als jedes denkbare System von von oben aufgesetzten Regeln. Mapper aus einer europäischen Großstadt haben im Prinzip die gleichen Freiheiten alles zu erfassen, was überprüfbar vor Ort zu beobachten ist und dabei Attribute zu verwenden, die dafür geeignet erscheinen wie Leute aus einem kleinen Dorf in einer entlegenen Ecke der Welt. Und wenn sich solche Leute irgendwo bei der Erfassung begegnen (also in der selben Gegend an den selben Objekten arbeiten), tun sie das auf der gleichen Augenhöhe. Es gibt daneben natürlich immer noch technologische und sprachliche Barrieren aber zumindest keine Verfahrensregeln, die zusätzlich diskriminierend wirken.

Dieses selbstorganisierte System funktioniert allerdings nur so lange die Mapper auch nach den Prinzipien der Selbstorganisation miteinander arbeiten. Wenn sich Mapper außerhalb des Projektes organisieren und dann in OpenStreetMap als organisierte Gruppe arbeiten, dann kann ein einzelner Mapper mit einer solchen Gruppe nicht mehr in der gewohnten Form interagieren und die Selbstorganisation bricht zusammen. Das ist der Grund, weshalb viele Mapper die Regulierung organisierter Mapping-Aktivitäten für notwendig halten und weshalb eine solche Regulierung jetzt von der DWG untersucht wird.

Allen, die irgendwie in OpenStreetMap involviert sind oder OpenStreetMap-Daten verwenden, würde ich nahelegen, an der Umfrage teilzunehmen.

delong_s2_980

6. September 2017
von chris
Keine Kommentare

Nochmal zur Positions-Genauigkeit von Satellitenbildern

Ich habe über das Problem der Positions-Genauigkeit von Satellitenbildern schon des öfteren geschrieben. Bei der Arbeit mit Bildern der Arktis für die Überarbeitung der Karte von Franz-Josef-Land sind mir dazu wieder ein paar Dinge aufgefallen, die ich hier teilen möchte.

Im Allgemeinen ist die verbreitete Meinung, dass die Positions-Genauigkeit von als offene Daten verfügbaren hochauflösenden Satellitenbildern im Grunde im Mittel ganz gut ist, jedoch nicht herausragend. Die Fehler, die hier von den Produzenten der Bilder angegeben werden, sind jedoch meist 90-Prozent-Angaben und deshalb nur begrenzt aussagekräftig. Das Ganze ist insgesamt ein recht komplexes Thema und es gehen eine ganze Reihe von verschiedenen Fehlerquellen da mit ein. Die Satellitenbild-Produzenten (in diesem Fall USGS und ESA) arbeiten daran, diese Genauigkeit zu verbessern, konzentrieren sich dabei jedoch hauptsächlich auf die relative Genauigkeit der verschiedenen Bilder zueinander (wodurch die Analyse von Zeitreihen verbessert wird) und weniger auf die absolute Genauigkeit.

Der am weitesten vernachlässigte Aspekt bei der Positions-Genauigkeit ist die Qualität der Reliefdaten, welche für die Relief-Korrektur verwendet werden. Die Argumentation ist dabei üblicherweise, dass

  • ein bestimmter Fehler in den Höhendaten üblicherweise bei einem Satelliten mit kleinem Sichtfeld der direkt nach unten blickt wie Landsat oder Sentinel-2 in einen deutlich kleineren Fehler in der Position umgesetzt wird.
  • die wichtigsten Teile der Erdoberfläche, also dicht besiedelte städtische Gebiete, sowieso im Flachland liegen wo Höhen-Ungenauigkeiten kein großes praktisches Problem darstellen.
  • solange für etwa 90 Prozent der Landflächen Reliefdaten ohne größere Fehler verfügbar sind der Rest keine Probleme bei den Fehler-Statistiken verursacht.

Wenn man jetzt aber die Teile der Welt außerhalb der 90 Prozent im Auge hat, bekommt man ziemlich deutliche Fehler. Sentinel-2 ist hier ein besonders gutes Studien-Objekt, denn (a) ist das Sichtfeld relativ breit so dass das ganze doch relative sensibel für Höhen-Fehler wird und (b) es ist bekannt, dass die ESA bei hohen Breiten Reliefdaten von viewfinderpanoramas.org verwendet, deren Eigenschaften direkt analysiert werden können.

Normalerweise treten die größten Fehler in Gebirgsregionen auf, Positionsfehler sind jedoch deutlich einfacher an der Küste zu vermessen und zu analysieren. Dort treten solche Fehler dann auf, wenn die Reliefdaten einen horizontalen Offset aufweisen und an der Küste Höhenwerte oberhalb des Meeres-Niveaus auftreten. Hier sind zwei recht eindrucksvolle Beispiele von solchen Unterschieden in der Küsten-Position in Bild-Paaren von Sentinel-2-Bildern, jeweils von etwa 100m. Das erste Beispiel zeigt die Bell-Insel in Franz-Josef-Land:

 

Das zweite Beispiel ist von der Bennett-Insel in den DeLong-Inseln:

 

Dieses zweite Beispiel ist auch aufschlussreicht dadurch, dass es zeigt, dass die ESA eine ältere Version der Reliefdaten verwendet ohne die neuere Aktualisierung, welche für die DeLong-Inseln die älteren und ungenaueren Daten mit Versatz und geringerer Genauigkeit durch bessere Daten ersetzt, wie ich sie hier vorgestellt habe:

 

Wie man sieht ist die Nordwest-Küste korrekt und verändert ihre Position nicht zwischen den beiden Bildern, denn dort liegen die Höhenwerte auch mit den falschen Reliefdaten auf Meeresniveau während an der Südküste durch die Höhenwerte über Null in den alten Reliefdaten (links im zweiten Vergleichsbild) die Küste verschoben ist.

Das Bildpaar der Bell-Insel stammt übrigens vom September 2016 mit vier Tagen Abstand, die Bilder der Bennett-Insel sind vom selben Tag (25. August diesen Jahres) von Sentinel-2A und Sentinel-2B.

fj_map_980

2. September 2017
von chris
Keine Kommentare

Aktualisierung der Karte von Franz-Josef-Land

Ich habe die Karte von Franz-Josef-Land aktualisiert mit neuen Daten auf Grundlage von Sentinel-2-Bildern und mit einer neuen Reliefdarstellung auf der Basis von ArcticDEM als Demonstration für die Verwendungsmöglichkeiten des neuen Reliefdatensatzes.

Franz-Josef-Land ist in ArcticDEM recht gut und mit nur wenigen kleinen Lücken abgedeckt, jedoch auch mit einer ganzen Menge von Artefakten, welche bei direkter Verwendung der Daten eine Kartendarstellung ziemlich ruinieren würden. Die Erkennung der Fehler ist nur teils automatisiert, nicht alle Artefakte können zuverlässig rein durch Analyse der Daten erkannt werden so dass für ein gutes Ergebnis eine manuelle Überprüfung notwendig ist. Zusätzlich zum Maskieren der Lücken und Artefakte und dem Füllen dieser Stellen mit einer Kombination von anderen Daten-Quellen und shape-from-shading-Techniken habe ich auch die Probleme bei der Höhen-Kalibrierung kompensiert, welche in meiner Besprechung von ArcticDEM erwähnt wurden, sowie die Wasserflächen eingeebnet.

ArcticDEM-Originaldaten mit Artefakten

korrigierte ArcticDEM-Daten

Da der Karten-Produktions-Prozess selbst mit der Platzierung der Beschriftungen und der Generalisierung vollständig automatisiert abläuft, ist die Aktualisierung der Daten-Basis und der Umstieg auf eine neue Relief-Daten-Quelle recht unproblematisch, was sehr nützlich ist, insbesondere für eine Karte von einem Gebiet, welches sich so schnell verändert wie dieses hier.

Die Ergebnisse kann man in der Karte von Franz-Josef-Land betrachten.

Wer gerne eigene Karten auf Grundlage dieser Daten produzieren möchte oder die Daten für andere Zwecke benötigt, findet diese auf services.imagico.de.

arcticdem_980

1. September 2017
von chris
Keine Kommentare

Review der ArcticDEM-Höhendaten

Einige Leser warten schon darauf – jetzt kann man meine Besprechung der ArcticDEM-Höhendaten lesen (auf Englisch), einem Datensatz, welcher in mehreren Schritten im Verlauf dieses Jahres von der Universität Minnesota und der US NGA produziert und veröffentlicht wird.

Wie so oft bei Höhendaten-Veröffentlichungen führt der erste Eindruck, den man von der Bewerbung der Daten durch den Produzenten bekommt, leicht dazu, dass sich beim Versuch der praktischen Nutzung erst einmal Enttäuschung breit macht. Dennoch ist dies eine interessante und durchaus wertvolle Datenquelle. Um herauszufinden, wo die Möglichkeiten und Grenzen liegen und auf was für Probleme man mit den Daten haben könnte, sollte man die Besprechung lesen.

Im nächsten Beitrag werde ich mich näher mit einer konkreten praktischen Verwendung der Daten beschäftigen.

osm-carto

24. August 2017
von chris
Keine Kommentare

OpenStreetMap-Carto – ein Blick in die Zukunft

Dies ist die Fortsetzung von meinem vorherigen Beitrag wo ich OpenStreetMap-Carto, dem Kartenstil, welche auf openstreetmap.org gezeigt wird, und dessen Entwicklung im Letzten Jahr betrachtet habe. Im zweiten Teil möchte ich jetz versuchen, ein bisschen in die Zukunft zu schauen.

Was bedeuten also diese Entwicklungen für die Zukunft von OSM-Carto? Das weiss ich natürlich nicht definitiv. Was für konkrete Änderungen stattfinden hängt davon ab, woran Entwickler jeweils interessiert sind und das ist schwer vorherzusagen. Aber es ist wahrscheinlich, dass die Änderungen in der Arbeitsweise, die ich im ersten Teil diskutiert habe, eine Auswirkung auf die Anreize und die Motivation für Beiträge haben. Was ich glaube zu erkennen, wenn ich jüngere Änderungen vergleiche mit Änderungen, die schon weiter zurück liegen – und zwar von einem gestalterischen Blickwinkel – ist, dass es eine gewisse Entwicklung mehr in Richtung naiver Kunst gibt. Das ist eine interessante Perspektive, welche man durchaus als passende Entsprechung zu den Methoden auffassen kann, mit denen in OpenStreetMap Daten erfasst werden. Jedoch ist die Datenerfassung in OSM – wenngleich sie meist nicht auf spezieller kartographischer oder geo-wissenschaftlicher Kenntnis und Ausbildung basiert – in den meisten Fällen durch ein hohes Maß an Raffinesse und Kenntnis charakterisiert und kann nicht wirklich als Analogie naiver Kunst charakterisiert werden.

Sollte OSM-Carto sich tatsächlich mehr in Richtung naiver Kunst bewegen, dürfte es vermutlich Konflikte mit dem hohen Maß an Komplexität und Raffinesse sowohl im eigenen Erbe des Stils als auch in den OpenStreetMap-Daten selbst geben. Wie dieser Konflikt gelöst wird ist eine interessante Frage. Auf einer mehr technischen Eben steht das auch im Zusammenhang mit einem Problem, welches ich vor etwa einem Jahr erläutert habe.

In der Vergangenheit war OSM-Carto oft Avantgarde hinsichtlich der Gestaltung von interaktiven digitalen Karten. Paul Norman hat vor kurzem in seinem SotM-Vortrag zu OSM-Carto (in der zweiten Hälfte des Videos) einige Beispiele dafür genannt, insbesondere die Auswahl von Beschriftungs-Größen auf Grundlage der Polygon-Größe, die systematische und automatische Auswahl von Farben auf Grundlage empfindungsgemäßer Farbräume und mehrsprachige Beschriftungen. Aus meiner eigenen Arbeit könnte ich hier noch Programm-generierte zufällige periodische Muster ergänzen, welche im Grunde zum ersten mal in OSM-Carto in größerem Umfang in der digitalen Kartographie verwendet wurden. Ich vermute, dass wir dies in Zukunft seltener sehen werden, denn die Entwicklung scheint sich jetzt mehr auf lokale Änderungen mit wenig Innovation und Koordination zu konzentrieren sowie Versuche (metaphorisch) Dinge hin und her zu schieben, um zu Testen, ob das besser aussieht, jedoch ohne ein tiefer gehendes Verständnis, weshalb gewisse Dinge funktionieren und andere nicht. Dies wird möglicherweise auch bewirken, dass sich der Stil mehr in Richtung des allgemeinen Trends von OSM-Karten bewegt, wie sie von kommerziellen Anbietern angeboten werden. Ob das Projekt auch weiterhin Entwickler anlocken kann mit dem Hintergrund und der Vision, innovative Lösungen für die großen Probleme zu entwickeln und ihnen eine unterstützende Arbeitsumgebung bietet, muss sich noch herausstellen.

Für den kritischsten Punkt in der zukünftigen Entwicklung von OSM-Carto halte ich die Frage, ob der Stil weiter erfolgreich seine Funktion als Mittel zur Rückmeldung an die Mapper erfüllen kann und dies bei der korrekten und präzisen Erfassung von Daten unterstützt. Richtig vorherzusehen, wie Mapper auf eine bestimmte Form der Darstellung ihrer Daten in der Karte reagieren, ist eine der schwierigsten Aufgaben eines OSM-Carto-Entwicklers und hierbei Fehler zu machen kann langfristig großen Schaden anrichten. Egal in welche Richtung genau sich der Stil entwickeln wird, dies ist der Punkt, den man genau im Auge behalten sollte. Wenngleich nützliche und konstruktive Rückmeldungen an die Mapper jetzt eines der dokumentierten Ziele des Stils ist, gibt es keine Regelungen dazu, die verhindern, dass Änderungen hier Schaden anrichten.

Meine Empfehlungen an diejenigen, denen das öffentliche Bild von OpenStreetMap und OSM-Carto am Herzen liegen sind:

  • Als Mapper sollte man dem Drang widerstehen, Seine Arbeit an die Verwendung der Daten in der Karte anzupassen – sowohl direkt als Mapping für den Renderer als auch indirekt, in dem man in einer Art und Weise Dinge erfasst, von der man glaubt, dass sie die Produktion einer gut aussehenden Karte vereinfachen – ich hab hierfür bereits vor Kurzem geschrieben.
  • Wer dies mag und kann, sollte bei der Stil-Entwicklung durch pull requests mit Änderungen mitmachen. Als nicht-Betreuer kann man nicht direkt Änderungen einbauen, aber man muss jetzt nur noch einen Betreuer von seiner Änderung überzeugen, damit diese in die Karte eingebaut wird.
  • Legt Wert darauf, dass die Betreuer des Stils für Ihre Arbeit verantwortlich sind und diese vor der OSM-Community und den sonstigen Nutzern des Stils verantworten müssen. Wie erläutert haben die Betreuer jetzt mehr Autonomie bei Entscheidungen, dass bedeutet jedoch auch mehr Verantwortung für die Änderungen. Das funktioniert natürlich nur, wenn die Kartennutzer auch Rückmeldungen zu den Änderungen geben. Man sollte dabei jedoch beachten, dass kommunizierte Abneigung gegenüber einer Änderung alleine nicht wirklich hilfreich oder überzeugend ist. Wer ein Problem im Stil beobachtet, welches nicht einfach ein klarer technischer Fehler ist, tut meist gut daran, das Problem anhand der dokumentierten Ziele des Stils zu erläutern.
  • Entwickelt alternative Kartenstile. Aus meiner Sicht ist dies der wichtigste Ratschlag von allen. Solange OSM-Carto ohne Alternativen ist, gibt es wenig Anreiz, den Stil substanziell zu verbessern. Dies würde sich ändern, wenn es andere Stile mit ähnlichen Zielen jedoch anderen Gestaltungs-Ansätzen gibt. Es gibt natürlich eine Vielzahl von Kartenstilen für allgemeine Anwendungen (nur wenige davon sind jedoch unter offenen Lizenzen) und es gibt eine Reihe von aus OSM-Carto abgeleiteten Stilen von lokalen OSM-Communities wie den französischen und den deutschen Stil. Daneben gibt es auch einige Stil-Varianten, welche als persönliche Projekte von einzelnen OSM-Aktiven entwickelt werden, beispielsweise hier. Was ich in den nächsten Jahren wirklich gerne sehen würde ist, dass wenigstens eine Hand voll unabhängige Kartenstile auf openstreetmap.org zur Anzeige verfügbar sind und jeder davon einen ehrlichen Versuch darstellt, eine gute Karte für die OSM-Community zu produzieren – selbst wenn dies mit weniger Arbeitskraft gemacht wird als bei OSM-Carto. Wenn man bedenkt, wie einflussreich die Karten für das Bild von OpenStreetMap sowohl von Außen als auch innerhalb durch die Mapper ist, wäre eine solche Entwicklung enorm produktiv und förderlich für die OSM-Community.
osm-carto

22. August 2017
von chris
Keine Kommentare

OpenStreetMap-Carto – ein Blick zurück auf das letzte Jahr

Vor etwa neun Monaten bin ich Mit-Betreuer von OpenStreetMap-Carto geworden, dem Kartenstil welcher auf openstreetmap.org gezeigt wird und in vielerlei Hinsicht das öffentliche Bild des OpenStreetMap-Projektes darstellt.

Während dieser Zeit gab es eine Reihe recht bedeutender Änderungen im Projekt, die meisten davon sind jedoch nicht unmittelbar sichtbar für den Nutzer der Karte. Ich möchte hier einen Blick auf diese Änderungen und den aktuellen Status des Projektes werfen, ein bisschen über seine Geschichte und seine Zukunft nachdenken, und ich möchte auch auf meine persönlichen Ziele des letzten Jahres in diesem Projekt zurückblicken und was ich davon erreicht habe und was nicht.

Ich habe bevor ich Betreuer wurde deutlich mehr an den eigentlichen Funktionen des Kartenstils gearbeitet als danach – was auch meinem Verständnis der Rolle eines Betreuers entspricht als jemandem der in erster Linie berät und beaufsichtigt. Meine Hauptziel nach der Ernennung zum Betreuer war es, klarere Ziele und Richtlinien für die Arbeit am Stil zu entwickeln und zu etablieren. Bis zu dem Zeitpunkt gab es so gut wie keine dokumentierten kartographischen Richtlinien in OpenStreetMap-Carto und für neue Mitwirkende am Projekt ist es oft schwierig einzuschätzen, was für Änderungen erwünscht ist und welche eher nicht.

Es ist mir gelungen, eine Reihe von Zwecken und Zielen für den Kartenstil zu definieren. Das ist recht wichtig, denn was der Zweck eines Kartenstils ist, ist keine einfache Frage, insbesondere bei einer Karte, die für so viele unterschiedliche Anwendungen eingesetzt wird wie OSM-Carto. Was ich jedoch nicht geschafft habe ist die Etablierung konkreter praktischer Richtlinien für die Entwicklung, welche den Zweck haben sollten, den Entwickler bei der praktischen Arbeit zu unterstützen. Meine Vorschläge hierzu fanden keine allgemeine Zustimmung und es gab auch keine Alternativvorschläge so dass wir uns letztendlich nicht auf etwas in dieser Richtung einigen konnten.

Dies bringt mich zu einer bedeutenden organisatorischen Änderung in OSM-Carto im letzten Jahr. Mit der Bestellung von drei zusätzlichen Betreuern ist die Gruppe der Betreuer sowohl größer als auch deutlich weniger homogen hinsichtlich Interessen, Hintergründen und Sichtweisen ihrer Mitglieder geworden. Hierdurch wurden Konsens-Entscheidungen zunehmend schwierig. Deshalb wurde die Entscheidung getroffen, das Konsens-Prinzip als Grundlage von Entscheidungen aufzugeben und den einzelnen Betreuern mehr Autonomie zu geben.

Im Grunde bedeutet dies, dass jeder Betreuer Änderungen machen oder Änderungen von Nicht-Betreuern akzeptieren kann selbst wenn andere Betreuer Einwände dagegen haben. Diese Änderung in der Arbeitsweise verhindert die Blockade von Änderungen am Stil, wenn kein Konsens dazu gefunden werden kann (was bis dahin recht oft vorkam), sie reduziert jedoch auch deutlich den Druck auf die Betreuer, eine gemeinsame Strategie und Vision für die Gesamt-Richtung des Stils zu entwickeln und zu erhalten.

Das Ganze macht durchaus Sinn für ein Projekt, welches Teil von OpenStreetMap ist, was ja weitgehend auf Prinzipien der do-ocracy aufgebaut ist. Jedoch wird sich erst mit der Zeit herausstellen, ob das Ganze in einem Karten-Gestaltungs-Projekt auch funktioniert. Das hat eine Menge damit zu tun, wie Methoden der Zusammenarbeit skalieren und wie sie Qualität sicherstellen. OSM-Carto ist was Kartenstile angeht ein recht großes Projekt. Gleichzeitig ist Gestaltungsarbeit nur sehr schwer in unabhängige Komponenten aufzuteilen, denn im visuellen Ergebnis hängt alles am Ende sehr stark zusammen. Meiner Meinung nach kann ein Projekt dieser Größe und Komplexität nur nach einem der folgenden Prinzipien funktionieren:

  1. Es gibt eine zentrale Autorität, welche letztendlich alle wichtigen Entscheidungen trifft. Dies war der Fall als bei OSM-Carto Andy noch der einzige Bertreuer war.
  2. Diejenigen in Entscheidungspositionen arbeiten zusammen und zwar nicht nur für gemeinsame Ziele, sondern auch mit einer gemeinsamen Vision dafür wie diese erreicht werden sollen. Dies erfordert ein großes Maß an Gemeinsamkeit und Kompatibilität zwischen denjenigen, die Entscheidungen fällen.
  3. Es gibt grundlegende Richtlinien für die Arbeit, welche universell gelten und letztendlich vom Projekt durchgesetzt werden, wodurch ein Mindestmaß an Homogenität und Konsistenz in den Ergebnissen sichergestellt wird sowie ein verlässliches Arbeitsumfeld für die Mitarbeiter. Dies ist zum Beispiel der Fall beim Mapping in OpenStreetMap. Die Richtlinien sind hier im Wesentlichen beschrieben unter How We Map und Good practice. Und diese Richtlinien werden letztendlich durch die DWG durchgesetzt falls die Mapper das nicht selber schaffen.

Der Punkt ist, dass der erste und zweite skizzierte Weg Probleme bereiten, wenn das Projekt sehr groß ist – wie zum Beispiel beim Mappen in OSM wo hunderttausende regelmäßig Beiträge leisten und wo diese Ansätze nicht funktionieren würden. Dies ist auch der Grund, weshalb OSM-Carto im letzten Jahr vom Konsens-Prinzip abgerückt ist. Für einen Kartenstil wie OSM-Carto wären diese Wege immer noch gangbar, jedoch würde dies eine recht strikte Hierarchie im Projekt und eine strikte Arbeitsteilung mit unterschiedlichen Aufgaben für die Beteiligten erfordern – was in einem offenen Gemeinschafts-Projekt nicht unbedingt funktioniert. Große kommerzielle Design-Projekte (man denke zum Beispiel an Architektur, Industrie-Design oder Mode) verwenden im Allgemeinen den ersten oder zweiten Ansatz. Oft gibt es daneben bei so was aber auch umfangreiche Dokumentierte Richtlinien zur Gestaltung. Die Frage welche bis jetzt niemand beantworten kann ist, ob der dritte Weg für ein kartographisches Design-Projekt wie einem Kartenstil auf Dauer funktionieren kann, insbesondere wenn es keine klaren praktischen Regeln für Gestaltungsentscheidungen gibt, die von Jedem akzeptiert werden und nach denen Änderungen bewerten werden.

Ein praktisches Problem mit Do-ocracy im Allgemeinen – und zwar noch mehr als bei anderen Organisations-Formen – liegt in dem permanenten Risiko, dass diese sich in eine Oligarchie der Leute in Machtpositionen entwickeln (welche diese erreichen, indem sie Dinge tun – deshalb ja auch do-ocracy) wo diese sich mehr darum bemühen, weiter Dinge tun zu können als darum, das Projekt offen und einladend für potentielle Mitarbeiter zu halten und dass es seinen Zweck erfüllt. Es gibt in Do-ocracy keinen inneren Mechanismus, durch welchen die beteiligten Leute sich um das Allgemeinwohl bemühen oder dafür belohnt werden, dies zu tun. Bei OSM als Ganzes und als Mapping-Projekt im Speziellen ist der wichtigste regulierende Effekt, dass niemand die ganze Welt alleine erfassen und aktuelle halten kann – oder auch nur eine Großstadt. Mit andere Mappern zusammen zu arbeiten – und zwar nicht nur mit einer Hand voll mit denen man viele Sichtweisen teilt, sondern mit einer großen Menge von Leuten weltweit – ist eine inherente Notwendigkeit der Erfassungs-Arbeit in OSM wodurch Do-ocracy hier weitgehend selbstregulierend wird. Bei einem Kartenstil jedoch, selbst wenn er so komplex ist wie OSM-Carto, ist dies anders. So etwas erfordert keine große Anzahl von Leuten, es lässt sich vermutlich sogar im Allgemeinen einfacher an so was Arbeiten, wenn bei den Entscheidungen nur eine kleine Anzahl von Leuten involviert ist. Natürlich ist OSM-Carto in der Vergangenheit bereits im Grunde ein aristokratisches/meritokratisches System gewesen, was auch eine Form der Oligarchie ist.

Eine andere große und eher technische Änderung in OSM-Carto im letzten Jahr war das Neuaufsetzten der Datenbank und der Wechsel zu einer hstore-Datenbank, wodurch endlich die Begrenzungen was für Tags im Stil verwendet werden können, weggefallen sind. Auch wurde in diesem Rahmen die Unterstützung für Multipolygone im alten Tagging-Stil abgeschafft. Diese Änderung ist im Grunde das Ergebnis von mehreren Jahren Arbeit. Ich war daran nur am Rande beteiligt. Obwohl diese Entwicklung nur recht wenige direkt sichtbare Wirkungen hat, ist sie eine wichtige Grundlage für zukünftige Änderungen.

In eine ähnliche Richtung ging der frühere Wechsel (von Ende 2016) zu Mapnik 3 und zu neueren CartoCSS-Versionen, was die Nutzung neuerer Funktionen erlaubte, welche zuvor nicht verwendbar waren. Dennoch ist der Stil nach wie vor oft vor allem durch den sehr konservativen Funktionsumfang von Mapnik und CartoCSS begrenzt, was eine Menge Dinge, die recht nützlich wären, entsätzlich aufwändig macht.

So weit mein Blick zurück auf das letzte Jahr. Im nächsten Beitrag werde ich dann ein bisschen in die Zukunft von OSM-Carto schauen.

landsat_engreenland_crop1.ann

22. August 2017
von chris
Keine Kommentare

Grönland am Abend

Aufgrund von recht schönem Wetter in weiten Teilen Grönlands im Juli und Anfang August gibt es eine ganze Reihe recht guter Satellitenbilder von Grönland von diesem Jahr. Ich habe diese Gelegenheit genutzt um zwei Abend-Bilder zusammenzustellen, beide hauptsächlich aus Landsat-Bildern vom Juli, also noch vor dem Schnee- und Eis-Minimum. Das erste Bild zeigt den Nordosten:

Diese Bild erstreckt sich über etwa 12 Grad Breite und illustriert recht gut, wie Nacht-Bilder bei Satelliten im sonnen-synchronen Orbit funktionieren. Am nördlichen Ende ähnelt das Bild im Grunde den normalen Tag-Bildern, beide nähern sich an der nördlichen Aufnahme-Grenze des Satelliten einander an, während sich die Beleuchtung weiter südlich mehr zum späten Abend verschiebt. Um das noch deutlicher zu illustrieren hier ein willkürlich ausgewählter Umlauf von Landsat (path 24 und 40 falls das jemand wissen möchte) mit den row-Nummern.

Row 246 ist die Grenze zwischen dem absteigenden Teil der Umlaufbahn auf der Tagseite und dem aAufsteigenden Teil auf der Nachtseite. Hier ein paar ungefähre Durchschnittswerte für die Sonnen-Richtung von Bildern mit dieser row-Nummer:

row Durchschnittliche Sonnen-Richtung
241 -74
242 -80
243 -87
244 -95
245 -105
246 -116
247 -125
248 -135
1 -144
2 -151
3 -158

Wie man sieht bewegt sich während der Satellit von der Nacht- zur Tagseite wechselt die Sonnen-Position von Nordwest (also Spätabend) über Westen nach Süden. Genau im Süden steht sie etwa bei row 9 (was etwa 72° Breite entspricht) und danach bewegt sich die Richtung weiter nach Südosten (also Morgen), was die typische Konfiguration bei niedrigeren Breiten darstellt.

Hier ein paar Ausschnitte aus verschiedenen Teilen des Bildes.

Ein Grund, weshalb solche Abend-Bilder besonders reizvoll sind – neben der dramatischeren Betonung des Reliefs durch den niedrigen Sonnenstand natürlich – ist, dass die Beleuchtungsrichtung mehr der Beleuchtung entspricht, die wir von schattierten Reliefdarstellungen kennen und solche Bilder deshalb weniger anfällig dafür sind, dass das Relief invertiert wahrgenommen wird, was bei der üblichen Morgen-Beleuchtung bei Betrachtern, welche nicht sehr geübt mit Satellitenbildern sind, recht häufig der Fall ist.

Das zweite Bild zeigt den Westen Grönlands von der Diskobucht nahe Ilulissat mit dem Jakobshavn Isbræ. Hier habe ich zusätzlich auch ein paar Bilder von 2016 verwendet.

Beide Bilder finden sich im Katalog auf services.imagico.de.