Freunde von mir erzählen, sie seien auf der Fahrt zum Feriendorf Auenland (https://www.openstreetmap.org/way/73988218) von Magic Earth auf einen Feldweg geleitet worden, wo sie so festsaßen, dass sie Hilfe benötigten.
(Bitte jetzt nicht genüsslich darüber herziehen, dass ein unbefestigter track als Zufahrt eigentlich stutzig machen sollte. Danke.)
Sache ist die: Wenn ich die Adresse der Anlage (Zum Burgberg 1) in ME eingebe, kommen ganz oben drei Treffer, die alle das richtige Objekt meinen (oder Teile davon). Der erste ist (zufällig, nehme ich an) die Sommerrodelbahn, und wenn man die als Ziel auswählt, wird wirklich über https://www.openstreetmap.org/way/73988398 geroutet. Das finde ich aus Anwendersicht höchst doof! Eine Adresse (Straße+Hausnummer) sollte auf ordentlichen Straßen zum richtigen Ziel führen und IMHO vor allem eindeutig sein! Ist es eine Mappingschwäche, dass drei Treffer erscheinen, oder trifft der Router hier einfach eine falsche Auswahl?
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.
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.
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.
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…
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.
Ja, sorry.
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.
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.
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.
