Hat jemand von Euch eine DB oder sonst ne Idee, um einfach zu prüfen, ob es sonst noch Changesets mit “created_by = OSMPOIEditor” gibt? Betrifft vermutlich nur Updates, die neuen POIs des Users von obigem Changeset scheinen Ok zu sein.
Ich habe mir gerade einmal erlaubt, folgende Notoperation durchzuführen: einen neuen Knoten am ursprünglichen Ort von # 2^31-1 erstellt und an dessen Stelle in die beiden Wege eingefügt (http://www.openstreetmap.org/browse/changeset/14999210). Damit verschwindet zumindest das hübsche weltumspannende Streifengebäude und OSMPOIEditor (und jede weitere kaputte Anwendung) kann mit #2^31-1 erst einmal machen, was es will, ohne Gebäude in Villingen-Schwenningen zu verbiegen. Das löst natürlich nicht das eigentliche Problem, aber zumindest schmerzen die Symptome nicht mehr.
Augenscheinlich ersetzt der OSMPOIEditor die ID des zu bearbeitenden Knoten durch die höchste Zahl, die er speichern kann; d.h. OSMPOIEditor wird auch weiterhin versuchen, #2147483647 zu bearbeiten. Dies wird häufig nicht klappen, weil der Server einen Konflikt meldet. Ein Editor muß beim Hochladen eines Objekts die ihm bekannte Versionsnummer angeben (“optimistic locking”). Stimmt diese nicht mit der aktuellen Version in der Datenbank überein, verweigert der Server die Annahme und meldet einen Konflikt. D.h. OSMPOIEditor wird #2147483647 nur noch “erfolgreich” verändern, wenn der Knoten, der eigentlich bearbeitet werden sollte, ebenfalls in Version 2 vorliegt; danach dann in Version 3 und so weiter. Das wird mit steigender Versionsnummer zwar immer unwahrscheinlicher, aber mit weiteren Bearbeitungen ist dennoch zu rechnen. Deswegen habe ich oben auch nicht einfach den Knoten zurück verschoben, sondern einen neuen angelegt.
Die Konfliktbehandlung dürfte auch das von Dir gefundene leere Changeset erklären, denn der Knoten, den der User tatsächlich bearbeiten wollte, ist in der nicht passenden Version 1.
Zur Verbreitung des Programms: Im 2. Halbjahr 2012 wurde OSMPOIEditor von 290 Nutzern für 5544 Bearbeitungen in 5634 Änderungssätzen genutzt. Selbst wenn der Softwarefehler schnell behoben werden sollte, müssen diese erst einmal alle ihr Programm aktualisieren. Bis dahin darf man gespannt den Knoten #2147483647 beobachten. Ansonsten ist es halt an den Admins, OSMPOIEditor von der API auszusperren.
Zumindest ist für dieses eine Programm jetzt bekannt, wie sich der 2^31-Bug auswirkt; und solange nur der eine Knoten #2147483647 betroffen ist, geht nicht viel kaputt. Bei den ganzen anderen neumodischen Telefonprogrammen heißt es abwarten, was für einen Murks sie machen. (Ich war ja ziemlich überrascht, daß bei osmosis in letzter Minute noch ein Problem entdeckt wurde und sogar die Geofabrik nicht ausreichend vorbereitet war. Bei den Eifon- und Android-Programmen hätte es mich im Gegenteil gewundert, wenn keine Probleme aufgetreten wären.)
Edit: Und ich habe mir soeben erlaubt, den Eintrag auf der Wikiseite anzupassen.
Naja, nix überstürzen. Ein paar Tage zum Lesen, Nachdenken, Ändern des Codes und Antworten sollte man ihm schon geben. Und glücklicherweise ist es ja so, daß das Programm augenscheinlich nur genau einen Knoten kaputtmachen kann Mehr Sorgen machen mir die anderen Programme, bei denen man noch nicht weiß, was schief geht. Jedenfalls gut, daß Du diesen Fehler schon entdeckt und beim Entwickler gemeldet hast.
Das Problem wurde behoben, wartet jetzt auf Appstore-Freigabe. Die 64-bit Identifiers Seite hab ich aktualisiert. Außer einem Test des Autors hab ich keine neuen Update-Changesets gefunden.
Ist sowas vom App-Store vorgesehen? Klar, automatischer Update geht, wenn der User das vorher aktiviert hat, aber kann man ihn zwingen?
Ich kann mich noch an die Story mit dem Mobile Acces Creator Mobac (?) erinnern; als da das Download-Limit eingeführt wurde, haben viele User einfach nicht upgedated und sind bei der offenen Version geblieben.
Es würde mich nicht wundern, wenn Apfel seinen Nutzern einfach Updates unterschöbe, ohne sie nach ihrer Meinung zu fragen. Aber das gilt vermutlich nur für die eigenen Produkte, nicht für Drittanwendungen.
Ich bin mal gespannt, ob auch bei Pushpin (iOS) ein Problem auftritt. Das Programm ist noch um einiges weiter verbreitet als OSMPOIEditor.
Gibt es denn nicht beim Haupt-OSM-Server die Möglichkeit, bestimmte Editoren mit bestimmten Versionsnummern zu blocken, wenn diese eine Gefahr für den Datenbestand darstellen?
Quasi eine Blacklist?
Somit wären alle POI-Editor-Nutzer auch zu einem Update “gezwungen”.
Auch FreieTonne / freietonne-db scheint mit 2^31 nicht zurecht zu kommen. Hier wurde der bereits bekannte Knoten 2147483647 (2^31-1) zunächst verschoben und dann gelöscht, was wohl eigentlich dem Knoten “Sperrwerg” (2170733135) galt. Das Problem dürfte völlig analog zu dem in POI+ sein und auf einen zu kleinen Ganzzahl-Datentyp zurückgehen. freietonne-db ist angeschrieben. Immerhin wird das Programm nur von einem einzigen User verwendet, sodaß keine Altversionen mehr herumstreunen werden, wenn der Fehler erst einmal behoben ist.
Nachtrag: freietonne-db hat geantwortet, das Problem bestätigt und sich an die Arbeit gemacht.
Ich weiß nicht ob es etwas mit der Problematik zu tun hat, aber beim OSM-Inspektor kann man z.B. bei diesem Punkt keine History und keinen OSM Data Browser aufrufen (bzw. es kommt eine Fehlermeldung). Außerdem hat der Node eine negative ID.
Mehr Sorgen machen mir die anderen Programme, bei denen man noch nicht weiß, was schief geht. Jedenfalls gut, daß Du diesen Fehler schon entdeckt und beim Entwickler gemeldet hast.