OpenStreetMap Forum

The Free Wiki World Map

You are not logged in.

#1 2014-12-14 18:17:54

Prince Kassad
Member
Registered: 2013-10-18
Posts: 2,035

Die A5 ist zerstört!

Seht selbst:

https://www.openstreetmap.org/#map=15/5 … 1&layers=N

Wer hat die Autobahn da abgebaggert?

Offline

#2 2014-12-14 18:23:56

chris66
Member
From: Germany
Registered: 2009-05-24
Posts: 8,934

Re: Die A5 ist zerstört!


Nichtkommerzieller Mapper aus dem Münsterland.

Offline

#3 2014-12-14 18:27:52

Prince Kassad
Member
Registered: 2013-10-18
Posts: 2,035

Re: Die A5 ist zerstört!

created_by=iD 1.6.2

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.

Offline

#4 2014-12-14 18:36:37

Prince Kassad
Member
Registered: 2013-10-18
Posts: 2,035

Re: Die A5 ist zerstört!

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.

Offline

#5 2014-12-14 20:06:08

TourenbikerFKB
Member
From: Kreis Waldeck-Frankenberg
Registered: 2012-03-13
Posts: 221

Re: Die A5 ist zerstört!

Die "liebevollen" Details bei der freiwilligen Feuerwehr Mörfelden

https://www.openstreetmap.org/edit?edit … 68/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.

Offline

#6 2014-12-14 20:14:45

SimonPoole
Member
Registered: 2010-03-14
Posts: 1,631

Re: Die A5 ist zerstört!

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

Offline

#7 2014-12-14 22:00:48

derstefan
Member
From: OpenTopoMap
Registered: 2010-03-28
Posts: 478
Website

Re: Die A5 ist zerstört!

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.

Offline

#8 2014-12-14 22:14:09

chris66
Member
From: Germany
Registered: 2009-05-24
Posts: 8,934

Re: Die A5 ist zerstört!

derstefan wrote:

Somit sind die rohen OSM-Daten generell unzuverlässig und erfordern für den professionellen Einsatz ein groß angelegtes Post-Processing.

Ja, sehe ich auch so.


Nichtkommerzieller Mapper aus dem Münsterland.

Offline

#9 2014-12-14 23:46:41

ngt
Member
Registered: 2011-05-30
Posts: 180

Re: Die A5 ist zerstört!

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..

Offline

#10 2014-12-15 06:51:49

stephan75
Member
Registered: 2008-05-28
Posts: 2,713

Re: Die A5 ist zerstört!

ngt wrote:

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

Offline

#11 2014-12-15 09:56:31

ngt
Member
Registered: 2011-05-30
Posts: 180

Re: Die A5 ist zerstört!

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
Ich glaub, damit werde ich in Zukunft einige Zeit verbringen *g* Zumindest, wenn ich es daheim zum Laufen bringe..
Danke für den Hinweis.

Offline

#12 2014-12-15 10:15:05

geri-oc
Member
From: Sachsen
Registered: 2011-03-21
Posts: 3,861
Website

Re: Die A5 ist zerstört!

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).

Offline

#13 2014-12-15 11:33:16

SammysHP
Member
From: Celle, Germany
Registered: 2012-02-27
Posts: 1,496
Website

Re: Die A5 ist zerstört!

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

Offline

#14 2014-12-15 11:34:29

Prince Kassad
Member
Registered: 2013-10-18
Posts: 2,035

Re: Die A5 ist zerstört!

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.

Offline

#15 2014-12-15 12:16:34

seichter
Member
Registered: 2011-05-21
Posts: 2,442

Re: Die A5 ist zerstört!

Prince Kassad wrote:

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.

Offline

#16 2014-12-15 12:55:47

ngt
Member
Registered: 2011-05-30
Posts: 180

Re: Die A5 ist zerstört!

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.

Offline

#17 2014-12-15 13:04:32

Netzwolf
Member
Registered: 2008-04-01
Posts: 1,665

Re: Die A5 ist zerstört!

Nahmd,

geri-oc wrote:

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).

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

Offline

#18 2014-12-15 13:56:37

chris66
Member
From: Germany
Registered: 2009-05-24
Posts: 8,934

Re: Die A5 ist zerstört!

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.


Nichtkommerzieller Mapper aus dem Münsterland.

Offline

#19 2014-12-15 14:57:43

geri-oc
Member
From: Sachsen
Registered: 2011-03-21
Posts: 3,861
Website

Re: Die A5 ist zerstört!

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.

Offline

#20 2014-12-15 19:04:22

Nakaner
Moderator
From: Karlsruhe
Registered: 2011-09-03
Posts: 2,376
Website

Re: Die A5 ist zerstört!

Hallo,

ngt wrote:

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..

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

derstefan wrote:

