Über den Niedergang eines faszinierenden Projekts.
13 Jahre meines Lebens verschwendet! OSM entwickelte sich wie Orwells "Amimal Farm": Anfangs ein Projekt ausschließlich von lokalen Mappern mit GPS und Ortskenntnis, wird es nun beherrscht von kommerziellen Interessen und von Nichtsnutzen, die den ganzen Tag nur daheim vorm Computer hocken, von nichts eine Ahnung haben, aber glauben, sich mit zigtausend falschen "Korrekturen" profilieren zu können. Ortskenntnis und Expertenwissen werden nicht mehr geschätzt, ganz im Gegenteil: Das Abschreiben falscher Daten aus anderen Quellen wird vorgezogen. Damit muss das ganze Projekt als gescheitert angesehen werden, profitieren tun nur noch einige größere Firmen, die z.B. Handy-Apps um gutes Geld verkaufen und es so aussehen lassen, als wären die Daten von ihnen selber.
Steve Coast, der Begründer von OSM, designte die Datenstruktur bewusst simpel mit einfachen Key-Value-Paaren statt wie schon damals nach den grundsätzen einer relationalen Datenbank, also mit zusammenhängenden Tabellen. Als Grund gab er an, damit Neulingen das Beitragen neuer Daten möglichst einfach zu gestalten. Das hat bestens funktioniert. Doch es war von vornherein absehbar, dass mit zunehmendem Umfang und Komplexizität der Daten dieses einfache Design an seine Grenzen stößt. Es wäre nötig gewesen, nach dem Ausbrennen der ersten Stufe die nächste zu zünden, also zu einem bestimmten Stichtag das Tag/Value Design auf ein relationales umzustellen. Das wurde verabsäumt, sondern immer auf Abwärtskompatibilität geachtet. Das Ergebnis ist ein Moloch an Daten, die sich nicht zuverlässig auswerten lassen, ähnlich wie eine Kiste, in der alle Fotos aus einem Nachlass zusammengeworfen werden.
Genauer gesagt besteht OSM aus einer Reihe von Objekten, von denen jedes durch seinen Objekttyp, seine geografische Lage und seine Tags (die Key-Value-Paare) charakterisiert ist. Ein OSM-Objekt entspricht vordergründig einem Datensatz in einer normalen Datenbank, die Keys entsprechen den Datenbankfeldern (Spalten) und die Values den Feldwerten. Im Ggs. zu einer normalen Datenbank gibt es aber keine Tabellendefinitionen, sondern jeder Datensatz enthält eine undefinierte Ansammlung von Tags. Zum Auswerten ein Horror, weil man über komplizierte Entscheidungsbäume aus den Tags und der Kombination mit den anderen Tags erraten muss, welche Art von Kartenobjekt der Datensatz eigentlich abbilden soll. Mit einem Tabellennamen ist am ehesten der Objekttyp vergleichbar, und es gibt davon nur 3: Rode (Punkt), Way (Linie) und Relation. Nur einem Node sind direkt Koordinaten zugeordnet. Ways sind Serien von Nodes und dadurch indirekt georeferenziert. Relationen sind Zusammenfassungen beliebiger Objekte (Nodes, Ways, Relationen) und somit ebenfalls indirekt georeferenziert. Objekte, die gar nicht georeferenziert sind, z.B. Restaurantbetreiber, sind in OSM gar nicht möglich. Es kann also nur die ganze Latte an Tags, die den Betreiber betreffen, auf das Restaurant gesetzt werden. Wenn 10 Restaurants den selben Betreiber haben, kann diese Latte an Tags nur REDUNDANT auf jedes einzelne Restaurant gesetzt werden, also die selbe Information 10x an verschiedenen Stellen. Wenn jemand die Telefonnummer der Betreibers aktualsiert, wird er das nur bei einem der 10 Restaurants machen und die anderen übersehen. Darum werden solche Redundanzen unter Datenbankentwicklern normalerweise als absolutes No-Go angesehen. Ein Restaurant hat normalerweise nur einen Betreiber, ein Gebäude kann aber mehrere Architekten haben und dann hören sich solche Taggingorgien wie architect:wikidata=* sowieso auf. Als Ausweg bietet sich an, für jeden Betreiber, Architekten usw. eine Relation anzulegen, aber das funktioniert in der Praxis erst recht nicht, weil niemand, der in Wien die Daten eines Gebäudes erfasst, auf die Idee kommt, dass der Architekt schon für ein Bauwerk in Chile als Relation erfasst wurde. Die OSM-Editoren bieten für Relationen keine Suchfunktionen an.
Ein lange bekanntes Problem ist auch, dass es für Flächen keinen eigenen Objekttyp gibt. Eine Fläche kann entweder als Multipolygon-Relation erfasst werden, was in den meisten Fällen die Übersichtlichkeit im Editoren und die künftige Wartbarkeit unnötig verschlechtert. Oder als geschlossener Way, d.h. mit End- = Anfangspunkt. Ein geschlossener Way ist aber nicht automatisch eine Fläche, sondern die Interpretation hängt von den Tags ab. So bezieht sich landuse=* immer auf Flächen, nie auf Linien. barrier=* hingegen bezieht sich nur auf Linien. Darum ist es üblich, ein eine umzäunte Wiese mit landuse=meadow + barrier=fence zu taggen. Alle Programme, die diese Karten auswerten, brauchen aber hartkodierte Listen, welche Tags sich auf die Fläche und welche sich auf die Linie beziehen. Wenn nun ein drittes Tag hinzukommt, z.B. name=* oder start_date=*, können Programme nur noch raten (bzw. über hartkodierte Regeln Annahmen treffen). Bezieht sich start_date=* auf die Wiese, also die Fläche, oder auf den Zaun, also die Umrandung? Es ist undefiniert!
Diese Unklarheit, welche Attribute/Subtags (name=*, start_date=*, height=* usw.) sich auf welche Main-Tags (landuse=*, highway=* usw.) beziehen, wird um so schlimmer, je mehr Tags zusammenkommen. Es ist Gang und Gäbe, verschiedene Maintags auf das selbe Objekt zu setzen, z.B. building=yes + shop=supermarket + Adresstags. Was aber, wenn das Palais X die Kunstschule Y beherbergt? Oder: natural=peak + man_made=cross + tourism=viewpoint + ele=1234. Ist name=* dann der Name des Gipfels, des Berges, des Kreuzes oder der Aussicht? Es ist nicht definiert! Man kann die Objekte voneinander trennen und deckungsgleiche Nodes anlegen, aber viele Validatoren zeigen solche deckungsgleichen Nodes als "Fehler", und es dauert oft nur Stunden, bis ein Dummuser sie deswegen "korrigiert", meist indem er alle Nodes verschiebt und so das Kreuz in OSM plötzlich neben dem Gipfel steht.
Das komplizierte Zusammenspiel der Tags und die Notwendigkeit, für jede Kleinigkeit ein Objekt vom Typ Relation anzulegen, macht die Daten praktisch unwartbar und für Unerfahrene komplett unverständlich. Damit ist genau das Gegenteil erreicht von der von Coast beabsichtigten Einfachheit. Ich war wahrscheinlich der letzte Experte, der alle Tags noch manuell in deren vollständiger Kenntnis setzte. Fast jeder lässt heute Editoren übers Tagging entscheiden. Diese Editoren, die den Usern das Denken abnehmen, sind aber oft fehlerhaft, weil ihre Entwickler selber von Tagging nichts verstehen bzw. sich ihre eigenen Taggingregeln ausdenken statt den etablierten zu folgen.
In der Kartografie ist es selbstverständlich, dass jede Signatur in der Karte genau einem realen Objekt entspricht und umgekehrt. Genauso sollte es im Idealfall in OSM sein: Jedes reale Objekt wird auf genau ein Objekt (Node, Way, Relation) in der Datenbank abgebildet. Wenn sich nun aber eine Geschwindigkeitsbeschränkung nur auf einen Abschnitt einer Straße bezieht, dann wird die Straße an Anfang und Ende der Beschränkung geteilt (split). So wird aus einem Way (Linie) zwei oder drei. Ebenso bei Überholverboten, Fahrspuränderungen usw. Auch für Routenrelationen (Bus usw.) werden Straßen oft geteilt: Wenn z.B. eine querende Wanderroute um 5 m gegen die Einmündung versetzt ausmündet, muss die Straße an beiden Stellen geteilt werden. So werden Straßen mit der Zeit in immer mehr kurze Stücke zerlegt, oft hunderte oder womöglich sogar noch mehr. Das macht die Daten unwartbar, denn sobald man eine Eigenschaft ändert, muss man diese Änderungen an unzähligen Abschnitten durchführen, von denen viele so klein sind, dass man sie im Editor gar nicht sieht. Das führt zu immer mehr Datenfehlern bzw. Inkonsistenzen. Ein weiterer Nachteil der Fragmentierung ist, dass Anwender, die nach einem Straßennamen suchen, nicht die eine komplette Straße angezeigt bekommen, sondern eine Liste von hundert winzigen Straßenstückchen als Suchergebnis gelistet bekommen.
Diese Probleme ließen sich mit Multilinestring-Relationen ganz wesentlich reduzieren. Genauso würden AddrN-Relationen, Cluster-Relationen usw. viele Probleme beseitigen. Nur werden diese Lösungen von jenen, die über OSM bestimmen, abgelehnt, weil ihnen, wie schon im ersten Abschnitt dieses Textes erwähnt, teils die Kompetenz, teils das Interesse an Lösungen fehlt. Als Grund für die Ablehnung wird meist genannt, dass die Relationen nicht von bestehenden Renderern/Routern/Editoren/Nominatim unterstützt werden. Nach dieser Argumentation dürfte es weder Straßen noch Autos geben, denn Autos dürften erst dann gebaut werden, wenn es die Straßen schon gibt, und Straßen dürften erst dann gebaut werden, wenn es die Autos schon gibt. Wenn sich etwas verbessern soll, muss irgendwo der Anfang gemacht werden, und das ist in OSM ganz klar der Datenbestand. Anwendungen müssen sich nach den Daten richten und nicht umgekehrt. Wegen der Vereinnahmung von OSM für kommerzielle Interessen ist dieses Verhältnis auf den Kopf gestellt, und nötige Verbesserungen an der Datenstruktur finden nie statt. Diese Änderungen hätten möglichst früh umgesetzt werden sollen, denn je länger man damit zuwartet, desto aufwendiger werden sie, weil die Daten immer mehr werden. Der Aufwand wird nun aber als weiterer Vorwand genommen, die Änderungen abzulehnen, mit dem Ergebnis, dass sie NIE passieren. So versinkt der OSM-Datenbestand unaufhaltsam im Chaos.
Wie im vorigen Absatz schon angeschnitten, kümmern sich Editor-, Validator- und Renderer-Entwickler wenig um bestehende Regeln. Sie machen sich ihre eigene Regeln und zwingen sie den Usern auf. Wo ein Editor einen Fehler anzeigt, wird der User die Daten nach den Empfehlungen des Editors ändern. Mit einer Armee von tausenden auf diese Weise ferngesteuerten Usern kann ein Editorentwickler in kurzer Zeit das Umtaggen von Millionen Objekten in der Datenbank erreichen. Am Ende nimmt er die veränderte Tagstatistik als Vorwand um auch die Definitionen im Wiki nach seinem Geschmack zu ändern.
Ich kam zu OSM in einer Zeit, als neue Tags noch das Ergebnis von Diskussionen unter vielen Usern waren, von denen jeder sein Expertenwissen einbrachte. Es gab einen komplizierten Proposalprozess mit Diskussionsphasen und Abstimmungen, und ich habe selber unzählige Proposals erstellt und einige durchgebracht. Darum konnte ich es kaum fassen, wie ungeniert immer mehr User das Wiki ohne eine Diskussion umschreiben und so gut wie immer damit durchkommen.
Am beliebtesten ist es, selbsterfundene Tags auf Status "de facto" zu setzen, obwohl sie es gar nicht sind, und Proposals anderere User auf "abandoned" zu setzen, obwohl sie es gar nicht sind.
Aber auch Umdeutungen und Zweckentfremdungen etablierter Tags nahmen überhand. So wurde access=*, das ausschließlich für Berechtigungen vorgesehen war und nicht für physische Restriktionen, ohne eine Diskussion für das Offenstehen von Toren und Schranken eingeführt und von Editor-Entwicklern dort sogar verpflichtend gemacht. Genauso wurde access=destination, per Definition und wie das Wort schon sagt Zielverkehr, im deutschsprachigen Wiki auf Anrainerverkehr erweitert, was aber etwas ganz anderes ist. Meine genauen Erklärungen im Wiki und in den Foren gingen in der Ignoranz anderer User unter. Am schlimmsten war aber die putschartige Zweckentfremdung von highway=living_street für Begegnungszonen. Ein einzelner User hatte sich das in den Kopf gesetzt und in der Mailingliste Talk-AT eine Abstimmung gestartet. Die ging aber umgekehrt aus als erhofft, weil Begegnungszonen rechtlich etwas ganz anderes sind als Wohnstraßen und ein spezielles Tagging für Begegnungszonen in OSM gar nicht nötig ist, weil im Prinzip die selben Verkehrsregeln gelten wie auf normalen Straßen. Trotz verlorener Abstimmung gab der User nicht auf, sondern fing eine Diskussion in einem anderen Forum an, wo er die Abstimmung verschwieg und den Mangel an Widerhall als Rechtfertigung nahm, um gemeinsam mit einem anderen User alle Wohnstraßen in Österreich heimlich umzutaggen. Dieser andere User war ein Neuling ohne Kenntnis der StVO, ohne Führerschein, nicht mal radfahren konnte er. Dennoch reagierte er auf meine Hinweise präpotent und verweigerte einen Revert. Die Begegnungszonen sind also bis heute alle falsch getaggt.
Am Anfang war die Erde wüst und leer. OSM ebenso. Jeder, der etwas in OSM einzeichnete, konnte OSM damit nur besser machen (sofern die Daten nicht frei erfunden waren). Je größer der Datenbestand wird, desto mehr wird an bestehenden Daten verändert. Diese Abänderungen sind nicht immer Verbesserungen. Es wird irgendwann ein Zustand erreicht, in dem sich die Verbesserungen und Verschlechterungen die Waage halten. Ein erzwungenes Mittelmaß. Ihr könnt euch vorstellen, dass Mozarts Kompositionen keine Meisterwerke bleiben, wenn jeder sie abändern kann. Jede Mozartkomposition wird am Ende zu einem mittelmäßigen Hiphopsong, der sich anhört wie tausende andere auch.
Die Wikipedia schränkte deswegen das Editieren durch normale User ein. Jeder Edit muss erst von einem erfahrenen User überprüft ("vidiert") und freigegeben werden. So werden Regelverstöße und offensichtliche Verschlimmbesserungen ausgeschlossen. In OSM wurde ein solches Qualitätsmanagement nie eingeführt. Jeder User kann von jedem anderen User erfasste Daten nach Lust und Laune verbessern, verfälschen oder ganz löschen.
Insbesondere hat jeder anonyme Anfänger genau die gleichen Rechte wie erfahrene User, die seit 15 Jahren an OSM mitarbeiten, zigtausende Edits beigetragen haben und tausende Stunden mit Lesen von Dokumentation und Diskussionen verbracht haben.
Besonders ärgerlich ist es, wenn man als erfahrener User von solchen Anfängern hochnäsig "belehrt" wird, aber die meisten antworten gar nicht, wenn man sie anschreibt. Von sich aus angeschrieben hat mich ein ein Anfänger noch nie, soweit ich mich erinnern kann.
Es ist ungefähr so, als würden Mittelschüler glauben, Universitätsprofessoren belehren in ihrem Fach zu können. Wobei – Greta Thunberg machte genau das, und die Öffentlichkeit hält sie für kompetenter als die Professoren. Also insofern entsprechen die Zustände in OSM nur dem Zeitgeist.
Ich bin kein Fan verstauber Benimmregeln (Messer in linke Hand...), aber ein grundsätzliches Gefühl des Anstands sollte doch jeder haben, oder bin ich mit meiner christlichen Erziehung ein Fossil? Wenn mich jemand etwas fragt oder um etwas bittet, empfinde ich es als Selbstverständichkeit, darauf zu antworten. Das erwarte ich auch umgekehrt, wenn ich jemanden anschreibe. Die meisten tun das jedoch nicht. Das ist nicht nur in OSM so, sondern ein generelles Phänomen der heutigen Zeit. Wenn ich solche Leute persönlich treffe, lügen sie mich an und behaupten, meine Anfrage nicht erhalten zu haben. Sie sagen nur: "Schick es nochmal!" Wenn ich das tue, antworte sie wieder nicht.
Im realen Leben würde niemand auf die Idee kommen, das Auto seines Nachbarn umzulackieren, schon gar nicht ohne sein Einverständnis. Auch in OSM finde ich es angemessen, einen Mapper, vor allem wenn er ein Objekt vor Ort erfasst hat und bekannt dafür ist, sich mit Taggingregeln auszukennen, erst mal anzuschreiben, bevor man ohne Ortskenntnis das Objekt verändert oder sich gar eine "Korrektur" anmaßt. Ich habe schon unzählige Mapper angeschrieben mit Kritik oder Verbesserungsvorschlägen, oder auch einfach aus Interesse um mehr über das Objekt zu erfahren. Mich hingegen schreibt fast nie jemand an. Ständig verpfuschen andere User meine Arbeit ohne mich vorher zu fragen.
Ich denke, dass viele OSM-User, vor allem solche, die sehr viel Zeit dafür aufwenden ohne selber im Gelände zu mappen, autistische Züge aufweisen und das Mappen sowie das Beheben von Fehlern wie ein Computerspiel betreiben. Für sie besteht die Welt nur aus ihnen selbst und dem Editor/Validator. Dass die Daten von anderen MENSCHEN, oft mit gehörigem Expertenwissen, erarbeitet wurden und diese vorher gefragt werden möchten, kommt den Autisten nicht in den Sinn und sie wollen es nicht wahrhaben. Sie bleiben lieber in ihrer geschützten, nur von ihnen selbst kontrollierten Traumwelt.
Jetzt (Stand März 2024) ist bald ein Jahr vergangen, seit ich nichts mehr mappe. Ich habe von einem auf den anderen Tag aufgehört, ohne es irgendwo zu verlautbaren. (Viele kündigen es großmaulig an, können es aber dann doch nicht lassen und editieren bald wieder massenhaft herum. Ich finde das lächerlich. Wenn ich etwas tun will, dann verblase ich keine heiße Luft, sondern tue es. Und wenn mich vor einem Regen in der Au hunderte Gelsen stechen, dann schreie ich sie nicht an, dass ich sie verlassen werde, dann nachtrauern werden sie mir sowieso nicht, geschweige ihre Taten bereuen oder ihr zukünftiges Verhalten ändern.)
Trotzdem ist vielen bald aufgefallen, dass ich nicht mehr mappe. Sofort fingen sie an, alles von mir umzutaggen (wenn die Katz aus dem Haus ist...). Aber was man sich in einer Gemeinschaft erwarten würde, ist nicht passiert. Mich hat KEIN EINZIGER angeschrieben und gefragt, warum ich aufgehört habe oder wie es mir geht. Ich hatte schon vor Jahren meine Krebserkrankung in meinem Profil kundgetan, es wusste also jeder davon und musste sich Sorgen machen, dass ich aus gesundheitlichen Gründen aufgehört habe (was auch tatsächlich mit ein Grund war) oder dass ich womöglich sogar gestorben bin. Tatsächlich interessiert es niemanden, bzw. vielen wäre mein Ableben sogar sehr recht, weil ich ihnen dann nicht mehr widersprechen kann.
Es hat mich auch niemand etwas Inhaltliches gefragt, z.B. warum ich etwas so oder so getaggt habe, oder ob ich weiterführende Auskunft über diesen Gebirgssteig oder jene Höhle geben kann, oder mich um Rat gefragt, wie man etwas mappt oder wie man im Gelände die Daten aufnimmt. NIEMAND ist interessiert, etwas zu erfahren, zu lernen, sich weiterzuentwicklen. Die heutigen OSM-Mapper sitzen nur noch vor ihren PCs und versuchen von dort aus die Welt zu bestimmen, ohne selbst irgendwelche Informationen aufzunehmen. Übersteigertes Ego ersetzt fehlendes Wissen.
Die OSM-Daten standen ursprünglich unter CC-BY-SA, wurden 2012 aber unter heftigen Kontroversen auf ODbL geändert. Die Änderung machte ein "redaction bot". Er löschte alle Daten der User, die der neuen Lizenz nicht zugestimmt hatten – teils weil sie nicht wollten, teils weil sie davon gar nichts wussten oder womöglich sogar schon verstorben waren. Die Begründung für die Umstellung war, dass CC-BY-SA für Datenbanken nicht anwendbar sei und die ODbL alle Probleme löse. Niemand las sich die neue Lizenz durch, weil niemand das "Legalese" verstand, schon gar nicht in der aufgeblähten Vollversion der Lizenz. Es gab aber so eine Art Standardinterpretation, dass jeder die Daten für alles verwenden darf, aber mit Lizenz- und Namensnennung.
Als Namensnennung war zunächst üblich sowas wie © OSM contributors, denn keiner konnte die Namen tausender Mapper, deren OSM-Usernamen fast ausschließlich Pseudonyme sind, recherchieren, geschweige in einen Kartenausschnitt hineinschreiben. Später wurden die contributors meist weggelassen, also nur noch © OpenStreetMap. Heute wird auch das meist weggelassen oder so versteckt, dass es niemand sieht, der nicht gezielt danach sucht. Wo kein Kläger, da kein Richter.
Diese Namensnennung ist aber sowieso nur dort vorgeschrieben, wo auf größere Datenbestände zugegriffen wird, wie eben in "slippy maps". Denn – was viele nicht wissen – die ODbL sieht die Verpflichtung zur Nennung von Urhebern und Lizenz nur für die Datenbank als ganzes vor. Die einzelnen Daten stellt die ODbL automatisch unter die DbCL, und diese ist gleichbedeutend mit Gemeinfreiheit (public domain). D.h. jeder kann die Daten beliebig verwenden oder wiederveröffentlichen OHNE die Herkunft anzugeben. Es darf also jeder die Daten als seine eigenen ausgeben.
Während die Lizenz auf Datenebene viel zu lasch ist, schießen auf Datenbank-Ebene die Lizenzbedingungen übers Ziel hinaus. Wer nämlich eine unter ODbL stehend Datenbank in eine andere integriert, z.B. die Geodaten aus OSM in eine Kundendatenbank, muss diese andere Datenbank ebenfalls als ganzes unter ODbL stellen. Das ist so gut wie nie möglich. In der Praxis wird diese Bedingung der ODbL deshalb immer ungeniert ignoriert. Wie gesagt: Wo kein Kläger, da kein Richter. Und was keiner weiß, macht keinen heiß.
Defacto ist die ODbL witzlos und die Daten sind eigentlich public domain, also ohne urheberrechtlichen Schutz.