Hallo,
ich beobachte immer wieder, dass von diversen Routern stets zur Straße navigiert wird, welche dem Punkt am nächsten liegt.
Nun frage ich mich, ob es Router gibt, welche zum Eingang navigieren, oder welche die korrekte Gebäude-Seite verwenden.
Das Problem tritt auch auf, wenn der Fußweg von der Straße bis zum Punkt eingetragen ist. Zumindest das, sollte ein Router doch als solches erkennen.
Bei Here WeGo und Waze z.B. ist es so gelöst, dass der Zugang/Eingang separat definiert wird.
1 Like
Was du willst ist ein “intermodaler” Router. D.h. du willst mit dem Auto auf den nächstgelegenen Punkt auf der Straße. Und dann zu Fuß weiter zum Haus (Wenn es denn einen zuweg zum Haus gibt der ein footway ist)
Und dazwischen steht irgendwo noch der Geocoder.
Typischerweise gibt dir der Geocoder ja die Adresse - oder besser - wenn die Adresse auf dem Gebäudeoutline ist, das Gebäudeoutline und das Geometrische Zentrum dieses Outlines.
Die Navigation sucht dann von diesem Punkt aus den nächstgelegenen Punkt auf einem Wegenetz das für die angegebene Modalität nutzbar ist. Also wenn du Autonavigation machst sucht der einen Punkt auf dem für Autos Nutzbarem Wegenetz (Das ist dann nicht der Fußweg).
Dahin wirst du geleitet.
Das können die ganzen Router auf der Hauptseite - da wird strikt nach der Modalität unterschieden.
Wenn du intermodalität willst gäbe es halt mehrere herangehensweisen. Du könntest angeben welche du kannst und der Router sagt dir jeweils an welchem Punkt du die Modalität wechseln musst - Also Auto → Fahrrad → zu Fuß (Oder Zug oder Fähre, oder Flugzeug).
Wenn ich mich richtig entsinne müsste BRouter intermodalität können. Aber da hab ich keine Ahnung.
Nein - denn die router auf der seite von OSM trennen strikt ihren Graphen nach für ihre modalität zulässige Wege. Und ein Auto darf nicht auf Fußwege also fallen die Fußwege bei OSRM aus dem Graphen komplett raus. Der kennt die dann nichtmal mehr.
Flo
2 Likes
Das Problem tritt auch bei reiner Fußgängernavigation aus. Das Problem ist, dass die Adresssuche (der Geocoder) nicht die Koordinaten des Eingangs sondern meist des Gebäudemittelpunktes zurückgibt.
2 Likes
Das ist aber ein Datenproblem was wir lösen könnten - wenn wir denn den Eingang taggen und ggfs da die informationen drauf packen nach denen gesucht werden würde.
Ich habe da ja hier im Forum und auch auf den Mailingliste immer wieder dafür Votiert POIs nicht als Flächen einzutragen - Aber da gibts keine Mehrheit für.
Flo
Auch POI-Punkte im Gebäude führen einem nicht zum richtigen Eingang. Probiere es aus!
Klar ist das ein Problem der Modellierung.
Es müsste schon der Eingang zurückgegeben werden oder Wege direkt bis zum Zielpunkt existieren. Jetzt kann man sich überlegen wie man durch Vorprozessierung die Adresse vom Gebäude an den richtigen Eingang bekommt … oder was man redundant an Knoten erfassen sollte.
Du kannst dann aber den Punkt dahin legen wo du hin willst - also z.b. auf den Eingang 
Typischerweise willst du ja auch gar nicht zum Eingang geroutet werden - sondern zum Wegestück das dem Eingang am nächsten ist. Ersteres würde ja bedeuten das man den Weg auch am Eingang anschliesst.
Defakto arbeiten alle diese Algorithmen um die unzulänglichkeit der OSM Daten drumherum.
Und das ganze bringe ich ja repetetiv seit 10 Jahren vor das wir eigentlich zusätzlich noch eine “navaid” relation brauchen die den Router hinten kann wo ich hin möchte wenn ich zu Objekt A möchte. Aber auch da gibts keine Mehrheit für.
Für einfache Wohngebäude ist das alles ja unproblematisch. Da ist der Fußweg zum Eingang auch dem Centroid des Outlines der Nächstgelegene Weg.
Es gibt 1-2% der Gebäude wo die nächstgelegene Straße nicht die Zufahrt des Gebäudes ist und Tonnen an anderen Problemen wo sich das Algorithmisch durch raten nicht lösen lässt. Dafür haben wir einfach keine Lösung. Das ist und bleibt halt kaputt.
Flo
1 Like
Solange der Eingang auf dem Weg des POIs liegt, ergibt sich doch alleine schon dadurch, wie man den POI betreten kann. Ob dieser POI nun ein Gebäude oder ein Geschäft ist, wäre dafür ja unerheblich. Die ganzen POI-Infos aber an den Eingang packen wird bei mehreren Ein/Ausgängen nicht funktionieren.
3 Likes
Bei großen gebäuden mit vielen Zielen kommst halt sowas bei raus (in dem Fall 3 Router - 3 Lösungen)
OpenStreetMap
WER macht das Vorprozessieren? Nominatim? Frag mal Sarah
Sie wird das garantiert nicht machen - Nominatim wird dir das Objekt zurück geben das der Suche matched. Alles was du dann machen willst musst du selber machen.
Der Router kann nur eines - Zu einer “Exakten koordinate” navigieren.
D.h. du brauchst einen Prozess der nachdem Nominatim der OSM Objekt zurück gegeben hat du das weiterprozessierst und die weiteren informationen hinzufügt. Und das wird eine RICHTIG harte nummer mit Entscheidungsbäumen die Wände füllen.
- Was ist wenn kein Eingang da ist?
- Was ist wenn 10 Stück da sind?
- Was ist wenn nur “Emergency Exits” getagged sind?
- Was ist wenn nur ein Eingang da ist der aber access tags hat die die nutzung verbieten? (access=no motor_vehicle=yes du aber modalität foot hast)
- Was ist wenn der Eingang gar nicht erreichbar ist weil hinter einem Zaun? (Was du nicht feststellen kannst weil du ja keine routing funktionalität hast sondern nur OSM Daten prozessierst)
Und das alles musst du Lösen OHNE Userinteraktion weil du ja nur die kleine Middelware bist.
Halte ich für Ausgeschlossen das da was besseres raus kommt. Da kommen halt andere Fehler bei raus.
Komplexe Zielwahlentscheidungen wie das Thema
- mehrere Eingänge
- Eingänge für unterschiedliche Modalitäten
brauchen Userinteraktion - Wo bringst du die unter?
Und das ist nur das Thema Eingang - Sowas wie “Rezeption eines Campingplatzes” - “Parkplatz des Abflugterminals 2 in Frankfurt” ist damit noch lange nicht gelöst.
Flo
1 Like
Ich weiss das - Ich werte sowas seit 10 Jahren strukturell aus - Das ist das Thema bei modalität “car” wenn das Ziel in einer Fußgängerzone liegt. Fähnchen wo die Adresse liegt die dir Nominatim geben würde. Die linie zeigt auf den nächstgelegenen Punkt auf dem Straßennetz. Und wie man hier sieht sind in den Daten noch tonnen an Fehler. Die ganzen service im Norden haben keine access tags Die sind auch nicht erreichbar - aber naja.
Hier kann man das interaktiv sich ansehen:
https://osm.zz.de/dbview/?db=addresses-nrw&layer=routeable#51.22392,6.77585,17z
wir reden hier aber gerade garnicht über multimodal
Es hakt auch schon bei reiner Fußgängernavi, weil logischerweise eben nicht Wege bis direkt zum Zielpunkt vorhanden sind und der Router sich halt einen Punkt in der Nähe vom Ziel suchen muss, den er erreichen kann. Die Frage ist also, wie findet man einen besseren Punkt (Eingang) als einfach nur den nächsten im Graph.
Ob man das jetzt wirklich lösen muss ist mir vollkommen egal, ich wollte nur aufzeigen, was der Fragesteller gemeint haben könnte.
Nominatim hat mit Navigation nicht unbedingt etwas zu tun. Mag sein, dass ein paar Router das intern als Geocoder nutzen, aber die große mehrheit vermutlich nicht.
Ja gar nicht. Bei mehreren Möglichkeiten muss ein Router immer fragen, oder eben einen Best-Guess machen. Aber sobald ein POI einen oder mehrere Eingänge hat, sollte ein Router einen auch versuchen dorthin zu führen, denn es ist ja anzunehmen, dass man nirgendwo sonst dorthin kommt.
Wie genau ein Router das erreichen möchte, sei ihm mal selbst überlassen. Ich kenne allerdings schon einige, die einem zunächst anbieten, zu einem Parkplatz in der Nähe zu navigieren und ab dann eben zu Fuß weiter zum Ziel. Die wenigsten POI-Eingänge sind ja mit dem Auto befahrbar. Für die Feuerwehr sollte ein Router hingegen nicht so routen.
Natürlich ist die Situation momentan suboptimal, aber „[…] den Eingang taggen und ggfs da die informationen drauf packen nach denen gesucht werden würde“ halte ich nicht für die Lösung, weil es das Problem mehrerer Eingänge auch nicht löst. Dafür gibt’s einfach keine sinnvolle Lösung bei der man den Nutzer nicht fragt, es seidenn wir haben zufällig einen entrance=main
3 Likes
das ist die Stelle, wo man es anders machen müsste, wenn man die Adresse auf einem Gebäudeumriss hat könnte man erstmal nachsehen, ob es auf dem Gebäudeway einen Haupteingang oder andere Eingänge gibt, und dahin routen anstatt ins Zentrum. Wenn man die Adresse auf einem Eingang hat ist es klar (außer man hat auf unterschiedlichen Eingängen diesselbe Adresse), und wenn die Adresse ein Node ist könnte man Gebäude und Eingänge in der Nähe suchen bzw. halt direkt an diese Stelle routen (sofern es die Adr. nicht mehrfach gibt). Bei einer Adresse auf dem Grundstück (z.B. Umriss POI) zu den Toren bzw. barrier=entrance. Erst wenn das alles fehlschlägt würde man zu einem berechneten Punkt in der Fläche routen.
2 Likes
+1, und wäre auch topologisch falsch, weil die POIs im Inneren des Gebäudes liegen und nicht halb drinnen halb draußen wie ein Eingang.
- Geocoder → Nimmt deine Texteingabe und returned ein oder mehrere OSM Objekte ggfs mit einer Score.
- Router → Lenkt dich über für deine Modalität zulässige wege zu dem der Geokoordinate nächstgelegenen Punkt auf diesem Wegenetz.
Der Router trifft keine entscheidung über
- Welchen Punkt
- Ob der Punkt für diese Modalität möglich ist
- Ob vielleicht zu dem OSM Objekt ein Eingangsnode existiert
Das ist für den router alles nicht “in scope”. Der Router muss eine fertige Entscheidung über “Was soll angesteuert werden” übergeben bekommen.
Im moment gibt es da keine Middleware oder Mediationslayer. Im moment ist das “Erstes Nominatim Objekt direkt an den Router übergeben” und das geht eben für komplexere Zielwahlentscheidungen kaputt.
Und Sarah wird dir einen Husten wenn du das in den Nominatim haben willst denn das ist völlig out-of-scope wenn du ein Objekt zurück bekommen möchtest was eigentlich mit dem in der Suche gefundenen nur so mittelbar zusammenhängt, und vor allem noch von deiner Modalität abhängt.
Genauso ist “Userinteraktion” in der routing engine komplett out-of-scope. Da wirfst du eine A und B Koordinate rein und bekommst ein Linestring ggfs mit Routing instructions zurück.
Du willst da eben ein neues Modul in der ganzen Navigation einbauen für die Zielwahlentscheidung, und ich sehe nicht wie das in den Router oder in die Geokodierung passt. Das muss einzeln in die Mitte - und das leider für jede Navigationslösung, ob nun webseite, OSMAnd oder sonstwas neu.
Der “best guess” geht halt in jedem fall kaputt - je nach Lösung halt unterschiedlich. Sehen wir ja jetzt - Aktuell ist das halt ein typus “Best guess” - Der hat halt in diversen Threads von mir dargelegte Mängel.
Und ich bin in Gedanken ja schon weiter. Eigentlich will ich nicht das für komplexe Ziele wie “Flughäfen” “Campingplätze” oder so geraten wird.
Ich möchte eine möglichkeit in abhängigkeit von Modalität explizit definieren können welcher exakte Punkt angefahren wird. Oder eben auch eine Liste.
Ich will ja in der Geokodierung nicht nach “Frankfurt Parkplatz P2 Abflug Terminal 2” suchen - Sondern ich will nach “Flughafen Frankfurt” suchen und dann will ich eine Liste der möglichen “Subziele” haben.
Aber es zerfasert halt hier jetzt auch die Diskussion. Das Thema ist für das Forum einfach zu komplex.
Flo
Wenn Du es so strikt trennen willst, dann ja. Aber ich meinte mit „der Router“ die ganze Software, also z.B. etwas wie Magic Earth, oder das vom TO angesprochene Here WeGo/Waze Zugegeben, das ist ein Navi, weswegen meine Formulierung missverständlich ist, aber as ist ja genau das, was gefragt wurde.
Also noch mal: ein Navi muss Dich im Zweifel fragen, wohin Du möchtest. Wenn ich „Flughafen Frankfurt“ eingebe, wäre es natürlich schön, wenn ich gefragt würde, ob ich Terminal 1 Abflug, oder Terminal 2 Ankunft möchte, oder vielleicht einen Parkplatz dort. Diese Aufgabe erledigt das Navi dann mithilfe eines Geocoders, in dem dieser den eingegebenen Suchtext in Koordinaten/OSM-Objekte überführt.
Nominatim ist allerdings nur ein Geocoder für OSM und ganz sicher keiner, auf dem man ein Navi aufsetzen würde, weswegen ich den vergleich immer anstrengend finde. Das erste, was ein Navi braucht, ist ja ein guter Geocoder und der kommt ohne Vorprozessieren nicht aus.
Genau. Und deswegen lassen wir’s hier mal dabei bewenden 
1 Like
Was Thomas möchte, lässt sich nicht mit getrenntem Geocoding/Routing lösen, so wie es die drei Router auf der osm-Seite machen.
Man müsste letztendlich einen Punkt im Routing-Graph suchen. Der Graph unterscheidet sich je nach Reisemodus (und nach Router). Ich kann also nicht einfach einen Standardgeocoder hernehmen. Der Geocoder muss auch den Graphen kennen und die Eingänge/Einfahrten.
Und selbst bei Kfz-Routing wäre am Ende ggf. auch der Fußweg relevant, der mich zum Eingang führt.
Naja - Das ist der Status Quo auf der Webseite - Du kannst wenn du eine Route berechnen willst drauf klicken und dann kannst du manuell einen Punkt suchen, oder du kannst eine Geocoding Anfrage bei Nominatim machen der dir einen Punkt zurückliefert. Eine Eingriffsmöglichkeit hast du auch nicht.
Und das lässt sich Algorithmisch auch genau so beschreiben. Der Router löst einen Dijkstra oder A* Graphen - Mehr macht der nicht. Der reichert dann den “Shortest Path” bzw “Lowest cost path” mit informationen wie Abbiegeinstruktionen an. Aber das ist eben der Algorithmus.
Das gesamte würde ich “Navigationslösung” nennen. Der Router ist der Algorithmus der eine route berechnet. Der geocoder ist ein System das aus einer Volltext anfrage einen Punkt (Oder Objekt) findet.
Nominatim macht enorm viel vorprozessieren um zusammenhänge zwischen Postleitzahlen und benannten Objekten herzustellen, oder Straßen in Orten, oder Hausnummern an Straßen. Viel mit “Geometrischer nähe” und Gewichtung. Um zu wissen ob du Washington USA oder Washington GB meinst nutzt der eine Graph Score der Wikipedia etc.
D.h. da findet sehr sehr viel vorprozessieren statt damit du ein Ergebnis bekommst das du höchstwahrscheinlich meinst. Aber eben - Das ist eine Suche die um Geographische Eigenschaften für die Gewichtung ergänzt ist - Nicht mehr und nicht weniger.
Was du brauchst ist noch viel mehr. Du brauchst einen Nominatim - und dann eine Middleware die dir aus - “Ich hab hier den Flughafen Frankfurt” dann ein “Lieber User - Meintest du Terminal 1 oder Terminal 2?” macht, und das in abhängigkeit von viel mehr informationen als vielleicht dein Standort und einer Volltextsuche.
Oder eben im Einfachsten Fall - Du suchst nach einer Adresse und bekommst ein Gebäudeoutline zurück. Jetzt möchtest du das erweitern und präzisieren in dem du
- Auf dem Gebäudeoutline suchst ob es ein oder mehrere Nodes mit “entrance=*” gibt
- Ob diese entrances= mit access tags belegt sind
- Diese access tags mit deiner Modalität abgleichen (Man will ja nicht zu Fuß in die Tiefgarage geschickt werden, mit dem Auto aber schon)
Etc etc etc - Je nach Objekt typ sind das dann riesige Entscheidungsbäume mit Rückfragen an den User was er denn wohl möchte.
Flo
2 Likes
This is not going to happen.
Ich kenne keine Lösung in der so ist. Auch nicht in den kommerziellen Lösungen. Es wird gesucht, es kommt ein Punkt zurück, es wird der nächstgelegene Punkt auf dem Graphen deiner Modalität gesucht, es wird auf diesem Graphen zu diesem Punkt navigiert.
Vor allem - Für JEDES OSM Objekt ist die entscheidung was denn wohl der anzufahrende Punkt etwas anderes. Und viele Objekte sind ja gar nicht im Graphen. Der Campingplatz selber ist ja gar nicht Routingfähig - der ist nur im Geocoder. Also kannst du viel in den Graphen gucken - da ist der Campingplatz nicht drin. Und schon gar nicht die Rezeption. Das wäre ja ein Gebäude und Gebäude sind ja auch nicht routingfähig. Der Graph enthält aber nur wege die auch für diese Modalität Nutzbar sind.
Was es gibt ist das Ziele erweitert sind. In den Harman-Becker Navis der alten Mercedes G/S/E Klassen gibt es die option das es eine Rückfrage gibt mit “Meinten sie” und dann klappt ein Menu auf. Das gibt es für wenige spezielle Ziele.
Und genau DIESE Möglichkeit will ich auch in OSM - Ich will ein explizites Hinting so das ich für Ziel A und Modalität “Fahrrad” einen expliziten Node setzen kann der dann angefahren wird. Mehr bedarf es gar nicht.
Rumraten oder “das muss der Router Lösen” verschiebt nur den Fehler und das Problem woanders hin. Frei nach RFC1925
(6) It is easier to move a problem around (for example, by moving
the problem to a different part of the overall network
architecture) than it is to solve it.
Flo
Und ich bin in Gedanken ja schon weiter. Eigentlich will ich nicht das für komplexe Ziele wie “Flughäfen” “Campingplätze” oder so geraten wird.
Ich möchte eine möglichkeit in abhängigkeit von Modalität explizit definieren können welcher exakte Punkt angefahren wird. Oder eben auch eine Liste.
Ich will ja in der Geokodierung nicht nach “Frankfurt Parkplatz P2 Abflug Terminal 2” suchen - Sondern ich will nach “Flughafen Frankfurt” suchen und dann will ich eine Liste der möglichen “Subziele” haben.
genau, Flughäfen sind ein Anwendungsfall, im Prinzip aber jeder Ort der mehrere Eingänge hat, und es wird es natürlich noch komplizierter wenn du auch noch Parken willst oder mit Öffentlichen fahren.
Ich würde in OpenStreetMap aber nur das eintragen wollen was man nicht aus anderen Daten bereits hat