DE:Proposed features/New TMC scheme

TMC (neu)
Zustand:	Inactive (inactive)
Vorgeschlagen von:	infoware_kna
Tagging:	tmc, tmc_area=*
betroffene Elemente:	node,way,relation
Kurzbeschreibung:	Defines improved tagging for TMC data
Statistik:
Darstellung:	hyperlink
Entwurf vom:	2012-03-15
Diskussionsbeginn:	2012-03-29
Abstimmungsbeginn:	*
Abstimmungsende:	*

Proposal: Neues Tagging-Schema für TMC-Daten

Dies ist ein Entwurf für ein neues Tagging-Schema für TMC-Daten in OSM. Nach einem gemeinsamen OSM Stammtisch der Gruppe Rhein-Sieg wurden einige Änderungen vorgeschlagen, die aufgenommen und hier in der aktuellen Form vorgestellt werden. Dabei gab es Änderungen, um das taggen zu erleichtern, als auch Änderungen, um die Korrektheit auch für seltene Fälle zu garantieren. An dieser Stelle noch einmal vielen Dank für das Interesse, feedback und die aktive Mitarbeit an diesem Proposal.

Die infoware GmbH (www.infoware.de) hat mit der Unterstützung der Geofabrik GmbH (www.geofabrik.de) ein verbessertes Tagging Schema für TMC Daten erarbeitet, das wir im Folgenden zur allgemeinen Verwendung in OpenStreetMap vorschlagen.

Ansprechpartner bei infoware: Jochen Stappert, Dieta Schülter (osmtmc@infoware.de, User:infoware_dsr, infoware_sta)

Ansprechpartner bei Geofabrik: Frederik Ramm (ramm@geofabrik.de)

Begründung

infoware entwickelt seit Jahren Navigationssoftware und beschäftigt sich intensiv mit der Integration von Verkehrsinformationen in solchen Systemen. Die Daten von OSM können aufgrund ihrer hohen Qualität mittlerweile auch in kommerziellen Systemen genutzt werden. Damit auch Verkehrsinformationen auf der Basis von OSM-Karten genutzt werden können, hat infoware ihre Erfahrung im TMC-Bereich in das neue Tagging-Schema einfliessen lassen.

Wir denken, dass ein neues Tagging Schema wie das hier vorgestellte sowohl die Erfassung als auch die Nutzung der Daten vereinfachen und dadurch voranbringen wird.

Hintergrund

TMC (Traffic Message Channel)

[Die folgende Beschreibung ist vereinfachend. Sie versucht nur die im Zusammenhang mit der OSM-Integration notwendigen Punkte zu verdeutlichen. Genauere Beschreibungen finden sich in ISO 14819.]

TMC (Traffic Message Channel) ist ein Verfahren zur Meldungen von aktuellen Verkehrsinformationen, typischerweise übers Radio, inzwischen aber auch über Internet oder Mobilfunknetze. Die Empfänger bekommen Informationen wo welche Behinderungen und andere Besonderheiten vorliegen. Meldungen können sich auf viele verschiedene Dinge beziehen: ein Stau, eine gesperrte Strecke oder gesperrte Abfahrt, Schneekettenpflicht in einem Gebiet, usw.

TMC-Meldungen enhalten immer die Information a) wo etwas passiert (location) und b) was passiert (event).

Die Frage des "was" interessiert uns in diesem Dokument weniger. Bei der Integration von TMC-Daten und OSM-Daten geht es darum, die Beschreibung *wo* etwas passiert ist aus den TMC-Meldungen mit den Straßen- und sonstigen Daten aus OSM in Verbindung zu bringen. Dabei geht es um zwei wesentliche Anwendungen: Die Anzeige der Verkehrsmeldungen auf einer Karte und die Einbeziehung der Informationen in die Navigation (z.B. keine Navigation über gesperrte Strecken, Berücksichtigung von Staus, usw.).

Locations in TMC

TMC kennt mehrere Arten von Orten (Locations):

• Point Locations beschreiben mehr oder weniger ausgedehnte Punkte wie

 Kreuzungen, Raststätten, Parkhäuser, usw.

• Line Locations beschreiben Straßen (Roads) oder Teile von Straßen (Segments).
• Area Locations beschreiben Gebiete (Land, Bundesland, Kreis, Gebirge, usw.).

Alle Locations haben

• eine eindeutige Nummer (Location Code, LCD),
• eine Klasse (CLASS)
• einen Typ (Type Code, TCD) und
• einen Subtyp (Subtype Code, STCD)

CLASS kann P(oint), L(ine), oder A(rea) sein). TCD und STCD sind kleine Ganzzahlen (Integer), sie werden häufig durch einen Punkt getrennt geschrieben (TCD.STCD). Sie geben an, um was es sich hier handelt: Ein Autobahnkreuz (1.1), eine Raststätte (3.3), ein Bundesland (7.0), eine Bundesstraße (1.2), usw.

Alle Locations in einem Land sind in einem Datensatz (Location Dataset, auch Tabelle/table genannt, was etwas verwirrend ist, weil ein Datensatz eigentlich aus mehreren zusammengehörigen Tabellen besteht) zusammengefasst, das von einer offiziellen Stelle herausgegeben und immer wieder aktualisiert wird. In Deutschland ist das beispielsweise das Bundesamt für das Straßenwesen (BASt). (Manche Länder haben auch mehrere Datensätze, die dann jeweils nur Teilgebiete umfassen.) Die eindeutige Nummer eines Ortes (Location Code) ist nur innerhalb dieses Datensatzes eindeutig. Zur wirklich eindeutigen Kennzeichnung eines Ortes braucht es also das Land, ggf. die Datensatznummer (TABCD - Table Code) und den Location Code. Der BAST Datensatz wird etwa alle ein bis zwei Jahre upgedated. Dabei werden in der Regeln neue Locations hinzugefügt, aber keine bereits exisiterenden Locationcodes verändert oder vertauscht. Es liegt immer auch eine Liste der Änderungen vor, so daß man diese gleich erkennen kann.

Zur Beschreibung des Straßennetzes werden die wichtigsten Punkte im Straßennetz (Kreuzungen, Brücken, Tunneln, Raststätten, ...) als Punkte erfasst, die über Vorwärts- und Rückwärtsverweise ("Positive/Negative Offset") miteinander zu Streckenzügen verbunden werden. Punkte durch die mehrere Straßen führen, z.B. eine Kreuzung oder ein Kreisverkehr, haben dabei mehrere Location Codes, für jede kreuzende Straße einen. (Manchmal gibt es noch weitere Location Codes an einem Punkt, wenn z.B. zwei Autobahnen vorübergehend auf der selben Strecke geführt werden.)

Zu jeder Point Location sind Koordinaten vorhanden, die aber nur ungefähr angeben, wo sich dieser Punkt befindet. Bei einem größeren Autobahnkreuz oder dergleichen wird immernoch nur ein Punkt angegeben. Im großen und ganzen geben die Koordinaten schon die richtigen Stellen an, größere Abweichungen von der tatsächlichen Position sind aber möglich, z.B. dann, wenn die beiden Richtungsfahrbahnen deutlich unterschiedliche Streckenführungen haben. In jedem Fall ergibt sich aus den TMC-Datensätzen nicht die genaue Streckenführung mit ihren Kurven, sondern nur der Zusammenhang, welche Straßen wo mit anderen verbunden sind.

Verkehrsmeldungen und Locations

Die meisten Verkehrsmeldungen beziehen sich auf eine Point Location und geben von dort eine Richtung (Direction) und Ausdehnung (Extent) an. Ein Stau wird z.B. gemeldet als: "Von Location Code 54975 in negativer Richtung mit Ausdehnung 2". Zusätzlich kann auch die Länge des Staus angegeben werden.

Ein Stau wird immer von dem Punkt aus angegeben, an dem der Grund für den Stau ist, also z.B. ein Unfall. Verlängert sich ein Stau, dann wird er daher mit dem gleichen Anfangspunkt, aber einer größeren Ausdehnung nochmal gesendet.

In unserem Beispiel ist der Location Code 54975 die Anschlußstelle Karlsruhe-Nord auf der A5. Die übernächste (extent 2) Location in negativer Richtung ist die Anschlußstelle Karlsruhe-Mitte. Der Stau würde also gemeldet mit "auf der A5 zwischen den Anschlußstellen Karlsruhe-Mitte und Karlsruhe-Nord in Fahrtrichtung Frankfurt, 3km Stau."

Bezieht sich eine Meldung nur auf einen Punkt (Abfahrt gesperrt an der Anschlußstelle X), dann wird der Extent 0 übertragen.

Manchmal beziehen Meldungen sich auch auf ein Gebiet (Area Location) ("Starker Schneefall im Harz, Schneekettenpflicht"). Meldungen können sich auch auf Segments oder Roads beziehen (Line Locations), das kommt aber in der Praxis selten vor.

Tagging

Das Tagging Schema, das wir vorschlagen, beschreiben wir nachfolgend im Detail.

Ländercodes und Tabellen

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

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

Alles drei sind beliebig vergebene Ganzzahlen (Integer).

Für OSM fassen wir diese drei 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.)

Der Location Code muss natürlich immer angegeben werden.

Vor dem Location Code wird ein Doppelpunkt als Trennzeichen verwendet. [Begründung: Der Doppelpunkt wird auch an anderer Stelle bei OSM im Sinne eines hierarchischen Trennzeichens verwendet.]

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

 CC[TABCD]: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
 FR17:19523 (falls in Frankreich mehrere Tabellen verwendet werden und es
             eine Tabelle mit Nummer 17 gibt)

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

Weitere Konventionen

Oft werden mehrere Location Codes zusammen verwendet (s.u.), in diesem Fall ist es nicht immer nötig, das Land und die Datensatznummer wiederholt anzugeben. In solchen Fällen wird dann abgekürzt. Statt

 DE:40144-DE:98204

schreibt man z.B.

 DE:40144-98204

[Im bisherigen Schema ist das so umgesetzt, dass die CID und TABCD im OSM-Key eines Tags untergebracht sind. Das ist in mehrerer Hinsicht problematisch: Diese Art der Notation ist sehr ungewöhnlich in OSM, daher ungewohnt für die User und viele Standardtools kommen damit nicht gut zurecht. Unschön ist auch die Nutzung des CID (z.B. 58 für Deutschland), eine nichtssagende Nummer und die sehr lange Form "TMC:cid_CID:tabcd_TABCD:...".

Der Grund für die Positionierung von CID und TABCD im Key ist, dass so Überschneidungen der Tabellen, z.B. an einer Landesgrenze, möglich werden. Da es aber auch innerhalb eines Datensatzes in einem Land vorkommt, dass ein Ort mehrere LCDs hat, ist dadurch nicht wirklich etwas gewonnen. Mehrere Codes an einer Location müssen in jedem Fall möglich sein.]

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 bestimmt werden, die betroffen sind. Am einfachsten ist das, wenn die Ways bereits mit genau dieser Information bestückt sind.

Dazu speichern wir an jedem Way einen Tag:

 tmc=DE:12345+58934

Dieser Way geht 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 der Weg in negativer Richtung, wird ein Minuszeichen ('-') verwendet:

 tmc=DE:39345-41005

So ein Tag beschreibt also immer eine Verbindungsstrecke (Link) vom Startpunkt (Erster Punkt im Tag; Ende der Strecke, wenn man in Fahrtrichtung denkt) zum Endpunkt (Zweiter Punkt im Tag; Start der Strecke, wenn man in Fahrtrichtung denkt), wobei der Startpunkt enthalten ist, der Endpunkt nicht.

An dieser Stelle gibt einen Änderungsvorschlag für das Proposal. Da es für den mapper beim eingeben der TMC Daten sehr unintuitiv ist 'gegen' die Fahrtrichtung zu denken, so wie TMC es tut, haben wir uns entschlossen für das tagging die Richtung in Fahrtrichtung anzugeben. Das ist deutlich intuitiver und nicht so fehleranfällig. Tools, die die TMC Informationen verarbeiten müssen dann umdenken. Da sich dabei aber um eine automatische Verabeitung handelt, stellt dies kein Problem dar. Außerdem übernehmen wir den Vorschlag, dass der Way, der dem LCD am nächsten ist entweder mit 123+ oder 123- gekennzeichnet wird, da er das Ende oder den Beginn eines TMC Segments darstellt. Wie das tagging Schema hiermit genau funktioniert wird im Folgenden anhand der Beispiele und Folien erkärt.

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

Anwendungsfall: Getrennte Richtungsfahrbahnen

Liegen getrennte Richtungsfahrbahnen vor (z.B. auf einer Autobahn), so ist die eine Richtung getagged mit:

 tmc=DE:123+456

die andere mit:

 tmc=DE:456-123

Anwendungsfall: Keine getrennte Richtungsfahrbahn

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

 tmc=DE:123+456;DE:456-123

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=DE:123+456

und die andere mit

 tmc=DE:123-543

Anwendungsfall: Kreuzung ohne getrennte Fahrbahn

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

 tmc=DE:123+456;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.

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.

Anwendungsfall: Kreisverkehr

Anwendungsfall: Sperrung einer Autobahnabfahrt

Anwendungsfall: Autobahnverzweigung

Mehrere Locations an einem Way

Ist ein Way mehreren Locations bzw. Kombinationen von Locations zugeordnet, so werden diese mit Semikolon (;) getrennt aneinander gehängt.

Beispiel:

 tmc=DE:123-456;DE:333-444

(Die Ländercodes müssen in diesem Fall wiederholt werden, weil die Locations aus verschiedenen Ländern bzw. Datensätzen stammen können.)

Da es nach diesem Vorschlag nur ein Tag pro Way gibt, ist diese Form kein Problem. Hätte man mehrere Tags (wie auch nach dem bisherigen Schema), so muss man Relations verwenden, damit die Tags einander zugeordnet werden können.

Ein Schema das ohne Relations auskommt ist natürlich viel einfacher zu benutzen, insbesondere für OSM-Neulinge.

Die Nutzung des Semikolons als Trennzeichen ist in OSM weit verbreitet, wenn auch viele Software damit nicht zurecht kommt. Da in diesem Fall aber in jedem Fall spezielle Software verwendet werden muss, um die TMC-Tags auszulesen, macht das auch nichts aus. Es ist auf jeden Fall einfacher in der Nutzung als Relations.

Nachteil der Nutzung des Semikolons (und auch der Bereichsangabe a la "DE:123-456") ist natürlich, dass man nicht mehr so einfach mit Standard-Tools wie der XAPI arbeiten kann. Z.B. ist eine Abfrage "alle Ways, die Location DE:123 betreffen" nicht möglich. (Außer es gäbe regular expression queries, dann gine das wieder.) Das die Nutzung der TMC-Daten in der Regel durch spezialisierte Tools erfolgt, kann man diesen Nachteil aber in Kauf nehmen.

Behandlung von TMC Area-Codes

TMC hat auch Location Codes für Gebiete (Area Locations). Es gibt zwei Arten von Areas: Verwaltungseinheiten ("Administrative Areas") und sonstige Gebiete ("Other Areas"). Die Verwaltungseinheiten sind dabei in eine Hierarchie einsortiert, Kreise in Regierungsbezirken in Bundesländern, usw.

Die Area Locations in TMC enthalten keine Geometrieinformationen. Die Position der Gebiete ergibt sich bei TMC nur indirekt aus den Point Locations, die auf die Gebiete verweisen, in denen sie enthalten sind.

Für die Administrative Areas sollten in OSM bereits an vielen Stellen Relations mit boundary=administrative vorhanden sein. Diese wurden häufig bereits nach dem bisherigen Schema mit den entsprechenden Area Location Codes getagged. Dies kann auch nach dem neuen Schema weitergeführt werden, allerdings in viel kompakterer Form:

 tmc_area=DE:266

Sollten mehrere TMC-Gebiete durch ein OSM-Objekt modelliert werden, so können auch mehrere Location Codes angegeben werden:

 tmc_area=DE:1234;DE:5678

Manche TMC-Gebiete haben kein Äquivalent in OSM. In diesem Fall sollte das Gebiet vorerst nicht erfasst werden. Wenn wir mehr Erfahrung mit der Nutzung von TMC haben, kann man später schauen, wie die Erfassung am besten erfolgt. Wenn ein TMC-Gebiet in OSM durch mehrere Gebiete abgebildet wird, z.B. wenn in OSM mehrere Stadtteile einzeln erfasst sind, das TMC-Gebiet aber "Hamburg-West" oder so etwas heisst, dann werden ggf. alle passenden OSM-Gebiete mit dem entsprechenden tmc_area-Tag versehen. Zur Nutzung der Daten müssen die Gebiete dann zusammengefasst werden. Dies geschieht zweckmäßigerweise nicht in den OSM-Daten oder während deren Erfassung, sondern erst dann in einem optionalen Schritt im Postprocessing, und nur dann, wenn dies für den konkreten Nutzungsfall nötig ist.

Manche TMC-Gebiete werden in OSM nur als Punkt erfasst, z.B. ein Parkhaus oder dergl. Dann wird das entsprechende tmc_area-Tag an den den Punkt getagged. Durch den key "tmc_area" statt einfach "tmc" ist hier eine klare Unterscheidung gegeben.

[Es ist nicht klar ist, ob die Area-Informationen, die mit den Punkt-Locations verbunden sind wirklich übereinstimmen mit den Flächen, wie sie bei OSM erfasst sind. Wahrscheinlich wird das aber gut genug sein, dass man erstmal so vorgehen kann. Dies sollte genauer untersucht werden.]

[Es wäre denkbar noch eine weitere Aufteilung vorzunehmen nach tmc_administrativearea und tmc_otherarea oder dergl. Es ist aber unklar, ob das etwas bringt. In den TMC-Datensätzen gibt es diese Unterscheidung.]

Erfassung von Linien-Locations sinnvoll?

Über die TMC-Datensätze läßt sich aus den Point Locations auch die Line Locations (Segments/Roads) ermitteln. Es besteht also keine unbedingte Notwendigkeit, diese Informationen in OSM zu erfassen. Aber natürlich könnte die Handhabung einfacher werden, wenn man die TMC-Datensätze nicht mehr braucht. Line Locations werden in Verkehrsmeldungen typischerweise nicht verwendet. Gelegentlich werden sie als Zusatzinformationen angegeben, z.B. um eine Umleitung zu bezeichnen.

Zum jetzigen Zeitpunkt ist nicht klar, ob es wirklich sinnvoll ist, Line Location Codes in OSM zu erfassen. Die von den Autoren dieses Textes ins Auge gefassten Applikationen benötigen diese Information nicht. Wir verzichten daher in diesem Entwurf bewusst auf eine Spezifikation, ob und wie diese Daten für OSM erfasst werden sollen. Wenn diese Codes zu einem späteren Zeitpunkt benötigt werden und klarer ist, in welcher Form sie gebraucht werden, kann das ergänzt werden. Das könnte zum Beispiel mit Tags tmc_segment und tmc_road oder dergl. erfolgen, die unabhängig von dem in diesem Dokument beschriebenen Tags sind.

Versionen

Die offiziellen TMC-Datensätze werden immer wieder aktualisiert und neu herausgegeben. Sie sind daher mit einer Versionsnummer versehen. Da neue Datensatzversionen in Navis eingespielt werden müssen, was nicht immer zeitnah möglich ist, sollen Änderungen zwischen verschiedenen Versionsständen dabei natürlich möglichst klein gehalten werden. Auf keinen Fall dürfen zum Beispiel Location Codes plötzlich an anderer Stelle sein.

