[Talk-de] Reisezeiten (was: Potlach! *kotz*)

Bernd Raichle bernd at dante.de
Mo Jan 28 10:14:31 UTC 2008


Hallo,


on Sunday, 27 January 2008 17:09:03 +0100,
qbert biker <qbert1 at gmx.de> writes:
 > > Jupp, auch die GDF-Daten der beiden Grossen lassen von der "Functional
 > > Road Class" nicht direkt auf Geschwindigkeiten bzw. Reisezeiten
 > > ableiten, da die FRC nur etwas die Wichtigkeit der Strasse im
 > > Gesamtnetz aussagt.  Wo also kaum Autobahnen sind, wird auch eine
 > > eigentlich untergeordnete Strasse fuer eine Verbindung wichtig.  Nur
 > > zusammen mit anderen Attributen (Form-of-Way, innerorts vs.
 > > ausserorts, Kurvigkeit, Anzahl Kreuzungen etc.) bekommt man gute
 > > Kanten-Reisezeiten.
 > 
 > Stimmt und deshalb geht mein Vorschlag dahin, ein paar Attribute
 > einzuführen, die im Gegensatz zu 'highway' einigermassen exakt 
 > definiert sind und sich mit diesen Punkten beschäftigen. 

'highway' ist IMHO genau genug definiert, denn als Anfaenger kam ich
mit der Beschreibung auf der englischen bzw. der deutschen Wiki-Seite
ganz gut zurecht ... auch weil ich die in dieser Liste immer wieder
hoch gekommene _administrative_ Zuordnung ignoriert habe (die gehoert
IMHO in's "ref"-Tag bzw. einem weiteren noch nicht beschriebenen Tag
wie "ref_admin_level" o.ae.).  Aehnlich wie in GDF die Functional-
Road-Class (FRC) ist "highway" halt auch ein Kuddelmuddel und
schwammig ... man vergleiche nur mal die FRC-Einordnung der beiden
grossen Kartenhersteller miteinander, die sind sich auch nicht immer
einig!

Ok, aber welche Attribute willst du denn genau, die ein Routing mit
brauchbaren Ergebnissen erst ermoeglichen sollen?


 > Ich baue keinen Router auf der highway-Info auf, weil ich nicht
 > weiss, was sich der Mapper bei seinem Eintrag gedacht hat. Die
 > statische Reisezeit (ohne Staus, etc.) wird ganz wesentlich von 
 > drei Bedingungen beeinflusst: Ausbau, Vorfahrt und Restriktionen
 > wie Geschwindigkeitsbeschränkungen. Kurvigkeit ist eine ganz
 > spezielle Geschichte und geht ja direkt aus dem Verlauf hervor.

In den GDF-Daten finde ich weder Ausbauzustand, noch Vorfahrt, noch
Geschwindigkeitsbeschraenkungen _flaechendeckend_ vor.  Wieso koennen
dann alle Router/Navis darauf brauchbar routen?

In den im Markt befindlichen Releases sind Speed-Limits nur fuer die
Hauptverkehrsstrassen aufgenommen, alle anderen werden aus der
Inner-/Ausserorts-Beziehung abgeleitet (sprich: 50 bzw. 100 in D).
Vorfahrts-Beziehungen sind nur vereinzelt vorhanden.  Ausbauzustand
gibt's neben den FRC und getrennte Richtungsfahrbahnen direkt nur ein
"paved"/"unpaved".


Was braucht man zum Routen?  Zum einen eine Optimierungsfunktion, die
fuer die schnellste Route eben die aufsummierten Kanten-Reisezeiten
minimiert.  Zum anderen fuer jede Kante eine Reisezeit ... und genau
die kann ich mit ein paar Heuristiken, sprich angenommenen
Geschwindigkeiten aus den vorhandenen GDF-, aber auch aus den
vorhandenen OSM-Attributen und -Relationen mir erstellen.  Dazu gibt
der FRC bzw. "highway" aber nur eine erste Grobklassifikation, die
aber durch andere Attribute wie "oneway" (deutet bei langen Kanten auf
getrennte Richtungsfahrbahnen hin), "maxspeed" (daraus bekommt man
momentan ausserorts, innerorts, 30er-Zone), "roundabout" und Dingen
wie kurze Kantenstuecke/viele Kreuzungen (mit/ohne Ampeln), Kreuzungen
mit "*_link" etc. ganz gut ergaenzt einem eine Durchschnitts-
geschwindigkeit ableiten lassen, die gut genug zum Routen ist!



 > Im derzeitigen Zustand der Karte findet der Router wichtige
 > Verkehrsbeziehungen nicht, weil sie aus der administrativen
 > Zuordnung nicht hervorgehen. Ein schönes Beispiel ist die
 > Umgehung von Rosenheim (OBB). Die ist derzeit als secondary
 > drin und war schon mal tertiary. Damit ist sie nicht mehr 
 > aus dem normalen Hauptstraßengewirr herausgehoben und der 
 > Router schickt die Leute auf dem kürzesten Weg durch die 
 > Stadt, also mitten durch den Rummel mit vielen Ampeln.

