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.
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.
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.
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.
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.
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?
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:
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.
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=
to=Erlebnisgarten
with=foot;bicycle
finalto=
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.
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:Tag:attraction%3Dsummer_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:
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
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.
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.
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!
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.
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.
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.
) 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).
