DE talk:Proposed features/New TMC scheme

Vereinzeltes

"Zur Nutzung der Daten müssen die Gebiete dann zusammengefasst werden." Hier sollte man vielleicht noch einen genaueren Hinweis geben, dass diese Zusammenfassung eben erst im Postprocessing erfolgen muss, und nicht in den OSM Daten. --Dieterdreist 20:33, 29 March 2012 (BST)

"/" als Trennzeichen

Unter Punkt 4.6: "Anwendungsfall: Keine getrennte Richtungsfahrbahn" führt ihr den Schrägstrich ("Slash") als Trennzeichen mehrerer Werte ein. Nach meinem - beschränkten - Wissen bereitet dieses Zeichen vielen Auswerte-Programmen Probleme. Vielleicht ist daher ein anderes Zeichen sinnvoller, z.B. der senkrechte Strich ("Pipe"): "|".

Davon unabhängig: Müsste es nicht heißen "D.h. 'A/B' wird bei der Nutzung der Daten übersetzt in 'A+B;B-A'" (ebenfalls unter 4.6)? --Seoman 13:19, 30 March 2012 (BST)

Ich wüsste kein Programm, das mit dem / Probleme hätte. -- Eckhart 22:11, 1 July 2012 (BST)

Auswirkungen von TMC-Nachrichten an Kreuzungen

Resolved

Ich beziehe mich im folgenden auf dieses Bild

Nehmen wir an, dass laut TMC Stau zwischen LCD 20 und LCD 5 (in dieser Richtung) ist. Dann sind alle Wege betroffen, die mit tmc=DE:5-20 getaggt sind. Dadurch kriege ich aber auch eine Staumeldung, wenn ich von LCD 50 nach LCD 8 will, oder? -- Eckhart 18:04, 1 April 2012 (BST)

Im OSM-Info-Treffen diskutiert. -- Eckhart 22:12, 1 July 2012 (BST)

Mapping auf Ways etc.

Generell halte ich (TrafficJam) es für eine gute Idee, das komplizierte Tagging der TMC-Daten zu vereinfachen modizifieren. Der hier vorgeschlagene Ansatz ist zwar sehr gut geeignet, um Anwendungen zu schreiben, die auf diesen Tags heraus Verkehrsmeldungen darstellen, aber nicht besonders komfortabel für Mapper und nicht rebust gegenüber Änderungen

• Zum Namensschema: die TABCD direkt Länderkürzel zu schreiben (FR17:19523) ist inkonsistent. Wenn man schon eine Hierarchie abbilden möchte, dann so FR:17:19523. Überflüssige Doppelpunkt lassen sich auch hier weglassen (vgl. IPv6)
• Ich finde es (für den Maper) generell schlecht, statt der Nodes die Ways mit TMC-Informationen zu taggen.
  • Die Location Code List (LCL) arbeitet stark punkt-orientiert und auch OSM arbeitet so. Diese gelernte Verhalten aufzugegeben, halte ich für falsch. Die Nodes kann der Mapper direkt aus der LCL lesen und 1:1 eintragen.
  • Eine Umstellung auf Ways bedeutet einen hohen Aufwand. Man kann das bisherige Mapping nicht einfach nach Regeln ins neue übertragen. Da zudem eine Verbindung zwischen zwei TMC-Knoten meist durch mehr als einen Way erfolgt, müssen mehr Daten in OSM gepflegt werden, das Risiko von Lücken und Inkonsistenzen steigt.
  • Man kann nicht mehr einen Algorithmus über einen OSM-Auszug laufen lassen, der prüft, ob alle Locations eines LCL (bzw. einer Klasse) bereits gemappt wurden.
  • Da Übertragen der Rückwärtsdenke von TMC in die Way-Tags halte ich nicht für intuitiv: DE:39345-41005, DE:41005+39345 ist für Menschen auch nicht intuitiv lesbar, denn das Minus wird leicht als Bereich (von/bis) und Plus als Aufzählung/Reihung interpretiert. Wenn man nun noch den Schrägstrich und die Verkettung per Semikolon hinzunimmt, ist die Verwirrung komplett
  • bislang ist nicht gewährleistet, dass jeweils ein OSM-Way auch an einem TMC-Knoten beginnt oder endet, d.h. man müsste viele neue Ways einführen
