Ich kann mich seawolff nur anschließen. Ich bin zwar erst 2 Monate nach ihm zu OSM gestoßen :-), aber es geht mir im Prinzip genauso: Am Anfang war ich sehr aktiv und begeistert dabei, habe viel mitdiskutiert und versucht neue Tags zu etablieren und bestehende Probleme zu lösen. Mittlerweile habe ich in weiten Teilen kapituliert. Ich ergänze weiterhin fehlende Wege oder korrigere nicht zutreffendes Tagging, wenn ich im Gelände unterwegs bin. Im Forum betätige ich mich zwar als Mod, aber schüttle meistens nur noch für mich den Kopf wenn die gleichen Diskussionen seit 2008 immer wieder hochkommen (Spitzenreiter ist glaube ich „Radweg“), jedes mal ohne Ergebnis.
Es werden zwar immer mehr Dinge erfaßt, aber ich beobachte auch daß die Qualität und vor allem die Nutzbarkeit der OSM Daten stetig schlechter wird. Nachdem ich mich als Informatiker beruflich mit Datenstrukturen auseinandersetzen darf und die Regeln für meinen eigenen Kartenserver von Null aufgebaut habe und ständig pflegen muß, denke ich daß ich ein ganz gutes fachliches Verständnis dafür habe. 2008 war ich total idealistisch von der Idee begeistert, an einer freien Geodatenbank für Alle mitzuarbeiten – aber OSM ist nur noch mit sehr viel Fachwissen und Erfahrung auswertbar. Ich mußte selbst auch schon mehrfach als Berater tätig werden, für Firmen oder auch in den Anfängen des Graphhopper Projekts, die an dem oftmals chaotischen, unlogischem Tagging und lückenhaften, widersprüchlichen und unzuverlässigen Wikieinträgen erst mal verzweifelt waren.
Genau das ist das Problem: OSM ist immer weniger eine für Kartographie geeignete Geodatenbank und wird immer mehr zu einer schlecht strukturierten Detaildatensammlung. Dabei geht es gar nicht darum, wie detailliert man persönlich mappen will, was „wichtig“ ist oder „in die DB reindarf“. Die Datenbank ist eigentlich groß genug für alles.
**Das Problem sind die mangelhaften Strukturen, die es immer schwerer bis unmöglich machen, die notwendigen Informationen für einen bestimmten Abstraktionslevel wieder mit vernünftigem Aufwand und vernünftiger Zuverlässigkeit aus der Datenbank herauszulesen.
**
Ein Beispiel für eine gut auswertbare, logische Struktur (die bis vor kurzem noch so funktioniert hat) wäre z.B.
- Level 1 tourism=information: Ein Renderer kann global entscheiden ob er diese Klasse von Objekten anzeigen will oder nicht. Alle Objekte sind „gleich groß/wichtig“ (Infopoints, Wandertafeln) und können sinnvoll mit einem (i) dargestellt werden.
- Level 2 tourism=information + information=office, hikingmap, citymap, etc.: Ein Renderer hat Regeln um bestimmte Objekte mit unterschiedlichen Icons anzuzeigen
- Level 3 tourism=information + information=hikingmap + name: Ein spezialisierter Renderer wertet auch noch die Detailinfos aus
Diese Struktur wurde vor Kurzem zerstört, als mit den zusätzlichen Werten information=route_marker und information=trail_blaze plötzlich einzelne Wanderschildchen unter dem gleichen Haupttag hinzukamen, die von Größe, Anzahl und Darstellung nicht zu Infobüros und Hinweistafeln passen. Dadurch funktioniert eine Level1-Auswertung nicht mehr, jeder Auswerter ist gezwungen, eine Level2 Auswertung zu machen und die unpassenden Werte wieder herauszufiltern, ansonsten ist z.B. eine Level1-Karte windpockenartig mit sinnlosen (i)s überflutet. Und natürlich muß der Auswerter erst mal von dieser Besonderheit wissen, denn logisch ist es ja nicht und bis letztes Jahr hat es noch einfach funktioniert.
Leider gibt es eine Vielzahl von solchen Verschlechterungen in der Datenstruktur, die in Summe die Latte für einen Auswerter verdammt hoch legen und ständige Aufmerksamkeit und Nachpflege erfordern – und dazu schon immer ungelöste Probleme. Hier nur ein paar Beispiele, die mir spontan einfallen:
- zum Haupttag inkompatible Erweiterungen von subtags wie im Beispiel oben
- willkürliche Umdefinition und Verkomplizierung von Tags im Wiki z.B. Höhenangaben genormt in WGS84 anstatt dem allgemein üblichen (und vorher auch im Wiki verankerten) Meter über Normal Null. Stellt alle Höhenangaben in Frage, zum Glück nur mit geringer praktischer Abweichung.
- nachträgliche Umdefinition bestehender Tags. z.B. natural=tree von „Signifikanter Baum“ auf „irgendein Baum“. Dabei gingen 50000 größtenteils signifikante Bäume ohne weiteres Tagging von 1500 Usern einfach zwischen den massenhaft importierten unbedeutenden Bäumen verloren
- fehlende Klassifizierung: Objekte werden zwar mit jeder Menge Level3 Detailtags eingetragen, aber es fehlen Level1 und Level2 Tags mit einer Klassifizierung für eine kartographische Abstraktion
- Negation des Haupttags in einem Detailtag. z.B. amenity=restaurant, disused=yes. Erzwingt eine Level3 Auswertung von allen Auswerten, führt zu falscher Anzeige von ungültigen Objekten bei allen Auswertern die nur eine Level1 Auswertung benötigen/machen.
- unnötig komplexes Mapping: wer mag kann die Datenbank mit unnötiger Komplexität für andere user unbearbeitbar und extrem schwer auswertbar machen. z.B. Multipolygone wo einfache Polygone ausreichend wären, Zerstückelung durchgehender ways um sie an MPs zu kleben
- unscharfe und mehrdeutige Tags: z.B. highway=path, bicycle=yes Das kann ein 2 Meter breiter, gut befestigter Spazierweg sein (nur ohne blaues Schild) oder ein handbreiter Trampelpfad im Gelände. Workarounds über zusätzliche Tags wie Wegbreite funktionieren nicht, da sie aufwändige Spezialauswertungen erzwingen und die nötigen Zusatztags nur selten verwendet werden.
- mangelndes Bewußtsein für die Probleme: Für das obige Problem wurde schon vor langer Zeit das Tag highway=trail vorgeschlagen, das Trampelpfade eindeutig gekennzeichnet hätte und die Verwechslung mit dem (unglücklich gewählten) path beendet hätte. Es konnte sich aber nicht durchsetzen.
- fehleranfällige Taggingempfehlungen und daraus resultierende Fehler: z.B. ist im Wiki immer noch das Schema access=no, bicycle=yes dokumentiert. Das ist fast immer falsch, da alle nicht ausdrücklich erwähnten Verkehrsteilnehmer verboten werden und die “exotischeren” angefangen beim Reiter meist vergessen werden.
- unzureichende API. Die Wirklichkeit ist komplizierter als es sich mit ways und nodes abbilden läßt. Die API wurde nie dahingehend weiterentwickelt, daß sie z.B. echte Polygone und Multipolygone unterstützt. Polygone ergeben sich nicht aus der Geometrie, sondern manchmal aus dem Haupttag, manchmal nur in Kombination mit dem Subtag area=yes. Multipolygone werden als Dauer-Workaround als relations dargestellt - eine weitere unnötige und unerwartete Stufe der Komplexität bei der Auswertung und eine große Hürde für neu eingestiegene Mapper.
Das ist eine sehr gute Frage - und ich fürchte es gibt auch hier keine Einigkeit.
Ich bin der Ansicht daß das freie Taggen von OSM eine super Idee war als es galt, gigantische weiße Flecken zu füllen und eine vage Information besser war als gar keine Information. Aber ab einer gewissen Datenmenge, Datendichte und Komplexität bräuchte man verbindliche Regeln und eine durchdachte Struktur um sich weiter zu verbessern. Ansonsten werden die Daten zwar noch mehr, aber gehen auch wieder kaputt und werden schlechter nutzbar. Auch für neue Mapper wäre es bedeutend einfacher, ein paar feste Regeln zu lesen als lange Diskussionsthreads ohne Ergebnis.
Aber als Resultat vieler Diskussionen mußte ich mich damit abfinden daß verbindliche Regeln bei OSM nicht mehrheitsfähig sind. Ich würde erwarten daß vielfach wieder die Antwort kommt “Es gibt doch gar kein Problem”. Es ist auch zu berücksichtigen, daß OSM ein globales Projekt ist, in dem es auch Politik zwischen verschiedenen Ländercommunities gibt.