Poller und Routing

ralrei · 2009-05-04T05:46:15.000Z

Hallöchen,

auf der Marktstraße
http://www.openstreetmap.org/?lat=51.38842&lon=6.71004&zoom=17&layers=B000FTF
stehen 2 Poller, damit die Straße wegen der Grundschule von Autos nicht mehr als Durchgangsstraße verwendet werden kann.
Zum einen werden die Poller mit Mapnik nicht angezeigt und zum anderen will http://www.openrouteservice.org/ mich durch die Poller routen.
Auch die routingfähige Karte für mein Garmin Etrex will mich durch die Poller leiten.

Hätte hier das Tagging anders aussehen müssen?

Ralf

de_muur · 2009-05-04T06:14:54.000Z

ralrei:

Hätte hier das Tagging anders aussehen müssen?

Naja, momentan drueckt das Tagging nur aus, dass da Poller stehen, aber nicht, welche Funktion diese eigentlich hanben. Wenn diese eine Sperre fuer Autoverkehr sind, dann ist ein access-Tag wie z.B. motorcar=no sicherlich nicht falsch, ergaenzend dazu am besten auch noch ein foot=yes und ein bicycle=yes. Wie schaut es mit Motorraedern aus? Koennen/duerfen die da durch?

Soviel erstmal zum Tagging. Dass die Poller beim Renderer nicht angezeigt werden, hat damit natuerlich nichts zu tun.

Und auch ein Setzen der access-Tags garantiert nicht, dass das beim Routing ordentlich beruecksichtigt wird. Das Routing laeuft nämlich primaer ueber die OSM-Linien, in wieweit die OSM-Knoten benutzt werden, wird von Router zu Router unterschiedlich sein.

Wenn du sicher gehen willst, dass durch die Strasse keiner geschickt wird, dann kannst du die Strasse vor und hinter den Pollern auftrennen und das Zwischenstueck als footway (oder was auch immer in diesem Fall passen koennte) deklarieren. Der Vorteil davon ist, dass es auf alle Faelle auf der Karte als Unterbrechung sichtbar wird, und dass jeder halbwegs brauchbare Router einen da nicht mehr lang schickt.
Auf der anderen Seite kann man sich natuerlich darueber streiten, ob solche kurzen Fusswege ein “Fehler” sind oder nicht. Im Prinzip geht die Strasse ja ueber die volle Laenge und sollte/koennte deshalb auch komplett so eingetragen werden. Oder aber man sagt, dass an der Stelle der Poller halt keine normale Strasse mehr ist, sondern ein recht breiter und sehr kurzer Fussweg (oder was auch immer), was sicherlich den optischen Eindruck vor Ort nicht treffend wiedergibt, dafuer aber die moegliche Nutzung besser abbildet.

Gruss
Torsten

ThorF · 2009-05-04T07:23:27.000Z

Naja, “Strasse vor und hinter dem Poller auftrennen” - das ist schon recht fragwürdig. Ich lese hier immer “wir mappen nicht für die Renderer”, und jetzt soll entsprechend für Routing gemappt werden? Also, ein Poller ist doch wohl eindeutig als Barriere zu sehen. Typischerweise ist er genau deshalb dort gesetzt, um den Autoverkehr zu blockieren, Fußgänger und Radfahrer aber durchzulassen. Klar, ein “Motorcar=no” kann sicher nicht schaden, aber diesen Tag sehe ich für einen Poller als implizit an. Eine Routing-Software sollte Poller und andere Barrieren (Schranken, Fahrradgatter etc.) auf jeden Fall berücksichtigen, entsprechend des ‘Verkehrsmittels’

FrzME · 2009-05-04T07:45:18.000Z