• Warum kann man bei einzelnen Locations die Länderlokation wegelassen DE:123-DE:456 -> DE:123-456, aber bei Aufzählungen nicht (DE:123-456;DE:333-444, aber nicht DE:123-456;333-444)?
• Versionskennzeichen halte ich für unerlässlich. Wenn man dieht, wie stark sich mit jeder Liste die Locations ändern, dann ist gerade die vorgeschlagene Way-Bezeichnung problematisch.
  • Beispiel (sehr häufig): Zwischen den Locations 123 und 789 wird die Location 456 neu hinzugefügt.
  • Fall 1: Kommt nach dem heutigen Modell eine TMC-Meldung mit 123 und Extent 1, wird bei einem veralteten LCL-Stand in OSM (oder im Navi) zu viel eingefärbt (nämlich die Strecke von 123-789). Nach dem neuen Vorschlag wird nach den Ways DE:123+456 gesucht, die es nicht gibt, also gar nichts eingefärbt.
  • Fall 2: Kommt die Meldung 456 mit Extent 1, dann wird in beiden Varianten nichts eingefärbt (ist auch OK so).
  • Die Karte ist also noch weniger robust gegen LCL-Wechsel als bisher. Und heute kann ich beim betroffenen Node in der OSM-Karte einfach nachsehen, ob ein Punkt bereits auf dem aktuellen LCL_Stand ist oder veraltet...

Die Migration zum neuen Schema würde massive Aufwände produzieren. Was soll das leisten und vor allen wer sorgt für ein zeitnahes Nachziehen nach einem LCL-Wechsel?

Fazit: Ich wäre von einer solch massiven Umstellung nicht begesitet und würde eher behutsam (auf Node-Basis) vorgehen:

1. Vereinfachung der Prefixes von TMC:cid_CID:tabcd_TABCD:... (ließe sich dann autoamtisch migrieren)
2. Mapping von mehreren TMC Location Codes auf einen OSM node durch eine Aufzählung statt durch Umsetzung mal durch Tags und mal durch Relationen

Meine Gedanken hierzu:

• "Der hier vorgeschlagene Ansatz ist […] nicht rebust gegenüber Änderungen" - meiner Erfahrung nach ist das alte Schema noch viel anfälliger.
• "Zum Namensschema: die TABCD direkt Länderkürzel zu schreiben (FR17:19523) ist inkonsistent. Wenn man schon eine Hierarchie abbilden möchte, dann so FR:17:19523." - stimme ich zu.
• "Überflüssige Doppelpunkt lassen sich auch hier weglassen (vgl. IPv6)" - IPv6 ist hier wohl nicht das richtige Vorbild.
• "Da zudem eine Verbindung zwischen zwei TMC-Knoten meist durch mehr als einen Way erfolgt […]" - das ist ein Argument für das neue Schema!
• "Man kann nicht mehr einen Algorithmus über einen OSM-Auszug laufen lassen, der prüft, ob alle Locations eines LCL (bzw. einer Klasse) bereits gemappt wurden." - das Problem kann ich nicht nachvollziehen.
• "DE:39345-41005, DE:41005+39345 ist für Menschen auch nicht intuitiv lesbar, denn das Minus wird leicht als Bereich (von/bis) und Plus als Aufzählung/Reihung interpretiert." - stimme ich zu, vielleicht wäre hier DE:39345<-41005 bzw. DE:41005->39345 besser geeignet?
• "bislang ist nicht gewährleistet, dass jeweils ein OSM-Way auch an einem TMC-Knoten beginnt oder endet, d.h. man müsste viele neue Ways einführen" - richtig, aber IMHO nicht so tragisch.
• "Warum kann man bei einzelnen Locations die Länderlokation wegelassen […], aber bei Aufzählungen nicht" - stimme ich ebenfalls zu.
• "Versionskennzeichen halte ich für unerlässlich. Wenn man dieht, wie stark sich mit jeder Liste die Locations ändern, dann ist gerade die vorgeschlagene Way-Bezeichnung problematisch." - stimme ich teilweise zu. Es sollte optional möglich sein, die Version mit anzugeben. Eine Möglichkeit wäre DE:v2:39345 (das "v" dient dazu, Mehrdeutigkeiten zu vermeiden; FR:2:v3:39345 wäre dann die dritte Version der zweiten Tabelle von Frankreich). Tatsache ist, dass sich solche Versionsprobleme mit dem neuen Schema aber relativ einfach erkennen lassen, wenn die zugehörigen Tabellen vorhanden sind.

