Hauszufahrten - Falsch zugeordnet / Routing

An dieser Stelle sollte “entrance=main” an den Häuschen das Problem lösen.
Ob sich Router die Mühe machen das auzuwerten ist noch was anderes. Ganz nebenbei: Wie sieht es eigentlich mit Nominatim aus?

Aber auch ein “entrance=main” ist kein Automatismus für Erfolg. Rein geschätzt ist der Eingang bei Hausnummer 22a immer noch näher an der Zufahrt als an der Straße.

Bezüglich Relationen…
Wo ist denn eigentlich der Eingang am Supermarkt? Also wo soll man hingeroutet werden?
Als Fußgänger zum Eingang, als Fahradfahrer zum Fahrradständer, als Autofahrer zum Parkplatz (oder zur TG-Eingahrt beim Einkaufszentrum) und als Lieferant zum Lieferanteneingang…
Könnte aber beim Einkaufszentrum dazu führen, daß man für jeden Laden eine Relation pflegen muß.

Eine einfachere Lösung ist es spezielle “Anfahrtsadressen” zu pflegen.
Oder umgekehrt. So wie du es im Prinzip gemacht hast: Die Adresse gehört an den Anfahrtspunkt.
… und die Häuschen bekommen einen Zusatz-tag der dort die Adresse zu einem reinen “label” macht.
Das eine für den Renderer und das andere für den Router.

in Italien sind die Nummern auf den Zugangspunkten, wo der öffentliche Raum verlassen wird am Übergang zum Grundstück oder Gebäude. Rechtlich gesehen (in Deutschland sind es Grundstücksnummern). Da klappt das Routing gut, aber man weiß nicht unbedingt, zu welchem Grundstück oder Gebäude/Laden die Nummer gehört (wo sie aufhört, auch kann ein Gebäude viele Nummern „haben“).
In Deutschland ist das Problem anders rum :wink:
Zusätzlich zu den Gebieten zu denen die Nummern gehören, muss man die Zugangspunkte mappen. barrier=gate / entrance oder entrance=* je nachdem wer die Nummer hat. Der Bezug wird dadurch hergestellt, dass ein solches Objekt (Tür/Zugang) auf dem outline einer Adresse sitzt. Problemchen ist dabei derzeit, dass die Nummern auf Gebäuden getaggt werden auch wenn ein Grundstück dazugehört. Eigentlich gehören die Nummern in Deutschland auf Grundstücke, aber das ist nur bei POIs so gemappt (wenn sie flächig gemappt sind)

Genau - Bei Hausnummer 22 und 22a geht das trotzdem schief.

Der Punkt ist - Das kann man dort hinzufügen (Optional) wo der Automatismus eine absurd kaputte Lösung findet. Das ist ja beim Supermarkt eher nicht so. Wenn ich zu einem Supermarkt route dann sehe ich den Fahrradständer, den Lieferanteneingang oder den Kundeneingang.

Das ist mitunter nicht so wenn man zu so komplexen Objekten wie “Nationalpark Eifel”, “Flughafen Frankfurt”, “Centro Oberhausen” oder Campingplätzen route.

Am Flughafen Paderborn habe ich dieses Experiment vor Jahren mal gewagt und bin hier rausgekommen:

https://www.openstreetmap.org/?mlat=51.61673&mlon=8.61684#map=18/51.61673/8.61684&layers=N

Dann sieht man zwar die Landebahn. Aber zum Terminal sind es drumherum nochmal 6-8km. Das liegt daran das für eben den komplexen POI “Flughafen Paderborn” der “nächstgelegene Punkt auf dem Straßennetz” völlig unvorhersehbar irgendwo landet. Und der Flughafen Paderborn ist jetzt bei leibe nicht groß oder komplex.

Kurzes Beispiel das wieder sehr Lustig ist:

Campingplatz Ecktannen:
https://www.openstreetmap.org/directions?engine=graphhopper_car&route=53.5011%2C12.6775%3B53.4952%2C12.6618#map=16/53.4976/12.6672&layers=N

