Imagico.de

blog

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.

Falkland Islands in Winter

29. Juni 2018
von chris
Keine Kommentare

Winter und Sommer 2018

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

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

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

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

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

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

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

The way of the water

14. Juni 2018
von chris
Keine Kommentare

Der Weg des Wassers

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

Wasser-Barrieren

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

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

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

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

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

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

Wasser-Barrieren bei z17

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

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

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

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

Wasserfälle an einem waterway=stream bei z16

Als Punkte erfasste Schleusen-Tore bei z15

Als Punkt erfasstes Wehr bei z17

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

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

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

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

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

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

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

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

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

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

Wasser-Quellen

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

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

Violett für Symbole mit Bezug zu Fortbewegung und Unterkunft

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

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

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

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

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

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

Darstellung von Wasser-Quellen bei z14, z15 und z16

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

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

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

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

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

Mit Gewässer-Linien verbundene Quellen bei z15


Brunnen bei z16


Isolierte Quelle bei z16


Mit waterway=stream verbundene Quelle bei z18


Springbrunnen und Brunnen bei z17


Springbrunnen und Brunnen bei z18

Zusammenfassung

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

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

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

Landsat evening view of Jan Mayen - May 2018

8. Juni 2018
von chris
Keine Kommentare

Ein weiteres Abend-Bild

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

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

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

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