-- Eckhart 14:56, 2 April 2012 (BST)

Versionierung

Der Umstand, dass sich die TMC-Stammdaten unter Umständen ändern, ist in der Diskussion bereits angesprochen worden. Es gibt hierzu auch einen Abschnitt im Proposal:

Versionen

Ich denke, man kann ausschließen, dass die "zuständigen Stellen" eine zuvor bereits vergeben ID in einer aktualisierten Version ihres Datenbestandes auf einmal für eine Location an einer anderen Stelle vergeben. Für wie relevant wird die Frage der Versionierung vor diesem Hintergrund betrachtet? --infoware_kna 15:28, 2 April 2012 (BST)

Das Beispiel von oben "Zwischen den Locations 123 und 789 wird die Location 456 neu hinzugefügt." wird von der Erklärung leider nicht zufriedenstellend abgedeckt. Außerdem setzt der Vorschlag im Text voraus, dass die Daten auf Endgeräten einigermaßen aktuell sind. Aus Erfahrungen mit MapDust kann ich jedoch sagen, dass teilweise drei Monate alte Routingdaten verwendet werden. -- Eckhart 16:29, 2 April 2012 (BST)

Robustheit

Ich möchte hier zusammentragen, wie gut das Schema mit Änderungen zurechtkommt.

JOSM

• Aufspalten von Wegen: unproblematisch, die Daten werden nicht beeinträchtigt.
• Kombinieren von Wegen: ein Kombinieren von Wegen mit unterschiedlichen TMC-Daten produziert einen Konflikt im tmc-Key. Der Lösungsvorschlag von JOSM ist wieder ein gültiger Wert (mit ; getrennte Einträge). Ein Kombinieren von Wegen mit gleichen TMC-Daten ist unproblematisch.
• Punkte vereinigen: unproblematisch, da keine Informationen an Punkten gespeichert werden
• Wegrichtung umkehren: problematisch; beim Drehen müsste aus DE:12/20 ein DE:20/12 werden
  • Sollte für JOSM kein Problem sein. Analog wie left/right, forward/backward, up/down ... Bei solchen Tags erzeugt JOSM schon einen Konflikt und schlägt das jeweilige Pendant vor. --Skyper 15:56, 15 April 2012 (BST)
    • Denkfehler? Im Text steht folgendes Zitat: Welche Richtung die positive ist und welche die negative ergibt sich aus den TMC-Datensätzen. Diese Information ist prinzipiell beliebig, sie kann nicht automatisch abgeleitet werden, ohne die TMC-Datensätze zu verwenden. Daher muss sie in den Tags auftauchen, wenn man die Daten auch ohne die TMC-Datensätze verwenden will. Daraus folgere ich, dass für die positive/negative Richtungsangabe eine Glaskugel erforderlich ist. Hoffentlich ist das nur missverständlich formuliert, sonst ist das Schema damit bereits gestorben.
    • Sollte das aber tatsächlich doch mit der Wayrichtung zusammen hängen, könnte man, statt Positiv/Negativ, was kaum ein Mapper verstehen wird, einfach forward/backward nehmen. Josm kann damit bereits umgehen. Dann wird beim Umdrehen des Ways aus "12 forward 20" ein "12 backward 20". Wer will, kann das zu einem "20 forward 12" manuell umdrehen. Das sieht wielleicht nicht so schön aus, wird aber vom Mapper eher verstanden.
    • Auch dann bleibt das Problem der Aufteilung von Richtungsfahrbahnen. Wenn ein Way mit "12/20" getaggt ist, weiß dann niemand, wo 12 und wo 20 ist und welche Richtungsfahrbahn dann forward/positiv/+ oder backward/negativ/- ist.
    • Besser wäre es, die tmc-Tags an die Kreuzungspunkte zu setzen. Im Fall einer einfachen Kreuzung bekommt der Punkt dann ein Tag tmc=DE:12345;6789. Im Fall einer komplizierteren Kreuzung bekommen entweder alle Kreuzungspunkte das Tag oder sie werden Mitglieder einer (Kreuzungs?-)Relation, die das Tag einmalig bekommt. Falls Tags an die Ways gesetzt werden sollen, kann der Mapper die forward/backward-Tags leicht selbst setzen. Ein recht einfach zu gestaltender JOSM-Stil würde da sogar für Übersicht sorgen.
    • Ggf. daraus abzuleitende Positiv/Negativ-Richtungen sind Sache der Auswertungssoftware. Nach allen Regeln von OSM ("On the ground"!) wird hier ohnehin bereits weit im Grenzbereich gesegelt. Ein Positiv/Negativ ist beim besten Willen für einen Mapper weder erkennbar noch verständlich.
    • Osmonav 2.2.2014

