Spielplatz mit access=yes?

Map_HeRo · 2021-11-04 13:39:36

seichter wrote:

Da möchte ich diese meist unerfahrenen Mapper etwas in Schutz nehmen: Die Editoren bieten diese Felder an und der Newbie meint eben, das müsse alles ausgefüllt werden.

Moin, ich bin auch einer der dummen Newbies und schaue als erstes, wenn ich noch keine Ahnung habe, mal im Wiki unter den Tag Features nach. Da werden als sinnvolle Kombinationen zu "playground" aufgelistet:

name, min_age, max_age, operator

Vom einem Namen mal abgesehen sind das für mich als Elternteil sinnvolle Informationen, gerne noch ergänzt durch Öffnungszeiten.

Bei den weiteren im Zusammenhang verwendbaren Tags werden unter access lediglich die attribute private/customers gelistet. Damit ist für mich als Newbie eigentlich klar, dass ein =yes überflüssig ist und so sehe ich das auch als Elternteil. Ein Spielplatz ist für mich solange grundsätzlich frei zugänglich, solange explizit nichts anderes festgelegt wird (also so eine Art opt out Regelung).

Btw: Ich weiß mittlerweile, dass die OSM Wiki bei den Mappingprofis kein besonders hohes Ansehen geniesst, aber das meiste, was dort beschrieben ist, macht schon Sinn, und irgendwo müssen gewisse Regeln bei dieser komplexen Materie auch dokumentiert sein, sonst würde jeder Neuling mit einer Arbeit mehr schaden als nutzen.

highflyer74 · 2021-11-04 14:56:53

Map_HeRo wrote:

dass die OSM Wiki bei den Mappingprofis kein besonders hohes Ansehen geniesst,

Das würde ich gar nicht sagen. Ich nutze das Wiki jeden Tag. Man kommt nicht umhin, im Zweifel ein wenig zu recherieren oder andere schlaue Mitmenschen zu fragen. Aber dafür sind wir hier ja

SafetyIng · 2021-11-04 16:14:18

Map_HeRo wrote:

Btw: Ich weiß mittlerweile, dass die OSM Wiki bei den Mappingprofis kein besonders hohes Ansehen geniesst

Wie kommst du darauf? Das große Problem ist, dass nicht alles vernünftig dokumentiert ist. Ich nutze das Wiki auch vorrangig und wenn ich etwas neu "erfinde", trage ich es auch im Wike entsprechend ein. Alles andere würde ja keinen Sinn ergeben. Wie sollen denn sonst andere wissen, was ich mit diesem Tag meine?

Map_HeRo · 2021-11-05 18:48:28

SafetyIng wrote:

Wie kommst du darauf? Das große Problem ist, dass nicht alles vernünftig dokumentiert ist.

Weil in den unterschiedlichsten Forumsbeiträgen, durch die ich mich in den letzten Wochen hindurchgelesen habe, um einen Überblick zu bekommen, immer wieder abfällige Äusserungen über das Wiki fallen. Für mich als Neumapper ist es das wichtigste Nachschlagwerk, wobei ich zugeben muss, dass die englische Version besser (umfangreicher und ausführlicher) ist als die deutsche, aber darauf wird in den deutschen Texten auch immer wieder verwiesen.

Um noch mal auf das Tagging der Spielplätze zurückzukommen: Wenn ein ausdrückliches access=yes eigentlich nicht erwünscht oder aber zumindest überflüssig (da defaultvalue) ist, dann ist es doch eher kontraproduktiv, wenn in StreetComplete der User aufgefordert wird, dieses Tag zu setzen ... gibt es da irgendeine Art von Abstimmung zwischen den verschiedenen Softwares? Frage nur interessehalber, da diesbezüglich absolut ahnungslos.

westnordost · 2021-11-06 17:30:00

Dass access=yes überflüssig sei, ist nur eine Meinung, keine Regel. Ist ja ok diese Meinung zu äußern, das Forum ist ja zum Meinungsaustausch da.

