Imagico.de

blog

A Midsummer Night's Dream

9. Juli 2018
von chris
Keine Kommentare

Ein Sommernachtstraum

Hier ein paar weitere Eindrück von Landsat-Bildern vom Spätabend wie sie dieses Jahr in größerer Zahl vom USGS aufgenommen werden – von einer Reihe von Gebieten im Norden Europas und Asiens von Ende Juni und Anfang Juli:

Vom nördlichen Ural-Gebirge:

Im Norden Islands:

Im Norden Norwegens:

Vom Werchojansker Gebirge:

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

3. Juli 2018
von chris
Keine Kommentare

RadioOSM-Podcast zu OSMF-Themen

Es gibt eine neue Folge des RadioOSM-Podcasts zu verschiedenen Themen im Zusammenhang mit der OSMF, Themen, die auf dem Treffen des OSMF-Vorstands, welches vor einiger Zeit stattfand, eine Rolle spielten. Ich bin für den podcast als Gast eingeladen worden, da ich mich zu einigen der Themen in der öffentlichen Diskussion zuvor geäußert hatte. Ich hab die Themen mit Andi und Peda diskutiert, wobei Peda als OSMF-Vorstands-Mitglied die Themen vorgestellt hat und seine Perspektive aus dem Vorstand dargelegt hat (so weit er das ohne Verletzung der Vertraulichkeit des Treffens konnte). Das Ganze ist bereits vor etwa einem Monat aufgenommen worden – falls sich jemand wundert, warum neuere Entwicklungen nicht erwähnt wurden (es ist zu den Themen aber zwischenzeitlich auch nicht so viel passiert).

Ich sollte erwähnen, dass das natürlich nicht nur eine Diskussion in deutscher Sprache war, sondern dass dabei insgesamt auch eine bestimmte Sichtweise auf die Themen dominierte und nicht alle Meinungen dazu gleichermaßen Berücksichtigung fanden. Peda hat zwar die Meinungen der anderen Vorstandsmitglieder zu den Themen dargestellt, das ist aber natürlich nicht das selbe wie wenn diese Meinungen durch ihre Vertreter direkt in der Diskussion vertreten werden. Das ist sicher ein Nachteil darin, die Diskussion auf Deutsch zu führen – gleichzeitig erlaubte dies aber meiner Meinung nach auch eine Art der Auseinandersetzung mit den Themen, wie sie in einer Diskussion auf Englisch, wo natürlich Britische und Amerikanische Meinungen und Diskussionsstile meist dominieren, meist nicht möglich ist.

Ich möchte mich auch für meine recht krächzende Stimme am Anfang entschuldigen, es wird mit der Zeit etwas besser.

Ich hoffe, dass diese Diskussion zu hören und über die verschiedenen in der OSMF behandelten Themen zu lernen möglichst viele ermuntert, Mitglied in der OSMF zu werden, an den Diskussionen teilzunehmen und die OSMF im Interesse der Mapper zu formen. Ich hoffe daneben auch, dass eine solche Diskussion auf Deutsch anderen nicht englischen Muttersprachlern verdeutlicht, dass ein Diskurs zu politischen Themen in der OSMF nicht auf Englisch geführt werden muss, um von Bedeutung zu sein. Natürlich ist das auf Deutsch im Moment einfacher, denn es gibt zwei Deutsch sprechende Mitglieder im OSMF-Vorstand, welche nicht drumherum kommen, mitzubekommen, was auf deutsch diskutiert wird. Aber der erste Schritt ist immer erst einmal, eine Diskussion zu führen und Meinungen zu entwickeln und zu artikulieren. Und wir haben mittlerweile eine ganze Reihe von lokalen OSM-Vertretungen, welche – falls notwendig – die Interessen und Wünsche ihrer lokalen Gemeinschaft mit erheblichem Gewicht unterstützen könnten.

Falkland Islands in Winter

29. Juni 2018
von chris
Keine Kommentare

Winter und Sommer 2018

Wir hatten gerade Sommer-Sonnenwende und ich habe zu diesem Anlass zwei passende Satellitenbild-Zusammenstellungen auf Grundlage von Sentinel-2-Daten produziert.

Das erste Bild stammt vom Sommer im Norden und zeigt das Tauwetter im Nordosten Russlands an der Küste des Arktischen Ozeans. Der erkennbare Kontrast zwischen Norden und Süden im Bild ist nicht nur durch die geographische Breite bedingt, sondern auch dadurch, dass das Meer wesentlich langsamer und weniger in der Sommer-Sonne erwärmt als die Landflächen. Auf einer kleineren Größenskala lässt sich dies auch bei den Seen beobachten, wo kleinere bereits eisfrei sind, während auf größeren noch Eis-Reste schwimmen.

Das Auftauen des Landes geschieht jedoch nur an der Oberfläche. Der größte Teil des gezeigten Gebietes ist von Permafrost geprägt, denn obwohl die Sommer-Temperaturen recht weit steigen können, sind die Sommer kurz (von etwa Mitte Juni bis Mitte September) und die Winter lang und kalt.

Es dauert etwa einen Monat länger, bis auch das Meer eisfrei ist und im Herbst ist die Situation dann umgekehrt – eine durchgehende Schneedecke bildet sich meist Ende September während das Meer erst Ende Oktober wieder zufriert.

Das zweite Bild zeigt eine Winter-Ansicht der Falkland-Inseln. Zum Vergleich kann man einen Blick auf mein Sommer-Mosaik der Gegend werfen. Die niedrige Sonnen-Position führt hier zu einer dramatischeren Beleuchtung.

Auf den Falkland-Inseln gibt es auch gelegentlich Schneefall, der aber meist nicht länger liegen bleibt.

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

The way of the water

14. Juni 2018
von chris
Keine Kommentare

Der Weg des Wassers

Dies ist ein weiterer Beitrag in meiner Reihe zum Thema Gestaltung von OpenStreetMap-Karten – anknüpfend an was ich vor einiger Zeit zu Gewässern und Furten geschrieben habe.

Wasser-Barrieren

Im ersten Teil geht es um die Darstellung von Wasser-Hindernissen oder Wasser-Barrieren, damit sind Dämme, Schleusen-Tore und Wehre sowie Wasserfälle gemeint. Wie bei Furten können diese Hindernisse in OpenStreetMap alle als Punkte auf der Gewässer-Linie erfasst werden. Für Wasserfälle ist dies die einzige anerkannte Methode – die Reliefkante, über die der Wasserfall fließt, wird als Kliff erfasst. Der Standardstil stellt Schleusen-Tore und Wehre durch einfach Kreise dar, welche in der Zeichenbreite von Flüssen sehr spät ab z17 dargestellt werden. Dies sieht recht wenig ansprechend aus.

Mit Punkten erfasste Wehre und Schleusentore in der Darstellung aus OSM-Carto

Wasserfälle stellt OSM-Carto seit kurzem als einfache Punktsymbole dar – ebenfalls unabhängig von der Gewässerlinie.

Wie bei Furten gibt es natürlich auch hier die Möglichkeit, eine Liniengeometrie auf Grundlage der den Punkt schneidenden Gewässerlinie zu konstruieren. Für Dämme, Wehre und Schleusen-Tore erlaubt es dies, durch Punkte erfasste Objekte im selben Stil darzustellen wie als Linien erfasste Objekte. Und für Wasserfälle ermöglicht es eine kompakte und intuitiv verständliche Darstellung.

Ich habe auch die Darstellung von Wehren so angepasst, dass man die Fließrichtung des Wassers erkennen kann. Auch bei durch Punkte erfassten Schleusen-Toren und Wasserfällen ist dies möglich. Für Wehre und Wasserfälle dient hierzu eine das Wildwasser symbolisierende helle Linie unterhalb. Bei durch Punkte erfassten Schleusen-Toren wird die Linie mit einem leichten Knick gezeichnet, welcher die Öffnungsrichtung der Tore symbolisiert.

Wasser-Barrieren bei z12-z14, ein Klick zeigt die Darstellung bei z15

Wasser-Barrieren bei z17

Das Problem hierbei ist, dass mit den in diesem Kartenstil für die Darstellung verwendeten Werkzeugen (und im Grunde gilt das für alle verbreitet für solche Zwecke verwendeten Werkzeuge) diese Art von Darstellung recht schwierig zu implementieren ist. Die kreuzende Gewässer-Linie zu ermitteln ist offensichtlich etwas, das man auf der Datenbank-Ebene in SQL tun muss. Aber die dabei zu erzeugende Geometrie muss an die Darstellungs-Breite der Gewässer-Linie angepasst werden, man muss also die Geometrie-Erzeugung Zoomstufen-abhängig parametrisieren.

