Imagico.de

blog

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.

12. August 2017
von chris
Keine Kommentare

„Social Engineering“ in OpenStreetMap

Mit der zunehmenden Verwendung und Popularität sowie der wachsenden wirtschaftlichen Bedeutung von OpenStreetMap über die letzten Jahre haben auch das Interesse und die Versuche, von außen Einfluss auf das Projekt und die an ihm Beteiligten zu nehmen, deutlich zugenommen. Ich möchte hier einen Blick auf die in diesem Zusammenhang manchmal recht unerwarteten Mechanismen werfen.

Ich verwende den Begriff „Social Engineering“ hier im Sinne von Aktivitäten, die das Ziel verfolgen, andere Menschen in dem was sie tun (oder nicht tun) zu beeinflussen, und zwar nicht durch Informationen und Bildung, welche diese befähigt, ihre eigenen Entscheidungen auf Grundlage ihrer eigenen Prioritäten zu fällen, sondern indem man ihre Wahrnehmung beeinflusst, um gewissen Zielen zu dienen, ohne dass dies der Person bewusst ist. Manch einer mag ein solches Verhalten für vertretbar oder sogar für erwünscht halten, falls es höheren Zielen dient, aber ich vertrete hier einen strikt humanistischen Standpunkt.

Man beachte, dass Social Engineering nicht notwendigerweise bedeutet, dass derjenige, der andere beeinflusst sich selbst der Gründe hierfür bewusst ist.

OpenStreetMap ist unter digitalen sozialen Projekten und Internet-Gemeinschaften recht bekannt dafür, dass es wenig feste Regeln hat und das Projekt seinen Beteiligten großen Freiraum lässt, sich zu betätigen. Dies schafft natürlich auch eine Menge Raum für Einflussnahme. Auf der anderen Seite ist die Gemeinschaft der OpenStreetMap-Aktiven zumindest in mancher Hinsicht recht vielseitig und auch stark vernetzt so dass es recht schwierig ist, hier gezielt eine Gruppe von Leuten zu beeinflussen, ohne dass andere davon mitbekommen. Dies bedeutet, dass klassisches Social Engineering im Verborgenen, wo die Leute nicht mitbekommen, dass sie beeinflusst werden, nicht so weit verbreitet ist.

Es gibt jedoch in OpenStreetMap eine ganze Reihe von Aktivitäten, die man als mehr oder weniger offenes Social Engineering bezeichnen könnte, welches auf die Steuerung und Organisation von Mapping-Aktivitäten abzielt. Humanitäres Mapping ist hier das offensichtlichste Beispiel. Es gibt auch eine Reihe von bekannten Werkzeugen wie Maproulette, welche solche Aktivitäten unterstützen können.

Die erhebliche Anzahl von Leuten, die regelmäßig bei der Erfassung von Daten in OpenStreetMap aktiv sind, macht die Einflussnahme auf diese Aktivitäten selbst auf kleinem Rahmen zu einem attraktiven Ziel. Dies ist jedoch meist recht harmlos, denn

  • diese Form der Einflussnahme ist recht direkt,
  • der Einfluss und oft auch die dahinter stehenden Interessen sind gewöhnlich für den Mapper sichtbar und
  • wenn das Ganze aus dem Ruder läuft, können solche Aktivitäten recht einfach durch die Gemeinschaft unterbunden oder reguliert werden.

In anderen Worten: Mapper, die sich an HOT-Projekten beteiligen, werden nicht massiv manipuliert, denn die von ihnen wahrgenommenen Gründe für die Projekte unterscheiden sich nicht sonderlich von den tatsächlichen Gründen. Solche Mapper wissen vielleicht nicht genau in wie weit die Leute in der Gegend wo sie Daten erfassen auch tatsächlich von diesen profitieren und was genau die wirtschaftlichen Interessen der organisierenden Institutionen dabei sind. Im Groben treffen sie jedoch eine informierte Entscheidung, wenn sie sich an so etwas beteiligen.

Trotzdem sind solche organisierten Aktivitäten in OpenStreetMap nicht ohne Probleme, insbesondere dadurch, dass sie die soziale Balance innerhalb des Projektes gefährden können und zum Beispiel individuelle Mapper, die lokal die ihnen bekannten Umgebung erfassen, sich durch organisierte Aktivitäten von außerhalb bevormundet und übergangen fühlen.