"Defaults" gibt es nicht in OpenStreetMap. Es ist den Datennutzern überlassen, wie sie das Fehlen eines Datums interpretieren wollen. Dies geschieht nach gesundem Menschenverstand der Datennutzern. Bei einer Hauptstraße ohne access=* Tag kann man getrost davon ausgehen, dass sie bestimmt öffentlich ist. Bei Auffahrten (highway=service + service=driveway) wohl tendenziell auch, aber hier ist es schon weit weniger sicher.
Oberfläche einer Straße wenn surface=* nicht gesetzt? In Deutschland kann sicherlich erstmal für normale Straßen Asphalt angenommen werden, wird in den meisten Fällen richtig sein. In vielen anderen Ländern ... eher nicht.

Es ist also vom Karten-Feature und vom Ort abhängig, als wie sicher eine fehlende Information aus ggf. anderen tags hergeleitet werden kann.

Hier ist auch noch eine Erklärung, warum StreetComplete bei bestimmten Features "Default"-werte setzt (nämlich solchen bei denen eine gewisse Wahrscheinlichkeit besteht, dass die Antwort variiert):
https://wiki.openstreetmap.org/wiki/Str … eatures.3F

Edit 6.11.21 17:46: Zurzeit haben nur etwa 13% aller Spielplätze ein access=*-tag. Davon sind etwa 28% als nicht öffentlich getaggt. StreetComplete fragt dies ab, weil Spielplätze wie vieles anderes auch von Luftbildern abgemalt/gemappt werden und so unklar ist, ob diese öffentlich sind oder z.B. nur für die Mieter des entsprechenden Apartmentkomplexes zur Verfügung stehen. Das ist eine Information, die zwingend vor-Ort erhoben werden muss.

Last edited by westnordost (2021-11-06 17:46:43)

Map_HeRo · 2021-11-06 19:28:09

@ westnordost

Miot dem Begriff "default" hatte ich mich auf den Beitrag #13 von NOP bezogen, der festgestellt hatte, dass ein explizites "yes" redundant ist, und zwar:

Nop wrote:

Redundant zum Default.
Wenn ein Spielplatz ohne weitere Info eingezeichnet ist, gehe ich von einem öffentlichen Spielplatz aus.
Nicht-öffentliche Spielplätze müssen mit entsprechendem access (oder auf Privatgrundtücken am besten gar nicht) eingetragen werden.

Die von Dir verlinkte Beschreibung, warum StreetComplete bei bestimmten unbesetzten Features Werte setzt:

westnordost wrote:

Hier ist auch noch eine Erklärung, warum StreetComplete bei bestimmten Features "Default"-werte setzt (nämlich solchen bei denen eine gewisse Wahrscheinlichkeit besteht, dass die Antwort variiert):
https://wiki.openstreetmap.org/wiki/Str … eatures.3F

steht im Falle playground access=yes im Widerspruch zu OSM Wiki, wo ausgeführt wird, dass access= nur mit private/customers zu besetzen ist, sofern dies zutrifft. Das verstehe ich so, dass der Wert "yes" hier überflüssig ist.

Daher nochmals meine Frage: Gibt es diesbezüglich eine Abstimmung zwischen Wiki und StreetComplete?

westnordost · 2021-11-06 19:45:48

Naja, da interpretierst du in...

access=private/customers for playgrounds unavailable to public

...etwas viel hinein. Ich erkenne da keinen Widerspruch. access=* wird für alle möglichen Map Features verwendet, und zwar mit den gleichen Values (yes, no, private, ...).

Wenn Du mehr über den Entscheidungsprozess was in StreetComplete eine Aufgabe werden kann (und was nicht), kannst du in den "Quest Guidelines" mehr erfahren:
https://github.com/streetcomplete/Stree … etComplete

MKnight · 2021-11-06 20:56:58

Map_HeRo wrote:

@ westnordost
Miot dem Begriff "default" hatte ich mich auf den Beitrag #13 von NOP bezogen, der festgestellt hatte, dass ein explizites "yes" redundant ist, und zwar:
Nop wrote:
Redundant zum Default.
Wenn ein Spielplatz ohne weitere Info eingezeichnet ist, gehe ich von einem öffentlichen [...]

Da besteht aber kein Konsens. Implizites (Nicht-)Tagging ist zwar ganz nützlich, aber eben nicht immer, gibt genügend nicht getaggte implizite Werte, die effektiv zwischen überhaupt nix und wenig über Zustand/irgendwas oder wie hier access aussagen.

