Datenmüll durch Umtagging von POIChecker

Das ist richtig. Straßen habe ich auch schon als offene Baustelle in POIChecker identifiziert. Die sollten zumindest als Linie und nicht als Punkt in der Karte angezeigt werden. Da würde man wohl am besten verstehen, dass man die Straße selbst und nicht Objekte an der Straße bearbeitet.

Daten nach Bedeutung (vgl. Parkplatz) vorsortieren wird automatisch sehr schwierig. Wenn man das bei jedem zu importierenden Datensatz vorher per Hand macht, dann kann man sich die Mühe sparen und die Attribute gleich direkt in OSM einpflegen. Bei Datensätzen zu nur einer Objektart könnte es aber Sinn machen, z.B.: wenn es um einen Datensatz für ausschließlich Kirchen, Bahnhöfe oder Parkplätze geht.

Nein, die Aktion wurde nicht von der Firma gesponsert. Ich kann Euch versichern, dass die Firma wohl nicht viel mehr als die entstehenden Unkosten mit dem Betrieb des Portals refinanziert. Die eigentlichen Daten werden nicht von der Firma erfasst, sondern vom Beirat von Menschen mit Behinderungen der Stadt Heidelberg.
Wir sind mit den Leuten von Wheelmap in Kontakt und überlegen, welches die besten Variante ist, um Wheelmap mit dieser Seite zu verknüpfen (was sinnvoll ist, da sich gegenseitig ergänzende Informationen vorhanden sind) und gleichzeitig nicht diese speziellen Links in OSM als website=* zu haben.

Danke für den Tipp. Erscheint mir für den Zweck wheelchair ebenfalls zu unspezifisch. Befürchte das dann ebenso in Kritik mündet, wie bei website. Werde nochmals nachfragen, ob diese Links am besten ausschließlich in der Wheelmap DB sein sollten.

Hallo,