Dies ist jedoch nicht das was ich hier hauptsächlich thematisieren möchte. Mit geht es um eine subtilere Form der Einflussnahme, welche ich social self engineering nennen möchte. Ein gutes Beispiel um zu erläutern, was ich damit bei OpenStreetMap meine, ist das was wir Mapping für den Renderer nennen.

Mit Mapping für den Renderer ist in der einfachsten Form gemeint, wenn Leute Daten in die OSM-Datenbank eintragen nicht mit dem Ziel, eine Beobachtung vor Ort in der Realität zu dokumentieren, sondern um in einer Karte auf Basis dieser Daten ein bestimmtes Darstellungsziel zu verwirklichen. Beispiele wären hier:

  • Als Namens-Attribute eingetragene Zeichenketten, welche keinen Namen darstellen, sondern zur Platzierung von sonstigen Beschriftungen in der Karte dienen.
  • Orts-Knoten, welche so verschoben werden, dass Beschriftungen an einer attraktiveren Position gezeichnet werden
  • Abweichende Klassifikationen von Orten oder Straßen, um diese früher und deutlicher in der Karte zu sehen.
  • Das Weglassen von Attributen, weil das daraus resultierende Erscheinungsbild in der Karte als unvorteilhaft angesehen wird.

Im Vergleich zu normalem Social Engineering sind die Rollen hier gewissermaßen vertauscht. Diejenigen, deren Verhalten beeinflusst wird, sind auch die, die darüber entscheiden (deshalb auch Self Engineering) und der Einfluss dies zu tun kommt von jemandem (dem Gestalter der Karte), der oft nichts von diesem Einfluss weiß und meist darüber auch gar nicht erfreut ist.

In dieser einfachen Form ist das Phänomen weit verbreitet und diejenigen, die so etwas tun, sind sich zwar im allgemeinen bewusst, dass das was sie machen nicht ganz richtig ist – sie sind sich aber meist nicht wirklich bewusst, was sie eigentlich motiviert, das zu tun, was sie tun und was für Konsequenzen dies auf die Datenqualität hat. In den meisten Fällen wird Mapping für den Renderer einfach als Abkürzung oder methodisches Schummeln angesehen. Die spezifischen Probleme der ganzen Wechselwirkung und Interaktion zwischen Karten-Gestaltern und Mappern habe ich auch schon früher mal diskutiert.

Es gibt aber noch eine andere Variante des Mapping für den Renderer (oder allgemeiner: des Mapping unter spezieller Berücksichtigung einer bestimmten Daten-Nutzung), welche weniger direkt ist und was ich als präventives Mapping für den Renderer bezeichnen möchte. Ein gutes Beispiel hierfür ist das verbreitete is_in-Attribut (oder Varianten wie is_in:country), welche angeben, in was für einem Land oder anderem Gebiet sich ein Objekt (zum Beispiel eine Stadt oder ein Dorf) befindet. Mir sind keine Anwendungen bekannt, für die dieses Attribut tatsächlich benötigt wird. Taginfo nennt Nominatim als einzige Anwendung, welche dieses verwendet. Allein schon die Idee, dass es in einer räumlichen Datenbank sinnvoll sein könnte, die Tatsache, dass sich eine Geometrie innerhalb einer anderen Geometrie befindet, per Hand als Attribut zu dokumentieren, ist absurd. Dennoch gibt es mehr als 2 Millionen Objekte mit diesem Attribut in der OSM-Datenbank.

Warum dies passiert hat eine Menge mit dem Phänomen des Cargo-Kults zu tun. Tatsächlich können recht viele der Tagging-Ideen und -Vorschläge, die in OSM entwickelt und kommuniziert werden, als Cargo-Kult-basiert klassifiziert werden und dies ist einer der Gründe weshalb viele Mapper Tagging-Diskussionen meiden. Eigentlich ist ja auch schon die Idee, dass jeder Dokumentation einer Beobachtung in der Realität in OSM ein universelles Klassifikations-System zugrunde liegen soll, inherent anfällig für Wunschdenken. Manchmal gibt es aufwändige strukturierte Tagging-Systeme, welche mit der Absicht entwickelt werden, es für Entwickler von Anwendungen attraktiv zu machen, sie zu implementieren, was glücklicherweise meist dazu führt, dass weder Mapper noch Daten-Nutzer diese Ideen umsetzen. Die Idee eines importance-Tags, welche alle paar Monate wieder irgendwo auftaucht, gehört auch zu dieser Kategorie. Aus dem Wunsch heraus, dass es einen objektiven und universellen Maßstab gäbe, um die Bedeutung von Dingen zu quantifizieren, erfinden Leute ein importance-Tag und hoffen, dass dessen Existenz allein ausreicht, dass dieser Wunsch Realität wird.

