Imagico.de

blog

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.
Northern Greenland Autumn 2018

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.

agricultural land use patterns

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.

jsdotpattern

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.

embankments rendering

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.

ac_z5_980

4. August 2018
von chris
Keine Kommentare

Zur Diskussion über von der OSMF unterstützte Karten auf Vektor-Kachel-Basis

Anknüpfend an meinen ersten Bericht von der SotM-Konferenz in Mailand möchte ich ein paar Dinge mehr im Detail diskutieren. Das erste davon ist das Thema Vektor-Kacheln auf osm.org.

Etwas Hintergrund dazu: Der Begriff Vektor-Kacheln (vector tiles) hat sich in der OSM-Community in den letzten Jahren zu einer Art weißem Elefanten entwickelt. Mir scheint dass diese über die Jahre als magische Lösung für so ziemlich jedes Problem bei der Kartenproduktion im OSM-Projekt vorgeschlagen wurde.

Wenn der Begriff mit Sinn und Verstand und nicht nur als leere Phrase verwendet wird, geschieht dies für zwei recht verschiedene Dinge:

  • Für die Idee, die Ergebnisse von Abfragen in einem Framework zur gekachelten Darstellung von Karten zwischenzuspeichern. In einem klassischen Karten-Darstellungs-System wie OSM-Carto wird die Karte aus den Ergebnissen einer Reihe von Abfragen von Daten aus einer räumlichen Datenbank (meist Postgis) für das Gebet der jeweiligen Kachel generiert. Das Ergebnis dieser Abfragen wird gleich nach der Berechnung der Kachel weggeworfen. Indem man die Ergebnisse der Abfragen zwischenspeichert lassen sich verschiedene Varianten eines Kartenstils und verschiedene Gestaltungen – wie zum Beispiel verschiedene Sprachen bei den Beschriftungen oder verschieden Farb-Schemata oder Kacheln mit unterschiedlicher Auflösung – deutlich effizienter produzieren.
  • Für die Idee, die eigentliche Darstellung auf dem Client (also dem Web-Browser) statt dem Server zu produzieren auf Grundlage von Vektor-Daten in Kachel-Form. Dies bringt die selben Vorteile mit sich wie der erste Ansatz, erlaubt es aber daneben vor allem dem Karten-Produzenten auch, die Karten-Darstellung und die dafür benötigte Computer-Kapazität an den Nutzer auszulagern.

Man kann sich vermutlich vorstellen, dass es erhebliche technologische Gemeinsamkeiten zwischen den Umsetzungen dieser beiden Ansätze gibt so dass die Verwendung eines gemeinsamen Begriffes dafür einen gewissen Sinn macht. Aber es ist dennoch wichtig, immer klar zwischen beidem zu unterscheiden, wenn man über Vektor-Kacheln redet.

Der erste Ansatz ist in der Praxis recht unproblematisch. Er wird heute weit verbreitet verwendet ohne dass dies für den Nutzer unbedingt erkennbar ist. Von den Karten, die auf openstreetmap.org ausgewählt werden können, verwenden mehrere diese Methoden und es gibt auch einen Port von OSM-Carto, welcher Vektor-Kacheln auf der Server-Seite verwendet. Der zweite Ansatz jedoch ist schwieriger, denn damit dies ohne erheblich Performance-Einbußen funktioniert dürfen die Vektor-Kacheln, welche zum Client übertragen werden, nicht viel größer sein als traditionelle Raster-Kacheln. Und dies ist extrem schwierig und wird praktisch kaum jemals erreicht. Anhand einer spezifischen Rendering-Aufgabe, der Darstellung von Polygonen in gleichförmiger Farbe, habe ich das vor einiger Zeit mal detaillierter diskutiert. Was Karten-Produzenten tun, um mit diesem Problem klar zu kommen, ist der Einsatz massiver verlustbehafteter Vektor-Daten-Kompression. Im Vergleich zu verlustbehafteter Kompression von Raster-Bildern, wo Jahrzehnte von Forschung in die Verfahren gegangen sind, die wir heute verwenden und wo es auch eine Vielzahl spezialisierter Verfahren für spezifische Anwendungen gibt (wie zum Beispiel die Kompression von Digitalkamera-Rohdaten) sind die hier verwendeten Methoden recht primitiv. Man kann dies eigentlich in allen Karten, welche auf dem Client aus Vektor-Kacheln berechnet werden, sehen, wo das Kartenbild primär durch die Anforderungen der Daten-Reduktion und weniger durch kartographische Erfordernisse definiert wird und wo ein erheblicher Teil der dem Nutzer durch die Karte kommunizierten Informationen Kompressions-Artefakte sind.

