You are not logged in.

#101 2014-01-11 18:36:15

mueschel
Member
Registered: 2012-06-11
Posts: 1,150
Website

Re: Überarbeitung von TMC / TPEG

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

Offline

#102 2014-01-11 19:38:55

MHohmann
Member
From: Tartu, Estonia
Registered: 2009-06-07
Posts: 1,600
Website

Re: Überarbeitung von TMC / TPEG

Oh toll, so hab ich mir das gewünscht 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.)


SotM Baltics, 3.-4. August 2013, Tartu, Estonia: amenity=university, mappers=yes

Offline

#103 2014-01-11 19:59:44

Gehrke
Member
From: Bremen, DE
Registered: 2013-10-19
Posts: 1,894
Website

Re: Überarbeitung von TMC / TPEG

mueschel wrote:

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 würde ich hier in Bremen auch gerne mal machen. Was brauche ich denn, um die Signale/Daten in den Computer zu bekommen?

Last edited by Gehrke (2014-01-11 20:00:16)

Offline

#104 2014-01-11 21:14:47

mueschel
Member
Registered: 2012-06-11
Posts: 1,150
Website

Re: Überarbeitung von TMC / TPEG

Gehrke wrote:

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

MHohmann wrote:

Könntest du vielleicht die Rohdaten von deinem Sample bereitstellen? An so einer Übersetzung würde ich mich auch gerne versuchen

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

Last edited by mueschel (2014-01-11 21:17:10)

Offline

#105 2014-01-11 21:26:32

MHohmann
Member
From: Tartu, Estonia
Registered: 2009-06-07
Posts: 1,600
Website

Re: Überarbeitung von TMC / TPEG

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


SotM Baltics, 3.-4. August 2013, Tartu, Estonia: amenity=university, mappers=yes

Offline

#106 2014-01-11 22:22:19

mueschel
Member
Registered: 2012-06-11
Posts: 1,150
Website

Re: Überarbeitung von TMC / TPEG

Der Link ist schon korrigiert, gleich zwei Tippfehler auf einmal hmm
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.

Offline

#107 2014-01-12 08:36:45

viw
Member
Registered: 2010-05-15
Posts: 2,623

Re: Überarbeitung von TMC / TPEG

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/t … ageChannel

Last edited by viw (2014-01-12 09:22:12)

Offline

#108 2014-01-12 09:49:25

MHohmann
Member
From: Tartu, Estonia
Registered: 2009-06-07
Posts: 1,600
Website

Re: Überarbeitung von TMC / TPEG

Das sieht ja klasse aus 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...

Last edited by MHohmann (2014-01-12 09:49:51)


SotM Baltics, 3.-4. August 2013, Tartu, Estonia: amenity=university, mappers=yes

Offline

#109 2014-01-12 10:22:32

viw
Member
Registered: 2010-05-15
Posts: 2,623

Re: Überarbeitung von TMC / TPEG

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/

Offline

#110 2014-01-12 14:50:43

MHohmann
Member
From: Tartu, Estonia
Registered: 2009-06-07
Posts: 1,600
Website

Re: Überarbeitung von TMC / TPEG

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


SotM Baltics, 3.-4. August 2013, Tartu, Estonia: amenity=university, mappers=yes

Offline

#111 2014-01-12 15:24:41

viw
Member
Registered: 2010-05-15
Posts: 2,623

Re: Überarbeitung von TMC / TPEG

MHohmann wrote:

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.

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?

Offline

#112 2014-01-12 15:36:54

mueschel
Member
Registered: 2012-06-11
Posts: 1,150
Website

Re: Überarbeitung von TMC / TPEG

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

MHohmann wrote:

Bleibt noch die Frage, was die positive und was die negative Fahrtrichtung sein sollen.

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.

Last edited by mueschel (2014-01-12 15:37:32)

Offline

#113 2014-01-12 16:10:28

MHohmann
Member
From: Tartu, Estonia
Registered: 2009-06-07
Posts: 1,600
Website

Re: Überarbeitung von TMC / TPEG

viw wrote:

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?

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"?

mueschel wrote:

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.

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?

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.

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.


