Sollten Adressen eindeutige Routingziele sein?

Das eine Rodelbahn https://www.openstreetmap.org/way/457840567 eine Adresse hat ist zumindest sehr fragwürdig.

Das Problem ist ein sehr vielschichtiges.

Navigation geht grundsätzlich immer zu einem Punkt. Wenn der Punkt am nächsten zu einem Feldweg liegt wird man halt da hin geschickt.

Es ist also sehr wichtig das wir genau definieren WOHIN wir navigieren wollen, zu einem Punkt der Sinn ergibt

Das nächste Problem stammt aus der Konvertierung von Flächen zu Punkten zu denenan navigieren kann. Die einfachste Methode die gerade alle Navigationsaoftware anwendet ist ein "Geometrisches Zentrum" der Fläche zu bilden. Das ist dann der Punkt zu dem möglichst nah herangeroutet wird.

Das Thema ist rein von der Software nicht zu lösen. Wir werden als OSM Community über kurz oder lang für komplexe POIs definieren müssen mit welcher Modalität (Fahrzeug, Fahrrad, Zu Fuß) zu welchem Punkt navigiert werden soll.

Ich habe das die "navaid" Relation genannt. Kam aber nicht so doll an.

Ich habe das Problem am Flughafen Paderborn wo man auf einem Feldweg im Wald auf der dem Terminal.gegenüber liegenden Seite landet. Auch bei Campingplätzen hab ich immer wieder das Thema das ich auf der anderen Flußseite lande oder an einem Zaun weit von der Rezeption weg etc.

OSM hat noch viel Potential nach oben was das bilden von anzunavigierende Punkten von FlächenPOIs angeht.

Flo

Hier kommen Einzelfaktoren zusammen, die alleine tragbar sind, aber in Gesamtheit zu einem miserablen Ergebnis führen.

• Adressen werden in GPS-Koordinaten überführt, ohne weitere Nachfrage beim User bleibt das immer mehrdeutig. In dem besagten Ort führt die Adresse "Zum Burgberg 1" zu mindestens *6* Koordinaten.
  
• Daran Schuld hat auch die Verwaltung, die hier nicht mehr Hausnummern vergeben hat. Auch Rettungsdienste hätten hier dadurch einen Nachteil.
  
• Bei dem osm.org-Frontend z.B. wird nur das erste Ergebnis aus der Name-zu-Korrdinate-Konversion ausgewählt.
  
• Eine Routingengine wie Graphhopper sucht sich eine Route, mit der sie so nah wie möglich an den POI, oder eine Polygonkante davon, heran kommt. Man müsste die Routingengine 6x befragen (wegen 6 Koordinaten), und müsste dann von den errechneten 6 Routen wieder die mit kürzester Lücke zwischen Fahrziel und POI wählen. Das wird aber bisher nicht gemacht.
  
• Die access-Werte für way 67249297 (service) und way 73988398 (Feldweg) sind nicht gesetzt, das wäre noch eine Voraussetzung, damit man über diese Wege mit dem Auto und Graphhopper eben nicht nah ran kommt.
  
• In dem Bereich fehlen auch ein paar Ways (für Detailversessene), ist aber erstmal nebensächlich.
  
• maxspeed könnte man noch setzen
  

flohoff wrote:

Das Problem ist ein sehr vielschichtiges. ...

Das sehe ich hier in dem Fall nicht.

jengelh wrote:

Hier kommen Einzelfaktoren zusammen, die alleine tragbar sind, aber in Gesamtheit zu einem miserablen Ergebnis führen. ...

Kann ich nicht nachvollziehen...

Es ist zwar unschön, daß mehrere Objekte die selbe Adresse haben, aber ist so und das gibt es häufiger!
Bei der Suche nach der Adresse bekommt der Anwender häufig mehrere Dinge angeboten.
Und da muß sich der Anwender entscheiden!

Wird Feuerwehr oder Rettung zu der Adresse gerufen, dann brauchen diese Aufgrund des Geländes auch detaillierte Infos.
Es brennt, kommen sie zum Zum Burgberg 1 und zwar zum Restaurant.