Neues Proposal

Hier ist ein geändertes Proposal von mir. Wesentliche Änderungen sind hervorgehoben. -- Eckhart 21:40, 28 April 2012 (BST)

Ländercodes und Tabellen

TMC benutzt zur eindeutigen Bezeichnung eines Ortes (Location) die Kombination aus

• CID (Staat, Country ID),
• TABCD (Datensatznummer, Table Code),
• Version und
• LCD (Location Code).

Alle vier sind beliebig vergebene Ganzzahlen (Integer).

Für OSM fassen wir diese hier Angaben zu einer zusammen. Statt der CID schreiben wir einen ISO 3166-1 Alpha-2 Country Code (CC), wie man ihn von verschiedenen anderen Stellen innerhalb und außerhalb von OSM schon kennt, für Deutschland beispielsweise "DE". Das ist viel leichter zu verstehen als der CID (für Deutschland wäre das 58).

Die Datensatznummer (TABCD) wird nur angegeben, wenn es für dieses Land wirklich verschiedene Datensätze gibt. In Deutschland ist das z.B. nicht der Fall. In jedem Fall darf die Datensatznummer nur weggelassen werden, wenn sie die erste Datensatznummer aus dem Bereich ist, der für ein Land vergeben wurde. (So wird sichergestellt, dass bei der zukünftigen Einführung weiterer Datensätze alle Angaben eindeutig bleiben. Welche Datensatznummern für ein Land vergeben wurden ergibt sich aus dem ISO-Standard.)

Die Version wird nur angegeben, wenn es tatsächlich notwendig ist. Sie wird geschrieben als vVERSION, wobei VERSION die Version darstellt. (Ob es tatsächlich Anwendungen für die Version gibt, ist nicht klar.)

Der Location Code muss natürlich immer angegeben werden.

Zwischen den Bestandteilen wird ein Doppelpunkt als Trennzeichen verwendet. [Begründung: Der Doppelpunkt wird auch an anderer Stelle bei OSM im Sinne eines hierarchischen Trennzeichens verwendet.] Die Reihenfolge der Komponenten ist wie hier angegeben.

Zusammenfassend kann also weltweit eindeutig jede TMC-Location so angegeben werden:

 CC[:TABCD][:vVERSION]:LCD

Beispiele

Zwei Beispiele für einen Location Code in Deutschland und in Frankreich. Da es in Deutschland nur eine Tabelle gibt, entfällt der Tabellencode.

 DE:82058
 FR:17:v2:19523 (falls in Frankreich mehrere Tabellen verwendet werden und es
             eine Tabelle mit Nummer 17 gibt; es wird die 2. Version der Tabelle referenziert)

Dieses Format ist sehr kompakt und enthält trotzdem genau die nötigen Informationen.

Weitere Konventionen

[...]

Tagging von Point Locations an Ways

Wie oben beschrieben sind in Verkehrsmeldungen typischerweise jeweils eine Point Location, eine Direction und ein Extent angegeben. Aus diesen Informationen müssen nun die OSM-Ways und auf jedem von diesen die Richtung bestimmt werden, die betroffen sind. Am einfachsten ist das, wenn die Richtung(en) der Ways bereits mit genau dieser Information bestückt sind.

