Edit: Der folgende Text ist für Navigation und Routing in DE irrelevant, der beschriebene Algorithmus ist lediglich auf dem NA-Routingserver implementiert!
[color=#999999]Durch die Antwort zu einer Diskussion im internationalen WME-Forum bin ich auf ein Thema gestoßen, dass im deutschen Wiki bisher überhaupt nicht zur Sprache kommt, den Unterschied zwischen Fußweg (Walking Trail) und Fußgängerzone (Pedestrian Boardwalk).
Auch, wenn beide Segmenttypen nicht befahrbar sind, gibt es Unterschiede im Zusammenhang mit der Navigation - ein Fußweg wird beim Routing berücksichtigt, eine Fußgängerzone dagegen nicht.
Beispiel:
Bei einer Navigation zum POI 1 endet die Route bei Ziel 1 auf der C-Straße.
Bei einer Navigation zum POI 2 endet die Route bei Ziel 2 auf der B-Straße.[/color]
[color=#999999]Beim POI 1 wird als nächstliegendes routbares Segment die C-Straße erkannt und deshalb so nah wie möglich direkt an den POI navigiert, was fast immer dem gewünschten Ergebnis entspricht.
Beim POI 2 dagegen ist das nächstliegende routbare Segment der Fußweg, da dieser aber nicht befahrbar ist, endet die Navigation an der Stelle, die dem routbaren Fußweg am nächsten liegt, das ist in diesem Fall die B-Straße. Dies ist kein Fehler, sondern im Routingalgorithmus so vorgesehen, auch wenn es auf den ersten Blick unverständlich scheinen mag!
Wenn also ein nur Fußgängern vorbehaltener Weg schon Eingang in die Karte finden muss (die Gründe bitte im Wiki nachschlagen!), sollte dieser in den allermeisten Fällen als Fußgängerzone eingetragen werden, um Probleme beim Routing zu vermeiden!
Leider ist die ähnliche Benennung “Fußweg” und “Fußgängerzone” in der deutschen Version des WME nicht sehr eindeutig, eine Unterscheidung “Wanderweg” und “Fußweg/Fußgängerzone” wäre selbsterklärender.[/color]
Variante 1 (POI an Fußgängerzone, Navigation zum nächstliegenden befahrbaren Segment) funktioniert definitiv so, wie beschrieben.
Variante 2 habe ich nicht direkt mit dieser Zielstellung getestet, aber sie erklärt mir im Nachhinein einen mehrere Monate zurückliegenden UR mit merkwürdigem Routing zu einem Pferdehof/Reitstall, bei dem Waze (war in der App und der Live Map wiederholbar) zu einem weiter entfernt liegenden Straßensegment navigierte. Dort fehlten insgesamt mehrere Straßen, dafür gab es einen “Walking Trail”, der direkt am betroffenen Gelände vorbeiführte.
Ansonsten spricht zumindest das niederländische Wiki auch von einem Unterschied, danach kann der Walking Trail zur Destination (Endpunkt der Navigation) werden, der Pedestrian Boardwalk aber nicht. Ich könnte mir darum vorstellen, dass dieses Verhalten nicht nur auf den NA Server beschränkt ist.
Ich werde Variante 2 aber in den nächsten Tagen noch einmal explizit im Vergleich mit Variante 1 testen!
Danke für die Erläuterung.
Mich wundert nur beim Beispiel im OP, dass beim Fußweg (rechts) der Weg berücksichtigt wird, obwohl er nicht angehängt ist, also eigentlich gar keine verbundene Segmente bis zum Ziel existieren (wobei Anhängen natürlich falsch wäre und vermutlich zu einem Routing bis direkt zum POI 2 führen würde, weil ja über alles geroutet wird, nur halt mit entsprechendem Penalty).
So wurde es zumindest im erwähnten Thread erklärt, im US-Wiki wird es ausführlicher beschrieben und im Benelux-Wiki kurz erwähnt. Detlev meinte ja, das wäre wohl nur auf dem NA-Server so, weswegen ich das ja auch direkt testen will, nur sind die dafür vorgenommenen Edits noch nicht live.
Sinnvoll wäre es auf jeden Fall, man stelle sich folgendes Szenario vor: eine Autobahn und direkt daneben ein Aussichtsturm, zu dem man aber nur über einen Fußweg/Walking Trail von einem Parkplatz gelangt, der an einer anderen Straße liegt, aber weiter weg vom Ziel ist. Ohne diese Unterscheidung von Fußweg (Walking Trail) und Fußgängerzone (Pedestrian Boardwalk) würde man ja immer die Autobahn als Ziel bekommen.
Was mir gerade zu den Testszenarien noch einfällt: Places deren Navigationspunkt nicht exakt auf der Straße liegt, können das Verhalten des Routingservers eigenständig beeinflussen. Besser wäre es, auf den Segmenten eine Hausnummer zu vergeben und die Tests dorthin routen zu lassen.
Für Betatester ist noch wichtig, dass bei Versuchen in der App auch der Routing-Betaserver das Verhalten ändern kann, den sollte man für allgemeingültige Resultate ausschalten oder gleich die Livemap nehmen.
was mich von Beginn an am Post gestört hat: kann man mit nicht angeschlossenen Segmenten ein Routing prüfen/testen? Und wenn man ein Ergebnis bekommt, wie soll man das bewerten?
Meiner Meinung nach ist Fußweg oder Fußgängerzone erstmal gleich. Habe einen weiteren Test gemacht mit exakt gleichen Segmenten (Abstand/Länge etc.), einen als Fußweg und eine Fußgängerzone. Daneben spiegelgleich eine befahrbare Straße, am Ende der Fußwege je einen Poi Test 1 und Test 2. Das Routing dahin ist in beiden Fällen exakt das gleiche, es gibt keinen signifikanten Unterschied zwischen Fußweg und Fußgängerzone, außer in der Darstellung: die Fußgängerzone ist im Client breiter, der Fußweg ein schmaler Strich. Ich vermute das unterschiedliches Routing mit anderen Dingen zusammen hängt, wie Start/Ziel/Entfernung, was auch immer.
kann ich nicht bestätigen. Am Beispiel Fußweg routet Waze dich da nur wenn du schon drin bist. Da aber die Segmente nicht angeschlossen sind wird dir wohl nur “begebe dich zur Route” (oder so ähnlich) angezeigt. Auch das hohe Penalty verleitet Waze nicht zum rein- oder durchrouten. Ich meine bei angeschlossenem Fußweg/Zone kommt sogar ein “bitte wenden” wenn du darauf zufährst.
Zur Historie: vor 1,5/2 Jahren hat Waze das routen in Fußwegen/-zonen unterbunden. Vorher ging das, war den Herren aber nicht klar irgendwie. Erst nachdem mit Nachdruck darüber gemeckert wurde wars auf einmal weg. Von heute auf morgen abgeschaltet
Ebenfalls gab es eine Aussage das die Fußgängerzone als Kategorie verschwinden sollte, oder war es der Fußweg? Jedenfalls sollte das zusammen gelegt werden. Ist aber bis heute bekannter maßen nicht passiert, aber für mich klarer Hinweis: kein Unterschied bzw. egal.
Waze routet zum nächstmöglichen Segment, zur Not halt Autobahn. Kennen wir von falschen Hausnummern aus Google. Da endet die Navigation auf der AB statt der Straße darunter/daneben. Insofern kommt es auf die Positionierung des Poi an bzw. des Navigationspunktes an. Ein Fußweg dahin nützt halt nix, nicht angeschlossen, nicht routbar.
Die zu klärende Frage hier ist die, ob dieses Verhalten auch für den INTL-Server beziehungsweise Deutschland gilt oder nur, wie Detlev sagt, für den NA-Server. Im DACH-Wiki findet sich dazu kein Hinweis, ein Unterschied wird aber im Benelux-Wiki erwähnt, was die Möglichkeit andeutet, dass auch in Deutschland beide Typen von non-drivable Segmenten unterschiedlich behandelt wird:
deine erste Seite ist eine explizite USA-Seite. Für den NA-Server gibt es mindestens seit letztem Jahr ein offiziell geändertes Routingverhalten bezüglich der beiden Segmenttypen.
Wie die Benelux-Seite hierzu zustande kam, kann ich nicht sagen. Mir wäre es - bevor wir hier etwas tun - wichtig, saubere Testergebnisse zu haben - mit Zielen die AUF der Straße liegen, idealerweise mit Hausnummern. Das Verhalten bei Places die neben der Straße liegen ist wie oben schon geschildert wieder ein eigenes Kapitel. Und wie gesagt auch mit dem produktiven Routingserver, nicht mit der Infrastruktur für Betatester.
Wenn es da einen Unterschied zwischen den beiden Typen gibt, wäre das ein Aufhänger um noch mal explizit beim Staff nachzufragen, ob sie das Verhalten des INTL-Routingservers angeglichen haben.
Ob die Benelux-Seite auf Basis von Reverse-engineering, Staffaussagen oder durch Übersetzung vom US-Wiki zustandegekommen ist, lässt sich nicht leicht ermitteln. In jedem Falle führt nur der Weg über Testszenarien und Staffanfrage zu gesicherten Erkenntnissen.
Okay, nach dem Update des INTL-Servers habe ich das heute abend mal testen können.
Ergenbis: der nicht verbundene Fußweg, der näher am POI (Punkt-POI) liegt als das nächstgelegene normal befahrbare Segment wird NICHT als Ziel dargestellt, er verhält sich damit ebenso wie eine Fußgängerzone.
Detlev hat also recht mit seiner Aussage, dass ein derartiges Verhalten nicht Teil des Routingalgorithmus auf dem INTL-Server ist.
Solche Tests, bzw. Reverse Engineering haben die Community groß gemacht. Kein Problem sie auch in der heutigen Zeit bei Bedarf einzusetzen. Jede falsche Theorie ist so lange richtig bis jemand das Gegenteil beweist oder eine bessere falsche Theorie aufstellt.
Deshalb vielen Dank dass Du den aktuellen Fall thematisert hast.
Es wäre nicht das erste Mal, dass staff etwas ändert und die Info irgendwie nicht in der Community ankommt. Dann lässt sich das nur durch Testen und Nachfragen aufklären. Also: Danke für die wertvolle Arbeit die hier reingeflossen ist!
ich hab das jetzt nochmal weiter verfolgt und einen weiteren Test gemacht, den ich unter realen, also fahrbaren Bedingungen testen konnte, dafür alle möglichen Straßen abgeklemmt, weil da sonst zwingend ein “reinfahren und wenden” kommt:
egal ob ich von der Seite mit Fußweg oder der Seite mit Fußgängerzone angefahren komme, in beiden Fällen wird bis zum Ende der Straße geroutet, am Beginn des Fuß… ist das Ende der Navigation.
Dann bin ich mit einem anderen Ziel sowohl auf den Fußweg als auch auf die Fußgängerzone zugefahren. In beiden Fällen wird ein wenden angezeigt und angesagt (obwohl der uturn NICHT gesetzt ist).
Auch bin ich mit dem anderen Ziel in die Fußwege rein, der normale Positionspfeil bleibt am Ende der befahrbaren Straße “hängen”, schön zu sehen hier der gelbe Pfeil mit der tatsächlichen Position. Es kommt auf dem Fußweg ein “begeben Sie sich zur Route” (oder so) und erst fast am Ende des nicht befahrbaren Bereiches “springt” die Navigation um und es geht normal weiter.
Ich sehe auch bei diesem Test kein unterschiedliches Verhalten, beide Kategorien sind identisch, außer der unterschiedlichen Darstellung im Client (dickerer Strich bei Fußgängerzone).
Das Verhalten beim Erreichen von “non-drivable” Segmenten habe ich in der Vergangenheit auch mehrfach getestet, nachdem ich einmal eher zufällig darauf stieß. Die Anweisung zum Wenden erfolgt wohl unabhängig davon, welcher Art das Folgesegment ist, so lange es nicht geroutet werden kann. Das gilt auch für unbefestigte Wege (so diese in den App-Einstellungen unterbunden sind) oder Privatstraßen, wenn das Ziel nicht in einer liegt. Der Übergang zu so einem Segment wird dadurch routingtechnisch eher wie eine Endkreuzung betrachtet und löst beim Daraufzufahren die Wendeanweisung aus.
Deine Testergebnisse decken sich somit mit meinen und der Aussage von Detlev. Ich denke, das Thema können wir damit erst einmal als abgeschlossen betrachten?
Wenn du zb auf eine Privatstraße zufährst routet es dich rein/durch. Ich nehme an bei Feldwegen auch, beide gelten als befahrbar. Aber hat ja nichts mit Fußweg zu tun
Der Übergang von Straße zu Feldweg ist eine Penalty von 1h. Künftig wird sich wegen des neuen Attributes “Unpaved” das auch mit normalen Straßen kombinierbar ist noch was ändern, das ist aber noch nicht raus.
