Hauszufahrten - Falsch zugeordnet / Routing

flohoff wrote:

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.

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....

SafetyIng wrote:

flohoff wrote:

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.

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).

SimonPoole wrote:

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

flohoff wrote:

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.

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.

Thomas8122 wrote:

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

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

flohoff wrote:

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.

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 😎

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.

SimonPoole wrote:

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).

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 😉
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)

EinKonstanzer wrote:

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.

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

EinKonstanzer wrote:

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.

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. … 4&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/direction … 2&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

flohoff wrote:

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

https://www.openstreetmap.org/?mlat=51. … 4&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.

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

dieterdreist wrote:

flohoff wrote:

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

https://www.openstreetmap.org/?mlat=51. … 4&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.

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

flohoff wrote:

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.

chris66 wrote:

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

dieterdreist wrote:

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...

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- … .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.

flohoff wrote:

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

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

flohoff wrote:

EinKonstanzer wrote:

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.

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.

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... 😉
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, ...

EinKonstanzer wrote:

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.

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.

Mammi71 wrote:

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

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

dieterdreist wrote:

Mammi71 wrote:

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

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.

flohoff wrote:

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

https://silicon-verl.de/home/flo/tmp/20 … ffahrt.png

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.

PT-53 wrote:

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?

OSM_RogerWilco wrote:

PT-53 wrote:

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*

jengelh wrote:

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.

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.

EinKonstanzer wrote:

OSM_RogerWilco wrote:

PT-53 wrote:

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*

Das war meine Überlegung - Aber nicht begrenzt auf "Adressen" sondern beliebige OSM Objekte. Das macht immer Sinn wenn das OSM Objekt eine große Fläche ist. Industriegebiet, Großer Gebäudekomplex, Campingplatz, Flughafen etc und eben der Automatismus keine schöne Lösung findet.

Und das ein "Router weiterdenkt" ist vielleicht schön, aber es gibt immer fälle die anders sind, die der Automatismus maximal daneben liegt so das man dem Automatismus helfen muss.

D.h. mache eine relation mit

type=navaid
mode=car
name=Pforte␣Gfm.␣Rommel␣Kaserne␣Augustdorf

Roles:
destination␣<hier␣beliebige␣OSM␣Objekte>
final␣␣␣␣␣␣␣␣␣␣␣<OSM␣Node>

destination darf beliebig viele Objekte beinhalten. Also alle Gebäude des Bundeswehrstandortes, den Fußballplatz des Standortes was auch immer gefunden werden könnte um dorthin zu navigieren.

mode beschreibt den modus des transports, also sowas wie car, foot, bicycle, hgv und ggfs sowas wie "public transport" wäre auch denkbar. D.h. ich kann die beste Haltestelle markieren für einen POI.

name beschreibt den user visible namen der dann angefahren wird. Z.b. sinnvoll wenn ein objekt an mehreren Relationen hängt z.b. "Flughafen Frankfurt" hängt an den relationen für "Abflug Terminal 1", "Ankunft Terminal 1".

"final" enthält einen Punkt der dann angefahren werden soll - Und ja - Das MUSS ein Punkt sein. Sondern haben wir eine Rekursion.

name/mode sind optional.

Natürlich "name" auch mit extension "name:de" "name:en" - ist ja user presentable.

Flo

EinKonstanzer wrote:

OSM_RogerWilco wrote:

PT-53 wrote:

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.

In diesem Fall führt aber eine Straße direkt bis zum Haus. 😠
Bitte nicht Äpfel mit Birnen vergleichen! 🙄

flohoff wrote:

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

wie hast du den Parkplatz gemappt und dass er zu dem Haus gehört?

Für deinen Wunsch müsstest du dem Router beibringen, dass er dich zum (fußgängerroutingtechnisch) nächstgelegenen Parkplatz (oder potentiellen Parkplatz) bringt. Jemand anderes will ja vielleicht nur jemanden absetzen oder das Haus kurz von außen ansehen welche Farbe es hat, da ist ihm die andere Straße lieber, auch wenn sie nicht zu dem Haus „gehört“

dieterdreist wrote:

flohoff wrote:

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

wie hast du den Parkplatz gemappt und dass er zu dem Haus gehört?

