Das wäre sozusagen die letzte Möglichkeit, aber wenn man Dinge wie das Tor zur Straßen (und damit den Grundstückseingang) erfasst, werden real existente Objekte in Relation gebracht. Die Information ist korrekt und vor Ort verifizierbar und sie kann einem Router helfen, den richtigen Weg zum Ziel zu finden.
Ganz genau so ist es. Es gibt ja nur 3 Möglichkeiten:
Zufahrten und Wege ergänzen, so dass ein Router den richtigen, besten Weg finden kann.
Dem Router mit Hinweisen wie „zu Adresse X geht’s aber hier entlang“ oder „der Eingang zum Grundstück ist hier“ helfen, den richtigen Weg zu finden
Router und Geocoder so schreiben, dass das Problem gar nicht auftritt.
Da wir (3) nicht beeinflussen können, muss sich jeder selbst fragen, ob, nachdem (1) angewendet wurde, (2) eine mögliche Alternative ist. Wir haben ja im konkreten Beispiel von @Robert_Schmaltz gesehen, dass das Problem für die meisten Router so nicht gelöst wird. Und ehe ich jetzt anfange, Address-Nodes durch die Gegend zu schieben, würde ich beide Ansätze, also Routing-Hints, wie routing:* auf Nodes und provides_feature-Relationen immer noch als die bessere Alternative sehen, wobei letzteres auch noch viel mehr Probleme Lösen kann, wie eben den passenden Parkplatz, usw.
Wenn es wirklich so ist, dass 3 eine Lösung wäre, aber nicht gemacht wird, kann daraus meines erachtens nicht folgen, dass wir das ausbügeln müssen. Das wäre nur, wenn es ein strukturelles Problem ist, dass Router nicht mit unseren Daten zurecht kommen. Da bin ich nicht 100% überzeugt. Letztendlich wäre meines erachtens 1 der Königsweg. flohoff sagt aber sinngemäß: Das ist für den Router zu schwierig, anhand der Daten immer selber zu entscheiden, was da das beste ist, das soll bitte ein Mensch machen und in die OSM-Daten schreiben um dem Router zu helfen. Ja bevor da echte Geometrie umgebogen wird im Sinne der Zweck heiligt die Mittel Ethik meinetwegen, aber so richtig glücklich bin ich damit nicht.
Die Daten von TomTom unterscheiden sich teilweise signifikant von OSM-Daten.
1 Like
Mammi71
(One feature, Six mappers and still More ways to map it)
65
Das ist erstaunlich!
Als ich schrieb:
hatte ich zuvor ebenfalls Google getestet und Google hatte genau das gleiche Problem!
Möglichkeit 1: @Robert_Schmaltz hat sich auch an Google gewandt und um Korrekturen gebeten.
Möglichkeit 2: falls Möglichkeit 1 nicht in Anspruch genommen wurde greift möglicherweise Google OSM-Daten ab um die eigenen Daten zu verbessern
Google kann Dinge tun, die wir nicht tun können. Die sind entspannt. Wenn Google zwei Hausnummern kennt, 10 und 14, dann kriegt das „unbekannte“ Haus in der Mitte einfach auch die Nummer in der Mitte, und in keinem Forum zieht ihnen dafür wer die Hosen stramm.
Und so werden sie wahrscheinlich, wenn sie die Fahrtrouten der Nutzer vs. ihrer Routenempfehlung auswerten, „einfach“ irgendwie „gewichten“, dass man wohl in die A-Strasse fahren muss, wenn man in den B-Weg will.
Wenn man genug Leute zusammen kriegt, kann man wahrscheinlich eine „Routing-Bombe“ werfen, indem alle nach der Kirche suchen und dann zur Kneipe fahren. Irgendwann „glaubt“ Google das. Und dafür gibt es bei Google keinen „wir sind eine Datebank, das ist mappen für die Navi!“-Anschiss im Forum, sondern eine Gehaltserhöhung.
Der Router und Plan.tomtom.com basiert auf den alten Karten direkt von TomTom. Für die neue Karte gibt es aktuell keinen frei zugänglichen Web Router, lediglich ein Spiel Editor über das TomTom
Developer Portal. (Oder je nach Land über AmiGO noch als App)
TomTom hat ab allen Adressen (welche immer ein Punkt sind) und pois einen Anker Punkt auf einer Straße sitzen zu der das pkw routing endet.
Kann halt sein, dass bei Anlage der Daten der Auto assigne auch die falsche Straße als nächsten Bezugspunkt genommen hat und den Anker da hin gesetzt hat.
Im Zweifel muss der Router halt fragen: “Ich hab hier mehrere Möglichkeiten, welche hättest du gerne?”
Machen sie auch schon heute, wenn verschiedene Routen mit unterschiedlichen Verläufen, Streckenlängen und Zeitspannen angezeigt werden.
Als ob das zu unseren Zeiten noch ein Argument wäre. Die meisten Router haben sowieso einen Fußgängermodus und es wäre vom Prinzip her nur notwendig, vom Geocode zum nächsten motor_vehicle=yes/private/destination-Weg zu routen. Wenn es mehrere gibt, siehe oben.
Wenn das mein Ziel ist… Davon abgesehen, dann gäbe es zumindest die Möglichkeit, mittels OSM-Daten Einfluss darauf zu nehmen, indem man z.B. den Fußweg direkt mit dem Gebäude verbindet (idealerweise natürlich am Eingang/an einem Eingang).
Dazu würde ein Stück weit auch gehören, dass man bei einem Gebäude nicht mehr den geometrischen Mittelpunkt sucht, sondern einen Eingang am Outline. Wenn es keinen solchen gibt, müsste man trotzdem den Mittelpunkt nehmen.
Der Vollständigkeit halber will ich noch sagen, dass diese Vorgehensweise natürlich nicht die Fälle abdeckt, die unzureichend gemappt sind. Momentan gibt es allerdings gar keine Möglichkeit, innerhalb von OSM das Routing in die Richtung zu verbessern, weil es schlicht keine Beachtung findet.
Und wie gesagt: Im Zweifel muss der Router halt fragen, welchen Eingang man gerne nehmen möchte.
Das glaub ich dir und wahrscheinlich ist obige Beschreibung auch nicht das letzte Wort - aber vielleicht geht es trotzdem in eine Richtung, dass die problematischen Fälle gelöst werden können, indem man noch mehr Details mappt.
Dann hast du für jede Route - wirklich JEDE - “Nächstgelegenen Punkt auf Straße A, B, C, D” - Ziemlich unpraktisch oder?
Du kannst ja mal auf einem gängigen Handy mit OSMAnd eine route berechnen - Und dann dir das Laufzeitverhalten von Algorithmen wie A*/Dijkstra ansehen. Das ist jetzt nicht O(1) sondern irgendwo zwischen O(n) und O(n²) - Wikipedia spricht von O(Knoten²) ohne optimierungen. Bei verdopplung der Knoten - Seit Corona weiss jeder was exponentielle Funktionen sind …
Ich habe jede menge prototypen gebaut und versucht so dinge zu Lösen. Ich sehe keine Lösung die immer funktioniert. D.h. wir haben IMMER einen Bodensatz von Problemen die wir mir dem Datenmodell nicht Lösen können.
Jetzt kannst du heuristische Algorithmen in alle Anwendungen verteilen die mehr oder minder gut funktionieren, bei denen sich der ein oder andere Anwender beschwert das aber in “Android Schimmelapp Foo Version 0.1beta” nicht geht.
Damit haben wir das problem verschoben, vielleicht sogar verkleiniert - aber das Problem bleibt.
Deshalb spreche ich seit 10 Jahren davon das wir eine Datenmodellierung brauchen für den Bodensatz der überbleibt. Es steht jedem Appentwicklet ja frei eine bessere, algorithmische Lösung, zu implementieren - Hat aber bisher keiner. Wenn das alles so einfach ist - warum gibts die dann nicht?
Und damit sind wir wieder bei RFC1925 - “The 12 networking truths” Satz 6
(6) It is easier to move a problem around (for example, by moving
the problem to a different part of the overall network
architecture) than it is to solve it.
(6a) (corollary). It is always possible to add another level of
indirection.
Naja, theoretisch könnte man sich ein addr:route_to=<coordinaten> oder was auch immer ausdenken. Geocoder findet die Adresse und kann diese Daten als “Ziel” zurück geben.
Jein, ich habe mal einen mir bekannten Entwickler gefragt; Google routet wohl idR über die Straße, die in der Adresse steht.
Also in diesem Beispiel die Donizettistraße, wenn ich wirklich Donizettistraße X auswähle; Wenn ich über rein Koordinaten gehe, dann versucht er erst eine Adresse heranzuziehen (teilweise auch über die Flurstücke) und dann erst die nächst gelegene Straße.
Und das wäre ja auch theoretisch ein Vorgehen, die jeder Router machen kann. Auch einer, der auf OSM basiert. Wenn ich eine Adresse habe idR erstmal über die entsprechende Straße aus der Adresse zu arbeiten.
Und das wäre ja auch theoretisch ein Vorgehen, die jeder Router machen kann. Auch einer, der auf OSM basiert. Wenn ich eine Adresse habe idR erstmal über die entsprechende Straße aus der Adresse zu arbeiten.
wir können zu einem Punkt oft nicht genau sagen welche Adresse er hat, weil viele Hausnummern auf Punkten oder Gebäuden sind aber dem Rest der Grundstücke keine Adresse zugeordnet ist.
Ja und? Dann nehme ich als Fallback, die nächst verbundene Straße. Aber habe halt für viele Punkte schon die Möglichkeit.
Google macht das oftmals sogar einfacher (dadurch aber dümmer); Am Ende gucken sie einfach, welche Adresse liegt meiner Koordinate am nächsten. und wählt diese dann für das Routing aus. Hat man öfter, wenn man dann mittels Rechtsklick erst eine Koordinate bekommt und dann den nächst verfügbare Adresse anwählt.
Am Ende ist es: Hier hat man Lösungen gesucht, wo viele Router die auf OSM aufbauen, halt einfach noch pennen. So einfach ist das. Und ich sage aus dem Bauch heraus grob 99% der Routings finden zu einer festen Adresse statt.
Eigentlich müssen wir uns ja nur darüber einig werden, ob wir zusätzlich zu Maßnahmen wie Ergänzen der Eingänge, Zuwege, usw. noch Hints/Tags/Relationen nutzen möchten, damit das Routen zu einzelnen Adressen korrigiert, bzw. verbessert wird, oder ob wir uns auf den Standpunkt stellen, dass die Router das schon irgendwann irgendwie selbst lösen können und müssen. Darüber zu diskutieren, wie Router das womöglich, unter Umständen, wenn man Spezialfälle außer acht lässt und überhaupt, das vielleicht jetzt schon hinbekommen oder verbessern könnten ist vermutlich wenig zielführend.
An sich denke ich schon, dass ergänzende Details für den Router schon sinnvoll sind. Hier denke ich jetzt nicht unbedingt nur an Privathäuser, wo das eher die Ausnahme sein sollte sondern viel mehr an größere Objekte.
Bspw. wenn ich zum Frankfurter Flughafen will, möchte vermutlich keiner da enden, wo OSRM, Valhalla & Co einen hin schicken. Frankfurt Flughafen wird aufgelöst zu Frankfurt Flughafen, Kapitän-Lehmann-Straße, Flughafen, Süd, Frankfurt, Hesse, 60549, Germany. Soll aber auch nur ein Beispiel sein. Beim Aldi will ich auch net zum Eingang, sondern zum Parkplatz. Diverse POI haben auch spezielle “Drop-Off/ Pick-up” Punkte bzw. ausgewiesene Parkplätze.
Klar, vieles könnte davon ein Router automatisch ermitteln, in dem er bei der Suche nach “Aldi” automatisch “nächster Parkplatz beim Aldi” sucht (in der Hoffnung, dass der Lidl-Parkplatz nicht am Ende näher am Mittelpunkt vom Aldi ist ). Oder “Drop-Off Punkt beim Ruhrzoo”. Ist aber dann alles immer Glücksache, dass man den richtigen Punkt automatisch zuordnet.
Eine Relation könnte daher schon sinnvoll sein. In der Relation könnte das “Ziel” drin sein und als weitere Mitglieder Routing-Punkte. Die Rolle dieser Punkte könnte dann sowas sein wie: parking, drop_off, pickup, entrance,…
Du fährst aber doch überall mit dem Fahrrad hin, also brauchst du den Fahrradständer bei Aldi am Eingang
SCNR
1 Like
Mammi71
(One feature, Six mappers and still More ways to map it)
78
Wir können hier noch sehr lange über mögliche Lösungen im Datenschema oder bei den Routern nachdenken - der betroffene Bewohner brauch jetzt (!) eine Lösung. Ich habe es einfach mal gemacht. Nicht optimal, aber es funktioniert.
Ich hab dann noch die Lage der Straße etwas korrigiert und die Zuwegung zur Treppe von footway auf service geändert. Wenn die Router das übernommen haben, sollte es bis zur Treppe funktionieren.
Wo ein Wille ist, ist auch ein Weg
Vielen Dank für Eure Unterstützung! Wie schon oben gesagt, ihr seid eine tolle community. Es gibt noch Ecken im Internet, die nicht von AI-Schrott und bekloppten überrannt sind
). Oder “Drop-Off Punkt beim Ruhrzoo”. Ist aber dann alles immer Glücksache, dass man den richtigen Punkt automatisch zuordnet.
