Das Problem mit den deplazierten wheelmap-POIs (Grund: unsinnige Voreinstellung in der rosemary-App) fängt für mich an, bedenklich zu werden.
Wenn der POI im falschen PLZ-Gebiet auftaucht und die PLZ eingetragen wurde, fällt das ja in den “Fools” auf. Ich möchte aber nicht wissen, wie viele falsche Nodes unbemerkt bleiben. Ich habe den Verdacht, dass bei den wheelmap-Änderungssätzen häufig wenigstens ein POI völlig falsch sitzt.
Damit nähert sich dieses Werkzeug dem (ungewollten) Vandalismus getreu der Devise “Gut gemeint ist das Gegenteil von gut gemacht”.
Ich habe auf der wheelmap-Webseite mal eine Fehlermeldung abgegeben, bin aber skeptisch, ob damit der richtige Ansprechpartner erreicht wird.
Wenn ich das Problem richtig verstanden habe, übernimmt rosemary die GPS-Daten direkt vom Betriebssystem, und dieses erlaubt sich die Freiheit, bei fehlendem Messwert einen Defaultwert auszugeben.
Wenn das stimmt, dann liegt die „unsinnige Voreinstellung“ woanders. Rosemary müsste man beibringen, genau diese Koordinate als ungültig zu betrachten, um den vorher gemachten Fehler auszubügeln. Das ist aber nur ein wackliger Workaround, der genau dann nicht mehr funktioniert, wenn eine neue OS-Version mal einen anderen Defaultwert auswirft.
Da werden alle wheelchair=* mit toilets:wheelchair=* versehen.
Ist ja bei yes nicht falsch, aber wenn wheelchair=no warum dann noch toilets:wheelchair=no. Ich würde so etwas nur bei toilets verwenden und nicht an Parkplätzen, Büros, …
Das kann auch bei yes falsch sein: http://www.openstreetmap.org/node/3408493239. Ich glaube nicht, dass der Haltestellenmast eine behindertengerechte Toilette hat.
Meine Vermutung ist, dass hier jemand das Gebäude bearbeiten wollte. Ein Changeset-Kommentar bringt da aber wohl nicht viel, wheelmap_visitor ist ja ein Sammeluser.
EDIT: @Nakaner: Sorry, hatte deinen Beitrag erst nach dem Absenden gesehen.
ich habe die Abweichung des Vorgangs nicht vollständig verstanden, also von dem Vorgang welcher die Objekte nicht an den tatsächlichen Ort platziert.
Aber mal unabhängig davon und direkt gesprochen:
Gebe es denn die Möglichkeit die Eintragungen der App(des OSM-Accounts) in die OSM-DB zeitweise anzuhalten bis die Abweichung abgestellt ist?
Nebenbei, gibt es aktuelle Beispiele von deplatzierten Objekten?
Da dieses Problem schon seit Monaten ungelöst ist und auch nicht zu erkennen ist, dass sich das ändern wird (Mein Kommentar bei GitHub ist nach einer Woche immer noch unbeantwortet), schlage ich vor “Rosemary” auf die Sperrliste des OSM-API zu setzen.
Wenn das so stimmt, wäre die App noch untauglicher als ich dachte. Der vom Smartphone-GPS-Sensor gelieferte Wert kann in Städten Dutzende von Metern abweichen. Dann wäre fast jeder POI ungenau. Da dies aber längst nicht immer der Fall ist, muss es die Möglichkeit geben, einen POI “von Hand” an Hand einer Karte zu setzen.
Respekt!
So einen Offset wie von Umbrien nach Thüringen hatte ich bisher noch nicht.
Dann dauert es vielleicht nicht mehr lange, bis Neuseeland hier auftaucht ;).
Ich bin von den Positionen ausgegangen, die mir bisher untergekommen sind. Aus der Gegend Mühlhausen war da nichts dabei, das wäre mir aufgefallen. Ich habe auch noch kein System dahinter finden können: Die Positionen lagen einige hundert Meter bis Dutzende Kilometer abseits. Es könnte so was wie die letzte bekannte GPS-Position sein.
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 :(.