Überarbeitung von TMC / TPEG

Gerade bei Hauptverkehrsstraßen, und darauf beziehen sich ja die meisten TMC-Routen. Na gut, ich denke, das ist ein Argument für Relationen. Ich werde mal ein Proposal dazu aufsetzen.

Ich würde für Relationen plädieren, aus mehrere Gründen:

  • Reicht ein einziges Tag wirklich aus? Ich bin mir da noch nicht sicher. Es braucht eher 2-3 TMC-Tags um eine Location abzubilden und wenn diese Tags dann an einem Knoten hängen haben wir wieder eine unübersichtliche Sitation.
  • Wenn die Kreuzung doch einmal detailierter gemappt wird, kann man einem TMC-unerfahreren Mapper recht einfach beibringen “in diese Relation kommen alle relevanten Knoten der Kreuzung”
  • Ganz wichtig: Viele Locations haben mehrere Codes. Mit Relationen kein Problem, mit einem tag am Knoten wird das sehr unschön.

Für die Zukunft kann ein Blick auf die TMC-Informationen die per UKW verteilt werden auch nicht schaden. Ich habe mir mal einen Empfänger genommen und ein kleines Script geschrieben, das die Daten auseinanderpflückt und in die einzelnen Teile aufspaltet. Das hier sind die momentanen Meldungen in Frankfurt. Unten habe ich die erste Meldung dann mal (noch von Hand) übersetzt - allerdings sind das alles feste Textbausteine, die man auch automatisch erzeugen kann. Die genauen Formulierungen sind in der Event_List vom BaST enthalten.
Vielleicht hat ja jemand Lust, solche Meldungen auf einer Karte darzustellen - zumindest grob nach Location-Liste, bis die OSM-TMC-Daten funktionsfähig sind?


Ev  201         LC 11611        Diver 1 Dir neg Exten 0 (9)AddEvent 63  (6)Suppl 162
Ev  703         LC 22492        Diver 1 Dir pos Exten 0 (9)AddEvent 25  (6)Suppl 4      (1)Control 2
Ev  406         LC 23982        Diver 1 Dir pos Exten 0 (6)Suppl 4
Ev  701         LC 22496        Diver 1 Dir pos Exten 0 (6)Suppl 4      (9)AddEvent 401 (1)Control 2
Ev  701         LC 11401        Diver 1 Dir pos Exten 0 (9)AddEvent 407 (6)Suppl 4
Ev  108         LC 10853        Diver 1 Dir neg Exten 2 (2)Length 11    (1)Control 6
Ev  334         LC 11533        Diver 0 Dir pos Exten 1 Dura 0


Ev  201      => Unfall
LC 11611     => A5 Bensheim
Diver 1      => die empfohlene Umleitung kann benutzt werden
Dir neg      => in negativer Richtung
Exten 0      => Ausdehnung 0 TMC Locations
AddEvent 63  => Gefahr durch Gegenstände auf der Fahrbahn
Suppl 162    => in der Ein/Ausfahrt

Oh toll, so hab ich mir das gewünscht :slight_smile: Könntest du vielleicht die Rohdaten von deinem Sample bereitstellen? An so einer Übersetzung würde ich mich auch gerne versuchen, und sie letztlich dann auch für Navit implementieren. Nur leider habe ich hier keinen TMC-Empfang, da das System in Estland (noch) nicht im Einsatz ist, und damit keine Daten…

Ja, sowas auf der Karte darzustellen halte ich für eine gute Idee. Prinzipiell würde ich mich zumindest daran beteiligen wollen, sowas aufzusetzen. Die Frage ist nur, wo man die Daten am besten hernimmt. Von sennewald63 gab es dazu den Vorschlag, dass ein paar Leute aus verschiedenen Teilen Deutschland TMC-Daten empfangen und an einen Server übermitteln, der sie dann auswertet und auf der Karte darstellt. (So ähnlich funktionieren Luftraum-Hobbyisten-Seiten wie Flightradar24.)

