Warum OpenStreetMap in ernsten Schwierigkeiten steckt

Geschrieben von am , übersetzt von am .

Ich habe lange Zeit zu OpenStreetMap beigetragen und mich lange Zeit für OpenStreetMap eingesetzt, aber das Projekt ist ins Stocken geraten, während die proprietäre Kartierungswelt ihre Datenqualität weiter verbessert hat. Für diejenigen unter uns, denen freie und offene Daten am Herzen liegen, ist das ein Problem. In diesem Artikel gehe ich auf die Gründe ein, warum OSM meiner Meinung nach ins Stocken geraten ist, und zeige Lösungen auf, um das Projekt wieder auf Kurs zu bringen.

Ich habe von 2008 bis etwa 2016 am OpenStreetMap-Projekt mitgearbeitet. Ich habe viel in das Projekt investiert. In dieser Zeit kartierte ich, organisierte Kartierungsgruppen in zwei Städten, trug zur Gründung von OpenStreetMap US bei, einer gemeinnützigen Organisation, die sich für OpenStreetMap in den Vereinigten Staaten einsetzt, hielt Vorträge über OpenStreetMap, trug zur OpenStreetMap.org Codebase bei, betreute zwei Studenten für OSM im Rahmen von Google Summer of Code, gründete eine Arbeitsgruppe, die sich mit dem Import von Daten in OpenStreetMap in den USA befasste, erstellte und koordinierte einen massiven Bot-Run in den USA, moderierte die Reddit-Seite r/OpenStreetMap und war Mitglied der OpenStreetMap Data Working Group, was mir weitreichende Privilegien (sowohl politisch als auch technisch) für das Projekt einräumte. Es gibt nur wenige Teile von OpenStreetMap, an denen ich nicht direkt oder indirekt beteiligt war.

Ich bin auch der Autor eines Artikels mit dem Titel Why the World Needs OpenStreetMap, der in zwei großen Publikationen, The Guardian Online und Gizmodo, erschien, zweimal auf der Titelseite von Hacker News war und in mindestens vier verschiedene Sprachen übersetzt wurde. Ich war ein stolzer OpenStreetMap-Befürworter!

Bevor ich das Projekt kritisiere, möchte ich mit Nachdruck betonen, dass ich immer noch von ganzem Herzen an die Grundprinzipien von OpenStreetMap glaube. Wir brauchen einen freien geografischen Datensatz heute genauso sehr wie in der Vergangenheit. Als ich meinen Artikel über OSM im Jahr 2012 schrieb, waren selbstfahrende Autos und andere Dienste noch ein Traum. Heute ist ein hochpräziser, freier geografischer Datensatz wichtiger denn je, und ich unterstütze alle, die daran arbeiten, ihn zu verwirklichen.

Obwohl ich immer noch an die Ziele von OpenStreetMap glaube, bin ich der Meinung, dass das OpenStreetMap-Projekt derzeit nicht in der Lage ist, diese Mission zu erfüllen, und zwar aufgrund schlechter technischer Entscheidungen, schlechter politischer Entscheidungen und eines allgemeinen Unbehagens im Projekt. Ich werde in diesem Artikel darlegen, was OpenStreetMap meiner Meinung nach falsch gemacht hat. Es ist durchaus möglich, dass OSM sich reformiert und die Hindernisse, die seinem Erfolg im Wege stehen, beseitigt - und ich hoffe, dass es das tut. Wir brauchen einen freien geografischen Datensatz.

So lang dieser Beitrag auch ist, es ist keine umfassende Liste aller Probleme mit dem Projekt, sondern nur derer, die sich meiner Meinung nach am unmittelbarsten auf den Erfolg des Projekts auswirken und die ich während meiner Zeit im Projekt nicht selbst beheben konnte.

Wenn die Welt eine Karte braucht, gib ihr eine Datenbank

Das erste Problem, das OSM meiner Meinung nach plagt, ist, dass die OpenStreetMap Foundation die Aufgabe des Projekts darin sieht, der Welt eine geografische Datenbank zur Verfügung zu stellen, aber keine geografischen Dienste. OSM gibt den Menschen die Werkzeuge in die Hand, um ihre eigene Karte zu erstellen, anstatt ihnen eine einfache, sofort einsatzbereite Lösung anzubieten. Einzelpersonen und Organisationen die Möglichkeit zu geben, ihre eigene Karte zu erstellen, mag für einige gut funktionieren, aber es hält kleine und mittlere Organisationen davon ab, OSM zu nutzen und sich somit an dem Projekt zu beteiligen. Und selbst wenn sie unsere Daten nutzen, geschieht dies über einen Dritten und nicht direkt mit uns.

Wenn Sie OpenStreetMap.org besuchen, sehen Sie eine Karte und ein paar Extras, wie ein Suchfenster, sowie ein paar zusätzliche Schaltflächen wie Anmelden und Bearbeiten. Man könnte annehmen, dass OpenStreetMap eine Karte ist, wie Google Maps oder andere Kartenprojekte, aber obwohl es eine Karte auf OpenStreetMap.org gibt, möchte OpenStreetMap nicht, dass Sie sie benutzen. Stattdessen möchte OpenStreetMap, dass Sie die Informationen von OpenStreetMap nutzen, um Ihre eigene Karte zu erstellen, oder dass Sie jemanden finden, der die Karte für Sie erstellt.

