Die A5 ist zerstört!

Seht selbst:

https://www.openstreetmap.org/#map=15/50.0127/8.6001&layers=N

Wer hat die Autobahn da abgebaggert?

https://www.openstreetmap.org/changeset/27371654

Keine weiteren Fragen, euer Ehren.

Dass das aber in den vier Tagen niemandem aufgefallen ist… ich hoffe, dass hier ein Revert noch möglich ist.

Der Typ hat aber noch mehr merkwürdige Sachen gemacht, siehe z. B. diese Bankfiliale auf der grünen Wiese oder dieses höchst interessante Riesen-Wohnhaus mitten im Wald, oder auch eine Lackiererei mit eingebautem Supermarkt. Die abgebaggerte Autobahn ist da nur die Spitze des Eisbergs.

Die “liebevollen” Details bei der freiwilligen Feuerwehr Mörfelden

https://www.openstreetmap.org/edit?editor=potlatch2&node=3213918804#map=19/49.97068/8.56375

könnten ein Hinweis auf seinen Wirkungskreis sein. Die Bankfiliale habe ich übrigens schon gelöscht. Aber man sollte die Reparatur wohl besser irgendwie koordinieren.

Ich reverte das mal, aber es wäre besser wenn jemand lokal den Rest anschaut.

Das Löschen eines Autobahnabschnitts ist ein typisches Beispiel, das den Mangel an Qualitätssicherungsmechanismen zeigt. Angenommen, ein Navi-Hersteller (ob kommerziell oder nicht) verwendet ungeprüft die Daten von irgendwann in dieser Woche, wird bis zum nächsten Kartenupdate (evtl. nie?) die Navigation in einem riesigen Gebiet schlechte Ergebnisse liefern. Somit sind die rohen OSM-Daten generell unzuverlässig und erfordern für den professionellen Einsatz ein groß angelegtes Post-Processing. Die Ergebnisse aus diesem fließen natürlich nicht zurück in die OSM, sondern jeder macht’s ein Stück weit schlechter oder besser oder gar nicht.

Wünschenswert ist die Qualitätssicherung auf API-Ebene. Fehler in Datenstrukturen (Relationen, Multipolygone usw.) muss die API zurückweisen bzw. an andere Mapper in diesem Gebiet weiterleiten. Die Kontrollmechanismen können beliebig komplex werden, beispielsweise mit zeitlichen Limits, wenn kein anderer Mapper drüber gesehen hat (z.B. automatische Sichtung nach wenigen Tagen).
Dieser Ansatz ist nicht neu und wurde schon paar Mal diskutiert, würde OpenStreetMap aber deutlich voran bringen.

Ja, sehe ich auch so.

Ich wäre schon glücklich, wenn ich die Änderungen in einem changeset mit dem Vorherigen vergleichen könnt und auch auf der Karte ein vorher-nachher Vergleich angezeigt bekäme… (Inklusive der gelöschten Punkte!)
Würde meine Zeit, die ich mit der Detektivarbeit nach Änderungen investieren muss, vermutlich um 90% senken und die Lust, mich ständig um schwachsinnige Änderungen zu beschäftigen erheblich steigern…

http://wiki.openstreetmap.org/wiki/Achavi kennst du aber??

Der Service ist auch pro changeset sehr gut über die beiden who-did-it Dienste für OSM nutzbar … siehe OSM-Wiki → Quality Assurance

hi, öhm, naja, versucht hatte ich das mal, aber ich bin gerade etwas erstaunt, dass es hier auf diesem Rechner tatsächlich funktioniert und daheim nicht…
Also ja, ich wusste, dass es da was gibt, aber nein, kannte das bisher nicht als funktionsfähige Lösung :roll_eyes:
Ich glaub, damit werde ich in Zukunft einige Zeit verbringen g Zumindest, wenn ich es daheim zum Laufen bringe…
Danke für den Hinweis.

Könnte ein “Löschen” von Neumapper nicht generell eingeschränkt werden - meist ist es unbeabsichtigt /unwissend. Mit einen Hinweis, das “Datenlöschungen” erst nach einer Anzahl Datenerfassungen / -änderungen möglich sind (ist m.E sinnvoll).

Nö. Was, wenn jemand wirklich etwas löschen will, weil es falsch ist?

Vor allem bei Geschäften, die häufig schließen und wieder öffnen, halte ich es für falsch, neuen Nutzern das Löschen zu verbieten.