Das Löschen eines Autobahnabschnitts ist ein typisches Beispiel, das den Mangel an Qualitätssicherungsmechanismen zeigt.

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

derstefan wrote:

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.

Oh wie schlimm! 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


Ein aussagekräftiger Änderungssatzkommentar ist gehört zum guten Ton.
Moderator im Bereich users: Austria.

Offline

#21 2014-12-15 21:47:10

Netzwolf
Member
Registered: 2008-04-01
Posts: 1,665

Re: Die A5 ist zerstört!

Nahmd,

Und Teufels Anwalt hob an und wrote:
derstefan wrote:

Somit sind die rohen OSM-Daten generell unzuverlässig und erfordern für den professionellen Einsatz ein groß angelegtes Post-Processing.

Cui bono?

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.

Das ist korrekt.

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.

Wünschenswert — für wen?

Ich sehe bei OSM eine arbeitsteilige Struktur:

1. Da sind die Fleißarbeiter, die Objekt nach Objekt zusammentragen und die Datenbank füllen, dabei aber auch immer wieder Dinge kaputtmachen.

2. Es gibt diejenigen (Deppen?), die den ganzen Müll — ähh sorry, Müll darf ich es ja nicht nennen — die Datenelemente suboptimaler Qualität in der Datenbank suchen und korrigieren. Die teils unnötige Arbeit erbringen, denn viele Fehler wären technisch verhinderbar oder automatisch korrigierbar. Die aber selbst keinen Zugriff auf einen sauberen Datenbestand haben, alldieweil sie nicht wissen, an welchem anderen Ende der Welt wieder Müll, — ähh, sorry — Daten nicht optimaler Qualität™ — uff! — eingestellt worden sind. Und ihre Zeit in das Fixen der Fehler stecken statt in das Nutzen der Daten. Die also (etwas übertrieben ausgedrückt) nichts von ihrer Reparatur-Arbeit haben, sich also zum Deppen machen für:

3. (natürlich rein hypothetisch) diejenigen, die aus den OSM-Rohdaten Daten von zwar nicht garantierter, aber deutlich höherer — kommerzieller? — Qualität gewinnen, indem sie (natürlich an den Haaren herbeigezogene Beispiele) im Kleinen statt auf aktuelle, aber defekte Versionen von Objekten auf zwar veraltete, aber korrekte Versionen zurückgreifen oder im Großen massive Änderungen erst mit Verzögerung übernehmen im Vertrauen darauf, dass Schädigungen von den "Deppen" aus 2. kurzfristig repariert werden. Und das Ganze ist stabil wegen:

4. denjenigen, die sich einer technischen Durchsetzung auch nur minimaler Qualitätskriterien wie geschlossenen Polynomringen widersetzen, sie verschleppen, oder schon die Idee ins Lächerliche ziehen.

Darauf schwieg er.

Möglicherweise ist der Grund für die fehlenden auch nur minimalen Sicherungen gegen defekte Daten die Angst vor den Folgekosten: die Fehler landen nicht mehr bei den "Deppen", sondern direkt über das User-Interface der Editoren bei den Eingebern und könnten diese verschrecken oder Nacharbeiten am iD nötig machen. Oder ganz simpel ein Mangel an Mitarbeitern bei den Betreuern der API. Letztere Hypothese ließe sich im Experiment testen, indem ein wirklich PostGIS-Kundiger sich um eine erste Implementierung bewirbt und man dann die Reaktion analysiert.

Gruß Wolf

Und jetzt: Popcorn!

Offline

#22 2014-12-15 22:49:38

MKnight
Member
Registered: 2012-08-01
Posts: 1,697

Re: Die A5 ist zerstört!

Netzwolf wrote:

[...]die Fehler landen nicht mehr bei den "Deppen", sondern direkt über das User-Interface der Editoren bei den Eingebern und könnten diese verschrecken oder Nacharbeiten am iD nötig machen.

Beim iD-Scheisse-finden bin ich gern immer ganz vorn dabei, aber Potlatch ist zwar ausgereifter und komplexer, eine Prüfung auf Konsistenz oder auch nur irgendwas gibt es genauso nicht. Ich kann dort gefahrlos und ohne was zu merken genauso löschen wie in iD.

Ich hätt allerdings auch noch Ideen zum Thema. Is imho ganz einfach. Wenn ich in jOSM ein Stück Autobahn lösche, dann werde ich (zu Recht!) angeraunzt, dass ich aus einer Relation etwas entfernen möchte.
Wäre - wenn ich grad nix übersehe - die einfachste Restriktion. Programme, die das nicht anmeckern, dürfen keine in Relationen enthaltenen Objekte löschen. (Ok, meiner Meinung nach dürften Programme ohne Fehlerprüfung gar nichts hochladen, aber das wäre mal ein Anfang...)


