Überarbeitung von TMC / TPEG

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:

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.

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.

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.

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.

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 .

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…

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.

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.

Es ist klar welcher punkt mit welchem Punkt zu verbinden ist. Damit ist auch klar welche Links existieren müssen. Damit kann man die Links zwischen Punkten sehr leicht auf Vollständigkeit prüfen.

Wie will ich denn umsetzen das Auffahrt XY gesperrt ist? Es muss also einen Weg geben, der diese Eigenschaft Auffahrt zu TMC Loc bietet. Diesen kann ich anhand der Tags der Relation erkennen und unbenutzbar machen. dann heißt die Relation nicht mehr TMC Link sondern TMC Auffahrt.

Diese Arbeit muss entweder einmal in OSM gemacht werden, oder nachher in jeder Routingsoftware automatisch. Außerdem hast du ja das gleiche Problem wenn du am Autobahnkreuz eben vier dieser Punkte in einer Location relation anlegen musst. Es wäre also das Gleiche.

Bei allen Routern die ich kenne werden zum Routing Kanten verwendet und keine Punktobjekte. damit müssen also die Eigenschaften von Punktobjekten in Kanten übersetzt werden. Diese Arbeit nimmst du mit den Relationen ab.

Also, ich denke eine mögliche Lösung hier wäre eine Kombination von Elementen aus beidem, d.h. es sollte sowohl Relationen für TMC-Punkte als auch für TMC-Links, d.h. die Strecken zwischen Punkten geben. Allerdings sollten die TMC-Punkt-Relationen im Gegensatz zu meinem Vorschlag nicht unbedingt besagte OSM-Nodes enthalten, sondern ebenfalls OSM-Ways. Bei einem Autobahnkreuz hätte man also Routenrelationen für die Verbindungen zwischen den beiden Autobahnen, genau wie bei den Links zwischen TMC-Punkten. Auf diese Weise lässt sich eine gesperrte Ausfahrt viel besser lokalisieren als wie von mir vorgeschlagen mit 4 Nodes pro Autobahnkreuz.

Hier mal ein einfaches Beispiel, wie das aussehen könnte - zu taggen als Routenrelation, die dort beginnt und endet, wo man die Hauptfahrbahnen von A 2 und A 7 verlässt bzw. befährt:

  • type=tmc

  • tmc:type=ramp

  • tmc:cid=58

  • tmc:tabcd=1

  • tmc:from_point=10509 (AK Hannover-Ost auf der A 2)

  • tmc:from_road=50080 (A 2)

  • tmc:from_dir=positive (positive Richtungsfahrbahn der A 2 nach TMC-Logik)

  • tmc:to_point=12342 (AK Hannover-Ost auf der A 7)

  • tmc:to_road=50163 (A 7)

  • tmc:to_dir=negative (negative Richtungsfahrbahn der A 7 nach TMC-Logik)

Damit hätte man nun diese Verbindung eindeutig erfasst und könnte aus einer Verkehrsmeldung ableiten, was gesperrt ist. Allerdings braucht man so für jedes Autobahnkreuz 8 Relationen, und so ganz beantwortet das nicht alle Fragen nach dem Tagging…

  • Was macht man mit den geraden Zwischenstücken auf der Hauptfahrbahn? Brauchen die auch eine Relation? Wie wird eigentlich gemeldet, dass ein solches gesperrt ist? Das gleiche gilt für solche Zwischenstücke bei einer Autobahnausfahrt.

  • Was macht man bei einer ganz einfachen Kreuzung mit nur einem Node? Gar keine Relation - also letztlich gar nichts? Würde Sinn machen.

  • Wie kann man TMC-Gebiete mappen? Im TMC-Datenmodell gehört jeder Punkt einem Gebiet an. Wenn man also eine Relation pro Punkt hätte, könnte man diese Relationen alle zusammen in eine weitere Relation packen und die dann als TMC-Gebiet taggen. Das geht nicht, wenn man für manche TMC-Punkte gar keine Relation hat. Links zwischen Punkten gehören nicht zu einem Gebiet, sondern sind ausgedehnte Objekte. Hier würden sich vielleicht eher anbieten, TMC-Gebiete als Multipolygone zu mappen, ähnlich den Verwaltungsgrenzen. Allerdings sehe ich da eine ähnliche Problematik wie bei den Postleitzahlen und den Wahlkreisen, wenn man noch eine solche Flächenkategorie einführt, die eng mit Verwaltungsgrenzen verknüpft ist. Nützlich sind solche Gebiete dennoch, weil über TMC Wetterwarnungen dafür übermittelt werden können.

Sind die Zwischenstücke wirklich wichtig? Es ist doch nur wichtig im Zweifelsfall zu verhindern das auf oder abgefahren werden kann. Man dürfte dann also für diese Relation nur die jeweils exklusiven Wege benutzen. Wenn das Zwischenstück dann gesperrt ist, dann ist sind davon zwei Auf- bzw. Abfahrten gestört/gesperrt. Halte ich für kein Problem.
Eventuell gibt es bei Ausfahrten auch die gleichen Meldungen wie bei Parkplätzen. Allerdings nehmen bei neugebauten/sanierten Strecken diese Zwischenstücke ab.
http://www.openstreetmap.org/#map=16/51.0624/13.6038

Relationen können auch nur ein Element enthalten, aber es ist auch ein Node möglich. Sollte das jedoch wieder ein doppelter sein, sind Relationen wegen der doppelten Tags besser.

