Überarbeitung von TMC / TPEG

Communities Deutschland (Germany)
#1

Hi,

auf vielfachen Wunsch einer einzelnen Person :wink: hier mal ein passender Thread.

Fragestellung: sollen wir die TMC-Daten weiterhin pflegen, durch das minimalisierte Schema vereinfachen oder ganz “sterben” lassen?

Hintergrund ist die Aussage, daß der Nachfolger TPEG keinerlei spezielle Informationen innerhalb der OSM-Daten benötigt, sondern sich einzig und alleine die bereits erfassten Straßen und Lokalitäten beschränken kann. Der Rest kann -angeblich- durch eine Software-Suche aufgrund der aktuellen GPS-Position im Endgerät erledigt werden.

Gruss
walter

ps: meine Stimme: “Sterben lassen”

#2

Der Titel des Thread istwar für mich etwas zu speziell oder suggestiv. Ich finde die Diskussion sollte darum Kreisen, wie (für das adaptive Routing) Vekehrsinformationen wie TMC und/oder TPEG zusammen mit OSM-Daten verwendet werden können und wie man das am besten umsetzt.

Da klingen meine Alarmglocken. Ist es wirklich besser, das TMC/OSM-Mapping zu “raten” als es explizit aufzuschreiben? Kann ich kaum glauben.

Zu TMC vs. TPEG:

TMC ist de facto aktueller Standard (und das noch eine ganze Weile). Es sollte eine Möglichkeit geben, den zu unterstützen. ich sehe auch nicht, warum wir über entweder TMC oder TPEG entscheiden müssen.

#3

Vorschlag? Ändere ich gerne.

#4

Z.B. “Unterstützung und Abbildung von TMC- oder TPEG-Informationen” ?

Als logisches “Oder” zu verstehen.

#5

Wenn TPEG wirklich keine spezielle Unterstützung seitens OSM benötigt, ist die Frage wohl eher: TMC weiterpflegen oder nicht? Wenn wir es schaffen könnten, TMC korrekt und vollständig zu haben, bevor der Standard sich selbst überholt hat, wäre ich dafür. Wenn nicht, halte ich es auch nur für Ballast, der Neulingen wie mir damals an allen Ecken und Enden im JOSM Fehler um die Ohren wirft :confused:
Insgesamt kenne ich mich mit TMC aber zu wenig aus, als dass ich mehr sagen könnte als: Ich hätte gerne Verkehrsinfos auf OSM-Karten ausgewertet :wink:

#6

Ich bin derzeit nicht informiert genug, um mir eine qualifizierte Meinung zum Thema zu machen. Ich denke aber, dass eine Trennung von Routen-Relationen und TMC/TPEG sinnvoll ist.

Bevor wir entscheiden, die bestehenden TMC-Infos komplett zu vernichten, sollten wir aber einschätzen können, wie falsch/defekt/veraltet sie wirklich sind. Bei den TMC-Areas gibt es ja vielleicht gar nicht so viel Korrekturbedarf.

#7

TMC mag ja Standard sein, aber unsere Daten sind so schrottig, daß sie mMn niemand vernünftig verwenden kann. Frederik hat ja 1-2 potentielle Anwender genannt, aber deren Statement dazu fehlt noch. Ist kein Wunder, die müssen ja nicht unser Forum lesen.

Also: Wer TMC “verteidigen” will, muß (mir) aktive Anwender nachweisen.

Ich werde die Daten jedenfalls nicht pflegen - obwohl es mir gestern durchaus gelungen ist, einen fehlenden TMC-Point nachzutragen. Löschen werde ich sie auch (noch) nicht.

Meine Auswertung der Bundesstraßen wird ab sofort TMC-Daten ignorieren. oops, falscher Thread :wink:

Gruß
walter

#8

Topic-Vorschlag: “Überarbeitung von TMC / TPEG” - das wollte ich gerade als Thread aufmachen, aber ihr wart schneller :wink: Hier also mein Senf primär zu TMC:

Zunächst einmal ein paar allgemeine Infos zu TMC und TPEG. Wozu ist das gut? Es handelt sich um Protokolle, um Verkehrsinformationen zu übertragen die z.B. von Navigationsgeräten ausgewertet werden können, um Staus oder gesperrte Straßen zu umfahren, oder um Autofahrer vor Gefahrensituationen wie Wetterbedingungen oder Unfällen zu warnen. Infos dazu gibt es hier:

http://de.wikipedia.org/wiki/Traffic_Message_Channel
http://de.wikipedia.org/wiki/Transport_Protocol_Experts_Group
http://www.tisa.org/technologies/tmc/
http://www.tisa.org/technologies/tpeg/