Hier ein paar praktische Beispiele, wie das Ganze im Ergebnis aussieht.

Wasserfall-Darstellung mit Hinweis auf die Fließrichtung bei z17

Darstellung eines Wehres mit Flißrichtung auf Grundlage einer Erfassung als Linie bei z16

Wasserfälle an einem waterway=stream bei z16

Als Punkte erfasste Schleusen-Tore bei z15

Als Punkt erfasstes Wehr bei z17

Mit dieser Darstellung, welche als Punkte und Linien erfasste Objekte im selben Stil anzeigt, stellt sich die Frage, welche Form der Erfassung die bessere ist. Das Problem dabei ist, dass Gewässer-Linien üblicherweise bei kleinen Maßstäben dicker gezeichnet werden als sie wirklich sind, damit sie gut sichtbar bleiben. Bei großen Maßstäben werden sie hingegen entweder dünner als in Wirklichkeit gezeichnet oder – falls ein Wasserflächen-Polygon existiert – in der realen Breite. Im einfachsten Fall ist die von mir konstruierte Linien-Geometrie so lang wie die Gewässerlinie in der Breite ist. Die Darstellung sieht folglich bei kleinen Maßstäben recht gut aus, bei größeren Maßstäben jedoch nicht mehr, falls es ein Wasserflächen-Polygon gibt und die Zeichenbreite der Barriere nicht an die Breite des Polygons angepasst wird.

Schleusen-Tore in einer Breite, welche der Zeichenbreite der Fluss-Linien entspricht

Wenn hingegen eine Wehr mit einer Linie über die gesamte Wasserfläche hinweg erfasst ist, sieht dies bei hohen Zoomstufen gut aus, nicht jedoch bei kleinen Maßstäben, denn die Linien-Geometrie ist dann zu kurz für die in diesem Fall breiter als in der Realität gezeichnete Fluss-Linie. Ich habe für diese zwei Fälle auch Lösungen implementiert, diese sind jedoch deutlich komplexer und aufwändiger als der erste einfache Fall.

Mit Berücksichtigung der Breite der Wasserflächen-Polygon

Um die verschiedenen Fälle besser zu verstehen hier das Ganze in Tabellen-Form, erst wie bei OSM-Carto dargestellt, dann mit den hier vorgestellten Techniken.

Punkt Linie
niedrige Zoomstufe
hohe Zoomstufe
Punkt Linie
niedrige Zoomstufe
hohe Zoomstufe

Insgesamt betrachtet ist also sowohl die Erfassung als Punkt als auch als Linie für den Zweck der Karten-Darstellung wie hier demonstriert eine brauchbare Basis. Die Erfassung mittels Polygonen hingegen ist – egal wie man Konkret die Umrisse eines solchen Polygons definiert – deutlich schwieriger zu interpretieren um eine hochwertige Darstellung in Karten zu produzieren. Für Dämme sind Polygone zur Erfassung weit verbreitet und akzeptiert. Für die übrigen Barriere-Formen hingegen ist dies – wenngleich in der Dokumentation klar nicht vorgesehen – auch erstaunlich verbreitet durch die weit verbreitete Fehlannahme, dass die Erfassung von Objekten als Polygone immer besser ist als jede andere Erfassungsform.

Für die Effiziente Darstellung wichtig ist aber vor allem Auch, die Wasserflächen-Erfassung der Flüsse in relativ kleinen Polygonen durchzuführen und nicht welche zu bauen, die sich über hunderte Kilometer erstrecken.

Ein weiteres Problem, welches aus den für die Darstellung verwendeten Werkzeugen resultiert ist, dass man für die Beschriftung alle diese recht komplexen Abfragen noch einmal durchführen müsste, denn die Beschriftung erfolgt in einer getrennten Darstellungsebene und man kann die Abfrage-Ergebnisse nicht zwischen verschiedenen Ebenen wiederverwenden. Für den Moment habe ich hierauf verzichtet so dass die Beschriftungen von Wasser-Barrieren einfach Punkt-Beschriftungen sind und nicht in die Zeichen-Richtung der Barriere ausgerichtet sind.

Ich bin mir nicht ganz sicher, wie diese Darstellungsform als Rückmeldung an Mapper wirkt. In den meisten relativ einfachen Fällen denke ich, dass eine Darstellung auf Grundlage einer Vernünftigen und konsistenten Interpretation der Daten wie ich sie hier durchführe in Ordnung ist, selbst wenn sie recht weit über eine einfache und direkte Visualisierung der Daten hinaus geht. Und meiner Meinung wird dadurch auch die positive Nachricht kommuniziert, dass eine recht einfache Erfassungs-Form (wie ein Punkt, welche eine Barriere auf einer Gewässer-Linie repräsentiert) ausreichend Informationen für eine präzise Darstellung beinhaltet und es nicht erforderlich ist, dass der Mapper quasi per Hand die Karte zeichnet. Aber insbesondere in den zwei komplizierteren Fällen (die Erfassung als Punkt bei hohen Zoomstufen und mit einem Wasserflächen-Polygon und die Erfassung als Linie bei niedrigen Zoomstufen) ist es recht wahrscheinlich, dass es Fälle gibt, wo die vorgestellten Methoden nicht gut funktionieren und dies zu einem nicht intuitiven Ergebnis führt. Wie problematisch dies wäre ist aber eine offene Frage. Dies ist auf jeden Fall ein Thema für das es deutlich zu wenig praktische Erfahrungen gibt um verlässliche Schlussfolgerungen zu ziehen.

Wasser-Quellen

Die zweite Änderung, die ich hier vorstellen möchte, betrifft das Aufräumen bei den inzwischen recht chaotischen Darstellungen von Punkt-Symbolen mit Wasser-Bezug in OSM-Carto. Eines davon – den Wasserfall – habe ich schon oben diskutiert. Die anderen zwei Symbole mit Wasser-Bezug in OSM-Carto sind im Moment Springbrunnen und Quellen. Zusammen mit den Wasserfällen werden für diese drei Objekt-Klassen drei verschiedene Farben verwendet was gestalterisch ziemlicher Unsinn ist.

Aber bevor ich das verbessern konnte, musste ich mich um ein anderes Problem kümmern. Der Standardstil verwendet seit langer Zeit einen Kräftigen Blau-Ton für die Darstellung von Symbolen mit Bezug zu Fortbewegung und Unterkunft – zum Beispiel Bushaltestellen, Parkplätze, Hotels, Campingplätze usw. Diese Verwendung von Blau hat zwar eine lange Tradition in OpenStreetMap – ist aber für ein intuitives Verständnis der Karte nicht ideal und steht im Konflikt mit der Verwendung von Blau für die Darstellung von Dingen mit Wasser-Bezug, wofür ein kräftiges Blau auch nützlich sein kann. Ich hab folglich die Symbol-Farben ein wenig um-organisiert – indem ich die Verwendung von Violett, zuvor nur für Lufttransport-Objekte eingesetzt, auf die Symbol-Klassen ausgedehnt habe, für die zuvor das kräftige Blau Verwendung fand. Daran muss man sich natürlich erst ein bisschen gewöhnen. Gleichzeitig habe ich auch die Verwendung von Grün für Freizeit-Symbole abgeschafft, welche vor einiger Zeit eingeführt wurde und welche – ähnlich wie bei Blau – eigentlich auf Objekte mit Vegetations-Bezug beschränkt bleiben sollte.

Violett für Symbole mit Bezug zu Fortbewegung und Unterkunft

Hierdurch wird das kräftige Blau frei für die Verwendung für Punkt-Symbole mit Wasser-Bezug.

Die Darstellung von Quellen ist in OSM-Carto vor kurzem geändert worden aber nicht wirklich in einer sehr vorteilhaften Form. Die Haupt-Motivation für diese Änderung war es, das alte Symbol mit einer ‘s’-Form abzuschaffen, was für ‘spring’ steht und für eine internationale Karte offensichtlich nicht optimal ist. Aber man sollte sich dabei klar machen, dass das alte Symbol als geometrisch einfaches Punkt-Symbol für die Verwendung bereits bei recht niedrigen Zoomstufen recht gut funktioniert hat, denn es ist sehr kompakt und wenig aufdringlich und gleichzeitig recht klar und wiedererkennbar.

Darstellung von Quellen in OSM-Carto – alt (links) und neu (rechts)

