Zumindest sehe ich keine widersprüchlichen Angaben. Auf EN:key:barrier steht, dass sich die Vorgabewerte unterscheiden, und auf DE:key:barrier sowie auf EN:Barriers steht, dass Barriers ohne Vorgabewert access=no sind.
Einer sagt also, Joghurtbecher haben unterschiedliche MHD-Angaben, und zwei andere sagen, dass man Joghurt ohne MHD nicht essen kann.
–ks
Prima herausgearbeitet. Einmal wird vom Joghurtbecher gesprochen, das andere Mal vom Joghurt.
Das ist öfters das Problem. 
PS. Ich esse keine Joghurtbecher ohne überalterte MHD-Angabe. 
Zum Thema: ich halte access=public besser als access=yes, letzteres ist mir zu trivial und allgemein.
Public empfinde ich als klarere Aussage.
Bei barrier=entrance ist in der deutschen Version access=yes impliziert (Spalte rechts).
In der englischen Version steht rechts kein Default, dafür steht im Text:
“access=yes is understood”. Was soll das denn heißen?
[1] https://wiki.openstreetmap.org/wiki/DE:Tag:barrier%3Dentrance
[2] https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dentrance
Das Problem ist für mich weniger das, was im Wiki steht, sondern was bei OSM seehr häufig passiert: Parkplätze vom Luftbild weg mappen. Und es werden sehr viele private Flächen gemapped, nur weil auf dem Luftbild da Autos zu sehen sind.
Daher ist das Löschen von access=yes für mich völlig unverständlich. Eigentlich sollten meiner Meinung nach auf der Standardkarte nur Parkplätze mit positiver Angabe zur allgemeinen Benutzbarkeit mit einem dunklen “P” gerendert werden.
In dem Kontext soviel wie „gilt als vereinbart“, „wird allgemein so aufgefasst“.
–ks
Sorry aber wer baut eine Schranke auf einen Waldweg, wenn sie nicht zum zumachen gedacht ist?
Deshalb für mich ganz klar, dass eine Schranke ein access=no implizieren muss. Wenn nun ein Mapper ein solches Element mit access=yes “deaktiviert” halte ich das für eine wertvolle Zusatzinformation.
Genauso bei Parkplätzen. Es zeigt an, dass diese frei zugängliche Parkplätze sind, was ja leider die Minderheit aller Parkplätze sind. Und dass hier nicht einfach eine Information fehlt, sondern der Tatbestand wirklich so ist
+1, und das Argument „dann braucht er sie ja gar nicht erst einzuzeichnen“ sticht nicht. Denn die Schranke in der Karte ist ein Orientierungsmerkmal, und zwar ein wichtiges („100 m hinter der Schranke geht’s links ab“), und der access-Wert¹ wird vom Router gebraucht, damit er weiß, dass diese Schranke zwar da ist, aber den Weg nicht versperrt.
Ich verstehe auch nicht ganz, was es da überhaupt zu diskutieren gibt 
–ks
¹ Dabei gefällt mir das hier vorgeschlagene „public“ sogar besser als „yes“, aber es ist nicht im Wiki dokumentiert, die sinnvolle Auswertung halte ich daher für fraglich.
Ok, hab dann mal rechts auch das “implies access=yes” reingeschrieben so wie in der deutschen Version.
+1
Nach meiner Erfahrung ist die überwiegende Mehrheit von Parkplatzflächen Firmengelände, Betriebsfläche oder Kundenparkplatz und häufig nicht ausreichend/korrekt getaggt. Von daher ist bei Parkplätzen eher Skepsis angeraten und access=yes ist ein wertvolle Information.
von daher ist es noch unklarer als die tags, für die im Wiki ein default angenommen wird. Bei Parkplätzen werden sowohl private als auch öffentliche gemappt, ein expliziter access tag ist daher nicht unbedingt schlecht, wenn nichts dran steht würde ich von access=yes ausgehen
So isses. Ein amenity=parking ohne weiteres Tagging wird – ebenso wie normale Straßen – als allgemein nutzbar betrachtet. Eingeschränkte Parkplätze müssen daher zwingend getaggt werden (meist access=customers, an Wohnhäusern access=private).
–ks
Wo wir gerade bei Parkplätzen sind, ich war letztens in 2 Parkhäusern wo es gar keinen Access gab. Ich hatte das Parkhaus Icon angetippt und der Router sucht wohl als Ziel die nächstgelegene Straße. Leider woanders als die wirkliche Zufahrt.
Beispiel 1: https://www.openstreetmap.org/#map=18/52.00893/4.36374
Beispiel 2: https://www.openstreetmap.org/#map=19/52.01077/4.70381
Ist mir schon öfters aufgefallen.
Ja, wenn das Parkhaus als Fläche gemappt ist kann das schnell passieren.
Routerfreundlich ist die Lösung einen P-Node an der Einfahrt zu mappen und das Parkhaus selbst als building=parking oder so.
Ergänzung: als amenity=parking_entrance.
–ks
Als unbedarfter Nutzer eines Navis würde ich erwarten dass das Routing bis auf den POI funktioniert. Deshalb hätte ich den Parkplatz als POI und gesetzt und eine higway_service von der Straße über amenity=parking_entrance auf den POI. Alle anderen Daten ( operator, fee, multi-storey usw.) dann in den POI übernommen.
Die amenity=parking_entrance erscheint ja erst in der letzten Zoomstufe und findet man zum Teil nur durch detailliertes suchen. Besonders wenn die Einfahrt an 3 Seiten möglich ist. Das P POI kann ich schon viel früher antippen und die navigation starten. Macht es viel einfacher und deshalb würde ich https://www.openstreetmap.org/#map=19/52.01081/4.70401 als POI mappen statt als Fläche.
Meinungen dazu ?
Ach menno, access=yes wurde bei einem Behindertenparkplatz ergänzt. 
EDIT: korrigiert, war mal wieder StreetsComplete.
Für uns ist eine Fläche genauso ein POI wie ein Punkt, die Kartierung von einer Fläche zurück auf einen Punkt zu reduzieren macht m.E. höchstens dann Sinn, wenn die Fläche nicht bestimmbar ist, es also um ein unscharfes Objekt geht. Bei einem Parkplatz wäre es ein Rückschritt. Die Navigation kann genauso gut zu einem Punkt routen wie zum Mittelpunkt einer Fläche (den kann sie sich errechnen, was aber in Ausnahmefällen auch mal nicht so gut funktionieren kann). Wenn dein Navi Punkte statt Flächen braucht müsste man an der „Übersetzung“/Konvertierung für das Navi ansetzen, nicht bei den Ausgangsdaten, weil die möglichst universell einsetzbar sein sollen.