Doch, schon. Sowohl OsmAnd als auch Graphhopper tun z.B., was ich von ihnen erwarte:
barrier=gate ohne Tags lässt Auto & Fuß durch (ggf. weitere),
barrier=gate mit bicycle=no lässt kein Rad mehr durch,
barrier=bollard ohne Tags lässt Auto nicht durch, Fuß+Rad schon.
Ich bin der Meinung, dass spezifische access-tags nichts an Barrieren zu suchen haben, wenn es keine Beschilderung gibt. Die Barrieren stellen physikalische Einschränken dar und verbieten kein Passieren.
Interessante Ansicht. Ich fahre mit dem Rad auch meist um ein barrier=gate rum, wenn ich kann. Bei geschlossenen Eisenbahnschranken mache ich das aber nicht. Warum eigentlich nicht?
Welche access-tags bekommt bei Dir ein Bahnübergang 
Gar keine. Man hat ja auch meist keine Möglichkeit, dran vorbei zu radeln, aber es gibt ja auch einseitige Schranken, und da könnte man schon. Darf man aber nicht, oder? Um ehrlich zu sein, ich habe schon mal (zu) viele Minuten an so einer Stelle gewartet, bis es mir dann doch zu dumm wurde. An roten Ampeln warte ich ja auch nicht ewig. Wenn ich der enzige Verkehrsteilnehmer weit und breit bin, dann traue ich meinem Verstand mehr als der Technik. Kann mich aber gut erinnern, dass ich mit dieser Ansicht nicht weit kam, als mich ein Polizist belehrte, nachdem ich zu Fuß eine rote Ampel ignoriert hatte. “Zeigte sich bei der Belehrung uneinsichtig” stand auf meinem Knöllchen. Ich war noch Schüler, aber der Mann hat Recht behalten 
Hmm - auch wenn man bei vielen barrier-Typen und den zugehörigen ways die möglichen Nutzer erkennen kann - es gibt doch einige Kombinationen, die nicht eindeutig sind. Wie willst Du bei diesen die verschiedene Durchlässigkeit angeben?
Das Problem bei access-tags an Barrieren ist, dass man oft irgendwen vergisst. Was ist z.B. mit Pferden? Oder Beispiel Fahrräder: Welche Art von Fahrrad (Fahrrad mit Anhänger, Dreirad, Liegerad,…) muss durch eine Barriere passen, damit bicycle=yes gerechtfertigt ist?
Die Frage ist doch, wie können wir Daten erzeugen, mit denen möglichst viele Anwender:innen etwas anfangen können? Ich bin für möglichst viele OTG-Daten/Fakten und möglichst wenig Interpretation. Gerade bei so einem Projekt mit so vielen Mitwirkenden, die alle Ihren eigenen Fokus und Vorstellungen haben.
maxwidth:physical (bzw. maxwidth) ist z.B. so ein eindeutiges Datum, dass man OTG gut erfassen kann. Sprich: Wie breit ist das Tor? Mit dieser Information kann jede:r berechnen, ob sie:er dort durch passt.
Wie willst Du ein abgeschlossenes Tor rein physikalisch von einem Gatter unterscheiden, dass so konstruiert ist, dass es Wanderer durchlässt, Wild aber zurückhält? Wie willst Du rein physikalisch darstellen, dass eine Schranke über dem Waldweg zwar PKW abhält, man es aber als Wanderer leicht umgehen kann (und in der Regel auch darf)?
Manche access-tags lassen sich aus den Gegenheiten vor Ort und Kenntnis der allgemeinen Rechtslage auch ohne Beschilderung herleiten.
Also, ein Bild sagt mehr als 1000 Worte:
So in der Art sind die Tore an den Stellen, an denen auch Fußgänger in den Saupark kommen. Am Tor an der Stelle, wo ich umdrehen mußte, war kein spezieller Fußgänger-Durchgang.
Noch eine Frage zum Mappen:
Das barrier plaziere ich als node auf dem track bzw. path. Was ist mit dem fence - bekommt der jeweils an derselben Stelle auch einen node? Oder endet bzw. beginnt der am jeweiligen Wegrand?
Fragt
tracker51
Also ich würde die von Dir gezeichneten Tore als zwei nebeneinanderliegende Tore einzeichnen wie von mir in #7 skizziert.
Der bekommt einen shared node mit dem Way. Das barrier gehört zu beiden Objekten. Sonst wäre der Zaun daneben ja offen.
Im Grunde ist ja das Tor auch Teil des Zauns bzw. eine Sonderform eines Zauns.
oft, aber nicht zwangsläufig.
bicycle bezeichnet erstmal ein Standardrad. Ohne Kinderanhänger, keine Tandemräder und auch keine 12-Personen-Bierbikes. Denn wie du sagst:
In dem man für bicycle ein Standardrad annimmt.
einen Beitrag weiter oben hattest du noch argumentiert, access-ähnliche tags hätten an Barrieren nichts zu suchen weil es sich bei einem Tor um eine physische und nicht um eine legale Beschränkung handle (eine Einschätzung die ich nicht teile, ein Tor verbietet den Zugang auch dann wenn es so altersschwach ist dass man es aufdrücken könnte).
Maxwidth und maxwidth:physical sind dagegen legale Beschränkungen und m.E. für die Breite des Tors weniger geeignet, besser passt „width“ und ist auch angenehm kurz
https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dgate
Okay, hab’ ich so gemacht, allerdings nicht bei dem Tor, durch das ich zum Bus gehastet bin - da habe ich nicht auf die Lage geachtet und will jetzt nichts Falsches mappen. Das gilt auch für ein paar andere Tore, die ich aber noch einmal erkunden werde.
Bei dem östlichsten Tor (am Forsthaus Mühlenbrink) wußte ich es aber und hoffe, daß ich es richtig gemacht habe. Für Rückmeldungen bzgl. von Unstimmigkeiten bin ich immer dankbar.
Ciao
tracker51
Seit wann haben wir ein access-tag für Wild? Und diese Einschränkung kann ich bei deinem Vorschlag auch nicht erkennen. Ansonsten würde ich das durch die Tags der Barriere beschreiben, dass es ich um ein Tor mit speziellen Vorkehrungen handelt bzw. um welche Art von Tor es sich handelt.
Man kann maxwidth:physical mit geschlossener Schranke angeben. An anderer Stelle haben wir mal darüber diskutiert, wie man mehrere maxwidth:phsical Werte angeben kann, wenn man die Barriere entfernt kann. Alternativ kann man den Weg, der die Schranke umläuft separat einzeichnen.
Die Logik verstehe ich nicht. Du schließt Anwender:innen aus uns behauptest, damit würdest Du möglichst viele Anwender:innen berücksichtigen? Wie definieren wir ein weltweites(!) Standardfahrrad? Wie geschrieben: Jede:r hat seine eigenen eingeschränkten Blickwinkel, wenn sie:er durch die Welt geht. Diese Interpretationen sind unnötige Einschränkungen. Was spricht dagegen die Breite anzugeben? Das ist eindeutig und man schließt keine Gruppe aus.
Das ist nicht richtig. maxwidth:physical beschreibt im Gegensatz zu maxwidth eine physikalische Einschränkung. Das gleiche gibt es auch für die Höhe: maxheight und maxheight:physical. Es wird jedoch auch argumentiert, dass es diese Unterscheidung nicht brauch, weil es für die Router-Auswertung auf das selbe hinaus kommt. Ich halte diese Unterscheidung aber für sinnvoll, so kann man bei Vorhandensein von einem Verkehrszeichen sowohl die tatsächliche als auch die rechtliche maximale Durchfahrtsbreite dokumentieren. In manchen Ländern gibt es anscheinend auch unterschiedliche Verkehrszeichen hierfür.
width hingegen beschreibt die Breite von einem Objekt. Bei einem barrier=gate kann man noch argumentieren, dass bei einem Tor width = maxwidth:physical ist, wobei hineinragende Befestigungsmittel und Schlösser die nutzbare Breite weiter einschränken können. Bei einem barrier=bollard beschreibt width jedoch die Breite vom Poller und da passt diese Vereinfachung nicht mehr.
Das kann man direkt an der vermeintlich gendergerechter Grammatik ablesen. Das Flexionsportmonteau mit “Anwender:innen” (wahlweise mit anderen typografischen Elementen wie Sternchen) vereinigt gestalterisch die maskuline und feminine Form. Entweder müssen sich die SJW jetzt die Kritik gefallen lassen, diese Flexion schließe Diverse aus (immerhin gut 0.02% der dt. Bevölkerung lt. Innenministerium), oder man muss anerkennen, dass mit 99.98% doch möglichst viele Standard-“Anwendende” abgedeckt sind.
Wo Du recht hast, hast Du recht.
Die Kombination mit “height” ist deutlich üblicher als die mit maxwidth und erst recht als die mit maxwidth:physical und maxheight, die letzteren beiden tauchen unter Kombinationen für barrier=gate auf taginfo überhaupt nicht auf. Zugegebenermaßen derzeit auch nicht die mit “width” (maxwidth wurde da allerdings auch ins Wiki gefiddelt).
“maxwidth:physical” ist ein tag der praktisch nicht vorkommt in OSM (400 Nutzungen, davon 281 auf nodes), im Vergleich zu allein über 3 Millionen barrier=gate. Außerdem ist der tag als physische Begrenzung nicht wirklich klar, da er sich ebenfalls auf Schilder bezieht, und von daher im Endeffekt nicht das tatsächliche Maß angibt sondern wiederum das was auf dem Schild steht.