Die neue Symbol-Gestaltung ist – wenngleich mit guten Absichten entwickelt – aus verschiedenen Gründen nicht optimal:

  • Das generische Kreis-Symbol ist sehr wenig spezifisch und kann auf eine Vielzahl von Objekt-Typen mit Wasser-Bezug hindeuten (oder ohne Wasser-Bezug, denn das kräftige Blau kommt ja auch anderweitig zum Einsatz).
  • Das Symbol ist größer und auffälliger ohne dass es gleichzeitig klarer und besser lesbar ist als das alte. Es erzeugt erhebliche Unruhe in der Karte, insbesondere bei niedrigen Zoomstufen.
  • Die Zeichen-Reihenfolge platziert das Symbol unterhalb der Gewässer-Linien, was eine ganze Reihe von Problemen bewirkt, insbesondere indem es eine Abhängigkeit von der Reihenfolge der Wasser-Ebenen erzeugt (wo die Gewässer-Linien über den Flächen gezeichnet werden), was eine recht starke Einschränkung darstellt.

Mein Ansatz ist hier, die selbe Grundform für verschiedene Wasser-Quellen-Objekte zu verwenden und durch Variation des Symbols verschiedene Objekt-Klassen zu differenzieren. Das Symbol ist dabei sehr kompakt gestaltet so dass es bei den niedrigen Zoomstufen nicht nennenswert mehr Platz einnimmt als das ursprüngliche ‘s’-Symbol. Die Symbol-Größe wird dann zwei Zoomstufen oberhalb etwas vergrößert um die Lesbarkeit zu verbessern. Hier ist gezeigt, wie das Ganze aussieht. Brunnen werden eine Zoomstufe später angezeigt als Quellen (z15 und z14) und Springbrunnen ab z17.

Darstellung von Wasser-Quellen bei z14, z15 und z16

Darstellung von Wasser-Quellen bei z17, ein Klick zeigt die Darstellung bei z18

Wie man sieht ist die Grundform des Symbols die selbe für mit Gewässer-Linien verbundene und isolierte Quellen so dass man erkennen kann, dass es sich um den selben Objekttyp handelt. Aber die Darstellung in Verbindung mit einer Gewässer-Linie muss natürlich an deren Gestaltung angepasst werden, so dass beide Formen nicht exakt indentisch aussehen. Und ich habe die Darstellung von heißen Quellen und Geysiren ergänzt. Diese werden mit einem roten Punkt in der Mitte dargestellt. Nur zeitweilig wasserführende Quellen sind auch durch eine Symbol-Variation unterschieden. Bei den höheren Zoomstufen sieht man außerdem neue Symbole für amenity=water_point und man_made=water_tap.

Die Darstellung von mit Gewässer-Linien verbundenen Quellen ist implementiert, indem ich die Geometrie aus SQL heraus erzeuge. Wie bei den Wasser-Barrieren erfordert dies die Parametrisierung mit der Darstellungs-Breite der Gewässer-Linie in Abhängigkeit von der Zoomstufe auf SQL-Ebene. Ein alternativer Ansatz wäre es, SVG-Symbole zu verwenden und diese passend zu rotieren. Aber man bräuchte hierfür eine recht große Anzahl unterschiedlicher SVGs für die verschiedenen Linienbreiten so dass das Ganze am Ende kaum weniger aufwändig wäre.

Eine weitere Neuerung ist die Darstellung eines zusätzlichen Becher-Symbols neben dem Haupt-Symbol bei höheren Zoomstufen für Objekte mit einem zusätzlichen Attribut amenity=drinking_water oder drinking_water=yes. Dies ist eine weitere Anwendung, bei der die Einschränkungen der verwendeten Werkzeuge sichtbar werden. Idealerweise würde man das Zusatz-Symbol dort platzieren, wo Platz vorhanden ist. Ich glaub jedoch nicht, dass dies mit den für diesen Stil verwendeten Werkzeugen möglich ist. Folglich habe ich einfach eine konstante Nordwest-Position gewählt. Was im Grunde möglich wäre ist die Positionierung bei mit Gewässer-Linien verbundenen Quellen so, dass das Symbol nicht über die Linie gezeichnet wird.

Die kleinen Symbole für Wasser-Quellen werden mit einem dünnen Weißen Rahmen gezeichnet, so dass sie vor einem dunklen oder strukturierten Hintergrund besser sichtbar sind. Hier ein paar praktische Beispiele dafür, wie das Ganze in der Karte aussieht.

Mit Gewässer-Linien verbundene Quellen bei z15


Brunnen bei z16


Isolierte Quelle bei z16


Mit waterway=stream verbundene Quelle bei z18


Springbrunnen und Brunnen bei z17


Springbrunnen und Brunnen bei z18

Zusammenfassung

Was ich hier vorgestellt habe sind eine Reihe von kartographischen Gestaltungs-Techniken, welche dabei helfen können, bessere Karten zu produzieren:

  • Die Verwendung von räumlichen Beziehungen zwischen verschiedenen Karten-Elementen (konkret: Punkt-Objekte mit Wasser-Bezug und die Gewässer-Linie auf der sie sich befinden) für ein harmonischeres und weniger unruhiges Kartenbild und für zusätzliche Informationen (wie die Wasserfluss-Richtung) für den Karten-Nutzer.
  • Die Verwendung subtiler Symbol-Variationen um leicht unterschiedliche Objekt-Typen darzustellen und um zusätzliche Informationen zu transportieren ohne dass die Interpretation der Karte deutlich komplizierter wird. Verwendung von kombinierten Symbolen aus mehreren Komponenten für zusätzliche Informationen (hier: Die Verwendbarkeit von Wasserquellen als Trinkwasser).
  • Die Verwendung einer vereinfachten Symbol-Variante bei kleineren Maßstäben für eine kompaktere Darstellung.
  • Die Vereinheitlichung verschiedener Erfassungsformen (hier: Erfassung von Wasser-Barrieren als Punkte und Linien) in einem einheitlichen Design für verschiedene Maßstäbe.

Wie immer findet man die vorgestellten Änderungen zum Studieren und Testen im alternative-colors-Stil.

Landsat evening view of Jan Mayen - May 2018

8. Juni 2018
von chris
Keine Kommentare

Ein weiteres Abend-Bild

Im vorigen Beitrag habe ich ein Beispiel für die ausgeweiteten Nachtseiten-Aufnahmen von Landsat 8 bei hohen geographischen Breiten dieses Jahr gezeigt. Hier ein weiteres Beispiel von der Insel Jan Mayen mit der ungewöhnlichen Spätabend-Beleuchtung und einer hübschen Wolken-Einrahmung.

Landsat-Spätabend-Ansicht von Jan Mayen – Mai 2018

Ich habe letztes Jahr bereits etwas umfassender über die von Satelliten in Sonnen-synchroner Umlaufbahn aufgenommenen Abend-Bilder bei hohen Breiten geschrieben.

Zum Vergleich kann man ein Blick auf mein Jan-Mayen-Mosaik auf Grundlage von normalen Morgen-Bildern von später im Jahr werfen.

LC81782382018115LGN00_expose.ann

5. Juni 2018
von chris
Keine Kommentare

Satellitenbild-Neuigkeiten

Es sind seit meinem letzten Bericht über Neuigkeiten in der Welt der offenen Satellitendaten eine ganze Reihe von Dingen passiert.

Die bedeutendste Änderung ist, dass Sentinel-2 nun in den meisten Teilen der Welt deutlich häufiger Bilder aufnimmt. Hier eine aktualisierte Darstellung des Aufnahme-Volumens:

Entwicklung der Bild-Abdeckungen von offenen Satellitendaten

Es gibt auch aktualisierte Visualisierungen zur Satellitenbild-Abdeckung.

Die Ausweitung des Aufname-Volumens (auf etwa die 1.5-fache Fläche im Vergleich zu vorher) wird durch die Datenübetragung mittels optischer Verbindung zu Satelliten im geostationären Orbit ermöglicht. Wie bereits im vorherigen Bericht angedeutet wird das zusätzliche Volumen hauptsächlich dazu verwendet, die bevorzugte Aufnahme von Europa und Afrika zu beenden so dass jetzt alle größeren Landmassen außer der Antarktis von jedem Satelliten in einem zehn-Tages-Intervall aufgenommen werden, zusammen alle fünf Tage. Wie ich auch schon erwähnt hatte werden auch einige Inseln neu aufgenommen, welche zuvor nicht dabei waren. Um das zu sehen hier die Aufnahme-Zahlen für das Kalenderjahr 2017 und die noch unvollständigen Zahlen für 2018.


Bei den neu aufgenommenen Inseln handelt es sich vor allem um Britische Übersee-Territorien. Zusätzlich zu den Inseln selbst wurde teilweise auch ein erheblicher Bereich des Meeres drumherum aufgenommen. Dies unterscheidet sich etwas zwischen Sentinel-2A und Sentinel-2B und es scheint so, als ob dies nach einiger Zeit wieder aufgegeben wurde.