Dann ist die Ableitung deine Kantengewichte (sprich
Kanten-Reisezeiten) schlecht.  Die Umgehungsstrasse (du meinst du ihm
Sued-Osten?) hat kaum Kreuzungen, und selbst die sind per
"oneway"-Verbindungen also Auffahrten angelegt, ausserdem sollte sie
ein entsprechendes "maxspeed"-Tag besitzen, das mit einem Wert >>50
km/h eine Ausserorts-Klassifizierung zulaesst.  Damit sollten die
Reisezeiten hierauf entsprechend kleiner sein, so dass die
inneroertlichen Strassen beim Routing schlechter abschneiden.  Wo
liegt da das Problem? ... ausser dass man halt etwas Hirnschmalz in
eine passende heuristische Zuordnung von Kanten- Durchschnitts-
geschwindigkeiten legen muss.  Aber dies _muss_ man bei einer GDF-
Karte (und auch bei den AND-Karten) auch tun.

Eine Heuristik a la ``ich bleibe zuerst auf der Strasse mit "hoeherem"
"highway"-Tag'' fuehrt einen auf alle Faelle in die Irre, da ich dann
in deinem Beispiel zuerst mal von Sueden her kommend auf der B15 bis
zum Eisstadion und evtl. noch weiter durchfahren werde, so dass ich
dann bereits in der Stadt bin.


 > Alles was ich will ist, dass der Mapper (und damit auch ich ;)) 
 > ein Werkzeug an die Hand bekommt um auf die Straße zu schauen 
 > und die in OSM beschreiben: Das ist eine etwas breitere 
 > Kreisstraße die in diesem Bereich kreuzungsfrei ausgebaut 
 > ist und sehr verkehrswichtig ist.
           ^^^^^^^^^^^^^^^^^^^^

Mmmh, wie klassifizierst du so etwas?  "verkehrswichtig={1,2,3,4,5}"?
Die eine Strasse ist verkehrswichtiger als die andere? ...

 >                                   Solange er sich entscheiden 
 > muss, ob der jetzt trunk, secondary oder tertiary ist und 
 > jeweils wichtige Detailinfo auf der Strecke bleibt, ist das 
 > Verfahren suboptimal.

... und dann bist du auch bei "highway={primary,secondary,tertiary}".


 > Im Fall der Umgehung von Rosenheim bedeutet die derzeitige
 > Einordnung, dass alle Routen die Rosenheim queren nicht die
 > sind, die ein Anwender erwartet, der auf schnellstem Weg 
 > weiter will. Kleine Ursache, grosse Wirkung.
 > 
 > Konkreter Vorschlag:
 > highway bleibt secondary
 > frc beschreibt die Wichtigkeit und
 > divider beschreibt die kreuzungsfreiheit.

"highway" und "FRC" sind nicht so unterschiedlich, solange du die
"highway"-Klassen nicht disjunkt betrachtest, sondern als sich
ueberschneidend, d.h. zusammen mit anderen Attributen kann eine mit
"tertiary" getaggte Strasse auch "wichtiger" werden lassen als eine
mit "primary" getaggte Strasse.  Und auch ein neues "FRC"-Tag fuer die
"Wichtigkeit" ist schwammig ... und bislang habe ich noch niemanden
eine saubere, eindeutige FRC-Klassifikation gesehen.

... und bislang diskutieren wir in dem Thread die ganze Zeit implizit
nur ueber Auto-Routing.  Fuer's Fahrrad oder zu Fuss werden ganz
andere Dinge wichtig, die bislang in OSM auch nur ansatzweise getaggt
und damit vorhanden sind.


 > > Die von einem Router berechnete Gesamtreisezeit wird ueblicherweise
 > > nur einige Prozent von der real benoetigten Reisezeit abweichen,
 > > solange man keine Staus und andere Stoerungen hat.  Will man bessere
 > > Werte, d.h eine geringere Abweichung muss man so oder so dynamische
 > > Reisezeiten verwenden, d.h. zumindest tageszeitabhaengige Ganglinien,
 > > um so die ueblichen Pendlerstroeme mit einzubeziehen ...  so wie dies
 > > auch (alle? die meisten?) aktuellen Router/Navis machen.
 > 
 > Na ja, über die Qualität des dynamischen Routings kann man sich
 > streiten. Da ist wohl auch bei den grossen mehr Schein als Sein.

Der Unterschied zwischen statischen und tageszeitabhaengigen
Reisezeiten ("Ganglinien") sind zumindest im belasteten
Kfz-Strassennetzen wie hier in D wichtig ... und es macht schon etwas
in der Akzeptanz aus, ob ich in der Nacht auf einer Strecke 30min und
tagsueber eher 45min als Gesamtreisezeit angezeigt bekomme und
vielleicht noch etwas anders geroutet werde.  Und hier rede ich nicht
einmal von aktuellen dynamischen Daten wie TMC oder direkte aktuelle
Kanten-Reisezeiten.

 > Statistische Verfahren funktionieren so la la und die direkte
 > Ableitung aus den Verkehrsmessgrößen (Induktionsschleifen/'Ufos')
 > ist auch nicht viel besser.

Komisch, auf der einen Seite willst du viel detaillierte (statische)
Infos fuer Strassen, auf der anderen Seite zweifelst du dann in diesem
Punkt an statistischen oder real gemessenen Geschwindigkeiten/
Reisezeiten/Durchfluss, die ganz sicher bessere Ergebnisse als ein
irgendwie eine Strasse einschaetzender OSM-Mapper ergeben werden?


Gruss,
  -bernd




Mehr Informationen über die Mailingliste Talk-de