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.
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…)
Ü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.
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.
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:
Es muss sich erst einmal jemand einer Änderung annehmen und diese freigeben. So etwas sollte zeitnah passieren
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, …)
Ä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.
Nun, es gibt (wie immer) sehr viele Meinungen und ständig kommen Vorschläge und weitere Hinweise dazu. Das Thema ist hoch komplex.
Ich würde daher einmal einen Minimalvorschlag versuchen, um zumindest größere Fehler, die in der Vergangenheit häufiger passiert sind, zu erschweren:
Änderungen an bestimmten, markierten Objekten (Coastlines, Administrativen Grenzen und anderen Dingen wie Ortsnamen, Autobahnen und anderen für die Karte (unser Aushängeschild) essentiellen Bestandteilen werden für Mapper ohne X Erfahrung gesperrt. Will jemand mit weniger Erfahrung sowas Ändern, tut er das mit einem Beitrag im Forum mit der Angabe von Gründen. In der Regel ist das keine alltägliche Änderung und schon gar nicht von Mappern, die erst kurz dabei sind!
Das ist bereits mehr als genug um darüber zu diskutieren aber die meisten Einwände hier im Thread wären damit berücksichtigt. Neue Mapper können hinzufügen und ihre Änderungen “live” verfolgen, sofern sie nicht gerade essentielle Teile ändern. Ob es eine Erleichterung wäre, kann ich aber nicht beurteilen, weil ich mich bisher möglichst von diesen Objekten ferngehalten habe
Du diskutierst dort mit Leuten, die nicht dort waren wo Du warst, aber glauben mehr Ahnung zu haben. Und letztlich kommt dann irgend ein Vollpfosten und revertet im 4 Sekunden Takt, womit eine hohe Zahl Bearbeitungen auf dessen Konto gehen und somit seinen Status als jemand der Freischalten darf sichern. Deine ellenlangen Erklärungen kann so jemand gar nicht gelesen haben… Mein Schwarzwald-Schwäbische Alb-Allgäu-Weg ist dort neuerdings aus der Liste der Wanderwege Baden-Württembergs geflogen, und ich werde mir ganz sicher nicht die Mühe machen, das wieder zu korrigieren…
IMO ist aber der Gedanke “wir brauchen einen möglichst von jedem bedienbaren Editor um möglichst viele Mapper zu rekrutieren” ein Irrweg. Eine Hürde ist notwendig. Wer mitmachen möchte muss bereit (und in der Lage) sein sich in eine Thematik zumindest ein wenig einzuarbeiten. Ich sehe auch Werbung zum Mitmachen kritisch - ich muss nicht jedem nen Pinsel in die Hand drücken und sagen “male mal auf unserer Karte”; Die Leute, die hier mitmachen möchten, finden IMO auf eigenen Wegen zum Projekt. OSM hat m.E. keine Missionsaufgabe.