Man kann in Relationen (Sammlungen) sowohl die einzelnen Location Relationen aber auch die vielleicht einzeln vorkommenden Nodes zu den Regionen vereinigen.

Warum die Links nicht zu den Regionen gehören sollen, weiß ich nicht. Insbesondere wenn hier Wetterinformationen oder sowas geliefert werden, sind das ja nicht nur Punkte sondern wieder vorallem die Wege die davon betroffen sind.

Das sieht schon wieder nach einem komplexen System aus. Ich bin dagegen, mit Links als Grundlage zu arbeiten. Lasst mich meine Überlegungen etwas weiter ausführen:

TMC wird sicher ein Randthema in OSM bleiben - die meisten Mapper werden auch mit einem neuen Schema keine Lust haben sich damit zu beschäftigen. Das führt zu zwei Dingen: Die Wartung muss einfach bleiben, weil sich nicht viele Mapper dafür begeistern lassen. Und, das grundlegende Konzept muss in ein oder zwei Sätzen allgemeinverständlich erklärbar bleiben, sonst wird das ganze nicht akzeptiert.
Auch das Eintragen darf nicht in zu viel Arbeit ausarten. Deswegen sollten wir das ganze modular angehen mit einfachen Dingen, mit denen man das meiste umsetzen kann zuerst.
Schauen wir uns die nötige Arbeit an: Punkt-Locations anlegen, wie zuerst von Manuel beschrieben: Wir reden von 26k Lokationen. Bei komplexen Kreuzungen eine Relation mit vier Punkten wie vorgeschlagen - das ist eine absolut überschaubare Aufgabe (ich will nicht sagen, dass es wenig Arbeit ist, aber das ist machbar). Mit diesen Punkten lassen sich schon viele Dinge machen, zum Beispiel Meldungen auf der Karte platzieren.
Dann der Vorschlag von viw: Link-Relationen anlegen. Es gibt grob geschätzt ebenfalls 26k Links zwischen Punkten, allerdings sind in vielen Fällen zwei Relationen, je eine pro Fahrtrichtung notwendig. Mittlerer Abstand zwischen den Knoten sind vielleicht 5km mit vielleicht 10 ways. Wir haben also mehr Relationen mit viel mehr Members zu pflegen.
Welche Variante ist robuster gegen unabsichtliches Beschädigen? Ich weiß es nicht.
Ein wichtiger weiterer Punkt: Die Link-Relationen lassen sich in vielen Fällen (gerade bei Autobahnen) automatisch gewinnen: Es gibt ohnehin die Straßenrelationen, die von relativ vielen Leuten gepflegt werden. Nun braucht es nur einen Algorithmus der sich diejenigen Wegstücke der Straße herauspickt, die den passenden Knoten von Anfangs- und Endpunktlokation enthalten und dann die dazwischenliegenden Wegstücke herausfinden. Dafür ist nur ein gewöhnlicher Routing-Algorithmus notwendig - mit Programmierarbeit, aber ohne zusätzliche zu pflegende Relationen.

Mein Vorschlag: Zunächst werden Punkt-Locations gemappt, wie beschrieben mit einigen Knoten. Dazu können dann noch Wege mit entsprechenden Rollen in die Relation eingepflegt werden, um Auf/Abfahrten und ähnliches zu kennzeichnen. Zusätzlich können Link-Relationen angelegt werden, die den genauen Streckenverlauf zwischen den Punkten angeben - zum Beispiel bei komplizierteren Streckenverläufen oder einfach der Vollständigkeit halber.

Ich würde sie für nicht mehr oder weniger wichtig halten als die Wege der Ausfahrten. Schließlich können hier genau so Sperrungen, Bauarbeiten oder ähnliche Meldungen vorliegen. Die Frage ich nur, wie sowas in einer TMC-Meldung codiert wird (ich versuche das rauszufinden), dann könnte man vielleicht genau das auf dieses Zwischenstück taggen. In diesem Proposal gibt es Tags für die Zwischenstücke - allerdings nicht für die Auf- bzw. Abfahrten.

Das kann sein, da muss man wohl einfach mal die elektronischen Ohren offen halten und schauen, was so reinkommt.

Naja, auf der A 4 hat man ja immerhin noch ein Zwischenstück zwischen Beginn (Abzweig zur A 17) und Ende (Auffahrt von der A 17 auf die A 4) des Dreiecks, das zu keinem der beiden TMC-Links (A 4 östlich bzw. westlich des Dreiecks) gehört. Genau so ist die Lage ja auch bei Parkplätzen oder einfachen Ausfahrten.

Sehe ich auch so.

Das kann man machen. Wenn man da aber einen einzelnen Node reinpackt, wo taggt man dann dessen Location Code? Eine Relation wäre dann doch wieder besser.

Das liegt daran, dass das TMC-Datenmodell an sich keine Links zwischen Punkten kennt, sondern nur Punkte, Straßen als ganzes (oder Segmente) und Flächen. Punkte, Segmente, Straßen und Flächen können eine Referenz auf eine sie enthaltende Fläche haben - Links dagegen nicht, sondern nur ihre Endpunkte. Für eine lange Bundesstraße kann dann z.B. die Referenz auf die Fläche Deutschland weisen, aber das hilft einem nicht wesentlich, wenn nur für einen Teil Deutschlands eine Warnmeldung kommt.