Routed mich in die mitte des Campingplatzes - “Sie haben das Ziel erreicht” - Wollte ich da hin? Nein.

Und sowas kannst du auf vielen Campingplätzen wiederholen. Wenn alles “access=private” ist stehst du auf einem Waldweg in Sichtweite des Campingplatzes, wenn alles offen ist wie hier in der Mitte des Campingplatzes. Aber deterministisch zur Rezeption bringt dich keiner. Da kann man tausende Beispiele ad hoc erzeugen wo das schief geht.

Das ist ein Grundlegendes Problem mit “Flächen POIs” - POIs heissen nicht umsonst “POINT of interest” und nicht “Area of Interest”.

POI ist eine Fläche, Navigation/Routing geht nur zu Punkten. Wie komme ich von der Fläche zu einem Punkt? Der Automatismus macht das für kleine Flächen relativ gut (Häuser, Supermärkte, Tankstellen) (Sicherlich 99% richtig mit eben den Ausnahmen wie hier beschrieben) und failed grandios bei Dingen wie Nationalparks, Flughäfen, Campingplätzen, Industrieanlagen, Malls und Städten und eben auch bei kleinen POIs die eben nicht triviale Anfahrtsstrukturen haben.

Flo

ja, kenne ich auch https://github.com/osm-search/Nominatim/issues/1389
wir müssen die Router fixen!

Aehm - Nein - Das kann kein Automatismus der Welt finden. Der braucht hilfe. Deshalb ja die “navaid” relation.

Vom vorgehen passiert ja folgendes.

  • Du gibst die Adresse/POI Namen ein
  • Nominatim findet ein OSM Objekt (Eine Fläche)
  • Nominatim liefert dir den “Mittelpunkt” (Postgres ST_Centroid) von diesem Objekt.
  • Ein router (OSRM, graphhopper - you name it) nimmt diesen Mittelpunkt und sucht in seinem Graphen den nächstgelegenen Punkt für deine Modalität
  • Du wirst zu diesem Punkt geroutet.

Wo willst du das jetzt im Router fixen?

Flo

Nominatim gibt eine Fläche als Ergebnis (in dem Fall der uns interessiert), und da darf der Router eben nicht den Mittelpunkt nehmen sondern einen geeigneten Punkt, z.B. den Haupteingang oder Hauptzugang, bzw. könnte es auch erkennen dass es mehrere Eingänge gibt und nochmal nachfragen…

Ja, damit sollten sich die meisten Fälle erschlagen lassen, wenn man zusätzlich die Zugangswege (auch Fußwege) beim Routing berücksichtigt.

Also: Adressbuilding hat ein entrance=main Node (oder genau einen entrance=yes):
Diesen als Routingziel nehmen anstelle des Mittelpunkts.

Fußwege berücksichtigen hatten wir oben Diskutiert - Nein - hilft nicht.

Und Entrance hilft auch nicht wenn der näher an Straße B als an A ist.

Flo

Ich geh mal mit einer Steilen These Vorran: Du schreibst den Entscheidungsbaum als “Pseudocode” und ich suche dir 100 Beispiele die damit nicht funktionieren.

Du kannst mir glauben das ich das seit 8 Jahren oder so immer wieder durchdenke. Und vor 8 Jahren hab ich auch mit automatischen Auswertungen angefangen die dieserlei Probleme automatisch findet.

Und ein Thema was ich da identifiziert und in den letzten Jahren bei mir gefixed habe in der Ecke sind tracks als Hauszufahrten, mit der Gießkanne verteilte access tags und fehlende Hauszufahrten.

Und jetzt bleibt halt ein Bodensatz an Problemen die sich durch fälschen von OSM Daten nicht lösen lässt.

Flo

Und hier ein paar Beispiele aus meiner Auswertung die dann zu fixen wären durch den Automatismus.

Wer da selber suchen will - Es sind herrliche Beispiele dabei - Hier ein Link auf die Interaktive Karte - hier NRW - Dortmund Fußgängerzone.

https://osm.zz.de/dbview/?db=addresses-nrw&layer=routeable#51.51429,7.46469,18z

Hier nur ein paar Beispiele:

Fußgängerzone Köln:

Kaserne Augustdorf. Es würde sinn ergeben alle Adressen zur Pforte zu delegieren. Aktuell gehen die zu diversen Straßen denen Access tags fehlen oder eben auf die Panzerringstraße nach außen:

Müngstener Brücke - Ein teil der Adressen geht richtigerweise zum Parkplatz vor der Schranke. Eine Adresse geht auf das gegenüberliegende Wohngebiet:

Die Kapelle auf dem Friedhof Schildesche - Sollte auf den Parkplatz gehen, geht zur Schäferstraße die gar keinen Zugang zum Friedhof hat:

Und es gibt auch noch so absurde Dinge wie die nächstgelegene Straße ist ein Tunnel:

Oder der nächstgelegene Punkt ist auf der anderen seite der Bahnlinie:

Oder der nächstgelegene Punkt ist auf einer Autobahn Auf-/Abfahrt:

Das “Kfz”-Profil eines Routers müsste, so denke ich, dahingehend angepasst werden, dass highway=footway auch mit in die Routingentscheidungen einfließen, sofern solche Fußwege nur am Start bzw. Ende der gesamten Route auftreten. Das würde Fälle wie auch diesem helfen.

Wenn man dann noch Fußwege bis zur Haustürnode gemappt hat, ist auch der “final gap” (also Lücke zwischen letzter graphisch erreichbarer OSM-Node zur ultimativ gewünschten Ziel-GPS-Position) sehr gut minimiert, sodass es in vielen Fällen nichts ausmacht, wenn addr: auf dem Gebäudezentroid statt dem Fronteingang liegt.

Zumindest das letzte Beispiel sollte sich leicht beheben lassen: dem Grundstück mit immerhin 4 Hausnummern fehlt ein Zufahrtsweg.

Verstehe jetzt die Argumentation nicht ganz. Vielleicht ist das Beispiel nicht brauchbar.
Das auf das ich hinaus möchte, zeigt das Beispiel der Fußgängerzonen am Besten. Die Probleme gibt es in dem Fall nämlich nur per KFZ. Zu Fuß nämlich nicht! Vorausgesetzt der Router beherrscht Routing auf Flächen… :wink:
Per KFZ sollte einem vielleicht das nächstgelege Parkhaus geliefert werden, per Fahrrad der Fahrradständer in der Nähe, … und wer in eine Fußgängerzone liefern möchte muß die Bestimmungen beachten (Anlieferung z.B. Werktags nur zwischen 6 - 10 Uhr).

Es gibt eben nicht zwingend die eine Koordinate an denen einen der Router schicken soll.

Zumindestens bei den Standardfällen könnte man das durch eine Trennung von Adresse für die Darstellung und Anfahrtsadresse vollständig erschlagen. Die Anfahrtsadresse wird genau so positioniert, das mit dem Routing klappt.
Der Versuch das mit Relationen zu lösen ist für mich im Moment zu hoch gegriffen.

Deine Beispiel zeigen ja auch deutlich: Das Problem sind nicht die nicht vorhandenen Wege sondern die Beschränkungen der Benutzbarkeit. Im KFZ Modus kann halt nur der nächst gelegene Punkt anvisiert werden der per KFZ zu erreichen ist. Auch wenn das Mist ist.
Ergänzend zur Idee Anfahrtsadressen zu pflegen wäre noch ein Attribut notwendig, daß das Verkehrsmittel definiert. Auto hier, Fahrrad hier, Lieferanten hier, …

Genau, der Router müsste eigentlich noch sehen, wie man da weiter kommt, d.h. wenn Eingänge gemappt sind ggf. Fußweg zu diesen, etc… Es hilft einem nichts, wenn der Zielpunkt die am nächsten gelegene Straße ist, wenn dann ein Fluss ohne Brücke zwischen dem Routingziel und dem gewünschten Ziel liegt.

Das wird zwar meistens noch scheitern weil die Fußwege und privaten Zuwegungen nur sporadisch gemappt sind, aber auf lange Sicht ist das erfolgsversprechend.

Was Eingänge angeht, so reichen “main” und “yes” als Hierarchie nicht aus. Habe bemerkt dass man mapper da “secondary” als Wert eintragen, was ich noch unterhalb von “yes” interpretiere und in meinem Mapping aufgegriffen habe. Analog ist m.E. auch noch Raum für “tertiary”, also Punkte wo man zwar in ein Gebäude reinkommt, aber das entweder nie genutzt wird, oder es sich z.B. um eine Sackgasse handelt (z.B. Zugang zu Abstellraum oder Müllraum, Haustechnikraum der von außen zugänglich ist), also Eingänge, die man als Router nicht oder nur zu allerletzt berücksichtigen sollte wenn es keine Alternativen gibt.

Ja, das sehe ich auch als Datenproblem an, einer der Wege ist kein track sondern vermutlich service.

Stimme ich zu. Nur muss man vor Ort überprüfen, ob die Zufahrt wirklich als service getaggt werden darf. Ich habe hier leider so einen Fall. Zufahrt zu einem Haus über einen “Feldweg” der mit 250 oder 260 (das weiß ich gerade nicht aus dem Kopf) für den (KFZ-)Verkehr gesperrt ist. Ohne Ausnahme. Somit auch kein hw=service. Der Briefkasten steht auch vor dem Weganfang.

Ich bin voll auf Deiner Seite bezüglich der von Dir vorgeschlagenen Relation.
Deine Beispiele hinken aber zum Teil. In o.g. Beispiel ist doch die Zufahrt falsch eingezeichnet, oder ?
Hast Du dazu mal einen Link auf die OSM-Daten?

Edit:
Hier die Links zu den Zufahrten:
1.) https://www.openstreetmap.org/way/34138133/history
2.) https://www.openstreetmap.org/way/34138135/history
Nach meiner Auffassung ist die Straßen-Klassifizierung (track statt service / unclassified) bei 1.) auf der ganzen Strecke und bei 2.) auf einem Teil des Weges falsch.

Vermutlich ja. Diesen Fehler sehe ich auch öfters, da der Weg nach Optik und nicht nach Funktion gemappt wird. Aber kennst Du die Beschilderung vor Ort?

Das Grundproblem läßt sich auch durch 100% korrektes taggen von Wegen/Straßen nicht lösen.

Der Router wird und muss immer den nächst möglichen Ort zum Ziel (Luftlinie) suchen.
100 Meter Fußweg sind nunmal 100 Meter Fußweg und für KFZ nicht befahrbar. Da nimmt der Router logischerweise den Punkt der 99 Meter vom Ziel (Luftlinie) entfernt ist auch wenn dazwischen eine Bahntrasse liegt.

Einem Router die Logik beizubringen, das Luftlinie nicht das beste Kriterium ist, das der Router weiter denken muss halte ich im Moment für Wunschdenken.

Ich hatte ja bereits den Vorschlag für spezielle Anfahrtsadressen gemacht. Diese auch mit Angabe der Fahrzeugart. In solchen Fällen bekommt man bei der Navigation zur Bachtalstraße 100 nicht einen Treffer sondern mehrere.

  • Bachtalstraße 100 (ohne eine Angabe, der klassische POI)
  • Bachtalstraße 100 - KFZ Anfahrt
  • Bachtalstraße 100 - Lieferantenanfahrt
  • Bachtalstraße 100 - Per Fahrrad

Ich mache das mal deutlich an der kleinen Zeichnung die ich spontan auf dem Papier gemacht habe. Straße A ist eine mehrspurige Straße mit Radweg und Halte/Parkverbot. Straße bei ist die Straße zu der das Haus gehört mit dem zum Haus gehörigen Parkplatz.

Straße A liegt deutlich näher. Ich möchte das die Navigation mich zum zum Haus gehörigen Parkplatz routed der über Straße B erreichbar ist.