Für deinen Wunsch müsstest du dem Router beibringen, dass er dich zum (fußgängerroutingtechnisch) nächstgelegenen Parkplatz (oder potentiellen Parkplatz) bringt. Jemand anderes will ja vielleicht nur jemanden absetzen oder das Haus kurz von außen ansehen welche Farbe es hat, da ist ihm die andere Straße lieber, auch wenn sie nicht zu dem Haus „gehört“

Das ist das regionale wissen das wir als mapper einbringen. Alternativ nimm den Parkplatz eines Supermarktes. Da ist es sehr offensichtlich.

Der Wunsch derer die dann zu dem Supermarkt routen ist zum Parkplatz zu kommen. Wie stellst du das sicher?

Flo

flohoff wrote:

Das ist das regionale wissen das wir als mapper einbringen. Alternativ nimm den Parkplatz eines Supermarktes. Da ist es sehr offensichtlich.

Der Wunsch derer die dann zu dem Supermarkt routen ist zum Parkplatz zu kommen. Wie stellst du das sicher?

Beim Supermarkt ist es genauso, vielleicht willst Du nur Deinen Freund abholen, der dort arbeitet oder einkaufen war? Wenn Du mit dem Auto einkaufen willst, ist der Parkplatz sicherlich angemessen. Ohne dass man es spezifiziert, kann der Router nur raten.
Wenn der Supermarkt als area gemappt ist, und der Parkplatz Teil davon ist, dann kann der Router es "einfach" bestimmen (außer es gibt mehrere Parkplätze, dann muss man wiederum entscheiden, zu welchem man will, das ist bei großen Geschäften wie Einkaufszentren, oder auch IKEA etc., oft der Fall.)

Ich vermute der Anspruch der Router ist derzeit, einen in die Nähe des Ziels zu bringen, und die letzten Meter erledigt dann Brain 1.0, aber wenn man wirklich bis zum Milchregal geführt werden will, dann muss natürlich auch gemappt sein, wo das Milchregal ist (wenn nicht, dann könnte der Router z.B. wissen, dass die Milch in Supermärkten normalerweise ganz hinten ist und mangels konkreter Daten dies als default annehmen). Das würde man im Moment aber wohl nichtmal von Google erwarten 😛

dieterdreist wrote:

Ich vermute der Anspruch der Router ist derzeit, einen in die Nähe des Ziels zu bringen, und die letzten Meter erledigt dann Brain 1.0, ...

Der Punkt ist aber das mit unseren Daten wir teilweise auch mal 10km daneben liegen. Du bekommst heute bei bestimmten Adressen eine Ansage "Sie haben das ziel erreicht" wenn noch eine Bahnlinie und der Mittelkanal dazwischen liegt und du das Ziel nicht einmal siehst. Und DAS bekommt Google besser hin.

Flo

flohoff wrote:

Der Punkt ist aber das mit unseren Daten wir teilweise auch mal 10km daneben liegen. Du bekommst heute bei bestimmten Adressen eine Ansage "Sie haben das ziel erreicht" wenn noch eine Bahnlinie und der Mittelkanal dazwischen liegt und du das Ziel nicht einmal siehst. Und DAS bekommt Google besser hin.

Ich gebe Dir da schon recht, ist mir auch schon öfters passiert, dass man auf einen Feldweg geschickt wurde, weil der dann dort wo er aufhört am nächsten am Zentroid des POIs liegt, obwohl man dort gar keinen Zugang hat, weil ein Zaun da steht. In erster Linie sehe ich da die Router in der Verantwortung, wenn Eingänge gemappt sind sollte man dorthin geleitet werden, bevorzugt zu entrance=main. Ggf. sollten auch Parkplätze eine Rolle spielen.

Google weiß vermutlich, wo der Eingang des Flughafens in Rom ist, auch ohne dass es in den Daten explizit gemappt sein muss (anhand der Bewegungsdaten der Menschen). Sobald man die Positionen eines Anteils der Menschen an einem Ort hat, dürfte es relativ einfach sein zu erkennen, dass die Route die OSM vorschlägt nicht funktionieren kann, obwohl man das als Mensch auch so auf einen Blick erkennen kann, wo wird wohl der Eingang sein, an der Autobahnzufahrtsschleife um den Bahnhof, umringt von Terminalgebäuden, oder am Ende der Landebahn auf der Tertiarystraße ohne Verbindung von der Straße zum Flughafen:

