Ich finde deine Formulierung hier schwierig.
Man muss die App oder den Editor nicht nutzen, wenn man bestimmte Dinge nicht möchte, mag oder es sich “aufgedrückt” anfühlen würde. In der SC-App kann man auch diejenigen Quests deaktivieren, mit denen man im Tagging-Verhalten nicht einverstanden ist. Da wird m.E. nichts aufgedrückt.
edit:
ich kenne das “Aufdrücken” von iD und deren Nicht-Nutzung des contact:*-Schemas. Daher nutze ich das Standardverhalten von iD nicht, wenn ich diese Infos hinzufüge.
Bitte schau über den Tellerrand. Jeder Editor hinterlässt seinen Fußabdruck, die Frage ist nur wie groß der ist. Als Person, die einige Software gar nicht benutzt, werde ich trotzdem öfters mit deren Taggingschema und auch mit noch nicht akzeptierten und kontroversen Tags konfrontiert. Das ist schon ein Aufdrücken, oder?
Jeder Editor stellt bestimmte Werkzeuge zur Verfügung, die man nutzen kann, aber nicht muss. Wenn ich es richtig verstehe, richtet sich StreetComplete primär an Nutzer, die sich mit den Editierdetails von OSM nicht intensiv befassen wollen, aber trotzdem auch etwas beitragen wollen und bietet dafür eine Oberfläche, die weniger kenntnisgesteuert angewendet wird als vielmehr softwaregesteuert. Und wenn diese Software dem Anwender vorschlägt, alle Spielplätze, an denen er vorbeikommt, mit access=yes zu markieren, ist das schon eine Art von “aufdrücken”, oder nicht?
Und wenn im Fall der Spielplätze dieses Attribut gemäß der Richtlinien (Wiki) eigentlich nicht notwendig ist und keinen Mehrwert bringt, stellt sich die Frage, ob hier zwischen den Beteiligten eine Abstimmung stattfindet. Das Problem gibt es aber bei OSM auch an anderen Stellen, die Wikieinträge widersprechen sich z.B. teilweise, speziell wenn es darum geht, wie welcher Key zu taggen ist. Das liegt sicher daran, dass es keine Adminstration bei OSM gibt, die verbindliche Detailvorgaben macht und die Umsetzung auch kontrolliert und dafür funktioniert der ganze umfangreiche Konstrukt wiederum erstaunlich gut … :D. Wie schon an anderer Stelle festgestellt, muss man wohl mit diversen Unschärfen bei OSM einfach leben können.
Wir habe ja schon eine Spielregeln und Mechanismen, um uns auf Tags und Taggingschemata zu einigen. Diese sollten wohl ein bisschen verfeinert werden, wie z.B. die Abstimmung zu Internetbezahlsystemen gezeigt hat. Auch die Definitionen des Tagstatus halte ich für zu schwammig. Ab wann ist ein Tag “proposed”, “in use” oder “de facto”?
Auf Seite der Personen, die an der Entwicklung von Editoren beteiligt sind, erwarte ich mehr Fingerspitzengefühl und die Verwendung von etablierten Tags oder ein entsprechendes akzeptiertes Proposal. Hier fehlt es eventuell auch ein paar generellen Richtlinien als Leitfaden.
Zwei Beispiele noch zu Verdeutlichung:
railway=tram_crossing und railway=tram_level_crossing, hier bestehen nach wie vor Überlappungen mit railway=crossing und railway=level_crossing und der neue Tag verändert die Definition des existierenden. Es gibt kein Proposal.
cycleway:both=* ohne oneway=*, wird massenweise getaggt, dabei kann das “both” weggelassen werden. Hier wird die Definition von cycleway=* verwässert.
Wenn sich niemand findet, um diese Definitionsthemen voranzutreiben, wird es leider so aufdrückend bleiben. Nun finde ich immer noch, dass nicht die Entwickler der Editoren hier etwas aufdrücken. Diese nicht vollständig definierten Tags drücken hier wohl eher auf. Man kann Tags wohl auch nie 100% vollständig definieren, sodass es immer Verwässerungen und Ausnahmen der Ausnahme gibt.
Das Problem bliebe selbst bestehen, wenn ich direkt in die Datenbank per Hand schreibe ohne Editor und mit ganz viel Fingerspitzengefühl. ¯_(ツ)_/¯
Denkst du, dass die Entwickler von SC nicht genug Fingerspitzengefühl haben? Das Problem ist doch die schwammige Definition und das nicht-Vorhandensein von Standardwerten, die einige Mapper annehmen, die aber nirgends dokumentiert sind.
Um zu versuchen, den Bogen zum Thema zu finden: Wie tagge ich einen Spielplatz als öffentlich, wenn nicht mit access=yes? Oder sollten deine zwei Beispiele hier besser herhalten - nur wie?
Einfach nur mit leisure=playground ohne access=, da ein leisure=playground ein access=yes impliziert. Nur wenn er nicht öffentlich ist, sollte ein access= getaggt werden. Dieses Schema funktioniert aber nicht mit der Arbeitsweise von StreetComplete. Wie gesagt finde ich aber ein “redundantes” access=yes an einem Spielplatz nicht störend.
Das steht wo? Im Wiki steht nur “access=private/customers - ein nicht öffentlicher Spielplatz (z.B. Spielplatz einer Kita)”. Da steht nichts zu access=yes/no/permissive/permit/….
Was ist mit vom Luftbild abgemalten Spielplätzen, die evtl. nicht öffentlich sind und der Arm-Chair-Mapper dieses implizite Wissen nicht hat, weils nirgends steht?
Was ist mit Straßen, Feldwegen, etc. die vom Luftbild abgemalt wurden? Gleiches Prinzip: Man geht erstmal davon aus, dass sie öffentlich sind. Wenn nicht → access.
Anderes Beispiel: Was ist mit Sitzbänken? Diese können auch in einem Einkaufzentrum stehen und somit access=customers sein.
Das sind nur ja Annahmen. Wenn ich Grundstückszufahrten von Luftbildern abmale und kein access Tag vergebe, nehme ich an, dass die privat sind und nicht öffentlich. Das lässt sich alles in jede Richtung interpretieren, wenn man nur will.
Deswegen sollte es explizit irgendwo formuliert werden, dann stellen sich diese Fragen doch nicht erst.
amenity=bench erwähnt im Wiki nicht einmal den access-Tag. Bei highway wird access wenigstens als sinnvolle Kombination erwähnt.
Das Wiki ist ja kein Regelbuch für OSM, sondern dient uns lediglich als Notizbuch unsere Diskussionsergebnisse zu dokumentieren. So sollte man das Wiki jedenfalls betrachten.
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?
So sollte man das Wiki jedenfalls betrachten.