Der Standard ist als ISO 14819 verfügbar. Für OSM interessant ist dabei vor allem der Location Code Standard ISO 14819-3, in dem angegeben ist, wie geografische Punkte in Form von Location Code Tabellen codiert werden. Für Auswerter / Navi-Programme ist außerdem der Event Code Standard ISO 14819-2 wichtig, in dem die Codierung von Ereignissen wie Staus oder Unfällen angegeben ist.

Die Idee von TMC in OSM besteht darin, dass man mit dem Tagging von Location Codes in OSM unmittelbar die Straßen finden kann, auf die sich ein Location Code und damit eine Verkehrsmeldung bezieht. Allerdings ist das derzeitige in Deutschland vorhandene Tagging, das aus einem Import stammt, mehr als unübersichtlich und entzieht sich einer Wartung:

http://wiki.openstreetmap.org/wiki/DE:TMC/TMC_Import_Germany

Ein besseres und übersichtlicheres Tagging wurde hier vorgeschlagen:

http://wiki.openstreetmap.org/wiki/DE:Proposed_features/New_TMC_scheme

Das mag noch nicht perfekt sein, könnte aber als Grundlage für die Erarbeitung eines finalen Proposals dienen. Wie das genau aussehen soll, kann und muss man sich natürlich überlegen. Das sollte der erste Schritt sein, wenn wir TMC weiterhin in OSM haben und vor allem auch pflegen wollen.

Das eigentliche Einpflegen der Daten scheint dagegen nicht besonders schwierig zu sein. Die Tabelle der deutschen Location Codes (ca. 46300 Codes) bekommt man auf jeden Fall hier umsonst vom BASt:

http://www.bast.de/cln_030/nn_42544/DE/Aufgaben/abteilung-f/referat-f4/f4-LCL/location-code-list-start.html

Darin enthalten sind die Location Codes, die offiziellen deutschen Bezeichnungen der Event Codes (interessant für Auswerter) und eine kurze, aber verständliche Beschreibung der mitgelieferten Daten. Die Location Code Tabelle gibt es u.a. als CSV-Datei. Für jeden Location Code findet man dort z.B.:

  • Location Code Nummer

  • Objektklasse (Fläche, Linie oder Punkt)

  • Typ (Verwaltungsbezirk, Straße, Straßenabschnitt, Kreuzung…)

  • Subtyp (Autobahnkreuz, Autobahndreieck, Autobahnausfahrt…)

  • Koordinaten (WGS84)

  • Referenz auf übergeordnetes Gebiet (“dieser Punkt ist im LK Gifhorn”)

  • Referenz auf übergeordnete Straße oder Segment (“dieser Parkplatz liegt am A 7 Abschnitt Hamburg - Hannover”)

  • Referenz auf benachbarte Punkte entlang der übergeordneten Straße (vorhergehende / nächste Ausfahrt etc.)

  • Namen und Referenznummern von Objekten - Straßen, Straßensegmenten, Parkplätzen, Rastanlagen…

  • Namen von Anfang und Ende eines Straßensegments (Hamburg - Hannover o.ä.)

  • Zusatzinformationen (Parkplatz nur in nördlicher Fahrtrichtung vorhanden, Autobahn kann nur in westlicher Richtung befahren werden…)

Damit ist es auf jeden Fall sehr einfach, GPX-Dateien zu erstellen, die dann, nach Region sortiert, die dortigen Features enthalten und einem Mapper als Quelle dienen können. Die Daten an sich sollten also kein Problem darstellen. Für den Anfang wichtiger und vermutlich nicht ganz einfach ist wohl die Erarbeitung eines sinnvollen, wartbaren Taggings. Man könnte vielleicht so vorhehen:

  • Bessere Dokumentation der verfügbaren Daten und des TMC-Datenmodells im Wiki

  • Grafische Übersicht der Daten?

  • Erarbeitung eines Tagging-Schemas, z.B. basierend auf dem o.g. Proposal

  • Bereitstellung der Daten z.B. als GPX oder in einer anderen für Mapper aufbereiteten Form

  • Einpflegen der Daten und Bereinigung / Löschung der veralteten TMC-Daten

So weit der Stand der Dinge. Der erste Punkt dürfte wohl keiner großen Diskussion bedürfen, den werde ich deshalb in Angriff nehmen und dabei auch die Wiki-Seite zu TMC etwas überarbeiten / ausbauen:

http://wiki.openstreetmap.org/wiki/TMC