Aber nicht alle derartigen Mapping-Ideen sind ohne Erfolg. Es gibt eine ganze Reihe von Attributen, welche erfunden wurden, weil jemand dachte, dass sie die Datennutzung einfacher machen und Mapper investieren eine Menge Zeit, diese Dinge zu erfassen – wie im genannten Beispiel von is_in. Oder bei der Idee, Dinge als Polygone zu erfassen, welche ebenso präzise mit linearen Geometrien oder Punkten erfasst werden könnten – wie hier.

Das Problem dabei ist nicht nur die Verschwendung von Ressourcen bei der Erfassung und der Pflege der Daten. So etwas hält auch oftmals Datennutzer davon ab, sinnvollere Erfassungs-Methoden zu interpretieren. Präventives Mapping für den Renderer zielt immer, selbst wenn die Überlegungen dahinter gelegentlich sinnvoll sind, auf eine technologisch konservative Daten-Interpretation ab. Auf diese Weise werden echte Innovation und Investitionen in eine intelligente und fortschrittliche Interpretation von für die Mapper optimierten Erfassungs-Methoden behindert. Das is_in-Tag beispielsweise wurde erfunden in der Frühzeit von OpenStreetMap als es noch keine Grenz-Relationen gab, über welche man automatisch hätte ermitteln können, in welchem Land sich ein Objekt befindet. Also hat jemand anstatt eine besser geeignete Lösung zu erfinden den technologisch einfachen Weg gewählt und die Arbeit auf den Mapper abgeladen. Glücklicherweise hat dies in diesem Fall nicht verhindert, dass am Ende doch Grenz-Relationen und und Punkt-in-Polygon-Tests als bessere Lösung entwickelt und etabliert wurden.

Und während Versuche von Datennutzern, direkt Einfluss zu nehmen und Mapper zu überreden, Daten in für sie einfach verwendbarer Form zu erfassen, meist recht leicht zu erkennen und ggf. zurückzuweisen sind, ist die präventive Variante von Seiten der Mapper oft schwieriger zu erkennen. Und auch die Motive, weshalb ein Mapper jetzt ein bestimmtes, problematisches Tagging nutzt oder befürwortet sind meist recht kompliziert und unübersichtlich.

Wer also als Mapper wirklich eine kompetente Nutzung der Daten unterstützen möchte, der sollte besser jegliche Annahmen zu den vermuteten Interessen der Datennutzer ignorieren und sich darauf konzentrieren, wie man seine Beobachtungen vor Ort möglichst effizient in Datenform wiedergibt.

new_guinea_landsat_980

28. Juli 2017
von chris
2 Kommentare

Wahrgenommene und tatsächliche Qualität von Bildquellen für OpenStreetMap

Einer der Fallstricke für Mapper in OpenStreetMap bei der Erfassung auf Grundlage von Bildern ohne aktuelle Kenntnisse der Situation aus der Nähe ist das Problem, dass gelegentlich scheinbar ungenaue Daten auf Grundlage veralteter Informationen „verbessert“ werden. Ein plakatives Beispiel dafür sind Fälle, wo abgerissene Gebäude in populären Bilddaten-Quellen sichtbar bleiben und Mapper diese immer wieder neu abzeichnen, da sie anscheinend ja in der OpenStreetMap-Datenbank fehlen.