FraukeLeo wrote:

...

Du hast nicht wirklich das Verkehrsmittel dazu geschrieben... Auto vermute ich in dem Fall mal.
Über welchen Weg wurden sie den tatsächlich geschickt?
Radverkehr ist bei highway=track Teil der Vorgabe, nicht jedoch der motorisierte Verkehr.

Mit dem Fahrrad zur Sommerrodelbahn kann tatsächlich über schlechte Feldwege führen...
Sollte der Router sie per Auto über auf den Feldweg geschickt haben, dann taugt der nichts!
Wenn die OSM Daten fehlerhaft sind, dann kann sowas natürlich auch passieren...
Hast du das mal kontrolliert?

Hätte man die Adresse nur noch einmal, dann würde ein Routing zu den verschiedenen Objekten nicht mehr funktionieren.
Unterschiedliche Adressen wäre da natürlich die schönste Lösung...

EinKonstanzer wrote:

Bei der Suche nach der Adresse bekommt der Anwender häufig mehrere Dinge angeboten.
Und da muß sich der Anwender entscheiden!

Sie haben die Karte auf die richtige Gegend geschoben und dann Straße+Hausnr ins Suchfeld eingegeben. Dann bekommt man folgendes:

Die ersten drei Treffer sind im richtigen Objekt. Sie nahmen den ersten, das ist die Sommerrodelbahn. Dass die Objektart nicht dabeisteht, sehe ich als Fehler von ME.

EinKonstanzer wrote:

Du hast nicht wirklich das Verkehrsmittel dazu geschrieben... Auto vermute ich in dem Fall mal.

Ja, sorry.

EinKonstanzer wrote:

Über welchen Weg wurden sie den tatsächlich geschickt?

Wussten sie nicht mehr genau, aber wenn ich mich wie oben beschrieben zur Sommerrodelbahn routen lasse, führt mich ME wie im ersten Post beschrieben über https://www.openstreetmap.org/way/73988398. Ich kann nur vermuten, dass es bei ihnen ebenso war.

Vor einiger Zeit hab ich ihnen ME als bessere Alternative zu Google vorgeschlagen, und bislang waren sie sehr glücklich damit. Wenn dann natürlich so was passiert, heißt es ganz schnell, OSM ist nicht brauchbar. Da wird nicht zwischen Geodatenprojekt und Anwendung unterschieden. Deshalb frage ich ja, ob hier ein systematischer Fehler in den Daten ist oder ob die Anwendung Mist baut.

Ich fände es sehr hilfreich, wenn ein POI (hier das Feriendorf) einen Node als eindeutiges Routingziel hätte (hier der Haupteingang / Rezeption) und man gar nicht erst unterschiedliche Elemente angezeigt bekommt, sondern ein "Hauptziel" präsentiert wird. Dass wie von flohoff beschrieben der geometrische Mittelpunkt der POI-Fläche genommen wird, ist sehr unglücklich. Kein Wunder, dass man da auf einem track am anderen Flussufer landet, wenn das halt aus Routersicht der nächste erreichbare Punkt ist.

https://www.openstreetmap.org/search?qu … 7/10.91692

Das könnte auch ME machen.

geri-oc wrote:

https://www.openstreetmap.org/search?qu … 7/10.91692

Das könnte auch ME machen.

Ja, aber das ist ja wohl erst recht Unsinn. Der zweite Treffer ist https://www.openstreetmap.org/node/812092277, und das Objekt hat selbst gar keine Adresse dran.

geri-oc wrote:

https://www.openstreetmap.org/search?qu … 7/10.91692

Das könnte auch ME machen.

Und was würde das ändern, solange die Adresse an der "Fläche" ist?

@ FraukeLeo:
Ich würde die Adresse an der "Fläche" löschen und auf das Gebäude der Talstation oder auf einen POI im Gebäude übertragen. Da will man ja auch hin, wenn man die Sommerrodelbahn nutzen will.

