Imagico.de

blog

26. Januar 2023
von chris
Keine Kommentare

Über die Initiative zur strategischen Planung der OpenStreetMap Foundation 2023

Deutscher Text auf Grundlage einer automatischen Übersetzung mittels deepl.

Es scheint eine neue Initiative von Mitgliedern des Vorstands der OpenStreetMap Foundation zu geben, um eine detailliertere strategische Planung für die Organisation zu entwickeln. Dies wurde bisher nicht breit öffentlich kommuniziert, aber es wird auch nicht explizit hinter den Kulissen entwickelt, d.h. man kann einige Einblicke in das Geschehen bekommen, wenn man die öffentliche Kommunikation beobachtet. Das sind insbesondere die öffentlichen Vorstandssitzungen, die Protokolle der öffentlichen und nicht öffentlichen Sitzungen und die Änderungen im öffentlichen OSMF-Wiki. Aufgrund der fehlenden öffentlichen Diskussion (nicht nur zu diesem, sondern auch zu früheren Themen des OSMF) kann man davon ausgehen, dass nicht viele Menschen in der OSM-Community diese Entwicklungen direkt verfolgen, aber ich möchte betonen, dass das, was ich hier diskutiere, auf öffentlichen Informationen basiert, die allen interessierten Mitgliedern der OSM-Community zur Verfügung stehen.

Die Dokumente über die neue Initiative zur strategischen Planung sind hier zu finden:

Ein Großteil des Textes scheint das Werk von Allan Mustard zu sein. Ich sehe dies positiv, da es von jemandem mit einem nicht-technischen Hintergrund entwickelt wurde, aber auch kritisch, da es von jemandem stammt, der sehr stark in der US-Kultur und deren kulturellen Werten verwurzelt ist. Außerdem stammen die Erfahrungen von Allan zum Großteil aus einer Karriere in der US-Bundesregierung, welche eine der größten streng hierarchischen Organisationen auf dem Planeten ist (nicht die größte allerdings – das ist mit ziemlicher Sicherheit die Kommunistische Partei Chinas). Dies prägt nicht nur seine analytische Sichtweise, sondern bestimmt insbesondere auch die Art von Lösungen und Ansätzen, die er in Betracht zieht, um Probleme zu lösen.

Besonders bemerkenswert ist das erste der aufgelisteten Dokumente, das mit der kritischsten Analyse der Arbeit in der OSMF beginnt, die ich seit langem aus den Reihen der OSMF gesehen habe. Es übt keine direkte Kritik am OSMF, sondern ist nach dem Motto was passiert, wenn man es versäumt,… aufgebaut. Es ist jedoch klar, dass dies den derzeitigen Zustand der OSMF charakterisiert.

Ausgehend von meinen eigenen Beobachtungen würde ich sagen, dass dies eine ziemlich zutreffende Analyse ist, wie die Übernahme einer zentralisierten, hierarchischen Arbeitskultur in der OSMF ohne stringente strategische Planung und Verwaltung zu einem höchst problematischen Durchwursteln geführt hat. Dies wird unnötigerweise mit einer abschätzigen Bemerkung über kleine Familienunternehmen verbunden. So könnte man wahrscheinlich die große Mehrheit der Unternehmen im weiteren wirtschaftlichen OSM-Ökosystem klassifizieren, von denen viele eine bedeutende Quelle freiwilliger Beiträge zur OSM-Community darstellen, was diese Aussage, wenn sie von der OSMF kommt, zu einer Art die Hand beißen, die einen füttert macht. Viele der Familienunternehmen, die ich kenne, haben eine viel solidere strategische Planung ihres Geschäfts als größere Unternehmen, die ihren Investoren vielleicht ein paar bunte Pläne auf Hochglanzpapier vorlegen, die aber oft nicht das Papier wert sind, auf dem sie gedruckt sind. Das Durchwursteln ist etwas, das ich in großen Unternehmen und Institutionen viel häufiger sehe als in kleinen Unternehmen. Aber vielleicht ist das auch ein Unterschied zwischen der amerikanischen und der europäischen Geschäftskultur. Oder es könnte einfach daran liegen, dass ich zu wenige schlecht geführte Familienunternehmen kenne (die es offensichtlich gibt). Aber ich komme hier vom Thema ab, zurück zum Thema.

Die treffende Analyse der aktuellen Probleme in der OSMF ist ein guter Ausgangspunkt und hätte dann zu einer Diskussion über die beiden Hauptoptionen zur Lösung dieses Problems führen können:

  • Veränderung der Arbeitskultur der OSMF, um weniger zentralisiert und hierarchisch zu sein, Einführung eines klaren Subsidiaritätsprinzips, mehr Offenheit gegenüber der sehr anderen Arbeitskultur in der OSM-Community, all die Dinge, die ich seit Jahren vorschlage.
  • Die vollständige Übernahme zentraler hierarchischer Managementideen.

Beides sind prinzipiell gültige Ansätze zur Lösung des Problems. Und ich möchte nicht behaupten, dass die Wahl des ersten Ansatzes die einzig vertretbare Entscheidung ist. Was meiner Meinung nach den ersten Ansatz so viel praktikabler und weniger riskant macht, ist die Natur von OpenStreetMap als ein in hohem Maße nicht-hierarchisches, offen kooperatives und do-okratisches Projekt. Die Wahl des zweiten Ansatzes bedeutet die Ablehnung der Kernelemente der Zusammenarbeit innerhalb von OpenStreetMap als Grundlage der Zusammenarbeit im OSMF. Und das schafft an sich schon erhebliche Probleme.

Eine wahrscheinliche Auswirkung des Wechsels zu einem vollständig hierarchischen Management wäre insbesondere der fortgesetzte und beschleunigte Ersatz von Hobby-Freiwilligen im OSMF durch geliehene Arbeitskräfte von Unternehmen/Institutionen. Hobby-Freiwillige sind in der Regel wenig geneigt, ihre Zeit für Arbeiten unter einer hierarchischen Leitung zur Verfügung zu stellen, insbesondere, wenn diese Leitung wirtschaftliche Ziele verfolgt.

Ich möchte insbesondere darauf hinweisen, dass wir aufgrund der Tatsache, dass OpenStreetMap als Ganzes so zutiefst nicht-hierarchisch ist, eine ganze Reihe von Projekten in der OSM-Community haben, die im Laufe der Jahre wertvolle Erfahrungen damit gesammelt haben, was in der nicht-hierarchischen menschlichen Zusammenarbeit in großem Maßstab funktioniert und was nicht. Die OSMF wäre also in einer ausgezeichneten Position und hätte einen guten Zugang zu kompetenter Beratung in dieser Hinsicht. Natürlich gibt es auch außerhalb von OpenStreetMap zahlreiche Beispiele für weniger zentralisierte Ansätze der menschlichen Zusammenarbeit. Sogar im militärischen Bereich – die meisten Strategien der Guerilla-Kriegsführung konzentrieren sich darauf, zentralisierte Hierarchien zu vermeiden und bauen auf kleinen, völlig autonomen Einheiten auf.

Wirtschaftliche Ausrichtung und Geschäftsmodell

Wenn ich mir die Schriften zur strategischen Planung ansehe, ist die auffälligste Beobachtung wahrscheinlich das Fehlen jeglicher substantieller Ideen in Bezug auf die Grundlage des strategischen Plans – Werte und Mission. Es gibt diese ziemlich ausgeklügelte Baumstruktur von Ideen und Aufgaben, die verfolgt werden sollen, aber nichts von einem Fundament darunter, das begründet, warum diese Dinge wichtig sind und andere nicht. Hierfür sehe ich zwei Hauptgründe:

Der erste ist, dass dies der wirklich schwierige Teil ist. Wie ich bereits in der Vergangenheit dargelegt habe, hat die OSMF über viele Jahre hinweg die intellektuelle Arbeit im Vergleich zur technischen Arbeit erheblich vernachlässigt und unterbewertet, und dies ist die Art von Dingen, bei denen dies zu einem ernsthaften Problem wird. Frühere Versuche der OSMF, Werte zu formulieren und zu beschließen, haben ebenfalls nicht zu sehr positiven Ergebnissen geführt.

