Imagico.de

blog

11. November 2018
von chris
Keine Kommentare

Muster verwalten

Beim letzten OSM-Hack-Weekend habe ich an etwas gearbeitet, was schon seit längerem ein wunder Punkt vieler Kartenstile ist. Es ist das Problem der Bilder für Flächen-Muster. Ich hab über Flächen-Muster in der Vergangenheit schon recht viel von der Gestaltungs-Seite geschrieben. Von der technischen Seite sieht die Geschichte folgendermaßen aus:

Am Anfang waren Flächen-Muster gleichbedeutend mit Raster-Bildern denn die Renderer kannten nichts anderes. An irgendeinem Punkt hat dann Mapnik Unterstützung für SVG-Muster eingeführt. Dies war und ist jedoch weiterhin hinsichtlich der unterstützten SVG-Funktionen sehr begrenzt so dass es eine Vorbearbeitung der SVG-Dateien benötigt. Das eigentliche Problem ist jedoch, dass die SVG-Muster-Wiedergabe von Mapnik kaputt ist und unter gewissen Bedingungen (siehe hier und hier) zu fehlerhaften Darstellungen führt. Der einzig sichere Weg korrekte und konsistente Darstellungs-Ergebnisse bei Karten für die Bildschirm-Anwendung zu erhalten ist also nach wie vor die Verwendung von PNG-Mustern.

Gleichzeitig ist es aber so, dass wenn man für den Druck Karten rendert PNG-Muster von Mapnik nicht wie die übrigen Elemente der Karte mit der Auflösung skaliert werden. Für den Druck möchte man also im Allgemeinen SVG-Muster verwenden.

Um das Dilemma zu lösen habe ich ein Skript geschrieben, das

  • automatisch sowohl PNG- als auch SVG-Dateien aus den SVG-Quellen erzeugt, wobei bei einfarbigen Mustern auch die Farbe geändert werden kann ohne dass man per Hand das SVG editieren muss.
  • es erlaubt, automatisch zwischen der Verwendung der PNG-Muster und den SVG-Mustern zu wechseln ohne dass man hierfür die MSS-Dateien per Hand editieren muss.
  • Voransichten der Muster mit der passenden Hintergrund-Farbe erzeugt.

Dieses Skript ist für Kartenstile auf Basis von CartoCSS+Mapnik geeignet, kann aber natürlich auch für andere Systeme angepasst werden.

Auf dem Client gerenderte Karten mit kontinuierlichem Zoom haben übrigens ihre eigenen spezifischen Probleme mit der Verwendung von Flächenmustern – was einer der Hauptgründe ist, weshalb in solchen Karten kaum Muster verwendet werden.

Vektor-Version des Swamp-Musters

Die Planung und Entwicklung davon hab ich größtenteils auf dem Hack-Weekend durchgeführt aber einige der Muster benötigten etwas zusätzliche Vorbereitung, um für die automatische Verarbeitung geeignet zu sein, was mich danach noch etwas beschäftigt hat. Dies betraf vor allem die Feuchtgebiets-Muster, welche mehrfarbig sind und in einem Raster-Prozess erzeugt wurden sowie das Fels-Muster, welches die jsdotpattern-Funktion für Rahmen-Linien verwendet, welche mit weißen Umriss-Linien gezeichnet werden, was eine Menge Arbeit erfordert um diese in eine optisch identische einfarbige Geometrie umzuwandeln. Es gibt auch noch einige ältere Muster, insbesondere verschiedene Linien-Schraffuren, um welche ich mich noch nicht gekümmert habe.

Fels-Muster reduziert auf eine einfache einfarbige Geometrie

Hier ist der aktuelle Satz an Mustern aus dem alternative-colors-Stil auf Grundlage der vom Skript erzeugten Voransichten, jede zusammengesetzt und beschnitten auf 128×128 Pixel Größe.

Muster im alternative-colors-Stil

3. November 2018
von chris
Keine Kommentare

Über OpenStreetMap-Kartographie reden

Anfang der Woche habe ich in Dresden bei der lokalen Sektion der DGfK einen Vortrag über OpenStreetMap-Kartographie gehalten. Da ich mehrere Anfragen zu den Folien dafür bekommen habe veröffentliche ich sie hier.

Der Vortrag behandelt in erster Linie offene Karten-Projekte aus der Community – im Gegensatz zu kommerziellen Karten auf OSM-Basis. Bei der Vorbereitung des Vortrags hab ich jedoch auch festgestellt, dass hinsichtlich kartographischer Innovation kommerzielle OSM-Karten im Grunde weder heute noch in der Vergangenheit eine große Bedeutung haben. Das ist ein bisschen beunruhigend, denn die Entwicklung digitaler Kartographie steht natürlich auch außerhalb von OpenStreetMap nicht still. Während OpenStreetMap also also in der Vergangenheit Vorreiter bei der Entwicklung von Techniken der digital regelbasierten Kartographie war, scheint es, dass sich heute viele kommerzielle OSM-Daten-Nutzer vollständig auf die technologische Seite der Karten-Produktion konzentrieren und recht wenig Interesse an tatsächlichem kartographischem Fortschritt zeigen.

Dabei gibt es im Grunde eine Menge Aspekte der Kartographie von digitalen interaktiven Karten, die bis jetzt oberhalb des Niveaus vom Ausprobieren zufälliger Ideen und technischer Spielerei noch kaum analysiert und diskutiert worden sind.

1. November 2018
von chris
Keine Kommentare

Aufruf Mitglied in der OSM Foundation zu werden

Am 15. Dezember sind die diesjährigen Wahlen zum OSMF-Vorstand und im Gegensatz zu letztem Jahr möchte ich dieses Thema dieses mal schon früher thematisieren mit dem Aufruf an Alle, die sich in OpenStreetMap als Mapper oder anderer Weise in ihrer Freizeit engagieren und denen das Projekt am Herzen liegt – diejenigen also, die das Herz und die Seele des Projektes sind, Mitglied in der OSMF zu werden, um bei den Wahlen teilnehmen zu können, was nur noch bis zum 15. November möglich ist (30 Tage vor den Wahlen). Das kostet 17 Euro für ein Jahr und wird nicht automatisch verlängert, man muss also nicht mit zusätzlichen Kosten durch die Hintertür rechnen.

Meine Motivation dafür ist, dass die OSMF sich sowohl was die Mitglieder als auch was den Vorstand betrifft in den letzten Jahren deutlich davon entfernt haben, die OSM-Community in ihrer Zusammensetzung und in ihren Interessen zu repräsentieren. Ich hatte dies schon bei der letzten Wahl als zunehmendes Problem angedeutet.

Ich schließe mich damit gewissermaßen dem Aufruf von Michael Reichert an, in dem er seine Analyse der Situation der OSMF detailliert dalegt. Ich stimme nicht in allen Details mit seiner Analyse überein, mit den wichtigsten Schlussfolgerungen und dem Aufruf selbst jedoch schon.

Wichtig im Auge zu behalten ist: Mitglied in der OSMF zu werden ist der einzige Weg, wie ein Mapper wirklich substantiell Einfluss auf die OSMF nehmen kann in einer Form, die nicht ignoriert werden kann. Die Hürden dafür sind hoch, das Ganze entspricht gewissermaßen eher dem amerikanischen Demokratie-Verständnis – man muss einen Monat vor den Wahlen Mitglied werden (quasi: sich für die Wahl registrieren), um eine Stimme zu haben und die Aufstellung der Kandidaten und der Wahlkampf beginnen erst nach dem Ende dieser Frist, so dass man nicht spontan entscheiden kann, zur Wahl zu gehen, um seiner Meinung Gehör zu verschaffen.

