Imagico.de

blog

Wind blown dust from the Copper River, Alaska

18. November 2017
von chris
Keine Kommentare

Mehr Staub und Eis

Hier eine weitere Ansicht der Staubwolke aus dem vorherigen Beitrag von ein paar Tagen später, aufgenommen von Sentinel-2:

Und noch eine andere bewerkenswerte Situation von der anderen Seite der Erde – eine beeindruckende Ansammlung von großen Tafeleisbergen in der Nähe von Elephant Island nordöstlich der antarktischen Halbinsel – von Sentinel-3 aufgenommen.

Landsat Winter Alaska 2017

15. November 2017
von chris
Keine Kommentare

In Richtung des Lichts

Ich hab hier mal ein etwas anderes Satellitenbild als üblich:

Das ist ein Streifen von neun aufeinander folgenden Landsat-Bildern, aufgenommen vor ein paar Tagen im Süden Alaskas. Ich hab das ganze so rotiert, dass das Bild in etwa in Flugrichtung des Satelliten orientiert ist. Man muss herunterscrollen, um das ganze Bild zu sehen. Während man das tut, bewegt man sich vom Rand der Polarnacht am nördlichen Ende in Richtung Sonne nach Südwesten über insgesamt etwa 1500km.

Manche bemerken vielleicht die leicht Krümmung, die das Bild dabei aufweist – das liegt daran, dass das gewählte Koordinatensystem nicht wirklich an der Umlaufbahn des Satelliten ausgerichtet ist, sondern eine einfach geneigte Mercator-Projektion darstellt. Durch die Sonnen-synchrone Umlaufbahn des Satelliten ist dessen Spur auf der Erdoberfläche nicht wirklich ein Großkreis, sondern wickelt sich, um der Sonne zu folgen, quasi spiralförmig um die Erde.

Das südliche Ende des Streifens ist bestimmt durch das Ende der Landsat-Aufnahmen hier, welche sich nicht über den offenen Ozean erstrecken (es heißt schließlich Landsat). Das nördliche Ende markiert die Aufnahme-Grenze aufgrund der niedrigen Sonnen-Position zu dieser Jahreszeit.

Hier ein Sentinel-3-OLCI-Bild vom selben Tag (und mit Nordorientierung – also kann man hier auch erkennen, wo die erste Aufnahme oben liegt) welches durch eine deutlich engere nördliche Grenze gekennzeichnet ist.

Zum Vergleich hier auch ein Flaschfarben-Infrarot-Bild von Sentinel-3-SLSTR, wo es keine Beleuchtungsbedingte Aufnahme-Grenze gibt und man folglich die Tag-Nacht-Grenze vollständig sehen kann – aber halt nicht in natürlichen Farben.

Die beiden Sentinel-3-Bilder zeigen auch eine beeindruckende Staubwolke, welche sich vom Delta des Copper River im Süden Alaskas auf der rechten Seite des Bildes nach SSW erstrecket. Hier eine vergrößerte Ansicht davon.

Und schließlich noch zwei Ausschnitte aus dem ersten Bild – der erste vom Norden, wo man den Flüssen zu dieser Jahreszeit gewissermaßen beim zufrieren zuschauen kann (nahe Fort Yukon).

und der zweite Ausschnitt vom Süden zeigt das tatsächlich sehr windige, aber sonnige Wetter bei Tugidak Island.

10. November 2017
von chris
Keine Kommentare

Satellitenbild-Neuigkeiten