Aber noch wichtiger ist, dass der OSMF-Vorstand derzeit wohl versucht, eine strategische Zweideutigkeit in Bezug auf den Kernkonflikt der Organisation zu bewahren. Der frühere Strategieplan (den der OSMF-Vorstand als offizielle Politik angenommen hatte) verfolgte ziemlich klar das Ziel, OpenStreetMap von einem primär sozialen Projekt der interkulturellen Zusammenarbeit neu auf das Ziel zu fokussieren, nützliche Geodaten zu sammeln (was insbesondere dadurch demonstriert wurde, dass einzelne lokale Wissensvermittler auf die gleiche Stufe gestellt wurden wie Unternehmensanbieter von Satellitenbildern und KI-Kartierungswerkzeugen). Dieser Gedanke schimmert in den diesjährigen Texten immer noch durch – aber er ist jetzt etwas zurückhaltender formuliert und bewahrt zumindest formal die Möglichkeit, sich in Bezug auf die Ziele in beide Richtungen zu bewegen.

Der Hauptgrund dafür ist wahrscheinlich die Overture-Initiative.

Um das zu erklären, muss ich ein wenig Kontext liefern. Derzeit benötigt die OSMF einen Mittelzufluss von etwa einer halben Million pro Jahr, um ihre laufenden Ausgaben (hauptsächlich für Personal) bestreiten zu können, und es wird im Text deutlich gemacht, dass die Autoren der Meinung sind, dass dieser Betrag in Zukunft deutlich und dauerhaft ansteigen muss (die Argumente für diese Notwendigkeit sind etwas dürftig – aber ich werde hier nicht ins Detail gehen).

Vor Overture hatte die OSMF zumindest prinzipiell die Perspektive, diese Art von Geld (und möglicherweise deutlich mehr) zu sichern, indem sie sich als Anbieter nützlicher Geodaten für OSM-Datennutzer und als Versicherung dafür präsentierte, dass diese Daten weiterhin produziert und gepflegt werden. Ich habe diese Perspektive bereits in früheren Beiträgen erörtert. Dies scheint jedoch genau das Marktsegment zu sein, auf das das Overture-Konsortium mit seiner Initiative jetzt abzielt.

Eine naheliegende Reaktion darauf wäre, dass sich die OSMF wieder als das positioniert, was sie viele Jahren zu sein versucht hat, nämlich der Garant hinter OpenStreetMap als primär soziales Projekt der interkulturellen Zusammenarbeit bei der Sammlung von lokalem Wissen. Basierend auf der Zuversicht, dass die Art und Weise, wie OpenStreetMap lokales Wissen durch egalitäre Zusammenarbeit einzelner lokaler Kartierer weltweit sammelt, weiterhin eine wesentliche Komponente für viele Anwendungen sein wird, die Geodaten benötigen, wichtig genug, um die Finanzierung der OSMF sicherzustellen, wäre dies meiner Meinung nach die natürliche und logische Reaktion (und das ist es, was ich mit meiner hypothetischen OSMF-Erklärung bezüglich Overture angedeutet habe).

Ich habe ein wenig den Eindruck, dass das Problem hier darin besteht, dass viele in der OSMF heutzutage nicht das Vertrauen haben, dass das, worauf die OSM traditionell basiert, nämlich die Kartierung in Eigen-Initiative durch Leute mit Ortskenntnissen, auch in Zukunft wirtschaftlich wichtig genug sein wird, um die finanziellen Bedürfnisse der OSMF zu befriedigen, einschließlich der von ihnen wahrgenommenen Notwendigkeit zu wachsen. Daher versuchen sie, sich ein Stück des Kuchens zu sichern, auf den Overture ein Auge geworfen hat, und gleichzeitig zu vermeiden, dass die globale Gemeinschaft der Mapper verärgert wird. Ich brauche wohl nicht zu erwähnen, dass dies ein ziemlich riskantes Unterfangen ist. Im Deutschen haben wir dafür einen Begriff: Der Versuch, auf zwei Hochzeiten gleichzeitig zu tanzen.

Natürlich ist auch der andere Weg nicht ohne Risiken, zumal er das Marktsegment berührt, das HOT derzeit besetzt – zumal HOT zunehmend versucht, sich als Unterstützer lokaler Mapping-Communities in Entwicklungsländern zu präsentieren. Die OSMF wäre also wirtschaftlich gesehen auf gefährliche Weise zwischen zwei viel größeren Akteuren (HOT und dem Overture-Konsortium) eingekeilt. Eine extrem passive Haltung bei der Klärung der Beziehungen zu den beiden (insbesondere zu HOT in Bezug auf die Markenrechte und zu den Overture-Partnern in Bezug auf die Einhaltung der ODbL) ist da natürlich nicht von Vorteil.

Was noch fehlt

Wie so oft bei Plänen und Dokumenten dieser Art ist es besonders interessant zu sehen, was fehlt und nicht nur, was da ist. Natürlich handelt es sich um Entwürfe, die noch erweitert werden sollen. Aber selbst im frühen Entwurfsstadium kann man schon Prioritäten erkennen.

Erstaunlich ist, wie ausführlich die Notwendigkeit der strategischen Planung als Instrument des hierarchischen Managements erläutert und begründet wird, dass es aber keinerlei Überlegungen zur Notwendigkeit der unabhängigen Kontrolle gibt. Da die Motivation und Begründung des Ganzen auf einer traditionellen westlichen Managementperspektive beruht, die ihrerseits (wie ausdrücklich erwähnt!) ihren Ursprung in militärischen Kommandostrukturen hat, könnte ich es auch militärisch ausdrücken: Es gibt keinen disziplinarischen Rahmen.

In der Unternehmensführung ist der primäre Disziplinierungsmechanismus, durch den die weiter oben in der Hierarchie stehenden Personen den weiter unten in der Hierarchie stehenden Personen sagen können, was sie zu tun haben, Geld. Und da im Strategieplan der OSMF ausdrücklich erklärt wird, dass ihr Schwerpunkt auf der Freiwilligenarbeit liegt, ist dieses Versäumnis besonders auffällig. Wenn das nicht angegangen wird, wird dies höchstwahrscheinlich zu einem weiteren Durchwursteln auf der Grundlage des derzeit vorherrschenden Paradigmas “People whose work we know and enjoy” führen – was bedeutet, dass das Hauptinstrument der Machtausübung in der Managementhierarchie gemeinsame persönliche Interessen und persönliche Abhängigkeiten zwischen dem Management und den Arbeitskräften wären. Und da dies als Kontrollmechanismus nicht sehr zuverlässig ist, könnte dies auch zu einer weiteren Verlagerung von ehrenamtlicher Arbeit zu bezahlter Arbeit führen, einfach weil letztere in einer Managementhierarchie so viel leichter zu handhaben ist.

Wenn wir uns die Details des Plans mit den Clustern ansehen, sehen wir, dass der Schwerpunkt – wie irgendwie erwartet – auf technischer Arbeit und Management liegt. Der gesamte Bereich der geistigen Arbeit ist nicht abgedeckt. Ich werde einige der konkreteren Bereiche, in denen ich im OSM-Kontext arbeite – Kartendesign und Tagging-Dokumentation – außen vor lassen, weil man durchaus argumentieren könnte, dass dies außerhalb des Zuständigkeitsbereichs der OSMF liegt. Allerdings scheint das Verständnis der Semantik der Daten, die die OSMF offensichtlich als eine ihrer wichtigsten Stärken betrachtet, eines der Dinge zu sein, in die man einige Ressourcen investieren sollte. Und angesichts der Tatsache, dass die OSMF so viele Ressourcen in die Kartenproduktion investiert, ist das völlige Fehlen des Kartendesigns im Strategieplan in gewisser Weise ebenfalls bemerkenswert. Aber was noch wichtiger ist: Was halten Sie von einer Organisation, die OpenStreetMap unterstützen will, ein Projekt, das in seinen sozialen Interaktionen zweifellos einzigartig und ungewöhnlich ist, und das Ziel, ein besseres Verständnis dafür zu erlangen, wie diese sozialen Interaktionen funktionieren, ist nirgendwo im Strategieplan zu finden?

In der Unternehmensterminologie: Das Cluster Strategische Forschung ist auffallend abwesend.