Das würde ich hier in Bremen auch gerne mal machen. Was brauche ich denn, um die Signale/Daten in den Computer zu bekommen?

Du brauchst einen TMC-Empfänger, den du dann noch mit einem passenden Interface für den PC versehen musst. Z.B. gibt es hier eine Umbauanleitung für ein spezielles Modell. Ich habe hier einen Empfänger direkt an einem Raspberry Pi hängen, dafür musste ich nur den Stecker wechseln.

Mein Code: http://github.com/mueschel/TmcDecoder
Ein kurzer Ausschnitt der RDS Daten: http://osm.mueschelsoft.de/RDSraw.bin

Wunderbar, danke! Der Link zum Code müsste wohl https://github.com/mueschel/TmcDecoder sein :wink: Ja, so hatte ich mir das vorgestellt. Die Daten kommen ja letztlich über einen seriellen Port, also genau wie die NMEA-Daten aus einem GPS-Empfänger. Und das zu decodieren sollte ja nicht schwer sein (auch wenn ich nicht genug von Perl verstehe, um das zu erkennen, aber in C ist es sicher auch nicht schwerer ;)).

Der Link ist schon korrigiert, gleich zwei Tippfehler auf einmal :confused:
Viel echtes “perlisch” sollte mein Code nicht enthalten, nur zwei Zeilen, der Rest sollte sich aus dem Kontext ergeben. Dekodieren muss man die Sachen bitweise, das ist kein ASCII wie bei NMEA. Bei Fragen kannst du mir gerne eine PN schreiben.

Hat jemand schonmal darüber nachgedacht das Smartphone dafür zu verwenden?
Fast alle diese Dinger haben doch ein UKW Radio drin und zugreifen kann man darüber sicher auch über Android, oder?

Gleich der erste Versuch: http://www.freesoftwhere.org/category/rds/
oder hier: http://www.sesma.eu/windowsmobile/en/hypergps.htm

Das hat mir doch keine Ruhe gelassen. Hier noch etwas:
http://sourceforge.net/apps/mediawiki/travelingsales/index.php?title=Plugin/TrafficMessageChannel

Das sieht ja klasse aus :slight_smile: Vor allem beim letzten Link ist eine Menge technische Dokumentation dabei, da hat sich offenbar schon jemand viele Gedanken gemacht. So in etwa stelle ich mir auch die Implementierung in Navit vor.

Zu Android kann ich persönlich nicht viel sagen, da ich selbst kein Android habe und auch kein Smartphone, sondern “nur” ein Wifi-Tablet mit Ubuntu. Von daher bräuchte ich hier etwas Unterstützung was die Implementierung angeht, da ich mich mit der Android-Entwicklung überhaupt nicht auskenne und eben kein Testsystem habe. Das gleiche gilt für Windows / Windows Phone. Aber in beiden Fällen dürfte das nur die Datenanbindung an die TMC-Hardware betreffen, die Auswertung läuft dann ja wie bei Linux auch.

Gerade habe ich herausgefunden, dass auch die Location Codes für Belgien kostenlos bezogen werden können:
http://www.technum.be/en/rds-tmc

Skizzen und Proposal sind in Arbeit…

Für windows mobile hätte ich hier was: http://forum.xda-developers.com/showthread.php?t=497977
Bei Android scheint es noch nicht ganz soweit zu sein aber hier gibt es schon mal eine Libary: http://mmbtools.crc.ca/content/view/53/33/

Hier mal eine kleine Skizze, welche Punkte ich bei einem Autobahnkreuz in zwei TMC-Punkt-Relationen packen würde:

http://wiki.openstreetmap.org/wiki/File:TMC_Motorway_Intersection.svg

Ein solches Kreuz hätte zwei Location Codes, jeweils einer mit Bezug auf die blaue und rote Strecke in der Skizze. Deshalb bräuchte es auch zwei Relationen - eine für die Punkte A-D, die zur blauen Strecke gehören, und eine für die Punkte E-H der roten Strecke. Jede sollte dabei folgende Tags bekommen:

  • type=tmc

  • tmc:cid=* - Ländercode

  • tmc:tabcd=* - Tabellennummer

  • tmc:point=* - Location Code dieses Punktes

  • tmc:segment=* - Übergeordnetes Segment (falls vorhanden)

  • tmc:road=* - Übergeordnete Straße

  • tmc:pos_off=* - Nächster Punkt in positiver Richtung

  • tmc:neg_off=* - Nächster Punkt in negativer Richtung