Das ist der klassische Konflikt zwischen leichter Benutzbarkeit und Sicherung der Qualität und Auswertbarkeit.
Ich fürchte, das OSM-DB-Konzept wird irgendwann einer dieser beiden Tode sterben müssen, d.h. einer der beiden Konkurrenten muss Einschränkungen hinnehmen.

Auf die Spitze getrieben:
Was hilft eine Datenbank, die auch von Anfängern superleicht zu bedienen, aber wegen mangelnder Qualität nicht mehr verwendet werden kann?
Was hilft eine Datenbank, die zwar eine gute Qualität hat(te), aber unvollständig bleibt und veraltet, weil die Hürden für Korrekturen so hoch sind, dass die meisten resignieren?

Gibt es einen Weg dazwischen?

Wenn nicht gegengesteuert wird, läuft es jedenfalls schleichend auf den ersten Fall hinaus.

Ja, bisher geben wir der einfachen Benutzung den Vorzug… Man darf aber auch nicht vergessen, dass wir hier in Deutschland sehr viele Mapper haben, die sich super auskennen und ggf. sogar eine halb moderierte Datenbank betreuen könnten. Ausserhalb von Europa wird es schon sehr schwer sowas zu stemmen.

Aber ich bin auch der Meinung, dass wir irgendwann den Kompromiss finden müssen, zwischen der Datenqualität (und damit der Erhaltung der erfahrenen Mapper) oder von Quantität (mit der Gefahr, dass erfahrene Mapper keine Lust mehr haben, ständig zu korrigieren).
Ein Punkt wäre wohl, Küstenlinien und administrative Grenze von Staaten nur von einer authorisierten Gruppe ändern zu lassen. Andere stellen mit ihren Changesets dann eine Art “Änderungsantrag”. Nach Prüfung werden diese dann freigeschaltet.

Eine andere lösung wäre ein Sperrvorschlag, den 5 Mapper (mit x Änderungssätzen/…) zustimmen müssen. Änderungen können dann nur durchgeführt werden, wenn ein anderer Mapper (mit x Änderungssätzen) diese prüft.

Ich weiss, diese Regeln kann man so komplex machen, wie man will, von mir aus wäre auch nur denkbar, dass bestimmte Objekte mit einem Tag versehen werden können, die eine gesonderte Warnmeldung ausgibt: “Benutzer x hat dieses Objekt erstellt/geändert und prüft regelmäßig die Richtigkeit. Willst du trotzdem ändern?”. Das ganze dann gekoppelt an die Aktivität des mappers oder was weiss ich…

Ja, alles bringt Einschränkungen für ALLE mit sich, aber ggf lassen sich meine Vorschläge ja aufgrund einer BBOX auf gut entwickelte Gegenden beschränken.

Nahmd,

Die API kann nicht (ohne weiteres) zwischen einem “syntaktischen” Löschen, also Löschen eines Weges wegen Join mit einem anderen Weg, oder löschen eines POI-Nodes wegen Umwandlung zu einem POI-Way, also implizites Löschen als Seiteneffekt, und einem “semantischen” Löschen, also ersatzlosem Entfernen eines Objektes unterscheiden.

Ersteres sollte möglich bleiben, zweiteres könnte man limitieren.

Gruß Wolf

Es wäre der Qualität schon geholfen wenn es (wie bereits bei den Grenzen) eine systematische Kontrolle z.B. des Autobahn/Bundesstraßennetzes gäbe.

Als ich mit OSM (Potlatch) angefangen habe, habe ich auch nur ein paar Punkte eingetragen - dann ein Gebäude - wo ich das erste Mal bewusst etwas gelöscht habe, weiß ich nicht mehr. Meist ändere ich - und nutze es auch bei “POI-Nodes wegen Umwandlung zu einem POI-Way”.

Wenn ich aber eine Meldung “Löschen ist erst nach … Änderungssätzen möglich - bei Dringlichkeit nutze dazu Notes oder das Forum” hätte ich Verständnis dafür.

Hallo,

Das habe ich auch gesucht. Aber schau dir die Antwort selber an.

… oder ein Mangel an Mappern, die sich mit Qualitätssicherung mit WhoDidIt & Co. beschäftigen.

Oh wie schlimm! :slight_smile: Dafür bietet sich hier ein Geschäftsfeld – OSM-Premium-Daten. Das wären dann Datenextrakte (nach Region oder Themen gefiltert), deren Änderungen vom Dienstleister gesichtet werden.

Viele Grüße

Michael