HD-Traffic Datenqualität (BAB-Sperre-Problem, langsame Fahrzeuge etc.)

  • Auf dem GO wird von beiden seiten das gesperrte Stück vermieden. Der Online-Routeplanner macht das von einer Seite nicht. Von der einen Seite (bei dir unter dem Link "Merkwürdigkeiten") wird doch das gesperrte Teilstück umfahren.


    Wollen wir nicht mal einen Thread für den Online-Routeplanner aufmachen? Der Online-Routeplanner ist noch in der Betaphase uns viele Unstimmigkeiten gibt es in der Form nicht auf den Geräten. Daher hat das IMHO nichts in diesem Thread zu suchen.


    Franz

  • Derzeit wird die Sperrung aufgrund der Staulänge umfahren. Auf Kurzstrecken wird nach wie vor durch den Tunnel navigiert (in beide Richtungen). Die Merkwürdigkeit von gestern war, dass erst das auf den Tunnel folgende Straßenstück umfahren wurde.


    Edit: Die Merkwürdigkeit gibt es heute immer noch.

  • Zitat

    Original von Franz Jaeger
    Wollen wir nicht mal einen Thread für den Online-Routeplanner aufmachen?


    Guter Vorschlag, beim nächsten Fehler.

    Gruß gs.arch

  • Hallo,


    ist es nur mir aufgefallern oder ist seit ein paar Tagen die Datenqualität von HD-T jenseits von Autobahnen und Schnellstraßen deutlich erhöht? Ich habe in den letzten tagen Meldungen in Karlsruhe und Nürnberg (im berufsverkehr, wo es sonst nie Meldungen gab. Also auf Innenstadtstraßen, wenn z.B. eine zu kurze Linkasabbiegespur und eine Apmelphase mit einer 3-Fahrzeug-Frequenz die Fahrt für alle Autos um 4-10 Minuaten verzögert, meldete HD-T die Verzögerung mitten in der Stadt.


    Beste grüße, tompetti

  • Das ist hier in Berlin schon seit einigen Monaten so. Die Addeckung ist halt noch nicht 100%, aber sie arbeiten dran. Scheinbar ist deine Gegend jetzt besser abgedeckt.


    Franz

  • Ich muss jetzt mal anderen Vorrednern (auch in anderen Threads) zustimmen, dass die Berechnung der Verzögerungszeit viel zu optimistisch ist.


    Gestern, auf der Rückfahrt vom Campingplatz in Hohenstadt zu mir sah ich in der Verkehrsleiste, irgendwann zwichen 11:00 und 11:30 Uhr, einen neuen Stau auf der A8 in einem 3 Spurigen Abschnitt (Bin Richtung Norden gefahren), noch etwa 15 Minuten von mir. Angezeigt mit 3 Minuten Verzögerung. 10 Minuten später wuchs die Verzögerung auf 5 Minuten. In den Meldungen wurde Unfall gezeigt, also nicht sehr IQ Routes relevant.


    Stauende erreicht kurz vor einer Abfahrt. TT macht keine Umleitung, weil es die Verzögerung sehr kurz eingestuft hat. Und da begann das Drama. Stop and Go. Die von TT angegebene Wartezeit ist mal zwischendrin auf 9 Minuten hochgegangen und dann wieder runter. Aber realistisch ist was anderes, da ich Minute um Minute beobachten konnte, wie ohne Änderung der Verzögerungszeit die Ankunftszeit nach oben korregiert wurde. Da viel Verkehr war, wuchs der Stau natürlich weiter. Als der Stau dann in den Verkehrsmeldungen doppelt so lang war, wie zu dem Zeitpunkt, wo ich hineingefahren bin, wurde er mit einer lächerlichen Verzögerung von 17 Minuten angegeben.


    Ich hatte nach erreichen des Stauendes nur die Halbe Strecke der "17 Minuten" zu fahren, erreichte aber erst nach 50 Minuten (!) die noch immer ungeräumte Unfallstelle (sowohl Unfall der die linke Spur blockierte, als auch einer, der direkt daneben die rechte Spur blockierte, wodurch nur einspuriges Fahren möglich war). Das war vor einer Abfahrt, ich glaube es war irgendwas mit Pforzheim).


    Da meine tatsächliche Verzögeruzng etwa 50 Minuten betrug, dürfte die Verzögerung Derer, die die doppelte Länge zurückzulegen hatten etwa 100 Minuten betragen haben. Da ist die TT Kalkulation von 17 Minuten einfach lächerlich.


    Und jetzt kommt mir keiner mit IQ Routes. Wäre DAS berücksichtigt worden, wäre im laufe des Staus die Ankunftszeit nicht um weitere 40 Minuten zusätzlich zu der errechneten Verzögerung angestiegen.

    Einmal editiert, zuletzt von KarstenSchilder ()

  • Wie diese Hochrechnung funktioniert ist mir auch ein Rätsel. Eigentlich solltest Du mit Deinem eingeloggten LIVE Service gerät ja die Verzögerungszeit mitbestimmen. Wenn jetzt noch zwei, drei weitere geräte in diesem Stau stehen, dann solle eigentlich eine realistische zeit erfasst werden. Bei mir ist die auf dem Nürnberger Frankenschnellweg auch immer der Fall, wenn dort drei oder vier minuten angezeigt werden, braucht man da gar nicht lang zu fahren. Dort führt allerdinge eine Bahnstrecke parallel un die dort Reisenden Handynutzer werden als Begründung für die unzuverlässige Stauzeitmeldung angegeben.


    Sobald ein tomto LIVE gerät in so einem Stau steht, hätte ich von der Technik eigentlich erwartet, dass es die zeit relativ genau bestimmen kann.


    Zumal es in Deutschland ja in der Regel so ist, dass kein Autofahrer auf dem Standstreifen im Schatten unter einer Brücke anhält und zwei Töpfchen für seine beiden kinder neben das Auto stellt. Wie ich es jetzt in Italien gesehen habe. Langsam bewegende LIVE Geräte, werden daher wohl immer Geräte im Stau sein...


    In Italien waren die Verzögerungszeiten, die TMC-Pro ausspuckte, wenn sie denn stimmten immer sehr zuverlässig, das hat mich doch deutlich überrascht, das kannte ich aus Deutschland bisher so nicht. (Ok, es mussten Staus sein, die es auch gab, manche Meldungen waren wie immer einfach falsch/veraltet).


    Weiß einer wie das berechnet wird?

    2 Mal editiert, zuletzt von tompetti ()

  • Wenn die Verzögerungszeit nicht gestimmt hat, lagen noch nicht genug Daten vor.


    Die Gesamtverzögerungszeit kann auch erst dann ermittelt werden, wenn jemand durch diesen Stau gefahren ist und seine Daten auch auswertbar waren. Die Daten von deinem Gerät konnten die Gesamtverzögerung auch erst darstellen, als du wieder freie Fahrt hattest. Während du noch gestanden hast, war es ja nur die Verzögerung von deinem Eintreffen bis aktuellem Standort im Stau. Wie tompetti schon anmerkte, müssen bestimmte Handybewegungen ausgefiltert werden (wie z.B. die Bahnreisenden, wo plötzlich viele Handys sich kompakt mit einer Geschwindigkeit bewegen). Auch jemand auf dem Standstreifen mit nem Livegerät darf nicht gleich ne Staumeldung verursachen. Deshalb müssen bestimmte Bedingungen erfüllt sein.


    Franz

  • Das Problem an der Sache ist, dass der Go wegen dieser falschen Verzögerungszeit auch keine Umleitung um den Stau gemacht hat, den man hätte mit deutlich kürzerer Zeit umfahren können. Und das ist es doch, was der Nutzer von so einem System grundlegend erwartet: Stundenlange Staus bequem zu umfahren.


    Als ich zuletzt in dem Stau (mehr Stop als Go) mir die Gesamtmeldung angesehen hatte, betrug die Länge 14 km. Die Autobahn hatte durchgehend 3 Spuren. Da man die meiste Zeit wirklich gestanden hat, gehen wir davon aus, dass auf 7 Meter Autobahn pro Fahrstreifen ein Auto kommt und wir bei 14km Länge auf geschätzt 6000 Fahrzeuge kommen. Gehen wir davon aus, dass auf ein Fahrzeug 2 Insassen kommen, sind wir bei etwa 12000 Personen. Runden wir es wegen Kleinkindern auf 10000 Personen ab. Der Marktanteil von Vodafone liegt etwa bei 35%. Somit dürften sich in dem Stau etwa 3500 Mobiltelefone mit Vodafonekarte befunden haben. Das sollte doch wohl reichen für eine brauchbare Kalkulation.

  • Und wenn 100000 am gleichen Fleck stehen... Dann weiß man immer noch nicht, wie lange es dauert, um den Stau zu durchfahren.


    Franz

  • Zitat

    Original von Franz Jaeger
    Und wenn 100000 am gleichen Fleck stehen... Dann weiß man immer noch nicht, wie lange es dauert, um den Stau zu durchfahren.


    Du vergisst die rechnerisch etwa 750 Vodafone Handies, die vor mir gefahren sind und demnach auch vor mir den Stau verlassen haben.


    Nach allem was ich über floating phone data gelesen habe, funktioniert das system aber nicht so, wie Du es da oben beschreibst (fett markiert).


    Soweit in den Beschreibugen und Werbevideos dargestellt, wird mittels der floating phone data ermittelt, mit welcher Geschwindigkeit sich Handywolken in den Gebieten fortbewegen. Anfang und Ende des "verzögerten Bereiches" wird dann aus den Daten interpoliert. Wie lange man braucht, um den Stau zu durchfahren wird überhaupt nicht gemessen. Das würde auch viel zu lange dauern und wäre auch wegen der Mittelung zur statistischen Darstellung, damit die Erfassung anonymisiert ist, nicht möglich. Dies wird errechnet, aus den Daten der ermittelten Fortbewegungsgeschwindigkeit. Und da liegt der Hund für diesen Stau begraben. Warum hat er eine so hohe Fortbewegungsgeschwindigkeit ermittelt, obwohl die Handies im Stau so langsam vorwärts gekommen sind?


    Rechnen wir mal:


    3 km bin ich in 50 Minuten gafahren, also etwa 3,6km/h.


    9 Minuten Verzögerung hat HDT angegeben. Rechnen ich mal noch 2 Minuten normale Fahrzeit für die 3km Autobahn drauf, komme ich auf 11 Minuten. Ergibt eine Durchschnittsgeschwindigkeit von etwa 16km/h.


    Woher der große Unterschied? Da ist weder eine andere Straße noch eine Eisenbahnstrecke unmittelbar daneben verlaufen.

    2 Mal editiert, zuletzt von KarstenSchilder ()

  • Aufgrund der Strassengeo oder der Infrastruktur von Vodafone ist nicht jeder Ort für ne Erfassung gut geeignet. Die besten Daten gibt es, wenn sich ein aktives Handy (Gespräch oder Datenübertragung... SMS reicht z.B. nicht) bewegt. Dann gibt es genaue Daten. Oder noch besser, FCD... Also z.B. ein Livegerät im Stau.


    Kuck dir mal das Video an: Klick


    Franz

  • im übrigen gibt es natürlich auch noch die Möglichkeit, das hier gar keine echte HD-T Meldung vorlag, sondern eine TMC oder TMC-Pro Meldung weiterverarbeitet wurde. Die erkennt man recht gur daran, dass sie immer an Autobahnauffahrten beginnen und enden.


    Dann wird nur ein Näherungswert ermittelt, der falsch und in Deutschland in der Regel zu optimistisch ist.