die Android-App MapFactor Navigator scheint leider Schlagbäume generell zu ignorieren? Kann dies jemand bestätigen? Bei gewähltem Fahrzeugprofil “PKW” navigiert es mich einfach durch den Schlagbaum durch, zusätzliche access-Tags (z.B. motor_vehicle=no) erzwingen da anscheinend auch keine andere Routenführung. Ob jetzt wirklich alle barrier-Tags konsequent ignoriert werden, habe ich nicht geprüft, aber vielleicht weiß hier jemand im Forum mehr. Soweit ich es verstanden habe, impliziert jedenfalls “barrier=lift_gate” generell ein “access=no”, es sei denn man erlaubt explizit gewisse Fortbewegungsarten, z.B. “foot = yes” ?!?! Aus Gründen des Aufwandes und “wir kartieren nicht für’s Navi”, würde ich jetzt nicht anfangen wollen, “nur für diese App” um jeden Schlagbaum nun auch noch ein kurzes Stück Straße mit “access=no”, o.ä. einzutragen?! Vielleicht liest hier ja jemand von dieser Firma mit und kann die Frage beantworten oder gar lösen, so dass ich mir nicht erst einen Account im MapFactor-Forum anlegen muss.
Diesen Umstand habe ich auch schon erleben müssen. Beispiel: Die Libboldallee in Berlin ist vom Parksteig durch mehrere dicke Steinpfosten getrennt, …und das schon seit mehr als 50 Jahren. Eine Durchfahrt mit einem Pkw ist unmöglich, die Zufahrt ist für PKWs nur von der Regattastraße möglich. In der OSM-Karte ist das richtig gekennzeichnet. Trotzdem ignoriert Navigator diese Tatsache, das ist ärgerlich.
Ansonsten bin ich mit Navigator sehr zufrieden.
Ich finde, es ist keine gute Idee, barrier=lift_gate grundsätzlich als Sperre anzusehen. Wenn ich an micromapping bei Bahnübergängen, Passstraßen oder beweglichen Brücken denke…
Ein Blick ins Wiki hilft. Bei bollard und lift_gate sind Zugangsrechte angegeben.
Bei bollard sind das access=no/foot=yes/bicycle=yes
Bei lift_gate ist kein Default Wert angegeben werden. Es wird auf access=* hingewiesen.
Damit steht es dem Router frei die Schranke als access=yes (passt für Mautschranken) oder access=no/foot=yes etc. (passt für Schranken an Waldwegen) anzunehmen.
Danke, d.h. auch “barrier = bollard” sogar mit explizitem “motor_vehicle=no” wird ignoriert! Sehr schade.
Aha, wieder was dazugelernt! Allerdings wären dann sehr viele Poller und Schranken in der OSM-Datenbank unzureichend erfasst (auch von mir). Bei allen Barrieren-Nodes habe ich bislang immer nur die erlaubten Verkehrsmitteln mittels access eingetragen. Somit müsste ich bei allen Schranken und Pollern noch ein “access=no” ergänzen, da ich bislang davon ausging, dies wäre bereits impliziert?!?!
Da möchte ich folgende “Idee” dagegenhalten. Ein Schrankensymbol auf einer Straße (z.B. auf einer Papierkarte) sagte mir bislang immer, dass ich dort nicht ungehindert entlang fahren kann. Warum wäre dort wohl sonst eine Schranke eingetragen? Daher zöge ich ein impliziertes “access=no” vor, eine Routersoftware kann ja nachgucken, welcher Verkehrsteilnehmer bei der Schranke doch durch darf. Ist die Schranke immer offen (meines Erachtens ein Ausnahmefall), dann eben noch schnell ein “access = yes” ergänzt. Nach Deiner Idee wäre die Schranke immer offen, es sei denn man ergänzt immer ein access=no + Verkehrsteilnehmer = yes?! Laut overpass-turbo wären dann 99% aller Schranken in meiner Region (nicht nur die von mir) geöffnet. Wie auch immer, dieser Sachverhalt war nicht Gegenstand meiner Frage und sollte bei Bedarf separat diskutiert werden.
Meine abschließende Meinung:
Soweit ich das MapFactor Forum überlicke, macht es leider keinen Sinn dort einen weiteren Thread zu diesem Thema zu eröffnen, da es dort schon einige Metusalems bezüglich der Beachtung von Barrieren gibt. Es scheint also leider nicht auf der Dringlichkeitsliste von MapFactor zu stehen. Ich persönlich finde die Beachtung der Barrieren und damit die Berechnung einer korrekten Route als sehr wichtig, aber dies machen bekanntlich derzeit nur sehr wenige Router. Zudem guckt man einem geschenkten Gaul bekanntlich nicht ins M… . Da mich bislang nur eine bestimmte Schranke “nervt”, behelfe ich mir eben mit dem Feature “Verbindung sperren”. Alle Ortsunkundigen werden jedoch immer erstmal von MapFactor Navigator zu dieser Schranke geleitet und dürfen dann dort auf “R” schalten.
Die Diskussion sehe ich damit als beendet an, da meine Frage ausreichend beantwortet wurde. Ich bedanke mich für die zahlreichen Rückmeldungen.
Bei Poller braucht es in der Regel keine access-Tags, denn der Defaultwert ist, dass nur Fußgänger und Radfahrer passieren dürfen. Bei der Schranke müssen access-Tags ergänzt werden, da es keine Defaultwerte gibt.
Korrektur: Bollard=* impliziert access=no. Und da lift_gate nichts eigenes festlegt erbt der access=no. Details siehe unten.
@fireball2: Das “motor_vehicle=no” habe ich erst vorgestern gesetzt. Bislang war dort kein Eintrag. Ich werde es nun im Auge behalten und beim nächsten Update testen. Vielleicht lag es genau daran…
Wenn also weder im entsprechenden Wikieintrag zu der Barriere (wie z.B. bei barrier=bollard [1]) noch am Objekt selbst etwas anderes vermerkt ist, dann gilt “access=no”.
Wenn du mich zitierst, dann bitte vollständig. Ich schrieb: Ich finde, es ist keine gute Idee, barrier=lift_gate grundsätzlich als Sperre anzusehen. Wenn ich an micromapping bei Bahnübergängen, Passstraßen oder beweglichen Brücken denke…
Nach meiner Vorstellung wäre eine Schranke nicht immer offen, genauso wenig, wie sie immer oder meist geschlossen sein kann. Ein default-Wert macht somit bei Schranken keinen Sinn. Da muss ein acces-Wert her, aus dem man die Art der möglichen Nutzungsbeschränkung erkennen kann.
Und solange wir keinen Weg finden, um den routern eindeutige Auswertungsmöglichkeiten der barrier-tags zu bieten, müssen wir denen schon überlassen, wie sie die “sichere Seite” der Angaben interpretieren.
Und nun zu meiner Gebetsmühle:
Solange bei OSM jeder machen kann was er will, können wir auch nicht erwarten das eindeutige Auswertungen möglich sind.
Die alte Regel “shit in - shit out” gilt weiterhin. Aber unser Weg zur guten alten Regel der Eindeutigkeit in Datenbanken und dem sinnvollen Ansatz “one problem - one solution” ist entweder noch lang oder “access=impossible”
Alles mit der Ruhe. Wie Mondschein oben ausgeführt hat, bedeutet bollard=* erstmal access=no. Damit gibt es ein festgelegtes Defaultverhalten für lift_gate.
Interessant wird die Frage, wie wir mit Lift_gates am Waldrand umgehen. Trampelpfad um die Schranke einzeichnen oder foot=yes; bicycle=yes
Bei “Trampelpfad um die Schranke einzeichnen” mag man im ersten Moment an “Tagging für was weiß ich” denken. Von einigen “meiner” Schranken im Spreewald weiß ich, daß es diese Wege um die Schranken gemäß der OnTheGround-Regel wirklich gibt…
Trotzdem halte ich foot=yes; bicycle=yes für die formal korrekt Variante…
Ich finde es durchaus sinnvoll, solche Wege als path einzuzeichnen. Es kann ja sein, daß man für die zwei Meter Gummistiefel oder lange Hosen mitbringen sollte. foot=yes; bicycle=yes am node habe ich bisher dennoch verwendet, da diese Tarampelpfade zu kurz sind, um sie geometrisch korrekt per GPS zu erfassen und ich zu faul bin.
Mein Ergebnis nach dem Kartenupdate (20.11.2015): Das “motor_vehicle=no” bei der eingezeichneten Barriere bringt keine Besserung. Habe es probiert.
Ich habe soeben in OSM die Libboldallee geteilt und habe nun die letzten 3m der Straße zum Parksteig für Motorfahrzeuge auf “no” gesetzt. Mal gucken, wie Navigator dann damit umgeht.