Diese Art von Problemen nimmt in den letzten Jahren zu, da die Anzahl unterschiedlicher Bildquellen, die für die Erfassung verwendet werden, wächst und gleichzeitig das durchschnittliche Alter dieser Bilddaten ansteigt, denn nicht überall werden die Bilder regelmäßig aktualisiert. Die Qualität von Bilddaten ist am Ende eine mehrdimensionale Größe wenngleich für Mapper, insbesondere wenn sie mit einer Gegend nicht vertraut sind, die Auflösung eines Bildes das offensichtlichste Qualitätsmerkmal ist und deshalb Mapper oft geneigt sind, die Quelle mit der höchsten Auflösung generell für die beste Bildquelle zu halten. Die wichtigsten Dimensionen der Bildqualität sind vermutlich:

  • die räumliche Auflösung.
  • die Positionsgenauigkeit – welche nicht unbedingt mit der Auflösung korreliert – näheres dazu in einem anderen Beitrag von mir.
  • das Alter – die fehlende Berücksichtigung hiervon ist die Ursache für das oben beschriebene Problem.
  • die Jahreszeit – Bilder von unterschiedlichen Jahreszeiten eignen sich unterschiedlich gut für die Erfassung verschiedener Dinge. Ein häufiges Problem mit hochauflösenden Bildern in Bing und DigitalGlobe bei hohen Breiten ist zum Beispiel, dass die Bilder oft von relativ früh im Jahresverlauf stammen (wo das Wetter oft besser ist als später im Jahr) und das meiste, was von Interesse ist, dann unter Schnee verdeckt ist.
  • die Wolkenfreiheit.

Von Menschen geschaffene Strukturen sind nicht der einzige Fall, wo die verschiedenen Dimensionen der Bildqualität in Kombination bewirken, dass die Bildquelle mit der höchsten Auflösung nicht unbedingt die Beste ist. Ich bin vor kurzem auf ein Beispiel gestoßen, welches dies sehr schön illustriert.

Hintergrund-Geschichte dazu: In 2013 hab ich die Gletscher von Neuguinea in OpenStreetMap erfasst – auf Grundlage von damals neuen Landsat-Bildern. Bing hatte damals wie heute keine hierfür brauchbaren Bilder.

Mit den vor kurzem von DigitalGlobe bereitgestellten Bildern gibt es jetzt für OpenStreetMap-Anwendungen hochauflösende Bilder der Gegend, jedoch sind diese nicht sehr aktuell, vermutlich stammen sie von 2011-2012. Wichtiger ist jedoch, dass das Gebiet des Northwall Firn einen erheblichen Versatz in der Position aufweist. Was dazu führt, dass die neue Erfassung durch palimpadum ohne böse Absicht schlechter ist als zuvor.

Ich hab jetzt zwei neue Bilder bei den OSM images for mapping hochgeladen, welche eine wirklich substantielle Aktualisierung der Gletscher und möglicherweise auch anderer Dinge in der Gegend ermöglichen sollten. Diese Bilder illustieren sehr schön die verschiedenen Dimensionen der Bildqualität für die Erfassung von Daten für OSM.

Das neuere der beiden Bilder stammt von 2016 und ist von Sentinel-2 aufgenommen. Es stellt das neueste wolkenfreie frei verfügbare Bild der Gegend dar. Jedoch weist es einen erheblichen Nachteil auf: Es zeigt Neuschnee auf den höchsten Teilen der Berge, welcher eine präzise Erfassung der Gletscher unmöglich macht.

Das andere Bild stammt von 2015 und ist von Landsat 8 aufgenommen. Es zeigt die Gletscher in schneefreiem Zustand und erlaubt so eine Erfassung ihrer Ausdehnung. Insgesamt haben wir also:

  • Das Bild von DigitalGlobe, welches die höchste Auflösung bietet, jedoch am ältesten ist und zumindest in Teilen eine schlechte Positionsgenauigkeit aufweist. Auch sind in der weiteren Umgebung weite Teile der Bilder durch Wolken unbrauchbar.
  • Das Sentinel-2-Bild, welches am aktuellsten, jedoch durch Neuschnee beeinträchtigt ist.
  • Das Landsat-8-Bild mit geringfügig geringerer Auflösung als Sentinel-2, jedoch mit einem klaren Blick auf die Gletscher.

Die Positions-Genauigkeit von Sentinel-2 und Landsat ist hier sehr ähnlich. Und schließlich sind die Wolken auch der Grund, weshalb es keine neueren Bilder von Landsat oder Sentinel-2 von der Gegend mit einem klaren Blick auf die Erdoberfläche gibt.

Für die Erfassung der Gletscher wird man sinnvollerweise also das Landsat-Bild verwenden. Für die Erfassung des Tagebaus, welcher sich recht schnell verändert, eignet sich das Sentinel-2-Bild vermutlich am besten. Andere Dinge wie Seen oder die Landbedeckung lassen sich – soweit nicht von Wolken verdeckt – recht zuverlässig von den Digital-Globe-Daten erfassen. Wobei es immer eine gute Idee ist, die Position anhand der anderen Bilder zu überprüfen und gegebenenfalls zu korrigieren.

