OpenStreetMap Forum

EvanE

Member

Registered: 2009-11-30

Posts: 5,716

Re: Mama, jemand hat die ganze Mittelrheinregion rosa angestrichen..!

Geänderte Objekte zu sperren, bis sie von jmd. anders bestätigt wurden dürfte wohl auch nicht wirklich praktikabel sein (z.B. bei Grenzrelationen, ...)

Denke auch, dass das nicht praktikabel ist. Aber warum gibt es beim Upload nicht einfach einen Fehler, wenn z.B. eine Grenzrelation nicht (mehr) geschlossen ist?

Ganz einfach, die API ist dumm, sie verwaltet nur die Objekte und deren Geschichte. Sie stellt keine Beziehung zwischen Objekten her, das wäre sehr aufwändig und würde die DB-Server sehr wahrscheinlich leistungsmäßig weit überfordern.

Was die Grenzrelationen angeht, so sind die in der Regel nur bruchstückhaft überhaupt im Fokus. Von daher ist es ausgesprochen schwierig festzustellen, ob die vollständig und geschlossen sind oder nicht. Es klingt so einfach, ist aber in Realität eher komplex.

Edbert (EvanE)

Gehrke

Member

From: Bremen, DE

Registered: 2013-10-19

Posts: 1,894

Website

Re: Mama, jemand hat die ganze Mittelrheinregion rosa angestrichen..!

Um mit Fred Sinnowatz zu sprechen: "Das klingt alles sehr kompliziert."

Aber soll man daher den Kopf in den Sand stecken?

seichter

Member

Registered: 2011-05-21

Posts: 3,337

Re: Mama, jemand hat die ganze Mittelrheinregion rosa angestrichen..!

Schon diesen simplen Schritt in Richtung einer konsistenteren DB (der kleinste, der mir eingefallen ist) bezahlt man teuer: mit Entwicklungsarbeit und mit Einschränkungen bei der Editierbarkeit.

Will man den Preis der Müllvorbeugung nicht bezahlen, so wird weiterhin Müll hochgeladen und man bezahlt für die Müllentsorgung. Oder hofft, dass es genügend freiwillige Müllwerker gibt.

Das ist ziemlich genau das Dilemma.

Mein Vorschlag war als Denkanstoß gedacht. Zur Verdeutlichung:
Es ist klar, dass jede Aktion, die ein unstable/preliminary Objekt einbezieht, selbst mindestens unstable bleibt, bis dieses stable geworden ist. Dasselbe gilt unweigerlich für beanstandete/verworfene Objekte. Diese Eigenschaften werden ebenfalls "vererbt".
Um ein lawinenartiges Anwachsen dieser Objekte zu verhindern, darf auf keinen Fall auf beabstandete Objekte aufgebaut werden, live-Objekte (und damit potenziell beanstandbare) müssen deutlich erkannt werden können.
Die Karenzzeit wäre ein sehr kritischer Parameter: Ist sie zu kurz, wäre nichts gewonnen, ist sie zu lang, wird die Aktualisierung der Daten bis zum Stillstand ausgebremst.

Der momentane Zustand ist auf schnelle, problemlose Aktualisierung mit kaum vorhandener Absicherung ausgelegt (Paradebeispiel iD). Das erinnert mich ein bisschen an SMTP, wo Spam den eMail-Dienst fast zum Erliegen gebracht hatte, weil es halt so simpel und angreifbar war.

So weit ich verstanden habe, ist auf die Schnelle wohl wenig auszurichten, ignorieren ist aber auch nicht die richtige Strategie.

Die OSM-Community sollte sich mMn aber ernsthaft mit dieser Problematik befassen: Die mir bekannten Vandalismus-Aktionen waren ziemlich primitiv und mit "relativ wenig" Aufwand revertierbar. Ein ausgefeilter bösartiger Angriff könnte die Datenbank um Wochen oder Monate zurückwerfen.