Extrembeispiel:
lit=no, da ist irgendwie allen klar, dass das nicht implizit sein kann,
das wird dann unschärfer über oneway=no an motorway_link und dann gibt's halt eben noch etliches "implizites" unscharfes tagging, wo dann ellenlange Threads entstehen können, weil die Unschärfen naturgemäss unterschiedlich unscharf sind.

P.s. Was ich persönlich aber doch etwas schwierig finde, wenn eine App einem User quasi die persönlichen Unschärfen des App-Entwicklers "aufdrückt".

Last edited by MKnight (2021-11-06 20:57:22)

Hungerburg · 2021-11-06 21:49:11

Implizit ist, was nicht eigens am Knoten/Weg angegeben werden braucht, weil es bereits mit einem der anliegenden Tags gesagt ist: zB foot=no auf Autobahnen, foot=yes auf Wanderwegen mit SAC-Scale Attribut. Autoritativ ist das Wiki, Rubrik "Implies: …".

Map_HeRo · 2021-11-06 23:26:58

MKnight wrote:

Da besteht aber kein Konsens. Implizites (Nicht-)Tagging ist zwar ganz nützlich, aber eben nicht immer, gibt genügend nicht getaggte implizite Werte, die effektiv zwischen überhaupt nix und wenig über Zustand/irgendwas oder wie hier access aussagen.

Ja, das mit dem nicht immer gegebenen Konsens habe ich (beim Einlesen in diverse Topics dieses Forums) auch schon bemerkt . Das ist aber auch gut so, bringt ein bisschen Leben in die Bude ...

Dafür gibt es ja die Wikis, die für mich als Neuling immer die erste Anlaufstelle sind. Und wenn dort bei einer bestimmten Location für das access tag lediglich die Attribute "private/customers" angegeben werden, verstehe ich das so, dass "yes" hier zumindest unnötig ist (wenn auch nicht explizt untersagt), also im Normalfall impliziert wird, denn sonst würde dort wohl eher "yes/private/customers" stehen.

Wenn auch nach dem Blick in die Wikis Unklarheit herrscht, würde ich mich am Objekt selber orientieren. Bei Spielplätzen ist die Frage nach dem access in der Praxis eher unbedeutend, da interessieren viel eher

Öffnungszeiten
Altersgruppe
Angebot an Spielgerät
Zustand (speziell in bestimmten Stadtbereichen -> gepflegt? verwahrlost? Junkie-Treff?)
eventuell noch Gebühren (wobei ich selber keinen einzigen gebührenpflichtigen Spielplatz kenne)

Ungeachtet dessen gebe ich Dir absolut Recht, dass Unschärfen naturgemäß unscharf sind und individuell unterschiedlich wahrgenommen werden.

Strubbl · 2021-11-08 22:34:55

MKnight wrote:

P.s. Was ich persönlich aber doch etwas schwierig finde, wenn eine App einem User quasi die persönlichen Unschärfen des App-Entwicklers "aufdrückt".

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.

Last edited by Strubbl (2021-11-08 22:36:50)

skyper · 2021-11-09 14:23:00

Strubbl wrote:

MKnight wrote:
P.s. Was ich persönlich aber doch etwas schwierig finde, wenn eine App einem User quasi die persönlichen Unschärfen des App-Entwicklers "aufdrückt".
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?

Strubbl · 2021-11-09 15:02:45

skyper wrote:

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?

Wenn man das weiterdenkt, ist ganz OSM ein Aufdrücken, oder?

edit: Was willst du nun tun? Oder worauf willst du mit deiner Aussage hinaus? Außer das ich nicht über den Tellerrand schaue.

Last edited by Strubbl (2021-11-09 15:11:13)

Map_HeRo · 2021-11-09 15:37:02

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 ... . Wie schon an anderer Stelle festgestellt, muss man wohl mit diversen Unschärfen bei OSM einfach leben können.

skyper · 2021-11-09 15:47:44

Strubbl wrote:

skyper wrote:
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?
Wenn man das weiterdenkt, ist ganz OSM ein Aufdrücken, oder?

Ohne Vetorecht auf jeden Fall.

Strubbl wrote:

edit: Was willst du nun tun? Oder worauf willst du mit deiner Aussage hinaus? Außer das ich nicht über den Tellerrand schaue.

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.

Map_HeRo · 2021-11-09 18:38:37

skyper wrote:

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.