Wenn Sie das seltsam oder verwirrend finden, sind Sie nicht allein.

Eine Karte ist nichts anderes als eine Visualisierung einer Sammlung von Fakten. Wir können dies mit Hilfe der Geometrie verstehen. Stellen wir uns ein Möbelgeschäft namens Frita's Furniture vor. Unsere Karte ist eine einfache zweidimensionale Ebene, wie wir sie im Erdkundeunterricht hatten, und sie liegt bei 10, 0. Wir könnten uns auch eine Straße namens Main Street vorstellen, die von 2,9 bis 15,9 verläuft.

Die Lage des Geschäfts und der Straße sind geografische Fakten, aber wenn wir diese Daten visuell darstellen wollen, verwenden wir normalerweise eine Karte. Wir würden uns entscheiden, wie wir die Straße einzeichnen. Würden wir eine einfache Linie oder ein Bild mit mehr Straßenlinien verwenden? Wie breit sollte die Linie sein? Welche Farbe soll sie haben? Wo würden wir den Namen der Straße platzieren? Wir könnten ihn quer zur Linie, neben der Linie oder auf eine ganz andere Weise anbringen. Und wollen wir das Geschäft als Punkt oder als Symbol für ein Geschäft darstellen?

Vor Jahren haben die Kartenersteller diesen Prozess manuell durchgeführt, aber mit Computern nennen wir diesen Prozess im Allgemeinen Kartenrendering, und es gibt viele Entscheidungen rund um das Rendering einer Karte, z. B. die Verwendung der Karte, lokale Konventionen und sogar die Einhaltung des Kartenstils einer bestimmten Organisation.

Aber die meisten Menschen interessieren sich für all das nicht. Sie wollen einfach nur eine Karte. OSM hat eine Karte auf seiner Website, rät aber davon ab, diese von Dritten zu nutzen. Stattdessen wird von den Nutzern erwartet, dass sie entweder einen kommerziellen Dienst finden, der die Karte für sie erstellt, oder es selbst tun.

Die Projektleiter geben an, dass sie wollen, dass die Nutzer von OpenStreetMap den Unterschied zwischen den geografischen Daten und ihrer visuellen Darstellung verstehen, und dass sie ein Ökosystem des freien Marktes mit Anbietern von gerenderten Karten fördern wollen, aber es ist auch eine Tatsache, dass viele der Personen, die auf diese Trennung drängen, auch kommerzielle Kartendienste verkaufen. Auf diesen Interessenkonflikt gehe ich später in diesem Beitrag ein.

Unklare Verwendungsrichtlinien

Ich habe bereits erwähnt, dass OSM von der Verwendung seiner Karten auf anderen Websites abrät. Dies geschieht durch technisch erzwungene Nutzungsrichtlinien. Das Verständnis einer Nutzungsrichtlinie ist in der Regel ein unkomplizierter Prozess. Eine Person oder Organisation erhält die Erlaubnis, einen Dienst in einem bestimmten Umfang zu nutzen. Wir könnten uns vorstellen, dass dies anhand der Anzahl der Kartenanfragen oder der Bandbreite usw. geschieht. Die Nutzungspolitik von OSM ist jedoch völlig anders. Sie erlauben die Nutzung der kostenlosen Karte, raten aber davon ab, und verbieten dann jede einzelne Anwendung, die mehr als 5 % der Kartenbandbreite nutzt. Diese Politik ist in mehrfacher Hinsicht bizarr.

Um zu verstehen, warum das so seltsam ist, können wir eine Analogie verwenden. Stellen wir uns vor, dass ich Eiscreme herstelle. Ich lege das Rezept für meine Eiscreme vor meinem Haus aus und schlage den Leuten vor, ihr eigenes Eis zu machen. Ich biete auch kostenlose Proben in meinem Haus an. Über meiner Tür hänge ich ein Schild mit der Aufschrift Bitte nicht nach Gratisproben fragen. Wenn dann jemand reinkommt und nach einer Probe fragt, gebe ich sie ihm. Die Leute erzählen vielleicht von meinem Gratiseis und schlagen es ihren Freunden vor. Stellen Sie sich vor, eine Person namens Fred ist ein Fan meines Eises und empfiehlt allen seinen Freunden, bei mir Eis zu essen. Ich verteile weiterhin kostenloses Eis an alle, die danach fragen. Aber wenn eine Person wie Fred zu viele Leute an mich verweist, werde ich allen, die Fred geschickt hat, den Zugang verwehren.

Um die Analogie fortzusetzen, werde ich Freds Freunden sagen, dass sie zu viel Gratiseis gegessen haben, anstatt es Fred zu sagen. Und wie viele Menschen sind zu viele Menschen? Die Antwort für OpenStreetMap ist alles, was mehr als fünf Prozent der Gesamtmenge an kostenlosem Eis ausmacht, die ich an diesem Tag verteilt habe. Fred hat keine Ahnung, wie viele Leute ich bedient habe, also ist das Einzige, was er tun kann, die Leute nicht an mein Haus zu verweisen.

Diese Analogie funktioniert, weil kein einzelner Dienst weiß, was ein anderer Dienst tut, und weil es keine Möglichkeit gibt, zu wissen, wie viele andere Anwendungen wie viele Kartenanforderungen gestellt haben. Da sich die wichtigsten Dienste und Anwendungen im Laufe der Zeit ändern, kann es sein, dass Sie an einem Tag gut dastehen und am nächsten Tag Probleme haben. Auch hier gibt es keine Möglichkeit, das zu wissen. Und wenn Sie die Grenze zur übermäßigen Nutzung des Dienstes überschreiten, erhalten Ihre Nutzer eine unfreundliche Nachricht über die Nichtverfügbarkeit, nicht Sie.

OSM könnte Standard-Nutzungsrichtlinien erstellen, in denen genau festgelegt ist, wie viel kostenlose Nutzung erlaubt ist. OSM könnte auch eine Premium-Mitgliedschaft einführen und die Nutzer dazu ermutigen, den Kacheldienst (gerenderte Karten) zu nutzen, aber im Moment ist es schwierig, OSM-Kacheln zu verwenden, ohne einen Dritten einzuschalten.

Ein schlechter Geocoder

Wenn Sie eine Adresse in eine Karte eingeben und diese Ihnen den Standort anzeigt, nennt man das Geokodierung. Wenn Ihr GPS oder Telefon weiß, wo Sie sich befinden, und Ihnen eine Gebäude- oder Straßenadresse gibt, nennt man das Reverse Geocoding. Der Geocoder auf OpenStreetMap.org heißt Nominatim, und er ist schrecklich.

Nominatim ist nicht der einzige OSM-Geocoder. Ähnlich wie bei der Kartendarstellung ist es möglich, einen eigenen zu schreiben oder einen kommerziellen Geokodierungsdienst zu nutzen. Aber Nomatim ist der beliebteste Geocoder für OpenStreetMap, er wird auf der Website verwendet, und Nominatim ist der Dienst, der auf OpenStreetMap.org unter seinen APIs aufgeführt ist.

Zu seiner Verteidigung möchte ich sagen, dass Geokodierung schwierig ist und Nominatim selbst ziemlich komplex ist; es ist fast eine technische Meisterleistung. Die Entwickler, die daran arbeiten, haben enorme Anstrengungen in die Entwicklung von Nominatim gesteckt. Das Problem ist, dass solche Software gewartet oder manchmal ganz ersetzt werden muss, um nützlich zu sein. Es gab zwar Nominatim-Maintainer, aber es wurde ihm nicht die Zeit und Aufmerksamkeit gewidmet, die es braucht und verdient hätte.

Um zu verstehen, warum Nominatim schlecht ist, muss man verstehen, wie die meisten Leute einen Geocoder benutzen. Meistens suchen sie nach einem Geschäft oder etwas Vagem wie Staples downtown Springfield. Diese einfache Abfrage mit drei Buchstaben ist ziemlich anspruchsvoll. Der Computer muss wissen, was Springfield ist, und die Abfrage darauf beschränken. Dann soll die Suche auf ein Gebiet namens „Downtown“ (oder in der Nähe davon!) beschränkt werden, und schließlich sollen die Ergebnisse auf Staples beschränkt werden.

Aber Nomintim kann solche Abfragen nicht verarbeiten. Es kann kaum mit einfachen Adressabfragen umgehen, wie z. B. 123 Main Street. Wenn ich z. B. eine Adresse in der Nähe meines Standorts in New York City eingebe, könnte Nominatim ein Ergebnis in Iowa liefern, das es mir – aus welchen Gründen auch immer – eher anbieten möchte.

Wenn ich versuche, meinen Standort als Manhattan anzugeben, nimmt Nomintim zunächst an, dass ich Manhattan, Kansas, meine, und ignoriert dabei sowohl die Bedeutung von Manhattan in New York als auch die Tatsache, dass die Anfrage selbst aus New York City stammt. Schlimmer noch, es ist nicht möglich, nach Kreuzungen zu suchen. Wenn ich 53rd and 6th, New York City in Nominatim eingebe, versteht es das Programm nicht. Selbst wenn ich versuche, die Suche auf 53rd Street und 6th Avenue, New York City zu verfeinern, funktioniert es nicht. Straßenkreuzungen sind für Nominatim keine Adressen. Es versteht weder Geschäfte noch in der Nähe oder Kategorien wie Restaurant. Die Ergebnisse sind oft irrelevant, und der Dienst ist ziemlich langsam.

Es gibt zwar andere Geocodierer für OSM, wie Pelias und Photon, aber nur Nominatim wird von der OSM Foundation betrieben und unterstützt.

Kein Moderations-/Prüfungsmodell

Eines der größten technischen Probleme von OSM ist das Fehlen eines Überprüfungsmodells, d. h. die Möglichkeit, Änderungen an der Karte zu moderieren und dann zu überprüfen, bevor sie angewendet werden. Das Fehlen dieser Funktionalität führte zu einer Reihe von Problemen im gesamten System, von denen ich einige hier erörtern möchte.

