Überarbeitung von TMC / TPEG

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.

Wo das Thema komplex ist, weiß ich noch nicht. TMC-Links sind einfach nur eine Zusammenfassung aller Wege zwischen zwei Punkten. Das ist das was jeder Router braucht um die Informationen zu verarbeiten.
Will ich hingegen Meldungen auf der Karte darstellen, reichen die ungefairen Koordinaten der BaSt aus. Viel besser wird es mit Relationen für Autobahnen auch nicht.
Der Rechenaufwand auf Autobahnen die Links zu erzeugen ist bei zwei Relationen je 4 Punkte auch nicht gerade schnell gemacht. Vielleicht haben wir auch 52k Links. Aber dann ist die gesamte Arbeit gemacht. Jede Routingsoftware weiß welche Wege gemeint sind. Arbeit wird nicht doppelt und dreifach gemacht. Links sind robuster als einzelne Knoten wenn sie aus mehreren Membern bestehen.

Vielleicht hilft folgende Idee weiter, die ich letzte Nacht um 1:24 hatte - da war mein Computer schon aus: ein 4-Stufen Plan.

  • Stufe 1: TMC-Punkte
    Die Punkte werden so gemappt, wie ursprünglich von mir vorgeschlagen und wie von mueschel favorisiert, d.h. als eine Relation pro TMC-Punkt, die jeweils bis zu 4 OSM-Nodes enthält. Das sollte sich relativ einfach machen lassen und könnte mit einer automatischen Validierung sowie einer Karte, auf der die Punkte angezeigt werden, unterstützt werden. Zusätzlich kann man (automatisch) Relationen für TMC-Segmente und TMC-Straßen erstellen, die aus den TMC-Punkten dieser Objekte bestehen.
    Mit dieser Stufe kann ein Router bereits feststellen, welche Punkte auf der von ihm berechneten Route liegen - denn die gemappten Nodes sind immer dort, wo sich Wege teilen, und die erfasst ein Router ohnehin in seinem Routinggraphen. Er kann also unmittelbar erkennen, ob eine TMC-Meldung für diese Route relevant ist oder nicht.

  • Stufe 2: TMC-Links
    Die Links werden so gemappt, wie von viw favorisiert - als Routen-Relationen, die jeweils zwei TMC-Punkte auf der gleichen Straße verbinden. Die Start- und Endpunkte sind dabei jeweils die zuvor in den TMC-Punkten erfassten Nodes. Das lässt sich nicht nur leicht validieren, sondern auch halbautomatisch erstellen - mit einem Router sucht man die Strecke zwischen zwei Nodes heraus und überprüft sie dann auf Richtigkeit. Am Ende hat man ein Netzwerk aus Punkten und Links (Mathematiker nennen es einen Graphen), das sich auf Konsistenz und Vollständigkeit prüfen lässt.
    Mit dieser Stufe wird es nun zusätzlich möglich, TMC-Meldungen zu lokalisieren, ohne dafür eine Route berechnet zu haben (und ohne für jede Meldung eigens eine solche berechnen zu müssen). Das verringert deutlich den Rechenaufwand. Stattdessen kann ein Router nun jede TMC-Meldung, die auf einem oder mehreren solchen Links liegt, direkt diesen zuordnen und so den dortigen Zeitverlust für die Routenplanung einbauen.

  • Stufe 3: TMC-Gebiete
    Jeder Punkt, jedes Segment und jede Straße ist im TMC-Datenmodell (maximal) einem Gebiet zugeordnet. Auch Gebiete sind wieder übergeordneten Gebieten zugeordnet. Das lässt sich dadurch abbilden, dass die entsprechenden Relationen für TMC-Punkte etc. in Relationen aufgenommen werden, die dann jeweils ein Gebiet beschreiben. Diese Relationen lassen sich automatisch erstellen, sobald man die Informationen aus Stufe 1 erfasst hat (man könnte es also auch vorziehen).
    Mit dieser Stufe bekommt man zusätzlich die Möglichkeit, Meldungen zu lokalisieren, die sich auf ein TMC-Gebiet beziehen - also z.B. Wetterwarnungen oder ähnliches. Diese lassen sich nun auf Straßen und Punkte abbilden und können dem Benutzer beim Befahren des Gebiets als Warnhinweis gezeigt oder auf der Karte dargestellt werden.

  • Stufe 4: Detaillierte Kreuzungen
    Als letztes kann man noch Kreuzungen / Autobahnkreuze, die etwas komplexer sind, im Detail erfassen, d.h. mit Verbindungsstücken zwischen den kreuzenden Straßen, wie oben von mir vorgeschlagen. Diese Verbindungen sind auch wieder Routen, die aber diesmal jeweils zu einer Kreuzung von TMC-Straßen gehören.
    Mit dieser Stufe kann man nun zusätzlich TMC-Meldungen lokalisieren, die sich auf gesperrte Ausfahrten beziehen - genau so wie es die TMC-Links schon für Meldungen entlang der Straßen ermöglichen, d.h. ohne ein Routing dafür zu benutzen. Damit hat man nun ein komplettes Bild, welche Strecken frei sind und welche gesperrt.