Aber um es ganz klar zu sagen: Wenn man so etwas nur formal hinzufügt, hat das keinen Nutzen. Um einen aussagekräftigen und glaubhaften Plan zu erstellen, braucht man ein gewisses Hintergrundwissen auf dem Gebiet, auch wenn das Hauptziel des Plans darin besteht, diese Kompetenz erst zu schaffen. Das ist ein Henne-und-Ei-Problem.

Damit schließt sich gewissermaßen der Kreis zu meinen einleitenden Bemerkungen. Es ist gut, dass es im OSMF eine Initiative gibt, die, soweit ich das sehe, zum ersten Mal seit vielen Jahren auf einer kritischen Betrachtung des OSMF mit zumindest ein bisschen Außenperspektive beruht. Aber diese Initiative wird nur dann substanzielle positive Ergebnisse bringen, wenn die OSMF tatsächlich Leute mit Kenntnissen in einem breiten Spektrum von Bereichen außerhalb der OSMF und außerhalb der people whose work we know and enjoy der OSMF überzeugen kann, ihr Wissen und ihre Erfahrungen beizusteuern. Und das kostet entweder viel Geld oder erfordert, dass die OSMF ein Umfeld schafft, in dem sachkundige und erfahrene Personen auch ohne wirtschaftliche Anreize bereit sind, einen Beitrag zu leisten. Dies schließt eine Managementhierarchie oder das System aus, das wir in den letzten Jahren nur allzu oft erlebt haben, bei dem Entscheidungen eher als Verhandlung von Interessen denn als Kampf der Argumente getroffen werden.

Risiken des Ansatzes

Und damit komme ich zu dem, was ich als die wichtigsten konkreten operativen Risiken bei der Verfolgung des skizzierten Verfahrens zur Entwicklung eines Strategieplans betrachte. Aufgrund der etablierten Arbeitskultur im OSMF und der Tatsache, dass es eindeutig keine solide Grundlage in Form von Werten, Mission und Kernzielen gibt, die die geplanten Aufgaben motiviert, besteht die große Wahrscheinlichkeit, dass dies kein gut strukturierter Plan zur Erreichung der Ziele der Organisation wird, sondern eine Ansammlung von Projekten, die im Interesse derjenigen liegen, die den größten Einfluss auf die Entwicklung des Plans haben.

Ein weiteres potentielles Problem – und diese Möglichkeit wird im Text bereits angedeutet – besteht darin, dass es sich nicht um einen Plan handelt, der als Ganzes verfolgt wird, in der Überzeugung, dass die sorgfältige Verfolgung all dieser Aufgaben der Schlüssel zur erfolgreichen Erfüllung der Mission der OSMF sein wird, sondern dass er zu einem Katalog von Dingen wird, die die OSMF ihren Geldgebern als Dienstleistungen anbietet, aus denen sie sich das herauspicken, was sie für geeignet halten, ihren Zielen zu dienen.

Schlussfolgerungen

Ich möchte aber klarstellen, dass keine meiner kritischen Anmerkungen hier ein Grund ist, die Idee, einen strategischen Plan zu entwickeln, aufzugeben und stattdessen mit dem Durchwursteln weiterzumachen. Selbst mit all den beschriebenen Risiken und Defiziten wäre die Entwicklung und Veröffentlichung einer solchen Planung eine wesentliche Verbesserung gegenüber dem Status quo. Es wäre natürlich gut, wenn die eingangs skizzierte Alternative der Dezentralisierung eines Großteils der Arbeit des OSMF ernsthaft diskutiert würde. Aber mir ist klar, dass dies als Initiative innerhalb der OSMF im Moment nicht sehr realistisch ist. Es wäre auch großartig, wenn ein breites Spektrum unabhängiger Experten an der Entwicklung eines solchen Plans von Grund auf beteiligt wäre, mit einer großen Bandbreite an erforderlichen Kompetenzen und ohne dass Interessen gegenüber Expertise und Argumenten dominieren. Aber mir ist klar, dass es ohne ein beträchtliches Budget schwierig ist, dafür qualifizierte Leute zu finden, die nicht in erster Linie ihre eigenen wirtschaftlichen Interessen verfolgen und die bereit sind, in einem hierarchischen Managementrahmen zu arbeiten. Und selbst wenn nichts dergleichen geschieht, hätte es doch den Vorteil, dass die Dinge, die die OSMF verfolgt, öffentlich klar genannt werden, statt des derzeitigen Durchwurstelns ohne klare, nach außen sichtbare Strategie, aber mit weitgehender Verfolgung von Partikularinteressen hinter den Kulissen.

19. Januar 2023
von chris
1 Kommentar

Namen und Beschriftungen in OpenStreetMap

Deutscher Text auf Grundlage einer automatischen Übersetzung mittels deepl.

Vor mehr als fünf Jahren habe ich hier einen Blogbeitrag über das Problem der Namenserfassung und der mehrsprachigen Namen in OpenStreetMap geschrieben. Ich möchte jetzt ein Update der Situation aus meiner Sicht geben und ein wenig darüber nachdenken, was sich seither geändert hat und was nicht. Außerdem soll dies ein wenig als Einleitung für einen folgenden Blogbeitrag dienen, den ich über Änderungen bei der Darstellung von Beschriftungen in meinem Kartenstil plane.

Was ich vor fünf Jahren erklärt habe, ist im Wesentlichen, dass die primäre Art und Weise, mit der Mapper in OpenStreetMap Namen aufzeichnen, das name-Tag, eine zentrale Rolle bei der Etablierung der Idee gespielt hat, dass OpenStreetMap das lokale Wissen seiner Mitwirkenden aufzeichnet, weil es nach allgemeinem Konsens explizit dazu gedacht ist, den lokal verwendeten Namen von geografischen Objekten aufzuzeichnen. Da jeder Mapper überall auf der Welt dies auf genau die gleiche Weise tut und diesen lokalen Namen direkt auf der Karte so sieht, wie er erfasst wurde, repräsentiert diese Praxis gut die Idee der gemeinsamen Kartierung des Planeten in all seiner Vielfalt.

Andererseits – und das habe ich auch schon vor fünf Jahren erwähnt – ist diese Praxis leider mit verschiedenen Problemen verbunden:

  • Sie beruht auf der Illusion, dass es immer nur einen einzigen lokalen Namen gibt.
  • Die Aufzeichnung des lokalen Namens ohne Informationen über die Sprache dieses Namens führt in einigen Fällen zu ernsthaften Problemen (insbesondere bei dem, was gemeinhin als the Han unification problem bekannt ist).
  • Was die Mapper als Beschriftung der Elemente in der Karte sehen wollen, ist sehr oft nicht der lokal verwendete Name.

Die damals von mir vorgeschlagene Lösung für die Beschriftung sowie

verschiedene andere Versuche, Ideen für die Beschriftung zur Lösung der ersten beiden Probleme vorzuschlagen, fanden keine breitere Unterstützung. Sowohl Mapper als auch Datennutzer schienen mit dem Status quo weitgehend zufrieden zu sein.

Die Situation heute

Kurz und bündig: Die heutige Situation ist im Wesentlichen unverändert. Die bereits 2017 sichtbaren Probleme haben sich jedoch verschärft und es ist mittlerweile recht deutlich sichtbar, dass die derzeitige Praxis nicht nachhaltig ist. Wenn ich versuche, die Verwendung des name-Tags heute zu kategorisieren, komme ich zu folgendem Ergebnis.

Die überwiegende Mehrheit der name-Tags enthält einen einzelnen Namen. In den meisten Fällen handelt es sich dabei um den lokal verwendeten Namen. Es gibt jedoch auch einen beträchtlichen Prozentsatz von Fällen, in denen ortsfremde Kartierer Namen, die sie verwenden oder mit denen sie vertraut sind, in das name-Tag eintragen, obwohl es sich offensichtlich nicht um den lokal gebräuchlichen Namen handelt (z. B. weil es sich um eine Sprache handelt, die lokal nicht weit verbreitet ist). In anderen Fällen verwenden lokale Mapper einen per Schild ausgewiesenen oder offiziellen Namen (d. h. einen Namen, der von einer Autorität, entweder einer offiziellen Stelle oder dem Eigentümer des betreffenden Merkmals, verwendet wird) und nicht den Namen, der vor Ort in der praktischen Kommunikation verwendet wird.

Alle diese Varianten der Aufnahme eines einzelnen Namens, der nicht der lokal verwendete Name ist, in das name-Tag, sind weitgehend durch die Tatsache motiviert, dass viele Datenbenutzer das name-Tag entweder nur direkt als Label-Tag interpretieren oder ihm bei der Auswahl zur Beschriftung Vorrang vor anderen Tags mit Namen geben. Dies ist ein Anreiz für die Kartierer, den Namen zu erfassen, den sie auf der Karte sehen wollen – was je nach dem einzelnen Mapper und den lokalen kulturellen Konventionen bei der Kartengestaltung unterschiedliche Dinge bedeuten kann.

Der zweit-häufigste Anwendungsfall für das name-Tag nach der Aufnahme eines einzelnen Namens ist die Aufnahme von etwas, das überhaupt kein Name ist. Diese Praxis wird teilweise durch denselben Mechanismus angetrieben, den ich bereits erörtert habe. Der andere Grund dafür ist, dass das Konzept von Namen (oder genauer: Eigennamen) eine sehr abstrakte Angelegenheit ist, mit der viele Mapper Schwierigkeiten haben. Ein beträchtlicher Prozentsatz der Verwendungen des name-Tags für Dinge, die keine Eigennamen sind, sind Fälle, in denen Mapper eine Beschriftung aus der realen Welt aufzeichnen, die keinen Eigennamen für das Feature darstellt. Oft handelt es sich dabei um eine Marke (wie bei Geschäften usw.), den Namen einer Person, die ein Feature betreibt (was normalerweise mit operator gekennzeichnet wird), Adressbestandteile oder eine Klassifizierung (man denke an einen Spielplatz, an dem ein Schild mit Nutzungsbeschränkungen angebracht ist: Spielplatz: Nutzung nur für Kinder unter 14 Jahren erlaubt – und der Mapper interpretiert den Spielplatz als den Namen des Objekts).

Mehrere Namen

Der dritt-häufigste Anwendungsfall für das name-Tag – und hier sind wir bei einem einstelligen Prozentsatz angelangt, obwohl dieser bei bestimmten Objekt-Typen und in einigen Regionen viel größer ist – ist die Aufnahme von mehreren Namen in das name-Tag. Dies ist ebenfalls weitgehend dadurch motiviert, dass die Datennutzer das name-Tag als Beschriftung anzeigen und die Mapper in einigen Fällen die Anzeige mehrerer Namen in der Karte als die wünschenswerteste Form der Beschriftung ansehen.

Es gibt zwei grundlegend verschiedene Varianten der Aufnahme mehrerer Namen in das name-Tag. Die eine (und weitaus verbreitete von beiden) ist die Aufnahme von Namen in verschiedenen Sprachen. Wenn es nicht nur eine einzige lokal verwendete Sprache gibt, sondern mehrere, hat ein Objekt in der Regel verschiedene Namen in diesen verschiedenen Sprachen und dementsprechend keinen eindeutigen lokal verwendeten Namen. Die andere (viel seltenere) Variante ist, wenn es in der einzigen lokal verwendeten Sprache mehr als einen lokal verwendeten Namen gibt und es nicht möglich ist, nachprüfbar festzustellen, welcher der lokal weiter verbreitete Name ist.

Ich möchte hinzufügen, dass es für beide Varianten auch den recht häufigen Fall gibt, dass ein einziger lokal am weitesten verbreiteter Name bestimmt werden kann, die Mapper dies aber – aus sozialen oder politischen Gründen – nicht angeben wollen und es vorziehen, mehrere Namen so zu erfassen, als ob sie lokal gleich weit verbreitet wären, auch wenn sie es nicht sind.

In letzter Zeit gab es in der OSM-Community ein erneutes Interesse am Thema der Erfassung mehrerer Namen im name-Tag, aber die meisten Diskussionen drehten sich um die eher oberflächliche und unbedeutende Frage, wie man die verschiedenen Namen in diesem Fall trennen kann. Das ist in etwa so, als ob man plant, ein paar Risse in einer Wand zu übermalen und darüber diskutiert, welche Farbe man dabei verwenden sollte.

In der Praxis sind die gebräuchlichsten Trennzeichen für mehrsprachige zusammengesetzte Namen ' / ' und ' - ' (d.h. Schrägstrich oder Bindestrich/Minus mit Leerzeichen drumherum) und – bei zusammengesetzten Namen, bei denen die Komponenten durch verschiedene Schriften unterschieden werden – ist es auch üblich, überhaupt kein Trennzeichen zu verwenden (nur ein Leerzeichen, das auch zwischen verschiedenen Wörtern der einzelnen Namen verwendet wird). Das Semikolon (;) wird in gewissem Umfang verwendet, allerdings meist in nicht mehrsprachigen Situationen, insbesondere in Fällen, in denen sich die verschiedenen Namen auf unterschiedliche Objekte der realen Welt beziehen.

Trotz all dieser Ungereimtheiten und widersprüchlichen Praktiken gibt es einen breiten Konsens über mehrsprachige Namen: Wenn Namen mehrerer Sprachen in zusammengesetzten name-Tags enthalten sind, sollte jede der Komponenten auch separat in dem jeweiligen name:<lang>-Tag erfasst werden. Diese Regel wird zwar nicht durchgängig befolgt, aber es besteht eindeutig ein breiter Konsens darüber, dass dies wünschenswert ist.

Das Dilemma bei der Kartendarstellung

Der Kern des Problems auf der sozialen Ebene (und der Grund, warum in diesem Bereich in den letzten fünf Jahren nichts Substanzielles passiert ist) liegt darin, dass die Illusion des name-Tags, das den einzigen lokal verwendeten Namen aufzeichnet, für die Datennutzer recht bequem ist, weil sie damit ihre Karte auf sehr einfache Weise beschriften können, und gleichzeitig ist die Möglichkeit, die Beschriftungen in Karten direkt zu kontrollieren, etwas, das die Mapper zu schätzen gelernt haben, und viele Mapper haben nicht das Vertrauen

  • in die Fähigkeit und Bereitschaft der Datennutzer, klarer strukturierte Informationen so zu interpretieren, dass sie zu guten Karten führen.
  • in ihre Mapper-Kollegen, damit sie die sauberer strukturierten Informationen zu den Namen gewissenhaft aufzeichnen (und die uneinheitliche Verwendung des name-Tags bestätigt diesen Verdacht direkt).

Was ich (und andere) in der Vergangenheit versucht haben, ist, Ideen zu präsentieren, wie das Problem von der Kartierungsseite her angegangen werden kann. Aber weder die Datennutzer noch die Mapper zeigten sich sehr interessiert daran, den Status quo zu ändern.

Außerdem sind die einflussreichsten Kreise in der OSM-Gemeinschaft – sowohl auf der Seite der Mapper als auch auf der Seite der Datennutzer – aus Westeuropa und Nordamerika und in erster Linie an Sprachen mit lateinischer Schrift interessiert, so dass sie nur wenig Interesse an der Lösung der Probleme haben, die der Mangel an Informationen über die Sprache(n) des name-Tags verursacht.

Das Dilemma für Kartengestalter, insbesondere in OSM-Carto, besteht darin, dass mittlerweile völlig klar ist, dass die primitive direkte Verwendung des name-Tags als Beschriftung für viele Features in OpenStreetMap einen großen Anteil an der oben skizzierten schlechten Situation hat. Mit anderen Worten: Wir als Kartendesigner sind Teil des Problems und es wäre daher in gewisser Weise klug, damit aufzuhören. Da wir aber – aus den oben und im Blogpost von 2017 genannten Gründen – weiterhin daran interessiert sind, überall auf der Welt lokale Namen in der jeweiligen Landessprache darzustellen und es keine andere etablierte Möglichkeit gibt, diese Information in OSM zu erfassen, haben wir keine andere Möglichkeit, als das name-Tag anzuzeigen. Und wir wollen (aus sehr guten Gründen, die ich kürzlich noch einmal erläutert habe) die Mapper nicht aktiv dazu bringen, ihre Kartierungspraxis in einer Weise zu ändern, die wir für wünschenswert halten.

