Hauszufahrten - Falsch zugeordnet / Routing

Hi,
ich habe hier und auf der Tagging Mailingliste das Thema der “Falsch zugeordneten” Adressen ja schon mehrfach Adressiert. D.h. Hausnummer 1 wird der Hauszufahrt von Hausnummer 2 zugeordnet und da rein geroutet obwohl von dort gar kein Zugang besteht. Es geht mir nicht darum dieses konkrete Beispiel zu fixen - Das geht mit dem aktuellen Datenmodell von OSM nur in dem man Daten absichtlich fälscht und kaputt machen.

Das liegt am Adressesuche → Nagivationspunkt Übergang in dem einfach der nächstgelegene Punkt auf dem Straßennetz gesucht wird.

Ich habe jetzt einen “Krassen” fall wo mich ein Anwohner angeschrieben hat das sich ständig Auslieferfahrer von Amazon und Co bei ihm Festfahren.

Es geht um diese Adresse - Putzhagen 22b, Gütersloh.

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

Hier ist die Hauszufahrt nötig weil ansonsten bei der Navigation die Nutzer auf die Nördlich gelegene “Herzebrocker Straße” geschickt werden “Sie haben ihr ziel erreicht” was halt Bullshit ist. Von dort existiert kein Zugang.

Jetzt ist das Problem das die Adressen

Putzhagen 22, 22a, 24, 56 und 62 auch auf die Zufahrt geschickt werden obwohl die damit nichts zu tun haben und auch die jeweiligen Hauszufahrten so wie sie denn existieren gemapped sind.

D.h. als option fallen aus

  • “access” tags - Wenn ich das mache wird auch für 22b die Hauszufahrt kaputt gemacht.
  • Weitere Hauszufahrten für die anderen Anwohner - da ist alles gemapped.

Ich habe jetzt als option versucht die Centroid bildung der Gebäudeoutlines zu überlisten und habe die Adressen auf Nodes verschoben um die Manuell positionieren zu können. (Näher an den richtigen Zufahrten)

Das wird für 24, 56, 58, 62 klappen so wie ich Kontrolliert habe (Änderung von eben - also noch nicht aktiv)

Für 22 und 22a wird das nicht klappen weil eben die Zufahrt zu 22b viel näher liegt.

Ideen?

Flo
PS: Es geht mir darum hier das Problem weiter zu Diskutieren - nicht das konkrete Beispiel zu fixen. Das Beispiel lässt sich mit dem aktuellen Datenmodell von OSM nicht fixen. Das ist einfach kaputt. Ich hatte ja mal die “Navaid” relation vorgeschlagen, die ja als “unnötig” abgeschmettert wurde, ohne für Probleme wie dieses eine Antwort zu haben.

Hm… Also an dem Beispiel von dir hätte ich es ggf. mit Darstellung der Zäune schon mal eine “visuelle” Unterstützung.
Ansonsten hilft es glaube ich nur, Zufahrten/Wege zusätzlich hinzuzufügen. Aber gleichzeitig müssen die Router sich vielleicht auch vom einfachen “Wir routen zum nächstgelegenen Punkt” bei Adressen etwas abwenden und der in der Adresse angegebenen Straße auch etwas an Gewicht geben…

Es gibt hier nicht mehr an Hauszufahrten als gemapped ist. 22 und 22a haben ihre Garagen direkt an der Straße stehen und nur einen Fußweg (Der für die Navigation per Auto nicht im Graphen ist und nicht in betracht kommt).

Und eine “andere Straße” nehmen ist doch auch nur verschieben des Problems. Produziert doch nur eine andere klasse Fehler. Und in diesem Fall ist ja die Straße sogar gleich. Es ist alles Putzhagen.

Und es ist ja auch nicht so einfach. Der “Router” KANN nur zu einem Punkt routen. Welches ist dieser Punkt? Wenn ich eine Adresse suche via Nominatim bekomme ich ggfs das Gebäudeoutline. Da kann man nicht hin routen. Ich brauche einen Punkt. Also wird über ST_Centroid der Geometrische Mittelpunkt des Outlines genommen und dann von diesem aus der nächstgelegene Punkt auf dem Straßennetz gesucht (Deshalb ist das bei der 24 Schief gegangen. Da war zwar das Gebäude näher an der eigenen Hauszufahrt, aber nicht der Gebäudemittelpunkt).

Deshalb hatte ich ja mal die “NavAid” relation vorgeschlagen bei der ich für ein OSM Objekt, wenn es angesteuert werden soll einen exakten Punkt definieren kann. Das wird dann für die 1-5% der Adressen/Objekte gebraucht bei denen das nicht automatisch zu finden ist.

Flo

Grundsätzlich müssen die Leute ja irgendwie zu ihrem Hauseingang kommen. Sprich es gibt Zufahrten, Fusswege und Eingänge. Denke es sollte in irgendeiner Form wenn diese gemappt sind, möglich sein die auch für das Fahrzeugrouting zu berücksichtigen (auch wenn diese nicht befahren werden können).

Aber auch das kann ja falsch sein. Stell dir vor die Hausnummer 22b hätte noch einen hinteren Garteneingang zur Herzebrocker Straße. Soll ich dann alle da hin routen? Die stehen dann immer an der Abgeschlossen Gartentür. Willst du das dein Besuch immer hinten am Gartentor steht?

Das verschiebt doch nur den Fehler in eine andere Richtung. IMHO bekommst du das Automatisiert nie für alle Fälle hin. Es braucht einen Mechanismus das “Explizit” zu definieren welcher der Navigationspunkt ist.

Flo

Adhoc hätte ich nur diese Ideen der Lösung, das so zu Lösen:

  1. Kennzeichnung der Grundstücke als Grundstücksfläche + entrace=main für den “Haupteingang” zum Grundstück
  2. Relation mit z.B. type=entrace die z.B. ein Objekt (area oder node) mit der Adresse (Gebäude, POI, etc.) mit einem Punkt zum Routing/Eingang verbindet. Änhlich wie entrace=* könnte man hier mit Rollen main, sencondary usw arbeiten und für ein Grundstück mehrere Eingänge definieren. Man könnte anhand der roles ggf. sogar die access-Typen unterscheiden (main_vehicle, main_foot, usw…)

Da 2. für z.B. Nominatim besser auswertbar wäre, würde ich sowas sogar eher bevorzugen. Müsste man ggf. ein Proposal draus machen und v.a. Nominatim auch dazu bringen, es auszuwerten…
V.a. das zweite lässt sich dann auch sehr gut mit einem Zaun/barrier koppeln. Dass dann das barrier=gate o.ä. als Option in der Relation wäre

Für eine generelle Lösung könnte ich mir vorstellen einen zweiten ‘addr’ Node auf die Grundstückszufahrt zu legen und einen neuen Tag ‘addr:=’ (* durch sinnvolle Namen ersetzen) hinzuzufügen. Der neue Tag soll den Node dann als vorgeschlagene Zufahrt definieren. Ein Router würde dann in der Umgebung nach diesem neuen Tag und der ausgewählten Adresse suchen und so die passende Zufahrt finden.

Das hätte den Vorteil, dass an dem bestehenden Tagging nichts geändert werden muss, weil ja meistens die aktuelle Methode ausreicht. Nachteil wäre natürlich, dass die Adressdaten doppelt eingetragen werden.

Edit: Wie oben bereits gesagt wäre wohl eine Relation und ein neuer Tag besser, der beschreibt, dass der Punkt auf der Straße die vorgeschlagene Zufahrt ist.

In der “navaid” relation Idee hatte ich das ja nochmal generischer angefangen - Ich glaube ich schreibe bei gelegenheit mal ein proposal.

Die Idee war auch so Dinge wie “Centro Oberhausen” oder “Flughafen Frankfurt” zu erschlagen.
D.h. es kann auch mehr als einen navaid für ein Objekt geben.

D.h. die relation sagt das wer zum Centro Oberhausen möchte die verschiedenen Parkplätze angeboten bekommt (In mode “car”) - Im modus “Zu Fuß” bekommst du die wirklichen Eingänge angeboten. Die können dann sogar noch Namen bekommen.

Wenn ich “Flughafen Frankfurt” suche will ich ja im Navi “Ankunft Terminal 1”, “Abflug Terminal 1”, “Ankunft Terminal 2” “Abflug Terminal 2”, “Parkplatz West 1”, “Parkplatz West 2” etc angeboten bekommen.

In diesem Fall nehme ich einfach das Haus mit der Adresse und einen Punkt auf der Straße und gut ist es. Keine Einschränkung der Modalität, Namen oder mehrere möglichkeiten.

So von der Idee …

Flo

Es gab ja mal im Karlsruhe-Schema type=roadAccess, weiß aber nicht ob das ausgewertet wird. https://taginfo.openstreetmap.org/relations/roadAccess

Routing nach den Halligen (!) ist auch tückisch ohne navaid: https://forum.openstreetmap.org/viewtopic.php?id=73711

Flo, ich würde dein Proposal unterstützen.

Cool - das kannte ich noch gar nicht. Ich tippe das es keiner verwendet oder auswertet. Selbst die “associatedStreet” relation ist ja gestorben.

Aber so in etwa stelle ich mir das vor.

Allerdings mit angaben zur modalität also Fuß/Fahrrad/Auto/ÖPNV - kann ja unterschiedlich sein, und eben noch “Namen” damit man ggfs mehrere solche relations da dran hängen kann die unterschiedliche Punkte haben und der User eine möglichkeit der Auswahl hat.

Flo

Klingt echt nice, kannte ich auch nicht. Deine Erweiterung lässt sich ja sicher auch einpflegen/-bauen. Also Lust hätte ich schon, das gemeinsam anzugehen :sunglasses:

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