https://www.openstreetmap.org/direction … %2C12.2269

Zu Fuß sind es von dort noch 7km zum Flughafen...
https://www.openstreetmap.org/direction … %2C12.2508

dieterdreist wrote:

In erster Linie sehe ich da die Router in der Verantwortung, wenn Eingänge gemappt sind sollte man dorthin geleitet werden, bevorzugt zu entrance=main. Ggf. sollten auch Parkplätze eine Rolle spielen.

Und wenn ein kompliziertes Objekt keinen Eingang hat? Oder 10?
Wo möchtest du denn bei deinem Beispiel explizit entrace=main hinsetzen? Irgendwie muss man dem Router ja dann eine Hilfe geben. Ja z.B. Google wird das sicher irgendeine KI machen 😉 Ich wüsste nicht, wo wir aber so viele Bewegungsdaten wie Google bekommen würden.....
Also muss sowas für entsprechende Objekte speziell geregelt werden.... Auch dein Beispiel Parkplatz hätte da wahrscheinlich nichts gebracht. Da wäre man wahrscheinlich in Focene am Strand gelandet.....

dieterdreist wrote:

flohoff wrote:

Der Punkt ist aber das mit unseren Daten wir teilweise auch mal 10km daneben liegen. Du bekommst heute bei bestimmten Adressen eine Ansage "Sie haben das ziel erreicht" wenn noch eine Bahnlinie und der Mittelkanal dazwischen liegt und du das Ziel nicht einmal siehst. Und DAS bekommt Google besser hin.

Ich gebe Dir da schon recht, ist mir auch schon öfters passiert, dass man auf einen Feldweg geschickt wurde, weil der dann dort wo er aufhört am nächsten am Zentroid des POIs liegt, obwohl man dort gar keinen Zugang hat, weil ein Zaun da steht. In erster Linie sehe ich da die Router in der Verantwortung, wenn Eingänge gemappt sind sollte man dorthin geleitet werden, bevorzugt zu entrance=main. Ggf. sollten auch Parkplätze eine Rolle spielen.

Aber dieses Nebulöse "das muss der Router halt Lösen" ist ja genau das Problem.

Wie?

Ich habe hier ja diverse Beispiele gezeigt und es gibt keinen Automatismus der alle die Dinger löst. Es bleibt bei jedem Automatismus ein Bodensatz an dingen die er nicht Lösen kann, wie kriegen wir die zur "Userzufriedenheit" geregelt?

Flo

SafetyIng wrote:

Und wenn ein kompliziertes Objekt keinen Eingang hat? Oder 10?
Wo möchtest du denn bei deinem Beispiel explizit entrace=main hinsetzen? Irgendwie muss man dem Router ja dann eine Hilfe geben.

ein Objekt ohne Eingang das gleichzeitig kompliziert ist, das möchte ich sehen 🙂

angenommen, man will zu einem Badesee, da könnte z.B. ein Weg oberhalb einer Abbruchkante über dem See verlaufen, aber ohne dass man hinkommt, und ein anderer an einer Wiese über die man an den See kommt, verbunden sein. In solchen Fällen wäre es am Besten, der Router würde einem den Zielbereich anzeigen und man könnte vorgeben, wo man hinwill. Im Endeffekt muss man sich ja sowieso das Ziel immer ansehen, weil man sonst riskiert, dass man sonstwohin geschickt wird.

SafetyIng wrote:

Ja z.B. Google wird das sicher irgendeine KI machen wink Ich wüsste nicht, wo wir aber so viele Bewegungsdaten wie Google bekommen würden.....
Also muss sowas für entsprechende Objekte speziell geregelt werden.... Auch dein Beispiel Parkplatz hätte da wahrscheinlich nichts gebracht. Da wäre man wahrscheinlich in Focene am Strand gelandet.....