Ein Ansatz, um diese Pattsituation zwischen Mappern und Datennutzern zu überwinden, könnte darin bestehen, ein funktionierendes Konzept zu präsentieren, das sowohl die Vorteile einer tatsächlichen Lösung des Problems aufzeigt (anstatt nur die Risse ein wenig zu übertünschen – siehe oben) als auch, wie ein reibungsloser Übergang vom Status quo zu einer solchen Lösung aussehen könnte. Und vor allem – um zu zeigen, dass ein solcher Weg es nicht erfordert, dass die Mapper die Kontrolle über die Kartierungspraxis an eine kleine Elite von technischen Gatekeepern abgeben, sondern dass er es ihnen erlaubt, weiterhin selbstbestimmte Entscheidungen zu treffen, und der die wenigen beschriebenen Punkte, wo Mapper tatsächlich einen Konsens darüber haben, wie Dinge kartiert werden sollten, respektiert und darauf aufbaut. Darum wird es im nächsten Blogbeitrag gehen.

11. Januar 2023
von chris
Keine Kommentare

Über die Lizenzierung von offenem Kartendesign

Deutscher Text auf Grundlage einer automatischen Übersetzung mittels deepl.

In den letzten Monaten habe ich an einer Reihe von Änderungen und neuen Funktionen für den Kartenstil Alternative Colors gearbeitet (mehr dazu vermutlich in zukünftigen Blogposts) und während dieser Zeit auch viel über die Situation des offenen Kartendesigns nachgedacht – im Allgemeinen und in der OpenStreetMap-Community im Besonderen. Ein Ergebnis dieser Überlegungen ist, dass ich mich entschlossen habe, die Lizenz des Stils zu ändern. Und in diesem Blogpost möchte ich erklären, warum.

Regelbasiertes Kartendesign ist ein ungewöhnliches Konzept, sowohl für diejenigen, die aus der traditionellen IT- und Softwareentwicklung kommen und die Dinge aus dieser Perspektive betrachten, als auch für Menschen mit einem traditionellen Hintergrund in Grafikdesign, visueller Kunst oder Kartografie. Ein Kartenstil wie OSM-Carto oder der AC-Style enthält Regeln, wie Geodaten in eine visuelle Darstellung – die Karte – umgewandelt werden. Diese Regeln sind in Form von Code implementiert, der automatisch von Computern verarbeitet wird. Daher neigen viele Softwareentwickler (und machmal auch traditionelle Designer) dazu, Kartenstile als Software zu betrachten und sie darauf zu reduzieren, Software zu sein. Das Hauptproblem dabei (abgesehen davon, dass der Kern der Kartengestaltung selbst damit als unbedeutend abgetan wird) ist, dass die Art und Weise, wie Kartenstile funktionieren, mit dem klassischen Paradigma der Computerprogrammierung kollidiert, dass Software Daten verarbeitet und dass die beiden Dinge technisch und rechtlich getrennt sind. In Gesprächen, die ich in der Vergangenheit über das Urheberrecht und die Lizenzierung von Kartendesign geführt habe, hat sich oft gezeigt, dass viele in der IT-Branche tätige Personen der festen Überzeugung sind, dass bei der Verarbeitung von Daten mit einem Computerprogramm das Urheberrecht an den verarbeiteten Daten vom Urheberrecht am Computerprogramm kategorisch unberührt bleibt. Dass es so etwas wie selbstreplizierende Programme gibt, die diese Vorstellung ganz klar in Frage stellen, wird in der Regel als praktisch irrelevanter Sonderfall betrachtet.

Die von einem automatisierten regelbasierten Kartenstil erzeugte Karte ist jedoch abgeleitet sowohl von den Geodaten, auf die der Stil angewendet wird, als auch vom Stil selbst. Die resultierende Karte enthält natürlich nicht mehr die generische Logik des Kartenstils, aber sie enthält die Arbeit der Kartengestalter, die den Stil entwickelt haben – zum Beispiel in Form von sorgfältig abgestimmten Farbkombinationen oder Liniensignaturen – oder einfach in der Auswahl dessen, was in einem bestimmten Kartenmaßstab gezeigt werden soll und was nicht. Und diese Entscheidungen sind in der resultierenden Karte tatsächlich manifestiert. Die gerenderte Karte basiert also nicht nur auf dem Kartenstil und der Arbeit ihres Entwicklers in dem Sinne, wie ein Computerprogramm Daten gemäß den Absichten seines Programmierers generiert, sondern sie enthält direkt und buchstäblich die Designarbeit selbst. Oder mit anderen Worten: Man könnte sie als eine Collage aus der Arbeit des Mappers, der die Geodaten generiert, und der Arbeit des Kartendesigners, der die Stilregeln schreibt, bezeichnen.

In Anbetracht dessen ist es recht merkwürdig, dass die meisten offen lizenzierten Kartenstile entweder auf alle Rechte ihrer Designer verzichten (wie bei CC0) oder unter einer Softwarelizenz lizenziert sind (normalerweise eine recht liberale wie BSD oder MIT). Dies ist besonders bemerkenswert im Kontext von OpenStreetMap, wo die Arbeit der Mapper den wesentlich umfangreicheren Bedingungen der ODbL unterliegt.

Oberflächlich betrachtet macht es dies einfacher, mit der besonderen Natur von Kartenstilen als urheberrechtlich geschützte Werke umzugehen. Aber ich bezweifle inzwischen, dass dies auf lange Sicht tatsächlich einen Nettonutzen bringt. Ich habe in diesem Blog nun schon mehrfach darauf hingewiesen, dass ich denke, dass in der OSM-Community (und wohl auch in der Geodatenverarbeitung und digitalen Kartenproduktion im Allgemeinen) geistige Arbeit, und damit ist natürlich insbesondere Kartendesignarbeit gemeint, im Vergleich zu technischer Arbeit stark unterbewertet ist und dass dies die Innovation in diesem Bereich erheblich einschränkt. Die Tatsache, dass die meisten offenen Kartengestaltungsprojekte in diesem Zusammenhang in einer Weise lizenziert sind, die es den Nutzern der Kartenstile erlaubt, so zu tun, als ob es sich nur um Software handelt, scheint in dieser Hinsicht ganz klar nicht hilfreich zu sein.

Eine konkrete Beobachtung, die dies überdeutlich machte, war, dass, als ich den Vorstand der OpenStreetMap Foundation Mitte 2022 darauf hinwies, dass es schön und moralisch ratsam wäre, wenn die OSMF als größter Nutzer von OSM-Carto die Arbeit der OSM-Carto-Designer in ihrer öffentlichen Kommunikation, insbesondere auf der Website, auf der die Karte gezeigt wird, anerkennen würde. Nichts geschah. Und warum sollte es auch, könnte man sagen. Wenn die OSM-Carto-Entwickler diese Art von Anerkennung wirklich wollten, könnten sie dies in ihrer Lizenz verlangen. Und da dies rechtlich nicht vorgeschrieben ist, warum sollte die OSMF diese dann bieten?

Eine wichtige Voraussetzung, um die Art und Weise, wie die OSM-Gemeinschaft die Arbeit von Kartendesignern betrachtet, zu ändern, ist es, den Kartendesignern praktisch unkomplizierte Optionen zur Verfügung zu stellen, wie sie ihre Arbeit auf eine Weise lizenzieren können, die

  • sicherstellt, dass der Stil und andere daraus abgeleitete Kartengestaltungsarbeiten offen bleiben und unter ähnlichen Bedingungen verwendet werden können.
  • die besondere Natur des regelbasierten Kartendesigns als etwas, das sowohl Softwarekomponenten als auch visuelle Designarbeit enthält, die in die produzierten Karten einfließt, angemessen anerkennt und behandelt.
  • von den Nutzern der Designarbeit verlangt, dass sie die Arbeit der Kartendesigner, die den Stil entwickelt haben, anerkennen und würdigen.

Dies ist nicht einfach, da es bisher keine speziell für Kartenstile entwickelten Lizenzen zu geben scheint. Was jedoch hilft, ist ein Blick auf andere Bereiche, in denen die Situation ähnlich ist. Wirtschaftlich bedeutsam ist hier insbesondere der Bereich der Computerspiele, wo – ähnlich wie beim Kartendesign – eine Kombination aus visueller Gestaltungsarbeit und Softwareentwicklung vorliegt, die dem Nutzer in Form einer Collage präsentiert wird. Lizenzmodelle, die in diesem Zusammenhang verwendet werden, könnten daher auch für die Lizenzierung von Karten geeignet sein.