Dazu speichern wir an jedem Way für jede (befahrbare) Richtung einen Tag:

 tmc:forward=DE:12345+58934

Wenn wir diesen Way in der Richtung befahren, in der er in OSM gespeichert ist (also vorwärts), kommen wir also von der Location 12345 in positiver Richtung zu Location 58934. Da TMC immer rückwärts denkt, muss man das entgegen der Fahrtrichtung lesen! Dieser eine Tag enthalt dabei zusammengefasst alle nötigen Informationen, anders als beim alten Schema sind weitere Tags nicht nötig.

Geht die Fahrt entlang der TMC-Punkte in negativer Richtung, wird ein Minuszeichen ('-') verwendet:

 tmc:forward=DE:39345-41005

Lässt sich ein OSM-Way (auch/nur) in der Richtung vom Endpunkt zum Anfangspunkt befahren, wird ein weiterer Tag für die Rückrichtung des Weges benötigt:

 tmc:backward=DE:45678+90123

So ein Tag beschreibt also immer die TMC-Informationen für eine Richtung des OSM-Ways; tmc:forward=* ist gültig, wenn man sich in der Reihenfolge der Knoten des Ways bewegt; tmc:backward=* ist gültig, wenn man sich entgegen der Reihenfolge der Knoten des Ways bewegt. Innerhalb des TMC-Netzes bewegt man sich dabei immer vom ersten LCD zum zweiten LCD.

Ausdehnung von Point Locations

Viele Point Locations haben in der Wirklichkeit eine Ausdehnung. Wenn man z.B. auf einer Autobahn ein Autobahnkreuz passiert, so geht das Autobahnkreuz von der ersten Abfahrt bis zur letzten Auffahrt (von der Autobahn aus betrachtet). Dieser Bereich ist dann nicht zwischen zwei Point Locations, sondern genau an einer Point Location. Aus diesem Grund wird er besonders ausgezeichnet:

 tmc:forward=DE:41005+

Wenn wir den Way in der Vorwärts-Richtung befahren, dann befinden wir uns also gerade an der Point Location 41005 und bewegen uns in positiver Richtung der Point Locations.

Die Information, dass wir uns an einer Point Location befinden, ist insbesondere dann wichtig, wenn TMC-Messages mit Extent 0 übertragen werden.

In keinem Fall werden hier Nodes getagged. Alle Tags sind an Ways.

Anwendungsfall: Getrennte Richtungsfahrbahnen

Liegen getrennte Richtungsfahrbahnen vor, die jeweils nur in einer Richtung befahren werden können (z.B. auf einer Autobahn), so ist die eine Richtung getagged mit:

 tmc:forward=DE:123+456

die andere mit:

 tmc:forward=DE:456-123

Anwendungsfall: Keine getrennte Richtungsfahrbahn

Sind die Richtungsfahrbahnen nicht getrennt, so werden beide Richtungen des Ways getagged:

 tmc:forward=DE:123+456
 tmc:backward=DE:456-123

Die Zuordnung zu den Richtungen ist von der Lage des Ways abhängig. Insbesondere führt ein Umdrehen des Ways dazu, dass tmc:forward=* und tmc:backward=* ihre Werte tauschen.

Als Abkürzung ist hier optional erlaubt:

 tmc=DE:123/456

D.h. "A/B" wird bei der Nutzung der Daten übersetzt in "A+B;B-A".

(Das Zeichen / wird hier zunächst exemplarisch verwendet. Aus technischen Gründen seitens OSM könnte die Verwendung eines anderen Symbols erforderlich sein. Dieser Text wird dann entsprechend angepasst.)

[...]

Anwendungsfall: Kreuzung, getrennte Fahrbahnen

Im Bereich einer Kreuzung ist die eine Richtung getagged mit

 tmc:forward=DE:123+

und die andere mit

 tmc:forward=DE:123-

(In diesem Beispiel wurde tmc:forward=* der Übersichtlichkeit halber weggelassen.)