Die ersten 3 Tags sind notwendig, sie geben den international eindeutigen Location Code an. Ich würde cid und tabcd in eigene Tags packen und nicht alle drei zusammen als cid:tabcd:point in den Wert packen, weil man dann für die restlichen Tags (Referenzen auf andere Locations) immer nur den letzten Teil braucht - solche Referenzen gibt es immer nur innerhalb einer Tabelle, d.h. cid und tabcd sind dort immer gleich. Die Frage ist aber, ob diese Referenzen auf andere Locations überhaupt in dieser Form als Tags erfasst werden sollten (und so die verkettete Liste abbilden) oder lieber als eigene Relation, die dann die Punkte als Member enthält. Beides hat wohl Vor- und Nachteile, ich habe da derzeit keinen klaren Favoriten.

Die vier Punkte A-D bzw. E-H sollten als Elemente der Relation vorhanden sein, für die Rollen würde ich mir eine Benennung so ähnlich wie diese vorstellen (die Namen sind nur schematisch, weil mir gerade nichts besseres einfällt - vielleicht hat jemand eine bessere Idee):

  • A/G: posend_negdir

  • B/H: posend_posdir

  • C/E: negend_negdir

  • D/F: negend_posdir

Dabei soll **posend** bedeuten, dass sich der Node auf der Seite des Kreuzes befindet, das näher am positiven Nachbar-TMC-Punkt liegt, während **negend**-Nodes auf der anderen Seite sind, näher am negativen Nachbar-TMC-Punkt. Außerdem geben **posdir** und **negdir** an, auf welcher Fahrbahn (in positiver oder negativer Richtung) der Punkt liegt. (Siehe dazu weiter unten.) Dieses Benennungsschema halte ich deshalb für sinnvoll, weil auf diese Weise immer die Nodes, die am gleichen Ende bzw. auf der gleichen Richtungsfahrbahn liegen, einen Teil des Rollennamens gemeinsam haben. Bei kompakteren Kreuzungen kann man dann Namen zusammenlegen:
  • Bei einer Straße ohne getrennte Richtungsfahrbahnen gibt es keine Unterscheidung zwischen posdir und negdir. Hier braucht es nur zwei Knoten, einen an jedem Ende, mit Rollen posend und negend.

  • Bei einer Straße mit getrennten Richtungsfahrbahnen, die von einer anderen ohne Trennung gekreuzt wird, liegt auf jeder Richtungsfahrbahn nur ein Kreuzungsnode und die Unterscheidung zwischen posend und negend fällt weg. Die beiden nodes bekommen dann die Rollen posdir und negdir.

  • Bei einer ganz einfachen Kreuzung komplett ohne bauliche Trennungen gibt es nur einen Node mit Rolle all.

Natürlich sind auch gemischte Kombinationen möglich, wenn eine Straße z.B. vor der Kreuzung baulich getrennt ist, dahinter aber nicht mehr etc.

Bleibt noch die Frage, was die positive und was die negative Fahrtrichtung sein sollen. Der TMC-Standard definiert die positive Richtung als die Richtung, die vom negativen Nachbarknoten weg zum positiven Nachbarknoten hin zeigt. Allerdings werden Ereignisse wie z.B. Staus immer von der Ursache (z.B. ein Unfall) an gemessen, d.h. entgegen der Fahrtrichtung. Ein Unfall auf der Seite, in der der Verkehr in positiver Richtung fließt, wird daher als “Ereignis in negativer Richtung” gemeldet, weil sich der Stau vom Unfall aus in die negative Richtung ausdehnt. Soll heißen: Auf der negativen Richtungsfahrbahn fließt der Verkehr in positiver Richtung. Weil das verwirrend sein kann, gab es hier den Vorschlag, diese Benennung in OSM umzudrehen. Andererseits könnte das wiederum die Nutzer verwirren, die etwas anderes erwarten, weil sie es vom TMC-Standard her so kennen. Ich bin mir hier nicht wirklich schlüssig.