Probleme für neue Mapper

Die Bearbeitung von OSM kann für einen Anfänger eine Herausforderung sein, und als das Projekt versuchte, neue Kartierer (Redakteure) zu gewinnen, trafen wir auf Leute, die einfach falsch kartierten. Da das OSM-Datenmodell keine Überprüfungsphase vorsieht, werden fehlerhafte Bearbeitungen in die Karte übernommen und bleiben oft unentdeckt, und selbst wenn sie entfernt werden, sieht der ursprüngliche Bearbeiter in der Regel nicht, warum.

Die Möglichkeit, dass ein Mapper Änderungen einbringt und diese dann überprüft werden, hätte der Karte eine höhere Datenqualität und eine Art Mentorenmodell zwischen neuen Mitwirkenden und erfahreneren Bearbeitern beschert.

Ich hatte gehofft, dass sich dies verbessern würde, als ich als Mentor eine Funktion in OpenStreetMap einführte, die Changeset Comments genannt wurde und mit der Benutzer Feedback zu den Änderungen der anderen Benutzer hinterlassen konnten. Leider wurde diese Funktion von vielen Leuten nicht konstruktiv genutzt, und es war ein Chaos.

Ohne Moderation sind Bots schwierig

Bots könnten in OSM sehr nützlich sein, um Fehler zu finden, die entweder durch ungenaue Datenquellen oder durch Bearbeitungsfehler verursacht wurden. Wenn z. B. eine Straße mit dem Namen Main Street mit einer anderen Straße mit dem Namen Main Stret verbunden ist, handelt es sich wahrscheinlich um einen Rechtschreibfehler, der korrigiert werden sollte. Es wäre jedoch gut, wenn die Änderungen zunächst von einem Menschen überprüft würden.

Da OSM jedoch keinen Mechanismus für überprüfte Bearbeitungen bietet, gibt es diese Art von Änderungsvorschlägen nicht. Entweder werden Bot-Edits ohne Aufsicht durchgeführt, was zu Fehlern führen kann, oder sie werden gar nicht durchgeführt und das Projekt geht verloren.

Importe sind schwierig

Importe sind aus einer Vielzahl von Gründen schwierig, aber ein Moderations- oder Überprüfungsmodell würde die Dinge sehr viel einfacher machen, da Änderungen in Etappen durchgeführt werden könnten. Die Unfähigkeit, massive Änderungen an der Karte zu moderieren und zu überprüfen, hat in der Vergangenheit zu Problemen geführt, und viele schlechte Importe bleiben unbemerkt. Wenn das Projekt stattdessen verlangen würde, dass ein Mensch die Änderungen überprüft, bevor sie in das System übernommen werden, könnten fehlerhafte Importe entdeckt werden, bevor sie Probleme verursachen.

Da es in OSM selbst kein Staging gibt, wurden Staging-Systeme für andere OSM-bezogene Projekte entwickelt. Diese Systeme erfordern häufig, dass die Redakteure diese Änderungen manuell in OSM einfügen. Dieser Prozess ist arbeitsintensiv und macht manche Importe so schwierig, dass sie abgebrochen werden, bevor sie beginnen.

Vandalismus ist schwer zu kontrollieren

Wie bei Wikipedia gibt es auch bei OSM Leute, die das Projekt absichtlich vandalisieren. Die Motive der Vandalen sind vielfältig. Einige Vandalen sind ganz normale Internet-Trolle, die gerne Probleme verursachen. Manchmal will ein Unternehmen etwas auf der Karte haben, obwohl die Gemeinschaft dagegen ist, und ändert die Karte, um ihren Bedürfnissen gerecht zu werden, auch wenn das Projekt als Ganzes dagegen ist. Manchmal Kartographen nutzen OSM, um politische Statements abzugeben, wie im Fall von umstrittenen Gebieten, und manchmal nutzt ein geografisch basiertes Spiel wie Pokemon Go OSM, um seine Daten zu generieren, und die Spieler stellen fest, dass sie die Karte ändern können, um sich einen Vorteil zu verschaffen. Was auch immer der Grund ist, OSM hat Vandalen.

Vandalismus ist in OSM schwierig, denn ohne ein Moderationssystem muss er „bereinigt“ werden, anstatt ihn von vornherein zu verhindern. Die Erkennung von Vandalismus ist schwierig. Mehrere Personen haben Überwachungsprogramme eingesetzt, um problematische Bearbeitungen und Importe zu finden. Ich war einer dieser Leute.

Selbst wenn problematische Bearbeitungen entdeckt werden, bedeutet ihre Entfernung, dass noch mehr Bearbeitungen vorgenommen werden müssen. Die Historie des Projekts ist mit vielen kleinen Änderungen übersät, die nur dazu da sind, eine frühere Änderung zu entfernen. Schlimmer noch, wenn der Vandalismus nicht frühzeitig erkannt wird, könnte jemand anderes ein Objekt ändern, das zuvor mutwillig verändert wurde, was dazu führt, dass entweder ein Werkzeug oder eine Person die guten Änderungen von den schlechten trennen muss, ein manueller Prozess, der arbeitsintensiv sein kann.