die einzigen in unserem Umfeld die mir spontan einfallen, wo Bewegungsdaten in großem Maß anfallen, sind Mapbox und evtl. maps.me. Mit Bewegungsdaten wird es aber auch kompliziert, und die Suchanfragen wären sicherlich zusätzlich hilfreich. Wenn mehrere Publikumsmagneten in der Nähe liegen gibt es vermutlich noch selbstsame Wechselwirkungen. Selbst wenn man das alles hätte, dann wäre es trotzdem nur "raten" mit Hilfsmitteln. Gut gemacht würde es bestimmt in der Regel super funktionieren, aber eigentlich wollen wir doch versuchen die Daten so gut zu machen, dass es direkt oder indirekt mit hoher Wahrscheinlichkeit ablesbar ist.

Auf Routerseite könnte man z.B. je nach Typ unterschiedliche Heuristiken anwenden. Bei einem Flughafen will man normalerweise ans Terminal. Genauer gesagt interessiert meist auch, ob man zum Abflug oder zur Ankunft will (und klar, es gibt noch mehr Parameter, wenn man sowieso für Flughäfen eine Extrawurst brät könnte man z.B. auch fragen: Langzeitparken oder Kurzparken/Halten, etc.). Niemand will an den Zaun neben dem Rollfeld, oder nur die, die das auch ohne Router finden 😉 D.h. der Router müsste bei einem Flughafen eigentlich fragen: Ankunft oder Abflug, ggf. auch das Terminal (oder idealerweise eigentlich die Flugnummer, dann findet er den Rest allein, aber das wäre wohl Wunschkonzert) und einen dann zum Zugang dieses Terminals bringen. Oder er würde die Terminals die er dort kennt als Auswahl anbieten.

Wo es einen expliziten Übergang gibt, erwartet man einen der tags barrier=gate, barrier=*_gate ,barrier=entrance, entrance=*
Eigentlich will man immer zum Eingang oder Zugang wenn es einen gibt, wenigstens diese Fälle könnte man lösen.
Problem bei komplexen POIs ist oft, dass es einen Perimeter für den ganzen POI gibt, das sinnvolle Ziel aber Punkte auf Gebäuden oder Gebieten innerhalb des POIs sind, z.B. Ticketoffice, Supermarkteingang für die Kunden (und nicht der Personaleingang, Notausgang oder Warenanlieferung), Terminal bei Flughäfen, Eingang nahe des Gleises wo man hinwill bei Bahnhöfen, ...
Bei komplexen POIs ist das Problem öfters, dass es drauf ankommt was man dort vorhat, bzw. wo genau man innerhalb des POIs hinwill, um festzustellen wo man sinnvollerweise hinroutet. In solchen Fällen sollte der Router am besten noch mal mehr oder weniger ausgefeilt nachfragen. Bei mehreren POIs hilft dann auch "navaid" nur insofern, als es beitragen könnte, die Rückfrage besser zu machen.

flohoff wrote:

ch habe hier ja diverse Beispiele gezeigt und es gibt keinen Automatismus der alle die Dinger löst. Es bleibt bei jedem Automatismus ein Bodensatz an dingen die er nicht Lösen kann, wie kriegen wir die zur "Userzufriedenheit" geregelt?

solche Probleme wie Fluss dazwischen könnte man dadurch verbessern, dass man im Anschluss an das Fahrzeugrouting von dem Endpunkt noch ein Fußgängerrouting zum angefragten POI macht. An dessen Länge könnte man ggf. erkennen, ob was nicht hinhaut. Geht natürlich nur, wenn man die Fußwege entsprechend gemappt hat.

dieterdreist wrote:

flohoff wrote:

ch habe hier ja diverse Beispiele gezeigt und es gibt keinen Automatismus der alle die Dinger löst. Es bleibt bei jedem Automatismus ein Bodensatz an dingen die er nicht Lösen kann, wie kriegen wir die zur "Userzufriedenheit" geregelt?

solche Probleme wie Fluss dazwischen könnte man dadurch verbessern, dass man im Anschluss an das Fahrzeugrouting von dem Endpunkt noch ein Fußgängerrouting zum angefragten POI macht. An dessen Länge könnte man ggf. erkennen, ob was nicht hinhaut. Geht natürlich nur, wenn man die Fußwege entsprechend gemappt hat.