Auch denen, die jetzt kein Interesse an Gletscher-Erfassung haben, empfehle ich, durchaus mal die drei Bildquellen hier in Ihrem bevorzugtem OSM-Editor zu landen und zwischen diesen ein bisschen hin und her zu schalten und so ein Gefühl für die Unterschiede zu bekommen. Hier die URLs für die OSMIM-Layer:

tms:http://imagico.de/map/osmim_tiles.php?layer=S2A_R088_S05_20160812T011732&z={zoom}&x={x}&y={-y}
tms:http://imagico.de/map/osmim_tiles.php?layer=LC81030632015286LGN00&z={zoom}&x={x}&y={-y}

slstr_temp_980

23. Juli 2017
von chris
Keine Kommentare

In der Dunkelheit sehen

Wie viele vermutlich bereits anderswo gelesen haben, ist vor kurzem ein recht großer Eisberg in der Antarktis abgebrochen, und zwar am Larsen-C-Schelfeis an der Ostseite der antarktischen Halbinsel. Das interessante daran ist weniger das Ereignis selbst (ja, das ist ein großer Eisberg und ja, seine Entstehung ist vermutlich Teil eines allgemeinen Trends des Rückgangs der Schelfeis-Flächen an der antarktischen Halbinsel im Verlauf der vergangenen hundert Jahre – aber nein, das ist nicht wirklich rekordverdächtig oder besonders alarmierend, wenn man das Ganze auf einem Zeithorizont von mehr als einem Jahrzehnt betrachtet). Interessant ist mehr die Art und Weise wie darüber kommuniziert wird. Eisberge dieser Größenklasse treten in der Antarktis in Intervallen von einigen Jahren bis Jahrzehnten auf. Es ist bekannt, dass viele der großen Schelfeis-Platten ein zyklisches Wachstum unterbrochen vom Kalben großer Eisberge wie diesem aufweisen, teilweise auf Zeitskalen von über fünfzig Jahren. Dieses war das erste mal, dass so ein Ereignis aus der Entfernung detailliert verfolgt wurde. In der Vergangenheit hat man so etwas meist einige Tage oder Wochen nach dem eigentlichen Ereignis bemerkt, während diesmal das Abbrechen erwartet worden ist und die Entwicklung der Risse im Eis detailliert verfolgt wurde. Es gab über Monate immer wieder Vorhersagen, dass das Kalben des Eisberges jetzt innerhalb von wenigen Tagen zu erwarten ist – oder anders ausgedrückt: Eine ganze Menge Leute hatten anscheinend ziemlich falsche Annahmen dazu, wie genau dieser Prozess ablaufen würde.

Ich bin nicht wirklich mit der Dynamik von Eis auf diesem Maßstab vertraut, so dass ich das nicht im Detail diskutieren werde. Wichtig ist immer im Hinterkopf zu behalten, dass sich Eis auf dem Maßstab von mehreren zehn bis hunderten Kilometern und unter den Drücken die dabei auftreten deutlich anders verhält als man dies in Analogie mit der Beobachtung von Eis auf Seen oder Flüssen vielleicht vermuten würde.

Der andere interessante Aspekt bei diesem Kalbungs-Ereignis ist, dass es in der Polarnacht stattfand. Da sich das Larsen-C-Schelfeis südlich des Polarkreises befindet, liegt die Gegend um diese Jahreszeit im Dunkeln. Wie beobachtet man also ein Ereignis in permanenter Dunkelheit auf Grundlage offener Satellitenbild-Daten?

Eine der interessantesten Möglichkeiten zur Beobachtung der Erde bei Nacht ist das Day/Night Band des VIIRS-Instruments. Dies ist ein Sensor im sichtbarem/NIR-Bereich, welcher sehr geringe Lichtmengen detektieren kann. Am bekanntesten ist dieser Sensor über Visualisierungen der Lichter menschlicher Siedlungen bei Nacht – welche künstliche Farben zeigen.

Dieser Sensor kann Bilder mit Hilfe von Mondlicht oder anderen nächtlichen Lichtquellen wie dem Polarlicht aufnehmen. Auf diese Weise sind einige der ersten Aufnahmen des frei schwimmenden Eisberges entstanden.

Antarktis im Mondlicht – VIIRS Day/Night Band

