Aber dieses Nebulöse “das muss der Router halt Lösen” ist ja genau das Problem.
Wie?
Ich habe hier ja diverse Beispiele gezeigt und es gibt keinen Automatismus der alle die Dinger löst. Es bleibt bei jedem Automatismus ein Bodensatz an dingen die er nicht Lösen kann, wie kriegen wir die zur “Userzufriedenheit” geregelt?
Flo
ein Objekt ohne Eingang das gleichzeitig kompliziert ist, das möchte ich sehen 
angenommen, man will zu einem Badesee, da könnte z.B. ein Weg oberhalb einer Abbruchkante über dem See verlaufen, aber ohne dass man hinkommt, und ein anderer an einer Wiese über die man an den See kommt, verbunden sein. In solchen Fällen wäre es am Besten, der Router würde einem den Zielbereich anzeigen und man könnte vorgeben, wo man hinwill. Im Endeffekt muss man sich ja sowieso das Ziel immer ansehen, weil man sonst riskiert, dass man sonstwohin geschickt wird.
die einzigen in unserem Umfeld die mir spontan einfallen, wo Bewegungsdaten in großem Maß anfallen, sind Mapbox und evtl. maps.me. Mit Bewegungsdaten wird es aber auch kompliziert, und die Suchanfragen wären sicherlich zusätzlich hilfreich. Wenn mehrere Publikumsmagneten in der Nähe liegen gibt es vermutlich noch selbstsame Wechselwirkungen. Selbst wenn man das alles hätte, dann wäre es trotzdem nur “raten” mit Hilfsmitteln. Gut gemacht würde es bestimmt in der Regel super funktionieren, aber eigentlich wollen wir doch versuchen die Daten so gut zu machen, dass es direkt oder indirekt mit hoher Wahrscheinlichkeit ablesbar ist.
Auf Routerseite könnte man z.B. je nach Typ unterschiedliche Heuristiken anwenden. Bei einem Flughafen will man normalerweise ans Terminal. Genauer gesagt interessiert meist auch, ob man zum Abflug oder zur Ankunft will (und klar, es gibt noch mehr Parameter, wenn man sowieso für Flughäfen eine Extrawurst brät könnte man z.B. auch fragen: Langzeitparken oder Kurzparken/Halten, etc.). Niemand will an den Zaun neben dem Rollfeld, oder nur die, die das auch ohne Router finden 
D.h. der Router müsste bei einem Flughafen eigentlich fragen: Ankunft oder Abflug, ggf. auch das Terminal (oder idealerweise eigentlich die Flugnummer, dann findet er den Rest allein, aber das wäre wohl Wunschkonzert) und einen dann zum Zugang dieses Terminals bringen. Oder er würde die Terminals die er dort kennt als Auswahl anbieten.
Wo es einen expliziten Übergang gibt, erwartet man einen der tags barrier=gate, barrier=_gate ,barrier=entrance, entrance=
Eigentlich will man immer zum Eingang oder Zugang wenn es einen gibt, wenigstens diese Fälle könnte man lösen.
Problem bei komplexen POIs ist oft, dass es einen Perimeter für den ganzen POI gibt, das sinnvolle Ziel aber Punkte auf Gebäuden oder Gebieten innerhalb des POIs sind, z.B. Ticketoffice, Supermarkteingang für die Kunden (und nicht der Personaleingang, Notausgang oder Warenanlieferung), Terminal bei Flughäfen, Eingang nahe des Gleises wo man hinwill bei Bahnhöfen, …
Bei komplexen POIs ist das Problem öfters, dass es drauf ankommt was man dort vorhat, bzw. wo genau man innerhalb des POIs hinwill, um festzustellen wo man sinnvollerweise hinroutet. In solchen Fällen sollte der Router am besten noch mal mehr oder weniger ausgefeilt nachfragen. Bei mehreren POIs hilft dann auch “navaid” nur insofern, als es beitragen könnte, die Rückfrage besser zu machen.
solche Probleme wie Fluss dazwischen könnte man dadurch verbessern, dass man im Anschluss an das Fahrzeugrouting von dem Endpunkt noch ein Fußgängerrouting zum angefragten POI macht. An dessen Länge könnte man ggf. erkennen, ob was nicht hinhaut. Geht natürlich nur, wenn man die Fußwege entsprechend gemappt hat.
Puh - ich habe das Gefühl wir fangen in diesem Thread wieder oben an. Ein Fußweg hilft dir bei car routing NULL. Er ist eher irreführend und produziert andere Fehler (Siehe meine Zeichnung weiter oben). Es ist einfach nur das verschieben des Problems woanders hin. Es löst es aber nicht.
Flo
ich kann Dir nicht folgen. Du willst ja beim Carrouting wenn ich das richtig verstanden habe nicht nächstmöglich ans Haus, sondern den nächstgelegenen Parkplatz finden. Weil das nicht immer so ist, wird man irgendwo nochmal nachfragen müssen, was Du willst, bzw. wirst Du es per Voreinstellung mitteilen müssen, oder es ergibt sich vielleicht aus der Analyse der Daten, die bereits von dem Nutzer gesammelt wurden, was er vermutlich meint…
So eindimensional ist das nicht. Ja - Normalerweise möchte ich möglichst nah ans Haus. Aber wenn das Nächstgelegene eine Autobahn ist, dann vielleicht doch nicht. Der Fall wäre ja noch einfach (Für Deutschland, in anderen Ländern darf ich auch auch der “Autobahn” parken). Aber vielleicht ist ja das Nächstgelegene (Mit oder ohne Fußweg) auch eine Primary - Ohne Standstreifen, wo ich gar nicht parken kann - und dann? Und dann gibt es vielleicht eine dem Haus zugeordneten Parkplatz, der ist aber ggfs weiter weg als die Primary. Wie kann ich das dem Automatismus beibringen? Funktioniert die regel in jedem fall?
Es ist nur eins von vielen Beispielen. Dieses “Da muss der Router sich drum kümmern” ist halt das typische “And here something magic happens”.
Deshalb - Schreib in Pseudocode auf wie du dir den Entscheidungsbaum denkst und ich suche dir 10 Stellen auf der Karte wo es schief geht. Die Realität ist viel komplizierter als das ein “one size fits all algorithm” das Lösen kann. Deshalb der Wunsch nach einer möglichkeit es explizit zu setzen.
Flo
Das Beispiel hast du doch schon gebracht - der Flughafen! Das Flughafengelände an sich hat keinen Eingang per-se. Es hat sehr viele. Und auf die Außenlinie des Flughafens kannst du halt auch keinen entrace=main irgendwo hinklatschen.
Denn was gehört denn alles zum Flughafen? Nur die internationale Zone? Die Parkhäuser aber nicht usw…
die Terminals haben allerdings klare Eingänge. Bei Riesengeländen kommt es schon mal vor, dass es viele Eingänge gibt, z.T. sogar auch weit voneinander entfernt. Bei großen Fabriken ist das auch der Fall. Aber dort haben die Eingänge/Zugänge in der Regel Nummern. Blöd ist halt, wenn der “Sonderbau” (z.B. Flughafen) keine Hausnummer/n hat.