Es gibt auch getrennte Karten für Sentinel-2A 2017, Sentinel-2B 2017, Sentinel-2A 2018 und Sentinel-2B 2018.

Ich muss sagen, dass ich es ziemlich nervig finde, dass trotz des erweiterten Aufnahme-Volumens jetzt nach wie vor speziellen Interessen enormer Raum eingeräumt wird. Es gäbe jetzt ohne weiteres die Möglichkeit, alle Landflächen in einem Abstand von fünf Tagen aufzunehmen – vermutlich einschließlich der Antarktis, ein bisschen abhängig davon bei welchem Sonnenstand man im Winter die Grenze zieht. Man müsste dafür ein bisschen die Aufnahmen bei hohen Breiten im Norden reduzieren aber man kann nicht wirklich ernsthaft dafür argumentieren, den Norden Grönlands mehr als einmal täglich aufzunehmen, verschiedene kleinere Inseln jedoch nie.

Die größten derzeit überhaupt nicht aufgenommenen Inseln sind die Südlichen Orkneyinseln.

Zu den anderen Neuigkeiten:

  • Es gibt einen neuen Bericht zum Datenzugang im Copernicus-Programm. Letztes Jahr habe ich diesen detaillierter diskutiert. Der neue Bericht hat genauso wie letztes Jahr ein recht schlechtes Signal-Rausch-Verhältnis aber es gibt da auch eine Reihe von interessanten Fakten:
    • Die Verfügbarkeit des Datenzugangs – welche im vorherigen Jahr sehr schlecht war wie die meisten Datennutzer aus eigener Erfahrung wissen – hat sich deutlich verbessert.
    • Die Verzögerung bei der Veröffentlichung von Sentinel-2-Daten ist nach wie vor recht groß, erkennbar zum Beispiel daran, dass 16 Prozent der Pakete erst mehr als 48 Stunden nach der Aufnahme verfügbar sind. Und dabei sind die Pakete, die komplett fehlen und nie veröffentlicht werden (worüber ich füher schon mal geschieben habe) vermutlich noch nicht enthalten. Das muss man auch im Zusammenhang damit sehen, dass mehr als die Hälfte der heruntergeladenen Pakete weniger als zwei Tage alt sind. Eine verlässliche Verfügbarkeit der Daten ist eine der Schlüsse-Kriterien für die routinemäßige Datennutzung.
    • Der Trend scheint zu sein, dass der Zugriff über den offenen Datenzugang deutlich schneller zunimmt als über andere Kanäle. Und die Nutzung der Dienste weltweit wächst stärker als in Europa.
    • Der Bericht erwähnt auch so weit ich weiß zum ersten Mal Pläne für den längerfristigen Datenzugang. Bis jetzt sind ja alle Daten seit Beginn der Aufzeichnung für den unmittelbaren Datenzugriff verfügbar, was eine ziemlich große und ständig wachsende Datenhaltung für den Direktzugriff erfordert. Dies soll sich in der Zukunft ändern und zwar ähnlich wie beim USGS. Man wird also ältere Produkte anfordern müssen und diese werden dann mit einiger Verzögerung zugänglich gemacht. Die skizzierten Pläne dafür sind recht präzise und vernünftig – die Verzögerung soll bei maximal 24 Stunden liegen und die Anforderung soll automatisiert möglich sein.
  • Die ESA hat angekündigt, dass sie planen, die größeren Daten-Pakete von Sentinel-2 mit mehreren Kacheln aus dem ersten Betriebsjahr neu in Einzelkachel-Pakete zu verpacken. Eine wirkliche Neuverarbeitung der Daten ist nicht vor 2019 geplant.
  • Sentinel-3B, der letzte der Satelliten des Copernicus-Programms, wurde im April mit viel PR-Getöse gestartet. Es gibt noch keine Daten und die Erfahrungen mit Sentinel-3A lassen vermuten, dass sich dies auch nicht so schnell ändern wird. Selbst von Sentinel-3A werden ja nach wie vor einige der höheren Bearbeitungsstufen der Daten nicht öffentlich zugänglich gemacht.
  • Der USGS hat die Möglichkeiten zum Gesamt-Download von Landsat-Metadaten stark eingeschränkt. Man kann nach wie vor die Gesamt-Pakete herunterladen aber sie sind nicht ganz aktuell und zumindest für Landsat 7 sehr unvollständig. Darüber hinaus kommt man jetzt nur über EarthExplorer an die Metadaten und nur per Hand, also nicht in automatisierbarer Form. Das macht eine automatische Auswertung wie ich sie weiter oben gezeigt habe deutlich schwieriger. Es scheint fast so als würden sich USGS und ESA hier annähern.
  • Ansonsten läuft der Landsat-Betrieb weitgehend wie bisher. Der USGS scheint für 2018 die Aufnahmen auf der Nachtseite bei hohen Breiten deutlich auszuweiten. Hier die Darstellung für alle Aufnahmen von 2017 im Vergleich zu den bisherigen Aufnahmen von 2018. Ein Beispielbild findet sich weiter unten.
  • Die Pläne zum Start von Landsat 9 Ende 2020 sind anscheinend recht weit fortgeschritten – es gibt ja auch nicht viel Spielraum denn Landsat 7 wird wenig später das Ende seiner nützlichen Lebensdauer erreichen.

Bennett Island am späten Abend im Frühling

Ein anderes Thema, welches ich noch erwähnen wollte: Es gab einige Aufregung darum, dass die US-Regierung anscheinend darüber nachdenkt, die Entscheidung für freien Datenzugang für Landsat zu revidieren. Dies wurde angestoßen von einem Artikel hier. Es scheint mir, als hätte die Empörung darüber etwas den Blick auf den eigentlichen Hintergrund davon verstellt. Die meisten Leute, die ihren Widerspruch zu dieser Idee kundgetan haben, argumentieren, dass es insgesamt betrachtet von einem wirtschaftlichen Standpunkt keinen Sinn macht, dies zu tun, denn sowohl die Privatwirtschaft als auch die Wissenschaft profitieren so sehr von den offenen Landsat-Daten, dass dies die Kosten mehr als kompensiert.

Das Problem ist jedoch, dass politische Entscheidungen so nicht funktionieren. Politische Entscheidungen sind eine Frage von Interessen und von Macht und Einfluss, welche dahinter stehen. Welche Interessen den größten Einfluss auf den Entscheidungsprozess haben ist in diesem Fall schwer vorherzusagen aber man kann wahrscheinlich davon ausgehen, dass die Wissenschafts-Lobby hier kein nennenswertes Gewicht hat, insbesondere mit der derzeitigen US-Administration.

In jedem Fall dürfte die wahrscheinlichste unmittelbare Wirkung dieser Diskussion auf der politischen Ebene auf den zukünftigen Budget-Rahmen und die Fähigkeiten des Landsat-Programms gerichtet sein. Landsat 9 (der wie erwähnt Ende 2020 gestartet werden soll) wird weitgehend eine Kopie von Landsat 8 sein. Die Diskussion um die Konzeption und die Fähigkeiten eines zukünftigen Landsat 10 ist gerade im Gange und mir scheint, dass das Timing der politischen Diskussion eventuell darauf ausgerichtet ist, genau hier Einfluss zu nehmen.

Und was einige Leute anscheinend auch vergessen ist, dass man offene Daten nachdem sie einmal für die freie und uneingeschränkte Nutzung veröffentlicht sind, nicht mehr wieder verschießen kann. Das Landsat-Daten-Archiv wird also frei nutzbar bleiben (wenn auch nicht unbedingt über den USGS zugänglich) – selbst wenn in der Zukunft die US-Regierung entscheiden sollte, dass neue Bilder nicht mehr frei verwendet werden dürfen.

Lützow-Holm Bay

25. Mai 2018
von chris
Keine Kommentare

Warum OpenStreetMap offene Satellitenbild-Daten braucht

Ja, ich hab diesen Punkt schon früher herausgestellt aber hier ist ein wirklich gutes Beispiel warum OpenStreetMap im Streben danach, die beste Karte der Welt zu produzieren, nicht auf die zur Nutzung freigegebenen Bild-Dienste kommerzieller Anbieter mit proprietären Bildern vertrauen kann um überall dort, wo man es braucht, Bilder bereit zu stellen.

Hier ein Gebiet an der Nordost-Küste des Kaspischen Meeres, wo vor kurzem ziemlich ausgedehnte Strukturen gebaut worden sind – insgesamt etwa 50 Kilometer lang und vermutlich im Zusammenhang mit dem nahen Kashagan-Ölfeld, welches man etwas weiter nordwestlich im Bild findet.