So viel zum allgemeinen Hintergrund. Was ich hier diskutieren und kommentieren möchte ist ein Vorschlag von Richard Fairhurst, ein Projekt zur Bereitstellung von Vektor-Kacheln für die Darstellung auf Client-Seite (der zweite Ansatz oben) auf OSMF-Infrastrukturen zu starten. Es gab ein paar Blogposts und Diskussionsbeiträge dazu und ein Spontan-Treffen bei der SotM-Konferenz zu dem Thema.

Der alternative-colors-Stil – exzentrischer aber weniger purpurfarben als OSM-Carto

Ganz allgemein und wie zuvor schon erwähnt unterstütze ich die Initiative zur Vergrößerung der Vielfalt von durch die OSM-Gemeinschaft produzierten Karten. Aber dadurch, dass das Thema ein solcher weißer Elefant ist gibt es auch eine Menge blinden Enthusiasmus drumherum, der leicht dazu führen kann, dass man wichtige Dinge dabei vergisst. Ich möchte hier ein paar davon erwähnen – einige davon habe ich schon bei dem Treffen auf der SotM vorgebracht, andere sind neu.

1) Es ist im Moment vollkommen unmöglich, alle Funktionen des OSM-Standardstils für die OSM-Comunity mit einem Framework auf Grundlage von auf dem Client berechneten Vektor-Kacheln zu erfüllen. Dies mag vielleicht nicht sonderlich relevant erscheinen, da OSM-Carto ja im Moment ungünstigerweise auch viele der Anforderungen an die Karte oft ignoriert (siehe hier) – der fundamentale Unterschied ist jedoch, dass dies bei OSM-Carto jeweils nur eine schlechte Entscheidung ist, die man recht einfach ändern kann, mit auf dem Client dargestellten Vektor-Kacheln jedoch ist dies deutlich schwieriger.

Die meisten bei dem Treffen auf der SotM Anwesenden waren sich dieser Einschränkung durchaus bewusst, aber ich fürchte, dass das Bedürfnis, diesen Ansatz durchzudrücken, sehr stark ist und die Akzeptanz diese Tatsache im Wesentlichen dazu dient, potentielle Opposition zu beruhigen während manche im Grunde doch überzeugt davon sind, dass der weiße Elefant eine Lösung für alle Probleme ist. Deshalb hier noch mal ganz deutlich: Auf dem Client dargestellte Vektor-Kacheln sind derzeit fundamental ungeeignet, Karten zu produzieren, die die verschiedenen Kern-Funktionen des OSM-Standardstils alle erfüllen und es sind keine technologischen Innovationen am Horizont zu erkennen, die versprechen, dass sich dies ändert.

2) Es wäre meiner Meinung nach wichtig mal grundsätzlich zu diskutieren, ob die OSMF in diesem Bereich wirklich aktiv werden soll. Wenn man sich die OSMF-Ziele anschaut sieht man, dass die Bereitstellung von Karten für alle möglichen Zwecke nicht Teil der Ziele ist. Die Tatsache, dass der derzeitige OSM-Standardstil eine Reihe wichtiger Funktionen für die OSM-Community und das öffentliche Bild von OpenStreetMap erfüllt, ist allgemein akzeptiert (auch wenn man sich natürlich darüber unterhalten kann, wie gut der Stil diese Funktionen tatsächlich erfüllt). Ich denke also dass ein neues, zusätzliches Projekt zur Karten-Produktion, um eine umfangreiche Unterstützung durch die OSMF in Form von Computer-Infrastruktur zu rechtfertigen, darlegen müsste, was für wichtige Funktionen es erfüllen möchte und demonstrieren, dass es dazu auch im Sinne der OSMF-Mission in der Lage ist.