Meiner meinung nach ist das richtige vorgehen die Straße beim Poller aufzutrennen und hinter dem poller mit access motorcar=no (bzw. delivery oder perimissive) zu taggen da die access eigenschaft ja sicher keine eigenschaft des pollers ist.
Natürlich mappen wir weder für router noch für renderer aber es ist doch richtig das dieser Teil der straße für Autos nicht zugänglich ist. Wenn es jetzt natürlich nur ein Poller wäre (einfach so mitten auf der straße) und nicht zwei wie im konkretem fall sähe das natürlich anders aus → routing software sollte/muss es auch unterstützen

ThorF · 2009-05-04T07:55:45.000Z

FrzME:

Meiner meinung nach ist das richtige vorgehen die Straße beim Poller aufzutrennen und hinter dem poller mit access motorcar=no (bzw. delivery oder perimissive) zu taggen da die access eigenschaft ja sicher keine eigenschaft des pollers ist.
Natürlich mappen wir weder für router noch für renderer aber es ist doch richtig das dieser Teil der straße für Autos nicht zugänglich ist. Wenn es jetzt natürlich nur ein Poller wäre (einfach so mitten auf der straße) und nicht zwei wie im konkretem fall sähe das natürlich anders aus → routing software sollte/muss es auch unterstützen

Stimmt, bei einem Straßenstück *zwischen *zwei Pollern könnte man das Zwischenstück auftrennen. Wobei: Wenn mein Auto zwischen den beiden Pollern ‘gefangen’ wäre, wäre es dann legal, dazwischen hin-und herzufahren? Aber wie Du ja auch sagst, ist es ein generelles Problem, wenn nur ein Poller da ist.
Ich kenne Fälle, da ist eine Straße nur durch Barrieren an einer Stelle künstlich abgetrennt, um den Durchgangsverkehr abzuhalten, d.h. es gibt zwei Sackgassen. Der Straßenname ist auch gleich. Zu Fuß bzw. mit dem Rad kann man an den Barrieren problemlos vorbeikommen.

de_muur · 2009-05-04T08:04:02.000Z

ThorF:

Also, ein Poller ist doch wohl eindeutig als Barriere zu sehen. Typischerweise ist er genau deshalb dort gesetzt, um den Autoverkehr zu blockieren, Fußgänger und Radfahrer aber durchzulassen. Klar, ein “Motorcar=no” kann sicher nicht schaden, aber diesen Tag sehe ich für einen Poller als implizit an.

Das ist jetzt aber deine persoenliche Auslegung, es gibt z.Z. keine Definition, bei welchem barrier welche access-Restriction implizit enthalten ist. Und ich denke eigentlich auch nicht, dass man das global sinnvoll festlegen kann. So gibt es z.B. Wegschranken, die nur Autoverkehr aussperren, es gibt aber auch Wegschranken, die auch das Radfahren verhindern.

Eine Routing-Software sollte Poller und andere Barrieren (Schranken, Fahrradgatter etc.) auf jeden Fall berücksichtigen, entsprechend des ‘Verkehrsmittels’

Das ist sicherlich sehr wuenschenswert, allerdings fuerchte ich, dass die meisten Router bei uns noch nicht soweit sind. Bei den webbasierten Routern weiss ich nicht, wie die Sachen stehen. Das Routing auf den Garminkarten steckt allerdings noch ziemlich in den Kinderschuhen, da wird es doch noch einige Zeit brauchen, bis das nicht nur experimentell sondern wirklich in der Praxis brauchbar wird (die kommerziellen Produkte haben die Messlatte beim Vergleich inzwischen auch schon ganz schoen hochgeschraubt).

Bei OSM haben wir dann zusaetzlich immer noch das Problem, dass wir keinen beschraenkten Wertebereich haben, d.h. wir kennen nicht nur x verschiedene Arten von Barrieren, sondern im Prinzip beliebig viele. Da kann man wohl kaum vom Router erwarten, dass er die automatisch umsetzen kann, wenn man ihm nicht entsprechende access-Tags dazu spendiert.

Gruss
Torsten

ThorF · 2009-05-04T09:22:49.000Z

de_muur:

