Bestimmte Objekte für Bearbeitungen sperren

Blöde Frage vielleicht, aber wäre es eventuell nicht sinnvoll manche Dinge, die quasi korrekt sind und sich erstmal auch nicht ändern werden, für Bearbeitungen zu sperren? Bspw. würden mir da teilweise Gemeindegrenzen einfallen. So könnten Leute ausversehen oder mutwillig nicht mal kurz alles über den Haufen werfen. Gut, es wird natürlich nicht unbedingt leicht, da Objekte auszumachen, die man sperren könnte, auch wäre es evtl. möglich unterschiedliche Sperrstufen einzubauen, bspw. Dinge die mehr oder weniger komplett gesperrt sind und dann Objekte, die für Neulinge gesperrt sind.

Wäre so etwas grundsätzlich nicht möglich?

Nein. Das würde gegen die Prinzipien von OSM verstoßen.

Derzeit ist das nicht mörglich!
Das erste Problem wäre zu klären wer darf sperren und wer darf es wieder rückgängig machen?
Das Objekte wie Grenzen sich selten ändern ist zwar richtig, insbesondere wenn die Grenze zu Staaten gehören, aber wer sagt denn das der eingezeichnete Verlauf korrekt ist. Vielleicht mißbraucht ein Mapper diese Daten auch wie das Nametag um etwas in seinem Sinne darzustellen. Vielleicht seinen eigenen Staat in der Antarktis. Dort sind ja schon mehrere Städte aus dem Nichts entstanden.

Naja, da müsste man sich natürlich Gedanken machen wer das sperren darf. Irgendwelche Nutzer mit Sonderrechten halt. Die könnten ja bspw. gewählt werden und müssten eine gewisse Erfahrung haben.

Es vergeht kaum eine Woche, in der nicht eine Grenze im OSMI kaputt ist. Wohlgemerkt, dort werden nur komplett fehlerhafte Grenzen angezeigt. Die Grenzen die nur so durch Verschieben von Linien/Punkten nicht mehr richtig sind fallen gar nicht auf und es sind vermutlich noch viel viel mehr!
Deshalb finde das die Idee an sich grundsätzlich erstmal nicht so schlecht. Klar, es passt nicht so ganz zu den Prinzipien von OSM, aber wie läuft das bei der Wikipedia? Da werden die Einträge doch auch irgendwie von den “Super-Leuten” vorher kontrolliert oder zumindest überwacht.

Mögliche Lösungen wären mMn eine bessere Überwachung von Grenzen. Oder aber, dass bestimmte Objekte nur editierbar sind, wenn man es gesondert anklickt, so etwa wie wenn man sich zusätzlich die GPS-Spuren herunterläd. Das kann einen gewissen Schutz gegen ungewolltes zerstören/verschlechtern der Daten beiten. Mit einem solcher Haken sind die Objekte jederzeit bearbeitbar, doch der Schutz gegen ungewollte Zerstörung verbessert sich immens. Wenn alles erlaubt bleibt, bzw. ganz einfach möglich ist, und es keine ausreichend funktionierende Qualitätskontrolle gibt, gibts am Ende noch mehr Datensalat, so dass man den Daten nicht mehr trauen kann.

Ich zähle zu den Grenzen zB auch die Naturschutzgebiete, die werden wie die administrativen Grenzen einmal eingezeichnet und bleiben Jahrzehnte richtig bestehen.

Ich glaube, für solch ein Feature bräuchte man einen neue API-Version, die derzeit nicht in Sichtweite ist. Trag doch deinen Vorschlag auf der Brainstorming-Seite dafür ein bzw. schau nach, ob ihn nicht schon jemand eingetragen hat. :slight_smile:

Ich persönlich denke, dass das XML, das die API ausliefert einfach ein Attribut preserved=yes (oder so ähnlich) enthalten sollte. Die API sollte Objekte, die in der Datenbank ein preserved=yes haben, dann nur ausgewählten User-Agents zum Editieren freigeben. iD & Co. sollten keine Freigabe erhalten.

Master, ich kann Deinen Frust gut verstehen. Sperren wurde ja schon oft diskutiert, und jedesmal kommt heraus, dass das nicht erwünscht ist, um neue Benutzer nicht abzuschrecken.
Kleiner Lichtblick am Horizont ist Oli-Wans Tool. Wenn das je mal fertig werden sollte, könnte da gleich was aufpoppen wenn irgendwo eine Grenze angefingert wird. Bis dahin, bleibt wohl nur beten.

Finde ich sehr gut! Quasi eine Warnung: “Achtung, geschütztes Objekt. Sind Sie sich sicher, dass Sie es bearbeiten wollen?”
Das macht keinen zum potentiellen Diktator und verbessert unbeabsichtigte Veränderungen.

Sollte man mal an die oberen Herren weitergeben, die sowas implementieren könnten.

Ich denke auch das es wesentlich sinnvoller wäre das nicht über bestimmte Sonderrechte in der DB sondern über die Editoren zu regulieren. Hätte auch schon ein paaar konkretere Ideen dazu, aber wo trägt man so einen Wunsch denn am besten an alle Editor-Authoren, bzw. zur allgemeinen Diskusion an die Community, herran?

Für JOSM hier: http://josm.openstreetmap.de/newticket

+1

Die Frage ist: Welchen Sinn macht es, bei dem “Standard” Editor iD überhaupt über sowas nachzudenken? Dort werden ja noch selbst ganz bodenständige Warnungen wie sie in den anderen Editoren bereits drin sind abgelehnt, um Neulinge beim Zerstören von Daten nicht zu verunsichern (oder so ähnlich :slight_smile:

bye, Nop

Schließt ja nicht aus, dass man es in JOSM implementiert.

Ich denke da an die Warnung nach dem Motto “Sie haben eine Linie mit mehr als 20 Punkten verschoben. Wollten Sie das”? Selbst als erfahrener Mapper kann man genug unbeabsichtigte Fehler machen.

Wie man es implementiert ist hier Auslegungssache. Dass sowas sinnvoll wäre, steht außer Frage. Es macht keinen Sinn Unfall-Tools zu entwickeln, ohne Unfälle zu vermeiden.

Ich fände sinnvoll, dass solche Objekte nur dann angezeigt oder erst heruntergeladen würden, wenn der Mapper entsprechend Erfahrung gesammelt hat (Anzahl der Edits) und den
Erweiterter Bearbeitungs-Modus: Objekte sichtbar machen, die in der Regel nicht bearbeitet werden müssen
-Knopf gefunden hat.
Das braucht aber auch Mitarbeit der API
Fatal wird es natürlich, wenn die Grenzrelation oder deren Weg an Wiesen/Straßen/Gewässer geheftet wurde

Meine Rede
Wer es trotzdem probieren mag: hier entlang.

Bei Potlatch muss man schon selbst einen Patch einreichen, wenn man etwas geändert haben möchte.

OT-Tipp: Man kann die Einstellung warn.move.maxelements auf 2 setzen um versehentliche Verschiebungen von Ways unabhängig von der Node-Anzahl zu vermeiden.

Jep ganz genau, für diese Funktionalität sollten die Grenzen nicht mit anderen Knoten/Wegen verknüpft sein. Dann müssten die API das Überwachen. Und natürlich unmittelbar vor dem Einführen der Funktion müssen alle Grenzen eigene Knoten und Wege bekommen.

Es hat nicht wirklich was mit Erfahrung zu tun, auch mir passiert das immer wieder, man verschiebt eine Straße oder Fluß und darunter ist eine Grenze, die man nicht sieht. Für JOSM könnte man - falls eine eigene Ebene nicht geht - zumindest eine Warnung einbauen. Ist manchmal auch nicht einfach, gestern habe ich einen Grenzfluss in den USA eingezeichnet, und versucht die Punkte immer neben die Grenze zu legen, was nicht immer klappt, trotz niedrig gestellten Fang.

Taste “Strg” gedrückt halten, dann snappt er nicht. Falls noch nicht bekannt. :sunglasses:

Und noch ein Pro-Tipp: Bei Grenzbearbeitungen nur Grenzobjekte laden (z.B. per OPAPI) oder andere Objekte per Filter deaktivieren oder ausblenden (mit [Alt]+[Shift]+[F] den Toggle Dialog einschalten und einen Filter mit "boundary=" hinzufügen). Ersteres geht allerdings etwas davon aus, dass Grenzen nicht mit anderem zusammenhängen oder diese Stellen zumindest per note= gekennzeichnet sind.

Und noch ein hoffentlich besser bekannter: Vor dem Splitten eines Ways immer die Elternelemente des Ways und seiner Endnodes(!) laden, um defekte Relationen zu vermeiden.

Und wenn ich schon dabei bin: Beim Umdrehen eines Ways sowie beim Mergen von Ways sollte man sich extrem sicher sein und ggf. alle damit in Verbindung stehenden Nodes bzw. Relationen prüfen. Das sind die beiden Aktionen, die meiner Erfahrung nach die Gefährlichsten sind (wegen des gleichzeitigen geringen Nutzens).

Aber du hast recht: Auch wenn man solche Tipps kennt kann einem sowas mal passieren.