Europa-Park Rust, Erlebnispark Tripsdrill, ... Es gibt noch so viele Erlebniseinrichtungen, bei denen nicht an jede Attraktion und an jedes Gebäude eine Adresse drangepappt wurde. Es gibt noch viel zu tun, auf gehts. 😐

FraukeLeo wrote:

ob hier ein systematischer Fehler in den Daten ist

Das würde ich annehmen. Das Feriendorf an sich ist ja überhaupt nicht erfasst, sondern nur die "Einzelteile", und diese fälschlicherweise mit Adressen, die sich nicht haben. Zumindest bezweifle ich stark, dass die Rodelbahn und der Abenteuerspielplatz eine solche besitzen. Die gehören zum nicht erfassten Feriendorf.

PT-53 wrote:

Da will man ja auch hin, wenn man die Sommerrodelbahn nutzen will

Nein, da will man nicht hin geroutet werden. Man will auf den Parkplatz, um seine Vehikel dort abstellen zu können und dann zu Fuß die Attrationen besuchen.

flohoff wrote:

Das Thema ist rein von der Software nicht zu lösen. Wir werden als OSM Community über kurz oder lang für komplexe POIs definieren müssen mit welcher Modalität (Fahrzeug, Fahrrad, Zu Fuß) zu welchem Punkt navigiert werden soll.

Ich habe das die "navaid" Relation genannt. Kam aber nicht so doll an.

Finde ich eine gute Idee. Wo kann ich mehr dazu lesen? Auf dem OSM-Wiki finde ich nur https://wiki.openstreetmap.org/wiki/Pro … res/navaid, aber da geht es um Seekarten, und seit 10 Jahren ist da nix mehr passiert.

dooley wrote:

PT-53 wrote:

Da will man ja auch hin, wenn man die Sommerrodelbahn nutzen will

Nein, da will man nicht hin geroutet werden. Man will auf den Parkplatz, um seine Vehikel dort abstellen zu können und dann zu Fuß die Attrationen besuchen.

In der Regel sind die Parkplätze doch direkt an der Talstation, oder?

Mal angenommen, dass dort wirklich diverse Objekte die gleiche Adresse haben, dann wäre es mMn für einen Router trotzdem sinnvoll, die Information "eine Adresse mit Straßenname wurde als Ziel angegeben" dahingehend zu interpretieren, dass das Ziel über eine Straße mit diesem Namen zu erreichen ist. Wenn der Router aber nur eine Koordinate als Ziel bekommt, dann kann der das nicht leisten.
Nominatim aber hat die Information, was gesucht wurde, und könnte daher die Ergebnisse nach der Entfernung zur jeweils nächsten passenden Straße sortieren, wenn es denn überhaupt erkennt, dass "Zum Burgberg" ein Straßenname ist.

dooley wrote:

Nein, da will man nicht hin geroutet werden. Man will auf den Parkplatz, um seine Vehikel dort abstellen zu können und dann zu Fuß die Attrationen besuchen.

Ich würde sagen: Man will im PKW-Modus zum Parkplatz geroutet werden und dann vom Router die Info bekommen, dass es jetzt zu Fuß weitergeht. Er schaltet auf Fußgängermodus um und führt einen zum Eingang der Attraktion. Aber das ist sicher Science-fiction.

EinKonstanzer wrote:

flohoff wrote:

Das Problem ist ein sehr vielschichtiges. ...

Das sehe ich hier in dem Fall nicht.

jengelh wrote:

Hier kommen Einzelfaktoren zusammen, die alleine tragbar sind, aber in Gesamtheit zu einem miserablen Ergebnis führen. ...

Kann ich nicht nachvollziehen...

Es ist zwar unschön, daß mehrere Objekte die selbe Adresse haben, aber ist so und das gibt es häufiger!
Bei der Suche nach der Adresse bekommt der Anwender häufig mehrere Dinge angeboten.
Und da muß sich der Anwender entscheiden!

