x

Hauszufahrten - Falsch zugeordnet / Routing


Geschrieben von flohoff (Gast) am 13. September 2021 11:19:30: [flux]

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.


Antworten: