Wenn’s da nicht aufgelistet ist, macht’s vermutlich auch keinen Sinn, oder? Die Wikis sind vielleicht kein Regelbuch, aber doch sehr ausführlich.
“yes” ist der Normalfall (siehe auch Diskussion auf Seite 1)
“no” ist Unsinn, wenn der Platz nicht zugänglich ist, brauche ich ihn nicht zu mappen
“permissive” macht bei einem Spielplatz auch nicht viel Sinn, bei einer Freigabe durch den Owner gilt zumindest temporär “yes”, also Normalfall, sollte der Owner seine Genehmigung zurückziehen, ist es “private” oder “customer”
“permit” ist bei einem Spielplatz in der Praxis kaum vorstellbar, es sei denn, bei einer Luxusanlage und das ist dann wohl eher ein “theme_park”
Dann kann er weder yes noch irgend was anderes zuordnen, wenn er das Wissen nicht hat …
Oder es hat einfach noch niemand eingetragen. Oder jemand hat es ohne Nachfrage gelöscht. Oder…
Und wenn ein Spielplatz aus welchen Gründen auch immer längerfristig/auf unbestimmte Zeit gesperrt ist? Kontamination festgestellt oder Senkungsgebiet und die tatsächliche Gefährdung muss erst untersucht werden, etc… Und was otg vorhanden ist, kann und soll gemappt werden.
Natürlich. Wenn die Benutzung lediglich geduldet wird, ist das access=permissive.
Ich verwende außerdem access=customers für Spielplätze, die nur Kund:innen einer Einrichtung zur Verfügung stehen.
Youah … das gilt dann aber für alle Informationen im Wiki - entweder haben die richtungsgebenden Character oder eben nicht, weil jeder drin rumbasteln kann.
Das stimmt natürlich - in seltenen Fällen werden Spielplätze auch mal wegen defekter Geräte geschlossen, wenn der Owner (im Regelfall notleidende Gemeinden) kein Geld für die Instandsetzung hat.
Klar, in der Theorie auf jeden Fall, ist mir in der Praxis bei Spielplätzen aber noch nie begegnet. Wenn z.B. ein Spielplatz zu einer Wohnanlage gehört, aber nicht als solcher gekennzeichnet ist (Schild: "Nur für Bewohner der Häuser *), wird jeder ihn als öffentlich zugänglich betrachten. Um den Zustand “permissive” eindeutig festzustellen, müsste eine entsprechende Beschilderung (“Nur für Bewohner der Häuser * … aber bis auf weiteres für die Öffentlichkeit freigegeben” o.äh.)vorhanden sein. Gibt’s das im real life?
Ich muss dafür nur ca. 200m laufen: Spielplatz auf dem Schulhof einer Grundschule der nachmittags auch für Kinder freigegeben ist, die nicht zu dieser Schule gehen, und ein bestimmtes Höchstalter nicht überschreiten.
Oder währe das eher ein Fall für access:conditional mit max. age und opening hours?
Als einzelne Person, ist meine Reichweite natürlich begrenzt und es muss in vielen kleinen CS getarnt werden, aber als organisiertes Team geht das schon viel besser. Wenn jetzt Editor-Software das auch noch anmahnt und/oder mehr oder weniger im Hintergrund macht, ist es bedenklich.
Ich nehme mal an, ein großer Teil der access=yes wurden ohne einen Blick ins Wiki gesetzt.
Es ist doch ein großer Unterschied, ob ich was per Hand eintrage oder ob mich die Software dazu einlädt und ja auch bei SC erwarte ich mehr Kommunikation im Voraus.
Wenn es unklare Definitionen gibt, sollten wir die verbessern oder verfeinern. Dafür haben wir die Diskussionskanäle und am Ende das Proposal. Einfach bisher kaum genutzte Tags, die auch noch andere Tagdefinitionen beeinflussen bis verändern, als offiziellen Tags zu promoten ist Murks.
Die beiden Beispiele sind eindeutiger und ich kann sie belegen, aber das Thema ist zumindest bei cycleway=both das gleiche. tram_crossing ist eher iD, aber ein sehr gutes Beispiel.
Wie sich oben ja schon rausgestellt hat bringt das access=yes SC eigentlich kein Stück weiter, sondern verhindert viel eher, dass eine Abfrage häufiger gestellt wird. Dann Frage ich mich jetzt wozu das ganze?
+1, leider fehlen hier aber auch häufig Links zu den Diskussion oder eine kurze Zusammenfassung des Ergebnis.
Es ist eine von mehreren Quellen und eher Richtlinien als Gesetzte. Wie jedes andere Wiki, sollten die Diskussion, welche eventuell auch nur auf anderen Seiten oder Mailinglisten geführt wurden, gelesen werden. Die zitierten Quellen selbst anzuschauen ist auch nicht schlecht.
Ich habe erst neulich die Vorlagen von Kraftwerken und von Pumpen in JOSM überarbeitet. Das ging super, da es angenommen Proposals gab und klare Wiki-Seiten. Zusätzlich habe wir auch direkten Kontakt mit der Person, welche die Proposal eingebracht hat.
Wenn ich mir da andere Seiten, wie z.B. die Barriere-Tags, anschaue, ist es wesentlich schwieriger. Da musste ich erst einigen Aufwand betreiben, um die Informationen, wie Status, zu überprüfen und Diskussionen zu finden.
Der eigentliche Koden ist nicht so kompliziert bis auf das Icon, die meiste Zeit braucht es aber meist, sich einen Überblick über den Tag zu machen.
Natürlich. Das ist doch die Stärke dieser SC App. D.h. ja nicht, dass die Quest ohne Blick ins Wiki erstellt wurde. Hmm, schaust du bei jedem Setzen eines Access Tags an ein Objekt ins Wiki?
Kommunikation im Voraus würde was genau bedeuten? Meinst du der App-Nutzer soll erfahren, was seine Antwort für Auswirkungen auf die DB hat außer das der Spielplatz nun als öffentlich geführt wird? Wie genau sollte das gehen? Dass der Nutzer erstmal eine Textwand bekommt, die er lesen und dann akzeptieren drücken muss? Was nie einer tun würde. Ich wüsste nicht wie so etwas sinnvoll umgesetzt werden soll. JOSM nimmt auch nicht gerade an die Hand und sagt mir, was passiert, wenn ich “Ausgewiesener Radweg” auswähle. Analog dazu iD. Die Tags sind dann anschließend einfach da. Ich kann sie noch bestaunen, aber wenn ich keine Ahnung von den Tags habe, nützt es mir nichts.
Deswegen wäre es cool, hier einen wirklichen Verbesserungsvorschlag zu bekommen.
Im Falle das die Objekte eben ewig nicht geändert werden, ist es doch nicht so. Nur in dem von dir konstruierten Sonderfall mit dem Teilen eines Fuß-/Radweges. Das ist wie gesagt nur ein Sonderfall und nicht der Normalfall. Wie oft wird ein Spielplatz geändert nachdem access=yes hinzukommt? Ich denke auch, dass das ein Sonderfall ist. Weiterhin würde es doch nichts bringen, die Abfrage häufig zu stellen im Vergleich dazu wie sich diese Begebenheit (access yes) ändert.
Also mir ging es drum, dass Editoren wie bspw. iD und oder SC oder sonstwas vorher fragen und dokumentieren müssen, ob Tagging-XY ok ist für die Community (oder nicht!) und nicht irgendwas erfinden, das der “App-Nutzer(!)” anhaken kann oder nicht. Ich glaub Du hast da sowohl bei skyper als auch bei mir was komplett falsch verstanden. (vorausgesetzt, ich verstehe skyper richtig ;))
Man kann eben NICHT erwarten, dass $User vorher ins Wiki schaut, ob TaggingXY etabliert ist. Das ist nicht schön, aber völlig ok.
Wenn mir aber als Noob eine Software unter die Arme greift, dann gehe ich (als Noob) davon aus, dass das schon seine Richtigkeit hat und/oder dass das Usus und wichtig ist hier oder dort einen Haken zu setzen.
P.s. Die Talsohle von solchen Schnellschüssen war meiner Meinung nach erreicht, als iD name_1, amenity_1 und dergleichen Blödsinn in die DB gekackt hat.
Youah, genau das ist auch mein Anliegen gewesen. Dass die User theoretisch jeden Unsinn taggen können, den man sich vorstellen kann (man braucht ja nur mal einen Blick in die TagInfo eines beliebigen Keys werfen …) ist eine Sache und auf Grund der OSM Struktur vermutlich kaum zu vermeiden, aber dass ein Editor den unerfahrenen User im Prinzip dazu auffordert, unerwünschte oder zumindest strittige Attribute zu setzen, könnte m.E. durch eine entsprechende Abstimmung vor dem Release vermieden werden.
Das ist ja schön und gut. Und jeder möchte gerne gefragt werden bevor etwas in die DB kommt. Aber wie stellt man sich das in der Praxis vor? Das ist mir nicht konrekt genug, als dass man mit diesen Infos irgendeine App/Editor verbessern könnte.
Dann sollte aber für die Neumapper, die dort Rat und Regeln suchen, oben auf jeder Seite stehen “Bitte nicht dran halten … das sind keine Mappingregeln, sondern nur Diskussionsnotizen.”
Leider blicke ich noch nicht wirklich durch, wie das ganze OSM Gebäude strukturiert ist oder auch nicht. Daher kann ich keine konkreten Vorschläge machen, wie diese Handling in der Praxis verbessert werden könnte. Aber Kommunikationsplattformen gibt es ja genug. Es gibt daher sicher Möglichkeiten für die Entwickler, neue Editoren oder neue Releases der Community vorzustellen, falls das nicht ohnehin in irgendeiner Form geschieht.
Ich bin da wohl nicht das beste Beispiel, denn ja, ich lese viel im Wiki und habe u.a. etliche “access”-Wikiseiten auf meiner Beobachtungsliste.
+1
Sprache und das Verstehen kann ja richtig kompliziert sein, aber immerhin eine Person hat mich wohl verstanden.
Als Konstrukt wurde ich den Fall des Ändern des Objekttypen halten, aber darüber haben wir noch gar nicht geredet. Das Teilen von Wegen als Sonderfall dazustellen ist in meinen Augen eine Verharmlosung.
Ich habe doch schon allein beim Verschieben des Knoten oder beim Einfügen eines Knoten in eine Linie eine neue Version. Daran hakt es doch schon. Default Werte bringen uns nicht wirklich weiter, sondern es braucht ein besseres System von SC oder OSM den Verlauf abzubilden. Ob SC sich jetzt speichert, wann welche Frage das letzte mal gestellt wurde oder eine schöne Semantik für “deep history” verwendet, ist mir erst einmal gleich. Meinen Vorschlag, lieber alle Tags regelmäßiger überprüfen zu lassen (und dies zu Speichern), anstatt immer nur einen, war durchaus ernst gemeint. Ich wundere mich halt auch immer über das massenweise cycleway:both=no in Wohngebieten aber von sidewalk=* fehlt jede Spur, obwohl real vorhanden.
So wie das Konzept im Moment ist, ist es mMn. zu kurz gedacht.
Das hast Du jetzt falsch wiedergegeben bzw. falsch verstanden. Wir dokumentieren dort vor allem unsere Diskussionsergebnise. Nicht selten wird auch einfach nur das aktuelle Taggingverhalten dokumentiert. So nach dem Motto: “Die meisten Mitwirkenden mappen ein XYZ so und so.” Es liegt in der Natur von OSM, dass man sich daran orientieren kann aber nicht muss. Kann also bedeuten, dass in 10 Jahren dort etwas anderes steht, weil sich das Verhalten verändert hat und ein anderes Tagging-Schema sich zwischenzeitlich durchgesetzt hat. Was ich außerdem mit dem Satz sagen wollte: Wir entscheiden gemeinsam, was dort steht. Wenn dort etwas noch nicht steht, heißt das nicht, dass das dann nicht trotzdem sinnvoll und richtig ist.
Für Anfänger:innen ist das tatsächlich schwer, ja das stimmt. Das ging mir auch so und ich wünschte mir nicht selten, dass irgendwo ganz eindeutig geschrieben steht, wie was zu Mappen ist. Ein festes Regelwerk. Gibt es aber nicht. Muss man mit leben.
Chef, ick hab dat schon voll richtig und jut verstanden, wie man auch am Zwinkersmiley, der am Ende meiner flapsigen Bermerkung steht (und in dem Zitat fehlt), erkennen hätte können sollen …:).
Ich betrachte das Wiki schon als Regelwerk, da es stets den aktuellen Mindest-Konsens der Beteiligten abbildet und andere Regeln nicht zur Verfügung stehen. Dass dieses “Regelwerk” lebt und ständig aktualisiert wird, spricht ja nicht dagegen. Was man sicher deutlich verbessern könnte, sind klare Hinweise für Neumapper, wie diese “Regeln” anzuwenden sind, was besonders wichtig ist und was man eher vernachlässigen kann und so weiter. Wenn man mit der komplexen OSM-Architektur noch nicht wirklich vertraut ist, kann man sich bei dem einen oder anderen Thema in den Tiefen der Wikis dumm und dusslig suchen, und dann sind die Hinweise zum Teil auch noch widersprüchlich und nicht immer logisch nachvollziehbar.
Ein anderer Neumapper schrieb dazu:
“Und so geht es mir bei vielen Dingen hier: Ich weiß zwar die Theorie dahinter, aber ich habe keine Erfahrung mit der praktischen Umsetzung. Ich will alles richtig machen, also lese ich sorgfältig nach, aber weil OSM nun mal organisch gewachsen ist, finde ich im Wiki (und sonst wo) widersprüchliche Angaben. Dann habe ich Angst, entweder was falsch zu machen oder gar zwischen die Fronten irgend eines Streits zu geraten, und mache im Zweifelsfall gar nichts.”
Wenn ich ein bisschen mehr praktische Erfahrung gesammelt habe, werde ich mich mit diesem Thema mal intensiver beschäftigen und ein paar Vorschläge dazu machen … ich komme ja aus diesem Arbeitsfeld (Lastenhefterestellung und Anwenderdokumentation für DB-Anwendungen) und bringe zumindest für die Dokumentationsseite eine gewisse Expertise mit. An der fachlichen Seite arbeite ich noch …
Schließe ich mich vollständig an. Wofür macht man denn sonst eine Dokumentation?
Dieses Regelwerk würde ich persönlich einfach noch mal in zwei Ebenen der “Verbindlichkeit” unterteilen. 1. Das was durch ein Proposal lief dann ist es u.a. für die Editoren mMn als Verpflichtend anzusehen. Und wenn ein Editor eine Sache einführen will, dann muss dementsprechend ein Proposal gemacht werden.
2. Das was “in use”/“de facto” ist, ist halt eine Grauzone; Dokumentiert / ggf Manifestiert in der Nutzung und somit eine Richtschnur.
