Hier mal eine kleine Skizze, welche Punkte ich bei einem Autobahnkreuz in zwei TMC-Punkt-Relationen packen würde:
http://wiki.openstreetmap.org/wiki/File:TMC_Motorway_Intersection.svg
Ein solches Kreuz hätte zwei Location Codes, jeweils einer mit Bezug auf die blaue und rote Strecke in der Skizze. Deshalb bräuchte es auch zwei Relationen - eine für die Punkte A-D, die zur blauen Strecke gehören, und eine für die Punkte E-H der roten Strecke. Jede sollte dabei folgende Tags bekommen:
-
type=tmc
-
tmc:cid=* - Ländercode
-
tmc:tabcd=* - Tabellennummer
-
tmc:point=* - Location Code dieses Punktes
-
tmc:segment=* - Übergeordnetes Segment (falls vorhanden)
-
tmc:road=* - Übergeordnete Straße
-
tmc:pos_off=* - Nächster Punkt in positiver Richtung
-
tmc:neg_off=* - Nächster Punkt in negativer Richtung
Die ersten 3 Tags sind notwendig, sie geben den international eindeutigen Location Code an. Ich würde cid und tabcd in eigene Tags packen und nicht alle drei zusammen als cid:tabcd:point in den Wert packen, weil man dann für die restlichen Tags (Referenzen auf andere Locations) immer nur den letzten Teil braucht - solche Referenzen gibt es immer nur innerhalb einer Tabelle, d.h. cid und tabcd sind dort immer gleich. Die Frage ist aber, ob diese Referenzen auf andere Locations überhaupt in dieser Form als Tags erfasst werden sollten (und so die verkettete Liste abbilden) oder lieber als eigene Relation, die dann die Punkte als Member enthält. Beides hat wohl Vor- und Nachteile, ich habe da derzeit keinen klaren Favoriten.
Die vier Punkte A-D bzw. E-H sollten als Elemente der Relation vorhanden sein, für die Rollen würde ich mir eine Benennung so ähnlich wie diese vorstellen (die Namen sind nur schematisch, weil mir gerade nichts besseres einfällt - vielleicht hat jemand eine bessere Idee):
-
A/G: posend_negdir
-
B/H: posend_posdir
-
C/E: negend_negdir
-
D/F: negend_posdir
Dabei soll **posend** bedeuten, dass sich der Node auf der Seite des Kreuzes befindet, das näher am positiven Nachbar-TMC-Punkt liegt, während **negend**-Nodes auf der anderen Seite sind, näher am negativen Nachbar-TMC-Punkt. Außerdem geben **posdir** und **negdir** an, auf welcher Fahrbahn (in positiver oder negativer Richtung) der Punkt liegt. (Siehe dazu weiter unten.) Dieses Benennungsschema halte ich deshalb für sinnvoll, weil auf diese Weise immer die Nodes, die am gleichen Ende bzw. auf der gleichen Richtungsfahrbahn liegen, einen Teil des Rollennamens gemeinsam haben. Bei kompakteren Kreuzungen kann man dann Namen zusammenlegen:
-
Bei einer Straße ohne getrennte Richtungsfahrbahnen gibt es keine Unterscheidung zwischen posdir und negdir. Hier braucht es nur zwei Knoten, einen an jedem Ende, mit Rollen posend und negend.
-
Bei einer Straße mit getrennten Richtungsfahrbahnen, die von einer anderen ohne Trennung gekreuzt wird, liegt auf jeder Richtungsfahrbahn nur ein Kreuzungsnode und die Unterscheidung zwischen posend und negend fällt weg. Die beiden nodes bekommen dann die Rollen posdir und negdir.
-
Bei einer ganz einfachen Kreuzung komplett ohne bauliche Trennungen gibt es nur einen Node mit Rolle all.
Natürlich sind auch gemischte Kombinationen möglich, wenn eine Straße z.B. vor der Kreuzung baulich getrennt ist, dahinter aber nicht mehr etc.
Bleibt noch die Frage, was die positive und was die negative Fahrtrichtung sein sollen. Der TMC-Standard definiert die positive Richtung als die Richtung, die vom negativen Nachbarknoten weg zum positiven Nachbarknoten hin zeigt. Allerdings werden Ereignisse wie z.B. Staus immer von der Ursache (z.B. ein Unfall) an gemessen, d.h. entgegen der Fahrtrichtung. Ein Unfall auf der Seite, in der der Verkehr in positiver Richtung fließt, wird daher als “Ereignis in negativer Richtung” gemeldet, weil sich der Stau vom Unfall aus in die negative Richtung ausdehnt. Soll heißen: Auf der negativen Richtungsfahrbahn fließt der Verkehr in positiver Richtung. Weil das verwirrend sein kann, gab es hier den Vorschlag, diese Benennung in OSM umzudrehen. Andererseits könnte das wiederum die Nutzer verwirren, die etwas anderes erwarten, weil sie es vom TMC-Standard her so kennen. Ich bin mir hier nicht wirklich schlüssig.
In dem verlinkten Proposal wurde auch vorgeschlagen, statt der cid ein Länderkürzel zu vergeben, und Tabellennummern nur dann zu taggen, wenn es in diesem Land mehr als eine gibt. Auch hier bin ich mir nicht ganz schlüssig, ob das Sinn macht. Wenn man cid und tabcd wie in den Tabellen angegeben taggt, vereinfacht das eine automatische Konsistenz- und Vollständigkeitsprüfung, und eine halb-automatische Aktualisierung. Soll heißen, wenn ein Land eine neue Tabelle herausgibt, kann man direkt automatisch mittels der Nummern feststellen, was noch aktuell ist, und eine Liste aller noch zu ändernder Nodes erstellen. Beim Mappen sollte der Unterschied klein sein, da man eine Nummer ja ohnehin als solche erfasst, und wer mit dem Location Code 12345 etwas anfangen kann, für den dürften auch cid 58 und tabcd 1 nicht zu kryptisch sein.