Mir scheint es nicht ganz unwahrscheinlich, dass solch ein Projekt von der Perspektive des Nutzers nicht viel mehr wäre als eine Kopie des OpenMapTiles-Projektes oder etwas ähnliches und in diesem Fall wäre es denke ich fair zu fragen, was es rechtfertigt, dass die OSMF Ressourcen in ein solches Projekt investiert.

3) Paul Norman hat in der Diskussion einen anderen wichtigen Punkt angeschnitten: Die Zahl der Entwickler in der OSM-Community mit der Fähigkeit und dem Interesse, produktiv an einem solchen Karten-Entwicklungs- und Karten-Gestaltungs-Projekt mitzuwirken, ist recht begrenzt. Das bedeutet, dass die Leute darüber letztendlich quasi mit den Füßen abstimmen werden. Das ist ähnlich wie das was ich letztes Jahr über OSM-Carto geschieben habe: Die Frage, die vermutlich über den Erfolg eines solchen Community-Projektes entscheidet (egal ob dieses OSMF-Infrastruktur nutzt oder nicht) ist ob es in der Lage ist, genügend kompetente und engagierte Entwickler anzuziehen, um tatsächlich seine Ziele zu erreichen.

Nicht dass dies sonderlich von Bedeutung ist (da ich eh nicht sonderlich qualifiziert wäre, beim Start eines solchen Projektes mitzuwirken) aber ich habe im Moment nur ein recht geringes Interesse in dieser Richtung, denn meine derzeitigen Interessen im Bereich durch die Community produzierter Karten liegt eher in den Bereichen, wo der Ansatz die Karten auf dem Client zu berechnen ungeeignet ist. Das ist jedoch keine unveränderliche Entscheidung, es ist durchaus möglich, dass andere Aspekte solch ein Projekt für mich interessant machen.

So weit zu den konkreten Plänen für einen zusätzlichen Typ von Karten auf osm.org welche ich wie gesagt als Beitrag zur Vergrößerung der Vielfalt an Community-produzierten Karten sehr begrüßen würde. Ich möchte jedoch auch noch etwas grundsätzlicheres zum Thema der Zukunft von OSM-Community-produzierten Karten generell sagen:

Der Beitrag von Richard beginnt mit einer zutreffenden Analyse davon, was OpenStreetMap von den großen kommerziellen Wettbewerbern unterscheidet. Der Visualisierungs- und Karten-Darstellungs-Teil von OpenStreetMap, also der Standardstil, hat historisch einen großen Anteil daran, dass sich OSM so entwickelt hat. OpenStreetMap hätte sich vermutlich deutlich anders entwickelt, wenn seine wichtigste Plattform zu Darstellung der Daten versucht hätte, Google Maps nachzuahmen. Stattdessen hat der Standardstil wie ich früher schon dargestellt habe, oft die Grenzen von dem was technisch und kartographisch machbar war erweitert und zwar in eine deutlich andere Richtung als wohin sich Google und andere bewegen. Und mir scheint, dass dies einen erheblichen Anteil daran hatte, dass sich OSM auf seine Kern-Werte konzentrieren konnte und nicht den kurzfristigen Trends gefolgt ist, die jeweils den größten kurzfristigen Erfolg versprochen haben. Dass dies in jüngerer Zeit in OSM-Carto deutlich weniger geworden ist, ist etwas was viele intensiv in OSM involvierte Leute spüren und dies hat vermutlich einen erheblichen Anteil daran, dass einige jetzt auf den weißen Elefanten setzen.

Aber zu versuchen, das Problem zu lösen indem man quasi unter die Flügel von Mapbox oder von anderen Konzernen schlüpft und das öffentliche Bild von OSM vollständig auf Technologie stützt, welche von kommerziellen Spielern entwickelt und kontrolliert wird, wäre meiner Meinung nach ein großer Fehler. Open Source oder nicht – die Erfahrung mit Mapnik und Carto hat recht gut demonstriert, dass OSM im Moment die Ressourcen und die Expertise fehlen, die Entwickung eines Karten-Rendering-Frameworks für die Bedürfnisse des Projektes unabhängig von entweder den großen kommerziellen OSM-Nutzern oder von der breiteren FOSS-Community voranzutreiben. OSM wird entweder in die Verbesserung dieser Fähigkeiten investieren müssen (was nicht wirklich realistisch ist, denn das Projekt hat nicht den Organisationsgrad und die Ressourcen dafür) oder man wird mit der FOSS-Community zusammenarbeiten müssen um die unabhängige Entwicklung von Werkzeugen zur Kartendarstellung im Sinne der aktuellen und zukünftigen Erfordernisse von OSM in technologischer und kartographischer Hinsicht voranzutreiben. Projekte in diesem Bereich gibt es schon eine ganze Menge (wie zum Beispiel Mapserver) aber sie werden derzeit vor allem für die Bedürfnisse kleinerer kommerzieller Nutzer und öffentlicher Einrichtungen entwickelt. Solche Projekte dazu zu bringen, Karten der OSM-Community als bedeutendes Anwendungsgebiet einzuschließen oder neue Projekte für die Bedürfnisse von OSM zusammen mit der FOSS-Community zu initiieren, wäre ein praktikabler Ansatz, um die Unabhängigkeit von OSM in Bezug auf die zukünftige Karten-Entwicklung sicherzustellen.

Und ja, Vektor-Kacheln (im generischen oben beschriebenen Sinn, weniger im Sinne eines spezifischen Dateiformates, welches von Mapbox kontrolliert wird) könnten recht wahrscheinlich Bestandteil solcher Entwicklungen sein. Sie sind jedoch nicht der weiße Elefant, auf den viele hoffen.

SotM 2018 Milano

3. August 2018
von chris
2 Kommentare

SotM Mailand – eine Zusammenfassung

Ich bin zurück aus Mailand (aus dem warmen Norditalien in ein ähnlich warmes Süddeutschland) und bin weitgehend fertig damit, die Videos der Vorträge, die ich auf der Konferenz verpasst habe, durchzusehen. Auf dieser Grundlage hier eine kurze Zusammenfassung. Ich werde vielleicht zu einzelnen Themen später noch konkreter etwas schreiben.

Zunächst etwas Statistik zu den Besuchern auf Basis der Besucherliste – was nicht ganz zuverlässig ist, denn diese spiegelt nicht exakt wieder, wer tatsächlich auf der Konferenz war und der Company Name ist lediglich ein Freiform-Feld. Eine Anmerkung für die SotM-WG: Veröffentlicht die Besucherliste doch bitte nicht in Form eines entsetzlich unstrukturierten PDFs. Das hindert Google nicht daran, die Daten abzugreifen und es macht die Analyse hier deutlich schwieriger. Ich würde es auch für eine gute Idee halten, in der Zukunft bei der Registrierung ein paar zusätzliche Informationen zu statistischen Zwecken abzufragen, denn das würde recht nützliche Einblicke in die Besucher-Struktur der Konferenz erlauben.

Es gab laut Liste 355 vorher angemeldete Besucher wovon 209 einen Unternehmens-Nahmen angegeben hatten (nach Entfernen einiger offensichtlicher Fehl-Interpretationen des Feldes). Das sind etwa 60 Prozent. Wie gesagt ist dies nicht wirklich zuverlässig aber deutet dennoch ziemlich klar darauf hin, dass die Mehrheit der Teilnehmer die SotM entweder beruflich besuchen oder dass ihr Besuch von einer Organisation bezahlt wird.

Die Unternehmen und Organisationen mit der größten Zahl an Besuchern waren:

Telenav: 8
Facebook: 7
Mapbox: 7
Microsoft: 5
Grab: 5
Heidelberg Institute for Geoinformation Technology: 5
HOT: 5
Politecnico di Milano: 4
MapAction: 4

Die geographische Verteilung der Besucher entsprechend ihrer Herkunft sieht folgendermaßen aus:

Natürlicherweise gab es aus Ländern mit kurzer Anreise die größten Zahlen an privaten Besuchern. Von den 66 Besuchern aus Italien hatten nur 30 einen Unternehmens-Namen angegeben. Von den 58 aus Deutschland waren es 25. Aus den Vereinigten Staaten auf der anderen Seite waren es 35 von 47. Wie gesagt ist die Genauigkeit dieser Zahlen begrenzt, es ist jedoch recht plausibel, dass bei einer weiten und teuren Anreise zur Konferenz die Wahrscheinlichkeit, dass jemand, der OSM als Hobby betreibt, dies auf sich nimmt, deutlich sinkt. Dies scheint mir auch durch die Gespräche, die ich geführt habe, bestätigt, denn bei Gesprächen mit Leuten von außerhalb Europas gab es in den meisten Fällen entweder einen geschäftlichen Bezug oder eine Beteiligung an einem Projekt, die über ein Hobby hinaus geht.

Die Stipendien

Es gäbe vermutlich eine Menge zu dem Stipendien-Programm der OSMF zu sagen, bis jetzt ist jedoch die einzige Information dazu, die ich habe, das was im Programm-Heft gedruckt ist, und das ist die Liste der Namen der 17 Stipendiaten.

Das Programm

Wie ich schon im Beitrag vor der Konferenz geschrieben habe, war das Vortrags-Programm für mich nicht von besonderem Interesse. Es gab keinen Vortrag, den ich unbedingt sehen wollte und nachdem ich jetzt den größten Teil der Vorträge, die ich verpasst hatte, auf Video gesehen habe scheint mir dieser Eindruck bestätigt. Dies bedeutet in keiner Weise, dass die Vorträge schlecht waren oder komplett uninteressant für mich – keineswegs. Aber ich habe mich nicht darauf konzentriert, so viele Vorträge wie möglich zusehen, sondern stattdessen mehr Zeit darin investiert, mit Leuten zu reden. Das ist ein bisschen ein Dilemma, denn natürlich ist ein Vortrag auch ein guter Ansatzpunkt, mit jemandem ins Gespräch zu kommen.

Da nicht alle Vorträge in allen Räumen aufgezeichnet worden sind hab ich natürlich auch eine Reihe von Vorträgen verpasst ohne die Gelegenheit, sie später noch anzuschauen. Ich hoffe allerdings, dass es zumindest eine mehr oder weniger vollständige Sammlung der Präsentationen gibt. Wer einen Vortrag gehalten hat und die Präsentation noch nicht an die Organisatoren geschickt hat, sollte dies tun.

Leute treffen

Wie bereits angedeutet war mein Ziel bei der Konferenz hauptsächlich, Leute zu treffen und mit ihnen zu reden. Es gab dazu gute Gelegenheiten obwohl es bei mehr als 350 Leuten natürlich auch viele Fälle gab, wo man sich über alle drei Tage nicht getroffen hat, weil man sich schlicht und einfach nie über den Weg gelaufen ist. Etwas, was bemerkenswert gut funktioniert hat ist, wenn eine dritte Person, die beide kennt, Leute einander vorstellt. Christine Karch insbesondere war hierbei sehr eifrig. Ich kann diesen Ansatz sehr empfehlen – wer interessiert daran ist jemanden anderes zu treffen, jedoch entweder Bedenken hat, diese Person einfach anzusprechen oder sie einfach nicht findet, weil man nicht weiß, wie sie aussieht, kann man einfach jemand anderes Fragen, der beide Personen kennt und die Vorstellung übernimmt. Dies kann auch dabei helfen, Sprach-Barrieren zu überbrücken, indem der oder die Vorstellende ein bisschen übersetzt.

Ich habe mich insbesondere über die Treffen und Gespräche mit Dorothea Kazazi, Martin Koppenhoefer, Nicolas Chavent und Rafael Avila Coya gefreut – welche ich alle vorher noch nicht persönlich kennengelernt hatte – ebenso habe ich aber natürlich auch viele andere getroffen, die ich schon kannte.

Die Abendveranstaltung

Der Ort der Abendveranstaltung war recht schön und das Essen war gut, dennoch war diese für eine OSM-Konferenz aus mehreren Gründen nicht ganz optimal:

  • Die Zugangs-Voraussetzungen des Lokals (konkret die Anforderung, dass die Besucher Schuhe tragen und dass man keine größeren Taschen mit hinein nehmen durfte, sondern sie am Eingang abgeben musste) wären etwas gewesen, was die Organisatoren vorher hätten ankündigen sollen. Ein Besucher aus Deutschland, der routinemäßig barfuß unterwegs war und an dem Abend keine Schuhe dabei hatte, wurde abgewiesen und viele hatten Bedenken, ihre Taschen mit wertvollem Inhalt wie Laptops und Kameras am Eingang abzugeben.
  • Für die meisten Teilnehmer ist die Abendveranstaltung primär eine Gelegenheit, mit anderen Besuchern der Konferenz zu reden. Die Musik wurde jedoch mit der Zeit immer lauter so dass es später am Abend recht schwierig wurde, sich noch zu unterhalten.

Die Auszeichnungen

Da ich etwas unerwartet eine Auszeichnungen für einflussreiches Schreiben erhalten habe (sorry Anonymaps) scheint es mir etwas undankbar, diesen Teil zu kritisieren – ich mach das jedoch trotzdem hier. Neben dem alten und schwer lösbaren Problem der Bevorzugung englischsprachiger Aktivitäten, welches ich bereits früher schon erwähnt habe sehe ich auch ein nachhaltiges Problem mit der Kategorie Innovation, wo dieses Jahr meiner Ansicht nach Niemand von den nominierten die Kriterien für das erfüllt hat, was ich Innovation nennen würde. Dies war in den vergangenen Jahren ähnlich. Ich würde vermutlich diese Preis-Kategorie schlicht und einfach streichen. Die Auszeichnungen in ihrer jetzigen Form sind im Grunde ein Popularitäts-Wettbewerb und Popularität und Innovation sind einfach Dinge, die normalerweise nicht unbedingt Hand in Hand gehen. Innovationen werden meist, wenn überhaupt, erst lange nachdem sie ursprünglich entwickelt wurden, populär und die Auszeichnungen auf der SotM beziehen sich immer auf das vergangene Jahr.

Ich würde daneben folgende weiteren Änderungen vorschlagen:

  • Die Nominierung auf Einzelpersonen und kleine Gruppen zu beschränken, deren Mitglieder individuell identifizierbar sind.
  • Eine ‘none of the above’-Option bei der Abstimmung einführen und den jeweiligen Preis nicht vergeben, wenn diese Option die meistern Stimmen erhält.

In jedem Fall gratuliere ich allen anderen Gewinnern welche ich abgesehen von der meiner Meinung nach falschen Kategorisierung bei den Innovationen alle für verdiente Empfänger der Auszeichnungen halte – was allerdings nicht bedeutet, dass die übrigen Nominierten in jedem Fall weniger qualifiziert waren. Wir haben uns zum Beispiel alle köstlich amüsiert darüber, dass Simon Poole mit einer Stimme Abstand gegenüber Richard Fairhurst unterlegen war, nachdem er im Vorfeld eine Wahlempfehlung für Richard abgegeben hatte.

Das nächste Jahr

In meinem Kommentar vor der Konferenz habe ich geschrieben, dass es unwahrscheinlich ist, dass die SotM in der näheren Zukunft wieder so nahe bei mir stattfindet wie dieses Jahr – so wie es scheint lag ich damit falsch. Heidelberg ist für mich natürlich recht bequem, es deutet jedoch auch stark einen Trend an, dass die SotM sich wieder mehr auf Europa konzentriert – mit dann drei der vier letzten Konferenz-Orte in Europa. Dies steht im Kontrast mit den vier Jahren davor, wo drei von vier Orten außerhalb von Europa lagen – gewissermaßen als Kompensation für die ersten vier Jahre, wo alle Konferenzen in Europa stattfanden.

Ein paar allgemeine Gedanken zur Konferenz

Für mich persönlich war der SotM-Besuch eine angenehme Erfahrung. Ich habe jedoch kein gutes Gefühl mit dem Anspruch der SotM, eine Konferenz für die gesamte OSM-Community zu sein. Dies entspricht nämlich meinem Eindruck nach klar nicht der Realität. Bedenkt man die Größe und Vielfalt der OSM-Community ist dieser Anspruch natürlich auch recht unrealistisch, zu versuchen, diese Illusion aufrecht zu erhalten steht jedoch meiner Ansicht nach einer produktiven Weiterentwicklung der OSM-Konferenzen in eine Richtung, die nachhaltig und produktiv das Projekt unterstützt, im Wege.

