Es ist komplizierter - bzw - es lässt sich generalisieren.
Jedes OSM Objekt aus dem ein einfacher Algorithmus nicht den auf dem Routingfähigen Netz richtigen Punkt findet, oder es mehrere gibt.
Und das können total banale dinge sein.
Haus hat Zufahrt von Straße A - Straße B ist aber geographisch näher.
Innerhalb eines Flächen POIs gibt es mehrere Zufahrten für unterschiedliche Zwecke (Beispiel: Amazon Logistikzentrum - LKW Zufahrt, Mitarbeiter Zufahrt, Besucherparkplatz)
Innerhalb eines FlächenPOIs der frei navigierbar ist gibt es eine Anmeldung. Beispiel: Campingplatz → Rezeption, National Parks in den USA
POI liegt innerhalb eines weiträumig gesperrten Bereiches der nicht frei navigierbar ist, es gibt eine offizielle Zufahrt, Anmeldung, Parkplatz. (Truppenübungsplatz, Kaserne, Fußgängerzone, Malls wie das Centro Oberhausen)
Und bevor irgendwer hier wieder mit “Das muss der Algorithmus machen” ankommt. “Put up or shut up” - Bitte den Algorithmus auf Github stellen damit wir das alle ausprobieren können. Ich mache seit 15 Jahren OSM und ich bin Software Dev und ich habe schon viel mit OSM Daten hantiert, und nach meiner Einschätzung kann man solche “Schätzeisen” verändern, aber man kann das Problem damit nicht grundsätzlich lösen. Es braucht in den OSM Daten explizites hinting für die o.g. Fälle. Und spätestens wenn es mehr als eine Lösung gibt braucht man Userinteraktion - dann ist jeglicher Algorithmus makulatur.
Nein, andersherum wird ein Schuh draus: die Autoren von Routern, Geocodern und Navis sollten sich bei den Mappern melden, was sie benötigen, damit ihr Produkt so funktioniert, wie sie es sich wünschen und dann tritt man in einen Dialog. Ich finde es anmaßend „Put up or shut up“ zu sagen!
Gerade bei Flughäfen reichen Eingänge eigentlich nie, “Flughafen” ist einfach nicht präzise genug um zu wissen wo man hinwill, zum einen ist oft Ankunft und Abflug getrennt, und dann gibt es auf größeren Flughäfen auch mehrere Terminals die auch weiter auseinanderliegen können. Und es gibt meist viele, viele Eingänge, oft über die gesamte Länge der Fassade zur Straße hin, sowie unterirdisch oder oberirdisch Richtung Bahnhof. Wo man aber eigentlich nie hinwill ist das Rollfeld, bzw. das Zentroid des Gesamtgeländes, und auch nicht der am nächsten gelegene Punkt vom Centroid zur nächsten Straße (quer durch den Perimeterzaun). https://www.openstreetmap.org/search?query=fco
Stimmt. Aber es gibt Fälle, wo Eingänge reichen. Fälle, wo es auch kein multimodales Routing bräuchte, sondern einfach nur Software, die das Potential der vorhandenen OSM-Daten komplett ausschöpft.
Solange es auch in diesen Fällen noch nicht funktioniert, ist eine Diskussion über navaid-Relationen und ähnliches sehr abstrakt, denn offensichtlich sind es ja nicht die fehlenden Daten, an denen die Umsetzung des im Ausgangspost beschriebenen Features heute scheitert. Und ich vermute, dass der Entwurfsprozess von Taggingmodellen für die komplexen Fälle deutlich praxisnäher wäre, wenn die Erfahrungen von Entwicklern einfließen würden, die bereits Unterstützung für die “einfachen” Fälle in ihren Anwendungen umgesetzt haben.
Auf OSM-Webseite funktioniert das so. Mit der Routing-Oberfläche suchst du einen Punkt mittels Nominatim. Die Koordinaten werden an die gewählte Routingengine übergeben.
Je nachdem nach was du genau suchst, findest du einen besseren oder schlechteren Punkt (du könntest z.b. auch nach Terminal x suchen). Aber prinzipiell sollte man hier die gefundenen Start- und Zielpunkte anhand der Karte per Hand verbessern.
Ich bin dann allerdings überrascht, dass von Graphhopper und Valhalla über access=privat geroutet wird.
Ich gehe mal davon aus, das die Navis ihre Suche mit einer Punkt-Datenbank erledigen. Da werden keine Koordinaten aus Linen und Flächen abgeleitet sondern es existieren manuell gesetzte POI-Punkte mit Namen, Adressen, Koordinaten und Kategorien. Die können dann die Punkte gezielt an die relevanten Eingänge setzen und gegf. auch “Flughafen X Terminal A”, “Flughafen X Parkhaus 1” als Namen haben.
@jengelh Beruhige dich mal, ich bin mir sicher niemand wollte hier irgendwelchen Entwicklern irgendwas vorschreiben.
Es geht um Ideen an welcher Stelle man das Problem lösen kann - in den Daten oder in der Software. Und meistens ist es hilfreich wenn es Rückmeldungen von den Entwicklern gibt welche Anforderungen sie an die Modellierung haben.
Hier schon, wobei die gefundenen Ziele (Flughafen, terminal 1) im Sicherheitsbereich liegen - sprich Routing von und zu access=private ist implementiert.
Graphhopper macht es gewöhnlich, wenn kein anderer Weg möglich ist (z.B. weil das Ziel auf dem privaten Weg liegt).
Auf der Webseite von Graphhopper wird man darauf aufmerksam gemacht, dass man über privaten Grund muss: GraphHopper Maps | Route Planner
Es gibt noch einige andere Hinweise, z.B. große Steigungen oder Absteigepflicht beim Fahrrad, assoziiert mit einer Streckenlänge.
Wenn der gesuchte Punkt in einem Gebäude liegt, dann den Punkt nicht direkt an Nominatim übergeben sondern das Gebäude auflösen und alle Ein- und Ausgänge an diesem Gebäude suchen. Den Nutzer auswählen lassen, zum Beispiel:
Eingang 2 Terminal C, Abflugbereich
Dann diese Koordinaten für das Routing verwenden.
Der Selektionsprozess muss über den Nutzer laufen, da die Engine nicht wissen kann wo genau der Nutzer hin will (außer vielleicht die Koordinaten sind sehr nahe an einem einzigen Ein- bzw. Ausgang).
Die Nutzerinteraktion gibt es aber quasi schon auf der OSM-Webseite. Du bekommst mit der Suche den Marker zurück den du dann noch per Maus verschieben kannst bevor du auf “Los” drückst. Mehr muss die OSM-Webseite eigentlich auch nicht können, sie ist ja schließlich kein Navigationssystem sondern ich sehe die Routing-Funktionen eher als Demo an.
Ob das mit der Liste der möglichen Ziele wirklich funktionieren würde? Hätten die eindeutige Namen? Wäre die Liste vollständig? vermutlich alles nicht.
Wenn es einen eindeutigen Eingang gibt, wäre natürlich dieser Punkt besser als irgendein Punkt in der Mitte der Fläche.
Ansonsten darf doch jeder Entwickler selber entscheiden wie komfortabel und komplex er seine Software gestallten will und auf welche APIs er dabei zurückgreifen möchte.