Dieses Bild verwendet eine logarithmische Farbskala, die tatsächlichen Lichtmengen variieren über das gezeigte Gebiet um etwa drei Größenordnungen.

Eine deutlich ältere und besser etablierte Methode zur Beobachtung bei Nacht ist die Beobachtung im thermischen Infrarot. Im langwelligen Infrarot-Bereich emittiert die Erdoberfläche Licht entsprechend ihrer Temperatur und diese Emissionen unterscheiden sich kaum zwischen Tag und Nacht. Wolken emittieren natürlich auch im langwelligem Infrarot, weshalb Aufnahmen im thermischen Infrarot insbesondere auch attraktiv sind und häufig verwendet werden zur durchgehenden Wetterbeobachtung Tag und Nacht von Wettersatelliten aus.

Thermische Infrarot-Bilder gibt es vom zuvor erwähnten VIIRS-Instrument, genauso aber auch von MODIS und Sentinel-3 SLSTR. Hier ein Beispiel unseres Gebietes von SLSTR.

Leuchten im Dunkeln – thermische Infrarot-Emissionen, aufgezeichnet von Sentinel-3 SLSTR

Während der Polarnacht treten die höchsten Temperaturen in der Gegend an offenen Wasserflächen auf wie auf der Westseite der Antarktischen Halbinsel oben links und die niedrigsten Temperaturen gibt es auf der Oberfläche der Schelfeis-Flächen und auf den untersten Teilen der Gletscher aus der Ostseite der Halbinsel. Die Umrisse des neuen Eisberges sind sehr gut sichtbar durch das recht warme offene Wasser in der Lücke zwischen Eisberg und Schelfeis, welches nur von wenig Eis überdeckt wird.

Thermische Infrarot-Bilder gibt es auch in deutlich höherer Auflösung von Landsat und ASTER. Landsat nimmt nicht routinemäßig bei Nacht Bilder in der Antarktis auf, jedoch wurden aufgrund des aktuellen Interesses an der Gegend in letzter Zeit einige Bilder dort aufgezeichnet. Hier eine Zusammenstellung von Bildern vom 12. und 14. Juli.

Hochauflösende thermische Infrarot-Aufnahmen von Landsat 8

Wie man sieht, wird die Sicht durch Wolken erheblich beeinträchtigt, insbesondere in den Bildern auf der rechten Seite, wo das Eis durch diese teils komplett verdeckt ist. Hier noch ein vergrößerter Ausschnitt um den Detaillierungsgrad zu zeigen.

ASTER bietet keine aktuellen Bilder der Gegend. Im Prinzip bietet ASTER jedoch derzeit die thermischen Aufnahme-Fähigkeiten mit der höchten Auflösung – sowohl im Bereich offener Daten als auch in der Welt öffentlich verfügbarer Daten generell, obwohl es vermutlich nicht öffentlich bekannte und zugängliche Sensoren mit höhere Auflösung im thermischen Infrarot gibt.

Bis jetzt sind alle gezeigten Bilder von passiven Sensoren aufgenommen, welche natürlich auftretende Emissionen oder Reflexionen messen. Die andere Möglichkeit zur nächtlichen Beobachtung besteht in der Verwendung aktiver Sensoren, insbesondere von Radar. Dieser Ansatz hat den zusätzlichen Vorteil, dass er unabhängig von Wolken ist (welche bei den verwendeten Wellenlängen im Grunde transparent sind).

Radar ist jedoch im Grunde erst einmal kein bildgebendes Verfahren. Man nehme zum Beispiel das klassische Navigations-Radar von Schiffen mit rotierender Antenne – das zweidimensionale Bild wird hier aufgebaut, indem man die Signal-Laufzeit des reflektierten und empfangenen Signals in die jeweilige Richtung aufträgt. Die Radar-Daten von Satelliten arbeiten im Grunde gar nicht so viel anders.

Satelliten-basierte Systeme, welche offene Radar-Erdbeobachtungs-Daten produzieren, gibt es derzeit auf Sentinel-3 und Sentinel-1. Sentinel-3 verfügt über einen Radar-Höhenmesser, welche die Position der Erdoberfläche entlang eines schmalen Streifens direkt unter dem Satelliten vermisst. Dies ist für die Beobachtung eines Eisbergs und seiner Entstehung nicht wirklich nützlich.