SotM Baltics, 3.-4. August 2013, Tartu, Estonia: amenity=university, mappers=yes

Offline

#114 2014-01-12 16:47:19

mueschel
Member
Registered: 2012-06-11
Posts: 1,150
Website

Re: Überarbeitung von TMC / TPEG

MHohmann wrote:

ch frage mich gerade, wie denn eine TMC-Nachricht codiert würde, wenn ein Teil eines Autobahnkreuzes gesperrt ist

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.

Offline

#115 2014-01-12 17:12:44

viw
Member
Registered: 2010-05-15
Posts: 2,623

Re: Überarbeitung von TMC / TPEG

MHohmann wrote:
viw wrote:

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?

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"?

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

Offline

#116 2014-01-12 18:50:11

MHohmann
Member
From: Tartu, Estonia
Registered: 2009-06-07
Posts: 1,600
Website

Re: Überarbeitung von TMC / TPEG

mueschel wrote:

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.

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.

viw wrote:

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

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.


SotM Baltics, 3.-4. August 2013, Tartu, Estonia: amenity=university, mappers=yes

Offline

#117 2014-01-12 19:08:33

seichter
Member
Registered: 2011-05-21
Posts: 3,270

Re: Überarbeitung von TMC / TPEG

MHohmann wrote:

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

Online

#118 2014-01-12 19:39:21

MHohmann
Member
From: Tartu, Estonia
Registered: 2009-06-07
Posts: 1,600
Website

Re: Überarbeitung von TMC / TPEG

seichter wrote:

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


SotM Baltics, 3.-4. August 2013, Tartu, Estonia: amenity=university, mappers=yes

Offline

#119 2014-01-12 20:03:55

viw
Member
Registered: 2010-05-15
Posts: 2,623

Re: Überarbeitung von TMC / TPEG

MHohmann wrote:
viw wrote:

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

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.

Naja wozu benötigt man die Information der Punkte? Insbesondere wenn sie an großen Kreuzungen doch eher Relationen sind?
Vielleicht reichen die Relationen der TMC-Links ja aus. Und auch die anderen Probleme ließen sich mit Relationen von Wegen mit den entsprechenden tags lösen. Dann gibt es eben keinen Start- oder Endpunkt, sondern eine Richtung oder was auch sonst diesen Weg als den richtigen identifizieren würde.

Offline

#120 2014-01-12 23:22:19

MHohmann
Member
From: Tartu, Estonia
Registered: 2009-06-07
Posts: 1,600
Website

Re: Überarbeitung von TMC / TPEG

viw wrote:

Naja wozu benötigt man die Information der Punkte? Insbesondere wenn sie an großen Kreuzungen doch eher Relationen sind?
Vielleicht reichen die Relationen der TMC-Links ja aus.

Möglich, ich sehe es nur gerade noch nicht ganz... Zum Beispiel wie man denn dann TMC-Segmente erfassen könnte (na gut, vielleicht muss man das ja nicht). Ein Segment ist definiert als eine Abfolge von Punkten (nicht Wegabschnitten / Links) innerhalb einer Straße. Ein Segment hat also zwei Endpunkte, der Straßenabschnitt dazwischen lässt sich keinem Segment zuordnen, sondern nur die Punkte.

Und auch die anderen Probleme ließen sich mit Relationen von Wegen mit den entsprechenden tags lösen. Dann gibt es eben keinen Start- oder Endpunkt, sondern eine Richtung oder was auch sonst diesen Weg als den richtigen identifizieren würde.

Na gut, überlegen wir uns mal, wie das aussehen müsste... Also, die linearen Wege zwischen zwei TMC-Punkten kann man natürlich in eine Relation packen, und z.B. in dieser Form taggen:

  • type=tmc

  • tmc:cid=* - Ländercode

  • tmc:tabcd=* - Tabellennummer

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

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

  • tmc:road=* - Zugehörige Straße

  • tmc:direction=positive/negative/both - Fahrtrichtung bei getrennten Richtungsfahrbahnen / gemeinsamer Fahrbahn (bei Trennung hätte man 2 Relationen, eine pro Richtung - ähnlich wie Busrouten nach ÖPNV-Schema).

