MapFactor Navigator für Android ignoriert nodes mit barrier = ...

fireball2 wrote:

impliziert jedenfalls "barrier=lift_gate" generell ein "access=no", es sei denn man erlaubt explizit gewisse Fortbewegungsarten, z.B. "foot = yes" ?!?!

Richtig.
Du kannst Dich im mapfactor Forum auch über facebook oder google account einloggen.

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.

hurdygurdyman wrote:

Ich finde, es ist keine gute Idee, barrier=lift_gate grundsätzlich als Sperre anzusehen.

Sehe ich auch so, Wiki-Definitionen nachträglich zu ändern bringt allerdings nur Chaos.

Eisenbahnschranken werden bei uns ja glücklicherweise selten separat gemappt sondern sind über level_crossing
abgehandelt.

fireball2 wrote:

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?!

Falls es sich um eine Einfahrt in einen Waldweg handelt ist es völlig okay diesen Weg mit motor_vehicle=no oder forestry zu beschränken.

chris66 wrote:

Du kannst Dich im mapfactor Forum auch über facebook oder google account einloggen.

Danke, dass wusste ich nicht.

erfi wrote:

... Die Libboldallee in Berlin ist vom Parksteig durch mehrere dicke Steinpfosten getrennt. ... Trotzdem ignoriert Navigator diese Tatsache, das ist ärgerlich.

Danke, d.h. auch "barrier = bollard" sogar mit explizitem "motor_vehicle=no" wird ignoriert! Sehr schade.

hfst wrote:

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.

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?!?!

hurdygurdyman wrote:

Ich finde, es ist keine gute Idee, barrier=lift_gate grundsätzlich als Sperre anzusehen.

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.

fireball2 wrote:

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?!?!

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...

hfst wrote:

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.

Der Default-Wert für barrier ist no:

Impliziert
access=no

https://wiki.openstreetmap.org/wiki/DE:Key:barrier

Implies
access=no

https://wiki.openstreetmap.org/wiki/Key:barrier

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".

[1]

foot=yes
bicycle=yes

https://wiki.openstreetmap.org/wiki/Tag … %3Dbollard
https://wiki.openstreetmap.org/wiki/DE: … %3Dbollard

Gruß,
Mondschein

fireball2 wrote:

...

hurdygurdyman wrote:

Ich finde, es ist keine gute Idee, barrier=lift_gate grundsätzlich als Sperre anzusehen.

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.
...
Die Diskussion sehe ich damit als beendet an, da meine Frage ausreichend beantwortet wurde. Ich bedanke mich für die zahlreichen Rückmeldungen.

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

hfst wrote:

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...

Sven

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.

Baßtölpel

hfst wrote:

Alles mit der Ruhe...

Ich bin noch sowas von ruhig...

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.

erfi wrote:

Mein Ergebnis nach dem Kartenupdate (20.11.2015): Das "motor_vehicle=no" bei der eingezeichneten Barriere bringt keine Besserung. Habe es probiert.
(...)

Das ist dann aber ein Problem des RRoutins und kein Kartenfehler.