Das kommt hinzu…
aus #112
außerdem ist das bei brouter ja noch beta…
Sven
Hallo GeorgFausB,
vielleicht habe ich Tomaten auf den Augen, aber ich kann den systematischen Fehler beim Zusammenmappen nicht nachvollzehen.
Das ist kein Fehler sondern erstmal nur eine Aufgabe, die der Router hat, unabhangig von der Art des Mappings. Er muss den besten Weg finden einschließlich der dazugehörigen Straßenquerungen.
Das verstehe ich nicht. Mit einem ‘sidewalk=both’ wird standardmäßig ausgedrückt, dass überall gequert werden kann, so wie es ja auch der Fall ist.
Solange keine Angabe zum Bordstein gemacht werden bleibt dir Querungsqualität unklar, z. B. wo man mit Rollstuhl hindernisfrei queren kann. Das ist beim Getrennt-Mapping aber exakt das Gleiche.
Auch das ist kein systematischer Fehler sondern einfach noch nicht gemappt.
Sobald man Angaben zur Querungsqualität dazu mappt, ist das auch abgebildet. Der größte mögliche Querungswiderstand wäre ein ‘crossing=no’.
Sicher? Ich würde jedem Fuß-Router mindestens empfehlen, eine Bundesstraße mit ‘sidewalk=no’ mit Maluspunkten zu belegen.
Unabhängig davon sollte uns das nicht hindern, ein Tagging zu finden und zu nutzen, das es den Routern leicht macht, solche Informationen zu verarbeiten.
Ich sehe keine Nutzergruppe, die ausgeschlossen wird. Was meinst du damit?
Dass man für mobilitätseingeschränkte Nutzer Angaben zur Querungsqualität auch beim Zusammen-Mappen machen kann, habe ich in Post 85 beschrieben. Hast du das gesehen?
edit: falsche Post-Nummer
Routago hat auch manchmal Probleme, ist meiner Ansicht nach allerdings trotzdem state of the art, was Fußrouting angeht. Ich seh das Getrennt-Erfassen von straßenbegleitenden Gehwegen, (hierzulande heißen die Gehsteige, das Wort sollte ins Deutsche Vokabular eingehen,) so wie Schienen legen, die Mapper schreiben bis ins kleinste Detail den Routern alles vor. Wenn dann herauskommt, dass eine Straße an Garageneinfahrten betreten und wieder verlassen werden MUSS, und dann auf der Straße weiterlaufen, die man sehr wohl näher am Ziel genausogut queren könnte, dann hat das für mich sehr wenig mit Barrierefreiheit zu tun. Dann könnte man sich das Ganze gleich sparen. Schade finde ich daran vor allem, dass das gleichzeitig ambitionierten Routern Prügel vor die Füße legt.
Nicht dass ich selbst nicht auch ab und zu Gehsteige getrennt erfasse. Weil wie schon Roger Wilco sagte, da ist Sensibilität für die Umstände angebracht.
als Fußgänger muss man immer damit rechnen, dass man mit einer Abkürzung die Route noch etwas verkürzen kann, z.B. indem man eine Böschung runtersteigt oder am Rand einer Wiese entlang geht. Da hat man im Vergleich zum Fahrrad oder Auto auch eher Gelegenheit, die Karte drumrum ein bisschen zu studieren. Klar, fehlende Querungen verlängern die Route „auf dem Papier“, aber für viele reale Anwendungen ist das gar nicht so wild, weil man sich „über die Route hinwegsetzt“ anstatt im Zigzag drum rumzugehen 
Eine der Schwierigkeiten ist es abzubilden wo man einfach so queren kann und wo das nicht geht wegen Absperrungen und anderen Hindernissen, das ist mit Attributen am highway vermutlich einfacher, weil alles an einem Objekt ist, wobei Absperrungen mit unterschiedlichen ways gut abgedeckt sind, wenn man nicht den Anspruch hat, die Art der Absperrung anzugeben.
Kindern beispielsweise will man soweit es geht das Queren nur an Übergängen empfehlen, es gibt unter den „Fußgängern“ jede Menge unterschiedlicher Profile, wenn man es sehr vielen Recht machen will ist ein einziges Profil für Fußgänger auch zu wenig 
Die Verkehrslage spielt natürlich auch eine Rolle, aber in der Stadt wird es auch auf dichtbefahrenen Straßen fast überall regelmäßig ein paar Sekunden und mehr ohne fahrenden Verkehr geben, wegen der Ampeln. Bevor man zig Meter Umweg geht wird man als Fußgänger vermutlich lieber einen halben Meter hochsteigen
Ihr lest beide nicht, was ich schreibe und habt Euch das Beispiel in Ottersberg auch nicht angesehen. Es geht beim getrennt Mapping nicht darum nur Grundstücksauffahrten zu mappen oder nur nur abgesenkte Bordsteine, sondern alle sinnvollen Querungsmöglichkeiten. Das ist z.B. auch die Stelle ohne abgesenkten Bordstein gegenüber von einem Haus (mögliches Ziel). Dort wird dann mit barrier=kerb + kerb=* usw. der Bordstein beschrieben. Der Router hat dadurch erst die Chance eine Auswahl zu treffen. JochenB, wenn Du den Router so konfigurierst, dass Du beim Fahrradrouting auch über 10 cm hohe Bordsteine runter als auch hoch geroutet werden möchtest, dann kannst Du das so einstellen und hast Deinen Spaß beim Radfahren. Andere die das nicht möchten haben jetzt erst die Wahl, das abzulehnen. Nix da mit Bevormundung, wie hier repetitiv behauptet wird.
Routing mit OSRM funktioniert jetzt:
https://www.openstreetmap.org/directions?engine=fossgis_osrm_foot&route=53.10908%2C9.14698%3B53.10947%2C9.14559
BRouter (Wandern beta) möchte es allen Recht machen und verwendet Fußweg und Straße: https://brouter.de/brouter-web/#map=19/53.10931/9.14637/standard&lonlats=9.146979,53.109072;9.145576,53.109469&profile=hiking-beta
Hallo JochenB,
ich gebe zu, dass ich bei meiner knappen Formulierung wohl zu sehr auf Deine Aussage des systematischen Fehlers beim Separat-Mapping sowie die (alleinige) Aussage des “die Fahrbahn kann überall gequert werden”
und den ewigen Madige-Äpfel - Klasse-I-Birnen - Vergleich der Routing-Graphen “Separat mit fehlenden Querungsverbindungen” sowie “Key-Mapping ohne Berücksichtigung des Key-Mappings” eingestiegen bin.
Daher mal etwas ausführlicher:
Mit dieser (alleinstehenden) Aussage beschränkst Du das Routing systematisch auf die Nutzergruppe
Kategorie A: Nutzer, für die ein Bordstein kein Hindernis ist.
Damit grenzt Du die
Kategorie B: Nutzer, für die ein Bordstein ein Hindernis ist
systematisch aus.
Allerdings sagst Du ja zusätzlich aus, dass man Querungshilfen auch per node angeben kann - wodurch das Routing auch für Kategorie B möglich wäre.
Und insofern gehe ich auch mit Dir konform, dass bei korrekter und vollständiger Erfassung das Separat- wie das Key-Mapping bezüglich Deiner 8-Punkte-Liste ziemlich gleichwertig ist.
Key-Mapping hat dabei einen Vorteil beim Punkt 7 Rendering, sobald es um Überzeichnung bei kleinen Maßstäben geht.
Separat-Mapping hat da ein Alleinstellungsmerkmal bei Punkt 8 Exakte Geometrie.
Insofern ist es tatsächlich eher eine persönliche Präferenzierung der eigenen Wichtung.
Ich würde allerdings dann gerne verstehen, was Du mit
meinst?
Ich kann nur vermuten, dass sich das auf den obigen Äpfel-Birnen-Vergleich bezieht.
Und
ja, ich bin mir sicher - und das Tagging ist ja durchaus schon vorhanden - ob es leicht auszuwerten ist, sei mal dahingestellt.
Aktuelle Router arbeiten auf (bereits vorhandenen) Kanten - das Key-Mapping müssten “ambitionierte” Router erst in seitenrichtige (virtuelle) Kanten umformen für ihren Graphen.
Und dann würden sie eine fehlende Querungsangabe genauso gnadenlos mit “fehlerhaftem” Umweg darstellen.
Mein persönliches Fazit:
Beide Mappingvarianten bieten die notwendigen Voraussetzungen für ein Kategorie-B-Routing - und der Mapping-Aufwand ist bei beiden in meinen Augen identisch. Ich persönlich bevorzuge dabei das für mich klarer abgegrenzte und übersichtlichere Separat-Erfassen.
Beim Key-Mapping ist höherer Aufwand auf der Auswerteseite erforderlich.
Aktuell erzeugen Auswerter aus Key-Mapping kein korrektes Routing für Kategorie-B-Nutzer - bis ambitionierte Router soweit sind, bietet das Separat-Mapping bereits jetzt die Möglichkeit.
Und meine Präferenzen liegen nunmal eindeutig bei Denen, für die ein Routing essentiell wichtig ist, als bei Denen, für die es nur eine mentale Erleichterung darstellt.
Grüße
Georg
Je nachdem, wie viel Gepäck ich habe und ob mit/ohne Anhänger, fahre ich ja auch gerne mal gesetzeskonform mit dem Fahrrad. Heißt, ich möchte wissen an welcher Stelle ich von dem Radweg auf die Straße wechseln sollte um dann auch flüssig Linksabbiegen zu können. Das hinzubekommen, halte ich ohne getrenntes Mappen für unmöglich, da es öfter mal vor einer Kreuzung dafür ein Stück abgesenkten Bordstein gibt. So was kann nicht gemappt werden.
das tag sagt aus, dass beidseits ein Gehweg verläuft, aber ob man da queren kann und darf ist dadurch noch nicht völlig klar. AFAIK haben wir noch gar keine tags um sagen zu können hier darf man queren oder nicht, vielmehr vermutet jeder, ist ja klar dass man überall (nicht) queren darf, je nach Rechtslage (ist vielleicht auch ein Fall von: „länderspezifische allgemeine Regelungen werden nicht getaggt“-eine Regel die sowieso eher nicht befolgt wird). Bei sidewalk ist davon abgesehen glaube ich auch nicht immer sichergestellt, dass der nicht doch baulich getrennt von der Straße ist (da könnte ich mich aber auch täuschen ).
Du hast Recht, ansich sagt ‘sidewalk=both’ nur, dass es zwei Gehsteige gibt und nichtmal, ob sie abgesetzt sind oder nicht.
Die Frage ist, wovon gehen wir aus, wenn keine Angaben zum Querungswiderstand gemappt sind.
Ich dachte immer, wenn nichts anderes getaggt ist gehen wir davon aus, dass man queren kann, anders bekäme man heute kein routing hin.
Ich sehe, da wurden ein paar neue Schienen gelegt. Offensichtlich immer noch zu wenige, denn die Router benutzen auf weiten Strecken nicht den Gehweg sondern die Straße. Nicht was Eltern ihren Kindern beibringen wollen. Nicht was Leute mit eingeschränktem Sehvermögen vorgeschlagen haben wollen.
Genau deswegen ist das Getrennt-Erfassen von Gehsteigen wie ganz speziell diesem nicht zielführend.
Update: Verzeihung skyper, dem ich die Worte von GeorgFausB in den Mund gelegt hatte.
Ich bezog mich auf das Vorgehen von OSM_RogerWilco für straßenbegleitende Gehwege. Er taggt an jedem möglichen Ziel eine Verbindung zwischen seperater Gehweglinie und der Straßenline. Im Mappen ist das recht aufwändig.
Er trifft dabei Annahmen, wo Querungen sinnvoll sein könnten. Nehmen wir mal an, diese Annahmen sind richtig, dann sollten die Router immer den besten Weg finden. Für die Anwendung “Routing” wäre dann das Problem gelöst.
In der Karte ist es aber weiterhin nicht korrekt abgebildet. Dort sieht das so aus, als wenn nur an bestimmten (vielen) Punkten gequert werden kann. In der Realität kann man aber überall queren. Das lässt sich mit diesem Mappingverfahren nicht abbilden. Sowas bezeichne ich als “systemetischen Fehler”.
Und nun zum Routingalgorithmus und wie er sich seinen Routing-Graphen erzeugt. Das ist eine echt spannende Frage!
Für die simple Frage “hat die Straße einen Gehweg” braucht es das noch nicht. Die Frage stellt sich erst, wenn die Lage der Gehwege im Routingalgorithmus berücksichtigt werden soll.
Aber nur, wenn man ‘crossing=no’ als Standardwert bei fehlenden Querungsangaben annimmt, siehe zwei Post früher an DieterDreist (#131). Das wäre jedoch inkonsistent zum bisherigen Umgang mit fehlenden Querungsangaben:
Bei Kreuzungen steht heute häufig nichts zu ‘crossing’, auch bei vielen Kreuzungen zwischen Gehwegen und Straßen. Vermutlich alle Router gehen davon aus, dass man dort die andere Straße queren kann, sonst würde das Routing oft schon an der ersten Kreuzung abbechen.
Genauso würde ich es auch mit Querungsangaben an Linien machen. Wenn keine Angabe da ist, so nehmen wir an, dass ein Queren möglich und der Querungswiderstand überall gleich ist.
Dann ergeben sich vier sinnvolle Querungsstellen:
-
wo ich auf eine Straße treffe
-
wo sich seitenraumbezogene Eigenschaften der Straße ändern können
-
wo Querungen getaggt sind
-
wo ich die Straße verlasse
Das sind
-
alle Knoten, wo Linien beginnen/enden/abzweigen.
-
alle Knoten mit Querungsangaben (außer ‘crossing=no’)
-
die Stellen, wo Start und Ziel der aktuellen Routingaufgabe liegen.
Ich denke, wenn der Routingalgorithmus dafür die virtuellen Gehwegkanten erzeugt, sollte er sie genau dort mit der Gegenseite bzw Fahrbahnkante verknüpfen. Dann solllte es auch keine fehlerhaften Umwege geben.
a. und b. kann man einmal im Pre-Prozess für das Netz machen.
c. ist für jede Routingaufgabe speziell, dafür müsste der Router jedes mal virtuelle Knoten im Graph setzen.
Ich bin mir allerdings nicht sicher, ob die Gehwege immer als eigene Kanten im Routing-Graphen abgebildet werden müssen. Womöglich ist das nicht notwendig, wenn es keine Angaben für Querungswiderstände gibt und sich routing-relevante Eigenschaften rechts und links nicht unterscheiden. Dann kann man einfach an der Hauptlinie routen wie bisher auch. Will man Querungen mit einem Malus versehen, wirds schon schwieriger.
Natürlich habe ich das gelesen, verstanden und auch die Beispiele angeschaut. Daher komme ich zu dem Fazit, dass dieser “Workaround” das Problem für Routinganwendungen auf nahezu Null reduzieren kann. Der systematische Fehler bleibt allerdings und der ist auf der Karte sehr gut zu erkennen.
Eine Motivation für einen Seitenwechsel hast du nicht genannt: Ein Wechsel der Eigenschaften der Geh- bzw. Radwege (z. B. einen Wechsel von ‘cycleway:right:smoothness=good’ zu ‘bad’). Hier müsstest du auch noch rechten und linken Geh-/Radweg verbinden.
Hätte er mit meinem Vorgehen beim Zusammenmappen auch.
Was mir aufgefallen ist: Im vorherigen Post habe ich beschreiben, wo der Router in seinen Graphen (virtuelle) Gehwege und Fahrbahnen miteinander verbinden muss:
-
an allen Knoten, wo Linien beginnen/enden/abzweigen.
-
an allen Knoten mit Querungsangaben (außer ‘crossing=no’)
-
an Stellen, wo Start und Ziel der aktuellen Routingaufgabe liegen.
Mit deinem Vorgehen nimmst die im Prinzip dem Router die Aufgabe c. ab, indem du das für alle potentiellen Ziele vorab manuell Verbindungen einträgst entsprechend b. .
Böse formuliert könnte man sagen, weil die Routingalgorithmen es nicht können, wird etwas in die Karte gezeichnet, was es in dieser Form draußen nicht gibt.
An anderer Stelle hat sowas zu heftigen Diskussionen geführt. Dort leiten Mapper aus Radwegnamen Abkürzungen ab, weil die Renderer das selber nicht gut können (zusammengesetzte Substantive). Das war für Einige ein No Go, auch du und u. a. SafetyIng gehörten dazu. Dein Vorgehen hier ist aber ganz ähnlich.
Ne, kann ich bei deinem Vorgehen eben nicht, weil du dort keine Verbindungen mappst.
Wie gesagt, ich will dein Vorgehen nicht schlecht reden. Wenn allo so mappen würden, wäre OSM viel besser!
Ich möchte nur nicht, dass diese Lösung als überlegen dargestellt wird. Mit dem Zusammenmappen kann man das ähnlich gut machen und das hat noch einen großen Vorteil: Fehlende Angaben führen nicht zu Umwegen im Routing - das Standardproblem bei seeerh vielen getrennt gemappten Gehwegen.
Zudem werden Dinge in den Karten so dargestellt, wie sie draußen auch sind (durchgängige Verbindung Radweg/Gehweg mit der Fahrbahn). Nachteil ist die v. a. die fehlende genaue Geometrie.
Ja, das sind vom Mapper festgelegte “Schienen”. Das Problem hast Du beim Tagging übrigens auch. Da musst Du diese Schienen via Tags abbilden, wenn man ein barrierefreies Routing möchte. Deine Schlussfolgerung aus dem fehlerhaften Routing von brouter (Profil Wandern beta!), dass es zu wenig Verbindungen seien, ist aber falsch. Das zeigt Dir z.B. OSRM.
Natürlich. GeorgFausB hat das gut zusammengefasst. Der systematische Fehler beim Getrennt-Mapping ist, dass man nicht überall die Straße erreichen kann, der systematische Fehler beim Tagging ist, dass man man überall die Straße erreichen kann. Für beides gibt es natürlich Anwendungsfälle, wo dieser Fehler nicht zutrifft, weil man die Straße tatsächlich nirgendwo erreichen oder überqueren kann (bauliche Trennung) oder der Gehweg nur durch einen abgesenkten oder ebenerdigen Bordstein von der Straße abgegrenzt ist und es keinerlei Hindernisse, wie Grünflächen, Bäume, Mülleimer, Fahrradbügel oder ähnliches gibt. Das eine ist quasi default crossing=no, das andere default crossing=yes. Beides kann richtig sein aber auch falsch sein und muss durch entsprechendes ergänzendes Mapping oder Tagging angepasst/korrigiert werden. Und das kann je nach Situation bei beiden Varianten in sehr viel Arbeit ausarten und unübersichtlich werden.
Ich sage nicht, dass getrenntes Gehwegmapping keine Fehler hat, sondern ich widerspreche Dir nur, dass das Gehweg-Mapping in erster Linie dafür da sei, die Geometrie besser abzubilden und das durch schlechtes Routing in Kauf nimmt. Es ist für mich oftmals das Mittel der Wahl um die Routing-Probleme eines unvollständiges sidewalk-Tagging zu lösen.
Ja, natürlich. Ich habe nichts anderes behauptet. Macht nur keiner so detailiert. Da wird getaggt, dass rechts und links ein Gehweg ist und die speziellen crossings werden getaggt. Ist genau so fehlerhaft, wie getrennt gemappte Gehwege, die nur an Ampeln und Zebrastreifen verbunden werden.
Nein, das mache ich nicht. Siehe die unterschiedlichen Routing-Ergebnisse der unterschiedlichen Routern. Aber es liegt natürlich am Mapper, wieviele Varianten er mappt und dem Router somit zur Verfügung stellt.
Es ging darum, dass ich angeblich keine Verbindungen mappen würde, wo es keinen abgesenkten Bordstein gibt und Du nicht in den Genuss der erhöhten Bordsteinkanten kommst, wenn Du unterwegs bist 
. Und ich habe entgegnet, dass ich solche Stelle sehr wohl auch eintrage und entsprechend kennzeichne. Somt kannst Du Deinen Router anweisen alle abgesenkten Bordsteine zu ignorieren und nur über erhöhte Bordsteine zu navigieren. Wenn Du aber sagst, dass Du nicht direkt vor Hausnummer 6 über die Straße (mit erhöhten Bordstein) geroutet werden möchtest, sondern 10m davor schon die Straße wechseln möchtest, dann gebe ich Dir recht: Diese Wahl hat der Router bei mir nicht, sofern es keinen (sinnvollen) Grund gibt, an dieser Stelle ein Verbindung einzutragen. Ich wüsste aber nicht, warum die Tagging-Variante da ein anderes Routing-Ergebnis liefern sollte. Auch dann würde der Router vermutlich die Stellen, die besonders gut zum überqueren sind bevorzugen und er wüsste immer noch nicht, dass Du 10 m vor Haus Nr. 6 über den erhöhten Bordstein fahren möchtest, außer Du teilst es dem Router über einen Wegpunkt mit. Und genau für diesen speziellen Fall hat die Tagging Variante tatsächlich einen Vorteil. Ob das jetzt als Argument gegen das Getrennt-Mapping ausreicht?
Ich bin mal (gedacht) ein sportlicher Fußgänger im Detailmapping - getrenntes mappen (ob wohl mir abgesenkte Bordsteine und Zebrastreifen lieber sind):
Als Autofahrer verlasse ich die vorgegebene Route und erhalte neu Anweisungen.
Als Fußgänger sehe ich den gegenüberliegenden Fußweg und wechsele über die Straße und erhalte neue Anweisungen.
Was natürlich “blöd” ist, wenn man ways einträgt, die keinen abgesenkten Bordstein haben, um nur das Routing zu den gegenüberliegenden Weg zu erreichen.
Hier sollte der gesunde Menschenverstand sagen: “Ja, ich kann dort schon mit dem Rollator über den Bordstein wechseln oder ich fahre lieber den vorgegebenen Umweg.”
Du musst nur den Startpunkt auf das Hinterstüberl der Pizzeria Flott legen, dann siehst du, dass OSRM um keinen Deut besser agiert. Wieso auch? Diese Router sind für den Autoverkehr gemacht.
Apropos barrierefrei: Es gibt Kurse, in denen Leute, die im Rollstuhl sitzen lernen, wie sie ohne fremde Hilfe über einen Bordstein kommen. Die Leute mit dem Stock mit weißer Kugel vorn dran schaffen das auch. Innerhalb der Gruppe, für die barrierefreies Routing Sinn macht, gibt es unterschiedliche Bedürfnisse.
Manche ziehen es eventuell vor, länger auf der Straße zu bleiben, während andere es vorziehen, schneller auf den Gehweg zu gelangen. Das ist eine Entscheidung, die der Router treffen sollte, nicht der Mapper.
Für einen Router, der sidewalk tags auswertet wäre es übrigens kein Problem, wenn es an der linken Straßenseite los geht und da ein sidewalk=right an der Straße hängt, dieser bis zur nächsten Garageneinfahrt zu folgen und erst dann “Nach rechts auf Bürgersteig wechseln” anzuweisen. Wenn der Sidewalk separat erfasst ist, dann bleibt keine andere Lösung.
Das ist nicht “blöd” sondern sehr wichtig und nützlich! Natürlich sollte der Bordstein mit barrier=kerb + kerb=* gemappt werden, damit Router die Wahl haben den sportlichen JürgenB freudestrahlend ( :D) diesen Bordstein hochfahren zu lassen und Oma Erna lieber 30 m weiter zur nächsten Grundstückseinfahrt oder Zebrastreifen zu lotsen.
Der Grund liegt an dem fehlerhaften sidewark-Mapping. Du vergleichst hier Äpfel mit Birnen! Diese Seite des separat erfassten Gehweg müsste man erst noch überarbeiten. Der westliche Teil ist auch noch nicht fertig, da noch keine Informationen wie kerb erfasst wurden. Das fehlt dort noch. Velleicht gibt es auch noch weitere sinnvolle Verbindungsstellen, die ich auf dem Luftbild leider nicht erkennen kann.
Ganz genau! Daher benötigen Router alle Daten, um auf die unterschiedlichen Bedürfnisse eingehen zu können.