Wenn ich irgendwo ein access=yes sehe, dann lösche ich das generell…
Mir ist nicht verständlich was daran sinnvoll sein soll.
Per Vorgabe ist alles automatisch access=yes - zumindestens bei den Straßen. Dann wird wenn nötig nur eingeschränkt.
Gibt es Ausnahmen?
Warum soll das ganze bei Parkplätzen anders sein?
Es gibt Fälle da finde ich - speziell bei Parkplätzen - eine Angabe zum access sinnvoll um Unklarheiten zu beseitigen… Und dann benutze ich access=public - weil aussagekräftig.
Wie schon gesagt, sagt meiner Meinung nach access=yes gar nichts aus. Also weg damit…
Im Wiki ist “yes” dokumentiert und wird 595.000 benutzt. “public” gibt es dort nicht, wird aber laut taginfo 31.000 mal benutzt.
Ich bin darüber gestolpert weill StreetComplete bei enem öffentlichen Parkplatz ein access=yes rein macht. Darum wird es ja auch so oft benutzt…
Wenn ich z.B. ein barrier=gate auf einem Wanderweg mappe, tagge ich immer access=yes dazu. Freigaben müssen sowieso dran, damit da durchgeroutet werden kann, mit einem allgemeinen yes vergesse ich keine Verkehrsart, und „zu viel“ gebe ich damit auch nicht frei, weil z.B. Autos da ja gar nicht hinkommen.
Wenn man sicher davon ausgehen kann, dass jemand bewusst access weggelassen hat, weil der Parkplatz allgemein zugänglich ist, dann wäre es ok. Parkplätze sind aber auf Luftbildern als solche gut erkennbar und werden gern von Couch-Mappern in OSM eingetragen ohne weitere Zusätze, wenn man die Ortskenntnis nicht hat. Per default ist das dann ein allgemein zugänglicher Parkplatz, der on-the-ground vielleicht gar keiner ist, sondern in irgendeiner Art und Weise ein Privatparkplatz mit eingeschränkten access: Kundenparkplätze von shops aller Art, vermietete P+R Parkplätze der Deutschen Bahn oder die Patientenparkplätze einer Kurklinik an der Ostsee. Blöd, wenn man als Kartennutzer einen schönen Parkplatz in Strandnähe findet, dort hin fährt und dann doch nicht parken darf (der Renderer oder der Router kann es gar nicht anders wissen).
StreetComplete fragt solche “fehlenden” tags ab. Richtige Anwendung durch den Nutzer vorausgesetzt besagt ein “access=yes”: ein Mapper war vor Ort, hat es überprüft und festgestellt, es ist ein allgemein zugänglicher Parkplatz ohne Einschränkungen. access=public sagt m.E. das gleiche aus.
Kommt aufs barrier an. Einige barrier-Objekte haben Defaultwerte, die im Wiki angegeben sind. Bei barrier=bollard ist z.B. foot=yes und bicycle=yes impliziert. Das ist natürlich sinnvoll, aber Reiter werden damit immer noch ausgesperrt, obwohl sie Poller normalerweise passieren können und dürfen. horse=yes gehört daher fast zwingend an jeden Poller dran.
Alle barrier-Elemente ohne Defaultwerte gelten als access=no. Das kann man doof finden, aber es ist so festgelegt. Daher muss man mit wachen Sinnen mappen.
barrier=gate hat keinen Access-Default und gilt daher ohne spezielles access=Tagging als geschlossene Sperre für alle Verkehrsarten. Daher ist
nicht zielführend, denn ein Router, der durch ein barrier=gate ohne getaggte Freigaben nicht hindurchroutet, verhält sich genau richtig, ein besserer wird es daher auch so machen.
Nein, das ist Erfassen der Realität und damit genau das, was OSM leisten will.
Und nochmal: Das immer wieder als Universaltotschlagargument missbrauchte „mappen für xy“ bedeutet nicht, beim Mappen auf xy Rücksicht zu nehmen, sondern es bedeutet, absichtlich etwas Falsches zu mappen, nur damit in xy das Gewünschte rauskommt. Bitte erklär mir, wieso ich etwas Falsches mappe, wenn ich an ein passierbares Gate dranschreibe, dass es passiert werden kann.
@Mammi71: So kann man bei jedem Objekt ins OSM argumentieren. OSM ist Opt-In. Nur wenn es etwas “spezielles” gibt wird das gemappt. Dieses “vorort-übergeprüft”, “last-check-date”, … ist eine ganz andere Baustelle! Wenn das StreetCompleet dazu fügen würde wäre das OK. Aber dieses “access=yes” sagt nicht wirklich was aus - und schon gar nicht, dass das irgend jemand vorort geprüft hat.
Aha! Per Vorgabe ist eine Straße immer erst einmal access=yes!
Weiterdenken: Per Vorgabe ist ein barrier wo nix dran steht immer erst einmal access=no - das ist der Sinn einer Barriere! Natürlich kann da kein Router durchrouten. Der Router weiß ja so gar nicht, was für eine barrier das ist. Natürlich muss man für den Router mappen, geht gar nicht anders. Natürlich könnte man aus dem access des Weges davor und dahinter ableiten, welches access für die barrier gelten könnte, aber kann man sich immer sicher sein, dass auch die access-Bedingungen am Weg absolut richtig sind?
OK, bei “barrier”. Wußte ich nicht. Dann habe ich wohl - durch nicht vorhandene access-tags - in der Vergangenheit nicht optimal gemappt. Das implizierte “no” halte ich aber auch hier für falsch!
Nein, kann man nicht. Eine Schranke auf einem Waldweg kann (unpassierbar) geschlossen sein (etwa vor einer Schonung oder einer Wildruhezone), obwohl die highway=track davor und dahinter foot=yes implizieren.
Grundsätzlich einig. Im Moment ist es aber anders umgesetzt.
Wenn man davon ausgeht, dass ein bewusst gesetztes tag möglicherweise nicht vor Ort geprüft wurde, dann muss man annehmen, dass so ziemlich alles in OSM nicht vor Ort geprüft sein könnte.
Sorry, Fehlschluss. Implizierte access-Werte unterscheiden sich von barrier zu barrier, das ist klar. Aber in https://wiki.openstreetmap.org/wiki/Barriers steht weiterhin: Barriers with undocumented default access imply access=no. This default restriction prevents softwares from routing through undocumented barriers (and generating a potentially unsafe route).
Viele barrier, darunter barrier=gate, haben keinen Defaultwert und gelten daher als access=no. Daran hat sich nichts geändert.