Für den AC-Style habe ich mich entschieden, die visuellen Designkomponenten unter CC-BY-SA 4.0 und die Softwareelemente unter AGPL 3.0 zu lizenzieren. Sowohl CC-BY-SA als auch AGPL sind in der Vergangenheit im Zusammenhang mit Kartendesign verwendet worden – CC-BY-SA vor allem im OpenTopoMap-Projekt, die AGPL zum Beispiel für die Arbeiten zur Transliteration von Sven Geggus. In der Praxis bedeuten diese Lizenzen, dass sowohl die Software als auch die Designkomponenten gemeinsam genutzt werden können und dass die Entwickler des Stils oder der Derivate alle Änderungen der Stilregeln unter kompatiblen Bedingungen freigeben müssen (was bei der GPL nicht der Fall wäre). Ob dies in der Praxis eine gute Wahl der Lizenzen ist, bleibt abzuwarten – wie der Stil selbst kann die Lizenz als experimentell angesehen werden.

Die beiden unterschiedlichen Lizenzen für Softwarekomponenten und visuelles Design bedeuten nicht, dass man pauschal annehmen kann, dass alle in einer Programmiersprache geschriebenen Komponenten nur der AGPL unterliegen. Wie ich oben versucht habe zu zeigen, ist dies nicht nur eine technische Unterscheidung. Es gibt viele Fälle im Stil, in denen visuelles Design in Form von Code implementiert ist – siehe zum Beispiel die Symbolentwürfe für Bäume, die in Form von SQL-Code implementiert sind.

Dass ich den AC-Style unter diesem Lizenzschema lizenziere, bedeutet nicht, dass die Funktionen und Ideen, die ich in dem Stil entwickle, nicht mehr in OSM-Carto übernommen werden können. Bislang bin ich der alleinige Autor der spezifischen Features dieses Stils und es steht mir frei, Teile dieser Arbeit auch unter einer anderen Lizenz zu lizenzieren, wenn ich das möchte. Andererseits könnte es natürlich eine gute Idee sein, darüber zu diskutieren, ob man auch die Lizenz von OSM-Carto ändern sollte. Wie ich oben dargelegt habe, ist es inzwischen ziemlich zweifelhaft, ob die Wahl einer sehr liberalen Lizenz für ein offenes Gemeinschaftsprojekt wie OSM-Carto dem Fortschritt und der Innovation auf diesem Gebiet zuträglich ist und kompetente Designer zur Mitarbeit an dem Projekt animiert.

Ich bin mir jedoch auch bewusst, dass der Wechsel zu einer Lizenz, die den Nutzer des Stils stärker einschränkt, nicht unbedingt zu einer Erweiterung der Nutzerbasis des Stils führen wird. Die gesamte Initiative zur Änderung der Lizenz ist Teil einer langfristigen Initiative, um das Bewusstsein dafür zu schärfen, dass regelbasiertes Kartendesign nicht nur eine etwas spezielle Art der Softwareentwicklung ist, sondern ein eigenständiger Bereich von Wert und Bedeutung, der davon abhängt, dass qualifizierte und talentierte Designer motiviert sind, ihre Zeit und Energie in ihn zu investieren.

Ich möchte auch klarstellen, dass diese Lizenzänderung nicht dazu gedacht ist, die Arbeit der OSM-Carto-Entwickler zu schmälern, auf deren Arbeit der AC-Style basiert. Daher möchte ich ausdrücklich, dass bei der von der neuen Lizenz geforderte Namensnennung auch deren Beiträge anerkannt werden.

Das wichtigste Ergebnis, das ich mir erhoffe, ist, dass diese Initiative andere Kartendesigner dazu ermutigt, (a) die Idee des offenen Kartendesigns anzunehmen und (b) bewusster und selbstbestimmter über die Bedingungen zu entscheiden, unter denen sie ihre Arbeit anderen zur Verfügung stellen. Im Moment ist es leider so, dass zu viele Kartengestalter – wenn sie an regelbasiertem Kartendesign arbeiten – ihre Arbeit nicht unter von ihnen gewählten Bedingungen veröffentlichen, sondern unter solchen, die andere (die oft keine Kartengestalter sind) gewählt haben. Oder sie halten ihre Arbeit proprietär, weil sie keinen guten Weg finden, sie verfügbar zu machen und weiterzugeben und sie nicht gleichzeitig für die egoistische Ausbeutung durch andere zur Verfügung zu stellen, ohne dass diese etwas zurückzugeben.

Imagico.de StyleInfo

20. Dezember 2022
von chris
Keine Kommentare

Vorstellung von StyleInfo

Deutscher Text auf Grundlage einer maschinellen Übersetzung mit deepl.

Im letzten Blogbeitrag habe ich die Idee des systematischen Testens im Kartendesign ein wenig vorgestellt und wie meine Arbeit daran – sozusagen als Nebenprodukt – zu den Rendering-Illustrationen geführt hat, die man auf TagDoc findet.

Aber es gibt noch ein weiteres Problem, mit dem die meisten automatisierten, regelbasierten Kartenrendering-Projekte konfrontiert sind und das durch systematisches Testen gelöst werden kann. Kartenstile, insbesondere komplexere wie OSM Carto, stehen vor dem Problem, dass es sehr schwierig ist, zu bestimmen, was der Stil tatsächlich rendert (d.h. welche Attributkombinationen in welcher Zoomstufe in einer bestimmten Weise gerendert werden), indem man sich den Code ansieht oder ihn analysiert. Der einzige zuverlässige Weg, dies zu tun, ist das tatsächliche Rendern von Dingen. Der einzige aussagekräftige Index oder Kartenschlüssel von OSM Carto, der bisher existiert, ist eine von Hand kuratierte Wiki-Seite, die von Menschen auf der Grundlage ihres Wissens über den Stil erstellt wurde.

Systematische Tests können dabei helfen, indem man den Stil mit verschiedenen Datenkombinationen füttert und prüft, welche davon zu einer spezifischen Darstellung führt. Wie Sie sich wahrscheinlich vorstellen können, würde dies eine unüberschaubare Anzahl von Tests erfordern, wenn man das ganz stupide ausprobieren würde. Aber durch die Verwendung geeigneter Heuristiken, um dies einzugrenzen, kann der Aufwand auf ein überschaubares Maß reduziert werden – auch wenn man im Falle eines Kartenstils wie OSM Carto immer noch bei über 100k Tests landet.

Und das ist es, was ich hier vorstellen möchte – StyleInfo ist ein neues Tool, das ich entwickelt habe und mit dem man sich ansehen kann, wie verschiedene Kartenstile OpenStreetMap-Daten darstellen – basierend auf einer Analyse des Stils, die heuristische, systematische Tests verwendet, um festzustellen, was der Stil in welcher Form wiedergibt, ohne dass man dafür vorab umfangreiche Informationen über den Stil benötigt,

StyleInfo ist ähnlich aufgebaut wie Taginfo, es erlaubt Ihnen, die verschiedenen Schlüssel und Tags des OSM-Tagging-Systems zu betrachten – aber anstatt zu zeigen, wie diese Tags in der Datenbank verwendet werden, zeigt es, wie diese Tags durch den ausgewählten Stil dargestellt werden.

Key based view in StyleInfo

Tag based view in StyleInfo

Darüber hinaus können Sie auch sehen, wie der Stil die Tags nur auf einer bestimmten Zoomstufe darstellt.

Zoom level based view in StyleInfo

All dies ist mit Querverweisen versehen, so dass Sie ganz einfach zwischen den verschiedenen Ansichten wechseln können. Ein paar Beispiele:

Die Informationen über den Kartenstil, die Sie auf diese Weise erhalten, sind insbesondere in zweierlei Hinsicht etwas eingeschränkt:

  • Aus prinzipiellen Gründen kann nicht garantiert werden, dass die Ergebnisse vollständig sind. Ich habe bereits einige Tag-Kombinationen identifiziert, die in einigen Stilen in der Analyse fehlen, und werde deshalb Anpassungen an der Heuristik vornehmen müssen. Nichtsdestotrotz ist dies die bisher umfassendste Dokumentation von OSM Carto und abgeleiteten Kartenstilen.
  • StyleInfo zeigt bisher Renderings von primären Tags und Kombinationen von primären Tags mit einem sekundären Tag. Weder Kombinationen aus mehreren primären oder sekundären Tags noch tertiäre Tags werden bisher behandelt. Was das genau bedeutet, werde ich im Folgenden noch genauer erläutern.

Das zugrunde liegende Tagging-Modell

OpenStreetMap verwendet prinzipiell ein Freiform-Tagging-System – ich habe das im Zusammenhang mit TagDoc näher erörtert. Praktisch alle OSM-basierten Kartenstile interpretieren dieses Tagging in einer etwas eingeschränkteren Art und Weise, und deshalb neigen Mapper auch dazu, Tags nach diesem etwas eingeschränkteren Tagging-Modell zu verwenden.

In diesem Modell (wie auf TagDoc dokumentiert) werden Tags grob unterteilt in

  • primäre Tags – das sind Tags, die einem Merkmal eine semantische Bedeutung verleihen, auch wenn sie allein verwendet werden.
  • sekundäre Tags – das sind Tags, die nur in Kombination mit einem primären Tag eine klar definierte Bedeutung haben.

Im Zusammenhang mit dem Kartenrendering und somit mit StyleInfo sind primäre Tags solche, die allein – wenn sie auf eine Geometrie angewendet werden – das Rendering-Ergebnis beeinflussen. Das wären z. B. Tags wie natural=water bei Polygongeometrien, highway=motorway bei linearen Geometrien oder amenity=pub bei Punkten. Sekundäre Tags sind Tags, die das Rendering eines primären Tags verändern. Beispiele hierfür sind name=* bei einem der zuvor genannten primären Tags oder bridge=yes bei highway=motorway.

In der Praxis gibt es einige Fälle in Stilen, die diesem Modell nicht folgen. Zum Beispiel werden Verwaltungsgrenzen von den meisten Kartenstilen nur dargestellt, wenn sie sowohl mit dem primären Tag (boundary=administrative) als auch mit einem admin_level=*-Tag (im Falle von OSM Carto mit admin_level zwischen 2 und 10) versehen sind. Dies erfordert die Einführung einer dritten Art von Tags in das Tagging-Modell:

  • Qualifier-Tags – das sind sekundäre Tags, ohne die das primäre Tag vom Stil nicht interpretiert wird.

Neben dem erwähnten Beispiel der administrativen Grenzen ist das häufigste Qualifier-Tag das name-Tag bei Merkmalen, die ein Kartenstil nur mit einer Namensbeschriftung wiedergibt.

Beachten Sie, dass verschiedene Kartenstile unterschiedliche Annahmen darüber treffen, was primäre und was sekundäre Tags sind, was die Analyse zusätzlich erschwert. OSM Bright und auch OSM Carto in frühen Versionen interpretieren name=* als primäres Tag und geben Namensbeschriftungen für alles mit einem Namens-Tag wieder, auch wenn keine anderen Tags vorhanden sind.

Und wie gesagt – was StyleInfo bisher nicht abdeckt, sind Kombinationen aus mehreren verschiedenen primären und sekundären Tags – was interessant zu betrachten ist, weil manchmal Stile solche Kombinationen explizit darstellen (wie eine Straße mit einem Brücken-Tag und Zugangsbeschränkungen), während in anderen Fällen ein Tag ein anderes überschattet (wie in den meisten Fällen mit mehreren primären Tags). Was ebenfalls nicht behandelt wird, sind tertiäre Tags – d. h. Fälle, in denen eine Kombination aus drei Tags zu einem anderen Rendering-Ergebnis führt – wie in OSM Carto bestimmte Werte von denomination=* in Kombination mit religion=christian auf amenity=place_of_worship, wodurch sich das verwendete Symbol ändert.

Die wichtigsten Einschränkungen

Einige haben sich vielleicht schon über die Auswahl an Stilen gewundert, die derzeit in StyleInfo angeboten werden. Wie Sie am Beispiel des Map-Machine-Stils sehen können, ist die Analyse nicht auf CartoCSS/Mapnik-Stile beschränkt. Aufgrund der großen Anzahl von Tests, die durchgeführt werden müssen, ist es jedoch erforderlich, dass die Integrationstests der gesamten Rendering-Kette effizient auf Allzweck-Hardware in einer Headless-Konfiguration ausgeführt werden können. Und das ist bei all den postmodernen clientseitigen Renderingstilen, die heutzutage beliebt sind, schwierig. Wenn mir jemand einen Arbeitsablauf zeigen kann, der Maplibre/Mapbox JSON-Stile als Bilddateien auf Headless-Allzweck-Hardware rendert, ohne auf esoterischen Ballast wie npm oder docker angewiesen zu sein, könnte ich es versuchen.

Für OSM Carto und andere Stile mit einer Rendering-Datenbank, die das OSM-Tagging direkt widerspiegelt, ohne dass die Tags beim Import aufwändig uminterpretiert werden, kann die Analyse des Kartenstils erheblich beschleunigt werden, indem der Datenbankimport aus dem Test ausgeschlossen wird. Dies unterstreicht meine frühere Beobachtung, dass die Idee, Tag-Interpretationen beim Datenimport und nicht während des Renderings durchzuführen – eine Überlegung, die in letzter Zeit in der OSM-Gemeinschaft an Popularität gewonnen hat – aus Sicht des Kartendesigns eine schlechte Idee ist. Man gewinnt nichts Substanzielles (denn Tag-Interpretation ist billig), und der Kartendesigner muss entweder den Datenbankimport in seine Designarbeit und seine Tests integrieren (so wie ich es für die StyleInfo-Analyse tun muss) oder seinen Stil nicht für OSM-Daten, sondern für ein zwischengeschaltetes Datenmodell entwickeln, das sich seiner Kontrolle entzieht (wozu die meisten postmodernen clientseitigen Rendering-Stilentwicklungen tendieren – daher wahrscheinlich die Popularität dieser Idee).

Eine brauchbare Karten-Legende?

StyleInfo dokumentiert, wie ein Kartenstil OpenStreetMap-Daten und -Tagging in eine visuelle Darstellung übersetzt. Obwohl dies offensichtlich ein Schlüsselelement für die Erstellung eines brauchbaren Kartenschlüssels oder einer Legende ist, fehlt die Übersetzung zwischen den OpenStreetMap-Tags und der Semantik der realen Welt, um sich als solche zu qualifizieren. Dies ist – wie sich einige Leser vielleicht erinnern – das Ziel von TagDoc. StyleInfo und TagDoc sind Projekte, die sich gegenseitig ergänzen, und die Idee ist, dass diese beiden zusammen Schlüsselkomponenten sein könnten, um einem breiteren Publikum ein besseres Verständnis der Semantik von OpenStreetMap-Daten und von OpenStreetMap-basierten Kartenstilen zu vermitteln.

Tags interpretiert von OpenStreetMap Carto - Visualisierung von StyleInfo, Link öffnet die interaktive Version

Tags interpretiert von OpenStreetMap Carto – Visualisierung von StyleInfo, Link öffnet die interaktive Version

Systematic testing in map design

19. Dezember 2022
von chris
Keine Kommentare

Systematisches Testen bei der Kartengestaltung

Deutscher Text auf Grundlage einer maschinellen Übersetzung mit deepl.

Das Thema dieses Beitrags ist etwas, mit dem ich mich schon seit einiger Zeit beschäftige – das Problem des systematischen Testens beim Kartendesign. Um zu verdeutlichen, worum es hier geht, muss ich ein wenig den größeren Zusammenhang erklären.

Traditionelles Testen bei der Kartengestaltung

Der traditionelle Weg, regelbasierte Kartenstile zu entwerfen, insbesondere im OpenStreetMap-Kontext, ist es, dies auf der Grundlage einer Testdatenbank zu tun, die eine Auswahl von tatsächlichen Kartendaten enthält. Die meisten Kartendesigner verfügen über eine Testdatenbank, die in der Regel entweder einen Auszug (z. B. von der Geofabrik oder mit der Overpass API erstellt) aus ihrem Interessengebiet oder eine Reihe von Gebieten aus verschiedenen Teilen der Welt enthält. Einen Eindruck vom Inhalt meiner Testdatenbank kann man sich in der ac-style Beispielgalerie verschaffen.