Wir wissen ja noch nichtmal WOHIN die Navigation ging - War es eine Adresse? Oder ein POI? Ein POI als Fläche? Was hat der Benutzer in der App ausgewählt und welcher Punkt wurde dann als Ziel angenommen?

EinKonstanzer wrote:

Mit dem Fahrrad zur Sommerrodelbahn kann tatsächlich über schlechte Feldwege führen...
Sollte der Router sie per Auto über auf den Feldweg geschickt haben, dann taugt der nichts!
Wenn die OSM Daten fehlerhaft sind, dann kann sowas natürlich auch passieren...
Hast du das mal kontrolliert?

Hätte man die Adresse nur noch einmal, dann würde ein Routing zu den verschiedenen Objekten nicht mehr funktionieren.
Unterschiedliche Adressen wäre da natürlich die schönste Lösung...

Es geht nicht um Adresse - Du kannst in der Navigation nach beliebigem suchen. Und das kann eine Fläche oder ein Node sein. Und wenn es eine Fläche ist - WO wird dann genau hinnavigiert - Probier es aus. Das mappen der Fläche auf einen Node macht auf der Webseite natürlich noch Nominatim nicht OSRM.

Und wenn du nach "Auenland" suchst und diesen Way dann anklickst:

https://www.openstreetmap.org/way/73988218

Der dann geometrisch auf einen Punkt gemapped wird - dann ist der nächstgelegene Punkt auf Wegen ein Track. Und wenn du dann einen router nimmst der Tracks nicht kategorisch ausschliesst landest du auf einem Track.

Einfach mal auf der Webseite eine Router von "Hinterrod" nach "Hinterrod, Erlebnisgarten" berechnen - Graphhopper (Car) schickt dich schön durch die Feldwege. OSRM (Car) ist nen bisschen schöner weil der Tracks kategorisch ausschliesst und der Entpunkt zufällig näher an der richtigen Zufahrt liegt.

Aber das Ergebniss für das Routing zu Flächenpois oder abseits der Straßen gelegene POIs ist nur zufall. Deterministisch kannst du da gerade bei OSM nichts drehen.

Flo

FraukeLeo wrote:

dooley wrote:

Nein, da will man nicht hin geroutet werden. Man will auf den Parkplatz, um seine Vehikel dort abstellen zu können und dann zu Fuß die Attrationen besuchen.

Ich würde sagen: Man will im PKW-Modus zum Parkplatz geroutet werden und dann vom Router die Info bekommen, dass es jetzt zu Fuß weitergeht. Er schaltet auf Fußgängermodus um und führt einen zum Eingang der Attraktion. Aber das ist sicher Science-fiction.

Darauf zielte genau meine idee der "navigation aid" oder "navaid" relation ab - Ich kann ein Ziel und die Modalität beschreiben und das "Ersatzziel" was stattdessen angesteuert werden muss:

to=Erlebnisgarten
with=car
finalto=<punkt auf parkplatz>

to=Erlebnisgarten
with=foot;bicycle
finalto=<punkt am eingang zum erlebnisgarten>

Wenn man dann definiert das finalto ein node ist - und noch eine Beschreibung enthalten kann und mehrfach vorkommen kann man in der Naviation dann machen

"Navigiere mich zum Müngersdorfer Stadion" und es klappt ein Menu auf wo die liste der Parkplätze sind weil in der navaid relation steht dann wenn ich zum Müngersdorfer Stadion mit dem Auto will das es mehrere "finalto" gibt - Parkplatz West, Parkplatz Ost, Parkplatz Foo.

Ebenso dann auch Flughäfen - Wo ich dann sagen kann wenn ich zum "Flughafen Frankfurt" will das ich eine Liste von Parkplätzen, Terminals und Ankunft/Abflug bekomme.

Flo

PT-53 wrote:

In der Regel sind die Parkplätze doch direkt an der Talstation, oder?

Den Sat-Bilder nach zu urteilen gibt es an der dortigen Talstation keine Parkplätze.

Bei dem Beispiel kommen einige Fehler zusammen, die meines Erachtens beim Kartografieren gemacht wurden:

Um das Gelände, auf dem sich die Sommerrodelbahn befindet, wurde eine Linie gezeichnet mit attraction=summer_toboggan - laut https://wiki.openstreetmap.org/wiki/DE: … r_toboggan ist dies aber nur für lineare Objekte zulässig. An diese Linie (die ja von OSM nicht als Flächenumrandung interpretiert wird) wurde mit Adressattributen versehen. Bei einem so großflächigen Objekt macht es zudem wenig keinen Sinn, eine Post- und Besucheradresse in ein so ausgedehnten Objekt zu intergrieren. Denn Anschrift ist das, wo man hingeroutet werden will und wo die Post zugestellt wird. Ich bezweifele, dass es sich bei der Zufahrtsstraße, die vom Dorf zur Talstation führt, um eine allgemeine Zufahrt handelt. Denn da fehlt es nicht nur an Parkmöglichkeiten, es ist auch keine Wendemöglichkeit vorhanden. Ich vermute sehr, dass diese Zufahrt nicht öffentlich befahrbar ist. Nach Satellitenbild sieht mir das auch eher wie ein geschotterter Feldweg aus. Die Verbindungen zwischen dem Parkplatz und der Talstation sind hingegen als Feldwege eingezeichnet. Sind das dann nicht eher Fußwege oder zumindestens Zufahrtswege?

Wie wäre meiner Meinung nach diese Sommerrodelbahn besser eingetragen worden:

1. https://www.openstreetmap.org/way/45784 … 0/10.91870 hätte ich komplett weggelassen.
2. https://www.openstreetmap.org/way/67249 … 1/10.91480 halte ich für ok, nur railway hätte ich weggelassen.
3. hätte ich einen POI an der Talstation gesetzt (steht ja auch in dem oben zitierten Wiki-Beitrag) mit tourism=attraction + attraction=summer_toboggan + name=Sommerrodelbahn Feriendorf Auenland (wobei man sich streiten könnte, ob die Sommerrodelbahn überhaupt einen Namen hat oder dies nur eine Bezeichnung ist) - dieser POI wäre jedenfalls, wo ich von meiner Routin-App hingeschickt werden muss. Und da ich davon ausgehe, dass man dort auch vom Parkplatz aus nicht einfach mit dem Auto vorfahren darf, wäre zu fragen, welche access-werte an die Wege zwischen Parkplatz und Talstation gehören (und es sind mit Sicherheit keine Feldwege)
Eine Anschrift würde ich diesem POI auch nicht geben. Dafür aber operator=Feriendorf Auenland
4. Nun braucht es aber noch eine Anschrift... Da wäre die Frage, wo ist die "Rezeption" des Feriendorfs? In dem Gebäude "Bergbaude" oder in dem Gebäude "Kulturscheune"? Wo hängt der Briefkasten? Ich war z.B. in einem Feriendorf im Urlaub, knapp 90 Häuser. Das ganze Feriendorf lief über die Anschrift Seeweg 1 - und am Haupteingangstor zum Gelände gab es ein Schild, auf der dieses Anschrift stand... dort habe ich den Adress-POI hingesetzt von dem Feriendorf. Übertragen auf das Feriendorf Auenland: Es scheinen ja die beiden Restaurants (Bergbaude und Kulturscheine) ebenso wie die Erdhäuse und die Sommerrodelbahn zum Feriendorf Auenland zu gehören. Daher müsste man vor Ort mal überprüfen, ob dort überall nur ein operator=... genannt wird und zentral am Parkplatz (oder eben in dem Gebäude, wo die zentrale Verwaltung oder Rezeption ist) einmal nur die Anschrift name=Feriendorf Auenland + addr:housenumber=1 + addr:street=Zum Burgberg...

