Spielplatz mit access=yes?

lit= ist nicht mit access= vergleichbar (finde ich). lit=no, lit= und lit=yes werden in OsmAnd alle unterschiedlich gerendert.

Das funktioniert doch hinten und vorne nicht. Default-Werte werden anstatt check_date:*=* verwendet. Wie funktioniert das bitte wenn die Straße mittlerweile geteilt wurde? Wenn dann muss doch die Änderung jedes einzelnen Tags und nicht die timestamp des Objektes verwendet werden.

Wie soll ich mir das jetzt in Zukunft vorstellen. Wird dann an jedes Objekt nicht nur eine Liste von Schlüsseln mit Default-Werte gehängt sondern zusätzlich zu jedem Tag auch noch ein entsprechendes check_date:*=*? Wollen wir das wirklich?
Welcher Editor unterstützt den check_date:*=*soweit, dass der Wert (das Datum) halbautomatisch bei Änderungen mit angepasst wird?

Es geht nicht um eine Liste von Schlüsseln, sondern um diejenigen, die vor Ort (otg) überprüft wurden. Das ist keine willkürliche Liste, sondern sie basiert auf einem Survey.
Welche Tags das alles sein könnten, ist in der Wikiseite zu sehen. Es wäre toll, wenn wir konkreter über Schlüssel diskutieren könnten anstatt zu pauschalisieren. Das Thema ist ursprünglich access=yes an Spielplätzen.

Dann werden die Fragen zu jedem Straßenabschnitt separat gestellt.

StreetComplete. Hast du die App in jüngster Zeit mal ausprobiert? Falls nicht, probier es doch bitte mal aus. Mir ist kein besserer Editor bekannt, um in OSM bereits eingetragene Daten zu pflegen, weil er einem die Objekte präsentiert, die seit langem nicht mehr geändert wurden.
Welchen Editor sonst würdest du dir denn wünschen für eine Halbautomatisierung? Brauchst du so eine Funktionalität in JOSM, Vespucci oder iD? Wenn man darin zB. die Straßenoberfläche ändert, kann man den check_date Tag auch löschen (außer natürlich man will ihn manuell aktualisieren).

Vespucci zeigt schon seit Jahren (genau gesagt seit Mitte 2017) veraltete Objekte an, und du kannst via JavaScript Preset auch semi-automatisch, z.B., ein check date Tag hinzufügen.

check_date kann keine Aussage darüber treffen, ob ein einzelnes Attribut überprüft wurde, da es sich immer auf das Gesamt-Objekt bezieht.

Es ist also durchaus möglich, dass jemand bei einem Spielplatz ein check_date drannsetzt, weil er/sie überprüft hat, ob es den Spielplatz noch gibt. Sofern kein access-Wert eingetragen ist, ist das aber keine Aussage darüber, ob der access-Wert nicht eingetragen wurde, weil es keine Nutzungseinschränkung gibt oder weil bislang niemand auf die Idee kam, dort irgendeinen access-Wert einzutragen.

Die meisten öffentlichen Spielplätze haben übrigens eine über das Alter definierte Nutzungseinschränkung wie z.B. “nur für Kinder bis 12 Jahre”… - ein access=yes wäre insofern aus meiner Sicht eher problematisch, weil dies ja bedeutete, dass jeder auf diesem Spielplatz spielen darf, also auch 16-Jährige.

Bislang ist mir aber nicht bekannt, dass die genaue Benutzergruppe von Spielplätzen in OSM erfasst werden. Ich beschränke mich daher darauf, bei nicht öffentlich zugänglichen Spielplätzen ein access=private zu setzen und bei öffentlichen Spielplätzen den access-Wert offen zu lassen. Manchmal ist es besser, keinen Wert einzutragen als einen nur halb-richtigen (weil access=yes bei bestehender Altersbeschränkung z.B. falsch wäre).

Danke, das wusste ich nicht.
@skyper: Vespucci ist damit der 2. Editor für Halbautomatisierung von check_date

Und was ist dann mit den beaufsichtigenden erwachsenen Personen?

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?