Sentinel-1 hingegen verfügt über ein klassischen bildgebendes Radar-System. Das meist verwendete Daten-Produkt von Sentinel-1 sind Ground Range Detected-Daten, welche meist in Form eins Graustufen-Bildes visualisiert werden – oder durch ein Falschfarben-Bild, wenn mehrere Polarisationen gemeinsam dargestellt werden. Hier ein Beispiel für das hier behandelte Gebiet.

Durch Wolken schauen – Bildgebendes Radar von Sentinel-1

Man beachte, dass das zwar wie ein Bild von oben aussieht, dieser Eindruck jedoch trügt. Das zweidimensionale Bild entsteht hier durch Interpretation der Signal-Laufzeit als Abstand (was eine weitgehend korrekte Annahme ist) und dadurch, dass man den Abstand auf einen Punkt auf einem Ellipsoid-Modell der Erde projiziert (was eine extreme Vereinfachung darstellt). In anderen Worten: Das Bild zeigt die Intensität des reflektierten Radar-Signals an dem Punkt, von wo das Signal käme, wenn die Erde ein perfekter Ellipsoid wäre. Für das Schelfeis ist dies kein so großes Problem, denn dieses ragt nicht mehr als vielleicht hundert Meter aus dem Wasser auf, was recht nahe am Ellipsoid-Modell ist, aber man sollte nie versuchen, aus so einer Visualisierung direkt Positions-Informationen über Punkte an Land abzuleiten.

Man sieht auch, dass das Rauschen in den Radar-Daten meist sehr viel stärker ist, das in optischen Bildern. Wir sprechen hier schließlich über ein Signal, welches mehrere hundert Kilometer weit ausgesendet wird, dann reflektiert und wovon ein ganz kleiner Teil am Ende über mehrere hundert Kilometer zurück reflektiert und aufgezeichnet wird. Aus Radar-Daten quantitative Informationen abzuleiten ist deutlich schwieriger als bei optischen Bildern. Aber der große Vorteil ist natürlich, dass man nicht durch Wolken beeinträchtigt ist.

Da dies möglicherweise verwirrend ist für Leser, die auch anderswo Bilder dieses Ereignisses sehen – die Darstellungen hier sind alle in UTM-Projektion und in etwa nordorientiert.

S2B_R053_S51_20170630T142859_expose.ann

7. Juli 2017
von chris
Keine Kommentare

Erste Sentinel-2B-Daten und Sentinel-3 L2

Seit ein paar Tagen sind die ersten Daten von Sentinel-2B öffentlich zugänglich.

Der Datenzugriff erfolgt über eine seperate Instanz der Datenzugangs-Infrastruktur so dass man Download-Skipte und Werkzeuge entsprechend anpassen muss. So wie es scheint wird Sentinel-2B genauso wie Sentinel-2A betrieben, das heißt, dass Europa, Afrika und Grönland mit Priorität aufgenommen werden und die größeren Landflächen des Rests der Welt weniger oft. Ich hab die täglichen Zahlen von Sentinel-2B in meiner Übersicht zu Satellitenbild-Erfassungszahlen ergänzt. Im Moment sind dies noch nicht so viele Bilder wie bei Sentinel-2A und Bilder von vor Ende Juni sind noch nicht verfügbar.

Wenn Sentinel-2B irgendwann mit der selben Frequenz Bilder aufnimmt wie Sentinel-2A soll das den zeitlichen Abstand zwischen den Aufnahmen halbieren – von normalerweise 10 Tagen in Europa und Afrika zu 5 Tagen. Die Überlappung der Bilder bei höheren Breiten wird dann auch dazu führen, dass für Grönland und den Europäischen Teil der Arktis ab 75° Breite bis zur Grenze bei 82.8° eine tägliche Abdeckung erfasst wird während die Grenze vorher bei 79.3° lag – dies liegt vor allem daran, dass die ESA anders als der USGS nicht aufgrund der Überlappungen die Aufnahme-Frequenz bei hohen Breiten reduziert.

Hier zwei Beispielbilder aus den letzten Tagen:

Upsala-Gletscher, Patagonien, Aufgenommen von Sentinel-2B

Sewastopol, Krim, Aufgenommen von Sentinel-2B

Neben den neuen Sentinel-2-Bildern gibt es jetzt auch Zugang zu einer Reihe weiterer Sentinel-3-Produkte – siehe hier, hier und hier. Das sieht in etwa so aus wie erwartet, das sind allerdings größtenteils recht spezielle Datenprodukte und nicht die Art von allgemeinen Level-2-Produkten wie man sie zum Beispiel von MODIS her kennt. Ich werde darüber vermutlich demnächst mal was schreiben.