ich bin Mitgründer von Wheelmap und habe an POIchecker wesentlich mit entwickelt. User shahmann gehört auch zum erweiterten Team, er hat das Mapping Event in Heidelberg durchgeführt und sich ja schon geäußert. (siehe #17 in diesem Thread). Leider hat das korrekte mappen offenbar nicht ausreichend funktioniert und das tut uns Leid.

Wir von Wheelmap bekommen immer wieder Daten zur Rollstuhltauglichkeit von Orten angeboten. Wir glauben diese sind hilfreich für OSM und Wheelmap, uns ist aber bewusst dass automatische Importe schlecht funktionieren und nicht im Sinne der OSM sind.

POIchecker hat deshalb den Zweck solche Datenspenden manuell von OSM-Usern zu überprüfen und erst dann in OSM einzutragen. Bei der Aktion mit Heidelberg Hürdenlos saßen Freiwillige einen Tag lang zusammen und haben versucht mit ihrem Ortswissen von Heidelberg die Datenspende durchzugehen. Wir haben sie vorher in der Nutzung von POIchecker geschult und jemand von uns war auch dabei, aber das hat offenbar nicht gereicht.

Lizenz:
Die Lizenz jeder Datenspende ist als Kommentar an jedem Changeset verlinkt und ich achte darauf dass sie Odbl-kompatibel ist. Bei dieser Aktion ist die Datenspende bspw. Public Domain: http://poichecker.de/de/data_sets/29

Fehler, die offenbar passiert sind:

  • Wahrscheinlich zutreffende OSM-Orte werden nur nach Name gesucht, so dass offenbar auch Straßen und andere nicht-POIs vorgeschlagen werden. So erkläre ich mir dass eine Straße von einem POIchecker-User versehentlich in ein Ärztehaus umgewandelt wurde.
  • Wenn das Feld Website leer war, haben manche Mapper die URL eingefügt, die mehr Barriere-Infos zu diesem Ort hat. Wenn da schon eine URL drin war wurde sie aber nie überschrieben.

Wir werden das Login für POIchecker sperren bis das gefixt ist.

Ich würde mich über weiteres Feedback sehr freuen weil ich nach wie vor Glaube, dass ein Tool zum Überprüfen von gespendeten Ortsdaten nützlich sein kann.

Grüße,
Holger Dieterich

-snip-

Hi Holger, danke für die Info

Ja, das können wir leider bestätigen :frowning:

“Public Domain” ist mMn nicht Odbl kompatibel. Es ist zwar bestimmt von den Spendern gut gemeint, aber da ist noch nicht alles “sauber”. Bin allerdings kein Lizenz-Profi.

Dir ist schon klar, dass das nicht die einzige “Datenverschlimmbesserung” war?

Ich schau mir noch die neuesten CS an; Auswertung läuft. Ist das Teil JETZT gesperrt?

Gruss
walter

Nachtrag: seit der letzten Auswertung sind keine neuen CS dazugekommen.

Ich halte es für sehr untauglich, da nur mit nominatim zu geocoden. Ich denke, ihr müsst da mit der Overpass-API rangehen, und wirklich genau auf Objekttyp filtern. Ja, das ist pro Datensatz ein bisschen neue Coding-Arbeit, aber die müsst ihr leisten, oder mal nen genauen Pointer in den Code geben, wo/wie ihr geocoded (mein ruby ist etwas eingerostet). Eventuell kriegt man das ja auch administrierbar, so das es keine Codeänderung pro Datensatz bedarf.

Geht es eigentlich immer nur darum, neue Infos einem bestehenden OSM-Objekt zuzuordnen, oder werden auch neue OSM-Objekte erzeugt?

Hallo,

Es ist irrelevant, was importiert wird. Für alle Importe gelten dieselben Regeln. Seien es Gebäude in einer US-amerikanischen Kleinstadt, Bäume in X-Stadt oder Dorfnamen in Zentralafrika. Es gibt keine Ausnahmen für humanitäre Zwecke (d.h. diverse HOT-Importe unterliegen denselben strengen Regeln).

Walter, diese Ausage war leider ein Griff ins Klo. Public Domain ist der englische Begriff für Gemeinfreiheit. Freier geht es nicht. Importierte Daten haben idealerweise diese Lizenz, weil man sich dann um nichts kümmern muss.

Dann sollte nach Ende des Imports aber dennoch der Link keinen 404 zurückgeben. Die Forderung der Import-Richtlinie nach einer Dokumentation im OSM-Wiki habt ihr noch nicht erfüllt. https://wiki.openstreetmap.org/wiki/Import/Guidelines

Im Falle von heidelberg.huerdenlos.de habt ihr im Wiki folgendes als Lizenz dokumentiert

Das ist in meinen Augen nicht ausreichend. Der Lizenzgeber hat nur der Nutzung durch die Wheelmap zugestimmt. Durch Hochladen auf osm.org darf jeder, nicht nur die Wheelmap, die Daten nutzen. Wenn ihr die Daten nicht für OSM hochladen dürft, müsst ihr sie in einer eigenen Datenbank halten. Um Missverständnisse zu vermeiden, rate ich euch, die wichtigen Passagen – auch euerer Mail(s) – und nicht nur Schnipsel zu zitieren.

Die Idee hinter dem POIChecker ist an sich in Ordnung. Der gehört zu der Kategorie an Software, die zwar für Spezialzwecke gedacht ist, aber auch anders eingesetzt werden könnte (siehe Tasking Manager, den man auch für nicht-HOT-Aktivitäten einsetzen kann). Bloß die nicht-technische Umsetzung ist nicht vorbildlich. Ich möchte euch, liebe Macher der Wheelmap bitten, die Import-Diskussion und -Dokumentation nachzuholen. Wenigstens habt ihr selbst den POIChecker vorübergehend abgeschaltet, dann muss keine höhere Instanz eingreifen (die ist bestimmt froh, wenn sie das nicht tun muss).

Viele Grüße

Michael
(der bei Läden u.ä. gerne ein wheelchair=* taggt – auch weil es die Karte gibt)

Wat denn nu? Oben ist PD ok und das bedeutet dennoch, dass die Jungs*Mädels die Daten nicht in OSM eingeben dürfen?
da blick ich nicht mehr durch.

Gruss
walter

Du schriebst “‘Public Domain’ ist mMn nicht Odbl kompatibel.”. Das ist falsch und das wollte ich richtig stellen.

Das Zitat im Wiki gibt leider nur ein “Die Wheelmap darf es verwenden, aber in OSM darf es nicht.” her.

+1. Wenn man sich die Changesets zu Heidelberg mal im Detail ansieht und die tlw. absurden Zuordnungen, die da von den armen Freiwilligen getroffen wurden, dann ist offensichtlich, dass diese Freiwilligen nicht verstanden haben und auch gar nicht verstehen konnten, was sie da taten: eben diese tlw. absurden Zuordnungen wurden ihnen ja von POIchecker vorgeschlagen. Dies zeigt, dass eine bessere Vorarbeit keineswegs nur um der OSM-Daten willen erforderlich ist, sondern gerade auch wegen der Anwender des Tools, die hier, im guten Glauben, etwas Gutes zu tun, viel kaputt gemacht haben. Diese Anwender müssen sich doch eigentlich vera****t vorkommen, wenn sie irgendwann einmal mitbekommen, was sie da unwillentlich angerichtet haben. Und das wollen wir doch alle nicht, oder?

Daher: Wenn sich ein Tool gerade an (Noch-)Nicht-OSM-Experten wendet, dann muss das Tool oder die die Datensätze vorbereitenden Person sicherstellen, dass die Wahrscheinlichkeit von falschen Zuordnungen und Änderungen sehr gering ist. Im Idealfall sollte POIchecker also bei der Zuordnung von Informationen über einen Parkplatz bzw. Behindertenparkplatz nur Objekte zur Auswahl stellen, die mit amenity=parking getaggt sind; wenn es um eine Kirche geht, nur Objekte mit amenity=place_of_worship und religion=christian, am besten auch noch building=; wenn es um einen Laden geht, nur POIs mit shop= usw. Ich kann mir vorstellen, dass das viel Arbeit macht, zudem könnten auf diese Weise sicher nicht alle Objekte eindeutig zugeordet werden (denn bei manchen ist das Tagging ja nicht eindeutig). Doch auf diese Weise würden ganz abwegige Zuordnungen ausgeschlossen und eine Beschädigung sinnvoller Daten unwahrscheinlich gemacht.

Ein weiteres Problem: mit POIchecker wurden ja nicht nur ein paar Tags zusätzlich gesetzt, die halt auch mal falsch sein können – es wurden auch Adressdaten geändert (in teils offensichtlich falsche), Objekte komplett umbenannt (siehe besonders eindrücklich Nakaners Beispiel von den 4 in “WC” unbenannten Bahnhöfen!) und umgewidmet etc. Wäre es nicht am besten, solche Änderungen komplett unmöglich zu machen? Sprich, POIchecker sollte Tags wie name=* oder Adressdaten einfach gar nicht ändern, sondern nur wheelchair=*-Tags u.Ä. ergänzen, wo diese fehlen.

Ohne sinnvolle Vorsortierung, ob manuell oder automatisch, kann ich mir nicht vorstellen, wie POIchecker jemals zu einem halbwegs sicheren Werkzeug werden soll (siehe oben). Vielleicht bin ich aber auch zu beschränkt ;). Jedenfalls, ohne ein bisschen mehr Aufwand wird es wohl kaum gehen, wenn das Tool wirklich mehr Freude als Ärger machen soll.

Uff … man überlege sich mal, was das im Umkehrschluss bedeutet! Wenn bereits die geschulten und begleiteten Freiwilligen in einer Stadt, in der sie sich auskannten, mit POIchecker solche Verheerungen anrichte konnten: was passiert dann erst, wenn ein nicht eingewiesener Benutzer mit diesem Werkzeug Orte bearbeitet, in denen er sich nicht auskennt? Und genau das kann jederzeit passieren, wenn das Tool auf einer öffentlichen Website steht. :roll_eyes: Umso dringender wäre es demnach, POIchecker stärker abzusichern, nämlich durch genauere Vorauswahl der Objekte und Einschränkung der zu ändernden Tags (siehe oben).

Edit: ergänzt.

PS: Ich weiß: OSM-Daten beschädigen kann jeder jederzeit – er muss sich nur einloggen und wild draufloslöschen oder, etwas subtiler, schwer zu erkennende falsche Informationen eintragen. Richtig “absichern” kann man OSM also nicht. Das Problem an Tools wie POIchecker ist aber, dass hier massive Datenbeschädigungen ohne bösen Willen passieren können – der User glaubt ja, etwas Gutes zu tun, und macht doch Dinge kaputt. Das ist ethisch ein massiver Unterschied. Und daher ist es leider nötig, gerade solche Werkzeuge besonders “idiotensicher” zu machen.

Update: Wir haben den Login auf POIchecker jetzt deaktiviert.

Jetzt erst? Ich dachte, das Zeug wäre schon längst gesperrt.

nun denn, fahre ich halt noch eine Auswertung.

Gruss
walter

EDIT: Mann oh Mann, ihr habt aber mächtig Quatsch verbreitet: housenumber anstelle von addr:housenumber, postcode anstelle von addr:postcode, website anstelle von source. ich hoffe, dass da nicht noch mehr kommt. :frowning:

Nachschlag: Noch 3 neue. Der Hype scheint wohl abgeflaut zu sein.


 https://www.openstreetmap.org/changeset/35681235 | http://poichecker.de/data_sets/29 | 2015-12-01 09:52:39
 https://www.openstreetmap.org/changeset/35687430 | http://poichecker.de/data_sets/29 | 2015-12-01 15:46:51
 https://www.openstreetmap.org/changeset/35705781 | http://poichecker.de/data_sets/29 | 2015-12-02 13:09:39

Zu https://www.openstreetmap.org/changeset/35705781 fällt mir auf: ihr könntet prüfen, ob die Koordinaten auch in DE liegen, auf die da die neuen Attribute geschrieben werden…

Bevor deshalb neue Kritik kommt: der Mapping-Fehler war mir bereits selbst aufgefallen und ich habe ihn auch schon korrigiert.
Weiterhin können POIChecker prinzipiell auch POIs außerhalb Deutschlands (z.B. Schweiz/Österreich) bearbeitet werden bzw. sogar auch POIs außerhalb des deutschsprachigen Raumes.

Da POIChecker aufgrund der beschriebenen Mängel derzeit nur bedingt geeignet ist, um Informationen zur Barrierefreiheit von Orten aus einem externen Datensatz in die OpenStreetMap zu übernehmen, hiermit die Bitte um Unterstützung an der manuellen Übernahme der Bewertung bzgl. Barrierefreiheit aus http://heidelberg.huerdenlos.de und Konvertierung in entsprechende wheelchair=* und toilets:wheelchair=* Tags. Wir werden auch daran arbeiten (nachdem die Korrektur der entstandenen Fehler abgeschlossen ist), sind über Unterstützung aber natürlich dankbar.

Nochmal zur Info: Die Erlaubnis zur Datenübernahme liegt vor und ist im Wiki dokumentiert:
https://wiki.openstreetmap.org/wiki/DE:Permissions#ab_2015

Wäre es nicht sinnvoll, erst alle (!) Beschädigungen rückgängig zu machen, die in Heidelberg und anderswo durch POIChecker entstanden sind? Oder seit ihr damit schon fertig? :wink:

Wenn keine Widersprüche kommen, werde ich vsl. am Sonntagabend oder Montag diese Changesets revertieren.

eventuell geht das einfacher, wenn du den vorher revertest: http://www.openstreetmap.org/changeset/35731715

war website → source

Gruss
walter

Das wäre super, damit dieser Alptraum endgültig vorbei ist. Vielen Dank, dass Du Dir die Mühe machst! Die reverts werden ja leider nicht gerade einfach sein, da schon viele Leute versucht haben, das eine oder andere manuell zu verbessern …