In dem verlinkten Proposal wurde auch vorgeschlagen, statt der cid ein Länderkürzel zu vergeben, und Tabellennummern nur dann zu taggen, wenn es in diesem Land mehr als eine gibt. Auch hier bin ich mir nicht ganz schlüssig, ob das Sinn macht. Wenn man cid und tabcd wie in den Tabellen angegeben taggt, vereinfacht das eine automatische Konsistenz- und Vollständigkeitsprüfung, und eine halb-automatische Aktualisierung. Soll heißen, wenn ein Land eine neue Tabelle herausgibt, kann man direkt automatisch mittels der Nummern feststellen, was noch aktuell ist, und eine Liste aller noch zu ändernder Nodes erstellen. Beim Mappen sollte der Unterschied klein sein, da man eine Nummer ja ohnehin als solche erfasst, und wer mit dem Location Code 12345 etwas anfangen kann, für den dürften auch cid 58 und tabcd 1 nicht zu kryptisch sein.

Das Ganze ist auch mehr verwirrend als zielführend. Daher ergibt sich die Frage ob es nicht ausreichend ist die TMC Segmente mit Start und Endknoten zu erfassen und die Richtung wegzulassen, da diese sich ja gemäß Definition ergibt. Oder habe ich das einfach nur falsch gedeutet?

Auch nach zweifachem Lesen habe ich nichts gefunden, das ich bemängeln würde.

Ich würde mich hier an den TMC-Standard halten. Ich sehe da kein Problem - man muss einfach geografisch denken und nicht aus Autofahrer-Sicht, dann ist alles direkt eindeutig.

Zur tabcd: Wenn ich das richtig verstehe, ändert sich die tabcd nicht, nur die Versionsnummer wird bei einem Update geändert. Erst wenn jemand eine völlig neue Tabelle anlegt, dann gäbe es eine neue tabcd. Würde es deswegen nicht Sinn machen, auch die Version einzutragen? Das enthält zwar keine wirkliche Information, aber dem Mapper zeigt es direkt, wie aktuell die Daten sind, und ob sie seit dem letzten Update jemand überprüft hat.

Für ein vollständiges mapping bei Autobahnkreuzen könnte sich optional anbieten, die Wege der Links mit Rolle in_positive, out_negative etc. zu versehen. Mit dieser Information kann man dann auch direkt die richtige Straße markieren wenn eine Ausfahrt gesperrt ist.

Ja, damit hast du vermutlich Recht, man muss das wohl nicht explizit taggen. Was genau meinst du in diesem Zusammenhang mit “TMC Segmente mit Start und Endknoten erfassen”?

Richtig, die tabcd bleibt gleich, so lange keine komplett neue Tabelle angelegt wird. Ich hatte mir auch anfangs überlegt, die Versionsnummer zu taggen, damit man den Datenstand erfasst hat, bin dann aber doch zu dem Schluss gekommen, dass es vielleicht eher Nachteile hätte. In so einem Fall müsste man alle TMC-Relationen ändern und die Versionsnummer anpassen, sobald eine neue Tabelle herauskommt - und nicht nur die, bei denen sich etwas ändert. Zugegeben, das meiste könnte man davon automatisch machen, und nur die Relationen einem Nutzer überlassen, bei denen sich wirklich etwas ändert. Allerdings würde das auch zusätzlich die History dieser Relationen füllen. Lohnt sich das wirklich?