Anwendungsfall: Kreuzung ohne getrennte Fahrbahn

Sind die Richtungsfahrbahnen nicht getrennt, so werden beide Angaben getagged:

 tmc:forward=DE:123+456
 tmc:backward=DE:123-543

Nach diesem Schema gehören alle Straßen immer genau zur Verbindung zweier Locations oder sie werden überhaupt nicht getagged. Es kann daher nicht passieren, dass eine Straße mit nur einem Location Code getagged wird.

Welche Richtung die positive ist und welche die negative ergibt sich aus den TMC-Datensätzen. Diese Information ist prinzipiell beliebig, sie kann nicht automatisch abgeleitet werden, ohne die TMC-Datensätze zu verwenden. Daher muss sie in den Tags auftauchen, wenn man die Daten auch ohne die TMC-Datensätze verwenden will.

Durch die Angabe der Location Codes für Anfang und Ende einer Strecke ergeben sich so "Ketten" von Ways durch alle Locations:

        123                456                105        
 --------*------------------*------------------*---------
     ← (123-) ← 456-123 ← (456-) ← 105-456 ← (105-) ←    
     → (123+) → 123+456 → (456+) → 456+105 → (105+) →    

Durch Angabe der Richtung (+/-) kann direkt die richtige Strecke aus den TMC-Meldungen extrahiert werden, ohne dass der TMC-Datensatz noch gebraucht wird.

Natürlich kann eine Strecke zwischen zwei Locations aus mehreren Ways bestehen, die dann alle gleich getagged werden.

Bleibt noch die Frage: Wo genau hört eine Strecke auf und fängt die nächste an? Definition ist hier: In Fahrtrichtung gesehen fängt die neue Strecke hinter der letzten Ausfahrt oder Einfahrt einer Kreuzung an und sie geht dann bis zur letzten Ausfahrt oder Einfahrt der nächsten Kreuzung. Um den Grund zu verstehen, muss man wieder in TMC-Art "rückwärts" denken. Wenn an der Anschlußstelle Karlsruhe-Nord (54975) eine Abfahrt gesperrt ist, dann wird das übertragen als "LCD 54975, negative Richtung, extent 0, Abfahrt gesperrt". Dann muss sich die Abfahrt natürlich auf dem Stück Weg befinden, das mit tmc=DE:54975-xxx getagged ist, damit sie gefunden werden kann.

Das folgende Beispiel eines Autobahnkreuzes illusttriert, wo der Location Code gewechselt werden muss. Der Wechsel sollte sinnvollerweise dort stattfinden, wo ein weiterer Verkehrsstrom einmündet. Nach der Verknüpfung dieser Ways wird das Schema dann mit dem neuen Location code fortgesetzt.

Anwendungsfall: Autobahnkreuz

Mit den einfachen Regeln, die wir vorgestellt haben, lassen sich auch komplexe Anwendungsfälle abdecken.

(In diesem Beispiel wurde tmc:forward=* der Übersichtlichkeit halber weggelassen.)

Anwendungsfall: Kreisverkehr

Anwendungsfall: Sperrung einer Autobahnabfahrt

Fehlererkennung

Es gibt mehrere Fehlerquellen, die programmtechnisch erkannt werden können:

Syntaxfehler

tmc:forward=* und tmc:backward=* können mittels eines regulären Ausdrucks auf Korrektheit überprüft werden. Hierzu werden keine TMC-Tabellen benötigt.

Geometrische Fehler

Mit TMC-Informationen versehene Ways sind miteinander verbunden. Löcher können entdeckt werden, indem diese Verbindung überprüft wird. Fehler entstehen somit an Anfangs- und Endknoten von Ways: An jedem Knoten v gilt: endet ein Way mit tmc:forward=X an v oder beginnt ein Way mit tmc:backward=X an v, so muss es einen Way mit tmc:forward=Y geben, der an v beginnt, oder einen Way mit tmc:backward=Y, der an v endet, wobei der Wert Y von X abhängig ist:

X	Y
A-B	A-B oder B- oder B-C}}
B-	B- oder B-C
A+B	A+B oder B+ oder B+C}}
B+	B+ oder B+C