Manch einer denkt jetzt vielleicht, diese Initiative ist nur der Versuch, statt amerikanischen Konzerninteressen andere Partikularinteressen von irgendwelchen Fortschritts-Gegnern in Deutschland in den Vordergrund zu schieben. Es geht aber hier nicht darum, dass Ihr der OSMF beitreten sollt um dann in einem gewissen Sinne abzustimmen, sondern darum beizutreten, um dann so zu entscheiden, wie Ihr es im Interesse von OSM für richtig hält. Das kann im Einzelfall von Person zu Person durchaus unterschiedlich aussehen, ich bin mir aber sicher, dass sich die allermeisten Hobby-Mapper einig sind, dass die Richtung, in die die OSMF derzeit tendiert – sowohl in dem was sie tut als auch dem was sie nicht tut, die falsche ist. Was genau die richtige Richtung ist, kann und sollte dann durchaus im offenen Diskurs und im Wettstreit der Argumente entschieden werden.

Aus meiner Sicht ist das Ganze ein bisschen der letzte Versuch, die OSMF als Vertretung der Interessen des OpenStreetMap-Projektes und seiner Aktiven zu retten. Die Alternative wäre am Ende, zu versuchen, die OSMF zu begraben indem die Mapper sie einfach völlig ignorieren. Dieses Szenario hätte aber zwei bedeutende Nachteile:

  • man würde die OSMF in jeglicher Hinsicht verlieren und müsste Alternativen dazu aufbauen – das würde viel Einsatz und Engagement von Leuten erfordern, was nicht unbedingt realistisch ist.
  • eine freidrehende OSMF könnte – selbst wenn von den Mappern und sonstigen Aktiven weitgehend ignoriert – enormen Schaden am OSM-Projekt anrichten.

Kurz: Bevor man diesen Weg mit seinen Risiken und Problemen einschlägt wäre es gut, noch einmal ernsthaft zu versuchen, die OSMF in eine produktive Richtung umzusteuern, die nachhaltig im Interesse des OSM-Projektes liegt. Und das geht nur mit Mitgliedern, die sich dafür einsetzen.

Ich weiß, dass für viele Mapper die Mitgliedschaft in der OSMF nicht wirklich erstrebenswert erscheint – sich da noch mal separat anmelden zu müssen, damit die eigenen Interessen Gehör finden in einer Organisation, deren offensichtlicher Zweck es eigentlich sein sollte, genau diese Interessen zu vertreten. Und dann auch noch 17 Euro pro Jahr dafür zahlen zu müssen wo man doch schon unzählige Stunden seiner Freizeit in das Projekt investiert ist wirklich ein ziemlicher Affront. Aber wenn die Hobby-Mapper eine solide Mehrheit in der OSMF haben, dann können wir das auch ändern.

Nachtrag: Es gibt jetzt auch einen Aufruf auf Französisch – was besonders wichtig ist denn französische Mapper sind in der OSMF im Moment ganz besonders unterrepräsentiert.

18. Oktober 2018
von chris
Keine Kommentare

Sentinel-3 L2-Daten – ein kurzer Einblick

Im Juli 2017 als die ersten Sentinel-3 Level-2-Daten veröffentlicht wurden habe ich nicht wie bei den Level-1-Daten einen detaillierten Bericht geschrieben, denn mir schien es sinnvoll, auf den Rest der Daten zu warten, die insbesondere was Land-Gebiete betrifft, deutlich interessanter schienen und deshalb für ein Gesamtbild auf die Daten und eine Gesamt-Bewertung entscheidend waren. Es hat dann allerdings noch mehr als ein Jahr gedauert bis das jetzt vor ein paar Tagen tatsächlich passiert ist – mit einem Gesamt-Zeitraum vom Start des Satelliten bis zur Veröffentlichung aller Daten-Produkte von fast 32 Monaten oder mehr als einem Drittel der Lebensdauer des Satelliten.

Hier ist die aktualisierte Zeit-Linie der Veröffentlichungen von Sentinel-Daten:

  • 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)
    • OLCI/SLSTR L2-Daten seit 5/6 Jul 2017 (>16 Monate)
    • SYNERGY L2-Daten seit 10 Okt 2018 (fast 32 Monate)
    • OLCI L1/L2 von vor 20 Okt 2016: Verfügbar seit Sep 2018.
    • SLSTR L1/L2 von vor Nov 2016/Sep 2017: 32 Monate und wir warten immer noch…
    • SYNERGY L2 von vor 10 Okt 2018: 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)
  • Sentinel-3B: Start 25 Apr 2018, bis jetzt 6 Monate, unklar in wie weit bereits Daten aufgezeichnet werden.

Dennoch habe ich jetzt eine kurze Einführung in die neu verfügbaren sowie die schon länger zugänglichen Level-2-Daten geschrieben. Wer sich für das Thema interessiert, sollte vermutlich zunächst das was ich zu den Level-1-Daten geschrieben habe lesen (Teil 1, Teil 2 und Teil 3) – vieles davon trifft in Analogie auch auf die Level-2-Daten zu.

Zu den neuen Daten mein Bericht auf Englisch.

13. Oktober 2018
von chris
Keine Kommentare

Software-Update für das Blog

Über die letzten Tage habe ich für dieses Blog eine neue WordPress-Version installiert und dabei auf eine neue PHP-Version gewechselt. Das hat gestern wegen fehlerhafter Tests zu einem ungeplanten Ausfall geführt. Jetzt sollte aber wieder alles funktionieren. Falls jemand noch Dinge bemerkt, die nicht mehr so laufen wie sie sollten bitte in den Kommentaren darauf hinweisen.

Bei der Installation dieses Updates habe ich bemerkt, dass ich hier über die Jahre mehr als 1700 Bilder gezeigt habe – zur Illustration hier ein Screenshot der media library:

10. Oktober 2018
von chris
Keine Kommentare

OpenStreetMap – Herausvorderungen in einer sich verändernden Welt

Ich war gerade dabei Material für einen Vortrag vorzubereiten, den ich nächste Woche auf der Intergeo in Frankfurt halten werde und habe mich dabei an ein Thema erinnert, über das ich schon seit einiger Zeit hier schreiben wollte. In dem Vortrag geht es um die Rolle von OpenStreetMap und offenen Daten im Allgemeinen bei der Entwicklung der digitalen Kartographie von einer reinen Dematerialisierung vor-digitaler Arbeitsabläufe hin zu einer regelbasierten Kartographie wo die Arbeit des Kartographen nicht mehr in der Verarbeitung konkreter Daten besteht, sondern in der Entwicklung von Regeln, welche die automatische Produktion einer kartographische Visualisierung aus generischen Geodaten steuern. Ich habe diese Idee mit einem etwas anderen Schwerpunkt bereits auf der FOSSGIS in Bonn präsentiert.

Beim Nachdenken über das Thema habe ich mich an die schon vor einiger Zeit erlangte Erkenntnis erinnert, dass der Erfolg des OpenStreetMap-Projektes zwar weit verbreitet primär auf die Idee der offenen gemeinschaftlich erfasster Daten zurückgeführt wird, dies aber nur die halbe Geschichte ist. Ich lehne mich mal ein bisschen aus dem Fenster – wenngleich man hier natürlich kaum was beweisen kann – und behaupte, dass der Erfolg von OpenStreetMap mindestens zum selben Anteil durch den revolutionären Ansatz bedingt ist, eine komplett generische Datenbank geographischer Daten zu produzieren. Im Bereich der Kartographie war dies zu dem Zeitpunkt ein völlig weltfremder und scheinbar absurder Ansatz. Und ich bin mir gar nicht sicher, ob dies tatsächlich ursprünglich eine bewusste Entscheidung war oder ob dies einfach das Glück war, das Thema ganz ohne all die Voreingenommenheiten anzugehen, die Kartographen dieser Zeit halt gewöhnlich so hatten.