Sehr gute Idee. Bei einfachen Autobahnausfahrten stelle ich mir das mit so einem Tagging dann relativ simpel vor, weil es ja in jeder Richtung eine Auf- und Ausfahrt gibt. Ich frage mich gerade, wie denn eine TMC-Nachricht codiert würde, wenn ein Teil eines Autobahnkreuzes gesperrt ist, also z.B. man nicht von der A 2 aus Richtung Osten kommend auf die A 7 nach Süden fahren kann, alles andere aber möglich ist. Dann ist ja weder generell die Ausfahrt aus der A 2 gesperrt, noch die Einfahrt in die A 7, sondern eben nur dieser eine Link.

Kein Thema, haben wir gerade in Wetzlar Ost: http://www.openstreetmap.org/#map=17/50.57138/8.54780
Nicht möglich sind: Ost->Nord, Ost->Süd und Nord->West (alle Links die die Lahnbrücke berühren), laut TMC auch Nord->Ost, laut Mitteilung auf hessen.de aber nicht.
In den TMC-Meldungen:


Ev  406         LC 23982        Dir pos Exten 0 (6)Suppl 4
B49 Anschlussstelle Wetzlar Ost, Einfahrt gesperrt, aus Richtung Gießen, eine Umleitung ist eingerichtet
Ev  701         LC 11401        Dir pos Exten 0 (9)AddEvent 407 (6)Suppl 4
A45 Anschlussstelle Wetzlar Ost, in Richtung Süden, Baustelle, Ausfahrt gesperrt, eine Umleitung ist eingerichtet

Es gibt noch Möglichkeiten, “erste Ausfahrt”, “zweite Ausfahrt” und “Ausfahrt Richtung XY” zu kodieren, das lässt sich also alles genau ausdrücken.

Naja ein TMC Segment ist für mich eine Relation von einem Startpunkt (node) mit einem der Reihenfolge nach sortierten Weg zu einem Endpunkt (node) die beiden nodes müssen am Anfang bzw. Ende des ersten bzw. letzten Wegstückes liegen.

Ich habe es mit den GTFS Segmenten ähnlich gemacht, wobei die Haltestellen nicht Bestandteil des Weges sein müssen. Das könnte man für die TMC nodes auch so machen, wenn man möchte. (Aber du schlugst ja vor lieber vier Knoten in einer Relation zusammenzufassen.)

Ah, verstehe. So 100% sehe ich es aus der Datenstruktur noch nicht, aber da muss ich noch mal die Spezifikation gründlicher lesen :wink: Ja, damit klappt das natürlich wunderbar. Dann müsste man nur schauen, wie man es so taggt, dass man mit den übertragenen Infos auch wirklich eindeutig den zugehörigen Link finden kann.

Ja, so eine Idee habe ich auch noch im Hinterkopf - also TMC-Links (ich nenne sie mal lieber so, weil es Verbindungen zwischen zwei TMC-Punkten sind, und der Begriff Segment schon für ein größeres Straßenteilstück benutzt wird) durch Routenrelationen abzubilden. Das hatte ich oben noch nicht aufgelistet, weil ich da noch am überlegen bin, aber das wäre sozusagen der zweite Teil, zusätzlich zu den reinen Punkten - oder meinenwegen auch alternativ? Ich finde die Punkte deshalb praktisch, weil man viele Informationen einmalig in so einen Punkt packen und den dann referenzieren kann - und eben Link-Roads damit einbeziehen wie von mueschel vorgeschlagen.

Proposal ist angelegt und wird demnächst weiter mit Inhalt gefüllt.

Das wäre dann sinngemäß identisch mit dem Ansatz des Proposals “vereinfachtes TMC” (siehe #8). Da gibt es sogar ein paar rudimentäre Realisierungen, z.B. die B 297 bei Tübingen.

Ja, richtig. Dort sollte es mit Tags an den Ways selbst gelöst werden. IMHO wäre eine Routenrelation sinnvoller, weil man an der die ganzen Tags nur einmal setzen muss und nicht an jedem Wegstück. Da kann man natürlich auch verschiedener Auffassung sein…

Das Proposal an sich finde ich gut, deshalb würde ich auch einiges davon einfließen lassen. Genau daher stammt ja diese Idee mit dem Taggen von Links, also ich habe das nicht selbst ausgedacht :wink: