Wenn redaktionelle Meldungen mal nicht ganz korrekt sind...

...muss das nicht immer an den Menschen liegen, welche die Meldungen eingeben. Abseits von Autobahnen, kommen auch schnell die Grenzen der Eingabesoftware für TMC Meldungen zum Tragen. Hier mal eine Meldung, die bereits vergangenes Wochenende geschaltet war, auch dieses Wochenende geschaltet ist und auch nächstes Wochenende nochmal geschaltet sein wird:

[Blockierte Grafik: http://img15.imageshack.us/img15/8172/tmc.png]

Zu sehen ist hier eine Sperrung mit einem Ende bei Heidenrod Kemel und dem anderen Ende bei Bad Schwalbach Ramschied. Tatsächlich ist das Ende bei Heidenrod Kemel aber falsch. In Wirklichkeit beginnt die Sperrung bei der Abfahrt nach Bad Schwalbach Heimbach.

Nun bin ich der Frage mal nachgegangen, warum die Meldung so falsch drin ist und hatte am Montag den Kollegen bei der LMS mal angesprochen. Er hatte den Zettel rausgesucht, wo der Auftrag für die Meldung draufsteht und da stand es richtig, jedoch die Abfahrt Heimbach per Hand durchgestrichen und durch Kemel ersetzt. Warum das so geschehen ist, konnte er nicht direkt beantworten, also haben wir das mal durchexerziert und sind in die Erstellungsmaske für eine neue Verkehrsmeldung reingegangen.

Dort haben wir dann die Ursache schnell gefunden. Die Kreuzung, wo die Sperrung tatsächlich beginnt, ist im TMC Straßenkatalog nicht hinterlegt und konnte dementsprechend auch nicht ausgewählt werden. Also ist man hergegangen und hat die nächste im Katalog verfügbare Kreuzung genommen und den tatsächlichen Sperrungsverlauf als Freitext hinzugefügt.

Da nun die automatisierten Systeme (Navi) mit dem Freitext nicht viel anfangen können, wird die Meldung dann natürlich falsch angezeigt und entsprechend falsch ist am Ende auch das Routing.

Somit war dann die korrekte Meldung den Medien vorbehalten, wo vorher eine Sichtung durch Mitarbeiter erfolgt. Theoretisch sollte das auch bei HDT gehen, wenn die Meldungen vorher gesichtet werden würden, da dieses System ja eigentlich nicht auf den TMC Kartalog angewiesen sein sollte.

Wenn man sich mal ein System vorstellt, das mittlerweile 7 Länder abdeckt, dann wird schnell klar, das dort nicht jede Meldung redaktionell bearbeitet werden kann. Zumal zum Beispiel der Mitarbeiter bei TT nicht den Zettel mit der Meldung in der Hand hat, wo die reale Kreuzung durchgestrichen ist. Er sieht nur die Meldung, die über das System kommt. Wie soll er also wissen, das diese Meldung so nicht stimmt?

IMHO der Grund dafür, das TT OpenLR als Standard etablieren will, damit diese Schwierigkeiten umgangen werden können.

Das die LT nicht mehr zeitgemäß ist, wird durch den Beitrag ja klar. Übrigens auch von mir ein Dankeschön für den Beitrag.

Franz

Zitat

Original von Franz Jaeger
Wie soll er also wissen, das diese Meldung so nicht stimmt?

Der korrekte Verlauf wurde als Hinweis in das Freitextfeld geschrieben.

Stell dir mal vor, du hast 400 Meldungen für ein Land vor dir, wo bei jeder Meldung ein Freitext hinterlegt ist und du sollst rausfinden, wo der Freitext was anderes als die Sperre in der Karte aussagt... Zumal ohne Ortskenntnis.

Nebenbei gibt es alle x Minuten noch neue Meldungen, Aufhebungen oder Meldungsänderungen...

Sowas geht IMHO nur automatisiert und ist redaktionell kaum zu bewältigen. Das Problem liegt in der LT und die muss geändert, erneuert oder eben ersetzt werden. Aus TT-Sicht am besten mit OpenLR, weil es eh schon bei TT verwendet wird.

Franz

War jetzt nicht bös gemeint War lediglich eine Antwort auf die Frage.

War auch von mir nicht bös gemeint

Ich stell mir nur gerade vor, wie ein Mitarbeiter ne Meldung aus Südfrankreich bearbeiten soll, wo im Freitext steht, das die Meldung eigentlich etwas falsch platziert ist...

Im Grunde wird bewusst ne falsche Meldung eingegeben, weil die LT zu ungenau ist. IMHO muss genau dort angesetzt werden, um die Meldungen zu verbessern.

Wenn es tatsächlich dazu kommen sollte, das OpenLR sich durchsetzt, werden die Probleme, auch mit falsch gesperrten BAB-Abschnitten über HDT, der Vergangenheit angehören. Zumindest fällt damit der hauptgrund weg.

Franz

Edit: Typo

Zitat

Original von Franz Jaeger

Wenn es tatsächlich dazu kommen sollte, das OpenLR sich durchsetzt, werden die Probleme, auch mit falsch gesperrten BAB-Abschnitten über HDT, der Vergangenheit angehören. Zumindest fällt damit der hauptgrund weg.

Franz

Edit: Typo

Alles anzeigen

Was für mich aber im Umkehrschluß heißt, daß HDT nur so genau ist wie die verwendete LT, oder gibt es noch eine genauere Möglichkeit die Meldungen von HDT am Gerät anzuzeigen bzw. zu verwenden? Die LT ist ja die Basis für die Meldungen, die ans HDT System übermittelt werden. Diese werden dann durch die Floating Data Meldungen ergänzt und ggf. noch durch redaktionelle Sachen, sofern vorhanden.

M.

TT verwendet IMHO OpenLR. Insofern ist TT, und damit HD-Traffic, nicht an die LT gebunden. Aber...redaktionelle Meldungen kommen ja aus einem System, das die LT verwendet. Insofern können redaktionelle Daten (Baustellen, Sperren, Unfälle usw.) nur so genau sein, wie es die LT zulässt.

Franz

Zitat

Original von Bogi100
Location Table

Edit: dort sind alle für eine Definition von Beginn und Ende eines Staus relevanten Koordinaten enthalten

Bei TMC und TMCpro. Diese LT ist in ihren Möglichkeiten begrenzt, weil nur begrenzt Orte bzw. Strassenabschnitte definiert sind.

Franz

Zitat

Original von Franz Jaeger
TT verwendet IMHO OpenLR. Insofern ist TT, und damit HD-Traffic, nicht an die LT gebunden. Aber...redaktionelle Meldungen kommen ja aus einem System, das die LT verwendet. Insofern können redaktionelle Daten (Baustellen, Sperren, Unfälle usw.) nur so genau sein, wie es die LT zulässt.

Franz

Danke für die Info.

Das heißt, die zugespielten Infos (Quellen die auch TMC bzw. TMC Pro speisen) beziehen sich auf die "offizielle" LT, HDT (und damit die TT Geräte) verwenden als LT aber OpenLR. Somit sind die Daten, die für HDT automatisiert verarbeitet werden, ident mit denen die für TMC und TMC Pro auch zur Verfügung stehen, kann man das so sagen?

Klar, durch HDT kommt halt noch die Floating Data Geschichte ins Spiel, aber mir gehts mal nur die Rohdaten, ohne Floating Data.

M.