Dringend: Große Löschung in München

Beim ersten Changeset (16899624) dürfte es reichen, die Änderungen in München (ausschließlich Löschungen) zu revertieren. Soweit ich das sehe, sind alle anderen Änderungen in Berseba (Namibia): http://www.openstreetmap.org/?lat=-25.99616&lon=17.76936&zoom=15&layers=M und ok (wenn auch anfängertypisch unvollständig). Das sind Geometriekorrekturen (Anpassung an Bing) von Straßen, neu eingezeichnete Gebäude (aber noch ohne building=yes) und eine Grundschule mit Namen.

Was sind das denn dann für Änderungssätze? Warum ist sowas überhaupt möglich?

Reine Relations-Edits (evtl. nur, wenn die Relationen auch nur Relationen als Member haben) z.B., hab’ ich auch schon geschafft, tauchten aber in der Liste trotzdem auf.

So sehe ich das auch. Allerdings wurden auch in München Objekte nicht nur gelöscht, sondern auch bearbeitet: Relationen nämlich, 90 Stück. Multipolygone, Routen, Abbiegebeschränkungen. Wie gesagt, die Löschungen waren in Sachen Wiederherstellung recht unproblematisch, weil mit wenig Konfliktpotential behaftet. Mal sehen, wie es jetzt mit den bearbeiteten Relationen läuft.

Der letzte und mittlere Änderungssatz sind durch. Ich werde JOSM jetzt mal auf den ersten ansetzen.
http://www.openstreetmap.org/browse/changeset/16901890

Leere Änderungssätze nicht zu vergessen.

Tatsächlich, die API gibt 6 aus, von denen drei komplett leer sind (eins, zwei, drei). Das einzig sinnvolle, was mir einfällt, wie sowas entstehen könnte, wäre, dass man sich eine Changeset-ID geben lässt und dann doch keine Daten liefert – gibt es sonst noch einen möglichen Grund dafür?

Alles (hoffentlich) wieder da, wo’s hingehört. Die Relationen waren zwischenzeitlich nicht bearbeitet worden, also glücklicherweise auch hier keine Konflikte.

Alle gelöschten Objekte sind wiederhergestellt, die betroffenen Relationen in München eine Version zurückgesetzt. Die (mutmaßlich sinnvollen) Bearbeitungen in Afrika habe ich nicht angetastet.

http://www.openstreetmap.org/browse/changeset/16901319
http://www.openstreetmap.org/browse/changeset/16901372
http://www.openstreetmap.org/browse/changeset/16901675
http://www.openstreetmap.org/browse/changeset/16901757
http://www.openstreetmap.org/browse/changeset/16901890

@KonB: Schon Antwort auf Deine Mail erhalten? Würde mich ja interessieren, was da passiert ist. Meine Vermutung ist, daß jemand versehentlich die flasche Gegend heruntergeladen und anschließend “Bereinigen” und “Löschen” verwechselt hat. Wie früher bei der Stasi: “Observieren” und “Abservieren”.

Der JOSM-Bug, der ursprünglich das Hochladen blockiert hat, liegt wohl irgendwo im Validator. Dieser sträubt sich anscheinend gegen Wege (= schmiert ab), die nicht komplett geladen oder anderweitig kaputt sind. Ich habe mir damit beholfen, vorübergehend die Überprüfung vor dem Hochladen vollständig abzuschalten (was normalerweise jeglicher Vernunft widerspricht). Im Reverter ist wohl auch was kaputt, ansonsten hätten keine Wege ohne Knoten zustande kommen dürfen (welche anschließend der Server - sinnvollerweise - nicht akzeptieren wollte).

Hallo!

Danke an das ganze Reparaturteam!

Ist schon erschreckend zu sehen, dass es nach 10 Sekunden Unbedachtheit, vieler erfahrener Mapper bedarf und rund 2 Stunden wertvoller Mapping- Zeit kostet, um alles wieder herzustellen. :confused:

Dabei ist dieser Fall aus zwei Gründen noch sehr glimpflich verlaufen: erstens war eine Gegend mit aufmerksamen Mappern betroffen, zweitens war der Krater nicht zu übersehen. Folglich sind die Löschungen sofort aufgefallen und konnten umgehend rückgängig gemacht werden. Ein viel größeres Problem sind aus meiner Sicht jene Unfälle, bei denen nicht gleich ein ganzes (Bermuda-)Rechteck verschwindet, sondern etliche unregelmäßig verstreute Objekte beschädigt oder gelöscht werden. Das fällt dann womöglich erst nach Monaten auf, wenn eine Wiederherstellung aufgrund von Konflikten und neu eingezeichneten Objekten kaum noch möglich ist. Oder es wird erst gar nicht bemerkt und der Schaden bleibt.