Diese 4 Stufen sollten dabei jeweils separate Proposals sein, d.h. man kann sie nacheinander ausarbeiten, vorschlagen und dann natürlich auch in die Tat umsetzen. Jede Stufe bietet einen Zugewinn gegenüber der vorherigen. Außerdem wird das Mapping einer Stufe dadurch erleichtert, dass die Daten der vorherigen Stufe bereits vorhanden sind. Auf jeder Stufe kann man außerdem automatische Konsistenz- und Vollständigkeitsprüfungen laufen lassen.

Das ganze System, TMC-Informationen in Relationen zu packen, hat noch einen Vorteil: Sollte TMC in der Zukunft abgelöst und nicht mehr benutzt werden, lassen sich alle TMC-Informationen in einem automatisierten Vorgang rauswerfen, indem man diese Relationen löscht. Damit ist sichergestellt, das wir keine schwer zu entsorgenden Altlasten produzieren (was ja ein paar Mal als Gegenargument gegen das Erfassen von TMC angeführt wurde).

Ich bin mir nicht ganz sicher ob diese Reihenfolge richtig ist. Aber ich gehöre auch nicht zu den Nutzern dieser Daten. Wenn insbesondere du als Entwickler der Navigationssoftware meinst das in dieser Reihenfolge die meisten Erfolge zu erziehlen sind, dann bitte.
Meine bedenken liegen lediglich darin, dass man zwar die Meldungen überprüfen kann, ob sie eine route betreffen, nicht aber welche Konsequenzen man daraus ziehen müsste.
Beispiel Streckensperrung. Klar ist der node auf meiner Route. Aber ist es die Gegenrichtung? Ist es die Auffahrt? Ist es nur die Weiterfahrt wo ich ohnehin abfahren will etc.

Sicher nicht unmittelbar die meisten Erfolge. Dafür braucht es sicher die von dir vorgeschlagenen Links. Aber ich denke, die sind einfacher zu generieren und zu überprüfen, wenn man schon die Punkte hat - letztere dürften einfacher zu setzen sein. Und ja, die Überlegung mit den Nodes auf der Route kommt tatsächlich daher, dass ich mich gefragt habe, welche Information ich z.B. bei einem Router wie nutzen könnte.

Das sollte sich schon ablesen lassen. Wenn ich Beispiel die Meldung bekomme “Stau auf der Strecke ab Punkt 1 in positiver Richtung mit Ausdehnung bis zum nächsten Punkt” dann kann ich aus der TMC-Punkt-Relation ablesen, welches dieser nächste Punkt ist. Dann kann ich überprüfen, ob beide Punkte auf meiner Strecke liegen, ob ich also den Abschnitt überhaupt durchfahre. Als nächstes kann ich überprüfen, in welcher Reihenfolge ich die beiden Punkte durchfahre, um zu wissen, ob die positive Richtung für mich relevant ist.

