Nachdem ich in http://www.openstreetmap.org/changeset/43222415
schon 3 (sic!) gleichartige Einträge “Augustiner am Wörthsee”
von PermobilF5 zusammengezogen habe
(den “stimmgelegten” POI zum Augustiner ist natürlich nicht reaktiviert worden
respektive habe ich mir erlaubt,
alles auf den vorhanden, nun reaktivierten “umzubuchen”)
Bildet wheelmap so “Sammel-Hotspots” ?
Und wenn ja, wie kommen die grad hier in die Pampa bei Dingelstädt ?
Ich erlaube mir zu sagen, wheelmap hat ein massives Problem …
Und zwar nicht nur wegen der “Koordinatenschieberei”,
auch den Inhalt (gemeindehaus, Hsuptsache, raisch, elektro Höfe)
sehe ich eher unter dem Aspekt “laden wir mal bei OSM unseren Schrott ab”
Das ist die Stelle, die mir bei den PLZ-Fools im PLZ-Bereich Küllstedt aufgefallen ist (von mir in Post #12 erwähnt), wo sich inzwischen 38 POIs (davon 30 auf gleicher Koordinate) angesammelt haben, die dort nicht hingehören.
Ich würde parallel dazu dafür sorgen, dass die App spätestens vor dem Hochladen zu OSM einen eurer Webserver kontaktiert und da nach einer neuen Version nachfragt. Dort könnte man auch eine “Upload-Sperre” einbauen, damit so eine unreife App auch gezügelt werden kann.
Installieren ist nicht unbedingt machbar aber zu verhindern, dass Schrott hochgeladen wird, schon.
Meine Webanwendungen (keine Apps) mache genau das. Wenn ICH das will, machen diese einen Reload der Webseite und dadurch wird eine neue Release automatisch aktiviert. Spätestens 1 Minute nach dem Aufruf ist das erledigt und nach 1-2 Tagen nutzen alle die neue Version.
Hm, ich hätte nichts gegen Gemeindehäuser in OSM (die mappe ich auch, aber am richtigen Ort :P), aber manche dieser Einträge sind wirklich schrottig. „Evangelische Kirche;Rathaus“ ist eine unsinnige Fusion zweier völlig separater Entitäten zu einem POI. Und vieles andere enthält gerade mal die wheelchair-Infos, aber die wirklich wichtigen Tags fehlen. Was soll amenity=school name=Fabia sein? Der „alter Friedhof Dätzingen“ ist nicht nur falsch (klein) geschrieben, sondern v.a. mit amenity=place_of_worship unpassend getaggt (entweder er ist noch ein Friedhof, oder er ist inzwischen ein Park/Grünfläche). Ein „Rathaus“ sollte nicht office=government bekommen, da haben wir was Passenderes für. Usw. …
Leider bekommt man öfter diesen Eindruck. So toll Wheelmap als Idee ist, beim Eintragen neuer POIs wird oft seltsames Zeug produziert – teils werden schon vorhandene POIs einfach nochmal gemappt (und nochmal und nochmal, siehe den oben zitierten „Augustiner am See“), teils wird das falsche Tagging genutzt, meist fehlen wichtige Tags und Infos, weil es ja nur auf die wheelchair-relevanten Tags anzukommen scheint …
Sollte man das Anlegen neuer POIs nicht vielleicht doch besser auf „richtige“ Editoren beschränken (ja, iD sehe ich jetzt mal als „richtigen“ Editor an) und in Wheelmap und Co. nur das Modifizieren bereits vorhandener POIs erlauben? – (Nachdenk) – OK, nein, wahrscheinlich auch keine Lösung. Dann würde wahrscheinlich, wenn der benötigte POI noch nicht drin ist, kurzerhand ein anderer nahegelegener umbenannt. Das wäre wahrscheinlich noch schlimmer.
Hallo “holgerd”,
ihr habt die Taubenstraße weiter im Blick? In den ersten Tagen des neuen Jahres sind schon wieder sechs fehlgeleitete POI dort gelandet…
Das kann IMHO keine dauerhafte Lösung sein. Sinnvoller ist es, entweder den Benutzern eine 0-Stunden-Sperre zu verpassen, damit sie ihre App aktualisieren, oder die Version der App API-seitig zu sperren. Letzteres wurde vor Jahren mal mit einer JOSM-Version gemacht.
Für die erste Lösung müsstest ihr für jeden betroffenen User eine Sperre über die DWG (data@osmfoundation.org) beantragen.
Der Weg über die API ist wesentlich einfacher und sicherer, da er alle User erreichen wird, auch wenn die erst nach Monaten wieder mal was hochladen wollen. Allerdings dürfte es schwieriger sein, die für die API zuständigen Admins von dem Problem und der Lösung zu überzeugen.
Die API-Sperre halte ich für wesentlich besser.
Ich habe übrigens bei meinen Anwendungen einen Test eingebaut, ob auf dem Software-Server eine neue Version vorhanden ist. Dann erfolgt ein Hinweis auf die neue Version und falls notwendig ein Zwangsupdate, der die neue Version aktiviert.
Hallo Holger,
danke für Deine schnelle Reaktion hier im Forum und auch - gewissermaßen - in der Taubenstraße. Gewissermaßen, weil alle betroffenen POI nun gelöscht sind, aber nicht an die richtigen Orte verschoben wurden. Oder übersehe ich was? Finde ich schade, nicht zuletzt für die aktiven (leider updatelosen) rosemary-Nutzer.
Ansonsten stimme ich Nakaner und wambacher zu, dass hier etwas aktiv passieren muss, um die Problematik zu beheben.
Wir haben die Orte verschoben, die genügend Adressdaten hatten um sie korrekt zu platzieren. Für einige war das aber nicht möglich (z.B. nur Name: “Mediamarkt” und sonst keine Infos).
Wie gesagt hoffen wir, dass das nun langsam aufhört (iOS-Nutzer aktualisieren die App recht schnell)
Das ist mir schon klar Man hätte aber ggf. ihre Ersteller anschreiben können (auch in einer Massenmail) und nachfragen können. Naja, denke der Drops ist rückwirkend gelutscht.
ich schlage vor, dass wir den OAuth-Key der Applikation widerrufen lassen und sich die Sozialhelden einen neuen besorgen (geht über ein Webformular), diesen in die Wheelmap-App aufnehmen und eine neue Version ausrollen, deren einziges Feature ein neuer Key ist. Anders kann man dieses Problem nicht bekämpfen.
Falls die Wheelmap nicht OAuth nutzt, blockt man die App halt, wie das mit der einen berühmten JOSM-Version passiert ist, die Längen- und Breitengrad vertauscht hat.
@RoterEmil:
Danke für den Hinweis, die Wheelchair-Angabe zum Gartencenter https://www.openstreetmap.org/node/4931544825 habe ich dem existierenden Gebäude in Herdern hinzugefügt und daher den Node gelöscht. Die Infos sind also verschoben.
@Nakaner:
Ich bin dagegen den OAuth-Key zu invalidieren, das wäre völlig unverhältnismäßig. Das würde neben riesigen Entwicklungsaufwand bedeuten, dass uns hunderte Informationen verloren gehen, die Wheelmap-Nutzer täglich eintragen.
Nach fast 2 Monaten ist nun ein einziger falscher Node entstanden den ich innerhalb von 14 Stunden korrigiert habe. Der Fehler tritt nur an dieser einen Koordinate auf und ist außerdem in der aktuellen iOS-Version gefixt. Wir beobachten die Koordinate nach wie vor und räumen auf falls es wieder zu falschen Nodes kommen sollte.