Heute ist mein Eindruck meist, dass es nicht so sehr der Umfang oder die Qualität der Daten oder ihre freie Verfügbarkeit sind, die selbst eher konservative Leute in der Kartographie dazu bringt, die Bedeutung von OpenStreetMap anzuerkennen, sondern die Fähigkeit, die eigene Position in einer sich rapide verändernden Welt zu erhalten und auszubauen, ohne viel in den Grundlagen des Projektes zu ändern und fast ohne irgendwelche zentrale Steuerung des Projektes. Es gab in den letzten Jahren in der OSM-Community eine ganze Reihe von Stimmen, die eine technologische Stagnation im Projekt kritisiert haben – eine Kritik, die nicht überall ganz falsch ist. Aber eines der bemerkenswertesten Dinge an OpenStreetMap ist, dass das Projekt trotz solcher Probleme in der Lage ist, das Wachstum und die Entwicklung der letzten 14 Jahre zu ermöglichen ohne dass das Projekt in seinen Grundstrukturen je neu aufgesetzt und neu definiert wurde wie das bei vergleichbaren eher traditionellen Projekten vermutlich alle paar Jahre notwendig gewesen wäre. Und es gibt keinen Grund anzunehmen, dass dies nicht für die absehbare Zukunft mit den selben Grundprinzipien auch weiter funktionieren kann. Wobei ich mich mit dieser Einschätzung nur auf die Kern-Prinzipien des Projektes beziehe und nicht alles, was sich mit der Zeit darum herum eintwickelt hat.

Man könnte sich also stolz zurücklehnen und denken: Alles gut. Aber das ist natürlich nicht die ganze Geschichte. Da OpenStreetMap mit seiner revolutionären Herangehensweise an die Kartographie anfangs ziemlich alleine war, musste das Projekt die meisten Dinge aus praktischer Notwendigkeit selbst entwickeln und wurde damit zu einer recht innovativen Kraft in der kartographischen Datenverarbeitung. Später kam dann das große Feld der Open-Source-Software in der Geodaten-Verarbeitung und diverse offene Standards bei Geodaten und Datendiensten dazu, welche sich parallel zu OpenStreetMap entwickelt haben, wo aber bei einigen OpenStreetMap ein bedeutendes erstes Anwendungsfeld war, so dass OpenStreetMap weiterhin in vielen Dingen Innovation in der kartographischen Technologie vorangetrieben hat (wenngleich man hier auch ein bisschen Anerkennung für Google geben sollte).

Damit, dass die institutionelle Kartographie sich zunehmend den Ideen der regelbasierten kartographischen Ansätze öffnet, sind diese Werkzeuge und die Möglichkeiten, die sie bieten aber kein exklusives Feld von OpenStreetMap mehr. Während man vor 5-8 Jahren eine Karte auf OSM-Basis meist schon aus der Entfernung aufgrund bestimmter charakteristischer Gestaltungs-Elemente als solche erkennen konnte ist dies heute nicht mehr der Fall. Kartenproduzenten kombinieren verbreitet OSM- und nicht-OSM-Daten, zum Beispiel auf Basis regionaler Aufteilungen, und das ist oft ohne dass man genau hinschaut nur schwer zu erkennen.

Anders ausgedrückt: OpenStreetMap hat seine fast vollständige Dominanz des technologischen Felds der regelbasierten digitalen Kartographie verloren. Daran ist an sich nichts schlechtes, denn OSM ist kein Technologie-Projekt, sondern ein Projekt zur gemeinschaftlichen Erfassung geographischer Daten – und in diesem Bereich nimmt seine Dominanz eher zu als ab. Dennoch hat diese Entwicklung einen erheblichen Einfluss auf das Projekt, denn OSM entwickelt sich damit nicht mehr in seinem eigenen isolierten Ökosystem, welches es anfangs aufgrund der fundamentalen Unterschiede zur traditionellen Kartographie geschaffen hat und in welchem die einzige sichtbare Konkurrenz im Grunde die kommerziellen nicht traditionellen Kartographie-Projekte waren (also Google, Here, usw.). Jetzt ist dieses Feld deutlich breiter und flacher geworden. Und auf diesem breiteren Feld finden auch andere Datenquellen Verwendung, insbesondere auf regionaler Ebene, aber auch globale, automatisch erzeugte Datensätze, andere gemeinschaftlich produzierte Daten wie Wikidata sowie weiterverarbeitete von OSM abgeleitete Daten. Mit all diesem steht OSM nun im Grunde im Wettbewerb und es gibt keine nennenswerte technologische Hürde aufgrund verschiedener kartographischer Traditionen mehr, die dem im Wege steht.

Wie bereits gesagt ergibt sich für OpenStreetMap hieraus im Grunde kein Problem als Datenproduzent. Das Haupt-Risiko hieraus resultiert in meinen Augen aus den Reflexen, mit denen viele Leute in der OSM-Community auf diese Entwicklung reagieren, weil sie diese zumindest unterbewusst doch als Bedrohung wahrnehmen.

Ich sehe hier zwei bedeutende Trends:

  • Die Abkehr vom Prinzip der generischen Geodaten und dem Grundsatz der Überprüfbarkeit, welche maßgeblich für den Erfolg von OpenStreetMap verantwortlich waren. Die Leute sehen die Stärke von OSM in der großen Gemeinschaft mit vielen Leuten aber sie haben kein Vertrauen, dass diese Stärke sich auf lange Sicht gesehen im Bereich überprüfbarer geographischer Informationen gegen die Kombination von institutionellen Datenproduzenten, Bot-Mapping und Fernerkundung erfolgreich behaupten kann. Also versucht man, den Bereich subjektiver, handgestalteter kartographischer Informationen, welchen die institutionellen Produzenten gerade zunehmend verlassen, da er für sie nicht mehr tragfähig ist, zu erschließen, also gerade den Bereich, der bis jetzt bei OpenStreetMap bewusst ausgespart ist.
  • Sich an den Annehmlichkeiten der Isolation vom Rest der Welt der Kartographie festzuhalten indem man die Welt außerhalb von OpenStreetMap ignoriert oder sie als irrelevant deklariert. Die technologische Trennung zwischen OpenStreetMap und der eher traditionellen Kartographie hat schon immer ein gewisses Risiko der Selbstbezüglichkeit mit sich gebracht, insbesondere mit dem Wachstum des Projektes. Die breite Nutzung von OSM-Daten auch außerhalb der unmittelbaren Umgebung des Projektes hat dem bis jetzt allerdings recht erfolgreich entgegen gewirkt. Aber dennoch gibt es einen gewissen Trend in der OSM-Community, die Komplexität der Welt auszublenden und irgendwie zu versuchen, selbstgenügsam in der eigenen Welt weiter zu arbeiten.

Ich glaube, dass diese beiden Trends – egal ob diese jetzt ausschließlich eine Reaktion auf die beschriebenen Entwicklungen sind oder ob da auch noch andere Faktoren hineinspielen – zu den größten Herausforderungen zählen, denen OpenStreetMap derzeit gegenüber steht. Wie gesagt sind die Kern-Prinzipien des Projektes (generische, überprüfbare Geodaten auf Grundlage des lokalen Wissens der Beitragenden) im Grunde eine solide Basis, welche das Projekt vermutlich für die absehbare Zukunft tragen können – jedoch nur, wenn die OSM-Community auch Vertrauen und Unterstützung für diese Prinzipien mitbringt.

Ich werde vermutlich noch detaillierter in einem zukünftigen Beitrag zu den Tendenzen gegen die Überprüfbarkeit von Daten in OSM schreiben.

Eine andere damit verbundene Entwicklung ist, dass während im OpenStreetMap-Ökosystem eine umfassende Dominanz von Open-Source-Software herrschte die Welt der institutionellen Kartographie seit jeher auch stark von proprietärer Software geprägt ist, Es ist kein Zufall, dass Esri vor ein paar Monaten einen Kartendienst auf Grundlage proprietärer Software vorgestellt hat, der recht klar dem OSM-Standardstil nachempfunden ist, welcher gewissermaßen ein Sinnbild für die regelbasierte Kartographie in OpenStreetMap darstellt. Es ist klar, dass die Anbieter proprietärer kartographischer Software sich aus der regelbasierten Kartographie nicht raushalten möchten. Und bei den institutionellen Kunden hat man hier auch gar keine schlechten Startbedingungen.

Dies ist natürlich weniger für OpenStreetMap direkt eine Herausforderung als für die OSGeo-Welt.

22. September 2018
von chris
Keine Kommentare

Die Essenz von OpenStreetMap

Frederik hat gestern im deutschsprachigen OSM-Forum gefragt, was die verschiedenen Aktiven im Projekt als die Essenz von OpenStreetMap wahrnehmen (im Sinne von “Was sind die essentiellen Eigenschaften von OSM, ohne die es nicht mehr OSM wäre?”). Das ist eine sehr interessante und wichtige Frage. Und ich glaube, dass die Meinungen dazu und wie sich diese mit der Zeit entwickeln sehr viel über den Zustand und die Entwicklung des Projektes aussagen. Leider ist es natürlich schwierig, auf eine so abstrakte und schwierige Frage in der Breite präzise Antworten zu bekommen.

Hier mein Versuch dazu. Für mich sind folgende Faktoren von übergeordneter Bedeutung:

  • Erfassung der Daten von Menschen für Menschen – d.h. die Datenerfassung ist unter der Kontrolle und Verantwortung von gleichgestellten Einzelpersonen und der Zweck der Datenerfassung ist primär die Nutzung durch Einzelpersonen.
  • Überprüfbarkeit der Daten – der Kern hiervon ist für mich insbesondere die konzeptionelle Abgrenzung von Projekten wie Wikipedia, welche die Beobachtung vor Ort ablehnen und stattdessen die die gesellschaftlich dominierende Vorstellung der Realität abbilden wollen (a.k.a. Tagesschau-Wahrheit).
  • Was die nicht direkt Mapping-orientierten Teile des OpenStreetMap-Projektes angeht – ich denke dabei vor Allem an Tagging-Diskussionen, Entwicklungs-Arbeiten oder das Aufstellen und die Diskussion von praktischen Regeln usw. – ist das meritokratische Prinzip für mich von essentieller Bedeutung. Die Idee dahinter ist, dass Entscheidungen immer auf Grundlage einer sachlichen Diskussion auf Basis von inhaltlichen Argumenten und überprüfbaren Belegen erfolgen.
  • Der soziale Vertrag – bestehend auf der einen Seite in der offenen Lizenz mit der Pflicht zur Quellen-Nennung und dem share-alike der Daten als sozialer Vertrag zwischen den Mappern und den Datennutzern. Auf der anderen Seite aber besteht ein solcher Vertrag auch unter den Mappern – durch das Prinzip “Gleiche Regeln für alle” sowie das Primat der lokalen Community (die lokalen Mapper haben die Hoheit über ihre Karte).

Wie die Meisten vermutlich erkennen, sind diese Grundsätze eng miteinander verwoben, einen Einzelnen davon zu entfernen würde zu erheblichem Ungleichgewicht und zu sozialen Verwerfungen im Projekt führen.

Dass diese Grundsätze von Einzelnen in Frage gestellt werden ist etwas, das seit Langem immer wieder vorkommt und für sich genommen kein Problem, sondern eher wünschenswert, da man dadurch dazu angeregt wird, eigene Prinzipien zu hinterfragen. Eine Frage, die ich mir erst in jüngerer Zeit gestellt habe, ist jedoch, ob es eigentlich unter den Aktiven in OpenSteetMap noch eine Mehrheit für diese Grundsätze gibt. Wenn jemand die Annehmlichkeiten und den Erfolg des Projektes schätzt, bedeutet das nicht zwangsläufig auch, dass er oder sie sich die Grundsätze, die zu diesem Erfolg geführt haben und für den zukünftige Erfolg entscheidend sind, auch zu eigen macht. Was ich in letzter Zeit recht häufig beobachte ist, dass Leute – oft aus einer sehr kurzsichtigen und egoistischen Motivation heraus – Kernprinzipien des Projektes in Frage stellen ohne sich klar zu machen, dass sie damit quasi an dem Ast sägen, auf dem sie sitzen.

Die oben aufgezählten Grundsätze sind natürlich meine persönliche Einschätzung der Essenz von OpenStreetMap. Andere mögen hier andere Schwerpunkte sehen. Aber ich würde Allen raten auch mal darüber zu reflektieren und kritisch zu hinterfragen, ob

  • die von einem wahrgenommene Essenz von OpenStreetMap tatsächlich in der Lage ist, das Projekt langfristig zu tragen.
  • die Grundsätze von einer Mehrheit der OSM-Aktiven geteilt werden.

19. September 2018
von chris
Keine Kommentare

Arktischer Herbst

Der nordhemisphärische Sommer war diese Jahr – obwohl er in Europa viel trockenes und sonniges Wetter gebracht hat – für die Arktis ein recht gemäßigter Sommer mit recht begrenzten Aufnahme-Möglichkeiten für gute Satellitenbilder, insbesondere bei sehr hohen Breiten. Der USGS hat auch diese Jahr wieder mehrere Bildreihen im Norden Grönlands außerhalb der regulären Landsat-Abdeckung aufgenommen (ich habe darüber schon früher geschrieben) – aber da diese Aufnahmen fest auf Path 40 begrenzt werden und keine Anpassung an die Wetter-Situation vorgenommen wird, ist das Ergebnis in den meisten Fällen sehr wolkig. Die besten Bilder von diesem Jahr stammen vom September wo jedoch bereits ein bisschen frischer Schnee gefallen ist. Ich habe diese Bildreihe ergänzt mit weiteren Bildern aus dem selben Zeitraum, um ein etwas größeres Mosaik des nördlichsten und gleichzeitig auch abgelegensten Teils der nördlichen Hemisphäre zu produzieren:

Bildaufnahmen bei hohen Breiten sind wie ich bereits früher mal erläutert habe durch deutlich stärkere Unterschiede in der Beleuchtung als bei niedrigen Breiten charakterisiert, was bei der Zusammensetzung zusätzliche Probleme bereitet. Die off-Nadir-Aufnahmen, welche den nördlichen Teil dieses Bildes definieren, zeichnen sich dadurch aus, dass die Aufnahmen am Anfang im Osten eine deutlich spätere lokale Aufnahme-Zeit aufweisen als im Westen. Das klingt intuitiv etwas absurd, ist aber logisch wenn man bedenkt, dass der Satellit hier in diesem Bereich schneller von Ost nach West fliegt als die tageszeitliche Bewegung der Sonne.

Durch den niedrigeren Sonnenstand ergibt sich eine stärkere Filterung des Lichtes durch die Atmosphäre und ein höherer Anteil an indirekter Beleuchtung, was zu einem insgesamt rötlicherem/violetterem Farb-Eindruck führt. Zur Anpassung daran habe ich für den Bereich weiter südlich nach Möglichkeit Aufnahmen verwendet, die eine ähnliche Charakteristik aufweisen – was natürlich nur begrenzt möglich ist durch die Rahmenbedingungen des Wetters und der Aufnahme-Pläne.

Hier ein paar Ausschnitte aus dem Mosaik:

Das Mosaik ist für eigene Verwendungen verfügbar im Katalog auf services.imagico.de.

Eine andere Gegend der Arktis, die ich hier zeigen möchte, ist das Matusevich-Schelfeis in Sewernaja Semlja. Ich habe über dessen Rückgang in den letzten Jahrzehnten in einem früheren Beitrag geschrieben. Diese Jahr konnte man bei den wenigen Gelegenheiten für einen wolkenfreien Blick beobachten, dass die Verbindung zur Karpinsky-Eiskappe jetzt fast verschwunden ist und der kleine Rest des Schelfeises lediglich Zuflüsse von der Rusanov-Eiskappe behält. Hier ein Sentinel-2-Bild von Ende August wo – wie im Norden Grönlands – bereits ein bisschen Neuschnee zu sehen ist.

Zum Vergleich hier eine Ansicht der Gegend von 2016 – Bilder von noch früher finden sich unter dem Link oben.

30. August 2018
von chris
Keine Kommentare

Mehr zur Verwendung von Flächenmustern in Karten

Flächenmuster und deren Verwendung in der Kartographie sind ein Thema, über das ich bereits in der Vergangenheit geschrieben habe. Wenn wir konkret von einfachen einheitlichen Mustern sprechen, ergeben sich in der Anwendung insbesondere folgende Vorteile:

  • Mit Flächenmustern lassen sich Flächen ohne unterschiedliche Farben differenzieren – und die Möglichkeiten zur Differenzierung sind auch wesentlich umfassender, denn die Zahl möglicher Muster-Varianten ist viel größer als die Zahl möglicher unterscheidbarer Farben.
  • Ein intuitives Verständnis der Bedeutung eines Musters ist deutlich einfacher zu erreichen als bei einer Farbe alleine. Bei Farben gibt es ein paar allgemeine Konventionen (wie Blau für Wasser und Grün für Vegetation) und manchmal die Regel der Ähnlichkeit (dass ähnliche Farben eine ähnliche Bedeutung haben) aber darüber hinaus ist die Bedeutung von Farben in einer Karte üblicherweise etwas, das man nachschauen und lernen muss oder anhand von Beispielen lernen kann, während ein gut gewähltes Muster oft zumindest eine gewisse Möglichkeit schafft, die Bedeutung aus den gewählten Formen und Strukturen abzuleiten.

Ich möchte hier anhand von ein paar Beispielen erläutern, wie sich das für die Gestaltung besserer Karten nutzen lässt.

Industrielle Landnutzung

Das erste Beispiel ist etwas, das ich bereits vor einiger Zeit im alternative-colors-Stil implementiert, jedoch bis jetzt noch nicht konkret diskutiert habe. Es betrifft industrielle Landnutzung im engeren Sinne – damit meine ich nicht landuse=industrial, was Land beschreibt, auf dem industrielle Infrastruktur gebaut worden ist, sondern Gebiete wo das Land selbst industriell genutzt wird, konkret landuse=quarry (Bergbau, Extraktion von Material aus der Erde), landuse=landfill (die Lagerung von Material, insbesondere Abfall), landuse=construction (Baustellen) und landuse=brownfield (als Vorläufer einer Baustelle).

In OSM-Carto werden diese derzeit in drei unterschiedlichen Farben dargestellt, brownfield und construction sehen gleich aus. Zumindest zwei dieser Farben ähneln stark anderen Flächenfarben, welche eine deutlich andere Bedeutung haben. Dieses Problem ist ein Symptom der Tatsache, dass der Standardstil das Ende der Fahnenstange erreicht hat was die Nutzung von Farben angeht. Es ist mittlerweile fast unmöglich geworden, neue Farben im Stil einzuführen, ohne dass sie mit anderen Farben kollidieren. Die meisten jüngeren Entscheidungen in Bezug auf Farben dort leiden an diesem Problem.

Was ich bei der industrielle Landnutzung gemacht habe, um solche Probleme zu vermeiden ist, dass ich mich auf eine Farbe für alle vier Nutzungsarten beschränkt habe – denn diese haben ja wie erläutert erhebliche Gemeinsamkeiten – und die weitere Differenzierung bei höheren Zoomstufen über Flächenmuster vornehme. Hier kann man sehen wie das aussieht.

Flächenmuster für die industrielle Landnutzung

Während die meisten dieser Muster (mit Ausnahme von quarry vielleicht) vermutlich für die meisten Kartennutzer in ihrer Bedeutung nicht intuitiv völlig klar zu verstehen sind – dies ist ein bisschen der Preis dafür, ein relativ fein strukturiertes Muster, welches sich für kleine Flächen eignet, zu verwenden – besteht dafür aber zumindest eine deutlich bessere Chance als bei der Verwendung von einförmigen Farben.

Landwirtschaftliche Details

Das andere Beispiel ist die Darstellung zusätzlicher Details bei der landwirtschaftlichen Landnutzung, konkret bei landuse=farmland und landuse=orchard.

Zunächst ein bisschen Information zum Tagging – die Differenzierung zwischen verschiedenen Nutzpflanzen bei der landwirtschaftlichen Landnutzung ist in OpenStreetMap recht kompliziert und auch ein bisschen willkürlich. Das beginnt mit der primären Differenzierung in verschiedene Landnutzungen. Konkret haben wir:

  • landuse=farmland – welches entweder als generisches Tag für alle Arten der landwirtschaftlichen Landnutzung dient oder (wie meist praktiziert) nur für all das, was von den anderen nachfolgenden Landnutzungen nicht abgedeckt wird.
  • landuse=meadow – Weideland und für Heu gemähte Wiesen.
  • landuse=orchard – was für Bäume und Sträucher für die Produktion von Früchten oder Nüssen (oder anderen Produkten außer Holz) vorgesehen ist.
  • landuse=vineyard – was im Grunde ein separates Tag für einen Typ von landuse=orchard darstellt.

Eine weitere Differenzierung darüber hinaus geschieht mittels crop=* (für farmland) oder trees=* (für orchard) oder produce=*.

Die Unterscheidung zwischen landuse=farmland and landuse=meadow wird nicht ganz konsistent gehandhabt – es gibt zum Beispiel 19k Verwendungen der Kombination landuse=farmland + crop=grass. Und was genau durch landuse=orchard abgedeckt wird ist auch recht merkwürdig – Tee-Plantagen werden zum Beispiel meist als landuse=farmland + crop=tea, ähnlich wie Kaffee – obwohl es in geringerem Umfang bei beiden auch die Verwendung von landuse=orchard gibt.

Die vier aufgeführten Landnutzungen werden im Standardstil unterschiedlich dargestellt – ursprünglich alle mit verschiedenen Farben, ich habe vor kurzem über die Geschichte der Farmland-Farbe geschrieben. Vor ein paar Jahren habe ich die Farben von orchard und vineyard vereinheitlicht und beide nur noch über das Flächenmuster differenziert, was der großen Ähnlichkeit zwischen beiden Rechnung trägt.

All dies demonstriert recht deutlich eine Britisch-Mitteleuropäische Perspektive auf Grundlage der in diesen Regionen dominierenden landwirtschaftlichen Nutzungsformen. In Bezug auf die Struktur des Taggings ist dies verständlich wenn man die geschichtliche Entwicklung von OpenStreetMap im Kopf hat. Wenn sich eine Tagging-Idee erst einmal verbreitet etabliert hat, lässt sich diese nur noch schwer wieder modifizieren. Aber dies ist nicht der Kern des Problems. OpenStreetMap hat ein freies Tagging-System so dass Mapper anderswo auf der Welt ihre eigenen Tags verwenden oder Zusatztags definieren können. Da komplett neue Tags den Nachteil haben, dass sie sich nur schwer bei Datennutzern durchsetzen lassen, sind Zusatztags der verbreitetere Ansatz. Wir haben deshalb eine Menge Zusatztags für landuse=farmland und für landuse=orchard auch für Planzen, die in Großbritannien und Mitteleuropa nicht wachsen.

Und hier ist der Punkt, wo die Probleme liegen – Kartenstil-Entwickler sagen zurecht, dass man nicht alle Nutzpflanzen-Arten in einer Karte für allgemeine Anwendungen differenzieren kann. Deshalb begrenzen sie die Differenzierung auf die primären Landnutzungs-Klassen, die aber wie erläutert für eine sehr starke geographische Voreingenommenheit stehen. Was das Problem verschärft ist, dass sich Stil-Entwickler in den meisten Fällen des Problems gar nicht bewusst sind, sie halten die Klassen für eine natürliche und global gültige Einteilung obwohl ja eigentlich die recht willkürliche Grenze zwischen landuse=farmland und landuse=orchard und die spezielle Abtrennung von landuse=vineyard das Gegenteil deutlich machen. Bei Diskussionen zur Darstellung von farmland oder orchard kann man fast generell beobachten, wie diese sich in den Köpfen der Entwickler als Getreide-Felder oder Apfelbäume und Beeren-Sträucher manifestieren und kaum jemals eine Reflexion darüber stattfindet, wie voreingenommen diese Bild ist.

Ein Kartenstil, welcher als Rückmeldung an Mapper dient, hat hier noch ein besonderes Problem, denn wenn man die primären Landnutzungs-Klassen nicht differenziert, unterschiedliche Nutzplanzen oder Gruppen davon aber schon (wie zum Beispiel die Vereinheitlichung von orchard und vineyard aber die Diffenzierung von zwei Klassen von orchard aufgrund anderer Kriterien) ist dies für den Mapper potentiell irritierend. Aber wenn man eine gewisse Differenzierung vornehmen möchte ist es essentiell dabei nicht mit einem engen Europäischen Blickwinkel an die Sache heranzugehen, sondern mit einer globaleren Sichtweise.

Das ist der Ansatz, den ich versucht habe bei der Darstellung von farmland und orchard zu verwenden – ich habe jeweils drei Untertypen mittels Flächenmuster differenziert zusätzlich zur generischen Darstellung.

Die neuen Typen von farmland und orchard

Die Typen sind ausgewählt danach wie stark der jeweilige Anbau-Typ sich für den Beobachter differenziert und wie weit verbreitet und konsistent die Verwendung des jeweiligen Tags in OpenStreetMap ist. Ich habe absichtlich keinen Getreideanbau außer Reis mit einbezogen, denn Getreide wird in den meisten Teilen der Welt mit Fruchtwechsel angebaut und deshalb ist hier die Angabe einer einzelnen Sorte meist ungenau. Die dargestellten Pflanzentypen werden üblicherweise nicht im Fruchtwechsel angebaut.

Hier ein paar Beispiele mit realen Daten für die verschiedenen orchard-Typen:

Olivenbaum-Anbau bei z16 – ein Klick zeigt einen größeren Ausschnitt

Ölpalmen-Plantage bei z15 – ein Klick zeigt einen größeren Ausschnitt

Bananen-Plantage bei z16 – ein Klick zeigt einen größeren Ausschnitt

Und hier die farmland-Typen:

Reisfelder bei z15 – ein Klick zeigt einen größeren Ausschnitt

Hopfen-Anbau bei z15 – ein Klick zeigt einen größeren Ausschnitt

Tee-Plantagen bei z16 – ein Klick zeigt einen größeren Ausschnitt

Die Symbolik orientiert sich am Erscheinungsbild der jeweiligen Planzen im Anbau und explizit nicht wie gelegentlich als Ansatz praktiziert am geernteten Produkt. Dies entspricht dem bereits anderweitig im Standardstil gewählten Ansatz. Die Gründe dafür habe ich bereits früher mal erläutert.

Das ist jetzt zunächst einmal natürlich eine Darstellung von Einzel-Sorten und wie schon angedeutet ist es nicht praktikabel, alle weltweit auftretenden landwirtschaftlichen Nutzpflanzen mit eigenen Symbolen darzustellen. Es wird also die Notwendigkeit geben, hier zu gruppieren und zu klassifizieren – wenngleich einige der gezeigten Sorten aufgrund ihrer Bedeutung und ihrer Besonderheit durchaus eine dauerhaft eigene Klasse bleiben könnten. Aber so eine Klassifizierung darf eben nicht ausschließlich auf der historischen Dominanz Europäischer Blickwinkel in OpenStreetMap basieren wie es derzeit im Standardstil der Fall ist. So etwas zu entwickeln ist nicht nur für OpenStreetMap weitgehend Neuland sondern auch in der Kartographie ganz allgemein.

Mir scheint auch dass dieses Beispiel schön illustriert, dass es wenn man Tagging-Konzepte entwickelt eine recht schlechte Idee ist, diese auf einem scheinbar logischen groben Klassifikation-System aufzubauen – wie die Unterscheidung zwischen farmland und orchard – welches bei genauerem Hinschauen jedoch keine klare, überprüfbare und universell anwendbare Grundlage hat. In solchen Fällen ist es besser, Tags mit kleinerem Anwendungs-Bereich aber besser definierter Bedeutung festzulegen – selbst wenn in der eigenen Kultur breitere Begriffe existieren, die man im normalen Sprachgebrauch verwendet.

Wie üblich findet man die Änderungen im alternative-colors-Stil.

16. August 2018
von chris
Keine Kommentare

Neue Version des Muster-Generators

Ich hatte es schon angekündigt, als ich über die Wald-Darstellung geschrieben habe – es gibt eine neue Version des jsdotpattern-Muster-Generators. Darin ist die Symbol-Auswahl komplett neu gestaltet. Diese erlaubt es jetzt beliebige Symbole zu kombinieren und dann mit zufälliger Auswahl in einem Muster zu verwenden. Zuvor geschah dies über fest definierte Symbol-Kombinationen (welche es aus Kompatibilitäts-Gründen weiter gibt).

Ich hab auch eine ganze Reihe neue Symbole ergänzt, insbesondere für Bäume. Hier ein paar Beispiele – ein Klick auf die Bilder ruft den Muster-Generator auf um das jeweilige Muster zu erzeugen so dass man die Parameter ändern oder das Muster als SVG speichern kann.

  

Das Programm findet sich mit den neusten Änderungen auf github.

15. August 2018
von chris
Keine Kommentare

Die Darstellung implizit erfasster Böschungen

Hier ein weiterer Beitrag aus meiner Serie zum Thema Gestaltung von OpenStreetMap-Karten – diesmal zur Darstellung von implizit erfassten Böschungen.

„embankments“ in OpenStreetMap sind künstliche Böschungen, welche vor allem gebaut werden um für den Bau von Straßen oder Schienen eine ebene Plattform zu schaffen – oder um anderweitig die Topographie künstlich zu gestalten. „cutting“ hingegen beschreibt das Gegenteil, künstliche Einschnitte in die natürliche Topographie, welche ähnlichen Zwecken dienen.