gesammelte Overpass-abfragen zu QA (hauptsächlich Strassenfehler) + verschiedene Stats zu Strassen-eigenschaften

Offline

#23 2014-12-15 23:06:22

Prince Kassad
Member
Registered: 2013-10-18
Posts: 2,035

Re: Die A5 ist zerstört!

Übrigens scheint der Revert nicht ganz reibungslos verlaufen zu sein, einige Relationen sind da wohl in die Brüche gegangen, z. B. die Darmstädter Buslinie AIR.

Offline

#24 2014-12-15 23:14:10

Netzwolf
Member
Registered: 2008-04-01
Posts: 1,665

Re: Die A5 ist zerstört!

Nahmd,

MKnight wrote:

Beim iD-Scheisse-finden bin ich gern immer ganz vorn dabei,

Es geht mir nicht ums iD-Bashing. Sondern: wenn die API Constraints durchsetzt, dann *gegen den Editor*. Der bekommt die Fehlermeldung von der API und muss damit zurechtkommen. Die Situation gibt es heute schon, auch mit JOSM, nämlich wenn man ein Objekt löscht (auch implizit), das Bestandteil einer Relation ist, die nicht geladen war. JOSM bietet in dem Fall eine Möglichkeiten zur Reparatur.

Mit einer Meldung: “nehme Relation nicht an, weil zwar type=multipolygon, aber Ways nicht geordnet oder keine geschlossene Ringe” muss der Editor zurechtkommen. Am besten, indem er *vor* dem Hochladen die Relation prüft und (anders als der Validator) bei erfolgloser Prüfung das Hochladen *verweigert* (würde ohnehin scheitern) und dem Benutzer sagt, was zu tun ist. Das in den JOSM einzubauen stelle ich mir vergleichsweise einfach vor, weil die Komponenten da sind. Aber auch eine an den Benutzer durchgereichte Fehlermeldung wäre erträglich: Relationseditor aufrufen und "Sort!", das kann man lernen.

Die geringe Einstiegshürde beim iD dürfte aber durch ein API-Constraint nicht leiden, und ich stelle es mir reichlich anspruchsvoll vor, einem Gelegenheitsbenutzer beim Schließen eines offenen Ringes zu assistieren.

Gruß Wolf

Offline

#25 2014-12-15 23:15:41

aromatiker
Member
Registered: 2009-05-16
Posts: 291

Re: Die A5 ist zerstört!

Ein paar Pfennige von mir dazu:

Wikipedia hat einen Mechanismus, der jedermann Änderungen an den Artikel gestattet. Öffentlich sichtbar werden diese jedoch erst, wenn ein "Erfahrener" die Änderungen freigibt.

Einerseits finde ich diesen Ansatz ganz gut: Änderungen sind weiterhin durch jedermann möglich.
Andererseits hat ein solcher Ansatz auch seine Schwächen:
1. Es muss sich erst einmal jemand einer Änderung annehmen und diese freigeben. So etwas sollte zeitnah passieren
2. Hier kommt dann auch leicht so etwas wie Zensur in's Spiel: Der Freigebende kann Kraft seines Amtes Änderungen ablehnen (zu banal, nicht gut genug, ...)
3. Änderungen wären dann nicht mehr direkt sichtbar. Damit entfällt für viele der Spaß am Verbessern, da nicht mehr (sofort) sichtbar

Ich habe auch keine Ahnung, wie aufwendig der technische Aspekt wäre:
- Zum einen müssten in der DB dann Changesets in einem weiteren Status (nicht freigegeben) verwaltet werden
- Diese Sets müssen allen Tools entsprechend behandelt werden (Renderer, Editoren, ...)
- Sind diese Daten dann zum Edieren für Andere sichtbar ?
- Was passiert, wenn jemand (vor der Freigabe) Teile des Changesets nochmals ändert ?

Zu den Editoren und deren Möglichkeiten / Freiheiten (oder wie immer das nennen möchte):
Nach meinem Verständnis sind die Editoren (JOSM, Potlatch, ID, ...) nur Frontends für die DB. Alle Informationen und Abhängigkeiten sollten in der DB abgebildet und auch geprüft werden.
Das betrifft insbesondere komplexe Dinge wie Ralationen.
Daher müssten solche Daten an der API geprüft und ggf. zurückgewiesen werden.
Soweit ich bislang verstanden habe, macht diese Arbeit jedoch der Editor selbst. Damit kann eine Fehler in dessen Implementierung ebenfalls sehr schnell Daten zerstören (siehe Fehler in den Coastlines bzw anderen Relationen).
Auch an dieser Stelle könnte eine Änderung eine erhebliche Verbesserung der Qualität durch eine Reduzierung der Fehlerquellen mit sich bringen.

Offline

Board footer

Powered by FluxBB