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

qbert biker qbert1 at gmx.de
Mo Jan 28 11:31:23 UTC 2008


-------- Original-Nachricht --------
> Datum: Mon, 28 Jan 2008 11:14:31 +0100
> Von: Bernd Raichle <bernd at dante.de>
> An: Openstreetmap allgemeines in Deutsch <talk-de at openstreetmap.org>
> Betreff: Re: [Talk-de] Reisezeiten (was: Potlach! *kotz*)

Hallo,
 
> '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 

Und das ist der Punkt. Der eine ignorierts, der andere nicht. Ich
hab ja die deutsche Übersetzung (german_road_tagging) selber 
überarbeitet und damals versucht, die englische Beschreibung
so genau wie möglich abzubilden. Und auf der englischen Liste
stehen schöne Dinge wie dass eine secondary größere Orte 
verbindet. Der Kompromissvorschlag, dass secondary als
Hauptverbindungsstraße _typischerweise_ eine Staatsstraße wäre
wurde kommentarlos gestrichen. Jetzt steht wieder etwas drin, 
was meiner Erfahrung nach faktisch falsch ist, also dass eine
Staatsstraße immer eine Hauptverbindungsstraße sein muss.

> schwammig ... man vergleiche nur mal die FRC-Einordnung der beiden
> grossen Kartenhersteller miteinander, die sind sich auch nicht immer
> einig!

Schon klar, die frc ist ja auch ansich eine schwammige Sache.
Der Unterschied ist nur, dass man bei der frc gar nicht versucht,
den Spagat hinzubekommen, für die schwammige frc ein einzelnes  alleingültiges Merkmal zu finden, denn das gibts einfach nicht.

Die frc ist ein Ergebniswert aus mehreren konkreten Parametern,
die ihrerseits wieder weniger schwammig sind. 

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

Die hatte ich doch schon genannt: Kreuzungsfreiheit, bzw Vorfahrt,
Limits, Ausbauzustand. Bei letzterem könnte man sich direkt
man bei der BAST schlau machen, denn die Querschnitte sind 
zumindest in Deutschland ja genormt.
  
> In den GDF-Daten finde ich weder Ausbauzustand, noch Vorfahrt, noch
> Geschwindigkeitsbeschraenkungen _flaechendeckend_ vor.  Wieso koennen
> dann alle Router/Navis darauf brauchbar routen?

Ich weiss nicht, wie die intern ihre Datenbanken halten, aber 
ich gehe schon davon aus, dass die viel mehr vorhalten, als
sie über GDF konkret ausliefern. Die konkreten Daten werden dann
eben in einen schwammigen Wert wie die frc verrechnet, der 
dadurch in Wirklichkeit gar nicht mehr so schwammig ist. 
  
> Was braucht man zum Routen?  

Ein Graph und einen Algorithmus der den kürzesten Weg rechnen
kann, sind schon mal der Anfang. Hier gehen Einbahnsituationen
schon mit ein. Das ist der Pflichtteil - die Kür ist die 
Optimierung auf die Reisezeit hin. Die ist kein Hexenwerk, aber
sie braucht einen Minimalset an Informationen, damit sie
funktioniert.

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

Wenn ich die das nächste mal fahre, schreib ich mir das
Limit auf. Sehr oft ist das bei solchen Straßen auf 60km/h und
daher kaum über den 50km/h in der Stadt. Der Rest ist sehr 
schwierig für den Router zu erkennen. Ein divider-Tag über
die kreuzungsfreie Strecke kann da helfen, aber das muss
auch mal gesetzt und ausgewertet werden. 

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

Und dazu ist das highway-Tag eben nicht zu gebrauchen und
eine saubere innerorts/ausserorts-Steuerung gibts ja auch nicht.
Ich habe da eben ein Henne/Ein-Problem und werde deshalb 
vorerst auf die AND-Daten ausweichen, weil bei denen bei der
Parametrisierung flächendeckend von ähnlichen Voraussetzungen
ausgegangen wurde. Damit kann man die Heuristik mal vernünftig
ansetzen. Spannend wirds dann, wenn man die dann auf OSM
ansetzt.
  
> Mmmh, wie klassifizierst du so etwas?  "verkehrswichtig={1,2,3,4,5}"?
> Die eine Strasse ist verkehrswichtiger als die andere? ...

Ein Kriterium ist z.B. die Vorfahrt...
 
> ... und dann bist du auch bei "highway={primary,secondary,tertiary}".

Ohne das harte Mapping auf die administrativen Klassen schon,
aber derzeit macht es jeder bei highway anders. Die einen
pfeiffen auf die Kreisstraße und die anderen bilden das sklavisch
genau nach den Schildchen ab.
  
> "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 ... 

Ist ja alles richtig, das Problem ist nur, dass es derzeit nicht 
funktioniert. Erweiternde Attribute wie Spuranzahl werden kaum
vergeben, weil die Renderer die nicht anzeigen und beim Basisattribut
highway gibts pures Chaos. Solange ich selber tagge, ist das 
alles kein Problem, weil ich mein Taggingstil an meinen Router
anpassen kann, aber wenn ich auf fremden Terrain routen will, gehts
schief.

> und bislang habe ich noch niemanden
> eine saubere, eindeutige FRC-Klassifikation gesehen.

Wär doch mal eine schöne Aufgabe fürs Projekt. Die 'Grossen' haben
sicher eine, aber die werden die niemals rausrücken ;)
 
> ... 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 Reisezeitberechnung in dieser Form ist eine KFZ-typische
Sache, da die Reisegeschwindigkeit bei Radfahrern und Fußgängern
nicht wesentlich von Straßenausbau oder Tempolimits abhängt.
Von einer guten Erfassung z.B. von Ampeln können auch diese
aber profitieren. 
  
> Der Unterschied zwischen statischen und tageszeitabhaengigen
> Reisezeiten ("Ganglinien") sind zumindest im belasteten
> Kfz-Strassennetzen wie hier in D wichtig 

Wäre schon wichtig, aber nach meinen Kontakten zu entsprechenden
Projekten glaub ich einfach nicht mehr so recht daran, dass das
jemals funktionieren kann. In München kenne ich ein paar Ecken,
bei denen der Stau so schön periodisch kommt, dass es klappen
könnte, aber meistens ist das eine spontane Sache, also chaotisch.

Der beste Ansatz scheint mir derzeit der mit den 'floating cars'
zu sein, also Daten von im Stau mitschwimmenden Fahrzeugen.
Wurde schon mal diskutiert, wie man die Fahrprofile hier ins
Projekt einfliessen lassen könnte um z.B. die real errechbare
Reisezeit zu ermitteln. Die potentielle Datenbasis von OSM ist
hier nicht ohne.

Grüsse Hubert


-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger




Mehr Informationen über die Mailingliste Talk-de