Was bedeutet in diesem Zusammenhang implizit? In OpenStreetMap können Böschungen explizit durch eine Linie mit dem Tag man_made=embankment erfasst werden, welche am oberen Rand der Böschung gezeichnet wird. Dies wird seit langem im OSM-Standardstil ähnlich wie natürliche Kliffe dargestellt mit einer grauen Linie und Markierungen auf der einen Seite, um die Richtung der Böschung zu zeigen. Die implizite Erfassung von Böschungen hingegen bedeutet, dass man die Böschungen entlang einer Straße oder Bahnlinie über ein Zusatz-Attribut erfasst. Dies geschieht mittels embankment=yes und cutting=yes. Die implizite Erfassung mittels embankment=yes ist mehr als doppelt so weit verbreitet wie man_made=embankment – zusammen sind embankment=yes und cutting=yes dreimal so verbreitet.

Dennoch werden embankment=yes und cutting=yes in OSM-Carto nicht dargestellt – da es nicht ganz einfach ist, dies in einer ansprechenden Form zu tun.

Was recht problemlos möglich wäre ist die Darstellung von embankment=yes mit einer besonderen Farbe der Umrahmung ähnlich der Darstellung von Brücken (oder wie meine Darstellung von Furten im alternative-colors-Stil). Dies wäre jedoch schwer intuitiv verständlich. Ein besserer Weg der Darstellung wäre in Form einer Linie mit seitlichen Marken wie sie bei man_made=embankment verwendet werden um die Straßen-Linie herum. Hier ist gezeigt, wie das aussehen würde:

Sehr einfache Form der Darstellung von Böschungen und die Fehler, zu denen dies führt

Wie man sieht ist das Ergebnis in ganz einfachen Fällen ganz akzeptabel, das Ganze geht jedoch in komplizierter gelagerten Fällen teils komplett daneben. Insbesondere bei Straßen, wo beide Fahrbahnen separat erfasst werden wie Autobahnen ist dies ein großes Problem.

Um diese Probleme zu vermeiden muss man für jede Straße mit Böschungen deren Umfeld, also andere Straßen mit und ohne Böschungen, mit berücksichtigen. Dies wird sehr schnell sehr kompliziert und in Bezug auf den Rechenaufwand teuer. Hier ist das Ergebnis eines Kompromisses, den ich zwischen Qualität und Geschwindigkeit ausgewählt habe.

Aufwändigere Darstellung von Böschungen

Die Abfrage dafür ist etwa 4-5 mal langsamer als die zuvor gezeigte trivial-Version – das klingt nach viel, ist aber eigentlich gar nicht so schlecht. Aufgrund der Art und Weise, wie die Abfragen durchgeführt werden, ist dies jedoch deutlich weniger effizient, als dies eigentlich theoretisch möglich wäre. Für die Darstellung der Straßen selbst muss man ja sowieso alle Straßen in der jeweiligen Kachel abfragen und man könnte das Ergebnis davon auch verwenden, um die notwendigen Berechnungen bei den Böschungen durchzuführen. Unglücklicherweise lassen sich mit Mapnik jedoch die Ergebnisse von Abfragen nicht in anderen Ebenen wiederverwenden.

Ein weiteres technisches Problem, mit welchem ich schon bei der Darstellung von Quellen und Wasser-Barrieren zu tun hatte ist, dass es für komplexere Geometrie-Berechnungen notwendig ist, die verwendeten Linienbreiten in Abhängigkeit von der Zoomstufe innerhalb des SQL-Codes zu kennen. Um dies zu ermöglichen ohne jedesmal ein längeres CASE-Statement mit den verschiedenen Linienbreiten dort in den SQL-Code einzufügen, wo die Linienbreite eingeht und welche dann alle geändert werden müssen, wenn irgendwo mal eine Linienbreite geändert wird, habe ich ein Skript geschrieben (abgeleitet vom bestehenden Skript für die Straßen-Farben), welches sowohl SQL-Funktionen als auch MSS-Code für die Definition und Auswahl der Linienbreiten auf Grundlage einer yaml-Datei erzeugt.

Die impliziten Böschungen werden werden für alle üblichen Straßen und Wege sowie für Eisenbahn-Schienen und Wasserwege dargestellt.

Böschungen für alle Arten von Linien-Objekten

Wie man sieht habe ich den Abstand der Marker auf den Linien im Vergleich zu OSM-Carto reduziert, da dies mit kleinen Krümmungs-Radien der Böschungen im Zusammenhang mit Straßen besser funktioniert.

Ich beginne mit der Darstellung von impliziten Böschungen ab z16. Früher anzufangen würde bedeuten, dass das Gesamtobjekt Straße plus Böschung sehr viel Platz einnimmt, denn normalerweise werden Straßen bei z15 und unterhalb in einer Linien-Breite gezeichnet, welche über ihrer tatsächlichen Breite liegt und die Böschung macht dies noch breiter. Das führt in vielen Fällen zu Überlappungen mit anderen Objekten und damit zu merkwürdigen Ergebnissen, insbesondere in detailliert erfassten Gebieten, was als Anreiz zum Mappen kontraproduktiv wäre.

Hier ein paar Beispiele bei z16:

Und hier bei z17:

Das letzte Beispiel zeigt sowohl implizit und explizit erfasste Böschungen. Die impliziten Varianten werden bei diesem Maßstab in etwa in ihren tatsächlichen Dimensionen dargestellt. Die implizite Erfassung hat ganz allgemein den Vorteil, dass sie sowohl in diesem Fall, als auch bei anderen Maßstäben gut aussieht während die explizite Erfassung nur dann ordentlich aussieht, wenn die Straße oder der Weg in ihrer tatsächlichen Breite gezeichnet wird. Bei einer geringeren Linienbreite bei den höheren Zoomstufen entsteht eine Lücke zwischen der Straße und der Böschung und bei einer größeren Linienbreite überlappen sich die Linien-Signatur der Straße und die Böschung, so dass letztere entweder nicht oder nur teilweise sichtbar ist. Dies zu vermeiden und die explizit erfasste Böschung bei den niedrigen Zoomstufen passend zu verdrängen wäre recht schwierig. Um hochwertige Karten mit relativ geringem Aufwand zu produzieren ist die implizite Erfassung von Böschungen also deutlich günstiger.

Wer das Ganze selbst ausprobierene möchte findet die Änderungen wie üblich im alternative-colors-Stil.

11. August 2018
von chris
Keine Kommentare

Missionare für Magie

Es war einmal (vor ein paar Jahren) ein Unternehmen namens what3words, welches versucht hat (und anscheinend auch noch immer versucht), Geld mit dem Verkauf eines Adressen-Systems zu verdienen, welches darauf basiert, geographische Koordinaten in eine Zeichenkette zu kodieren. Für jeden mit ein bisschen Verständnis für Geodaten und Geographie ist die Idee, daraus ein Geschäft zu machen, ziemlich offensichtlicher Irrsinn, aber es ist noch irrsinniger, dass sie damit zumindest in begrenztem Rahmen auch noch Erfolg hatten.

Die Sache ist dabei, dass Koordinaten mit einem Gitter-System in irgendeiner Form zu codieren überhaupt nichts neues ist, so dass man die Idee natürlich nicht patentieren kann. Und man kann auf die kodierten Koordinaten auch nicht wirklich Urheberrechts-Ansprüche anmelden. Der einzige Weg damit Geld zu verdienen ist also, das Kodierungs-System geheim zu halten und für Lizenzen für dessen Nutzung Geld zu verlangen.

Insgesamt kann man wohl sagen, dass what3words damit sehr erfolgreich unsere Gesellschaft und unser Wirtschaftssystem getrollt hat.