Ein Moderationswerkzeug würde vieles davon verhindern. Viele Vandalen würden feststellen, dass ihre Arbeit nicht in die Datenbank gelangt, und würden weiterziehen. Zwar würden einige böswillige Bearbeitungen immer noch durchkommen, aber wir wären in der Lage, die meisten zu beseitigen, bevor sie zu einem Problem werden.

Externe Tools sind schwierig

Einer meiner Beiträge zu OpenStreetMap war die Arbeit an der Verbesserung von MapRoulette, einem Tool, das dabei hilft, Probleme in OSM zu finden und den Benutzern die Möglichkeit gibt, sie zu beheben. Eine Funktion, die wir in MapRoutlette haben wollten, war die Möglichkeit, den Benutzern einfache Ja/Nein-Fragen zu stellen. Leider ist dies zwar nicht unmöglich, aber in OpenStreetMap wäre es eine komplizierte Aufgabe gewesen. Wenn diese Bearbeitungen in eine Moderations-Warteschlange hätten gestellt werden können, wären wir zuversichtlicher gewesen und hätten MapRoutlette in einigen Fällen möglicherweise gar nicht gebraucht.

Viele Entwickler wollten das gleiche Problem lösen, indem sie die Möglichkeit anboten, hilfreiche, aber anonyme Bearbeitungen in das Projekt aufzunehmen. Da OpenStreetMap jedoch voraussetzt, dass jede Änderung von einem einzelnen Nutzer vorgenommen wird und nicht von einer Firma oder einem Bot-Account, war die Einstiegshürde für Gelegenheits-Kartierer oft zu hoch.

OSMs Mangel an Ebenen

Die meisten geografischen Datenbanken verwenden einen mehrschichtigen Ansatz, um verschiedene Merkmale darzustellen. Eine Ebene kann die politischen Grenzen darstellen, eine andere das Straßennetz, eine dritte das Wasser und so weiter.

Anstelle der herkömmlichen Ebenen verwendet OSM eine einzige Ebene und dann Tags (Schlüssel/Wertpaare) für einzelne Objekte. Auf den ersten Blick scheint dies eine gute Idee zu sein, aber letztendlich führt es zu einem riesigen Durcheinander.

Werkzeuge sind schwieriger zu schreiben

Stellen Sie sich vor, wir wollten einen Editor für OSM schreiben, der nur mit dem Straßennetz arbeitet. Diese Aufgabe scheint einfach zu sein, da wir nur die Merkmale extrahieren müssten, die als Straße gekennzeichnet sind, wie z. B. highway=*. Leider ist es nicht so einfach.

Erstens muss ein Editor, der diese Straßenmerkmale bearbeitet, nicht nur die Straßen (Ways in der OSM-Terminologie) erfassen, sondern auch die Punkte (Nodes), aus denen diese Straße besteht. Zweitens kann die Straße, wenn sie besonders kompliziert ist, als Relation dargestellt werden. Die Bearbeitung auf diese Weise ist zwar zeitaufwändig, aber einfach zu handhaben.

Was nicht so einfach ist, ist die Tatsache, dass ein Merkmal wie eine Straße auch die Funktion eines anderen Merkmals, z. B. einer politischen Grenze, übernehmen kann, ebenso wie alle damit verbundenen Merkmale. Die Bearbeitung von Straßen kann versehentlich zu einer Änderung einer politischen Grenze führen.

Die Tatsache, dass Kartenmerkmale eine so radikal unterschiedliche Bedeutung haben, zwingt sowohl die Hersteller von Werkzeugen als auch die einzelnen Redakteure, die an OSM arbeiten, sich bewusst zu machen, dass jede Änderung, die sie vornehmen, Konsequenzen haben kann, die über das hinausgehen, was sie zu tun glauben.

Importe sind ohne Ebenen schwierig

Einer der Schlüssel zur Bewegung für freie und quelloffene Software ist die Wiederverwendung von Code, d. h. die Idee, dass man Software aus verschiedenen Quellen integrieren kann und dass sie nahtlos zusammenarbeitet. Man sollte meinen, dass dies auch bei geografischen Daten der Fall sein sollte, aber aufgrund des Fehlens von Ebenen ist es sehr schwierig, Daten in OSM zu importieren.

Ohne Ebenen ist es schwierig, eine bestimmte Region nach Merkmalen zu extrahieren und diese zu analysieren oder zu ersetzen. Stattdessen müssen die Daten aufgrund ihres komplexen Tagging-Systems als Ganzes analysiert werden. Importe sind möglich, werden aber ohne Ebenen erschwert, um die isolierte Datenanalyse zu erleichtern.

Fehlen von permanenten IDs

In jeder Datenbank haben Objekte ein ID-Feld, in der Regel einen numerischen Wert, nach dem der Datensatz gesucht werden kann. Das ist bei OSM nicht anders, und jedes Objekt in OSM hat ein ID-Feld. Leider repräsentieren die ID-Felder in OSM eher die Objekte der unteren Ebene als irgendein Konzept der oberen Ebene. Das schafft ein großes Problem. Ich werde diese Idee als „konzeptionelles Objekt“ bezeichnen und zeigen, wie problematisch das Fehlen dauerhafter IDs für diese Objekte ist.

