Bürgersteige/Fussweg

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

1. alle Knoten, wo Linien beginnen/enden/abzweigen.

2. alle Knoten mit Querungsangaben (außer ‘crossing=no’)

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

1. an allen Knoten, wo Linien beginnen/enden/abzweigen.

2. an allen Knoten mit Querungsangaben (außer ‘crossing=no’)

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

#132

Das habe ich nie geschrieben.

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.

https://www.openstreetmap.org/way/993871294
ist nicht vorhanden. Wir tragen ein, was wir sehen, wie es vor Ort ist.

Ich hätte nichts dagegen eine Linie mit virtual:highway=* ( 56 x https://taginfo.openstreetmap.org/search?q=virtual%3Ahighway ) einzutragen, dann hat ein Router die Möglichkeit es zu verwenden und der Renderer die Möglichkeit es auszublenden.

Ich würde sogar vorschlagen das highway:virtual=* ( 48 x https://taginfo.openstreetmap.org/search?q=highway%3Avirtual#keys ) in virtual:highway=* zu ändern, damit highway:= für tatsächliche Wege frei wird / bleibt und virtual:*= * auch z.B. für Fährlinien und (Wasserwander-)routen frei ist.

( Gab es schon mindestens einmal https://forum.openstreetmap.org/viewtopic.php?id=66678 - Leider bin ich kein Proposal-Fan …)

Betrifft auch virtuelle Wege auf Plätzen. Aber auch die Mittellinie von mehrspurigen Straßen ist letztendlich nur eine Art virtuelle Linie. Auf der Mittellinie fährt niemand. Das Flächen-Mapping von Straßen und Wegen könnte eine Lösung sein.

Aber auch ich würde ein Tag zum Kennzeichnen solcher Verbindungen begrüßen.

Hat er leider nicht. Wir haben ja schon erkannt, dass beim Taggen der Gehwege an der Straßenlinie kein systematischer Fehler vorhanden ist. Man kann dort durchaus darstellen, dass man abschnittsweise nicht queren kann. Das hatte ich hier mehrfach gezeigt.

Ein systematischer Fehler wäre es, wenn das nicht möglich wäre. Dass es kaum jemand macht hat nichts mit dem System zu tun sondern eher damit, dass es nicht ausreichend dokumentiert ist.

Beim Seperat-Mapping ist es anders, da kann man die kontinuierliche Querungsmöglichkeit nicht sauber abbilden. Man kann aber mit punktuellen (virtuellen) Verbindungen negative Auswirkungen auf das Routing minimieren.

OK, verstanden. Diese Generalisierung ist nicht korrekt. Bei vielem, was ich so sehe, denkt allerdings offensichtlich niemand ans Routing. Da vermute ich zwei Motivationen:

• Geometrien möglichst genau zu erfassen (Informationen aus dem Luftbild möglichst exakt übernehmen)

• Den Renderer dazu bringen, es darzustellen (Mapping für Renderer, ‘sidewalk=*’ wird ja kaum gerendert)

Der Unterschied ist aber, dass das übliche unvollständige Getrenntmapping zu den Umwegen führt. Das unvollständige Zusammenmapping erzeugt dagegen keine Umwege.

Für Mobilitätseingeschränkte sind beide Mappingarten wenig hilfreich, wenn sie unvollständig sind.

Bezieht sich dein “Nein” auf das “alle potentielle Ziele”?

Letzten Endes ist das “dem Router zur Verfügung stellen” genau diese Vorarbeit, die du ihm abnimmst, weil er es selber beim Getrennt-Mapping nicht kann. Beim Mappen des Gehsteigs an der Fahrbahn muss und kann er diese Arbeit selber leisten.

Stimmt, sorry, du mappst ja auch hohe Bordsteinkanten, wo du ein Ziel vermutest. Ich ziehe die Bemerkung zurück

Ich weiß, für das Routing ist bei deiner Mappingweise diese Diskussion ziemlich akademisch. Praktisch macht es leider kaum jemand so gut wie du. Drum fände ich es halt besser, auf das Getrennt-Mapping bei durchgehender Querungsmöglichkeit zu verzichten. Alles andere kann man damit ja auch abbilden, außer die exakte Geometrie.

Die exakte Geometrie der Straße ist allerdings auch beim Getrennt-Mapping nicht komplett abgebildet. Für die Fahrbahn- und Gehweglinien wird ja nur eine durchgängige Breite angenommen, ist draußen insbesondere im Kreuzungsbereich ja auch nicht so.

edit: Wort zuviel

Leider nicht: Ist der separate Gehweg einmal zwischen Haustüre und Straße eingezogen, dann kann kein Fußrouter mehr den einfach überspringen. Es ist dann nicht mehr möglich, die Unterscheidung zu treffen, die ich angesprochen habe. Diese Tür ist dann zu. So wird aus einem mehr an Information ein weniger an Möglichkeiten.

Wenn man barrierefreies Routing mit dem Autorouter OSRM machen will, dann bleibt freilich keine andere Wahl. Man bedient dann die Bedürfnisse einer kleinen Gruppe innerhalb derer, die barrierefrei geroutet werden wollen, nämlich die, die mit etwas Autoähnlichem unterwegs sind, sogenannte mobility scooter zB. Und ignoriert, dass des einen Barriere dem andren keine.

Getrennt Mapping von straßenbegleitenden Gehwegen wird um so was nicht herumkommen. Es werden Millionen werden. Man kann die alle dann noch sehr detailliert ausstatten: surface, smoothness, etc. Die prefix-Methode finde ich tragbar. Mehrmals wurde schon der Wunsch nach highway=path+path=virtual vorgeschlagen, weil das nämlich gleich rendert. So ist das eben. Eine weitere Möglichkeit wäre highway=virtual+virtual=footway.

Eines davon könnte am “Alten Weg” gleich in die Tat umgesetzt werden OSRM wird nicht aktiv, wenn nicht eine kritische Masse überschritten wird.

Nicht drauf vergessen: ein highway=primary mit Sidewalks links und rechts wird auch nicht so einfach gequert. Es gibt auch lineare Einschränkungen.

Leider beobachte ich das auch so. Der “Alte Weg” ist kein Einzelfall. Warum Luftbildäquivalenz so hoch bewertet wird, das wundert mich dabei am meisten: Unterwegs zeigt mich das GPS meist in irgendeinem Gebäude oder gleich auf der anderen Straßenseite.

Danke JochenB, wenigstens einer hier der versteht

Echte Fußrouter ignorieren diese auch. Die machen Plaza-Routing und anderes Routing über Flächen. Steckt noch ein wenig in den Kinderschuhen, alt genug wäre es zwar, um herausgewachsen zu sein, aber was noch klein ist, kann noch groß werden. Mapperfleiß dagegen regnet es vom Himmel, aber die Erde ist ganz schön riesig.

kann man schon, aber man braucht eine Relation dafür.

Das stimmt, grundsätzlich geht das. Dabei muss erkenntlich sein, welche Wegabschnitte der Gehsteige und der Fahrbahn sich unmittelbar gegenüberliegen, denn nur zwischen denen darf gequert werden.

Wenn Fahrbahnen und Gehsteige jeweils aus mehreren gesplitteten Wegabschnitten bestehen, wird es aber schwer mit der eindeutigen Zuordnung. Dazu müssten m. E. Gehsteige und Fahrbahnen immer an derselben Stelle geteilt werden und für die jeweilig zusammengehörigen Wegabschnitte eine eigene Relation erstellt werden.

Wenn alles in einer Relation zusammengepackt wird wüsste ich nicht, wie man eindeutig erkennen kann, welche Abschnitte/Knoten gegenüber liegen.

Das halte ich für recht kompliziert und fehleranfällig, drum hatte ich das garnicht erst angesprochen.

Danke fürs richtig stellen.

Da trage ich doch dann lieber die Barrieren und Grünstreifen ein und unterlege die einzelnen Wege noch mit area:highway und das ganze mit landuse=highway.

Hallo,
das man eine Straße an die sich direkt über eine Bordsteinkante der Gehweg (Bürgersteig) anschließt, die Straßenlane mit ‚sidewalk=*‘ getaggt wird und baulich getrennte Gehwege als separaten lane getaggt wird, klingt für mich logisch. Für mich stellt sich aber die Frage: Was ist ein „Baulich getrennter Gehweg“? Okay, wenn zwischen Straße und dem Gehweg ein Grünstreifen verläuft, vielleicht sogar mit Bäumen, ist der Gehweg zur Straße baulich getrennt. Wie ist das aber mit Parkplätzen die parallel zur Straße verlaufen? Ich meine diese Parkplätze, wo das Auto noch auf der Straße steht und dann die Bordsteinkante die Straße und den Gehweg trennen. Ist das schon eine räumliche Trennung? Und wie ist das erst recht bei Parkplätzen an Straßenrändern, wo die Parkplätze um 90 Grad gedreht zur Straße bzw. Gehweg angelegt sind? Die Autos stehen ja noch auf der Straße und hinter den Parkplätzen befindet sich die Bordsteinkante zum Gehweg. Vielleicht ist meine Frage auch etwas Spitzfindig. Ich tagge bei 90 Grand gedrehten Parkplätzen den Gehweg dann schon separat weil es in meinen Augen dann doch schon eine Räumliche Trennung vorhanden ist. Der Gehweg verläuft wenigstens 2m entfernt von der Straße. Ich denke auch, dass man dann einfach individuell entscheiden muss.
Wie seht ihr das?
Ciao Holger

Für die Wissenschaftler unter uns, hier https://www.openstreetmap.org/user/Robhubi/diary/394488 ists ausführlich beantwortet. Nicht zuletzt geht es auch um rechtliche Fragen, wer was wie nutzen kann, darf, soll oder gar muss.

Eine Straße besteht also je nach Ausbau aus vielen Spuren: der Fahrbahn mit ihren Fahrspuren (lanes), Parkflächen (parking:lane), Radwege (cycleway), Gehwege (sidewalk), Grünstreifen (verge), Bankett (shoulder). Die Überlagerung von James Ross zeigt ein paar davon. https://osm-tiles.james-ross.co.uk/?layer=standard&layer=roads - Längsparken und Quer wird unterschieden, Abbiegespuren kriegen keine Pfeile. Sidewalk hinter Parking sieht man ab und zu, selten wohl, weil Parken wenig erfasst ist.

Diese Antwort steht in Hungerburgs schöner Zusammenstellung. Wenn die Frage aber ist “Ab wann taggt man einen Bürgersteig als seperate Linie”, wird es keine einhellige Antwort geben, dort gilt

Es gibt viele Mapper, die alle Bürgersteige getrennt mappen, andere Mappen nahezu alles an der Straßen-Linie, beides ist nicht grundlegend falsch. Wo die Schwelle zwischen den Tagging-Schemas ist, ist damit individuell.

Ich für mich sehe die Schwelle zur separaten Linie dort, wo man nicht durchgehend vom Bürgersteig auf die Fahrbahn wechseln kann, ohne über Hindernisse zu gehen, die nicht dafür gedacht sind. Solche Hindernisse sind für mich Grasflächen, Leitplanken, Geländer, Hecken usw., aber nicht Parkspuren, egal ob längs oder quer geparkt wird.

Das heißt aber nicht, dass ich jedesmal wegen z. B. weniger Meter Geländer das Schema gewechselt habe. Das habe ich nach Situation entschieden.

Eine von der Mittellinie entfernte Lage des Bürgersteigs kann man über die Breitenangaben der Fahrbahn bzw. der Fahr- und Parkspuren abbilden, deswegen muss man den Bürgersteig nicht sperat mappen. Allerdings kenne ich keinen Renderer, der das darstellt. Wer seine Arbeit im Renderer sehen will, wird daher eher seperat mappen.

Es ist immer eine Abwägungsfrage, z.B. wenn man sehr detailliert wechselnde Eigenschaften des Gehwegs (Breite, Oberfläche etc.) mappt sollte man m.E. eher die separate Variante anwenden, weil man sonst die komplette Straße in zig Stücke zerhäckseln muss nur weil sich der Gehweg ändert

Ich halte das Erfassen von Sidewalks vor allem für ein Mappen für den Router. Meine Schwelle ist also dort, wo ich mit einer Anweisung wie “Folgen Sie der Soundso-Straße (auf der linken|rechten Seite) 100m.” meine, dass jemandem Ortstremden, möglicherweise mit “besonderen Bedürfnissen” nicht mehr geholfen wäre. Da ist dann ein separater Gehweg nötig, selbst wenn keine bauliche Trennung vorliegt, komplizierte Kreuzungen zB machen da oft viel Arbeit. Andernfalls Attribut; Und, splitten muss man da nicht viel, wenns nur um linke/rechte/beide Seiten geht, das Problem ist fast mehr, die Straße zusammenzuklauben, die von Tempolimits, Abbiegebeschränkungen, Bus- u.a. Routen usw. eh schon über Gebühr zersplittet sind.

Die Querbarkeit der Straße als Alleinkriterium heißt, sie zu überbewerten: Die die es sehen gehen/rollen drum herum, was kein Problem ist, wenn da nicht ein Umweg von hundert Metern draus wird, oder queren auch das, den Grünstreifen, die Bodendecker, das geparkte Auto, die Reling, usw; andere verwenden hoffentlich Router, die, was ich als bevormundend für mich empfinden würde, aber ich bin eben nicht allein auf der Welt, die also von vornherein die Route so legen, dass vorhandene, gemappte Übergänge bevorzugt werden, für Mobility Scooter sogar ein Muss. Was einen wichtigen Punkt beim Sidewalk Mapping berührt: Übergänge!