Sinngemäß gilt diese Beziehung auch in die umgekehrte Richtung. Hierzu werden keine TMC-Tabellen benötigt (ohne TMC-Tabellen gibt es jedoch false positives an den Stellen, an denen Ketten beginnen oder enden).

Referenzfehler

Es kann überprüft werden, ob für den Wert A+B bzw. A-B in den Tabellen auch ein Eintrag (LCD: A, POS_OFF_LCD: B) bzw. (LCD: A, NEG_OFF_LCD: B) existiert. Hierzu werden TMC-Tabellen benötigt.

Unterstützung in Editoren

JOSM

• beim Verbinden von Ways mit unterschiedlichen TMC-Informationen wird eine Warnung angezeigt
• beim Drehen der Richtung von Ways mit TMC-Informationen wird (korrekterweise) angeboten, tmc:forward=* durch tmc:backward=* (und umgekehrt) zu ersetzen

Zusammenfassung Stand 2013

Für den Fall, dass sich jemand neu in das Proposal einarbeiten will, fasse ich hier das Wichtigste zusammen, wie ich es verstanden habe. (Stand: Dezember 2013, identisch Juli 2012)

• Es soll nicht die gesamte TMC-Datenbank integriert werden, sondern nur, was für eine praktikable Nutzung (in Verbindung mit der TMC-Datenbank) und Qualitätssicherung gebraucht wird. Dafür müssen nur OSM-Ways getaggt werden, und nur mit einem Tag-Schlüssel.
• Daher sind für das Proposal nur zwei der TMC-Datentypen relevant:
  • TMC-Punkte ("point locations"). Das sind vor allem Kreuzungen.
  • TMC-Strecken. TMC-Strecken führen (ggf. quer durch Europa) über mehrere TMC-Punkte und haben jeweils eine definierte positive und negative Richtung.
• Es wird vorgeschlagen, die Wegstücke (OSM-Ways) zwischen zwei TMC-Punkten zu taggen mit:
  tmc=[Start-Punktnummer][Richtungszeichen][End-Punktnummer].
  • [Richtungszeichen] ist hierbei "+" oder "-", je nachdem, ob das Wegstück in positive oder negative Richtung bezüglich der TMC-Strecke führt.
  • Punktnummern setzen sich aus Ländercode (country ID, CID), TMC-Tabellennummer (table code, TABCD) (wenn es für das Land mehrere Tabellen gibt, was auf Deutschland nicht zutrifft), und Point-location-Nummer (location code, LCD) zusammen.
    Format: tmc=[CID][TABCD (wenn mehrere)]:[LCD]
    Beispiel: tmc=DE:1234

--KonB (talk) 13:49, 3 January 2014 (UTC)

Details und Beispiel

• Ursprünglich war das Format tmc=[Endpunkt][Richtungszeichen][Startpunkt] vorgeschlagen, was eher der kontraintuitiven TMC-Denkweise entspricht, da sich die -- mit TMC beschriebenen -- Verkehrsstörungen entgegen der Fahrtrichtung ausbreiten.
• Es bietet sich an, Wegstücke, die zu ausgedehnten TMC-Punkten (z.B. Kreuzungen) gehören, mit [Punktnummer][Richtungszeichen] zu taggen.
• Eine Fahrt könnte bspw. (bei getrennten Richtungsfahrbahnen) von einem OSM-Way mit tmc=DE:1234+1235 über eine Kreuzung (Way mit tmc=DE:1235+) auf einen Way mit tmc=DE:1235+1236 führen. Die Gegenrichtung wäre dann mit tmc=DE:1236-1235 usw. getaggt.
• Für nicht-baulich-getrennte Spuren entsprechend: tmc=DE:1234+1235;DE:1235-1234, wofür man auch eine Kurznotation finden könnte (z.B. DE:1234/1235). Alternativ wurden tmc:forward und tmc:backward vorgeschlagen.
• Entgegen meinem obigen Beispiel werden die Punktnummern meist in "+"-Richtung kleiner, realistischer wäre also tmc=DE:1235+1234;DE:1234-1235.

--KonB (talk) 13:49, 3 January 2014 (UTC)