Es würde genügen, den OAuth-Consumer-Key zu sperren. Der ist in der App enthalten, die auf den Smartphones installiert wird, und für alle Installationen gleich. In der ersten Version, die den Bug fixt, integriert man einen neuen OAuth-Consumer-Key. Nach dem Release der neuen Version, kann der Entwickler den alten Key sperren (auf hxxps://www.openstreetmap.org/user/USERNAME/oauth_clients unten unter “My Applications” die Details aufrufen).
Nutzer, die dann noch nicht auf die neue Version aktualisiert haben, sind zwar ausgesperrt, aber irgendwann muss man die kaputte App sowieso verbannen. Alle Nutzer der neuen Version müssen sich einmal frisch einloggen und die “neue” App authorisieren, aber das kann man mit einem Erklärtext ergänzen, bevor das Login-/Authorisierungsformular als Web View aufgerufen wird.
Ich habe den Umfang des Problems noch nicht analysiert (Fehler gezählt), weshalb ich vorerst auf Forderungen verzichte. Dennoch wäre es sehr empfehlenswert, wenn ein App-Entwickler bei einem solchen Bug ohne Drohungen aktiv wird.
Diese Association liegt doch genau dort, wo schon unzählige andere POIs lagen? Scheint ne beliebte Location zu sein, allerdings scheinen die POIs dort nicht lange überleben zu können…
Mich ärgert es mich schon etwas, dass der App die Berechtigung zum Verändern der Daten nicht (vorübergehend) genommen wird - solange bis sie das mit den jeweiligen Geolocation-APIs nachweislich in den Griff bekommen.
Auf Wheelmap-Verantwortliche zu hoffen, ist vermutlich vergebene Liebesmühe, auch auf CS-Kommentare und PN habe ich bisher noch nie eine Reaktion erhalten.
Dieser Fall ist aber noch ziemlich harmlos: Hausadresse und POI waren schon vorhanden, der neue fast redundante POI lag nur 20 Meter entfernt jenseits der Bahngleise.
Momentan kann man den Wheelmap-Einträgen nur seufzend hinterherräumen :(.
Solange bis die neue App erscheint sollen sich gefälligst die Wheelmap-Verantwortlichen um falsche POI-Positionierungen kümmern. Das dauert einfach schon zu lange!
Oiso jetzt aber … 435 km zu weit westlich …
Du bist aber schon a bisserl kleinlich oda ?
Solche Beiträge machen einfach Freude,
vor allem weil es den Punkt (zum editieren) längst gibt …
WANN die das Thema jetzt endlich in den Griff bekommen ?
Ich halte das Argument (also das ironische zwischen den Zeilen) für relativ valide, denke aber, dass es ziemlich viele Ausnahmen geben kann. Bspw. einen POI mit "Aussen"toilette, die zugänglicher ist, als der eigentliche POI.
Stimmt auch wieder. Tatsächlich ist die Kombination wheelchair=no, toilets:wheelchair=yes sehr interessant. Was ich meinte, war halt der Standard-Fall: wheelchair=no, toilets:wheelchair=no; in diesem Fall ist das toilets:wheelchair=no nicht gerade überraschend und könnte mMn weggelassen werden. Aber Du hast schon, eben weil es auch den Fall wheelchair=no, toilets:wheelchair=yes gibt, ist es doch nicht ganz redundant, auch im Falle von wheelchair=no auch noch explizit toilets:wheelchair=no anzugeben.
Edit: letzter Satz korrigiert; in einer früheren Fassung (auf die kreuzschnabel im folgenden Abschnitt anspielt) endete der Satz versehentlich so: „… auch noch explizit toilets:wheelchair=anzugeben anzugeben.“