Spielplatz mit access=yes?

Aus Faulheit habe ich nur check_date geschrieben, meine aber das, was westnordost ausformuliert hat:

Edit:
Das ist wohl im Moment auch der Aufreger, dass pro Key ein check_date erstellt wird, wenn das vor Ort geprüft wurde.

Das geht mit min_age und max_age. Ist auch im Wiki so dokumentiert.

Auf min_age/max_age wurde ja schon hingewiesen. Die Spielplätze die ich kenne haben oftmals noch ein dog=no und bicycle=no. Aber mich stört ein access=yes trotz dieser Unschärfe nicht. Ich denke es ist hinreichend klar, was gemeint ist.

[Sarkasmus ein] Derjenige muss in OSM/vor Ort nachschauen, ob er mitdarf. Und hat sich dadurch als aufsichtspflichtige Person disqualifiziert [Sarkasmus aus]

Leute, ihr löst Probleme, die niemand haben müsste.
a) Der Spielplatz ist privat. Diese Menschen wissen schon, wer da spielen darf. Ich würde das normalerweise nicht als amenity erfassen.
b) Der Spielplatz ist öffentlich. Da ist access=yes nur die halbe Wahrheit, es gibt aber Spielplätze für alle Altergruppen. In dem Fall braucht es kein max_age. Wenn aber ein max_age vorhanden ist, dann sind automatisch erwachsene Begleitpersonen erlaubt.
Wie gesagt: Die Betroffenen dürften das Problem nur dann haben, wenn sie sich auf OSM verlassen, weil da mittlerweile jeder Privatkram erfasst wird :frowning:

Nu das sehe ich anders. Spielplätze geben mir zumindest auch einen anderen Nutzen als die Möglichkeit die Kinder zu beschäftigen. Sie markieren eine Stelle, an der man besondere Aufmerksamkeit braucht, sei es weil die Gefahr sich in ihrer Bubbel befindlichen quatschenden Erwachsenen auf dem vorbeifahrenden Fahrradweg stark erhöht ist, sei es weil konsequent alle Flächen zu gewissen Uhrzeiten zugeparkt sind oder ganz klassisch, das plötzliche Schreie den Hund beim Gassi gehen erschrecken… Und das unabhäig ob privat oder allgemein…

Gut, POIs sind ein bisschen leichter. Hier ein konkretes Beispiel:

  1. ein leisure=playground ist erfasst als Knoten

  2. StreetComplete fragt nach access, und es wird ergänzt

  3. der Knoten wird leicht verschoben

  4. ein Tag, z.B. fenced=yes wird ergänzt

Braucht es nicht ein check_date:access=* schon bei 2.? Ist dann nicht access=yes überflüssig?
Wenn jetzt jeweils drei Jahre zwischen den Änderungen vergehen, wann fragt StreetComplete nach ob die Eintragungen noch richtig sind? Wenn ich es richtig verstanden habe zehn Jahre (2x3+4) nach 2., richtig?

Eine Straße wird geteilt und trotzdem wird an dem neuen Objekt das Intervall eingehalten. Wie funktioniert das ohne check_date? Oder beginnt das Intervall erst bei der Erstellung des neuen Objekts und wird danach auch bei jeder weiteren Änderung wieder neu gestartet?

Da hast Du mich falsch verstanden. Ich erwarte eine Frage, ob check_date:opening_hours verändert werden soll, wenn ich den Wert von opening_hours=* verändere. Bitte nicht vollautomatisch, weil ich ja vielleicht nur die Schreibweise oder Syntax-Fehler korrigiert habe, aber die Öffnungszeiten gar nicht überprüft wurden. Zeigt iD überhaupt check_date*=* standardmäßig an?

Interessant, gibt es dazu mehr Infos/Background?

So ein Plugin für JOSM oder iD Unterstützung dafür ist mir nciht bekannt.

iD zeigt ja alle Tags an. Was genau meinst du? Dass es weit oben in dieser Kartegorie “Felder” angezeigt wird?

Deine restlichen Frage gehen sehr ins Detail. Da müsste ich den Quellcode von StreetComplete lesen und verstehen, um die zu beantworten. Vielleicht liest westnordost noch mit und könnte dazu etwas schreiben.

Korrekt.

Wenn (noch) kein entsprechendes check_date: gesetzt ist, orientiert sich die App ansonsten am Datum der letzten Änderung des gesamten Elementes.

Du hast hier das Problem richtig erkannt, dass im Zweifelsfall, nämlich wenn das Element wegen anderer Dinge jeweils geändert wird bevor das erneut-Überprüfen-Interval abgelaufen ist, quasi nie erneut gefragt wird. Das ist ungünstig. So bringt dieses Feature eben nicht so viel, wie es bringen könnte.

Die Frage liegt also nahe: Warum setzt StreetComplete also für tags die von der App als volatil genug eingestuft werden, dass sich eine erneute Überprüfung alle X Jahre lohnt, nicht immer (auch) ein check_date:?

Kurze Antwort: Als ich die Erneut-Überprüfen-Funktionalität vor über einem Jahr eingebaut habe, fragte ich auf der Tagging Mailingliste welche Art zu taggen präferiert wird.
Die vorherrschende Meinung schien damals zu sein dass man mit check_date: möglichst sparsam umgehen sollte, also den tag nur setzen sollte wenn es nicht anders geht. Siehe den Link zur Mailinglisten-Diskussion für die Gründe dafür.

Also habe ich mich danach gerichtet, auch wenn ich sinnvoller gefunden hätte, an volatile Eigenschaften immer check_cate: ranzuhängen, wegen dem Problem dass du in deinem letzten Kommentar ansprichst.

Habe jetzt noch nicht die komplette Diskussion durchgelesen, habe aber schon einige Argumente wie “Deep History” oder eine regelmäßigere Abfrage aller Tags mit entsprechender externer Datenbank für die Abfragezeitpunkte gefunden. Von dem bisherigen Konzept halte ich sehr wenig.

Persönlich, heißt das für mich, alle “default” Angaben bei Veränderungen zu löschen, damit StreetComplete wieder Fragen stellt und nicht erst in zehn Jahren. Ist dann aber auch nicht das Gelbe vom Ei und hilft bei Schlüsseln mit expliziten Werten wie Öffnungszeiten auch nichts. Da bleibt mir ja nur ein check_date:*=* aus der Historie zu konstruieren.

Ich benutze iD überhaupt nicht, aber werden standardmäßig wirklich alle Tags angezeigt?
Eine Aufteilung, zwischen “Felder” und sonstige Tags ist hier sehr kontraproduktive.

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.

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 :slight_smile:

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?

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.

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/StreetComplete/FAQ#Why_does_StreetComplete_often_tag_the_absence_of_features.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.

@ 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:

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

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?

Naja, da interpretierst du in…

…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/StreetComplete/wiki/Adding-new-Quests-to-StreetComplete

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

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: …”.

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.