Ein paar Neuigkeiten, die für den ein oder anderen Leser von Interesse sein könnten – ohne einen Anspruch auf Vollständigkeit.

  • Das Sentinel-2-Datenformat hat sich geändertschon wieder. Diesmal ist die Änderung recht klein und für die meisten Anwender nicht erheblich. Das interessante und witzige daran ist, dass die Saga des zweiten Zeitstempels um eine weitere Anekdote reicher wird – für den zweiten Zeitstempel gilt nun: is specialised to ensure a deterministic repeatable name across time for the same product. In anderen Worten: Er hat keine eigentliche Bedeutung als Zeitstempel mehr. Vielmehr dient er ausschließlich dazu, zwischen verschiedenen Paketen mit ansonsten gleichem Namen zu unterscheiden (was an den Grenzen zwischen data strips vorkommen kann).
  • Noch was anderes zu Sentinel-2 – das wurde nicht groß angekündigt, aber es gibt einen mehr oder weniger regelmäßig aktualisierten Daten-Qualitäts-Bericht zu Sentinel-2. Man muss da beim Lesen jedoch etwas aufpassen. Regelmäßige Aktualisierung bedeutet nicht, dass alle Informationen darin auf dem neusten Stand sind. Und man muss wissen, wie man die Aussagen dort interpretieren sollte. Man nehme zum Beispiel die absolute Positionsgenauigkeit (über die ich vor kurzem auch gechrieben habe) – diese kann man prinzipbedingt nur dann wirklich quantitativ ermitteln, wenn man genaue Referenzdaten hat – was gewöhnlich vor allem in denjenigen Regionen nicht der Fall ist, wo die Daten nicht so gut sind. Folglich sind die <11m at 95.5% confidence sehr wahrscheinlich nicht an einer neutral und gleichmäßig auf der Erde verteilten Sammlung von Punkten bestimmt. Die verwendeten Punkte sind natürlich nicht veröffentlicht – genauso wenig wie die Quelle der Positionsangaben, welche als Referenz dient.
  • Der USGS hat ein Datenprodukt Namens Landsat Analysis Ready Data vorgestellt. Das sind im Grunde Landsat-Daten, welche für das Gebiet der Vereinigten Staaten in ein einheitliches Koordinatensystem reprojiziert wurden und in Kachel-Form verfügbar sind. Ich werde mich hier nicht näher damit beschäftigen, denn ich halte das konzeptionell und technisch eher für eine Sackgasse. Dies ist per Definition ein regionales Produkt, was nicht auf eine globale Abdeckung ausgeweitet werden kann. Und eine doppelte Reprojektion (von den Level-0-Rohdaten in das UTM-Gitter der Level-1-Daten und dann nochmal in die Projektion des ARD-Gitters) ist unnötig und verschwenderisch hinsichtlich der Informationen in den Daten. Es gibt natürlich Vorteile dafür, für größere Regionen Daten in einem gemeinsamen Gitter zu verarbeiten, aber eine Lösung, welche auf das Gebiet der Vereinigten Staaten beschränkt ist, ist da natürlich kein universell verwendbarer Ansatz.
  • Bei der kommerziellen Erdbeobachtung hat Planet Labs sechs neue SkySat-Satelliten gestartet – das sind die etwas größeren Satelliten, die sie mit der Akquisition von Terra Bella von Google erworben haben. Ich habe diese kurz bei der Besprechung von Planet Labs vor einiger Zeit erwähnt. Es gibt über den Betrieb dieser Satelliten nur recht wenig öffentlich zugängliche Informationen. Die angegebene Aufnahme-Kapazität von 185k km^2 pro Tag für alle 13 Satelliten zusammen ist recht wenig. Mit einer Sichtfeld-Breite von 8km bedeutet dies weniger als 2000km Aufnahme-Länge pro Tag pro Satellit oder etwa 20 Sekunden Aufnahme pro Orbit. Ob dies in der Zukunft gesteigert werde kann ist unklar. Im Moment scheinen diese Satelliten, mit Positionen für Aufnahmen bei unterschiedlichen Tageszeiten und der Möglichkeit zur Aufnahme von Schwarzweiß-Videos, vor allem dafür verwendet zu werden, was man als Event-Fotografie aus dem Weltraum bezeichnen könnte.
  • Es sind für die nächste Zeit zwei Starts von Erdbeobachtungs-Satelliten angekündigt. Für den 14. November ist der Start von JPSS-1 geplant, welcher das ein zweites VIIRS-Instrument bietet zusätzlich zu dem auf dem 2011 gestarteten Suomi NPP. Und Ende Dezember ist der Start von GCOM-C geplant. Beide Satelliten starten wesentlich später als geplant. JPSS-1 sollte bereit vor einem Jahr starten. Bei GCOM-C war der Start ursprünglich bereits 2014 geplant.

