Spielplatz mit access=yes?

Darüber könnt man trefflich streiten (ich hab übrigens SC gar nicht erwähnt).

Per default öffentlich, alles andere muss getaggt werden.

Aber das ist nicht das Problem, sondern das Argument, dass man ohne expliziten Wert nicht wissen kann ob das einfach übersehen wurde/nicht erfasst/usw. Um ein nicht so fernes Beispiel (ich hab tatsächlich mal eine halbe Stadt von boat=no und motor_boat=no Tags befreien müssen, ist also gar nicht an den Haaren herbeigezogen) zu nehmen, payment: -eigentlich- müsste man an jeden Laden ein halbes 100 payment Tags kleben wenn man nicht damit leben kann, dass es implizite Werte gibt.

Ein schönes Beispiel an dem man sieht, wie weit das Forum wieder von der Praxis entfernt ist. :laughing:
Diskutieren ohne Ziel und ohne Ergebnis. Hauptsache aufgeregt.

Und auch wenn ein paar alteingesessene die Welt nicht verstehen. Selbst Straßen werden mit access=yes getaggt, egal wie falsch es ist. Einfach mal Overpass eurer Wahl laufen lassen oder so. Da sind Spielplätze ein Witz dagegen … :D:D:D lustige OSM Welt.

In den Editoren sind die Vorlagen für Spielplätze ebenfalls nicht einheitlich.
JOSM: fragt den Zugang nicht ab
iD: fragt ihn ab

Ich z.B. nutze fast ausschließlich JOSM. Ich gehöre damit zu den Mappern, die regelmäßig vergessen, access=yes zu erfassen.

Eher “jeder darf hier eintreten” oder “zugang frei” (access <=> zugang). Elter oder Großelter düŕfen ja auch hinein, eben wenn sie nicht spielen, vielleicht eben nicht dürfen wegen Älter.

Wer oder was StreetComplete ist, das weiß ich nicht - aber irgendjemand oder irgendwelchem “Service” der verlangt überflussiges einzutragen, dem sollte den Zugang zu unser Database untersagt werden.

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.