Keines davon (weder die Strukturen an der Küste noch das Ölfeld) finden sich in irgendeinem der verschiedenen für OSM nutzbaren globalen Bilddienste. Einer zeigt eine Baustelle an der Küste in einem frühen Zustand. Und weder das eine noch das andere ist derzeit in OpenStreetMap halbwegs ordentlich erfasst.

Außer diesem Bild hab ich auch noch ein paar weitere Bilder bei den OSMIM hinzugefügt – ein neuses Bild von 2018 von der Nordseeküste bei Niedrigwasser, ein neues Bild der Straße von Kertsch mit der fertigen Brücke – die Brücke ist in OSM schon gut erfasst aber einige der Änderungen an der Küste, der Bau von Zufahrtsstraßen und sonstige Veränderungen in der Umgebung könnten noch Aktualisierungen vertragen. Und schließlich hab ich immer noch nicht aufgegeben, die OSM-Mapper zu ermuntern, an einer besseren Erfassung der Antarktis zu arbeiten – mit einem weiteren interessanten Gebiet an der antarktischen Küste auf Grundlage neuerer Bilder. Ich sollte vermutlich auch mal betonen – weil das wahrscheinlich garnicht jedem klar ist – dass es nirgendwo auf der Erde so einfach ist, mit ganz wenig Aufwand zumindest lokal OpenStreetMap in die beste Karte der Welt zu verwandeln. Wenn man in dieser Gegend auf Grundlage der bereitgestellten Bilder mappt (genauso wie in den meisten anderen Teilen der Antarktis wo die OSMIM Bilder bieten), kann man sich fast sicher sein, die beste Karte der Welt für dieses Gebiet zu produzieren. Und gleichzeitig lernt man auch einem Menge über eine ziemlich interessante aber gleichzeitig ziemlich unbekannte Gegend der Welt.

Woodland rendering in maps

21. Mai 2018
von chris
1 Kommentar

Differenzierte Darstellung von Wald in Karten

Dieser Beitrag ist die Fortsetzung meiner Ende letzten Jahres mit Texten zur Darstellung von Wegen und Gewässern begonnenen Reihe, mit der ich ein bisschen mehr über die Gestaltung von Karten auf OpenStreetMap-Basis schreiben möchte. Diesmal beschäftige ich mich mit der Darstellung von Wäldern.

Zunächst ein bisschen Geschichte zur Erfassung und Darstellung von Wäldern in der OpenStreetMap-Welt. Abgesehen von der fehlgeschlagenen Differenzierung zwischen landuse=forest und natural=wood – über die es vermutlich niemals einen Konsens geben dürfte, was sie genau bedeuten soll – habe Mapper in OpenStreetMap schon sehr früh begonnen, verschiedene Arten von Wald mit Hilfe des Schlüssels wood zu differenzieren. Die meistgebrauchten Werte waren deciduous, coniferous und mixed.

Das war einer der offensichtlichsten Fälle von geographischer Voreingenommenheit in OpenStreetMap. Die Mapper, welche dieses Konzept eingeführt haben, stammten größtenteils aus Flachland-Regionen Mitteleuropas wo man gewohnt ist, dass Nadelbäume fast durchgehend immergrün sind und Laubbäume ihr Laub im Winter abwerfen. Global betrachtet gibt es jedoch alle Kombinationen davon und mit der Zeit haben die Mapper begriffen, dass wood=deciduous/coniferous/mixed nicht wirklich ein universelles Werkzeug ist, um Wälder zu klassifizieren und man hat die neuen Schlüssel leaf_type und leaf_cycle eingeführt. Diese sind jetzt allgemein akzeptiert.

Historische Entwicklung der Verwendung von wood und leaf_type/leaf_cycle

Für mehr Hintergrund-Information zum allgemeinen Thema der Wald-Darstellung in Karten empfiehlt sich Jerrys history of woodland cartography von 2014.

Was ich jetzt im alternative-colors-Stil implementiert habe geht auf die erste größere Änderung in der Darstellung von Wald in OSM-Carto zurück. Damals war die wesentliche Differenzierung noch zwischen landuse=forest und natural=wood – welche selbst unter der Annahme eines konsistenten Unterschiedes zwischen den beiden im Vergleich zu andere Differenzierungen in der Karte einen zu kräftigen Unterschied darstellte.

Urprüngliche Darstellung von forest und wood im Standardstil vor 2015

Das wurde 2015 vereinheitlicht unter Verwendung eines Baum-Paar-Symbols. Die Diskussion dazu findet sich hier.

Vereinheitlichte Darstellung von Wäldern ab 2015

Das war damals als provisorische Lösung gedacht bis eine Darstellung entsprechend leaf_type möglich ist, was dann später umgesetzt wurde, wobei die Baum-Paar-Symbole weiterverwendet wurden für die Darsellung von Flächen ohne Angabe von leaf_type.

Aktuelle Wald-Darstellung in OSM-Carto ab August 2017

Diese Gestaltung halte ich für etwas suboptimal. Die starke Abstraktion bei den Symbolen ist recht un-intuitiv (man könnte auch an einen Tennisschläger und einen Tortenheber denken). Symbole in Mustern funktionieren anders als Einzelsymbole, der Leser der Karte nimmt sie anders war. Es ist nicht unbedingt notwendig, dass man das einzelne Symbol erkennen kann um die Karte lesen zu können, es ist das Muster als Ganzes, welches lesbar sein muss. Das bedeutet, dass wenn das Einzel-Symbol nicht gut zu erkennen ist, das Muster als Ganzes nicht unbedingt unbrauchbar ist. Auf der anderen Seite gibt es aber auch keinen Grund für eine extrem einfache Geometrie bei den Einzel-Symbolen damit um jeden Preis eine klare und konturscharfe Darstellung sichergestellt ist. Stattdessen muss das Muster vor allem mit dem Rest der Karte harmonieren und sollte natürlich daneben – soweit wie möglich – intuitiv verständlich sein.

Damals 2015 habe ich im Rahmen der Diskussion um die Darstellung von Wäldern eine Reihe von Konzept-Skizzen produziert, um verschiedenen Gestaltungs-Ansätze zu demonstrieren.




Die erste Variante verwendet die Symbole, welche später auch für OSM-Carto verwendet wurden, die zweite Variante verwendet etwas komplexere Formen, die dritte ist am Stil deutscher topographischer Karten orientiert und die letzte Variante zeigt einen völlig anderen Ansatz – sie basiert auf der Idee einer Ansicht des Waldes von oben im Gegensatz zu den sonst üblichen Profildarstellungen der Bäume.

Der Vorteil dieser letzten Variante ist, dass indem man nicht auf die figürliche Darstellung der Einzelbäume baut, sondern nur eine Gesamt-Struktur des Waldes darstellt – ein bisschen so wie bei den Mustern für unbewachsenen Untergrund – man eine Ablenkung des Betrachters von anderen Punkt- und Linien-Signaturen in der Karte vermeiden kann. Der Nachteil ist jedoch, dass man wesentlich weniger Möglichkeiten hat, über das Muster konkrete Informationen zu transportieren. Die drei Typen Laubwald, Nadelwald und Mischwald sind im Grunde bereits das Maximum an Differenzierung, das hier über die Geometrie des Musters möglich ist, während ein Muster mit figürlichen Einzel-Symbolen im Prinzip über unterschiedliche Symbole viel mehr differenzieren kann.

Kreise und Punkte sind – quasi als abstrakte Darstellung einer Ansicht eines Baumes von oben – recht weit verbreitet bei der Darstellung von Wäldern. Ältere französische topographische Karten verwenden dies, neuere nur für Laubwälder während die Nadelwaldsymbole Profil-Ansichten sind. Man findet diese sowie die neueren Varianten auf dem IGN Géoportail.

Hier eine Darstellung, die sich an der neueren französichen Gestaltung anlehnt.

Eine abstrakte Darstellung von Nadelbäumen von oben findet sich verbreitet in norwegischen Karten – hier zwei Beispiele, weitere findet man in der historischen Kartensammlung von Kartverket.

In Bezug auf die Perspektive ähnelt dieses Konzept etwas dem oben gezeigten Strukturmuster. Man kann auch dies natürlich an die digitale Kartendarstellung anpassen.