Praktisch besteht die SotM im Grunde aus drei Gruppen von Leuten:

  • Die professionellen Besucher, welche die Konferenz als Teil ihrer beruflichen Tätigkeit besuchen.
  • Der internationale OSM Jetset, bestehend aus recht wohlhabenden Aktiven, für welche OSM ein Hobby ist und die in der Lage und gewillt sind, die Kosten für einen Konferenz-Besuch aus eigener Tasche zu bezahlen.
  • Die Mitglieder der lokalen Communities in der Nähe des Konferenz-Ortes.

Alle anderen, insbesondere lokale Mapper und übrige Aktive von anderswo, sind realistischerweise nicht auf der Konferenz vertreten – auch wenn Stipendien eventuell ein paar Einzelne ergänzen. Niemand sollte den Fehler machen anzunehmen, dass die Besucher der SotM oder der nicht berufliche Teil von ihnen auch nur ansatzweise die globale OSM-Community repräsentieren.

Das Hauptproblem bei der Planung der SotM-Konferenz scheint es zu sein, die Interessen dieser drei Gruppen auszubalancieren. Schon vor meinem Besuch dieses Jahr war mein Eindruck, dass das Gewicht der dritten Gruppe verstärkt werden sollte und dass es optimal wäre, den Veranstaltungsort vielfältig und weltweit zu variieren – eventuell sogar dahingehend, dass man gar keine separate internationale Konferenz veranstaltet, sondern sich jedes Jahr an eine regionale Konferenz anhängt und diese mit besonderer Unterstützung bedenkt. Aber da von den drei genannten Gruppen die dritte auch recht klar die mit dem geringsten Einfluss ist, habe ich nicht den Eindruck, dass eine solche Entwicklung recht wahrscheinlich ist.

26. Juli 2018
von chris
Keine Kommentare

Mailand und SotM

Ich werd morgen nach Mailand zur SotM-2018-Konferenz fahren.

Die SotM hatte vom Programm her in den letzten Jahren für mich nie einen besonderen Reiz, aber sie wird vermutlich nicht so bald wieder so nahe wie dieses Jahr stattfinden (die Fahrt mit dem Zug nach Mailand dauert etwa so lange wie nach Hamburg – und man muss nicht umsteigen) so dass es eine gute Gelegenheit ist, mal einen Eindruck aus erster Hand zu bekommen. Und ich freue mich auf die Gelegenheit, verschiedene Leute zu treffen und über OpenStreetMap, Kartographie, Geodaten usw. zu reden.

Alternative-colors style at z13

24. Juli 2018
von chris
Keine Kommentare

Weitere neue Farben

Ich hab im alternative-colors-Kartenstil jetzt einige weitere größere Farb-Änderungen implementiert, welche ich hier kurz vorstellen möchte.

Ackerflächen-Farbe

Die erste Änderung betrifft die Farbe der Ackerflächen (farmland). Diese wurden in OSM-Carto lange Zeit in einem recht dunklen Braunton dargestellt. Das sah in Kombination mit den hellen urbanen Landbedeckungen dann recht merkwürdig aus. Da Ackerland in intensiv landwirtschaftlich genutzten Gebieten meist recht große Flächen bedeckt, macht eine hellere Farbe hier sehr viel Sinn. Deshalb ist die Farbe vor einigen Jahren in einen deutlich helleren Farbton geändert worden.

Dies stellte eine deutliche Verbesserung darstellte. Es blieb jedoch bei der Merkwürdigkeit, dass eine braune Farbe für die Kennzeichnung bewachsener Flächen dient.

Das Problem bei der ganzen Sache ist, dass im Bereich heller Farbtöne nur recht wenig Raum für verschiedene unterscheidbare Farben existiert. Deshalb muss die Farbe auch recht kräftig sein, um sie von anderen hellen Farben zu unterscheiden und dies hat bei der Farmland-Farbe vielen nicht gefallen.