EDIT: Naja, das war eigentlich als zusammenfassender un einleitender Eröffnungspost gedacht :wink: Also ich denke, wenn wir uns hier überlegen, ob wir TMC in modenisierter Form erfassen (und ich sage nicht behalten - den derzeitigen Datenbestand behalten halte ich für sinnlos), sollte auf jeden Fall umrissen werden, was genau das für Daten sind, wie sie aussehen und was sie aussagen. Siehe eben dieser Post.

#9

Ich mag noch nicht glauben, dass Geo-Koordinaten alleine ausreichen. TPEG-Loc gibt z.B. ja auch Infos zu Ausfahrten etc. an. Aus dem Wikipedia-Artikel:

Auch wenn man keinen “TPEG-Code” bräuchte, müsste OSM zumindest gewisse Voraussetzungen erfüllen (z.B. Ausfahrtnamen o.ä.), um die Zusatzinformationen zu verarbeiten.

Da TMC in Millionen von Navis verwendet wird, gehe ich nicht davon aus, das in weniger als 5-10 Jahren stirbt.

#10

Es gibt keine TPEG-Informationen, die man irgendwie in den OSM-Daten unterstützen müsste/könnte - das ist ja gerade das Reizvolle daran (für mich).

Gruss
walter

was man eventuell bräuchte, ist ein Software-Modul, daß aus der von TPEG per Funk/Inet/Wlan/? übermittelten GPS-Position “DA ist ein Stau in Richtung xxx”, die richtige Stelle sucht.

#11

Ich bin nicht generell für TMC, sondern für ein behutsames Vorgehen. Aber ich sage auch, OSM sollte nicht nur die schützen, die es derzeit aktiv nutzen, sondern auch bestrebt sein, mehr Nutzer/Anwender zu gewinnen. Die Katze beißt sich in den Schwanz, wenn wir nur unterstützen wollen, was schon genutzt wird.

#12

Es gibt auch den Ansatz von Telenav ein eigenes Segmentierungssystem für OSM zu verwenden. Ob jetzt dieses oder noch ein anderes, ich denke es wäre zielführender sich Gedanken zu machen wie sowas für OSM aussehen könnte. Mit Einbezug von Überlegungen wie dies möglichst mapper-freundlich gemacht und auch zur Meldung (automatich oder manuell) von Problemen genutzt werden kann.

Die Segmentierungen eines Drittystems (TMC oder was auch immer) dann darauf abzubilden kann dann extern geschehen. Ich denke dies wäre auch eher im Sinn des Projektes als proprietäre Daten (TMC) in OSM zu importieren, die in weiten Teilen der Welt nur gegen Lizenzgebühren erhältlich sind.

Simon

#13

Wäre ja schön. Wie wird eine Warnung “Klotz auf der Fahrbahn” bei Autobahnen einer Fahrtrichtung zugeordnet? Durch zwei Koordinaten, die eine Richtung beschreiben? Klingt irgendwie hässlich.

#14

Klingt gut. Wie robust wäre dieses externe Mapping bei Änderungen wie aufgetrennten Wegen? Wenn man das auf Segmente von intakten Routenrelationen beziehen könnte, wäre das wohl gangbar.

#15

Komisch ist es schon, aber da muß man erst mal durch die Spezifikationen von TPEG durchsteigen um zu verstehen, wie das wirklich funktioniert/funktionieren soll - was ich auch noch nicht gemacht habe. Dazu ist das Thema hier noch zu frisch.

Aber eines ist mir klar: Es werde im Datenbestand der Anwendung/des Navis keinerlei TPEG-spezifischen Daten benötigt, kein TPEG-Point, TPEG-Segment oder gar TPEG-Area. Die kriegen das irgendwie hin und das reicht mir momentan.

Gruss
walter

ps: Total OT: 7 PLZ-Rels missing, bin schon dran.

#16

