[Talk-de] Potlach // Baukasteneditor // RFC: Einschraenkung durch Relationen?

Bernd Raichle bernd at dante.de
Mo Jan 21 09:40:28 UTC 2008


On Saturday, 19 January 2008 18:52:22 +0100,
Christian Koerner <misk at gmx.net> writes:
[...]

 > Eine Idee die mir schon seit einiger Zeit im Kopf rumschwirrt, ist das
 > Sperren von Wegen durch die Verwendung von Relationen. Wir haben sie
 > nun mal, warum sollte man sie nicht sinnvoll nutzen?!
 > Sieht man den Streckenverlauf einer Autobahn oder eines
 > Autobahnabschnitts als 'sicher' an, da die Wege nicht
 > von den (sagen wir mal 50) vorhandene GPS-Traces abweichen, legt man
 > eine Relation fuer die Autobahn an.
 > 
 > type=lock
 > 
 > Die 'sicheren' Wege gibt man als Mitglied (Member) der Relation an, die
 > Rolle/Funktion koennte 'node_position_lock', 'name_edit_lock',
 > 'ref_edit_lock' und so weiter sein, um die Verschiebung von Nodes, das
 > Bearbeiten des 'name'- bzw. des 'ref'-Tags zu verhindern.

Wann definiert man einen Wegabschnitt als "perfekt", aehm :-), "komplett"?
Momentan fahre ich bspw. einige Strecken ab, nicht um die Wege
einzupflegen, denn der ist bereits komplett, sondern um Dinge wie
Bruecken, Tunnel und Dinge laengs des Weges (Tempolimits und sonstige
Schilder) aufzunehmen und dann nach und nach einzupflegen.

Und beim Einpflegen derselbigen habe ich auch schon einige Dinge von
anderen "zerstoert", so dass auf der Slippy-Map Strassenteile nicht
mehr sichtbar waren (mein beliebtester Fehler ist "layer=+1" statt
"layer=1").


 > Die Aenderung von gesperrten Wegeigenschaften erfolgt erst nachdem ein 
 > Dialog mit einer Warnmeldung positiv bestaetigt wurde.
 > Oder, der Benutzer der die Relation anlegt wird automatisch ein Mitglied
 > der Relation mit der Rolle 'editor', weiteren Mitgliedern kann das
 > Aendern gestattet werden, in dem sie mit in die Relation
 > aufgenommen werden und ihnen die Rolle 'editor' zugewiesen
 > wird. Voraussetzung ist dafuer, dass Benutzer(-IDs) Mitglied einer
 > Relation werden koennen.

... und dass die Low-Level-API diese Art von Sperren dann auch
umsetzt, denn notfalls kann ich mit einfachen REST-Anfragen sehr
leicht viel Unheil anrichten!


[...]
 > 
 > Das sind nur ein paar Ideen, sollte jemand der Meinung sein, dass
 > sich etwas sinnvoll daraus entwickeln laesst, wuerde ich eine
 > 'Relations/Proposed/Lock'- oder 'Relations/Proposed/Locking'-Wikiseite
 > anlegen, auf der man diese und weitere Ideen diskutieren koennte.

Prinzipiell eine gute Idee, aber ich bin mir nicht so ganz sicher, ob
Sperren der richtige Weg ist oder nicht doch eher so etwas wie eine
Freigabe von Aenderungen nach einem Review der fuer ein Gebiet
und/oder fuer einen Object-Typ Verantwortlichen.  Mit letzterem sperrt
man niemanden aus, da die Aenderungen vorlaeufig aber dennoch sichtbar
sind, sondern sorgt nur dafuer, dass Aenderungen einen Review-Prozess
durchlaufen, bevor sie "permanent" werden.  Und wenn sich fuer ein
Gebiet niemand als Reviewer findet, wenn sich also niemand
verantwortlich und/oder auf den Schlips getreten fuehlt, dann darf wie
bisher "wild" geaendert werden.

Ich hege aber Zweifel, ob dies per Relations geloest werden sollte
oder nicht gleich in die OSM-API und die Datenbank rein muss, damit
_alle_ Editoren diese Freigabe (oder Sperren) implementieren.
Ansonsten wird es sicherlich bald dieselben Klagen wie jetzt geben ...



Gruss,
  -bernd




Mehr Informationen über die Mailingliste Talk-de