Damit könnte man nun natürlich jede Ortsangabe behandeln, die zwischen zwei TMC-Punkten, d.h. auf einem eben solchen TMC-Link liegt. Die Ortsangabe enthält einen TMC-Punkt und eine Richtung, in der sich das Ereignis von dort aus befindet. Also sucht man den Link, der besagten Punkt am richtigen Ende hat. So weit, so gut.

Kommen wir nun zum Beispiel von mueschel. Nehmen wir an, eine Ausfahrt ist gesperrt. In dem Fall wäre die Ortsinformation (wenn ich das richtig verstanden habe) der Location Code der Ausfahrt, die Richtung (positiv oder negativ, d.h. auf welcher Seite der Autobahn) sowie evtl. die Nummer der Ausfahrt (wenn mehrere an der gleichen Stelle sind - z.B. weil man in verschiedene Richtungen auf eine getrennte Straße ausfahren kann) oder die Fahrtrichtung (auf einen weiteren TMC-Punkt zu?). Gut, so ein Link-Way verbindet natürlich zwei Straßen, deren Location Codes könnte man auf eine entsprechende Route eintragen, die dann eben diesen Link enthält. Ja, so könnte das klappen.

Als anderes Beispiel fällt mir gerade noch ein, dass die TMC-Spezifikation auch Wetterwarnungen für Gebiete spezifiziert. Solche Gebiete werden für gewöhnlich dadurch identifiziert, dass sie Punkte bzw. kleinere Gebiete enthalten. Wie könnte man sowas mappen? Gut, die meisten Gebiete sind Vewaltungsgebiete, d.h. Gemeinden, Landkreise, Bundesländer. Sollte da jedes noch mal eigens eine TMC-Relation bekommen? Oder einen TMC-Code an die schon vorhandene Relation? Manchmal ändern sich aber Gemeindegrenzen oder Landkreise, ohne dass TMC umgehend daran angepasst wird... Deshalb wäre es meine Idee gewesen, einfach die Punkte aufzunehmen, die gemäß Location Code Tabelle in der gleichen Fläche liegen, und diese mittels Relation zusammenzufassen.


SotM Baltics, 3.-4. August 2013, Tartu, Estonia: amenity=university, mappers=yes

Offline

#121 2014-01-13 00:03:11

mueschel
Member
Registered: 2012-06-11
Posts: 1,150
Website

Re: Überarbeitung von TMC / TPEG

Ich würde versuchen, TMC-Daten möglichst direkt zu übernehmen und nicht nur davon abgeleitete Informationen. Also in erster Linie die Locations selbst, und nur wenn notwendig solche TMC-Links. Wie definiert sich sonst eine Kreuzung? Das wäre ein Punkt, an dem sich mehrere Links treffen. Das ist kaum auszuwerten.
In vielen Fällen sind die Links als Relation hilfreich für die Darstellung, deswegen sollten wir sie als Option in jedem Fall haben, gerade bei komplizierteren Straßenverläufen. In deinem Vorschlag fehlt in der Relation noch die Unterscheidung zwischen einer TMC-Location-Relation und einer TMC-Link-Relation.

Offline

#122 2014-01-13 00:40:38

mueschel
Member
Registered: 2012-06-11
Posts: 1,150
Website

Re: Überarbeitung von TMC / TPEG

Noch ein kleines Betthupferl an TMC-Eigenheiten (inzwischen mit automatischer Übersetzung):

Ev  701         LC 22496        Dir pos Exten 0 (6)Suppl 4      (9)AddEvent 401 (1)Control 2
B277 Wetzlar -> Herborn bei/am  Herborn-Süd:    Baustelle, eine Umleitung ist eingerichtet, gesperrt, in beiden Richtungen

Hier sieht man schön, dass es auf die Reihenfolge der Argumente ankommt: An der B277 Richtung Wetzlar gibt es eine Baustelle an der Location Herborn-Süd. Diese ist gesperrt, und zwar in beiden Richtungen. Das "beide Richtungen" bezieht sich auf die Sperrung, nicht auf die Baustelle, und damit ist auch gesagt, dass in Richtung Wetzlar keine Behinderung vorliegt. Und, wie sollte es anders sein, hat diese Dauerbaustelle natürlich auch jemand in OSM eingetragen: http://osm.org/go/0GKo3Ykul-?way=19371791 .