Ich habe mein Satellitenbild-Sensor-Schaubild entsprechend aktualisiert. Dabei ist zu beachten, dass ich mit nach wie vor nicht dazu durchringen kann, bei den PlantScope-Satelliten ein Intervall zur vollständigen Abdeckung anzugeben. Sie zeigen zwar jetzt eine ordentliche monatliche Abdeckung von über 90 Prozent zwischen -60 und 75 Grad Breite mit der Kombination RapidEye und PlantScope aber vollständige Abdeckung bedeutet für mich vollständige Abdeckung. Und demo or it did not happen.

Sentinel-2 2017 coverage

1. November 2017
von chris
Keine Kommentare

Satellitenbild-Erfassungen – Bericht für das letzte Jahr

Vor etwa einem Jahr habe ich meinen Bericht über die Erfassungen von Sentinel-2 im ersten Betriebsjahr geschrieben – mit Vergleich zu Landsat im selben Zeitraum. Das war – und ist so weit ich weiß nach wie vor – die detaillierteste und genaueste Analyse der von diesen Satelliten verfügbaren Bilder. Hier eine Aktualisierung für den Zeitraum vom Oktober 2016 bis Oktober 2017.

Die Aufteilung im Oktober ist dafür da, dass jeweils genau eine Sommer-Saison sowohl auf der Nord- als auch auf der Südhalbkugel der Erde enthalten ist. Eine Aufteilung nach Kalenderjahr würde im Süden immer den Sommer teilen.

Hier die Entwicklung des Erfassungs-Volumens für die verschiedenen Satelliten:

Landsat

Beide Landsat-Satelliten sind im letzten Jahr ohne nennenswerte Zwischenfälle oder Unterbrechungen betrieben worden. Landsat 7 hatte Anfang 2017 sein letztes Manöver zum Bahn-Erhalt und fliegt nun in einer Umlaufbahn, deren Aufnahme-Zeitfenster sich in der Zukunft kontinuierlich von derzeit etwa 10:15 zu früheren Zeitpunkten verschieben wird, wie es bereits bei EO-1 der Fall war.

Hier die Abdeckungs-Karten von Tagaufnahmen von Landsat 8:

Der bedeutendste Unterschied zu den vorherigen Jahren liegt darin, dass die Abdeckung der Antarktis im Sommer 2016-2017 wesentlich seltener erfolgte (siehe letztes Jahr zum Vergleich). Man sieht dies auch in der zeitlichen Entwicklung oben im ersten Diagramm, wo die Linie für Landsat 8 Ende 2016 eine deutliche Delle aufweist, was in den vorherigen Jahren nicht der Fall war. So weit ich weiß hat der USGS sich bis jetzt noch nicht zu den Gründen hierfür geäußert.

Ansonsten hat sich nicht viel verändert – wir bekommen jetzt routinemäßig off-nadir-Erfassungen von Nord-Grönland und dem Inneren der Antarktis. In Grönland passiert dies immer beim selben Umlauf (path), was Verbesserungspotential bietet, denn man könnte durch eine dynamische Auswahl des Zeitpunktes die Chancen für gutes Wetter im Zielgebiet verbessern. Alle off-nadir-Bilder von 2017 in Nordgrönland sind stark durch Wolken beeinträchtigt.

Es gibt auch nach wie vor die zwei eine Lücke in der Land-Abdeckung bei niedrigen Breiten – Rockall und die Jonas-Insel. (Ergänzung: ich habe bemerkt, dass es von Rockall ein Bild in diesem Jahr gibt, aber keine reguläre Abdeckung. noticed there is actually one image for Rockall – though not regular coverage. Die Jonas-Insel ist die bedeutendere Lücke)

Sentinel-2

Für Sentinel-2A blicken wir jetzt auf das zweite Jahr des Betriebs und man könnte vielleicht erwarten, dass dies zu mehr Routine und entsprechend größerer Zuverlässigkeit führt. Es gibt auch die ersten Bilder von Sentinel-2B. Hier die Zahlen für Sentinel-2A und Sentinel-2B getrennt:

Und hier zusammen mit einer anderen Farbskala.

Ich sollte betonen, dass dies die öffentlich verfügbaren Bilder zeigt. Wie ich früher schon mal betont habe gibt es erhebliche Unterschiede zwischen den veröffentlichten Erfassungs-Plänen und den tatsächlichen Erfassungen. Daneben sind auch die Veröffentlichungen der Bilder oft unvollständig. Hier ein Beispiel von Sentinel-2B aus meiner detaillierten Statistik-Seite (welche ich bei der Gelegenheit auch aktualisiert habe).

Ich habe nicht genau bestimmt, wie viele Bilder hiervon betroffen sind, aber zusammen genommen ist die Anzahl der Bilder, welche geplant, jedoch nicht aufgenommen wurden oder aufgenommen wurden aber nicht veröffentlicht sind, erheblich. Insbesondere der zweite Fall sieht in der im Bild gezeigten Willkür ziemlich peinlich aus.

Das Erfassungs-Muster ist fast das selbe wie im letzten Jahr und auch für Sentinel-2A und Sentinel-2B anscheinend identisch. Zur Zusammenfassung: Der größte Teil von Europe und Afrika sowie Grönland werden bei jeder Gelegenheit aufgenommen (was ein 10-Tage-Intervall für jeden Satelliten bedeutet). Der Rest der größeren Landflächen mit Außnahme der Antarktis wird bei jeder zweiten Gelegenheit aufgenommen – außer einige ziemlich willkürlich ausgewählte kleinere Gebiete, für die auch ein 10-Tage-Intervall gilt. Viele kleinere Inseln fehlen. Die Antarktis wurde im Sommer 2016-2017 aufgenommen, aber deutlich seltener als der Rest der Erde.

Außer der beschriebenen räumlichen Verteilung der Aufnahmen (welche recht offensichtlich eine bewusste politische Entscheidung ist), liegt der offensichtlichste Unterschied zu Landsat darin, dass die Aufnahmen bei hohen Breiten in Europa und Grönland nicht ausgedünnt werden, um der stärkeren Überlappung der Aufnahmen dort Rechnung zu tragen. Im Norden Grönlands führt dies im Sommer zu oft mehr als einem Bild pro Tag. Wenngleich das natürlich für Leute, die an diesen Gebieten interessiert sind, recht angenehm ist und auch in gewisser Hinsicht als Kompensation für die Vernachlässigung dieser Regionen generell aufgefasst werden kann, ist das Ganze ziemlich verschwenderisch in Bezug auf die Erfassungs-Ressourcen. Der Grund dafür liegt vermutlich darin, dass hier einfach starr an der Regel festgehalten wird, Grönland und Europa bei jeder Gelegenheit aufzunehmen, was von Bürokraten beschlossen wurde, die keine Vorstellung davon hatten, was dies in der Realität bedeutet.

Schlussfolgerungen

Insgesamt hat sich also nicht so wahnsinnig viel verändert – was so scheint mir für Landsat eine recht gute Nachricht ist, für Sentinel-2 jedoch weniger wenn man die verschiedenen Probleme und Einschränkungen bedenkt, die bereits im letzten Jahr existierten. Aber vielleicht sind wir ja in ein paar Jahren einfach an diese Dinge gewöhnt…

Außer den bereits diskutierten Problemen wird der Betrieb von Sentinel-2 nach wie vor von häufigen Verzögerungen bei der Verarbeitung der Bilder und anderen Zwischenfällen geplagt. Während man bei Landsat recht zuverlässig vorhersagen kann, wann das nächste Bild von einer bestimmten Gegend aufgenommen wird und dass es ein paar Stunden später verfügbar ist, ist dies bei Sentinel-2 oft deutlich weniger zuverlässig.