Kleiner Einschub zur Erklärung der Bearbeitungsstufen bei Satellitenbildern:

  • Level-0 sind üblicherweise mehr oder weniger die Rohdaten, wie sie vom Satelliten kommen.
  • Level-1 schließt meist Kalibrierungen bezüglich der Eigenschaften des Sensors oder der Optik sowie geo-Referenzierung mit ein.
  • Level-2 umfasst in erster Linie die Kompensation unerwünschter Störeffekte bei der Aufnahme, insbesondere durch die Atmosphere, die Perspektive des Satelliten und die Beleuchtungsrichtung. Ziel ist meist eine Charakterisierung der Erdoberfläche, die unabhängig von den Aufnahme-Parametern ist, ggf. bereits für eine bestimmte thematische Anwendung.
  • Level-3 ist weniger klar definiert, meist handelt es sich hier um zeitlich aggregierte Daten, weiterreichende Auswertungen oder Kombinationen mit anderen Datenquellen.

Manche erinnern sich vielleicht an den Trend, den ich vor einiger Zeit mal hinsichtlich des Timings der Verfügbarkeit von Daten und den Satellitenstarts im Sentinel-Programm skizziert habe. Wir können dies jetzt ein wenig fortschreiben:

  • Sentinel-1A: Start 3 Apr 2014, öffentlicher Datenzugriff ab 9 Mai 2014 (1 Monat)
  • Sentinel-2A: Start 23 Jun 2015, Daten ab Ende November 2015 (5 Monate)
  • Sentinel-1B: Start 25 Apr 2016, Daten ab 26 Sep 2016 (5 Monate)
  • Sentinel-3A: Start 16 Feb 2016:
    • OLCI L1-Daten seit 20 Okt 2016 (8 Monate)
    • SLSTR L1-Daten seit 18 Nov 2016 (9 Monate)
    • teilweiser Zugang OLCI/SLSTR L2 seit 5/6 Jul 2017 (>16 Monate)
    • Weitere L2-Produkte: 16+ Monate und wir warten immer noch…
    • Daten von vor 20 Okt 2016: fehlen und es ist unklar, ob die jemals verfügbar werden.
  • Sentinel-2B: Start 7 Mar 2017, Daten-Zugang seit 5 Jul 2017 (4 Monate)

Der Trend ist also unterbrochen und ich bin sicher, dass jeder den im Vergleich zu Sentinel-2A beschleunigten Ablauf bei Sentinel-2B zu schätzen weiß. Der Ablauf bei Sentinel-3 ist jedoch – wie soll ich sagen – bemerkenswert. Man behalte dabei im Hinterkopf, dass die Level-2-Daten alles Dinge sind, die schon seit mehr als einem Jahr routinemäßig produziert, jedoch nicht veröffentlicht wurden – und das obwohl die Vorschriften dies eigentlich erfordern. Man könnte jetzt sagen, dass die Level-1-Daten das sind, worauf es ankommt, und alles andere nur optionale Zusatzleistungen sind. Wenn man jedoch zum Beispiel auf die MODIS-Daten schaut – da bin ich mir sicher, dass über 90 Prozent der Nutzer Produkte von Level 2 oder höher verwenden. Für das Ziel einer breiten Verwendung der Daten also (und ich würde zumindest bei der EU-Kommission annehmen, dass sie dieses Ziel verfolgt) ist das Zurückhalten von Level-2-Daten einfach nur bescheuert.

Tierra del Fuego in Winter 2017

4. Juli 2017
von chris
Keine Kommentare

Wintereindrücke 2017

Wie üblich wenn hier im Norden Sommer-Sonnenwende ist, herrscht im Süden Winter, also hier passend zwei Winter-Eindrücke auf Grundlage von Landsat-Bildern von der südlichen Hemisphäre aus den letzten Wochen.

Das erste Bild ist eine Ansicht des südlichen Teils von Feuerland und dem Beagle-Kanal:

mit Ushuaia, der südlichsten Großstadt der Erde:

Das zweite Bild zeigt Südgeorgien in einer seltenen fast wolkenfreien Situation in der Mitte des Winters:

Das Südgeorgien-Bild ist auch im Katalog auf services.imagico.de.