Offline

#123 2014-01-13 01:54:26

MHohmann
Member
From: Tartu, Estonia
Registered: 2009-06-07
Posts: 1,600
Website

Re: Überarbeitung von TMC / TPEG

mueschel wrote:

In vielen Fällen sind die Links als Relation hilfreich für die Darstellung, deswegen sollten wir sie als Option in jedem Fall haben, gerade bei komplizierteren Straßenverläufen. In deinem Vorschlag fehlt in der Relation noch die Unterscheidung zwischen einer TMC-Location-Relation und einer TMC-Link-Relation.

Stimmt, danke, das habe ich tatsächlich vergessen. Ich hatte an Tags der Form tmc:type=point/link gedacht, sie aber offenbar nicht oben gepostet...


SotM Baltics, 3.-4. August 2013, Tartu, Estonia: amenity=university, mappers=yes

Offline

#124 2014-01-13 06:45:07

viw
Member
Registered: 2010-05-15
Posts: 2,623

Re: Überarbeitung von TMC / TPEG

mueschel wrote:

Ich würde versuchen, TMC-Daten möglichst direkt zu übernehmen und nicht nur davon abgeleitete Informationen. Also in erster Linie die Locations selbst, und nur wenn notwendig solche TMC-Links. Wie definiert sich sonst eine Kreuzung? Das wäre ein Punkt, an dem sich mehrere Links treffen. Das ist kaum auszuwerten.
In vielen Fällen sind die Links als Relation hilfreich für die Darstellung, deswegen sollten wir sie als Option in jedem Fall haben, gerade bei komplizierteren Straßenverläufen. In deinem Vorschlag fehlt in der Relation noch die Unterscheidung zwischen einer TMC-Location-Relation und einer TMC-Link-Relation.

Was hat es für einen Vorteil, wenn man jetzt Punkte statt Links verwendet? Für ein Routing benutze ich keine Punkte, sondern immer die davon ausgehenden Wege. Daher ist mein Ansatz die betreffenden Wege mit Tags so identifizierbar zu machen, dass "alle" möglichen Informationen darauf abgebildet werden können.
Außerdem bin ich dafür möglichst wenige Informationen in die Datenbank zu übernehmen. Das macht dann weniger Aufwand und es kann weniger kaputt gehen.
Insebesondere spielt es dasnn nur noch eine kleinere Rolle, wenn ein Knoten gelöscht wird oder aus der Kreuzung verschoben, da der betreffende Weg mit großer Sicherheit noch in Teilen vorhanden und über die Relation zu geordnet ist. Damit kann man die Sperrung dennoch abbilden und Verzögerungen wirken zu mindest auf einen großen Teil des Weges.

Offline

#125 2014-01-13 15:23:15

mueschel
Member
Registered: 2012-06-11
Posts: 1,150
Website

Re: Überarbeitung von TMC / TPEG

Gegen die ausschließliche Verwendung von Links sprechen einige Punkte:
- Punkte kann ich automatisch überprüfen, weil Daten aus der TMC-Datenbank mit denen in OSM übereinstimmen müssen. Bei Links, die in keiner anderen Datenbank auftauchen und erst aus den TMC-Daten rekonstruiert werden müssen wird es kompliziert.
- Viele Meldungen beziehen sich gerade nicht auf Links, sondern auf Punkte. Wie stellst du "Ausfahrt gesperrt" dar? Dabei nützen dir Links nichts, du musst über die Struktur eines Punktes Bescheid wissen - genau das leistet das Proposal von Manuel
- Es gibt keine Möglichkeit, Links automatisch anzulegen. Das ist eine sehr große Arbeit die von Hand gemacht werden muss, weil ich sehr viele Member in die Relation aufnehmen muss. Locations sind viel einfacher. Ein Element ist für die Basis-Funktionalität ausreichend.

Offline

Board footer

Powered by FluxBB