Das ist jetzt aber deine persoenliche Auslegung, es gibt z.Z. keine Definition, bei welchem barrier welche access-Restriction implizit enthalten ist. Und ich denke eigentlich auch nicht, dass man das global sinnvoll festlegen kann. So gibt es z.B. Wegschranken, die nur Autoverkehr aussperren, es gibt aber auch Wegschranken, die auch das Radfahren verhindern.

Naja, diese Implikationen sind vielleicht nicht immer festgelegt. Was nicht heissen soll, dass man sie nicht sinnvoll festlegen kann und sie z.T. auch schon sind: Z.B. steht im Wiki-Entry zum “barrier=bollard” drin:

By default access=no foot=yes bicycle=yes is implied.

Wobei die “Durchlässigkeit” sicher Auslegungssache ist. Wenn ich eine Wegschranke habe, kann ich evtl. mit dem Fahrrad einfach herumfahren. Und selbst eine Barriere vom Typ “barrier=cycle_barrier” kann ich mit dem Rad überwinden - wenn ich geschickt bin, sogar ohne abzusteigen - ich kann halt nur nicht mit 20km/h einfach durchfahren.

de_muur:

Bei OSM haben wir dann zusaetzlich immer noch das Problem, dass wir keinen beschraenkten Wertebereich haben, d.h. wir kennen nicht nur x verschiedene Arten von Barrieren, sondern im Prinzip beliebig viele. Da kann man wohl kaum vom Router erwarten, dass er die automatisch umsetzen kann, wenn man ihm nicht entsprechende access-Tags dazu spendiert.

Naja, es gibt ja schon “offizielle” Werte und inoffizielle. Für eine Routing-Software ist es sicher nicht verkehrt, per default erstmal zumindest “motorcar=no” für Barrieren anzunehmen, deren Wert unbekannt ist.

TEL0000 · 2009-05-05T01:15:37.000Z

Es ist nunmal so, dass die auswertende Software (Renderer, Routing-Programme, Garmin-Konverter) dem Tagging-Schema hinterherhinken. D.H. es wird in der Regel nur implementiert, wenn es in der Datenbank bereits häufig genug vorkommt.

Die barrier-Tags sind noch recht neu, und daher noch nicht gut implementiert. Sie sind aber besonders auch fürs Routing erfunden worden… Hier hilft nur: Taggen wie in den Map-Features vorgesehen, und dann auf implementierung warten…

de_muur · 2009-05-05T05:47:11.000Z

ThorF:

Naja, diese Implikationen sind vielleicht nicht immer festgelegt. Was nicht heissen soll, dass man sie nicht sinnvoll festlegen kann und sie z.T. auch schon sind: Z.B. steht im Wiki-Entry zum “barrier=bollard” drin:

By default access=no foot=yes bicycle=yes is implied.

…

Naja, es gibt ja schon “offizielle” Werte und inoffizielle. Für eine Routing-Software ist es sicher nicht verkehrt, per default erstmal zumindest “motorcar=no” für Barrieren anzunehmen, deren Wert unbekannt ist.

Ok, im Wiki stehen Default-Werte fuer die Poller, das war mir bisher noch nicht aufgefallen. Da das Wiki aber nicht in Stein gemeisselt ist, sondern sich staendig aendert (leider auch bei der Beschreibung etablierter Tags), bleibe ich dabei, dass es sinnvoll ist, irgendwelche access-Beschraenkungen bei einer Barrier explizit anzugeben. Das gilt dann auch noch 6 Monate spaeter, wenn im Wiki inzwischen vielleicht was ganz anderes drin steht.

Wie ist das eigentlich rechtlich mit den Pollern? Die sind ja normalerweise so aufgestellt, dass ein Auto da nicht durch passt. Fuer einen Roller oder ein Motorrad stellen sie meist ja aber kein Hindernis da. Heisst das, dass diese dann auch da durch duerfen, wenn da keine weitere Beschilderung ist? Dann wuerden die Default-Werte im Wiki naemlich nicht wirklich stimmen.

Gruss
Torsten