Die Lösung, für die ich mich jetzt entschieden habe, ist im Grunde ein Farb-Tausch (mit kleineren Anpassungen) zwischen der Farmland-Farbe und der Farbe für Bildungs-Stätten und Krankenhäuser (societal_amenities). Dies ist recht sinnvoll aufgrund der Ähnlichkeits-Regel (dass Elemente, welche einander in Bedeutung und Zweck ähneln, in ähnlichen Farben dargestellt werden während Elemente, die sich in Bedeutung und Zweck stark unterscheiden, eher unterschiedliche Farben bekommen sollten). Der Farbtausch stellt hier im Grunde eine Entflechtung der Flächenfarben dar.

Farmland-Farben in verschiedenen OSM-Kartenstilen

die neue Farmland-Farbe – ein Klick zeigt ein größeres Gebiet

Ich habe die Idee für diese Farb-Änderung schon eine ganze Weile im Kopf, war aber Anfangs nicht so vom Ergebnis überzeugt. Mit kleineren Anpassungen und etwas Gewöhnung scheint sie mir jedoch jetzt ganz gut zu funktionieren.

Straßen-Farben

Bei der Änderung bei den Straßen-Farben handelt es sich im Grunde eine Verschiebung der Straßen-Klassen um eine Stufe nach unten und die Extrapolation einer neuen Farbe für die Autobahnen am oberen Ende in Erweiterung des bestehenden Farbschemas.

Auch hierzu ein bisschen Hintergrund: Als 2015 das derzeitige Farbschema in OSM-Carto entwickelt wurde, gab es im Grunde zwei wesentliche Einschränkungen bei den Farben:

  • Die verwendbaren Farben waren auf die Reihe Rot-Orange-Gelb-Weiß beschränkt, welche bereits zuvor für die Straßen verwendet worden waren (mit zusätzlich Grün und Blau, die wir jedoch nicht mehr verwenden wollten). Diese Reihe über Rot hinaus zu erweitern war nicht möglich, denn das hätte zu Verwechselungen mit den Purpurfarbenen Grenzen bei den niedrigen Zoomstufen geführt.
  • Die Unterschiede zwischen den einzelnen Farben mussten groß genug sein, dass man die Farben noch zuverlässig voneinander unterscheiden kann.

Diese Rahmenbedingungen bedeuteten, dass die Anzahl unterschiedlicher Farben auf fünf reduziert werden musste (Rot, dunkles Orange, helles Orange, Gelb und Weiß) und die ‘tertiary’-Straßen damit ihre eigenständige Farbe verloren.

Dadurch, dass im alternative-colors-Stil jetzt Purpur nicht mehr für die Grenzen verwendet wird, ist die erste Einschränkung aufgehoben, und ich kann die Farbpalette zu Purpur hin erweitern und zu sechs verschiedenen Farben zurückkehren.

Die Straßen-Farben ind OSM-Carto (oben) und hier (unten)

Hier ist gezeigt, wie das Ganze praktisch bei den verschiedenen Zoomstufen aussieht.

z14 – ein Klick zeigt ein größeres Gebiet


z13 – ein Klick zeigt ein größeres Gebiet


z12


z11


z10

Ich habe auch die Demonstration für die niedrigen Zoomstufen mit dem neuen Farbschema und aktuellen Daten neu berechnet.

Ergänzung: Auf Grundlage des Kommentars von Ilya hab ich das Skript zur Farb-Berechnung geändert so dass die Autobahn-Farbe etwas heller wird, insbesondere bei den niedrigen Zoomstufen. Man kann dies in den Beispielen im Readme sehen und in der Demonstration für die niedrigen Zoomstufen.

A Midsummer Night's Dream

9. Juli 2018
von chris
Keine Kommentare

Ein Sommernachtstraum

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

Vom nördlichen Ural-Gebirge:

Im Norden Islands:

Im Norden Norwegens:

Vom Werchojansker Gebirge:

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

3. Juli 2018
von chris
4 Kommentare

RadioOSM-Podcast zu OSMF-Themen

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

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

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

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