Datenmüll durch Umtagging von POIChecker

neue-strassen.de scheint wirklich Gold wert zu sein beim Aufspüren von Unsinn.

Hier ist eine Straße, die mit Hausnummer in einer Straße liegt und eine Telefonvorwahl, aber andererseits auch einen Gehweg hat. Ein Haus-Straßen-Mischwesen:

http://www.openstreetmap.org/way/155203311

Jemand vor Ort und kann uns sagen, was damit zu tun ist? Da ist doch offenbar ein Tagging vollkommen danebengelaufen.

–ks

Edit: Betreff geändert

In HD gibts eine auffallende Häufung. Ich stolpere gerade über http://www.openstreetmap.org/way/26843009/ in Version #22. Hier sollte offenbar ein Metzgerladen per poichecker eingetragen werden, das Tagging landete aber an der Straße.

Ich habe den User schon darauf hingewiesen.

Sind da untaugliche Werkzeuge im Einsatz? Kenne poichecker nicht.

–ks

Das betreffende Changeset: http://www.openstreetmap.org/changeset/34606070 enthält jedenfalls noch mehr seltsame Dinge. U.a. kommt derselbe Way (96054435) in diesem Changeset in 2 Versionen vor (ist das normal? sowas habe ich noch nicht hinbekommen). Es geht um die Jesuitenkirche, die innerhalb dieses Changesets von “Jesuitenkirche” in “Jesuitenkirche-Gemeindesaal” umbenannt wurde: Version 9 und 10 in

http://www.openstreetmap.org/way/96054435/history

Das würde mich aber doch wundern: die Jesuitenkirche ist nämlich immer noch die Jesuitenkirche, der Gemeindesaal sollte, so er exisiert, eine eigene Entität sein. Strange … das arme Heidelberg. Demnächst benennt poichecker.de dann das Heidelberger Schloss in “Papierkorb am Schloss” um.

Was ist das eigentlich für ein Editor, der da verwendet wurde: rosemary v0.4.3?

Ja das geht. Wenn du beim ersten Hochladen den Changeset nicht abschließt, kannst du den gleichen Weg wieder bearbeiten und nochmal in den gleichen, offenen Changeset hochladen. Dann ist der Weg dort zweimal in zwei Versionen vorhanden.

Ah, danke für die Aufklärung!

Dann ist das also kein Problem; wohl aber das, was in diesem Changeset so alles geschieht … Zumindest Wikipedia ist durchaus der Meinung, dass die Jesuitenkirche noch die Jesuitenkirche ist und kein Gemeindesaal; das Erzbistum klärt mich zwar darüber auf, dass die Kirche offiziell jetzt “Pfarrkirche Hl. Geist” heißt (im Text heißt sie dann jedoch wieder durchgängig “Jesuitenkirche”), aber das ist eben ein Fall für alt_name oder old_name, jedenfalls immer noch kein Gemeindesaal.

Wenn dann alt_name.
Auch zu Zeiten als diese Kirche von den Jesuiten betrieben wurde hieß war sie auf den Hl.Geist geweiht. Das ist das gleiche wie in München die Theatiner Kirche, die in Wirklichkeit St.Kajetan heißt.

poichecker frisst externe Daten aus Datenspenden, nimmt diese Daten, sucht sich eine Koordinate dafür und bietet ein paar verdächtige POIS aus der Nachbarschaft dieser Koordinate ein. Aufgabe des Benutzers ist es, den Punkt aus der Datenspende dem Element aus OSM zuzuordnen. Beschreibung gibts auf github: https://github.com/sozialhelden/poichecker

