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

Und wenn einer während der Wartezeit am selben herumdreht, gibt es den Konflikt aus verschiedenen Bearbeitungen, von denen kein Admin wissen kann, welcher richtiger ist :confused:

Gut, aber das ist ja aktuell auch nicht anders. Ich sage ja nicht, dass DAS dadurch automatisch besser wird: Vielmehr dachte ich erstmal nur an die Fälle, wo es einfach offensichtlichen Vandalismus, großflächige Löschugnen, etc. gab. Die fängt man so ab, ohne dass sie in der Map bzw. dem eigentlichen Datensatz landen. Klar, was ich meine? :slight_smile:

Aber aktuell lädt man die Daten auch schnell wieder hoch, da vergeht weniger Zeit, in der jemand anderes das selbe Objekt editieren könnte und somit zerlegt. 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, …)

Ich denke dass solche hypothetischen Probleme erst gelöst werden, sobald sie wirklich drängend werden. Bis jetzt gab es soweit ich weiß ja noch keine wirkliche böswillige Manipulationen der Daten, außer ein paar Kahlschlägen, oder?

Was sich mir nicht ganz erschließt, warum der API-Zugriff offenbar unbeschränkt ist, da kann man einfach mal so 30.000 Nodes löschen: http://www.openstreetmap.org/browse/changeset/19122846?way_page=12 oder 50.000 leere Nodes anlegen: www.openstreetmap.org/browse/changeset/19122607 Da könnte man sicherlich ein Limit einführen + Ausnahmegenehmigungen für Massenimporte durch die DWG oder andere (demokratisch bestimmte?) Entscheidungsinstanzen.

Aber wie gesagt, solange sich solche Sachen in Grenzen halten, wird wohl nicht viel passieren.

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?

Moins,

bevor der Backofen explodiert: wie wäre es, erst einmal ganz kleine Brötchen zu backen.

Ein Beispiel: man könnte die geometrische Wohlgeformtheit von type=multipolygon-Relationen auf dem Server durchsetzen. Das sollte technisch kein Hexenwerk sein (wobei ich die durch die Prüfung erzeugte Serverlast nicht beurteilen kann), und würde u.a. das Problem defekter Admin-Relationen und das “und täglich grüßt das Postleitzahlenfresstier” verkleinern.

Kostet aber.

Denn ein Editor sollte vor dem Hochladen den Test des DB-Servers vorwegnehmen, um Ablehnungen zu vermeiden. Wenig Probleme machen Split eines Weges (wenn das neue Teilstücke in die gleichen Rels kommt wie das Basisstück), Join mit einem Way exakt gleicher Relzugehörigkeit und Verfeinerung eines Ways durch Einfügen innerer Punkte: das alles kann ein wohlgeformtes MP nicht beschädigen.

Sobald aber ein Wegstück entfernt oder eines ergänzt oder verkürzt oder verlängert wird, muss das MP nachgerechnet werden. Das muss zum einen implementiert sein, zum anderen muss der Editor dazu alle (viele+lange) Wegstücke des MP laden.

Während der Arbeit an einem MP ist das MP (natürlich) nicht wohlgeformt. Was bei JOSM kein Problem ist (ich lade erst nach vollständiger Bearbeitung hoch, wenn das MP wieder ok ist), schränkt einen Editor wie iD, der Änderungen sofort hochlädt, ein: Wege, die Bestandteil eines MP sind, kann man weder löschen noch verkürzen, und aus einem Verlängern muss der Editor ein Ansetzen einer neuen Linie mit gleichen Attributen machen.

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

Gruß Wolf

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)

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

Aber soll man daher den Kopf in den Sand stecken?

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.