Neue Versionen der Datensätze werden veröffentlicht und treten dann etwas später zu einem genau definierten Zeitpunkt offiziell in Kraft. Man könnte jetzt in OSM die Versionsnummern der Datensätze mitführen, um bei Änderungen für einen Übergangszeitraum sowohl die alten als auch die neuen Daten zu haben. Das erscheint aber übertrieben, der Aufwand die Versionsnummern (oder den Gültigkeitszeitraum) für die Tags zu erfassen erscheint doch recht hoch. Alle Änderungen müßten dann außerdem doppelt erfolgen: Einmal bei Herausgabe der neuen Datensatzversionen und dann nochmal später, um nach einer Übergangszeit die veralteten Daten zu entfernen. Wenn man stattdessen versucht, die Änderungen möglichst zeitnah am offiziellen Umstellungszeitpunkt durchzuführen, dann ergibt sich nur ein kleines Zeitfenster in dem die Daten nicht ganz korrekt sind.

Sollte in einem Land doch einmal eine komplette Überarbeitung eines Datensatzes erfolgen, so würde in diesem Fall eine neue Datensatznummer verwendet. Die Daten könnten in so einem Fall problemlos nach dem beschriebenen Schema zusätzlich erfasst werden.

Relevante Änderungen der Location Datensätze sind für uns nur die Einführung neuer Location Codes oder die Abschaffung bestehender Punkte. Dabei ändert sich u.U. auch die Kodierung des nächsten und vorhergehenden Punktes entlang einer Strecke. Diese Änderung läßt sich anhand der TMC-Datensätze und der tmc-Tags in OSM eindeutig erkennen und korrigieren. Andere Änderungen an der Tabelle, z.B. wenn an einem Punkt eine Ausfahrt hinzukommt, die vorher nicht vorhanden war, sind nicht relevant, weil diese Information in den OSM-Daten nicht erfasst wird.

Eine typische Folge falscher Daten wäre die Darstellung eines Staus auf einer etwas zu kurzen oder zu langen Strecke, wenn innerhalb dieses Bereiches z.B. eine neue Anschlußstelle in eine Autobahn eingefügt wurde. Das erscheint nicht also besonders problematisch, da Angaben über die Länge von Staus häufig sowieso ungenau sind.

Die Versionsstände der TMC-Tabellen werden daher nicht in OSM erfasst.

[Nach dem bisherigen Tagging-Schema wurde TMC:cid_CID:tabcd_TABCD:LCLversion getagged. Wie genau bei Änderungen der TMC-Datensätze verfahren werden soll, um alte und neue Version ggf. parallel zu verwenden, ist nicht klar.]

Programmatische Auswertung des tmc-Keys

Soll in einer Software die tmc-Keys ausgewertet werden, so passiert das in folgenden Schritten:

1. Aufteilung nach Semikolon. Aus einem String wird ein Array von Strings. Danach wird jedes Element des Arrays einzeln weiter verarbeitet.

2. Ersetzen der Form "CC[TABCD]:LCD1/LCD2" durch "CC[TABCD]:LCD1+LCD2" und "CC[TABCD]:LCD2-LCD1".

3. Parsen der Elemente nach dem Format "CC[TABCD]:LCD1[+-]LCD2". Alle Strings, die nicht diesem Format gehorchen müssen verworfen werden.

4. Ggf. Umsetzung von CC und TABCD in eine Datensatznummer.

Varianten für Tag-Key

[Meinungen erwünscht]

In diesem Dokument wurden als Tag-Keys erwähnt: - tmc - tmc_area - tmc_road - tmc_segment - tmc_point (nicht erwähnt, aber mögliche Erweiterung)

Der Key 'tmc' ist sicher der am häufigst vorkommende, die kurze Form ist daher durchaus gerechtfertigt. Alternativ könnte man aber auch z.B. 'tmc_link' verwenden, um das gleiche Format wie bei den anderen Keys zu haben und besser auszudrücken, um was es sich hier handelt: Die Verbindung zwischen zwei Point Locations.

Eine weitere Alternative wäre die Benutzung von ':' als Trennzeichen: - tmc:link - tmc:area - tmc:road - tmc:segment - tmc:point

Auf jeden Fall sollten kleine Buchstaben verwendet werden, weil das a) bei OSM für Keys allgemein so üblich ist und b) um sich von den Tags nach dem bisherigen Schema klar abzuheben.

Fehlererkennung:

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

- Syntaxfehler

- 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). [edit] 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.