Ganz so fuzzy ist das nicht: In den Parkplatz darf zunächst alles rein, was auch auf die Straße darf.
Wenn nicht für Wohnmobile o.ä., steht ein Zusatzschild, das man im Prinzip ins Tagging aufnehmen sollte.
Ich finde es seit längerem frustrierend, dass StreetComplete das Setzen überflüssiger Defaultwerte in offenem Widerspruch zu vorherigen Konventionen etabliert. Es war nämlich eigentlich lange Zeit Konsens, dass Dinge wie access=yes, surface=asphalt, oneway=no (kommt bestimmt noch) eben nicht gesetzt werden, weil sie die Liste der Tags unnötig unübersichtlich machen und echte Informationen (und Änderungen an solchen echten Informationen) im Rauschen des eigentlich Selbstverständlichen untergehen.
Es ist auch keineswegs eine nachhaltige Lösung, um zu dokumentieren, dass jemand diese Info nachgeprüft hat, Denn man muss so was ja nicht nur einmal überprüfen, sondern regelmäßig. Das kann aber ein access=yes nicht leisten – das wird auch in zehn Jahen noch in der DB stehen und eine Überprüftheit suggerieren.
Wieso denn das?
Weil in unseren Breiten Straßen bestimmter Typen üblicherweise asphaltiert sind und es daher nicht wirklich nützlich ist, diese Information explizit mit anzugeben. Stattdessen macht es aus meiner Sicht mehr Sinn, die vergleichsweise wenigen Ausnahmen entsprechend zu taggen.
Von Autobahnen bis runter zur Kreisstraße und residential dürfte das bei uns i.d.R. zutreffen und stimme Dir voll zu. Bei unclassified, service, track, und path etc. sehe ich das anderst und ergänze surface und smoothness nach Ortsbesichtigung.
Grüße
Was wir denn da suggeriert? Der Tag wurde zum Zeitpunkt der Setzung faktisch gesichtet (soweit der Ersteller nicht schummelt). In 10 Jahren wird man in der DB halt sehen, dass der Tag ein Jahrzehnt alt ist und ihn entsprechend bewerten.
Dass es bei OSM keinen ordentlichen geregelten Umgang mit Default Werten oder Aktualisierungen der Werte gibt kann man der App nicht vorwerfen. Sie bewegt sich meiner Meinung nach wegen ihrer schlichten und effizienten Bedienung in einem Feld, dass man bei OSM noch nicht ausreichend beackert hat, da es durch den hohen Aufwand bisher zu wenig angewandt wurde. Und ja, dabei kommen mit Sicherheit auch sehr irritierende Sachen bei raus.
Also wenn die App eine Frage enthält ähnlich wie: “Ist dieser Parkplatz frei zugänglich?” und mit ja, nein, privat, nur für Kunden etc. beantwortet wird, dann kann das Ergebnis durchaus mehrwert haben. Heute weis ich nämlich in der Regel nicht, ob ich auf den vielen Parkplätzen in OSM parken darf oder nicht.
Die Frage ist nur was bedeutet ein “access=yes” überhaupt (an einer Strasse, oder von mir aus an einem Parkplatz)?
Heisst das alle Beschränkungen sowohl für Nutzungsart wie auch Farhrzeugsart/Bewegungsart aufgehoben?
Muss ich also tatsächlich ein boat=no und ein motor_boat=no an so einer Strasse pappen (hab ich schon gesehen)?
Kriegt jeder das dann auch hin die korrekten Breiten-, Höhen- und Längenbeschränkungen wieder hin (pro Fahrzeugart)?
Pappt da auch jeder ein carriage=no an die Autobahn?
Und so weiter.
Es stimmt access=yes ist ein guter Marker,
DAFÜR DAS FASLCH GETAGGT WURDE
Naja, solange auf dem Parkplatz kein verbotsschild für Bote steht, dürfen die da aber rauf. (ob sie es können ist ein völlig anderes Thema)
In diesem CS https://www.openstreetmap.org/changeset/59328266#map=19/48.09320/9.77551 wurden 3 Hausnummern ergänzt. An diesen Gebäuden fehlt auch noch die Straße.
Fragt StreetComplete nicht beides gleichzeitig ab ?
Das wäre suboptimal.
StreetComplete fragt nicht beides gleichzeitig ab. Jedenfalls wurde das in einer früheren Diskussion so festgestellt … Auch ich war und bin (siehe meine damaligen Posts) der Meinung, dass Hausnummer und Straßenname/Place-Name immer zusammen erfasst werden sollten.
Nein, immer nur eine einzelne Aufgabe.
Der Benutzer kann aber Adresse und Hausnummer nacheinander abarbeiten und dann, je nach Einstellung, zusammen hochladen.
Ein ausdrücklicher Hinweis, daß an diesem Objekt noch mehr Daten fehlen, fehlt dann wohl. Und deshalb bleibt das Objekt halt weiterhin unvollständig erfaßt = suboptimal
Ich sehe da kein großes Problem drin. Denn SC liefert hier etwas wertvolles aus der Surveyperspektive, das vom Remote Tagging nicht erfasst werden kann. Natürlich ist ein Haus, das von der Adressangabe nur die Nummer hat unvollständig erfasst. Aber gerade die Nummer ist ein Problem das SC perfekt lösen kann, aber allen Häusern an einer Strasse die Adressangaben zu verpassen geht viel leichter in JOSM.
Vielmehr noch geht es noch leichter wenn die Nummer schon da ist um anhand der fortlaufenden Reihe zu erkennen, welche Adressen welchen Strassen zugeordnet sind (an Kreuzungen beispielsweise).
Na und? Das kann man ja mit Qualitätssicherungstools auffinden und vervollständigen.
Und warum soll das nicht gleich mit StreetComplete erledigt werden?
Arbeitsteilung ?
Arbeitsteilung zwischen Tools, ja. Wie gesagt, ich glaube dass das mit JOSM sehr viel einfacher geht und dass das nicht wirklich Aufgabe einer Survey App ist/sein muss.
Aber es könnte alternativ auch jemand eine entsprechende Aufgabe für SC entwerfen, dann würde (je nachdem wie man die Aufgaben priorisiert) erst die Strasse und dann die Hausnummer abgefragt. Ich würde mir aber ehrlich gesagt auch ein bisschen blöd vorkommen, wenn ich an einer Strasse entlang gehe und an jedem Haus bestätigen muss, dass es zu dieser Strasse gehört. Wie gesagt, sowas geht meiner Meinung nach super mit JOSM.
Ich würde mir blöd vorkommen, wenn ich heute an jedem Haus nach der Haus-Nr. gefragt werde und morgen an jedem Haus in der gleichen Straße nach dem Straßennamen.
Die Einschränkung gibst du selbst: “in unseren Breiten”, StreetComplete hat wie OSM nicht das Ziel nur “in unseren Breiten” genutzt zu werden, sondern weltweit. Und da können je nach Region diese Tags sehr viel Sinn machen.
Sehe ich genauso.
Stimmt. Allerdings muss es nicht zwangsläufig so sein. Ich habe jüngst dann und wann SC genutzt und wenn ich maxspeed=* eintrage, folgt sofort die Frage nach surface=*, danach nach der Beleuchtung.