Tiefer eintauchen

Um zu verstehen, warum das Fehlen von permanenten IDs ein Problem darstellt, müssen wir etwas tiefer in die Funktionsweise von OSM eintauchen. Während viele dieser Details den Rahmen dieses Artikels sprengen würden, möchte ich die Grundlagen der Informationsspeicherung in OSM vorstellen. Ein Punkt in OSM wird als Knoten bezeichnet, und jeder Knoten hat eine ID. Punkte können zu einer Linie zusammengefasst werden, und diese Linie wird als Weg bezeichnet, und Sammlungen von Knoten und Wegen können zu einem komplexeren Objekt kombiniert werden, das als Relation bezeichnet wird. Eine Relation kann auch andere Relationen enthalten. Knoten, Wege und Relationen haben alle ID-Felder.

Um dies zu veranschaulichen, denken wir an ein Gebäude, das Eigenschaften hat. Das Gebäude befindet sich an einem bestimmten Ort, es hat eine bestimmte Größe, Form und eine Adresse. Wenn es groß genug ist, kann es mehrere Adressen haben. Aber das Konzept des Gebäudes ist einheitlich. In OSM kann dieses Gebäude durch einen einzigen Knoten dargestellt werden, der die Adresse repräsentiert. Oder ein Gebäude kann durch eine Art Gebäudeumriss dargestellt werden, oder ein Gebäude kann durch eine Beziehung dargestellt werden, die Details der verschiedenen Gebäudehöhen, -ebenen und -dachtypen umfasst. Das Problem ist, dass es bei einer Suche keine direkte Möglichkeit gibt, nach dem Gebäude zu fragen. Stattdessen muss ich nach Aspekten des Gebäudes suchen, z. B. nach seiner Adresse oder seinem Standort.

Verlust der Historie

So seltsam es klingen mag, aber in OpenStreetMap ist es durchaus möglich, einen Knoten von einer Seite der Welt zu nehmen, ihn auf die andere Seite der Welt zu verschieben und ihn für etwas ganz anderes zu verwenden. Zum Beispiel ist es technisch möglich, einen Teil eines Hauses zu nehmen, ihn auf einen anderen Kontinent zu verschieben und ihn als Teil einer Straße zu verwenden. Das ist zwar höchst ungewöhnlich, aber nicht verboten. Wenn ich mir die Geschichte des Knotens ansehe, sehe ich, dass er sich bewegt. Dabei bleibt zwar die Geschichte des Elements erhalten, nicht aber die konzeptionelle Geschichte eines Objekts.

Wenn wir z. B. mit einer Darstellung eines Objekts beginnen, die das Gebäude als einzelnen Knoten darstellt, und dann zu einer komplexen Beziehung übergehen, spiegelt sich das nicht in der Objekthistorie wider, und somit gehen die Änderungen im Laufe der Zeit verloren.

Permanente IDs auf konzeptuellen Objekten könnten hier Abhilfe schaffen, indem sie eine Historie dessen liefern, was die Daten darstellen, und nicht nur die Daten selbst.

Importintegration

Neben anderen Problemen stellt das Fehlen einer permanenten ID für ein konzeptionelles Objekt in OSM die Herausforderung dar, Objekte in OSM mit Objekten in anderen Datensätzen zu verknüpfen. Wenn wir zum Beispiel eine Gebäudedatenbank von einer lokalen Behörde erhalten, hat jedes Gebäude in diesem Datensatz eine ID. Wir wollen diese ID mit unseren vorhandenen Objekten vergleichen. Leider haben wir dazu zwei Möglichkeiten: Entweder wir erstellen einen neuen Bezeichner (Schlüssel), mit dem wir die Zusammenführung vornehmen, oder wir müssen die ID des zweiten Datensatzes in OSM verwenden - beides ist keine optimale Lösung.

Es ist schwierig, Verbindungen zu anderen Datensätzen herzustellen

Keine Standards für die Datendarstellung

In OpenStreetMap gibt es im Projekt keine formalen Standards für die Darstellung von Merkmalen auf der Karte. Nehmen wir als Beispiel einen Gehweg. Bürgersteige sind auf einer Karte nützlich, weil sie uns zeigen, ob die Straße fußgängerfreundlich ist. Manchmal werden Bürgersteige durch ein Attribut auf der Straße selbst dargestellt. Manchmal werden Bürgersteige als eine Linie (Weg) dargestellt, die parallel zur Straße verläuft. Manchmal haben diese Wege den Namen der Straße als ihren eigenen Namen, und manchmal haben sie überhaupt keinen Namen.

Für Kartographen ist dies verwirrend, da es keine einheitliche Methode gibt, Dinge zu kartieren. Wenn Sie versuchen, Werkzeuge für die Arbeit mit OpenStreetMap zu entwickeln, ist es aufgrund der fehlenden Standardisierung der Daten im gesamten Projekt schwierig, damit zu arbeiten.

Es gibt einen informellen Prozess für die Datendarstellung, der hauptsächlich im Wiki stattfindet, aber da dieser nicht formell durchgesetzt wird und das massenhafte Ändern von Daten als eine Form von Vandalismus angesehen werden kann, sind die Datenkonsumenten gezwungen, Werkzeuge zu schreiben, die viele Darstellungen der gleichen Daten akzeptieren.

