Einleitung
Zuletzt habe ich in OSM markante POI mit verschiedenen Social-Media-Tags ergänzt. Dass diese sinnvoll sein können, zeigen Apps wie Osmand und Magic Earth die z.B. Telefonnummer, Website auswerten und Osmand auch andere Tags wie contact:facebook auswertet und innerhalb der App verlinkt. Im mobilen Einsatz ist es sehr bequem, wenn diese Tags gesetzt sind, da viele Handys appbasiert am effektivsten arbeiten.
Nun ist es ja bekanntlich so, dass viele Geschäfte inzwischen nur noch eine Facebook-Website besitzen, also kommt man um facebook ohnehin nicht umhin. Andere Tags wie twitter, youtube oder alle sonstigen wie vimeo, pinterest oder instagram habe ich gleich mitgesetzt. ## Status quo Während ich in Magic Earth nach POI wie “Flughafen Dresden” suchte, sah ich, dass dieser nur absolut stiefmütterliche Tags besitzt, nicht einmal eine postalische Adresse. Auch andere Gebäude haben durch das Taggen der Nummer auf den Eingang nicht einmal eine postalische Adresse. Die Datenqualität in OSM kann nur als dürftig beschrieben werden.
Klar kann sich nun der OSM-Mapper hinsetzen, aber das kann ja nicht Sinn der Sache sein tausende POI händisch nach Updates zu untersuchen. Bei unserem Konkurrenten google ist es z.B. so, dass jeder User die Fehler in den Daten melden kann. Bei OSM ist das nur über openstreetbugs möglich. Aber sein wir ehrlich: openstreetbugs ist nur für Leute gedacht, die überhaupt verstanden haben was OSM ist, nicht für App-Benutzer, die vielleicht gar nicht wissen, was OSM ist. Bereits das Beispiel MapDust von skobbler zeigte, wie die Nutzer mit unsinnigen Fehlermeldungen das System fluten können. # Anforderungen Was braucht OSM also? Unter höchstmöglicher Produktivität stelle ich mir das folgendermaßen vor: OSM erstellt eine Bug-API die alle Apps nutzen können. Der User kann dann in der App jegliche Tags, z.B. das Feld “Website” oder “contact:facebook” usw. als fehlerhaft melden. Dann hat er verschiedene Meldegründe:
- Wert überprüfen: “Website lässt sich nicht öffnen” (würde den Grund dafür optional lassen, gibt OSM aber Möglichkeit nachzugucken, ob etwas noch stimmt)
- Wert ändern: Seite umgezogen -> Eingabe der neuen Seite
- Wert hinzufügen: Eingabe der Seite
- Wert löschen: Website existiert nicht mehr (z.B. geschlossen) –> im Endeffekt hat der Nutzer so die Möglichkeit, jeden Tag als “überprüfen”, “hinzufügen”, “löschen” oder “ändern” zu markieren und dazu einen neuen Wert sowie Kommentar zu hinterlassen.
Zusätzlich muss der App-Lieferant zusätzlich 3 Tags zu jeder Fehlermeldung protokollieren:
- Den App-Lieferant (da schlecht designte Apps u.U. uns mit Bugs überfluten, wo sich die Benutzer über die App auslassen o.ä.)
- Die App muss uns eine anonyme unique User-ID liefern, damit wir die Validität der Datenlieferanten einschätzen können und Spammer blocken können
- Die ID des zu bearbeitenden Objekts (Relation, Way, Node)
Bearbeitung durch Mapper
Nun sind diese Daten im OSM-Bug-System. Sie sollten aber nicht nur einfach dargestellt werden, wie das bei MapDust oder openstreetbugs der Fall ist, sondern aufgrund der zu erwartenden hohen Fehlerzahlen, muss die Verarbeitung verbessert werden. Da der Datenlieferant uns die Daten bereits auf das konkrete bezogene Objekt und die zu ändernden Daten bringt, wird es für den versierten OSM-Mapper einfach, indem er in einer Web-Oberfläche entscheidet: Im Grunde hat der OSM-Mapper 4 Möglichkeiten:
- Bug-Mängelmeldung übernehmen: Nach einem Klick auf “übernehmen” werden die vorgeschlagenen Änderungen instant in die Datenbank gebracht (vorher hat der Mapper noch Möglichkeit, selbst kleine Änderungen an Tags vorzunehmen (z.B. Websiteangabe normieren))
- Bug-Mängemeldung ablehnen: Die Bug-Meldung wird geschlossen, es werden keine Änderungen vorgenommen (optional Kommentar)
- Bug-Mängelmeldung selbst übernehmen: der Mapper öffnet selbst einen Editor und ändert das Objekt, danach ist der Bug geschlossen (wenn komplizierter Sachverhalt)
- Bug-Mängelmeldung benötigt lokales Wissen/Vor-Ort Besichtigung: Der Bug ist nicht geschlossen, aber er wurde bereits durch einen Mapper erfolgreich anfangsgeprüft. (So können wir gewähren, dass VorOrt-Bugs die lange rumliegen können, unser System nicht verstopfen und wir neue Bugs trotzdem filtern können)
Schluss
Das ist mein Vorschlag, er würde OSM extrem in der Breite verbreiten und anschließend eine effektive Abarbeitung ermöglichen sowie sogar Spezial-Apps eine Möglichkeit geben, bestimmte Dinge flächendeckend durch User einzutragen lassen. Durch die Kennzeichnung des App-Lieferanten könnten Spezial Mapper (z.B. Eisenbahninfrastrukturmapper) durch Filterung sich extra dieser Bugs annehmen. Sicher muss man an der einen oder anderen Stelle noch etwas verfeinern, aber das wäre das Grundprinzip.
Comment from MarkusHD on 9 January 2016 at 21:48
Wann warst du das letzte mal auf OpenStreetBugs? Die Seite ist offline und wurde schon vor über 2 Jahren durch OSM Notes abgelöst.
Comment from monotar on 9 January 2016 at 22:42
Ja, ich meine natürlich OSM Notes
Comment from SimonPoole on 10 January 2016 at 11:40
Ich kann mich nur MarkusHD anschliessen irgendwie hast du die letzten 2 Jahre verpasst, OSM Notes erlaubt essentiell alles was du forderst und es gibt auch genügen Apps die die API unterstützen. D.h. nicht das es an der Notes API nichts zu verbessern gäbe, aber das ist eher im Detail als grundsätzlich.
Du kannst auch falls du das Gefühl hast gewisse Tags fehlen oft einen entsprechenden TEst für OSMOSE vorschlagen (aber vermutlich gibts den eh schon).
Comment from monotar on 10 January 2016 at 16:21
Ohne mich eingelesen zu haben zu der API, sehe ich aber als Notes-Bearbeiter nicht, dass wir gerade viel Feedback kriegen oder dass für mich als Bug-Bearbeiter die Sacher anders läuft als es zu openstreetbugs-Zeiten war? Allein die Anzahl der MapDust-Bugs übersteigt die OSM-Notes bei mir um ein weites. Dass wir nicht viel Feedback kriegen liegt doch sicher daran, dass Apps wie Osmand Notes nur über Zusatzplugin ermöglichen (wie ich gerade gelesen habe, war mir als osmand-Benutzer zuvor auch nicht bewusst), sodass es dann nur OSM-Profis nutzen die wissen was sie wollen. Ich vermute das wird doch für die Allgemeinheit deshalb nicht freigeschalten, weil dann wirklich die unkoordinierte Spam-Welle kommt. Auf der DE-Notes Wikiseite steht doch auch: “Bitte keine Hinweise automatisiert eintragen.” - Tja, damit sind alle Apps weg vom Fenster für OSM-Notes - und damit für OSM die dringend benötigte breite Userbasis.
Die OSM-Notes sind nach meinem Verständnis nicht mit einem konkreten Objekt verknüpft, sondern nur Text-Meldungen, die an eine GPS-Position gegeben werden. Bei Seiten wie Google und Facebook läuft es halt viel einfacher: Man kann Änderungen an Tags jederzeit konkret vorschlagen und nach Prüfung werden diese übernommen. Das ist für mich der zentrale Punkt: simplicity erzeugt bessere Daten, das verstehen diese 2 Firmen wie keine andere. Die Realität z.B. bei Öffnungszeiten ist halt, dass man diese heute lieber bei Facebook als bei OSM nachschaut.
Osmose kannte ich bisher nicht. Es zeigt mir das Problem auf, dass selbst ich als langjähriger Mapper viele Dinge nicht kenne, die eigentlich auf die Hauptseite neben OSM-Notes integriert werden sollten, die Fragmentierung ist ein ernsthaftes Problem. Ich habe vor kurzem das Leipziger Messegelände geprüft. 2008 wurde eine Website eingetragen, 2016 ist sie nicht mehr erreichbar. Wie viele Jahre schon, weiß niemand. Ob den Fehler schon einmal jemand in einer App bemerkt hat? Sicher, dieser POI wird bestimmt immer mal angewählt, aber gemeldet oder korrigiert hat ihn niemand. Osmose scheint website auch nicht zu prüfen, schade.
Comment from MarkusHD on 11 January 2016 at 10:20
Ich glaube nicht, dass die geringe Anzahl an Hinweisen, wie ich es auch in meiner Gegend empfinde, auf die Notes-API zurückzuführen ist, sondern eher auf die Integration in Anwendungen. Oder es gibt tatsächlich zu wenige Lücken oder Fehler in den von den Anwendern am häufigsten genutzten Daten (Adressen, POI-Namen), mit Sicherheit werden viele Details aus den Daten einfach nicht verwendet. Ich verstehe deine Schlussfolgerung auch nicht: Was hat automatisiertes Eintragen von Hinweisen mit Apps zu tun? Über Apps, die die Notes-API unterstützen, kann manuell vom Anwender ein Hinweis erstellt werden. Das schreibst du doch selbst über OsmAnd.
Ich habe mir gerade verschiedene Hinweise in meiner erweiterten Umgebung angeschaut. Die wenigsten ließen sich auf reine Anpassung von Tags beschränken und oft sind die richtigen Tags dann nicht angegeben. Viele Hinweise sind allgemeiner gefasst und erfordern ein Anpassen der Geometrie, Anlegen von Objekt(en) oder Bearbeiten mehrerer Objekte. Es wird also immer auch eine Möglichkeit geben müssen, formlos Fehler zu berichten. Es scheinen aber auch einige anonyme Hinweise von Mappern zu stammen und nicht von reinen Nutzern. Dass aber OSM Notes nur für Leute mit OSM-Kenntnis gedacht ist, ist schlicht falsch. Oder warum braucht man für “$HIER existiert $DIESES Problem” Wissen über OSM? Ist alles nur eine Frage der Einbindung in Anwendungen.
Der Unterschied zu Google Maps ist, dass du bei OSM die Daten problemlos selbst eintragen kannst und keinen Antrag stellen musst. Anwender, die mit dem einfachen Fehlerreport über die Notes-API nicht glücklich sind, sind vermutlich bereits Zielgruppe für einfache OSM-Editoren. Durch deine beschriebene Bug-API würde daraus ein Tag-Editor ohne direkte Datenübernahme in die OSM-Datenbank entstehen. Etwas zwischen Fehlerbericht und OSM-Editor. Bräuchte man dann eine parallele Datenbank? Oder würden die Daten doch in der Datenbank landen, nur mit speziellen “Bug”-Tags. Viel Aufwand für einen meiner Meinung nach seltenen Anwendungsfall.
Ein neuer Notes-Status “lokales Wissen nötig” wie oben beschrieben könnte hilfreich sein für den von dir geschilderten Einsatzzweck.
Nicht erreichbare Webseiten kann man mit Keep Right finden. Es ist nicht sinnvoll, alle Arten von Qualitätssicherungs-Tools in die Hauptseite zu integrieren, denn Komplexität ist auch ein ernsthaftes Problem. Die Wiki-Seite Quality assurance sollte das Problem mit der Fragmentierung doch ausreichend lösen, wenn man sie erstmal kennt.