Stimmt, später ergeben sie sich auf jeden Fall aus den Links. Aber gerade zum Mappen der Links würde ich diese Rollen für sinnvoll halten, weil man beim Suchen der Wegstücke für den Link so genau weiß, welche beiden Nodes der Link verbinden soll, und man die dann halbautomatisch suchen kann.
Ich werde mal schauen, ob es einen Anwendungsfall für die Rollen gibt, und falls ja, wie man den lösen könnte, wenn man keine solchen Rollen hat. Dann müsste sich ja zeigen, ob sie Sinn machen oder nicht.
EDIT: Die Rollen sind tatsächlich überflüssig, weil man die Information ganz einfach rekonstruieren kann. So lange es nur TMC-Punkte und keine TMC-Links gibt, muss man ohnehin eine Route als Grundlage verwenden, um mittels der gemappten Nodes zu wissen, welche TMC-Punkte man durchfährt. Und dann kann man ja mittels der Reihenfolge der Nodes auf der berechneten Route erkennen, welcher davon welcher ist. Später, wenn man Links hat, ist das ohnehin klar, auch wenn man keine Route berechnet hat. Man kann sie also einfach weglassen. Ich werde das mal entsprechend im Wiki einbauen.
In dem Fall würde ich aber die Rolle “(leer)” für Infrastruktur auf “both” ändern, damit die sich von den Nodes auf der Straße unterscheidet. Außerdem ist es dann konsistent mit den Rollen “positive” und “negative” dafür, die würde ich auch auf jeden Fall behalten, denn diese Objekte liegen ja nicht als Nodes auf der Straße, weshalb man sie auch nicht mittels Routen identifizieren kann.
Schön. Hier sieht man aber auch den nachteil der “nur” Punkte. Wenn man nämlich nur einen Teil des links befährt haben Router keine Chance zu erkennen ob die Meldung für ihre Strecke möglicherweise relevant ist. (Streckensperrung ziwschen zwei Knoten, aber ich fahre eben von einer kleineren Nebenstraße auf/ab)
Naja, das Problem kann bei Links auch bestehen. Wenn eine Meldung reinkommt, dass zwischen A und B eine Unfallstelle ist, ich aber nur einen Teil der Strecke von A nach B fahre, weiß ich auch nicht, ob die Unfallstelle auf “meinem” Teil der Strecke liegt - unabhängig davon, wie es gemappt ist. Der Router kann aber sowohl mit Links als auch mit Punkten erkennen, dass ich einen Teil der Strecke zwischen A und B befahre. Mit Links sieht er, dass meine Route einen Teil des Links enthält. Mit Punkten sieht er, dass meine Route den einen TMC-Punkt enthält, aber nicht den anderen.
Ich habe jetzt die Rollen im Proposal angepasst und eine Übersichtsgrafik an den Anfang gestellt. Die Erklärung der Rollen habe ich einfach mal rausgenommen. Das ganze ist sicher noch nicht optimal… Es ist ja auch noch Draft.
Hat zufällig jemand eine Idee, wie man bei dem Beispiel unten die Member-Nodes zusammen auf einer Karte innerhalb der Wiki-Seite darstellen kann? Das fände ich etwas schöner als auf eine externe Seite zu verlinken…
Ich habe das Proposal noch einmal überarbeitet und die Beispiele etwas aufgeräumt. Hat jemand noch Ideen oder Vorschläge, was man noch einbauen sollte? Falls nicht, würde ich den Status von Draft auf RFC ändern und das Proposal auf die Tagging-Mailingliste geben.
Mir ist aufgefallen, dass eine ganze Menge Ortsstraßen in den TMC-Tabellen eine Referenznummer haben, die mit “G” anfängt - für Gemeinde? Solche Nummern sind mir vorher noch nie begegnet, deshalb frage ich mich, welchen offiziellen Charakter diese Nummern haben und wo sie benutzt werden. Gefunden habe ich sie z.B. in den Verkehrsmeldungen für Frankfurt und ähnliche Nummern beginnend mit I für Hamburg. Lässt sich damit irgendwas anfangen?
Da auf den RFC zum Proposal keine weiteren Verbesserungsvorschläge eingegangen sind, habe ich basierend auf dem dort vorgeschlagene Tagging einmal testweise eine Import- und Prüfungsfunktion gebastelt, um TMC-Punkt-Relationen zu erzeugen. Diese Punkte habe ich mal testweise importiert:
Auf der Karte werden nun die Koordinaten in der Location Code List in rot sowie die gemappten Punkte in blau angezeigt. Links findet sich nun der Relationsprüfer, der anzeigt, ob eine Relation vorhanden ist und ob die Tags stimmen. Die Relation lässt sich zum Bearbeiten öffnen. Bei Punkten, die noch keine Relationen haben, wird stattdessen die Importfunktion angezeigt. Darunter werden die TMC-Daten angezeigt.
In der Datenbank habe ich jetzt Deutschland, Italien, Norwegen, Schweden und Finnland. Belgien kann man über ein schriftliches Formular beantragen, das kann ich auch mal versuchen. Siehe auch die Übersicht.
Falls jemand Wünsche oder Verbesserungsvorschläge für den TMC Viewer hat, oder irgendwas nicht richtig funktioniert, kann ich da gerne was dran ändern.
Im Wiki habe ich außerdem noch das Datenformat etwas ausführlicher dokumentiert.
Da damit die erste Stufe des Proposals praktisch fertig ist, könnte man selbige eigentlich zur Abstimmung freigeben. Allerdings habe ich die Befürchtung, dass sich wegen der geringen Zahl an unmittelbar Interessierten die Beteiligung in Grenzen hält und am Ende jemand das Ganze als “rejected” in die Tonne hauen will. Das ist natürlich nicht Sinn und Zweck der Sache. Für solche “Sparteninformationen”, die nur von einem kleineren Nutzerkreis direkt ausgewertet werden, ist das Proposal-Verfahren mit seinen Mindeststimmen eher ungeeignet. Vorschläge?
die beiden Tags neg_off und pos_off finde ich etwas wenig intuitiv. Alternativ wäre evtl. neg_offset / pos_offset oder sogar negative_offset/positive_offset möglich?
Auch wäre ein weiterer Link für ein “zoom” oder “load_and_zoom” in JOSM schön, damit man schneller in der Zielgebiet zoomen kann und dort zunächst automatisch die vorhandenen Daten geladen werden. Das entspricht also dem, was im rechten Teil als Karte im tmcview.php angezeigt wird.
Im zweiten Schritt kann man dann über “Import into editor” die Relation zusätzlich laden und mit den vorhandenen Daten verknüpfen.
Ich sehe gerade, dass das so schon auf der Proposal-Seite steht.
Nicht drüber abstimmen, die interessierten ausreichend darauf hinweisen und wenn keine Vorschläge mehr kommen einfach anwenden. Ich würde auch eher erwarten, dass sich genug Leute finden, die nicht verstehen (wollen?) worum es in dem Proposal geht, aber trotzdem abstimmen…
Könnte man auch machen. Ich hatte sie abgekürzt, weil ich es komplett ausgeschrieben etwas lang fand und sie auch so abgekürzt in den Tabellen schreiben, aber eine längere Form klingt auch gut.
Ich habe das Proposal noch einmal überarbeitet und dabei den Vorschlag von couchmapper mit aufgenommen. Am Ende sind es diese beiden Änderungen geworden:
pos_off / neg_off umbenannt in pos_offset / neg_offset. Ich denke, wenn man offset ausschreibt, ist klarer, was gemeint ist. Dagegen sollte die Bedeutung von pos / neg spätestens dann klar sein, wenn man beide zusammen getaggt vorfindet.
Verwirrung um road_ref beseitigt: Wenn man den Location Code der zugehörigen Straße als road_ref taggt, denkt stattdessen jeder sofort an den ref-Wert der Straße. Deshalb habe ich das ganze doch wieder so umgebaut, dass *_ref den ref-Wert von Straße (road_ref) oder Ausfahrt (junction_ref) abbildet, und dass die Location Codes stattdessen mit *_lcd getaggt werden. Ich denke, das dürfte keine große Verwirrung auslösen, wenn es hinreichend dokumentiert ist (und das wird es natürlich). Jemand, der sich mit TMC befasst und es auswerten möchte, dem ist lcd als Location Code ohnehin klar. Und wer es nicht kennt, der wird sich um die ihm fremde TMC-Relation entweder wenig kümmern, oder bei Bedarf im Wiki den Tag nachschlagen und dann die Erklärung finden können.
Inzwischen ist auch [Proposal Stufe 2: TMC Links](https://wiki.openstreetmap.org/wiki/Proposed_features/Relation:tmc/TMC_Links) weiter vorangeschritten und nimmt bereitwillig Verbesserungsvorschläge entgegen ;)
Ja, genau letzteres sehe ich auch als das Hauptproblem an. Der Vorschlag hört sich für mich sinnvoll an - ich denke, so kann man das machen.
Hi, ich klinke mich mal in die Runde mal ein, weil ich in meiner freien Zeit (z.Z. schreibe ich meine Abschlussarbeit für mein Studium) etwas mit TMC befasse. Ich habe kein TMC-Empfänger im GPS-Gerät kann aber mit der Zeit die RDS-TMC Daten mit Hilfe von verschiedenen kleinen Tools auswerten.
Ich beobachte den Thread schon eine Weile, kann sein, dass ich was übersehen habe, aber das Beispiel im Beitrag #101 auf Seite 5 ist doch recht interessant. Hier bringe ich wieder die Rolle der Nodes ins Spiel. Die Location 11611 ist ein TMC-Point, der in der Meldung kein Extend enthält, aber die Richtung negativ besitzt. So müsste ich in diesem Fall dennoch schauen, wo sich der Extend befindet um die korrekte Ausfahrt zu ermitteln. Wie schon von euch diskutiert erwähnt wäre es ein Problem bei den Routern. Erfassung der zusätzlichen Richtungen wäre für die Auswertung einfacher, aber bei der Erfassung und Pflege aufwendiger. Da ich die LCL nicht genau kenne, kann es sein, dass es fälle gibt, in denen es kein Prev oder Next gibt?
Ein anderer Interessanter Punkt, ist der Zusatz 162 (lt. 14819-2 Places: on slip Road) bedeutet ja das die Ein und Ausfahrt gesperrt ist. Frage wäre hier, ob ggf. die vollständigen Ein und Ausfahrten zusätzlich erfasst werden oder es ausreicht in diesen Fall der an dem Nodes angebundene *_link als gesperrt zu markieren. Alternativ den Weg, der nicht in der noch zu definerenden TMC-Line befindet.
Ich habe auch TMC-Meldungen gesehen, die sich auf Gebiete beziehen, da kann ich mich erinnern das ich letztens den Eintrag gesehen habe, der eine Störung der Notrufnummer enhielt. Von dieser Meldung war einer ganzer Landkreis betroffen, hier kann man auf die vorhandenen Relationen der Kreise und Länder zugreifen, ist nur fraglich, ob man die TMC-Bezeichung ggf. gleich in die Relation der Grenze mit einbetten könnte.
Wenn ich mit meiner Abschlussarbeit durch bin und ich dann neben der Arbeit Zeit habe habe ich vor eine Auswertung der TMC-Daten vor zunehmen, wo zu sehen ist welche Location und Events wie oft auftreten.
Stimmt, guter Punkt eigentlich. Ja, so einfach ist das in diesem Fall tatsächlich nicht, wenn man nur die Nodes ohne Rollen erfasst… Es sei denn, die Ausfahrt ist ein Teil einer Route, die ein Router ermittelt hat. Dann weiß der Router, welche TMC Locations in welcher Reihenfolge auf der Route liegen und somit, in welcher Richtung der Fahrer unterwegs ist. Damit weiß er auch, ob die von ihm benutzte Rampe betroffen ist.
Ja, am Anfang und Ende einer Straße.
Den *_link zu finden und zu sperren klappt dann, wenn es nur eine Ausfahrt gibt. Bei komplexeren Situationen wie Autobahnkreuzen kann das schon deutlich komplexer werden… Deshalb sieht das Proposal für solche Fälle auch ein Mappen der Ein- und Ausfahrten vor, allerdings in einer späteren Ausbaustufe, weil das doch noch mehr Aufwand bedeutet.
Ich würde sie lieber in eine separate Relation für die TMC Area packen und dann die Grenzrelation als Member in diese TMC-Relation einbinden. Auf diese Weise kann man die TMC-Daten, falls es TMC irgendwann nicht mehr geben sollte, einfacher aufräumen und entsorgen. Das ist ja ein großer Kritikpunkt am derzeitigen Tagging. Übrigens treten auch oft Wettermeldungen für Glatteis etc. für Landkreise oder ganze Bundesländer auf.
Gute Idee. Wenn du etwas interessantes findest, lass es mich wissen
Hier werden jeweils die Nodes erfasst, an der das gerade Straßenstück endet. Apropos, es gibt ja auch Kreisel, bei denen sich die Straße unmittelbar vor dem Kreisel Y-förmig verzweigt. In dem Fall würde ich (nur) die Nodes erfassen, wo es sich verzweigt.
Da es auch von außerhalb des Forums keine weiteren Verbesserungsvorschläge zum Thema TMC Point Locations gegeben hat, würde ich es so machen wie von rayquaza vorgeschlagen und von mir für gut befunden und den…
Startschuss zum Mappen von TMC Point Locations als Relation type=tmc:point
…geben, und das natürlich im Wiki dokumentieren (und sicher auch selbst mitmappen). Um einen Überblick über die gemappten Punkte zu bekommen, habe ich einen kleinen Skript gebastelt, der auf Vollständigkeit und Konsistenz der gemappten Relationen prüft. Die Links dazu gibt es nach Ländern aufgeteilt unten auf der TMC-Startseite - Achtung, Deutschland ist dabei etwas über 500kB groß, da kann der Browser einen Moment für die Tabelle brauchen. Ganz unten gibt es dann auch noch eine kleine Statistik über die gemappten Punkte. Aktualisiert wird die Statistik nicht automatisch beim Aufruf, sondern jeden Tag um 2:00 deutscher Zeit.
Sobald ich wieder etwas Zeit zum Programmieren habe, werde ich mal versuchen, eine Übersichtskarte zu basteln.
da du das jetzt “freigegeben” hast, habe ich einfach mal die Probe gemacht. Hierzu habe ich mal die Landesstraße L79 in Brandenburg mit allen Points versehen: http://www.openstreetmap.org/changeset/20576141
Hierzu nun einige Anmerkungen, erst einmal mappt sich das mit mit deinem Tool schon recht gut, allerdings wenn ich auf Import to JOSM klicke, zoomt mein JOSM immer voll raus. daher markiere ich mir vorher die Punkte und drücke die 3, damit ich dann wieder nach dem Import an der richtigen Stelle lande.
Auch ist mir beim Eintragen so einiges aufgefallen, wo ich einfach mal nach Gefühl eingetragen habe:
Kreisverkehre mit Y, war ja schon geklärt, einfach den Punkt davor.
Des Weiteren hast du ja bei Motorway/Trunk junctions ja vorgesehen auf der normalen Straße nur 2 Punkte einzutragen, da hier die Auffahrten etwas genauer gemappt wurden worüber man sich streiten kann, hier habe ich alle 4 Schnittpunkte zugeordnet. Beispiel: http://www.openstreetmap.org/relation/3513442
Allgemein: Ich habe noch einige alte TMC-Punkte gefunden. Teilweise existieren sie als Relation auch auch direkt an den Nodes.
Übrigens wäre es für den Anwender der TMC-Zuordnungen allgemein, nicht nur bei den Nodes, interessant, welche Version der LCL gemappt wurde. Das ist nicht nur für den Anwender der Daten interessant, auch für die Pflege, so können bei wegfallenden Objekte einfach die Relation gelöscht werden, bei gebliebenen einfach automatisch die Versionsnummer hoch gesetzt bzw. ergänzt werden. Bei geänderten kann dann eine ToDo-Liste erstellt werden.
Um deiner großen Liste ein wenig die Übersicht zu geben, könntest du ja wenn du mal zeit hast diese mit Filter zu versehen bzw. in mehrere Teile teilen: Gesamtliste (wie jetzt), Erledigt, Offen, Differenzen.
Ja, das ist mir auch aufgefallen, da habe ich noch nicht ganz rausgefunden, was man dagegen machen kann… Vielleicht muss ich dem importierten OSM-File passende Bounds geben. Ich versuche das mal.
Das würde ich hier genau so machen. Dann wird immer mindestens ein Punkt passiert, egal von wo man auf die L 79 fährt oder von dieser kommt.
Sieht gut aus. Hier würden vielleicht die äußeren Punkte reichen, aber so macht es sicher Sinn, das würde ich so lassen.
Stimmt, die hatte ich auch gefunden. Die werden ja auch genutzt, z.B. vom Bayerischen Rundfunk. Wäre natürlich schön, wenn man dieses alte Tagging mit seinen verwirrenden Tags irgendwann rausnehmen könnte, wenn es nicht mehr genutzt wird, bzw. eben nach einer Umstellung auf das neue Tagging.
Das wäre eine Idee. Wobei ich denke, dass man das Löschen weggefallener TMC-Punkte und einen Abgleich, welche der gerade aktuellen LCL entsprechen, auch mittels der gemappten Location Codes machen könnte. Diese Überlegung hatten wir hier im Thread ja auch schon einmal, allerdings würde dann mit jeder neu aufgelegten LCL eine neue Version aller TMC-Relationen erzeugt werden, ohne dass sich deren eigentliche Daten ändern… Ich bin mir nicht sicher, ob das wirklich gerechtfertigt ist.
Gute Idee, das werde ich vielleicht heute Abend mal in Angriff nehmen. Danke auf jeden Fall für das Feedback
Das Problem mit dem Import in JOSM konnte ich mit einem Blick in den Sourcecode einkreisen: Tatsächlich zoomt JOSM nach einem Import immer auf die importierten Daten. Dabei berechnet es den Zoombereich aus dem Nodes in der importierten Datei. Wenn aber keine Nodes vorhanden sind wie in diesem Fall, wo nur Relationen ohne Mitglieder importiert werden, kann JOSM keinen Zoombereich bestimmen und zoomt stattdessen auf das Maximum. Da hilft leider auch nicht, die “bounds” in der OSM-Datei zu setzen. Und Nodes in die Datei zu packen macht auch keinen Sinn, wenn man nicht vorhat, diese auch tatsächlich zu importieren…
Sind das sicher die aktuellen TMC-Codes? Ich wundere mich etwas, dass die neue (seit Dezember 2012) Führung der B2 in München-Pasing noch nicht berücksichtigt ist… Der Punkt 21392 z.B. gehört zur alten Führung, die jetzt teilweise Einbahnstraße ist. Und die Kreuzung des neuen Abschnitts der B2 mit der St 2063 scheint (bei Suche nach den Straßennamen) auch noch keinen Location-Code zugewiesen bekommen zu haben.
Ich habe gerade noch einmal beim BASt nachgesehen. Tatsächlich sind das die derzeit verwendeten Codes der Version 12.0 - allerdings nur noch bis 8. April Es gibt bereits die neue Tabelle der Version 13.0 zum Download. Ich werde die gleich mal in meine Datenbank einspielen…
Aber generall kann es durchaus sein, dass die TMC-Daten etwas dem umgebauten Straßenverlauf “hinterherhinken”, weil sie nicht ganz so oft aktualisiert werden.
EDIT: Update abgeschlossen. Jetzt ist die neue Streckenführung drin, siehe 7467 und 7468. Mein Skript hat auch gleich Alarm geschlagen und von bisher 61 gemappten TMC-Punkten 3 als fehlerhaft bemängelt, darunter genau die beiden Nachbarn des nicht mehr existenten Knoten 21392. Korrigiert ist das auch schon
Wunderbar, damit gab es gleich einen “ungeplanten Testlauf” für ein Update der LCL. Fazit: Scheint problemlos geklappt zu haben.
Ich habe mir mal den Parkplatz Weilbach vorgenommen (und zwar, weil es für den gerade eine TMC-Meldung gibt, dass er gesperrt ist), um mal zu schauen, wie sich das Mapping von Infrastruktur wie Parkplätzen gestaltet. In der Relation sind nun nicht nur die Nodes auf der Straße, sondern auch Parkfläche und Toilette aufgenommen, und zwar mit den Rollen positive (Fahrtrichtung nach Frankfurt) und negative (Fahrtrichtung nach Köln).
Achtung! Das “alte” TMC-Tagging aus dem Import scheint genau die entgegengesetzten Richtungsangaben zu benutzen - im Wiki konnte ich gar keine klare Definition finden, wie dort TMC:Direction getaggt ist. In dem von mir vorgeschlagenen Tagging sind positive und negative so, wie sie tatsächlich in TMC zur Anwendung kommen - also ist die positive Fahrtrichtung vom positiven Offset weg. Das findet man auch genau so in den zugehörigen TMC-Meldungen (hier von meinem Skript übersetzt):
d3 68 85 45 83 23 e8 ed
d3 68 85 45 58 ec e9 f8
d3 68 85 45 0c 00 00 00
Event: 803 - (Q sets of) construction work
Location: 59629
Direction: positive
Extent: 0
Stop time: 236
Separator
Additional event: 1990 - car park closed (until Q)
Event: 803 - construction work
Event: 1990 - car park closed
Urgency: normal
Road: 7077 - A3 Köln - Frankfurt
Location: 59629 - Weilbach
Extent: 0
Stop time: middle of March
d3 68 85 43 c2 bd e8 ed
d3 68 85 43 58 f5 e9 f8
d3 68 85 43 0c 00 00 00
Event: 701 - (Q sets of) roadworks
Location: 59629
Direction: negative
Extent: 0
Stop time: 245
Separator
Additional event: 1990 - car park closed (until Q)
Event: 701 - roadworks
Event: 1990 - car park closed
Urgency: normal
Road: 7077 - A3 Frankfurt - Köln
Location: 59629 - Weilbach
Extent: 0
Stop time: end of July
Zum Vergleich: Von Köln nach Frankfurt geschlossen bis Mitte März, in der Gegenrichtung bis Ende Juli.
Hierzu habe ich mal die Landesstraße L79 in Brandenburg mit allen Points versehen: 
Es gibt bereits die neue Tabelle der Version 13.0 zum Download. Ich werde die gleich mal in meine Datenbank einspielen…