Zum Punkt aus der Datenspende wird eine grösseren Menge an “verdächtigen POIS” angeboten. Z.B. wird zum Behindertenparkplatz aus der Spende eine Auswahl aus Straßen, ein Jugendtreff, ein Bürgeramt und eine Bank angeboten. Der Nutzer könnte dann entweder den richtigen finden und auf “Der ist es” anklicken. Er könnte auch “Ort nicht dabei? Überspringen” wählen. Oder er könnte die erst beste angebotene Straße diesem POI zuordnen, vielleicht auch in der Meinung “Das ist er” sollte “Da in der Nähe liegt er” bedeuten. Das passiert wohl, wenn die Tags der Metzgerei auf der Straße landen.

Grüße, Max

Das ist die Wheelmap.

Hallo kreuzschnabel!

Ja, ich bin vor Ort.
Da ist einiges schief gelaufen.
Mir sind diese fehlerhaften Bearbeitungen schon Mitte Oktober aufgefallen.

Auf Verdacht habe ich einen der beteiligten langjährigen Mapper angeschrieben, hier eine gekürzte Version meiner Nachricht vom 13. Oktober 2015:

Alle Namen habe ich unkenntlich gemacht.

Die Antwort war sehr freundlich und ausführlich.
Wie dieser zu entnehmen ist, handelte es sich um eine Mapping-Aktion.
Der von mir angeschriebene Mapper ist einer der anleitenden Personen.
Mir wurde zugesagt die Bearbeitungen nochmals auf grobe Fehler zu überprüfen und dafür ein Zeitrahmen von ca. 2-4 Wochen genannt.
Nach über 6 Wochen hat sich da aber nicht wirklich viel getan.

Ich habe zwar angefangen die Fehler zu beseitigen, war dann aber auf Grund der vielen Fehler so demotiviert, dass ich eine Mapping-Pause von über einem Monat eingelegt habe.
Es gab übrigens zuvor schon einige Mapping-Aktionen in und um Heidelberg (waren aber wahrscheinlich andere Akteure), nach denen ich dann tagelang aufräumen durfte.
Irgendwann schwindet hier die Motivation nach solchen Aktionen hinter anderen Mappern aufzuräumen.

Viele Grüße,
whb

@ whb: Oh jemine :frowning: – herzliches Beileid!

Könnten wir Dir durch verteiltes Abarbeiten der Fehler bei der Korrektur helfen? Wäre Dir das Recht? Wir könnten die Arbeit vielleicht irgendwie aufteilen; z.B. wenn Du mir per PN den Namen eines an der Aktion beteiligten Mappers schickst, so könnte ich dessen Changesets auf verdächtige Objekt-Änderungen prüfen. Jemand anderes könnte einen anderen Mapper übernehmen, etc. (Oder hast Du zufällig sogar schon Listen betroffener Changesets?)

Oder sollte man vielleicht alle betroffenen changesets einfach reverten? Bei einer so hohen Fehlerquote erscheint mir das fast als bessere Lösung … Was meinen die Revert-Experten?

Nochmal nachhaken? Derjenige muß doch einsehen, daß das nicht nur ein Schönheitsfehler ist, sondern dem Projekt nicht unwesentlich schadet. Wer derzeit nach aktuellen Karten durch HD will, dessen Navi findet die betroffenen Straßen unter Umständen gar nicht, wenn sie entsprechend unsinnig umbenannt wurden.

Wir wollen einklich nicht da landen, wo Wikipedia schon ist – jede Änderung nicht-bewährter Benutzer muß erst gesichtet werden, bevor sie scharfgeschaltet wird :frowning:

–ks

Bei ein paar Stichproben gewinne ich den Eindruck, eine der Absichten der Aktion sei es gewesen, Links auf die passenden Unterseiten von http://www.heidelberg.huerdenlos.de/ in unsere DB reinzudrücken. Nun ist das zwar eine an sich begrüßenswerte Website, aber der Link gehört normalerweise nicht in unser website=-Tag, das (wie whb schreibt) für die offizielle Website eines POIs gedacht ist. Wie könnten wir denn beim Verbessern mit diesen huerdenlos-Links umgehen, bzw. was können wir den Beteiligten beim Verbessern vorschlagen? Wie wäre es z.B., den huerdenlos-Wert in ein Tag wheelchair:website= zu verschieben? Das gibt es zwar lt. taginfo erst 8-mal, aber es wäre m.E. immerhin klar und konsistent mit wheelchair:description=* etc.

