iD: access=psv im Drop-Down-Menue, im Wiki nicht erwähnt

Eine Merkwürdigkeit von iD:

access=psv ist im OSM-Wiki nicht erwähnt

Wie damit umgehen?

PTNA meckert hier derzeit und schlägt vor stattdessen access=no und psv=yes zu taggen

Also für DE ist access=psv totaler Käse und in vielen Fällen eigentlich vehicle=no + psv=yes oder gar nur bus=yes, da taxis extra erwähnt werden.

Stimmt. Manchmal sehe ich neben access=psv noch foot=yes und bicycle=yes … dann wäre access=no + … + psv=yes schon mal eine gute Näherung (ohne vor Ort gewesen zu sein).

Zumeist ist nur ein access=psv dran und ich frage mich (und gegebenenfalls "the mapper’), wie die Passagiere dorthin gelangen (rein formal, basierend auf access-rights in OSM).

Hmm, manchmal gibt es einen Fußweg/Pfad zum Bussteig. Aber wie gelangen die Fahrgäste vom Bussteig in den Bus?

ja, sorry: hatte vergessen zu erwähnen, dass dabei zumeist keine Fußwege in der Nähe sind, die Passagiere also > 50 m über die Straße “geleitet” werden müssen (formal, Navi-mäßig).

Ein beherzter Sprung, aus dem Stand? Ohne Anlauf, denn eine ‘platform’ als Node hat keine Ausdehnung, keine Strecke zum Anlaufnehmen? :wink:

Anpassen, wenn WIssen oder Daten (Mapillary) vorliegen ansonsten den Mapper, der es eingeführt hat fragen.

im iD werden nach meiner Beobachtung als Auswahl auch Werte angezeigt, die nirgendwo dokumentiert sind. Ich habe das Gefühl, die zeigen auch Dinge an, die andere manuell eingebebn haben bzw. die es in dem gerade zu bearbeitenden Kartenabschnitt schon gibt. Ich habe jedenfalls schon öfter Werte mit erkennbaren Schreibfehlern neben den korrekten Werten zu Auswahl angeboten bekommen.

wäre irreführend, wenn man in Drop-Down-Listen solche Dinge anbietet: man glaubt, das seien “offizielle”, weil im GUI implementierte Vorlagen.

Hier verhält sich JOSM wohl analog.

Meines Wissens nach übernimmt iD die Werte von Taginfo und schlägt diese auch in Reihenfolge nach deren Häufigkeit vor. Verschwände demnach access=psv als Tag aus der Datenbank, würde der Wert auch in iD nicht mehr angezeigt bzw. vorgeschlagen.

Ich vermute mal das wurde hauptsächlich wegen den Straßen- und Ortsnamen eingeführt, damit der Editor per Anfangsbuchstaben schon eine nützliche Vorauswahl anbietet, die man dann einfach übernehmen kann anstatt jedes Mal komplett einzutippen.
Dass es bei anderen Tags auch funktioniert kann man als Fluch oder Segen sehen.

access=psv wird schon über 1349 mal verwendet, access=bus wird 1639mal verwendet… das ist ja schon fast defacto

https://taginfo.openstreetmap.org/tags/access=bus#chronology
https://taginfo.openstreetmap.org/tags/access=psv#chronology

In der Chronology sieht man zwar immer wieder Rückgänge, wahrscheinlich durch umtagging… aber es hat sich immer wieder erholt. Das Tagging gibt es schon seit über 10 Jahre :slight_smile:

Und es gibt auch anscheinend keine Probleme zu verstehen was gemeint ist :wink:

Gruß Miche

Nein, dass ist nicht der Grund (und der Mechanismus wird in der Form auch nicht für Namen gebraucht)…

Siehe auch https://2018.stateofthemap.org/2018/T061-An_excursion_in_to_the_world_of_OSM_tagging_presets/

Defacto “falsch”. Es gibt klar die Struktur der Access-Tags. Siehe auch hier: https://wiki.openstreetmap.org/wiki/DE:Key:access
Vor allem, für psv=* gibt es mehr als 100k Einträge und für bus=* mehr als 170k Wege und 2 Mio Nodes…

Man kann nicht einfach allen Datenauswertern so einen Sch**** vorwerfen und sagen: Ihr müsst halt damit leben. Es gibt ne klare Struktur im Bereich der Zugangsbeschränkungen…

Gut, dann werde ich das Meckern in PTNA belassen:

  • access=bus oder access=psv wird als Fehler angesehen mit Kommentar, dieses gegebenenfalls als access=no und bus|psv=yes zu mappen.

Das wäre rein formal die korrekte Umsetzung.

Ob foot=yes, bicycle=yes schon dran sind oder noch dran müssen oder motor_vehicle=no nicht besser wäre als access=no prüfe ich weiter nicht.
Das könnte ich in der Dokumentation noch vervollständigen


- Meldung:        Route: fehlerhafte Beschränkung (%s) auf Weg. Gegebenenfalls mappen als '%s'='no' und '%s'='yes' 	
- Type:           Fehler
- Option:         check-access 
- Erläuterung:    Die Beschränkung stimmt nicht mit den Map Features überein.
- Hinweis:        Bitte konsultiere das OSM Wiki: https://wiki.openstreetmap.org/wiki/DE:Map_Features#Beschränkungen

Eine Access=no… hab ich eine allergie wenn dann vehicle=no bzw.

In DE meist ist das vorzufinden:
http://osmtools.de/traffic_signs/?signs=250,1024-14

+1, wenn nicht sogar motor_vehilce=no

Auch “motor_vehicle=psv” würde hier auch als Fehler gemeldet (“fehlerhafte Beschränkung (%s) auf Weg”)
Bei “Gegebenenfalls mappen als ‘%s’=‘no’ …” wird im %s lediglich der Key der fehlerhaften Beschränkung wiederholt (access, vehicle, motor_vehicle, …).

Die Prüfung in PTNA ist hier nicht ganz so schlau wie sie evtl. sein könnte, sollte aber auch keine falschen Vorschläge machen.

Wie es vor Ort korrekt wäre, weiß man nur wenn man vor Ort war oder Mapillary/Kartaview zu Hilfe nimmt.

Sehe ich auch so. Access=no ist in solchen Fällen in der Regel nicht korrekt, da sonst auch ein Fußgänger dort nicht entlang dürfte, was aber in der Regel zulässig ist.

Ich habe erste neulich bei einigen Waldwegen access=forestry durch motor_vehicle=forestry ersetzt. Die ganzen Wanderer und Radfahrer, die auf den meisten Waldwegen legal unterwegs sein dürfen, wären sonst ausgeschlossen, es sei denn, sie seien gerade forstwirtschaftlich unterwegs.

Access=no heißt “Betreten und Befahren verboten”, was bei öffentlichen Straßen nur selten der Fall ist.

ja kommt auch vor… da dürfte man z.B. mit Fahrrad noch durchfahren… des müsste man prüfen was genau…, also mindestens motor_vehilce=no… :confused:

Edit:
mit motor_vehilce=no wäre dann des:
http://osmtools.de/traffic_signs/?signs=260,1024-14

access=* mit access-Schlüsseln als Werten ist mir schon öfters aufgefallen. Wollte eigentlich einen Validator-Test dafür schreiben, bin aber leider noch nicht dazu bekommen.

Grundsätzlich ist access=* mit Vorsicht zu geniesen. private und permissive sind oft nicht exakt und auch bei no bei Baustellen werden häufig die zusätzlichen access tags übersehen und dann ist die Baustelle doch für z.B. Fahrrad noch frei, da bicycle=yes access=no überschreibt.

Haben mal wieder das Problem, dass die Renderer access=* darstellen, aber bei nur einem vehicle=no fehlt dann meistens schon die Unterstützung, von Kombinationen mehrere access Tags oder gar :conditional ganz zu schweigen.