PS @KonB: Willkommen im Forum. Das ist jetzt irgendwie untergegangen.

Zuerst meinen Dank an den aufmerksamen User und das ehrenamtliche “emergency response team”.

Das Ereignis sollte uns aber doch so langsam zu Bedenken geben, ob es wirklich noch vertretbar ist, dass jeder im Prinzip alles in der OSM-DB ungehindert modifizieren/löschen kann.
Ich akzeptiere die Bedenken der User, die jede Einschränkung ihrer Freiheit als Verletzung der Offenheit von OSM ansehen.
Aber ungeprüfte Einträge in einer Datenbank empfinde ich wie eine Operation am offenen Herzen, die von jedem durchgeführt werden kann, der beim Eintreten den Pförtner freundlich gegrüßt hat.
Ich will den Teufel nicht an die Wand malen, aber es hätte schlimmer kommen können.

Hat ja seine Gründe, dass es so ist.

Vor allem würde ich auch nicht ausschließen, dass mir so eine Löschung auch passieren kann. Also mit einen simplen “Beiträge von Neulingen werden erst gesichtet” wie bei Wikipedia ist es nicht getan. So ein Löschen kann durch eine Unachtsamkeit echt schnell passieren (muss es aber nicht).

Mal ne Frage am Rande: gibt es irgendwo eine Übersichicht über “nicht beobachtete Gebiete”? Ich denke wir alle haben eine Bbox um unser Stammgebiet gezogen und kriegen Änderungen schnell mit. Aber vielleicht gibt es nicht oder nicht ausreichend beobachtete Gebiete.

Danke!

Aber Hallo!

Der hierbei verwendete Josm informiert vor dem Upload der Änderungen genau darüber, was gleich abgeht. Und wer das nicht sieht und dann die Notbremse zieht, sollte am besten die Finger von OSM lassen.

Gruss
walter

p.s. selbst der so geschmähte iD macht das sauber.

Akzeptiere ich auch. Aber irgendwann muss man doch einmal Nutzen und Risiken abwägen.

Die Sicherheitsmechanismen bei Wikipedia sind mit Sicherheit nicht auf OSM anwendbar, da die OSM-Daten anders als in Wikipedia ständigen Veränderungen unterliegen (sollen!). Ich will keine Blockwartmentalität befürworten, aber irgend eine Absicherung gegen versehentliche oder böswillige Massenedits sollte doch möglich sein. Die sind halt für jeden User mit Account möglich, egal ob er etwaige Warnungen versteht oder nicht. Momentan ist die einzige Schadensbegrenzung (für den Normaluser) so weit ich es sehe die Begrenzung des heruntergeladenen Gebietes durch den Server.

Die Liste der Änderungen hilft mir wenig, wenn ich erwarte, daß sie lang ist. Es fehlt eine Visualisierung der Änderungen.

Baßtölpel

Gibt es leider nur, wenn es schon zu spät ist:
http://owl.apis.dev.openstreetmap.org/ → Chronik (beta)

In JOSM ist das einigermaßen leicht möglich:

  • Finden: modified
  • Mit 3 auf die selektierten (=geänderten) Daten zoomen.

Leider sieht man die gelöschten Daten dabei nicht, also auch unvollkommen.

Edbert (EvanE)

User hat sich inzwischen gemeldet und entschuldigt, hatte aber auch nicht wirklich eine Erklärung, was da passiert ist…

Morgen,

könntest Du das bitte kurz erklären?

Ich kann mit “Finden: modified” leider nichts anfangen :frowning:

Du siehst mich ratlos, wie das zu machen ist, es klingt aber sehr interessant.

Schönen Tag noch
Erwin

Im Edit-Toolbar (die Leiste, die meistens am linken Rand sitzt) auf das Trichter-Symbol klicken. Das öffnet rechts das Dialogfeld Filter. Dort einen neuen Filter anlegen (linker button), modified in die Textzeile eingeben, Filter bestätigen. Dann die drei Checkboxen rechts und links der Zeile mit modified aktivieren. Diese bedeuten: der Filter ist aktiv, ausgefilterte Objekte werden überhaupt nicht dargestellt statt nur grau und die der Kondition entsprechenden Objekte werden dargestellt.

edit: typo

Baßtölpel

Ganz einfach: In der Suchfunktion von JOSM ([Strg]+[F]) “modified” eingeben.

Ein Nachtrag noch: im ersten Anlauf war mir die Hälfte der Relationen durchgerutscht, insbesondere jene, die komplett leergeräumt wurden. Soeben nachgeholt: http://www.openstreetmap.org/browse/changeset/16910696

In der Summe ging es um 963 gelöschte Knoten, 3420 gelöschte Wege und 181 beschädigte Relationen.