Bei aller Kritik an den Problemen von Sentinel-2 muss aber auch erwähnt werden, dass mit nun zwei Satelliten im Betrieb mit mehr oder weniger gleichmäßigen Resultaten Sentinel-2 nun in den meisten Fällen eine höhere Aufnahme-Frequenz bietet als Landsat 8 (was ein praktisch sinnvoller Vergleich ist, denn Landsat-7-Daten sind durch die SLC-Lücken oft nur schwierig zu verwenden) – und zwar selbst in den Kontinenten mit geringerer Priorität – mit Ausnahme der kleinen Inseln und der Antarktis natürlich. In anderen Worten: Wenn man nach dem neuesten Bild für einen bestimmten Punkt auf der Erde sucht, findet man dies eher im Sentinel-2-Archiv als bei Landsat 8 – trotz der Verzögerungen in der Verarbeitung der Daten, fehlenden Aufnahmen oder nicht erfolgter Veröffentlichung, welche sich bei Sentinel-2 negativ auswirken.

Und noch etwas positives zu Sentinel-2 – die Verfügbarkeit der Download-Infrastruktur ist in der letzten Zeit deutlich besser geworden. Längere ungeplante Ausfälle, bei denen über längere Zeiträume überhaupt kein Download möglich ist, kommen kaum mehr vor.

Hier zum Nachschlagen alle Visualisierungen der Aufzeichnungen von diesem und den vergangenen Jahren:

Jahr Tag Nacht Pixel-Abdeckung Tag
2014 LS8, LS7 LS8 LS8
2015 LS8, LS7 LS8 LS8
2016 LS8, LS7 LS8 LS8, S2A
2017 LS8, LS7 LS8 LS8, S2A, S2B, S2 (beide)

Auch zu erwähnen sind die detaillierten Abdeckungen für jede Umlauf-Periode und die täglichen Erfassungs-Zahlen.

iceland_autumn2017_expose.ann

29. Oktober 2017
von chris
Keine Kommentare

Inseln im Frühling und Herbst

Hier ein paar Satellienbild-Eindrücke von den letzten Wochen von Inseln im Frühling und Herbst. Zunächst eine Ansicht vom Südwesten Islands von vor ein paar Tagen:

Dann ein Blick bei gutem Wetter auf Südgeorgien im Frühling – mit einem großen Eisberg im Nordosten:

Und schließlich ein Bild von Onekotan im Norden der Kurilen:

Die ersten beiden Bilder basieren auf Copernicus Sentinel-2-Daten, das letzte ist auf Grundlage von Landsat-Bildern produziert.

carto-path_980

26. Oktober 2017
von chris
6 Kommentare

Linien zeichnen

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

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

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

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

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

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

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

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

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

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

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

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

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

(die selben Stellen im Standardstil: hier und hier)

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

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

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

Die gezeigten Änderungen finden sich hier.

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

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

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

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

nz_980

19. Oktober 2017
von chris
Keine Kommentare

Neuseeland-Mosaik und 3d-Ansichten

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

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

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

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



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


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

osm-name_980

12. Oktober 2017
von chris
Keine Kommentare

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

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

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

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

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

Beschriftungen in mehreren Sprachen in Marokko

Beschriftungen in mehreren Sprachen in Korea

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

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

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

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

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

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

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

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

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

alaska_autumn_crop1.ann

5. Oktober 2017
von chris
Keine Kommentare

Herbstfarben 2017

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

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

Hier zwei vergrößerte Ausschnitte daraus:

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

Auch hier zwei vergrößerte Ausschnitte:

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

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

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

lz_980

1. Oktober 2017
von chris
6 Kommentare

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

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

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

Wasserflächen-Darstellung vom letzten Jahr

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

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

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

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

Beispiel für generalisierte Landbedeckungs-Flächen

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

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

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

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

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

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

Wie die Landbedeckungs-Klassen zusammengefasst werden

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

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

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

Mit Linien und Beschriftungen

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

Normale Darstellung ausschließlich aus OSM-Daten

Mit Fallback-Ebene

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

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

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

20. September 2017
von chris
Keine Kommentare

Umfrage zu organisiertem Mapping in OpenStreetMap

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

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

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

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

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

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

delong_s2_980

6. September 2017
von chris
Keine Kommentare

Nochmal zur Positions-Genauigkeit von Satellitenbildern

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

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

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

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

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

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

 

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

 

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

 

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

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