Nach meinem Dafürhalten dürfte es damit keine Navigationsprobleme mehr geben. Nach Anschrift würde man zum Parkplatz bzw. zu einem der Gebäude dort unmittelbar nebenan geroutet. Hat man nach Sommerrodelbahn allein gesucht, wird der POI an der Talstation verwendet, wäre klar, dass die Wege dorthin nicht dazu gedacht sind, mit dem Auto direkt dorthin zu fahren (access-Werte, Fußweg statt Feldweg...) würde die Navi-App einen nicht mit dem Auto direkt dorthin schicken wollen.

dooley wrote:

PT-53 wrote:

In der Regel sind die Parkplätze doch direkt an der Talstation, oder?

Den Sat-Bilder nach zu urteilen gibt es an der dortigen Talstation keine Parkplätze.

Mit meiner Lösung würde man aber auf die korrekte Zufahrt geführt werden und von dort werden ja wohl Hinweise auf Parkmöglichkeiten vorhanden sein.
Welche praktikable Lösung schlägst Du denn vor?

Die Idee von Flohoff mit seiner "navaid" relation" finde ich gut. Müßte nur noch konkret eingeführt werden.

Siehe Post #18 von Galbinus, besser kann ich es nicht ausdrücken.

Galbinus wrote:

Bei dem Beispiel kommen einige Fehler zusammen, die meines Erachtens beim Kartografieren gemacht wurden:

Um das Gelände, auf dem sich die Sommerrodelbahn befindet, wurde eine Linie gezeichnet mit attraction=summer_toboggan - laut https://wiki.openstreetmap.org/wiki/DE: … r_toboggan ist dies aber nur für lineare Objekte zulässig.

Und https://wiki.openstreetmap.org/wiki/DE:Key:attraction besagt genau das Gegenteil, nämlich so wie gemappt.
Ist schon blöd, wenn das Wiki so widersprüchlich ist ...

Ansonsten ziemlich +1.

GeorgFausB wrote:

Ist schon blöd, wenn das Wiki so widersprüchlich ist ...

wow, ist in diesem Fall wirklich kurios, da der von Dir gefundene Artikel im Text sogar auf den von mir verlinkten Artikel verlinkt... spätestens, wenn man so etwas verlinkt, sollte man doch mal vergleichen und dabei so deutliche Widersprüchlichkeiten erkennen!

flohoff wrote:

Ich habe das Problem am Flughafen Paderborn wo man auf einem Feldweg im Wald auf der dem Terminal.gegenüber liegenden Seite landet. Auch bei Campingplätzen hab ich immer wieder das Thema das ich auf der anderen Flußseite lande oder an einem Zaun weit von der Rezeption weg etc.

OSM hat noch viel Potential nach oben was das bilden von anzunavigierende Punkten von FlächenPOIs angeht.

ich habe auch so ein Problem hier mit dem Flughafen. Einfach mal "FCO" suchen, dann weißt Du was ich meine, 5km vom Eingang entfernt auf einen Weg um den Flughafen bringt dich Nominatim (und vermutlich viele andere). Das Problem sehe ich aber vor allem bei den Datennutzern: bei einem viele Hektar großen Objekt wie einem Flughafen ist es klar, dass ein Algorithmus der nur das Zentrum sucht, nicht funktionieren kann ohne viel Glück. Man müsste in diesem Fall (wie ein Mensch 😉 ) erkennen können, dass es da Parkplätze und Terminalgebäude gibt, und dass man an einem Flughafen normalerweise wissen muss, ob man zum Abflug oder zur Ankunft will, und welches Terminal / Gate. Bei Parkplätzen auch, ob man kurzparken bzw. auch nur halten will (Taxis, aus- und einladen), oder ob man den Wagen 2 Wochen stehen lassen will. Das sind Dinge, die einerseits in OSM noch nicht wirklich tief semantisch beschrieben werden (An- und Abflug, Gates, Terminals, Langzeit vs. Kurzzeitparken sofern es nur finanziell und nicht rechtlich (Zulässigkeit) einen Unterschied macht), und die andererseits auch nur stiefmütterlich von den Router Implementationen behandelt sind (kein mir bekannter Router fragt nach, zu welchem "Unterobjekt" eines riesigen Objekts man geführt werden will).
Den/die (Haupt)Eingang/Eingänge zu mappen geht bei kleineren Objekten gut und sollte man auch machen, allerdings braucht man bei Flughäfen noch mehr Infos, weil jedes Terminal wahrscheinlich mehrere Eingänge hat, und die auch so weit auseinanderliegen können, dass es einen signifikanten Unterschied macht.