Klar, Auffahrten kann man so noch nicht wirklich umfassend behandeln - vielleicht eingeschränkt. Wenn ich eine Meldung der Form “Auffahrt gesperrt von Punkt 1 in Richtung Straße 2 / Punkt 3 in positiver Richtung” kann ich überprüfen, ob meine Route den Punkt 1 enthält sowie den folgenden Punkt auf Straße 2, oder eben Punkt 3. Wirklich umfassend kann man das dann in Stufe 4, die aber auch den größten Aufwand bedeutet.

Sinn dieses Planes ist es deshalb vor allem, schon mit relativ kleinem Aufwand ein (wenn auch noch nicht in vollem Umfang) nutzbares System zu bekommen, dessen Nutzen man in verdaulichen Happen weiter ausbauen kann. Am Ende hätte man ja durchaus sowohl Links als auch Punkte, und ich denke, in dieser Reihenfolge ist es einfacher, beides aufzubauen. Natürlich könnte man stattdessen auch zuerst Links mappen und dann Punkte generieren o.ä., das halte ich persönlich allerdings für etwas aufwändiger, da ein Link mehr Daten (alle Wegstücke) braucht, die man sich zusammenklicken muss. Wenn man dagegen die Punkte hat und z.B. das JOSM-Routing-Plugin, ist sowas schneller generiert und geprüft.

Die Stufen 1 und 2 entsprechen ja auch meiner Ansicht, da bin ich also dafür.
Und wie gesagt, die meisten Links kann eine halbwegs intelligente Software von selbst bestimmen indem die Straßen-Relation (die von vielen Usern verstanden und aktiv gepflegt wird, im Gegensatz zu den TMC-Relationen) analysiert werden.

Über Stufe 3 bin ich mir nicht im klaren: Ist das wirklich notwendig? Punkte und Links brauchen wir, um die Einträge in der TMC-Tabelle auf OSM-Objekte zu mappen. Bei Areas ist das nicht nötig - aus der TMC-Tabelle bekomme ich eine Liste an enthaltenen Punkten, und diese kann ich dann in OSM suchen.

Stufe 4 hingegen würde ich als optional in 1 und 2 integrieren - in Form von Wegen mit einer bestimmten Rolle innerhalb der Punkt-Relationen.

Das könnte man auch machen. Ich hatte mir nur gedacht, wenn man auch noch diese (relativ wenigen, verglichen mit den Punkten) Codes einbaut, braucht es die externe Tabelle nicht mehr, um den richtigen Ort zu finden.

Das hatte ich mir anfangs auch überlegt, bin dann aber davon abgekommen, weil z.B. eine Verbindung zwischen zwei Autobahnen nicht zu einer TMC-Punkt-Relation gehören müsste, sondern zu zweien - weil ein Autobahnkreuz zwei Location Codes hat. Ich habe es auch deshalb hinten angestellt, weil es die meiste Arbeit macht und ein Proposal komplexer macht. Stufen 1 und 2 lassen sich einfacher und zügiger realisieren.

Ich halte 2 für deutlich komplexer als 4:

  • Die Einträge von 4 umfassen jeweils nur sehr wenige Wege (in der Regel 1-5, längere Auf/Abfahrten sind wohl selten vorhanden), und diese liegen in einem räumlich sehr kleinen Bereich
  • Bei den meisten Locations ist 4 nicht notwendig, weil sie nicht komplex gemappt sind

Hast du über meine Idee, die Links für Stufe 2 automatisch aus den Straßenrelationen zu extrahieren nachgedacht? Wenn dem so ist, dann wäre eine Menge Arbeit nicht notwendig.

Na gut, das stimmt. Ich bin mir noch nicht ganz schlüssig, wie man sowas am besten taggen könnte / sollte, aber das kann man sich ja überlegen.

Ja, wobei ich da noch nicht 100% schlüssig bin. Also automatisch generieren sollte durchaus möglich sein, allerdings frage ich mich, wie fehleranfällig das ist. Was ich auf jeden Fall für realistisch halten würde wäre zunächst einmal eine automatische Generierung, die sich dann ein Mapper ansieht, nötigenfalls korrigiert und dann die fertige Relation hochlädt. Auf diese Weise wäre die Arbeit deutlich geringer.

Du leitest die Komplexität einfach aus der Anzahl der Elemente einer Relation ab?