Edit: Die Website http://www.huerdenlos.de/ zeigt deutlich, dass es sich bei www.(stadtname hier).huerdenlos.de um ein durchweg kommerzielles Projekt handelt, mit dem eine Firma Geld macht. (Die POI-Verböserungsaktion in HD wurde aber nicht zufällig von dieser Firma gesponsert?)

Die Richtung stimmt, aber es geht ja auch bei huerdenlos.de nicht nur um Rollstuhltauglichkeit, sondern auch z.B. um Eignung für blinde Personen. Da brauchen wir ein allgemeineres Taggingschema.

https://wiki.openstreetmap.org/wiki/Disabilities zeigt schon mal ein paar Ansätze.

–ks

Man sollte mal den Poichecker ausprobieren, um zu sehn, wie das passiert…

Ich hole mir aus der Liste der noch zu bearbeitenden POIs z.B. eine Postagentur und bekomme ein paar mögliche POIs eingeblendet. Hier sind das eine Kletterstelle und noch irgendwas abwegiges, vermutlich der Mittelpunkt einer Stadtteilgrenze.

Ich klicke auf den ersten angebotenen POI und bekomme ein Fenster, in dem links die Daten aus dem Import stehen, rechts die aus OSM und in der Mitte die Vereinigungsmenge. Wenn ich da auf “speichern” klicke habe ich den POI editiert (habs schon wieder repariert, Version #2 des Nodes ist die poichecker-Version).

Ich hatte wenig Möglichkeiten, zu erkennen, dass ich hier Unsinn treibe. Ich konnte nicht sehen, dass ich da eine Kletterstelle mit Adressen und URL eingetragen habe, uninteressante Tags wie amenity oder highway werden nicht angezeigt.

Grüße, Max

Danke! Das klingt nach Fälligkeit einer deutlichen Ansage in Richtung der Macher des Tools. Bevor uns das noch mehr Daten zerschießt.

–ks

Ich habe denselben Test gemacht wie maxbe und kann mich nur anschließen. poichecker.de präsentierte mir diverse zu checkende POIs in Heidelberg (weil ich als Standort Bad Rappenau angegeben hatte – soviel zum Thema Ortskenntnis/räumlicher Nähe) und präsentierte mir für einen Behindertenparkplatz, ein Seniorenzentrum u.Ä. jedesmal diverse Vorschläge – aber kein einziges Mal (ich habe nach 10 Versuchen abgebrochen) war der passende Treffer unter den Vorschlägen. Stattdessen wurde mir z.B. vorgeschlagen, ein Haus (!) oder eine Straße als Behindertenparkplatz zu taggen. (Ich habe Bildschirmfotos, nur für den Fall, das das jemand nicht glauben kann, ich kann’s ja selbst kaum glauben.) Dabei lagen die Vorschläge sogar dann ziemlich daneben, wenn poichecker.de eigentlich bereits über eine recht genaue Anschrift (mit Hausnummer) verfügte. Besonders absurd: in einem Fall war die Senioreneinrichtung sogar schon mit Namen getaggt, für jedermann deutlich sichtbar auf der Karte, dennoch präsentierte mir poichecker gerade nicht dieses Gebäude, sondern alles (Un-)Mögliche in der Umgebung.

Ich hoffe ja, dass da gerade nur die Konfiguration kaputt ist o.Ä., oder dass ich “Unglück” hatte. Aber zumindest im derzeitigen Zustand scheint mir poichecker.de eher ein Werkzeug zur Datenzerstörung zu sein als zur Verbesserung unserer Daten.

Wir haben vor ungefähr drei Wochen versucht, die Fehler zu beheben. Bei den Nodes sollte eigentlich auch nicht mehr viel Kaputtes übrig sein. Offenbar haben wir dabei insbesondere bei den Ways noch nicht alle Fehler erwischen können. Wir werden mit Hilfe der Anmerkungen hier nochmals genauer drüber sehen. Ich hoffe, dass das noch vor Weihnachten klappt.

Bzgl. POIChecker bin ich mit den Kollegen in Kontakt und wir überlegen, wie man POIChecker verbessern könnte, damit solche Fehler nicht mehr passieren können. Die Idee von POIChecker ist es, Daten bzgl. Barrierefreiheit aus nicht-OSM-Datensätzen möglichst einfach in OSM einpflegen zu können, sodass nicht nur OSM-Experten beitragen können, sondern auch OSM-Anfänger. Die Software befindet sich noch in der Erprobungsphase und nur durch “Erprobung am lebenden Objekt” kann man die Schwachstellen tatsächlich finden.

Es tut uns Leid, dass bei der Mapping-Aktion so viele Fehler entstanden sind. Wir hatten die Hoffnung, mit einem Tool, wie POIChecker, bei dem die Einstiegshürde geringer ist, als bei “normalen” OSM Editoren, neue Mapper für das Projekt zu gewinnen. Die Resonanz war insgesamt sehr positiv, sodass wir dennoch hoffen, einige neue Mitglieder für das Projekt gewonnen zu haben.

Das Mapping-Event wurde im übrigen nicht vom Betreiber der Webseite “Hürdenlos” gesponsert (abgesehen vom CSV-Datenexport, den sie dem Heidelberger Beirat von Menschen mit Behinderungen, der die Daten ursprünglich mit Hilfe der Webseite erfasst haben, zur Verfügung gestellt haben). Wir werden die Anmerkungen bzgl. der URLs mit aufnehmen. Unser eigentliches Ziel ist es, in der Wheelmap eine Verknüpfung zwischen Wheelmap-Punkten und externen Quellen, die in der Regel wesentlich genauer über Barrierefreiheit informieren, als es OSM kann, herzustellen. Möglicherweise gibt es dafür einen Weg, der nur über Wheelmap, nicht aber über OSM, führt. Wir prüfen das.

Na toll, wie befürchtet. Wie gehen wir weiter vor, um weiteren Schaden nach Möglichkeit einzugrenzen?

Alle Changesets, die von poichecker reinkommen, erstmal zurückhalten und händisch prüfen lassen?
Die betreffenden Useraccounts (befristet) sperren?
Die Autoren von poichecker kontaktieren und um Erklärung des beobachteten Verhaltens bitten?

Wenn das so weitergeht, muß ja ständig jemand hinterherräumen, wo immer poichecker aktiv war. Was nicht sinnvoll geht, weil ich ohne Ortskenntnis nicht weiß, wo der Metzgerladen denn genau ist, der da an die Straße getaggt wurde. Da kann ich den Unsinn nur löschen. Ein gut gemeintes Tool wird zur reinen nutzlosen Arbeitsbeschaffungsmaßnahme für Ehrenamtliche.

–ks

Nö, sondern um Korrektur des Verhaltens und Mitteilung an alle Anwender bitten, bzw auffordern.

ist ja bereits geschehen.

Unter den Umständen ist es dringenst notwendig, die Quellen für diese “nicht-OSM-Datensätze” offen zu legen. Es handelt sich hier nämlich um einen Import “fremder” Daten, deren Lizenzlage zumindest OSM nicht bekannt ist.

Dass diese Daten hier semi-manuell “eingepflegt” werden (ich würde eher von “reingeschludert” sprechen), ändert nichts daran, dass das so nicht zulässig ist.

Dadurch wird übrigens die Hürde für einen generellen Revert sehr stark gesenkt.

Gruss
walter