Die APIs werden nur langsam weiterentwickelt

Zum Zeitpunkt der Erstellung dieses Artikels ist die aktuelle offizielle OpenStreetMap-API 0.6. Die API-Version wurde seit 2009 nicht mehr verändert. Während eine stabile API eine gute Sache für ein ausgereiftes Softwareprojekt sein kann, ist dies im Fall von OpenStreetMap eher ein Zeichen für schlechtes Projektmanagement.

Eine API ist Teil eines Protokolls, das es entweder einem Client ermöglicht, mit einem Server zu kommunizieren, oder das es Servern ermöglicht, miteinander zu kommunizieren. In diesem Fall geht es um die Bearbeitungs-API von OpenStreetMap, die zwischen OSM und Bearbeitungssoftware verwendet wird.

Die OpenStreetMap-Bearbeitungs-API ist sehr leistungsfähig und vollständig, aber es gibt einige Design-Entscheidungen, die 2009 sinnvoll waren und in den neun Jahren seither weitgehend durch bessere technische Optionen ersetzt wurden. Dazu gehören kleine Änderungen wie das Format der Datenserialisierung, aber auch bedeutendere Änderungen wie die interne Datendarstellung.

Im Jahr 2012 wurden beispielsweise mehrere Vorschläge zur Schaffung eines neuen Datentyps namens Area gemacht, der die Darstellung bestimmter Arten von geografischen Merkmalen erheblich vereinfachen würde. Trotz dieser Vorschläge und des Angebots an technischer Hilfe hat das Projekt in dieser und anderen wichtigen technischen Fragen keine nennenswerten Fortschritte gemacht.

OSM hat versteckte Torwächter

In Anknüpfung an den vorigen Abschnitt müssen wir uns fragen, warum das Projekt nicht mehr technische Fortschritte gemacht hat, und die Antwort ist, dass die Schlüssel zum OSM-Schloss leider größtenteils nicht in den Händen der OpenStreetMap Foundation liegen, sondern in den Händen von ein oder zwei Personen, die als Torwächter für den Quellcode und die Infrastruktur des Projekts fungieren.

Es ist zwar nicht ungewöhnlich, dass ein Freie-Software- oder Open-Source-Projekt einen wohlwollenden Diktator auf Lebenszeit hat, doch werden diese Rollen oft durch eine formellere Struktur ersetzt, wenn die Bedürfnisse des Projekts wachsen. Im Fall von OpenStreetMap gibt es eine formale Einheit, die Eigentümerin der Daten ist, die OpenStreetMap Foundation. Aber gleichzeitig unterstehen die endgültigen Entscheidungen für die Website, die geografische Datenbank und die Infrastruktur nicht der direkten Kontrolle der Stiftung, sondern liegen größtenteils bei einer Person, die (obwohl persönlich freundlich) Veränderungen gegenüber skeptisch bis offen feindlich eingestellt ist.

Als ehemaliger professioneller Systemadministrator habe ich viel Verständnis für diese Art von Personen. Gleichzeitig müssen die Wünsche dieser Personen mit den allgemeinen Bedürfnissen des Projekts in Einklang gebracht werden, um Fortschritte zu erzielen und die Dynamik aufrechtzuerhalten, damit die Nutzerbasis zufrieden und engagiert bleibt.

Das ist hier nicht der Fall, und das ist zum Nachteil des Projekts.

Die Kultur der OpenStreetMap-Stiftung

Es wäre einfach, die OpenStreetMap Foundation (OSMF) mit der Wikipedia Foundation zu vergleichen, aber abgesehen von der Tatsache, dass sie die Inhaberin der freien Daten ist, werden die beiden Projekte völlig unterschiedlich geführt.

Die Wikipedia Foundation ist eine millionenschwere Organisation, die nicht nur Wikipedia verwaltet, sondern auch andere Projekte, wie die weniger bekannten Wikidata und Wikinews. Diese Projekte unterstützen die umfassende Aufgabe der Organisation, der Welt qualitativ hochwertige Informationen zur Verfügung zu stellen. Um dieser Aufgabe gerecht zu werden, gibt Wikipedia viel Geld für seine Infrastruktur aus und leitet und finanziert die Entwicklung neuer Tools, die die Gemeinschaft nutzen kann.

OpenStreetMap hingegen stützt sich in erster Linie auf gespendete Hosting-Dienste und kommt mit einem sehr geringen Budget aus. OpenStreetMap hat keine bezahlten Mitarbeiter und finanziert oder leitet die Entwicklung seiner Softwarebasis nicht.

Dies hat dazu geführt, dass einige Organisationen versuchen, die Sache in die Hand zu nehmen und die Situation zu verbessern, darunter eine von mir mitbegründete Organisation namens OpenStreetMap US, eine in den USA ansässige gemeinnützige Organisation, die sich auf die Förderung von OSM in den Vereinigten Staaten konzentriert. Eines unserer Ziele für die Organisation war es, die Lücken bei den Entwicklungs- und Kartierungsressourcen der OSMF zu schließen, was uns teilweise gelungen ist, aber aufgrund der Fragmentierung der Organisationen waren wir weniger erfolgreich als erhofft.