Für die Arbeit an der Gestaltung eines bestimmten Objekttyps sucht man sich ein oder mehrere Vorkommen dieses Objekttyps in Ihrer Testdatenbank und untersucht die Auswirkungen der Änderungen auf diese Vorkommen. Häufig verwendete Design-Tools – wie TileMill in den ersten Tagen oder Kosmtik (im Falle von CartoCSS-Stilen) und andere Tools, wie Maputnik, im Falle von JSON-basierten Styling-Sprachen – sind speziell für diesen Arbeitsablauf konzipiert.

Viele Beispiele für die Verwendung dieses Ansatzes bei der Stilentwicklung finden sich in OSM-Carto – wie hier.

Diese Arbeitsstrategie hat mehrere Vorteile

  • Sie ist relativ unkompliziert und erfordert keinen großen Arbeitsaufwand vom Designer, um loszulegen.
  • Sie testet das Design in genau dem Kontext, für den es gedacht ist, nämlich der Darstellung von tatsächlichen Kartendaten.

Aber sie bringt auch gewisse Nachteile mit sich

  • Man testet das Design nur in den Kontexten, die man zufällig als Beispiele ausgewählt hat. Das deckt in der Regel weder alle relevanten Situationen ab, in denen das Design verwendet werden soll, noch ist es repräsentativ für die gesamte Vielfalt der Orte, an denen das Merkmal auftritt.
  • Es ist sehr schwierig, irgendeine Art von systematischen Tests durchzuführen. Selbst der Vergleich zwischen verschiedenen Zoomstufen ist schwierig, da sich der geometrische Kontext beim Wechsel der Zoomstufe verändert.

Synthetische Tests

Aufgrund dieser Probleme haben die OSM-Carto-Entwickler seit langem damit begonnen, zusätzlich zu den traditionellen Tests auf der Grundlage von realen Testdaten synthetische Tests durchzuführen. Ich kann nicht mit Sicherheit sagen, wann dies das erste Mal gemacht wurde, aber hier sind zwei Beispiele:

OSM-Carto synthetic test example 1

OSM-Carto synthetic test example 2

Normalerweise werden solche Tests in JOSM entworfen, durch osmium renumber laufen gelassen und dann in eine Testdatenbank importiert.

Diese Art von Test ist vor allem für etwas erfahrenere Kartendesigner nützlich, die bereits im Voraus abschätzen können, in welchen Kontexten eine bestimmte Änderung besonders kritisch zu begutachten ist.

Ich würde sogar so weit gehen zu sagen, dass Änderungen des Straßenrenderingsystems von OSM-Carto, die oft in vielen verschiedenen Designkontexten funktionieren müssen, ohne den Einsatz synthetischer Tests fast unmöglich zu entwickeln sind. Das Rendering von unbefestigten Straßen, das es kürzlich endlich in OSM-Carto geschafft hat, ist ein gutes Beispiel dafür:

OSM-Carto synthetic test example 3

So nützlich diese Art des Testens auch ist, sie birgt immer auch die Gefahr, dass sich Kartendesigner vollständig auf synthetische Tests konzentrieren und das Testen mit realen Daten vernachlässigen. Das ist natürlich keine gute Idee. In der praktischen Kartengestaltung sind Tests mit realen Daten immer notwendig und wichtig.

Ein weiteres Problem besteht darin, dass bei dieser Art von handgezeichneten synthetischen Tests die Vergleichbarkeit zwischen verschiedenen Zoomstufen immer noch eingeschränkt ist.

Automatisierte Skalierung von Tests

Diese Einschränkung hat mich vor einigen Jahren dazu veranlasst, einen Ansatz zur automatischen Skalierung synthetischer Testdatensätze zu entwickeln, um eine bessere Vergleichbarkeit über Zoomstufen hinweg zu erreichen. Ich habe in diesem Blog bereits mehrfach Beispiele für diesen Ansatz gezeigt. Durch die Skalierung der Testdaten auf die gewünschte Zoomstufe werden die Rendering-Ergebnisse über verschiedene Zoomstufen hinweg viel besser vergleichbar. Dies ist besonders nützlich, um sicherzustellen, dass die Entwicklung von Designparametern über die verschiedenen Zoomstufen hinweg (z. B. Linienbreiten oder Beschriftungsgrößen) gut funktioniert.

Straßen-Elemente bei z16

Straßen-Elemente bei z16

Das Selbe bei z17 mit skalierten Geometrien

Das Selbe bei z17 mit skalierten Geometrien

Systematisches Testen

Sobald die automatische Skalierung von Tests funktioniert, ist es nur noch ein kleiner zusätzlicher Schritt, die Rendering-Ergebnisse systematisch in verschiedenen Zoomstufen und mit verschiedenen Kombinationen von Attributen zu testen. Dies ermöglicht zwei Dinge:

  • das formale Testen des Kartendesigns in allen verschiedenen Varianten, in denen es funktionieren soll.
  • die Funktionen eines Kartenstils umfassend zu dokumentieren.

Den zweiten Anwendungsfall habe ich schon vor einiger Zeit in TagDoc demonstriert:

Darstellungs-Beipiele aus TagDoc

In letzter Zeit habe ich das ganze Konzept des systematischen Testens von Kartenstilen zu einem Werkzeug weiterentwickelt, das ich im nächsten Blogpost vorstellen werde.

New Antarctic images for mapping

10. Dezember 2022
von chris
Keine Kommentare

Neue Bilder zum kartieren in der Antarktis

Ich habe einige weitere Satellitenbilder der Antarktis für die Kartierung in OpenStreetMap vorbereitet und zur Nutzung bereit gestellt. Sie decken hauptsächlich die Gebirge von Königin-Maud-Land ab, d. h. den Abschnitt der ostantarktischen Küste, der dem Atlantik zugewandt ist. Dieses Gebiet war in der Vergangenheit ein wichtiger Schwerpunkt der europäischen Erforschung der Antarktis und bietet einige der spektakulärsten Landschaften des Kontinents. Außerdem sind einige weitere Bilder der antarktischen Halbinsel enthalten.

Zusätzlich zu den Sentinel-2-Bildern mit einer Auflösung von 10m habe ich auch eine Reihe von Landsat-Bildern vom Abend bereit gestellt, da zwei Bilder mit unterschiedlichen Beleuchtungen für die Kartierung von Gipfeln und Graten in gebirgigem Gelände von großem Wert sein können. Hier ein Beispiel:

Auch sonst halte ich die einzelnen Bilder in separaten Ebenen, damit die Mapper zur besseren Beurteilung der örtlichen Situation mehrere verschiedene Bilder heranziehen können, sofern verfügbar.

Wer meine frühere Diskussion über den Stand der Kartierung der Antarktis gelesen hat, wird sich vielleicht fragen, warum ich mir die Mühe gemacht habe, obwohl die OSM-Community insgesamt eindeutig recht wenig Interesse an der Kartierung der Antarktis zeigt. Der Grund ist, dass ich angesichts der schlechten Situation der meisten üblichen Bildquellen, die von Mappern verwendet werden, sicherstellen möchte, dass die Kartierung hier zumindest nicht durch den Mangel an geeigneten Bildern behindert wird.

Die Bilder, die ich für die Antarktis aufbereitet habe, decken nun mehr als die Hälfte der Teile des Kontinents ab, die eisfreie Gebiete enthalten. Das bedeutet, dass Sie, wenn Sie an der Kartierung eines bestimmten Teils des Kontinents interessiert sind, möglicherweise immer noch kein geeignetes Bildmaterial finden können. Wenn Sie jedoch vor allem generell daran interessiert sind, den Kontinent im Allgemeinen zu kartieren, gibt es fast überall auf dem Kontinent jetzt gute Möglichkeiten dazu.

Wie bisher werden die neuen Bilder wahrscheinlich bald in den Editoren verfügbar sein – wer nicht warten möchte, kann diese auch manuell über die in meiner Vorschau-Karte angegebenen Links hinzufügen.