Alles bisher gezeigte basiert auf der Idee von zwei Typen von Wäldern – Nadelwäldern (welche man als immergrün annimmt) und Laubwäldern (welche implizit als laubwerfend angenommen werden). Diese Übereinstimmung zwischen leaf_type und leaf_cycle ist global betrachtet jedoch eigentlich nicht sonderlich verbreitet und leaf_cycle, also die Unterscheidung zwischen immergrün und laubwerfend, ist oft lokal die bedeutendere Unterscheidung. Borealer Wald wird von Nadelbäumen dominiert und die Haupt-Unterscheidung besteht zwischen immergrünen Bäumen (Fichten, Tannen und Kiefern) und sommergrünen Baumen (Lärchen). Bei niedrigen Breiten (Tropen und Subtropen) sind Wälder von Laubbäumen dominiert und die Differenzierung liegt zwischen immergrünen Bäumen und Bäumen, welche in der Trockenzeit das Laub abwerfen. In der gemäßigten Zone der Süd-Hemisphere sind immergrüne Laubbäume deutlich weiter verbreitet als im Norden, so dass hier die Unterscheidung nach leaf_cycle ebenfalls bedeutender ist.

Die Darstellung von leaf_cycle unabhängig von leaf_type oder der Art der Bäume ist in der klassischen Kartographie sehr wenig verbreitet – hauptsächlich weil wie bereits erwähnt die Trennung zwischen diesen beiden Dimensionen der Klassifikation von Wäldern in vielen der Länder, die historisch in der Kartographie führend waren, nicht entscheidend war. Ein weiteres Problem bei OpenStreetMap-Karten, welche der Rückmeldung an die Mapper dienen sollen, besteht darin, dass neben den drei Haupt-Klassen für leaf_cycle (evergreen, deciduous und mixed) auch eine vierte Klasse für Flächen ohne eine entsprechende Angabe erforderlich ist.

Ich hab für den Moment die Verwendung unterschiedlicher Symbol-Farben für die Illustration von leaf_cycle gewählt. Das kombiniere ich mit neu gestalteten Symbolen mit relativ traditionellen Formen. Das ist jedoch nicht in Stein gegossen, ich denke nach wie vor auch über andere Möglichkeiten nach. Hier ist gezeigt, wie das Ganze aussieht.

leaf_cycle differenziert über die Symbolfarbe

Die neuen Wald-Symbole

Das hab ich für natural=wood/landuse=forest, natural=scrub und natural=wetland + wetland=swamp sowie natural=wetland + wetland=mangrove implementiert – letzteres ohne die Differenzierung, denn Mangroven sind generell immergrüne Laubbäume.




Wie man sieht stelle ich Flächen ohne Angabe von leaf_type bei wood und swamp ohne Symbole dar – ich verwende als nicht das Baum-Paar-Konzept von OSM-Carto. Das bedeutet, dass leaf_cycle ohne leaf_type nicht dargestellt wird, dass tritt praktisch in den Daten jedoch auch recht selten auf. Die Symbole für scrub (Buschland) sind kleine, vereinfachte Versionen der Baum-Symbole. Ich verwende für Flächen ohne leaf_type das etablierte scrub-Symbol. Bei Buschland ist im Vergleich zu Wäldern die Angabe von leaf_type und insbesondere leaf_cycle weniger verbreitet. Für swamp existiert diese praktisch überhaupt nicht. Hier die Zahlen im Detail.

  • natural=wood: 4.6M
    • leaf_type: 258k
      • leaf_type=broadleaved: 144k
      • leaf_type=mixed: 83k
      • leaf_type=needleleaved: 30k
    • leaf_cycle: 111k
      • leaf_cycle=deciduous: 84k
      • leaf_cycle=mixed: 14k
      • leaf_cycle=evergreen: 12k
  • landuse=forest: 3.5M
    • leaf_type: 329k
      • leaf_type=broadleaved: 165k
      • leaf_type=mixed: 85k
      • leaf_type=needleleaved: 78k
    • leaf_cycle: 115k
      • leaf_cycle=deciduous: 68k
      • leaf_cycle=mixed: 24k
      • leaf_cycle=evergreen: 18k
      • leaf_cycle=semi_deciduous: 2k
  • natural=scrub: 1.9M
    • leaf_type: 48k
      • leaf_type=broadleaved: 15k
      • leaf_type=mixed: 4.1k
      • leaf_type=needleleaved: 29k
    • leaf_cycle: 15k
      • leaf_cycle=deciduous: 11k
      • leaf_cycle=mixed: 2.6k
      • leaf_cycle=evergreen: 1.8k
  • wetland=swamp: 80k
    • weniger als 1k mit leaf_type/leaf_cycle

Das bedeutet auch, dass eine weitere Differenzierung in der Darstellung – zum Beispiel bestimmte Baumarten dediziert zu zeigen anstatt nur die Grob-Klassifikation mit leaf_type – aktuell dadurch begrenzt wird, dass es keine nennenswerten Daten dafür gibt, auf die man bauen könnte. Das Ganze ist ein interessantes Thema und man findet in der klassischen Kartographie auf Papier-Basis eine ganze Reihe von Ansätzen in diese Richtung. Ebenso für die Unterscheidung zwischen dichten Wäldern mit geschlossenem Kronen-Dach und offenen Wäldern. Ein Thema für die Zukunft.

Die verwendeten Symbole wird es in der nächsten Version von jsdotpattern geben.

Sommergrüner Laubwald bei z14

Mischwald und Wald + Buschland ohne Differenzierung bei z16

Landsat/Sentinel-2 mosaics of the Subantarctic islands

8. Mai 2018
von chris
Keine Kommentare

Bilder der subantarktischen Inseln

Gewissermaßen als Gegengewicht zu den kürzlich gezeigten Bildern der nördlichen Polarregion gibt es jetzt ein paar neue Satellitenbild-Zusammenstellungen aus dem Süden von den subantarktischen Inseln. Diese Inseln werden ähnlich wie manche Teile der Arktis von den Satellitenbild-Ebenen der üblichen Karten-Dienste sehr vernachlässigt. Entweder indem sie komplett weggelassen werden oder durch eine Abdeckung in vergleichsweise schlechter Qualität. Einige dieser Inseln bieten auch besondere Schwierigkeiten dadurch, dass die Aufnahme-Pläne der Satelliten sie gleichermaßen übergehen. Bei Sentinel-2 wurden beispielsweise lange die südlichen Sandwichinseln und die Gough-Insel nicht aufgenommen, was sich erst vor Kurzem geändert hat. Nach wie vor nicht aufgenommen werden dort jedoch die Bouvetinsel, die Amsterdam-Insel, die Sankt-Paul-Insel, die Snares-Inseln und die Bountyinseln.

Hier eine illustrierte Liste der neuen Bilder:

Kerguelen

Das Bild der Kerguelen-Inseln ist das größte Mosaik in dieser Liste und auch eines der schwierigsten in Bezug auf die Wolken.

Heard und die McDonaldinseln

Die Heard-Insel befindet sich südöstlich der Kerguelen und ist stärker vergletschert und weniger bewachsen. Die McDonaldinseln sind kleiner und liegen etwas westlich von Heard.

Tristan da Cunha

Tristan da Cunha im südlichen atlantischen Ozean ist die nördlichste der hier eingeschlossenen Inseln und abgesehen von den Falkland-Inseln auch die mit den meisten Bewohnern.

Gough-Insel

Die Gough-Insel liegt südöstlich von Tristan da Cunha. Bei Sentinel-2 ist sie erst seit Anfang 2018 in den Aufnahme-Plänen enthalten und dieses Bild ist verwendet eine Kombination von Sentinel-2- und Landsat-Daten.

Bouvetinsel

Die Bouvetinsel liegt deutlich weiter südlich und ist fast vollständig von Eis bedeckt. Hier werden derzeit keine Sentinel-2-Bilder aufgenommen obwohl aufgrund der Wolken-Situation in der Gegend zusätzliche Bilder recht nützlich wären.

Crozetinseln

Die Crozetinseln liegen im südwestlichen Indischen Ozean und zeichnen sich durch ein sehr windiges und nasses Klima aus.

Prinz-Edward-Inseln

Die Prinz-Edward-Insel und die Marion-Insel (die größere Insel unten im Bild) befinden sich ein Stück weiter westlich. Die Schwierigkeit hier ist weniger ein wolkenfreies als ein schneefreies Bild zu produzieren.

Amsterdam-Insel

Sankt-Paul-Insel

Weiter nördlich im Indischen Ozean liegen die Amsterdam-Insel und die Sankt-Paul-Insel. Da diese nicht im Sentinel-2-Aufnahme-Plan enthalten sind, dienen für diese Darstellung Landsat-Daten als Grundlage.

Südliche Sandwichinseln