Für andere Unternehmen in der Branche von ortsbezogenen Diensten, insbesondere natürlich Google, war und ist das Ganze recht ärgerlich. Nicht nur als Konkurrenz sondern auch, weil es die ganze Branche der Lächerlichkeit preis gibt. Das Interesse von Google liegt hier also nicht in erster Linie darin, what3words Marktanteile abzunehmen und mit den selben Dingen Geld zu verdienen – die haben wichtigere Dinge zu tun. Nein, die wollen in erster Linie den Troll loswerden, der die Reputation der gesamten Branche ruiniert.

Um das zu tun macht Google das offensichtliche, sie entwickeln ein alternatives, offenes Kodierungs-System und propagieren es als bessere Alternative in der Hoffnung, dass wer vor der Wahl zwischen einem kostenlosen oder einem kostenpflichtigen System von what3words steht sich eher für das kostenlose entscheidet – vorausgesetzt man untermauert das Genug mit Marketing-Maßnahmen und sichtbarer Unterstützung durch Dritte.

Das ist in etwa der Hintergrund der Situation, die wir im Moment haben. Was ich schon damals, als es mit what3words los ging, bemerkenswert fand ist, dass der einzige wesentliche Kritikpunkt bei der Sache die proprietäre Natur des Systems war. Aber im Grunde gibt es daran noch eine Menge mehr zu kritisieren.

Die wesentliche Verkaufsmasche bei diesen Koordinaten-Kodierungs-Systemen ist, dass es weite Teile der Welt ohne zuverlässiges Adressen-System gibt, insbesondere in Regionen mit rapide wachsender Bevölkerung wie in großen Teilen Afrikas. Also denken sich die IT-Entwickler im Silicon Valley: Das können wir lösen indem wir automatisch Adressen für alle diese armen Leute ohne Adressen erzeugen. Das wäre in Ordnung, wenn sie es dabei belassen hätten und einfach allen Interessierten das Kodierungs-System zur Verfügung gestellt hätten – zur Nutzung nach eigenem Ermessen (und natürlich ohne den fragwürdigen Versuch damit Geld zu verdienen wie bei what3words).

Das ist jedoch nicht das, was jetzt passiert. Da das wesentliche Motiv von Google ist, die Ärgerlichkeit namens what3words los zu werden, können sie sich nicht einfach damit zufrieden stellen, ihre offene Alternative jedem zur Verfügung zu stellen, sie müssen das zumindest so weit offensiv vermarkten, dass es hinsichtlich Markt-Bedeutung in die Nähe von what3words kommt. Und der ganze humanitäre und Entwicklungshilfe-Sektor springt natürlich sofort darauf auf, denn man will ja offensichtlich den armen Leuten in Afrika auch helfen und nicht einfach nur tatenlos daneben stehen wenn Google die beste Idee seit geschnittenem Brot ausrollt.

Zeit für einen Schritt zurück und einem Blick darauf, was Adressen-Systeme eigentlich ausmacht (denn das ist ja der Zweck, für den die Koordinaten-Kodierungs-Systeme dienen sollen). Sarah Hoffmann hat dies in ihrer Präsentation zu Nominatim auf der SotM recht gut erläutert. Adressen sind die Methode, mit welcher Menschen üblicherweise in Kommunikation mit anderen geographische Orte spezifizieren. Da sie vom Menschen für Menschen entwickelt wurden und üblicherweise über Jahrhunderte entstanden sind, unterscheiden sich solche Systeme weltweit recht deutlich abhängig von lokalen kulturellen Besonderheiten. Solche Adressen-Systeme sind üblicherweise danach modelliert, wie ein Mensch seine lokale geographische Umgebung wahrnimmt. Aus diesem Grund ist die Entwicklung eines Geocoders (eines Programms zur Übersetzung zwischen geographischen Koordinaten und Adressen) eine recht anspruchsvolle Aufgabe.

Die zuvor besprochenen Koordinaten-Kodierungs-Systeme sind dagegen danach modelliert, was für den Computer am einfachsten zu interpretieren ist, also die geographischen Koordinaten. Die Kodierung ist zwar darauf abgestimmt, für Menschen lesbar und kommunizierbar zu sein (wobei what3words und Google hier sehr unterschiedliche Ansätze gewählt haben) aber es ist immer noch ein Code, den man entweder auswendig lernen oder nachschauen muss, denn es gibt dazu kein mentales Umfeld in der geographischen Wahrnehmung, das die eigene Addresse in einen Zusammenhang stellt. Da das Kodierungs-Verfahren auch nicht realistischerweise im Kopf durchführbar ist, lässt sich so ein Code eigentlich nur als Adresse verwenden, indem man ihn als magischen Code interpretiert. In anderen Worten: Der einzige Weg, so etwas als Adressen-Sytem in der Kommunikation zwischen Menschen zu verwenden ist, den Code von seiner ursprünglichen Bedeutung loszulösen und ihn als reine Magie zu betrachten.

Das ist es, was Leute aus dem humanitären Sektor anscheinend im Moment verbreitet tun, es werden automatisch in großer Zahl Codes für Gebäude in afrikanischen Ländern erzeugt und diese werden den dort lebenden Leuten dann als die Adressen dieser Gebäude präsentiert. Ein Teil dieses Vorhabens schwappt auch auf OpenStreetMap über wo natürlich die Idee, Codes als Attribute von Objekten zu speichern, welche nur eine Kodierung der geographischen Koordinaten dieser Objekte sind, ziemlich absurd ist. Aber aus der Sicht der in solch einem Projekt beteiligten Leute macht dies natürlich irgendwie Sinn, denn um Menschen dazu zu bringen, diese Codes in der Kommunikation zwischen Menschen zu verwenden und ihnen dadurch eine tatsächliche soziale Bedeutung zu geben, muss man sie wie erläutert als magische Codes losgelöst von ihrer ursprünglichen Bedeutung etablieren.

Ich finde die hinter diesen Versuchen stehende Einstellung ziemlich zynisch und menschenverachtend – und zwar sowohl mit einem proprietären als auch mit einem offenen Kodierungs-System. Anstatt den Menschen in Dörfern in Afrika zu helfen und sie zu beraten, ihr eigenes lokales Adressen-System zu entwickeln, angepasst an ihre lokalen Gegebenheiten und die spezifischen Bedürfnisse, entwickelt man ein System magischer Codes, gestaltet so, dass deren Erzeugung möglichst bequem zu programmieren ist, und legt Menschen in Afrika nahe, ihr Leben um dieses System magischer Codes herum zu organisieren. Die Arroganz und Geschichtsvergessenheit dahinter finde ich ziemlich erschreckend.

Um das klar zu sagen: Ich denke, dass die meisten Leute, die sich derzeit für die Verbreitung dieser Kodierungs-Systeme einspannen lassen, sich vermutlich über diese Zusammenhänge gar nicht im klaren sind, was ein Grund ist weshalb ich hier darüber schreibe.

Und natürlich ist an der Idee, geographische Koordinaten in irgendeiner Form zu kodieren, nichts grundsätzlich verwerfliches. Es sind dafür durchaus Nutzungsmöglichkeiten denkbar, zum Beispiel in der Kommunikation von Mensch zu Computer. Aber wir reden dann natürlich nicht mehr über ein Adressen-System, sondern um ein System zu Angabe und Kodierung von Koordinaten.

Übrigens ist das was Google jetzt forciert im Grunde nur eine primitivere Variante von etwas deutlich älterem. Das System von Google versagt in Pol-Nähe – ein Problem welches sich recht einfach vermeiden ließe, wenn man ein bisschen mehr Gehirnschmalz darin investiert hätte. Aber Google ist wie üblich mit der 90-Prozent-Lösung zufrieden.

Nachtrag: Frederik hat eine FAQ (auf Englisch) zu dem Thema geschrieben welche eine ganze Reihe praktischer Fragen dazu beantwortet.