Zusätzlich zu OpenStreetMap US und anderen Chaptern auf der ganzen Welt gibt es das Humanitarian OpenStreetMap Team, dessen Aufgabe es ist, OSM in Entwicklungsländern zu fördern und die OSM-Gemeinschaft in humanitären Krisen zu mobilisieren. Es gibt keinen Grund, warum HOT eine unabhängige Organisation sein sollte, außer der mangelnden Bereitschaft der OSMF, ihre Rolle zu erweitern. Selbst Steve Coast, einer der Gründer von OpenStreetMap, hat dieses Problem erkannt und versucht, es mit seiner Organisation „Map Club“ zu lösen.

Die offensichtliche Frage ist, warum die OpenStreetMap-Führung die Positionen vertritt, die sie vertritt, obwohl die Notwendigkeit für Veränderungen offensichtlich ist. Meiner Meinung nach ist die Antwort der Kommerzialismus im Projekt, zusammen mit dem kulturellen Wunsch, das Gefühl der frühen Tage des Projekts zu bewahren.

Es gibt zwar Unternehmen, die um den Motor von Wikipedia (den Wikimedia Server) herum aufgebaut sind, aber es gibt nicht viele Unternehmen, die mit der Neuverpackung von Wikipedia Geld verdienen. OpenStreetMap hingegen hat ein kommerzielles Ökosystem um sich herum, das größtenteils aus dem Geschäft mit der Erstellung maßgeschneiderter Karten für Kunden stammt.

Viele der Gründer des Projekts, aber auch andere, haben kommerzielle Dienste rund um OSM gestartet. Leider schafft dies einen Anreiz, das Projekt klein und im Umfang begrenzt zu halten, um die Lücke mit kommerziellen Diensten zu schließen, die sie verkaufen können. Dies gilt auch für HOT, das ein finanzielles Interesse daran hat, Fördergelder für sich selbst zu erhalten und diese Mittel nicht in die OSMF fließen zu lassen.

Zu diesen Interessenkonflikten kommt der Wunsch der leitenden Mitglieder der Gemeinschaft, das Projekt in seinem Umfang klein zu halten. Sie sehen das Projekt als ein Projekt, bei dem es um Menschen und das Hobby des Kartierens geht, und wollen Importe oder andere Aktivitäten vermeiden, die den Eindruck erwecken könnten, dass der menschliche Faktor aus dem Projekt verschwindet. Sie sehen auch die Gefahren, die mit der Schaffung einer Organisationsstruktur verbunden sind, die Geld verlangt, und befürchten, dass dadurch ein ständiger Kreislauf entsteht, in dem man Spender finden muss, nur um eine Verwaltungsebene zu unterstützen.

Ich bin anderer Meinung und sehe das Fehlen einer aktiveren Struktur der OSMF als Ursache für die Stagnation des Projekts und den erheblichen kommerziellen Einfluss.

Die Welt hat sich verändert

Als OSM ins Leben gerufen wurde, hatten die Regierungen ihre Daten nicht unter freien Lizenzen freigegeben. Sie taten dies nur, weil OSM jetzt als Konkurrenz existiert. Aufgrund der von mir geschilderten Probleme sind OSM-Importe jedoch schwierig, und die Aktualisierung von Importen, sobald sie in OSM sind, ist fast unmöglich. Dies ist ein kritisches Problem für das Projekt.

Als OSM ins Leben gerufen wurde, waren auch Drohnen nicht billig und nicht verfügbar. Die künstliche Intelligenz war nicht in der Lage, Straßen visuell gut zu erkennen, und fliegende Autos waren noch Zukunftsmusik. Heute gibt es all diese Werkzeuge, und doch wird OSM immer noch weitgehend von Hand bearbeitet.

Wenn OSM sich ausschließlich auf manuelle Arbeit verlässt und nicht in der Lage ist, mit anderen Datensätzen zu arbeiten, wird die Datenqualität weiter sinken und das Projekt wird letztlich stagnieren und scheitern.

Nur die Stolpersteine

Es mag auf den ersten Blick so aussehen, als sei dieser Artikel eine umfassende Liste all dessen, was ich an OSM falsch finde. Das ist es aber nicht. Es gibt noch viel mehr Bedenken, die ich gegen das Projekt habe, aber ich habe meinen Artikel auf den Umfang der Bedenken beschränkt, die ich habe und die meiner Meinung nach den Fortschritt des gesamten Projekts aufhalten. Wenn (und nur wenn) das Projekt als Ganzes erfolgreich ist, wird es Zeit geben, die kleinen Probleme zu beheben. Wenn das nicht der Fall ist, werden die kleinen, pingeligen Probleme ohnehin irrelevant sein.

Ich hoffe aufrichtig, dass dieser Artikel ein Aufruf zum Handeln für OSM sein wird. Es gibt viele brillante und inspirierende Menschen in diesem Projekt. Wenn ich ein Wortspiel bin, dann hoffe ich, dass OSM wieder seinen Weg findet.