Die südlichsten der subantarktischen Inseln sind die südlichen Sandwichinseln. Ganz generell gibt es hier keine besonderen Probleme mit Wolken, denn die Gegend zeichnet sich im Spätwinter durch recht häufiges sonniges Wetter aus. Ein wolkenfreise Sommerbild zu produzieren ist jedoch ein anderes Thema. Dass die Inseln neuerdings von Sentinel-2 aufgenommen werden ist hier recht hilfreich.

Macquarie-Insel

Wir bewegen uns jetzt weiter nach Osten zu den Inseln südlich von Neuseeland – zuerst die Macquarie-Insel.

Aucklandinseln

Campbell-Inseln

Antipoden-Inseln

Snares-Inseln

Bountyinseln

Und schließlich haben wir noch die neuseeländischen subantarktischen Inseln – in verschiedenen Größen und Formen. Nur die Aucklandinseln und die Campbell-Inseln sind in den Sentinel-2-Aufnahmen enthalten, der Rest wird nur bei Landsat abgedeckt.

Daneben hab ich auch aktualisierte Bilder von Südgeorgien und den Falkland-Inseln produziert:

Südgeorgien

Falkland-Inseln

Und zum Schluß noch ein Bild der Balleny-Inseln vor der Küste der Antarktis:

Balleny-Inseln

Alle Bilder finden sich wie üblich auf services.imagico.de.

Landsat mosaic based on pixel statistics

25. April 2018
von chris
Keine Kommentare

Arktis-Mosaik und die Neubetrachtung von Farben

Anknüpfend an den vorherigen Beitrag hier mehr Beispiele für die Anwendung von Pixel-Statistik-Methoden auf Landsat- und Sentinel-2-Daten und wie dies dabei helfen kann, bessere Farben zu produzieren.

Ich hatte bereits früher mal erwähnt, dass hinsichtlich der Spektralbänder für realistische natürliche Farben Landsat eine deutlich bessere Basis liefert als Systeme mit niedriger Auflösung wie MODIS oder Sentinel-3 und dass von Landsat 7 und EO-1 über Landsat 8 zu Sentinel-2 ein merklicher Trend der Verschlechterung festzustellen ist hinsichtlich der Eignung der Daten für die präzise Farb-Reproduktion.

Spektralbänder gängiger Erdbeobachtungs-Satelliten mit offenen Daten im sichtbaren Bereich

Diese Einschätzung basiert auf den spektralen Empfindlichkeits-Verläufen und lässt sich praktisch auf Grundlage einzelner Bilder nur recht schlecht demonstrieren, denn die Unterschiede in den Betrachtungs-Bedingungen sind meist groß im Vergleich zu den Unterschieden in den Farben aufgrund verschiedener spektraler Empfindlichkeiten.

Ich habe jetzt ein Mosaik auf Grundlage von Pixel-Statistik-Methoden (die ich im vorherigen Beitrag thematisiert habe) produziert, welches einen größeren Bereich abdeckt und durch Vergleich mit dem „Green Marble“-Bild auf MODIS-Grundlage kann ich damit den Effekt der unterschiedlichen Spektralbänder deutlich besser demonstrieren. Die verwendeten Bilddaten stammen für die Landflächen von Landsat 7, Landsat 8 und Sentinel-2 und das „Green Marble“-Bild dient als Hintergrund für die Wasserflächen. Die Daten-Basis ist nicht extrem umfangreich so dass es auch einige Unterschiede in den Farben aufgrund unvollständiger Konvergenz des Verfahrens gibt. Aber man sieht dennoch sehr gut die grundsätzlichen Farb-Unterschiede im Vergleich zum MODIS-Mosaik.

Arctis-Mosaik auf Basis von Landsat- und Sentinel-2-Bildern

Green Marble zum Vergleich

Der offensichtlichste Unterschied ist, dass das Green-Marble-Bild auf MODIS-Grundlage nur sehr selten wirkliche Grau-Töne zeigt. Die meisten Bereiche, die im Landsat/Sentinel-2-Mosaik grau sind, erscheinen bei der „Green Marble“ in Rot-und Braun-Tönen. Das ist das Ergebnis der schmalen Spektralbänder beim MODIS-Instrument, insbesondere was den Grün-Kanal angeht. Graue Farben bedeuten, dass die Reflexion mehr oder weniger identisch in allen drei Empfindlichkeitsbereichen des menschlichen Auges ist. Dies bedeutet aber nicht zwangsläufig, dass die Reflexion auch völlig konstant über den gesamten sichtbaren Bereich ist. Falls sie dies nicht ist führt das meist dazu, dass der Sensor für eine Fläche, die das menschliche Auge als farbneutral wahrnimmt, eine nicht neutrale Farbe registiert. Auch der umgekehrte Fall ist möglich, aber sehr viel unwahrscheinlicher.

Moskau auf Grundlage von Landsat-Pixel-Statistik

Moskau auf Basis der „Green Marble“

Werchojansker Gebirge auf Grundlage von Landsat-Pixel-Statistik

Werchojansker Gebirge auf Basis der „Green Marble“

Das gezeigte Arktis-Mosaik ist übrigens meinem Kenntnisstand nach das erste vollständige Mosaik der Arktis in natürlichen Farben mit einer Auflösung besser als MODIS. Ich möchte keine tatsächliche Auflösung spezifizieren aufgrund der im vorherigen Beitrag diskutierten Grenzen der Pixel-statistischen Methoden. Das Ganze ist bearbeitet in einem 30m-Gitter (entsprechend der multispektralen Auflösung bei Landsat). Natürlich bieten meine regionalen Zusammenstellungen wie jene von Grönland und von Skandinavien eine deutlich höhere Auflösung, sie sind jedoch auch teurer in der Produktion.

Grönland-Beispiel aus dem Arktis-Mosaik auf Grundlage von Landsat und Sentinel-2-Daten

Das selbe Gebiet auf Basis des Landsat-Mosaiks von Grönland

Das selbe Gebiet auf Basis der „Green Marble“

Neben der Arktis hab ich auch eine vollständige Abdeckung von Europa produziert, jedoch bis jetzt nicht darüber hinaus. Wer interessiert ist an anderen Gegenden kann mich aber gerne kontaktieren.

Europa-Mosaik auf Grundlage von Landsat- und Sentinel-2-Daten

pixel statistics based on Landsat - Pyrenees

21. April 2018
von chris
Keine Kommentare

Pixel-Statistik mit Satellitenbildern

Regelmäßige Leser meines Blogs wissen, dass ich in den letzten Jahren eine ganze Reihe von Satellitenbild-Produkten produziert habe und daneben auch über die Arbeit anderer auf diesem Gebiet geschrieben habe. Neue Produkte wurden in den letzten 2-3 Jahren in diesem Bereich relativ oft von verschiedenen Firmen vorgestellt aber bemerkenswerterweise scheint die Qualität dabei kaum Fortschritte zu machen. Ein großer Teil der diese Tage vorgestellten Produkte in diesem Segment scheint nicht wirklich innovativ genug, dass sie eine detaillierte Betrachtung Wert sind.

Und das ist der Fall obwohl es eigentlich eine Menge Faktoren gibt, die so sollte man meinen recht gute Rahmenbedingungen für Qualitäts-Verbesserungen bieten:

  • Es gibt neue Satelliten, welche Daten hoher Qualität liefern.
  • Es gibt eine schnell wachsende Sammlung von Bilddaten, welche als Quelle für die Produktion von Bildzusammenstellungen zur Verfügung stehen.
  • Computer zur Verarbeitung dieser Daten werden immer noch leistungsfähiger und günstiger.

Die Frage, die sich also stellt und die ich hier erörtern möchte ist, warum wir trotz der günstigen Rahmenbedingungen keine weit verbreiteten Verbesserungen in der Qualität von Satellitenbild-Zusammenstellungen für die Endanwendung in Diensten finden.

Es gibt natürlich wirtschaftliche Faktoren dafür, aber einer der wichtigsten Gründe ist technologischer Natur. Der Schwerpunkt im Bereich der Produktion von Satellitenbild-Mosaiken lag in den letzten 5-10 Jahren fast ausschließlich in einer Richtung die ich Pixel-Statistik-Methoden nennen möchte. Der „Cloudless Atlas“ von Mapbox war hierfür ein gutes Beispiel. Es war nicht das Erste – die Blue Marble Next Generation von 2005 ist technisch auch mit einer Pixel-Statistik-Methode produziert und im Grunde reichen die Urprünge solcher Techniken wenigstens bis zu frühen AVHRR-Produkten in den 1980er Jahren zurück. Aber das Mapbox-Mosaik war das erste kommerziell auf globalem Maßstab für die Visualisierungs-Anwendung produzierte Produkt.