Puh - ich habe das Gefühl wir fangen in diesem Thread wieder oben an. Ein Fußweg hilft dir bei car routing NULL. Er ist eher irreführend und produziert andere Fehler (Siehe meine Zeichnung weiter oben). Es ist einfach nur das verschieben des Problems woanders hin. Es löst es aber nicht.

Flo

ich kann Dir nicht folgen. Du willst ja beim Carrouting wenn ich das richtig verstanden habe nicht nächstmöglich ans Haus, sondern den nächstgelegenen Parkplatz finden. Weil das nicht immer so ist, wird man irgendwo nochmal nachfragen müssen, was Du willst, bzw. wirst Du es per Voreinstellung mitteilen müssen, oder es ergibt sich vielleicht aus der Analyse der Daten, die bereits von dem Nutzer gesammelt wurden, was er vermutlich meint...

dieterdreist wrote:

ich kann Dir nicht folgen. Du willst ja beim Carrouting wenn ich das richtig verstanden habe nicht nächstmöglich ans Haus, sondern den nächstgelegenen Parkplatz finden. Weil das nicht immer so ist, wird man irgendwo nochmal nachfragen müssen, was Du willst, bzw. wirst Du es per Voreinstellung mitteilen müssen, oder es ergibt sich vielleicht aus der Analyse der Daten, die bereits von dem Nutzer gesammelt wurden, was er vermutlich meint...

So eindimensional ist das nicht. Ja - Normalerweise möchte ich möglichst nah ans Haus. Aber wenn das Nächstgelegene eine Autobahn ist, dann vielleicht doch nicht. Der Fall wäre ja noch einfach (Für Deutschland, in anderen Ländern darf ich auch auch der "Autobahn" parken). Aber vielleicht ist ja das Nächstgelegene (Mit oder ohne Fußweg) auch eine Primary - Ohne Standstreifen, wo ich gar nicht parken kann - und dann? Und dann gibt es vielleicht eine dem Haus zugeordneten Parkplatz, der ist aber ggfs weiter weg als die Primary. Wie kann ich das dem Automatismus beibringen? Funktioniert die regel in jedem fall?

Es ist nur eins von vielen Beispielen. Dieses "Da muss der Router sich drum kümmern" ist halt das typische "And here something magic happens".

Deshalb - Schreib in Pseudocode auf wie du dir den Entscheidungsbaum denkst und ich suche dir 10 Stellen auf der Karte wo es schief geht. Die Realität ist viel komplizierter als das ein "one size fits all algorithm" das Lösen kann. Deshalb der Wunsch nach einer möglichkeit es explizit zu setzen.

Flo

dieterdreist wrote:

ein Objekt ohne Eingang das gleichzeitig kompliziert ist, das möchte ich sehen smile

Das Beispiel hast du doch schon gebracht - der Flughafen! Das Flughafengelände an sich hat keinen Eingang per-se. Es hat sehr viele. Und auf die Außenlinie des Flughafens kannst du halt auch keinen entrace=main irgendwo hinklatschen.
Denn was gehört denn alles zum Flughafen? Nur die internationale Zone? Die Parkhäuser aber nicht usw.....

SafetyIng wrote:

dieterdreist wrote:

ein Objekt ohne Eingang das gleichzeitig kompliziert ist, das möchte ich sehen smile

Das Beispiel hast du doch schon gebracht - der Flughafen! Das Flughafengelände an sich hat keinen Eingang per-se. Es hat sehr viele. Und auf die Außenlinie des Flughafens kannst du halt auch keinen entrace=main irgendwo hinklatschen.
Denn was gehört denn alles zum Flughafen? Nur die internationale Zone? Die Parkhäuser aber nicht usw.....

die Terminals haben allerdings klare Eingänge. Bei Riesengeländen kommt es schon mal vor, dass es viele Eingänge gibt, z.T. sogar auch weit voneinander entfernt. Bei großen Fabriken ist das auch der Fall. Aber dort haben die Eingänge/Zugänge in der Regel Nummern. Blöd ist halt, wenn der "Sonderbau" (z.B. Flughafen) keine Hausnummer/n hat.