FraukeLeo wrote:

Sie haben die Karte auf die richtige Gegend geschoben und dann Straße+Hausnr ins Suchfeld eingegeben. Dann bekommt man folgendes:

Screenshot-20200921-070050-Magic-Earth.png

Die ersten drei Treffer sind im richtigen Objekt. Sie nahmen den ersten, das ist die Sommerrodelbahn. Dass die Objektart nicht dabeisteht, sehe ich als Fehler von ME.

ok, wenn man so einen screen als Suchergebnis bekommt, dann ist einem doch schon klar, dass man nochmal besser nachsehen sollte, wo genau man hin will, und dass es leicht zu Missverständnissen kommen kann. Neben dem Nutzer 😉 sehe ich da das Problem auch klar in der Anwendung, die weder die Ergebnisse gemeinsam auf einer Karte darzustellen scheint, noch die Objektarten oder sonst eine nützliche individuelle Beschreibung generiert.

flohoff wrote:

Ich habe das Problem am Flughafen Paderborn wo man auf einem Feldweg im Wald auf der dem Terminal.gegenüber liegenden Seite landet. Auch bei Campingplätzen hab ich immer wieder das Thema das ich auf der anderen Flußseite lande oder an einem Zaun weit von der Rezeption weg etc.

Ich frage mich, wie schafft es Google-Maps, dass es Autofahrer auf die richtige Seite des Paderborner Flughafen schickt, obwohl auch dort der POI "Flughafen" nicht dort sitzt, wo man den Flughafen betrifft sondern irgendwo mitten zwischen Rollbahn und Startbahn?

Galbinus wrote:

Ich frage mich, wie schafft es Google-Maps, dass es Autofahrer auf die richtige Seite des Paderborner Flughafen schickt, obwohl auch dort der POI "Flughafen" nicht dort sitzt, wo man den Flughafen betrifft sondern irgendwo mitten zwischen Rollbahn und Startbahn?

Hier mal zum Vergleich OSM-Routing (graphhopper):

Wenn ich aber auf meinem Handy in der magic-earth-App die Route erstellen lassen, funktioniert es wiederum bestens:

Galbinus wrote:

Ich frage mich, wie schafft es Google-Maps, dass es Autofahrer auf die richtige Seite des Paderborner Flughafen schickt, obwohl auch dort der POI "Flughafen" nicht dort sitzt, wo man den Flughafen betrifft sondern irgendwo mitten zwischen Rollbahn und Startbahn?

die wissen halt, dass 98% der Leute die in den letzten Jahren Paderborner Flughafen als Suchziel eingegeben haben, am Ende dahin fahren wo jetzt das Ergebnis auf der Karte sitzt. 😉

Ich habe den Test "Termini"->"FCO" gemacht mit Google, Apple maps und OSM Webseite.
Die beiden kommerziellen bekommen es beide hin.
Ich vermute allerdings, dass dieses Ergebnis zumindest bei Apple (bzw. Here) "handkuratiert" ist, weil ich mit Apple Maps zuletzt 2x genau dasselbe Problem hatte: anstatt zum Eingang/Parkplatz (einer archäologischen Stätte und eines POI für Kinder) wurde ich zu einem Feldweg geführt, der räumlich dem vermuteten Zentroiden am nächsten kam, aber relativ weit vom Eingang entfernt war.
D.h. für Flughäfen haben sie vermutlich einen verifizierten Punkt gespeichert, aber für alles was es gibt geht das natürlich eher nicht.

Die von Google und OSM angezeigte Punkt liegen aber nicht weit auseinander. Und Magic-Earth scheint in diesem Fall das Routing auch auf OSM-Datenbasis korrekt hinzubekommen.