Spielplatz mit access=yes?

Wem sagst du das? http://qa.poole.ch/?zoom=4&lat=44.89405&lon=8.81445&layers=FFFTB0 existiert seit Jahren. Und ja, im Schnitt hat eine Strasse die mit access=yes getaggt ist falsche Zugangstags (mal abgesehen davon, dass es nicht klar ist wie ein access=yes überhaupt wirkt im Falle von Strassen).

Alle 4 Jahre wird nachgefragt, ob es noch so ist. Es wird dann in der App die aktuell kartierte Situation dargestellt und gefragt, ob es noch genauso ist oder ob es sich geändert hat.
Siehe auch “Is there a cycleway here? What type?” auf https://wiki.openstreetmap.org/wiki/StreetComplete/Quests

Ähnlich Rückfragen gibt es auch für andere Quests wie surface, lit, fee, crossing, segregated, kerb, construction, traffic_signals, ramp, wheelchair uvw. Details hierzu bitte auf der o.g. Wikiseite nachschauen.

+1

Wie macht SC das, ohne ein check_date oder ähnliches Tag zu setzen?

+1, genau diese Frage habe ich auch. Dazu fehlt leider die Information im Wiki. Kann das bitte ergänzt werden, Danke.

Wenn das eh schon funktioniert, wieso braucht es dann die Eintragungen der Default-Werte überhaupt?

So weit ich das verstehe, setzt StreetComplete beim erneuten Überprüfen ein check_date - nur halt nicht beim ersten Hinzufügen des Tags.

check_date:= wird nur gesetzt wenn sich das abgefragte Tag nicht geändert hat. Wenn bereits ein check_date: gesetzt ist, wird es auf das heutige Datum aktualisiert, egal ob sich das abgefragte Tag geändert hat oder nicht.

In Abwesenheit irgendeines check_date: wird der timestamp des Elementes betrachtet, also wann das Element im gesamten zuletzt bearbeitet wurde, um festzustellen ob z.B. erneut überprüft werden sollte, ob hier noch ein Fahrradweg oder was auch immer ist.

Sinnvoll wenn es nicht offensichtlich ist - bei Kindergärten / Einkaufszentren / Campingplätzen / Gaststätten ist es ja nicht selbstverständlich, das sie für die Allgemeinheit zugänglich sind.

Und es sei daran erinnert, das gesetzte Default Werte die Information “wurde auf den Aspekt geprüft” beinhaltet.

Man kann sonst ja nicht erkennen,ob die Daten einfach unvollständig sind oder der defaultwert gilt

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?