Pixel-Statistik-Methoden bedeuten, dass man für jeden Pixel des Bearbeitungs-Gitters alle Ausgangsdaten-Punkte aus den verschiedenen zu verschiedenen Zeitpunkten aufgenommenen Bildern sammelt und dann mit einem statistischen Verfahren daraus einen idealen, repräsentativen Pixel-Wert abschätzt, welchen man für das erzeugte Bild verwendet.

Die Statistik kann dabei gegebenenfalls sehr einfach sein – was unter den richtigen Umständen zu erstaunlich guten Ergebnissen führen kann wie das Mapbox-Mosaik gut demonstriert. Aber man kann natürlich auch kompliziertere Ansätze wählen, ggf. auch unter Verwendung zusätzlicher nicht aus den eigentlichen Bilddaten abgeleiteter Informationen. Mein „Green Marble“-Bild demonstriert dies recht gut. Der zentrale Punkt ist, dass man jeden Pixel getrennt behandelt. Das macht solche Ansätze sehr attraktiv, denn sie sind (a) programmtechnisch sehr einfach zu formulieren und (b) sehr effizient in großem Maßstab auszuführen. Diese Vorteile haben dazu geführt, dass so gut wie jeder, der im Bereich der Produktion von Satellitenbild-Zusammenstellungen in den letzten Jahren etwas begonnen hat, einen solchen auf Pixel-Statistik basierten Ansatz gewählt hat.

Was viele Leute dabei jedoch nicht berücksichtigt haben ist, dass diese Verfahren nicht für jede räumliche Auflösung gleichermaßen geeignet sind. Die Zusammenstellung von Satellitenbildern ist kein Maßstabs-unabhängiges Problem. Ich hab darauf bereits bei meiner Besprechung des Google-Landsat-Mosaiks hingewiesen.

Pixel-Statistik bei 250m Auflösung – das Green-Marble-Bild

Bei einer Pixel-Größe von etwa 250m kann man recht gut jeden Pixel eines Bildes unabhängig bearbeiten. So lange man eine genügend breite Datenbasis für die Konvergenz der Statistik hat, so dass das unkorrelierte Rauschen sowie Streifen-Artefakte vernachlässigbar sind und die statistische Methode geeignet für die Aufgabe ist, kann man ein gut lesbares Ergebnis erhalten. Aber wenn man zu deutlich höheren Auflösungen wechselt, gilt dies nicht mehr, denn unsere Fähigkeit zum Lesen und Verstehen von Bildern höherer Auflösung hängt zunehmend von mehr oder weniger präzisen räumlichen Beziehungen innerhalb des Bildes ab. Und diese geht oft verloren, wenn man jeden Pixel eines Bildes unabhängig betrachtet.


Landsat-Bilder mit 15m Auflösung

Viele Mosaike auf Grundlage von Pixel-Statistik, welche mit Landsat- oder Sentinel-2-Daten produziert werden, erreichen gar nicht den Punkt wo die genannten Rahmenbedingungen erreicht werden (eine genügend breite Datenbasis und ein geeigneter statistischer Ansatz). Aber selbst wenn sie das tun ist das Ergebnis oft dennoch unübersichtlich und ist dem Einzel-Bild hinsichtlich Definition und Lesbarkeit weit unterlegen.

Kurz: Pixel-Statistik-Methoden sind eine hoch-attraktive Methode zur Produktion von Satellitenbild-Mosaiken und können sehr effizient bei geringen räumlichen Auflösungen verwendet werden. Aber sie sind bei deutlich höheren Auflösungen praktisch ungeeignet. Ich hab noch nie einen Versuch gesehen, solche Methoden bei Bildern sehr hoher Auflösung mit Pixel-Größen unter einem Meter anzuwenden und es würde vermutlich recht übel aussehen (wenngleich es auch recht schön mein Argument hier illustrieren dürfte). Im mittleren Auflösungs-Bereich wird der Gewinn an Qualität durch eine höhere Auflösung der Ausgangs-Daten und des Bearbeitungs-Gitters zunehmend schwächer bis zu dem Punkt, wo mit höherer Auflösung keine Steigerung der Qualität im Ergebnis mehr zu erwarten ist.


Bilder mit Auflösung besser als 1m (von IGN Spanien)

Praktisch überlappt dieser Effekt mit anderen Einflussfaktoren wie der begrenzten Positions-Genauigkeit der Daten und der typischerweise geringeren Zahl von verfügbaren Bildern bei höheren Auflösungen. Während die zuletzt genannten Probleme jedoch durch technologische Verbesserungen gelöst werden können, ist das beschriebene Hauptproblem prinzipieller Natur und bildet eine harte Grenze für Methoden auf Grundlage von Pixel-Statistik.

Und letztendlich ist dies der Grund, weshalb sich die Qualität von Satellitenbild-Mosaik-Produkten in den letzten Jahren nur wenig verbessert hat.

Aufgrund dieser Einschränkungen hab ich mich bei höher aufgelösten Zusammenstellungen im Bereich der Auflösung von Landsat/Sentinel-2 (10-15m) immer auf Methoden konzentriert, die nicht auf Pixel-Statistik basieren. Aber Pixel-Statistik hat natürlich wie erwähnt ihren Charme – in erster Linie natürlich ökonomisch, aber auch, weil man damit recht präzise Farben hinbekommen kann. Die Farben in einem einzelnen Satellitenbild sind immer stark davon abhängig, unter welchen Bedingungen das Bild aufgenommen wurde. Man kann jetzt eine Menge Aufwand bei der Atmosphären- und BRDF-Korrektur treiben, aber solche Methoden erzeugen zwangsläufig auch neue Varianz in den Daten durch ungenaue vereinfachende Annahmen, die ihnen zugrunde liegen. Mit einer genügend breiten Datenbasis kann Pixel-Statistik helfen, diese Varianz zu reduzieren und präzisere Farben zu produzieren.

Pixel-Statistik auf Grundlage von Landsat-Bildern

Das ist der Grund, weshalb ich mich jetzt auch mal mit der Verwendung von Pixel-Statistik-Methoden für Landsat- und Sentinel-2-Bilder beschäftigt habe. Nicht so sehr für eine höhere Auflösung (welche natürlich gerne gesehen ist – wenngleich unter den beschriebenen Einschränkungen), sondern mehr für das, was man bei den Farben erreichen kann.

Mehr dazu im nächsten Beitrag. Bis dahin als Vorgeschmack:

21. April 2018
von chris
Keine Kommentare

Man nennt es Fortschritt

Bin heute über diesen bemerkenswerten Karten-Vergleich gestolpert – mit einem Klick auf das Bild kommt man zur Quelle:

Man beachte, dass ich das Bild ein bisschen retuschiert habe um es etwas mehr so aussehen zu lassen wie es eigentlich aussehen soll – siehe auch die Beschreibung hinter dem Link. Das ist jedoch nicht ganz fehlerfrei – man sollte die unterschiedlichen Sprachen der Beschriftungen ignorieren.

Ich finde dies auf verschiedenen Ebenen ein ziemlich lehrreiches und zum Nachdenken anregendes Beispiel. Es gibt da die Ebene des generellen Karten-Konzeptes (statische vs. dynamische Interaktion), die Ebene der Technologie darunter und die Ebene der kartographischen Gestaltung. Und über all dem steht natürlich der Zweck der Karte (hier: eine Positions-Karte für einen Wikipedia-Artikel). Etwas recht offensichtliches, was man sich zum Beispiel fragen kann ist warum die Karte links so viel anders aussieht als die Karte rechts wo doch beide dem selben Zweck dienen sollen. Die meisten werden mir wohl zustimmen, dass vor diesem Hintergrund die Unterschiede in der Gestaltung bemerkenswert stark sind. Was sind die Gründe und Motive dafür? Liegen diese in dem Unterschied zwischen statischer und dynamischer Nutzer-Interaktion? Oder liegt der Grund in der darunter liegenden Technologie? Ist es eine Frage von sich ändernder Mode in der Gestaltung? Oder vielleicht etwas völlig anderes?

Ich habe bereits vor mehreren Jahren schon mal über die ökonomische Seite dieses Themas geschrieben – zufällig auch im Zusammenhang zu Wikimedia maps. Ich hab auch vor weniger langer Zeit über die die soziologische Dimension der Karten-Gestaltung nachgedacht. Ich halte das Ganze jedoch nach wie vor für ein sehr interessantes Thema mit vielen offenen Fragen. Wenn Sie eigene Überlegungen und Blickwinkel zu diesem Thema haben fänd ich es interessant, darüber in den Kommentaren zu lesen.