Im Wiki für Poller steht " Die Eigenschaften access=no foot=yes bicycle=yes werden impliziert."
Impliziert heißt für mich das sie ohne weiter Angaben angenommen werden wenn ich den Poller mit barrier=bollard in die Straße setze. Bei ID wird auch nichts weiter gesetzt, bei der JOSM Vorlage wird foot=yes und bicycle=yes zusätzlich gesetzt.
Ich denke wirklich impliziert ist nur access=no. Stimmt das so?
Ich halte die Situation mit den implizierten access-Werten bei barrier=* für so verkorkst, dass ich sicherheitshalber immer foot, bycicle…=yes dazuschreiben würde.
Bai barrier=* steht, dass access=no der defaultwert ist. Man müsste dann noch beim einzelnen Wert nachsehen, ob dort was anders steht. Bei barrier=bollard ist das zufällig so, bei anderen wurde es vermutlich einfach vergessen (beim Weiderost oder beim Zaunübertritt z.B. wären Fussgänger verboten, was sicher oft nicht die Absicht der Erbauer war).
Da nun niemand weiss, ob sich der Mapper streng ans Wiki gehalten hat, ob er auch alle Wikiseiten dazu gelesen hat, oder ob er für ihn selbstverständliche Dinge einfach vergessen hat, muss auch jeder Auswerter diese Werte recht frei interpretieren und eigene (womöglich andere als der Mapper…) Selbstverständlichkeiten annehmen. Das ist eine recht unglückliche Situation, die man durch ausführliches Taggen vermeiden kann.
Grüße, Max
Das sehe ich im Prinzip genau so.
Bei barrier steht access=no ist der defaultwert sogar mit Bsp. das bei Poller noch foot=yes + bicycle=yes zusätzlich gesetzt werden sollen.
Bei Poller steht access=no foot=yes bicycle=yes werden impliziert. Passt also alles nicht.
Resultat: Manche schreiben es dazu, manchen nicht. Und genau hier liegt auch der Hund begraben. Ein Hauptanwendungsgebiet für viele ist/wird sein das Routing. Und mit den Werten ist es entscheidend wie gut das funktioniert.
Entweder der Router befolgt die Vorgabe (und kommt damit nirgends mehr lang) oder er ignoriert die Vorgabe und …
Wenn wir mal annehmen das wirklich nur access=no impliziert ist haben wir eigentlich ein großes Problem, denn bei vielen fehlen die Zugangserlaubnisse.
Wenn jemand, der overpassisch kann, sich mal die Mühe machen würde alle “barrier” ohne weiter Erlaubnisse abzufragen wüssten wir mehr. Da könnte der Router der sich an die Konventionen hält nämlich dann eigentlich nicht lang.
Vielleicht hat jemand Zeit/Lust das mal abzufragen.
+1
Verbessern lässt sich die Situation (wie bereits gesagt wurde) nur durch explizites taggen.
Das wird eine lange Liste. Eine sehr lange Liste.
…aus meinem Overpass-Reservoir
http://overpass-turbo.eu/s/fhQ
Im Idealfall sollten alle Punkte grün sein (dann ist foot=yes und bicycle=yes vorhanden)
rot: ohne foot=yes und bicycle=yes
schwarz: mit foot=yes und ohne bicycle=yes
braun: ohne foot=yes und mit bicycle=yes
Sven
Ja, da haben wir das erschreckende Ergebnis.
Danke erstmal an streckenkundler für die Abfrage.
Zumindest die roten Punkte finde ich bedenklich. Sollte ausschließlich access=no als implizierter Wert richtig sein müsste der Router an der Stelle “umkehren”.
Wer kann denn zweifelsfrei in Erfahrung bringen welche implizierten Werte bei den barrier Tags gelten?
… naja die braunen sind wohl auch nicht richtig, in der Realität sollten Poller wo man mit den Rad aber nicht zu Fuß durch kann wahrscheinlich selten
Du hast ja schon alles in Erfahrung gebracht: Laut Wiki gilt access=no für alle barrier=* und zusätzlich foot=yes+bicyle=yes für barrier=bollard. Ein barrier=bollard ohne weitere Tags wäre nach derzeitigem Stand des Wiki mit Rad und zu Fuss passierbar.
Was die Leute mappen, hängt davon ab, ob sie das Wiki lesen, wie weit sie es lesen und ob sie sich danach richten.
Was z.B. die Programmierer der Router darus machen, hängt davon ab, ob sie das Wiki lesen, wie weit sie es lesen, ob sie sich danach richten und ob sie glauben, dass die Mapper sich nach dem Wiki richten.
Was in OSM m.E. fehlt, ist ein “verbindlicher” Router. Wo Fehler im Routingsystem auch behoben werden, und als Beispiel für andere Router dienen.
Graphhopper hat einen einen guten Anfang - Probleme aber mit Fußgänger - und in OSM ist nur eine Minimalfunktion eingebunden.
Mapzen funktioniert zumindest schnell und genauer - aber auch nur einige Grundfunktionen.
Ein Prinzip von OSM ist, dass man Dinge schrittweise verfeinern kann. Dies bedeutet, dass man bei wo es sinnvoll machbar ist Defaultwerte festlegt und dokumentiert. Die Defaultwerte sollten idealer Weise in einer Großzahl der Fälle zutrifft. Daher soll man beim Festlegen sich Mühe geben und den Defaultwert nicht dem Zufall oder einem Auswertetool überlassen.
Wichtig ist, zu bedenken, dass ein Defaultwert eine Definition ist, und dass diese nicht “falsch” oder “richtig” ist, sondern nur praktisch / unpraktisch.
Nein, als ich die Standard-Profile für BRouter entwickelt habe, habe ich mich nur danach gerichtet, was ich im Feld vorfinde und wie ich glaube, den besten Kompromiss zu finden zwischen Wege nicht unnötig zerschneiden und nicht plötzlich vor unerkannten Barrieren stehen.
Rausgekommen ist:
- für Fahrrad überhaupt keine impliziten Regeln, barrier=* ist immer zugänglich wenn nicht explizit überschrieben
- für Autos wie oben, aber bei barrier=bollard|gate|lift_gate|cycle_barrier implizit access=no
Sowas kann es nicht geben, weil ein Router, der sich in Wikis, Proposals und der Diskussion über das Landeswaldgesetz von Lummerland verheddert, den würde keiner benutzen, weil er nicht funktioniert, und also wäre er auch nicht relevant.
Im Wiki für barrier (http://wiki.openstreetmap.org/wiki/DE:Key:barrier) steht ziemlich weit unten unter Bemerkungen und unter Beispiele
Bemerkungen
Standardmäßig ist access=no impliziert, deshalb sollten Zugangsberechtigungen für das Element vergeben werden.
Beispiele
Ein Poller, der nur Fußgängern und Fahrradfahrern den Zugang erlaubt:
barrier=bollard
+bicycle=yes
+foot=yes
Und das deckt sich nicht mit dem was unter poller (http://wiki.openstreetmap.org/wiki/DE:Tag:barrier%3Dbollard) steht, nämlich das bicycle+foot =yes impliziert sind.
Daher meine frage was genau denn jetzt stimmt.
Genau, auf den Punkt beschrieben. Der Router wird’s schon richten, nö eben nicht, kann er gar nicht.
Entweder die Route wird total zerschnitten, wirr und unlogisch oder er muss ggf. in Kauf nehmen durch Gelände zu fahren durch das er nicht fahren darf. Ich erinnere an die Treads in denen Leute Routen aus OSM rauslöschen weil es Privatgelände, Parks, Wildbrücken, NSG o.ä. sind.
Muss er aber… Selbst wenn das Wiki perfekt wäre und alles durchreguliert, müsste man noch damit rechnen, dass die Leute gar nicht auf die Idee kommen, alle Regeln zu lesen und auch kein Verkehrsmittel vergessen. JOSM hilft immerhin schon mal gegen Vergessen von Radfahrern und Fussgängern.
Der erste Schritt wäre das wiki mal konsitent zu machen, daher immer noch meine Frage: Was stimmt?
Das was im wiki barrier steht oder das was im wiki poller steht?
Es stimmt beides, denn die konkrete Regel (hier Bollard) schlägt die allgemeine Regel.
Da das nur auf der deutschen und nicht auf der (im Zweifel maßgeblichen) englischen Seite steht, würde ich eher der Aussage auf der Seite zu barrier=bollard vertrauen.
Wenn es stört, dass für das Beispiel auf barrier=* ausgerechnet barrier=bollard genommen wurde, wo an anderer Stelle andere default-Werte angegeben werden, nehmen wir halt was anderes.
Wie wäre es mit “Ein Gatter oder Tor, das nur Fußgängern und Fahrradfahrern den Zugang erlaubt: access=no, foot=yes, bicycle=yes”.
Bei barrier=gate stehen derzeit keiner zusätzlichen default-Werte. In der englischen Ausgabe finde ich auch keinen Widerspruch und dort muss man auch keine Beispiele anpassen, es gibt nämlich keine.
Am default-Wert der Poller sollten wir jetzt nichts mehr ändern. Vielleicht hat sich ja jemand am Wiki orientiert, seit das 2009 so eingetragen wurde 
Ok, bin überzeugt, halbwegs. Die konkrete Regel schlägt die allgemeine Regel.
Die Formulierungen sind aber nicht leicht zu durchschauen und sollten sich zumindest nicht widersprechen.
Bei barrier=kerb ist z.B. access=yes impliziert und schlägt somit das access=no von barrier.
Vielleicht können wir das noch irgendwie zum Ausdruck bringen.
Deinen Vorschlag fände ich sehr gut dann würden sich zumindest nicht die beiden wiki’s widersprechen
Vorschlag zur Formulierung
Bemerkungen:
Standardmäßig ist für barrier=* immer access=no impliziert, zusätzlich können für einzelne Elemente aber bereits Zugangsberechtigungen impliziert sein, welche die Einschränkung für einzelne Verkehrsmittel standardmäßig erlauben bzw. die Zugangsberechtigung komplett erlauben.
Bsp.: barrier=bollard impliziert access=no + foot=yes + bicycle=yes
Bsp.: barrier=kerb impliziert access=no + access=yes 
Zu den implizierten Werten siehe …
Und wenn noch ein Bsp. benötigt wird dann das “falsche” Bsp. mit deinem Bsp. ersetzen.