.. full_acc .. !!

Strubbl · 2021-11-09 19:42:57

skyper wrote:

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?

OSM_RogerWilco · 2021-11-09 20:05:11

Strubbl wrote:

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.

Strubbl · 2021-11-09 20:37:31

OSM_RogerWilco wrote:

Einfach nur mit leisure=playground ohne access=*, da ein leisure=playground ein access=yes impliziert.

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?

OSM_RogerWilco · 2021-11-09 20:53:39

Strubbl wrote:

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.

Last edited by OSM_RogerWilco (2021-11-09 20:56:16)

Strubbl · 2021-11-09 21:03:08

OSM_RogerWilco wrote:

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.

OSM_RogerWilco · 2021-11-09 21:08:31

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.

Map_HeRo · 2021-11-09 22:38:39

Strubbl wrote:

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/….

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"

Strubbl wrote:

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?.

Dann kann er weder yes noch irgend was anderes zuordnen, wenn er das Wissen nicht hat ...

OSM_RogerWilco · 2021-11-10 07:51:59

Map_HeRo wrote:

Wenn's da nicht aufgelistet ist, macht's vermutlich auch keinen Sinn, oder?

Oder es hat einfach noch niemand eingetragen. Oder jemand hat es ohne Nachfrage gelöscht. Oder...

Map_HeRo wrote:

"no" ist Unsinn, wenn der Platz nicht zugänglich ist, brauche ich ihn nicht zu mappen

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.

Map_HeRo wrote:

"permissive" macht bei einem Spielplatz auch nicht viel Sinn, [...]

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.

access=yes kann aber muss nicht getaggt werden.

Map_HeRo · 2021-11-10 11:12:40

OSM_RogerWilco wrote:

Oder es hat einfach noch niemand eingetragen. Oder jemand hat es ohne Nachfrage gelöscht. Oder...

Youah ... das gilt dann aber für alle Informationen im Wiki - entweder haben die richtungsgebenden Character oder eben nicht, weil jeder drin rumbasteln kann.

OSM_RogerWilco wrote:

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.

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.

OSM_RogerWilco wrote:

Natürlich. Wenn die Benutzung lediglich geduldet wird, ist das access=permissive.

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?

Announcement

#51 2021-11-04 13:39:36

Re: Spielplatz mit access=yes?

#52 2021-11-04 14:56:53

Re: Spielplatz mit access=yes?

#53 2021-11-04 16:14:18

Re: Spielplatz mit access=yes?

#54 2021-11-05 18:48:28

Re: Spielplatz mit access=yes?

#55 2021-11-06 17:30:00

Re: Spielplatz mit access=yes?

#56 2021-11-06 19:28:09

Re: Spielplatz mit access=yes?

#57 2021-11-06 19:45:48

Re: Spielplatz mit access=yes?

#58 2021-11-06 20:56:58

Re: Spielplatz mit access=yes?

#59 2021-11-06 21:49:11

Re: Spielplatz mit access=yes?

#60 2021-11-06 23:26:58

Re: Spielplatz mit access=yes?

#61 2021-11-08 22:34:55

Re: Spielplatz mit access=yes?

#62 2021-11-09 14:23:00

Re: Spielplatz mit access=yes?

#63 2021-11-09 15:02:45

Re: Spielplatz mit access=yes?

#64 2021-11-09 15:37:02

Re: Spielplatz mit access=yes?

#65 2021-11-09 15:47:44

Re: Spielplatz mit access=yes?

#66 2021-11-09 18:38:37

Re: Spielplatz mit access=yes?

#67 2021-11-09 19:42:57

Re: Spielplatz mit access=yes?

#68 2021-11-09 20:05:11

Re: Spielplatz mit access=yes?

#69 2021-11-09 20:37:31

Re: Spielplatz mit access=yes?

#70 2021-11-09 20:53:39

Re: Spielplatz mit access=yes?

#71 2021-11-09 21:03:08

Re: Spielplatz mit access=yes?

#72 2021-11-09 21:08:31

Re: Spielplatz mit access=yes?

#73 2021-11-09 22:38:39

Re: Spielplatz mit access=yes?

#74 2021-11-10 07:51:59

Re: Spielplatz mit access=yes?

#75 2021-11-10 11:12:40

Re: Spielplatz mit access=yes?

Board footer