So viel ich weiss ist bei TTL (den Telenav Vorschlag einfach mal als Beispiel genommen, siehe auch http://wiki.openstreetmap.org/w/images/1/16/SotM2012_Telenav_Traffic_Locations.pdf ) dies eine einfache ID, sprich es überlebt mindestens so gut (oder so schlecht) wie das aktuelle TMC Gewusel.

IMHO ist es aber eher den Mappern beizu bringen, die “OSMTrafficId” an einem Objekt nicht zu entfernen, als irgendwelchen undurchsichtigen TMC-Salat. Desweiteren könnte man, wenn tatsächlich ein OSM-weites System und nicht nur ein Deutsches eingeführt würde, dies auch in den Editoren ohne grossen Aufwand speziell behandeln…

Simon

#17

Der Vollständigkeit halber hier noch mal der TMC-Link von Infoware/Geofabrik:

http://osm-tmc.infoware.de/tmc/

#18

So ein OSM-eigenes System wäre natürlich auch nett, wenn man denn hinterher gut z.B. einen TMC-Verkehrhinweis in eine OSM-Streckeninformation übersetzen kann. In so einem Fall sollte man es zumindest so weit kompatibel / allgemein halten, dass man von TMC, TPEG oder anderen Quellen für Verkehrsinfos eindeutig und umfassend übersetzen kann. Das mag nicht unbedingt einfach sein, aber auch nicht unbedingt unmöglich. Wie schwer genau, kann ich schwer einschätzen.

Den Vorteil z.B. von TMC (und in Zukunft TPEG) sehe ich darin, dass es sich um einen wohldefinierten Standard handelt, den eine Gruppe von Leuten in einem gewisse Zeit dauernden Prozess erarbeitet hat. Da steckt also schon viel Überlegung drin, die man für einen eigenen Standard erst einmal auf die Beine stellen müsste.

Nach einem ersten Blick auf den TPEG-Loc-Standard ISO TS 14234-6 finde ich ehrlich gesagt nicht ganz überzeugend, wie man dort ein Objekt sicher finden soll… Dort ist als Beispiel eine Beschreibung für “Terminal 1 des Flughafens Frankfurt” angegeben - viel Spaß beim Entziffern:

location_co-ordinates
location_type: nodal area (loc01_2)
mode_type_list
mode_of_transport: aircraft (loc05_9)
mode_of_transport: railway (loc05_2)
point
WGS 84
longitude: E 8.56964
latitude: N 50.05062
radius of expansion: 3 km
descriptor
type: tpeg-ilc1 (loc03_7)
text: A03
descriptor
type: tpeg-ilc2 (loc03_8)
text: B43
descriptor
type: tpeg-ilc3 (loc03_9)
text: Hugo-Eckener-Ring
descriptor
type: node name (loc03_2)
text: Frankfurt Airport

Also das auszuwerten stelle ich mir gruselig vor, jedenfalls deutlich komplexer als eine einfache ID. Und wenn dann noch ein Tippfehler in einem Straßennamen ist, klappt das Matching auch nicht mehr.

Ich denke, wir sind und einig darin, dass das aktuelle TMC-Gewusel unbrauchbar ist und aufgeräumt / abgelöst / rausgeworfen werden sollte. Es sollte also eher verglichen werden zwischen einem OSM-eigenen System und einem neuen, besseren TMC-Mapping, das nicht so ein Gewusel darstellt. Dann hätte man vermutlich in beiden Fällen eine einfache ID.

Ein neues Tagging sollte auf jeden Fall international einheitlich sein, gar keine Frage - egal ob nun TMC oder OSM-eigen. Es stimmt natürlich, dass TMC nicht den ganzen Globus abdeckt. Hier in Estland ist es z.B. (derzeit) nicht im Einsatz, aber wohl in Planung (so weit ich ein Proposal verstanden habe, das ich auf der Webseite des hiesigen Straßenbauamtes gefunden habe). Was für Systeme es in anderen Ländern gibt, wo es kein TMC gibt, habe ich noch nicht herausgefunden.

#19

Ich würde in keinem Fall Perfektion anstreben (Deutsche Krankheit), sondern einfach gut genug, sprich es muss nicht jede Feinheit jedes Systems 1 zu 1 abbildbar sein.

Es geht weniger darum wie verbreitet TMC ist, sondern das die entsprechenden Tabellen für andere Länder nur gegen Geld erhältlich sind.

#20

Das Hauptproblem sind ja weniger die vielen Punkt-Lokationen, sondern vielmehr die aufwendige Pflege der vielen Routen. Wie wäre es also mit dem Vorschlag, zumindest diese Punkte soweit möglich vollständig in OSM zu haben? Also, folgende Informationen, sortiert in absteigender Wichtigkeit (!):

  1. Alle (wichtigen) Punkte mit TMC-ID, Typ erfassen. Das lässt sich einfach validieren und ist auch überschaubarer Aufwand.
  2. Alle wichtigen Punkte mit einem Tag versehen, mit welchen anderen Punkten sie durch Strecken verbunden sind (tmc_connected_to=id1;id2;id3)
  3. Eine saubere Form der bisherigen TMC-Routen einführen und diese Routen dort anlegen, wo man Wert auf solche Details legt.