um es bildlich auszudrücken (siehe unten): Ich möchte gerne beim Routing die Straßenseite an einem Knoten wechseln. Das braucht man z.B. beim Rollstuhlrouting. Rolli-Fahrer können Bordsteine nur schwer überwinden und brauchen somit abgesenkte Bordsteine um die Straße queren zu können.
Beim attributiven Datenhaltungsystem werden an das Hauptelement (z.B. Highway = tertiäry) die Attribute (z.B. sidewalk = both) zugeordnet.
Die Frage ist jetzt: Kann ein existierender Routinealgorithmus (z.B. pgRouting) “erkennen” das eine Straßenquerung am Straßenknoten P1 (mit dem Attribut: “sloped_curb = yes” abgesenkter Bordstein) genutzt werden muss, weil bei P2 keine abgesenkten Bordsteine vorhanden sind?
Es wäre schön, wenn mir jemand helfen könnte!
Gruß Nico
oP3 (Ziel)
^|
^|
^|highway=tertiary; sidewalk = left
^|
^|
P0 (Start) ^>>>>>>>>>>>>>>>>>>>>>^|
o------------------^o--------------------------------------o--------------------highway=tertiary; sidewalk = both
Zusammenfassung: Ja, sowas geht, aber in der Praxis eher nicht gut, weil eben diese Querungen selten gemappt sind. Dein grösstes Problem wird sein, dass Du erst mal das Routing auf einer Strassenseite implementieren musst, bevor du die Strassen querst. Das Anlegen dieser parallelen Wege ist zeitaufwändig und gerade bei Kreuzungen mit vielen Mutmassungen (unten im Text bei “Probleme”) verbunden… Wenns mehr als ein “schaut mal, was ich kann” werden soll, hast echt viel Arbeit vor dir
Mit pgrouting vorführbar ist es nur auf einer kleinen Teststrecke: Hier wird der Fussgänger mit Umweg zur Ampel geführt und da wird die Kreuzung etwas eigenartig überquert, weil der westliche Zweig der Kreuzung keine passende Querung hat. In allen anderen Gegenden gehts höchstens zufällig, weil ich besondere Übergänge nicht besonders belohne: Hier wird die Blumenstr. an dieser Kreuzung überquert, aber nur weil es kein Umweg bedeutet gegenüber einer Querung irgendwo entlang dieser Strasse.
Danke für die ausführliche Antwort. Allerdings verstehe ich das Ganze noch nicht richtig.
Mein Projekt befasst sich mit dem Routing mobilitätseingeschränkter Personen (z.B. Rollstuhlfahrer). Diese Personengruppe kann Straßen nicht einfach, an einer beliebigen Stelle überqueren. Deshalb sind keine “virtuellen” Querungen (10m Abstand) notwendig. Die Straße kann nur überquert werden, wenn die baulichen Gegebenheiten (abgesenkter Bordstein auf beiden Seiten der Straße) vorhanden sind.
Bei getrennt gemappten Bürgersteigen (linke Seite und rechte Seite einer Straße) würde an der Stelle der Absenkung ein Knoten gesetzt und mit highway=crossing; crossing=unmarked (bei Ampeln: highway=crossing; traffic_signals). Muss man dies dann auf der anderen Seite auch tun?
Muss man einen “virtuellen” Weg über die Straße legen und beide Bürgersteige verbinden? Wenn ja, welche Bezeichnung (highway = crossing) gibt man dem?
P.S. Es gibt ein Untersuchungsgebiet, in dem ich alle Querenden selbst erfassen und bezeichnen kann.
Richtig, die zusätzlichen Wege an beliebigen Stellen kannst du dir sparen. Ich hab die drin, weil ich einen Router für sportliche Fussgänger machen wollte. Nur an ein paar Stellen ist er eben auf “seniorenfreundlich” getrimmt, damit ich das auch testen kann.
Nein, da würde ich dem 5-Meter-Stück Weg über die Strasse diese Attribute geben. Wie man die Bordsteinabsenkung mappt, weiss ich nicht. Fürs Routing würde ich sie bei Gewichtung des Wegstückes berücksichtigen. Entweder viele Strafpunkte für hohe Kanten oder den Weg rauswerfen, wenn die Stufe den Weg unpassierbar macht.
Bei sidewalk=leftrightboth ist die Strassenquerung ja zu einem Punkt zusammengeschrumpft. Der virtuelle Weg ist nur nötig um die beiden ebenfalls virtuellen Wege links und rechts der Strasse zu verbinden. Bei mir hat der im Routinggraphen keine attribute wie “highway” oder “crossing”. Es ist einfach ein fürs Routing berücksichtigter Weg. Ich flicke diese Wege nach dem osm2po-Import in die Routingtabelle von pgrouting ein, deshalb interessiert mich nur noch Länge und Gewichtung.
Brauchst Du auch, sonst stoppst du schon an der nächsten Ecke ;). So grob gesagt sind Mapper, die Kreuzungen mit allen möglichen Attributen eintragen auch Mapper, die Gehwege getrennt von der Strasse eintragen. Mapper, die sidewalk=* benutzen, kümmern sich mal um Ampeln oder Zebrastreifen, selten um abgesenkte Bordsteine.
Grüße, Max
PS: Den ganzen Blödsinn mit virtuellen Querungen, braucht man nur, wenn man auch virtuelle parallele Wege macht. Mir fiel nichts besseres ein, aber vielleicht kommst du oder jemand anderes hier auf kreativere und elegantere Lösungen. Im Prinzip brauch man ja keine Geometrie des Gehweges, es würde reichen, dem Router das Konzept “links/rechts von einem Hindernis, das nur an bestimmten Stellen unterbrochen ist” beizubringen…
Leider kann man kerb=* nicht einer bestimmten Seite des Weges zuweisen. Solange die abgesenkten Bordsteine gegenüber liegen ist das kein Problem. Aber wenn nur auf einer Seite ein abgesenkter Bordstein ist und auf der anderen Seite ein normal hoher Bordstein gibt es Probleme.
^>>>>>>>>>>>>
--------------|_--------------- Das könnte bei Zebrastreifen oder alten Ampeln sein.
|
Ich habe mir die das Ganze angeschaut. Das löst das Problem mit gegenüberliegenden abgesenkten Bordsteinen soweit auch auf.
Wie würde man aber Situationen mappen, in dem ein Straßenüberweg nur auf einer Seite einen abgesenkten Bordstein hat?
^>>>>>>>>>>>>
--------------|_--------------- Das könnte bei Zebrastreifen oder alten Ampeln sein.
|
Mal eine Folgeanfrage zu meinem Problem: Wie “erklärt” man dem pg_routing welche Wege zum roten erlaubt sind und wo die Straße gereizt werden darf? Gibt es dazu irgendwo eine Website oder ein Paper?
Dann ist dort kein “Überweg” - nur eine Verbindung zur Straße (Grundstücksausfahrten).
Was soll den solch ein “Überweg” bringen - das ist wie das Wechseln über den Bordstein.
Soweit wie ich es verstanden habe, setzt kerb=* ein parallel zu Straßen erfasstes Fußwegenetz vorraus… http://wiki.openstreetmap.org/wiki/Proposed_features/kerb, kerb=lowered würde dann als node an der Stelle der Bordsteinabsenkung erfasst.
Eine entsprechende Unsetzung dieser Geschichte bei attibutiver Fußwegerfassung stelle ich mir schwierig vor, eventuell ginge es mit kerb:left=* und kerb:right=* aber ich weiß nicht, ob sich einer dazu schon Gedanken gemacht hat…
Ich weiss nicht, wie du importierst. Ich nehme osm2po, allerdings baue ich die Tabelle aus Gründen der Tradition ins Schema von osm2pgrouting um.
Wege die garantiert nicht zum Routen verwendet werden sollen, löscht man einfach. Da die originale ID von osm erhalten bleibt, kann man die einfach mit “delete from routinggraph where id=” rauslöschen.
Wie “gerne” man die Wege verwendet bestimmt man mit einer Angabe von Kosten. Heisst bei mir “costfactor” und wird zum Routenberechnen einfach mit der Länge multipliziert. Ich lese “costfactor=1.5” immer als “15 Meter auf diesem Weg sind so mühsam wie 10 Meter auf einem normalen Weg”. Holprige Wege wären für deine Zielgruppe z.B. costfactor=20 (=“lieber 100m zur Ampel und 100m zurück als hier 10m mühsam über Bordsteine klettern”). Oder man kann die Wege ganz löschen, wenn die Passage “unendlich mühsam” ist.
Lösche lieber nicht zu viel und arbeite lieber mit hohen Kosten. Kann sein, dass du da noch viel justieren musst. Viele Wege und hohe Kosten machen die Berechnung zwar langsamer, aber das justieren einfacher als jedes Mal neu importieren.
Ich kenne nichts dazu. Ich habs mir halt irgendwie zusammengestöpselt mit viel rumprobieren und viel starren auf virtuelle Wege. Das undokumentierte, ineffiziente und wirre Programm dafür passt aber halt nur bei mir, deine Datenbank wird anders aussehen…
Grüße, Max
PS: Mal so als Alternative zu virtuellen Gehwegen in den Raum geworfen. Ein linksseitiger Gehweg an einer unüberquerbaren Strasse bedeutet auch einfach nur ein Rechtsabbiegeverbot für jemanden der da entlang läuft. Der Router müsste nur erkennen, dass der Nutzer auf der linken Seite geht und dann schnell ganz viele Abbiegeverbote vor ihm aufstellen… Details (z.B. Zieladresse liegt am Weg, aber auf der faschen Seite) wären natürlich noch zu klären, Code wäre noch zu schreiben
Nur als Information: Ich versuche das zum ersten mal und habe (zum jetzigen Zeitpunkt) noch keine Datenbank. Ich bin gerade dabei einen Objektkartenkatalog zu erstellen, der alle Objekte (Schlüssel+Werte) enthält die genutzt werden sollen.
Der nächste Schritt wird sein, dass ich die Daten in meinem Untersuchungsgebiet überarbeite. Fehlende und falsche Objekte erfassen und in die OSM DB hochlade.
Danach soll im Testgebiet gerostet werden. Leider habe ich aber verschiedene Nutzergruppen (Rollstuhlfahrer, gehbehinderte Menschen, Kinder, usw.), die unterschiedliche Routingprofile erfordern. Deshalb fällt ein bestehender Onlinedienst weg. Die Nutzerprofile finden sich dort nicht wieder (außer eventuell Rollstuhlfahrer). Ich muss also selbst einen Router betreiben.
Leider habe ich nur eine vage Vorstellung wie das funktioniert.
Mir ist klar, dass ich die OSM Daten in eine eigene Datenbank überführen muss. Dazu nutzt man Tools (z.B. osm2po). Mit Datenbanken kenne ich mich einigermaßen aus und weis wie man z.B. Abfragen macht.
Leider ist mir der Rest noch nicht ganz klar. Wie setzt man einen Router auf die Datenbank auf und wie trägt man die Kosten ein?
Ich würde mir einfach mal osm2po installieren und mit den Strassentypen dort spielen. Das braucht ja erst mal keine Datenbank, sondern liest osm-Dateien und läuft dann einfach als fertiger Dienst mit Karte und Streckeneingabe auf einem Webserver. Kosten gibts dort nicht, aber in der osm2po.config gibts die “kmh” und diese Geschwindigkeit kann man einfach als Kehrwert der Kosten sehen. Minimiert wird Weg/Geschwindigkeit statt Weg*Kosten. Barrieren soll man dort auch einbauen können, sagt die Doku. Vielleicht kann man Randsteine für manche Zielgrupen als solche betrachten. Rotingprofile gibts dort auch, statt car/bike/foot kannst ja Gehstock/Rollator/Rollstuhl nehmen und Treppen für letztere sperren und für die ersten beiden sehr langsam machen.
Wenn das funktioniert, kann man sich Gedanken über eine Datenbank machen (postgis) und pgrouting installieren. osm2po muss dann nicht mehr routen, sondern nur noch importieren. Mit Datenbank und pgrouting kannst du die einzelnen Wege dann weiter manipulieren ohne jedes Mal neu zu importieren.
Aber: pgrouting ist sehr exotisch und der Preis der Bastelfreude ist eine gewisse Trägheit. Man braucht auch keine Datenbank, um einen Router zu betreiben. graphhopper und brouter routen auch gut, haben schon Möglichkeiten, z.B. surface=* zu berücksichtigen und hilfsbereite Entwickler. Für diese Router müsstest Du allerdings Wege finden, eine OSM-Datei zu manipulieren, um zusätzliche Gehwege und Querungen einzubauen. Habe ich nicht gemacht, weil ich keine Lust/Fähigkeit/Wissen hatte, mir die ganzen Funktionen von postgis (“mach eine Parallele zu diesem Weg”, “welche Objekte überquert dieser Weg?” …) neu zu schreiben.
Falls Dir das gelingt oder eine schöne Bibliothek dafür findest, wärst Du ohne Datenbank besser dran. Diese manipiulierte OSM-Datei kannst Du dann nämlich sämtlichen Routern im OSM-Umfeld geben, einschliesslich pgrouting, und den geeignetsten davon nehmen. Andere hätten auch mehr davon, weil sie dein Programm auch für ihre Router nehmen könnten.
vielen Dank für Deine Hinweise. Ich habe mir gerade osm2po angeschaut. Es macht genau das was ich brauche.
Jetzt verstehe ich auch den Unterschied zur Datenbank.
Vielen Dank dafür!
