Überarbeitung von TMC / TPEG

Der Titel des Thread istwar für mich etwas zu speziell oder suggestiv. Ich finde die Diskussion sollte darum Kreisen, wie (für das adaptive Routing) Vekehrsinformationen wie TMC und/oder TPEG zusammen mit OSM-Daten verwendet werden können und wie man das am besten umsetzt.

woodpeck wrote:

Ich bin mittlerweile - und in die Richtung sind wir auch mit dem SWR gefahren - der Ueberzeugung, dass TMC-Daten ueberhaupt nicht in OSM hineingehoeren, ausser vielleicht in einigen wenigen Ausnahmefaellen. Wenn man sich bei der Software Muehe gibt, kann man meiner Ansicht nach ueber 95% der TMC-Segmente vollautomatisch aus OSM herleiten (nach dem Motto: Ich weiss aus der BASt-Tabelle, dass das Segment X von ungefaehr hier bis ungefaehr dort geht und A5 heisst, nun such ich mir mit einem Routing-Algorithmus in OSM die Strassenstuecke, die damit am wahrscheinlichsten gemeint sind).

Da klingen meine Alarmglocken. Ist es wirklich besser, das TMC/OSM-Mapping zu "raten" als es explizit aufzuschreiben? Kann ich kaum glauben.

Zu TMC vs. TPEG:

TMC ist de facto aktueller Standard (und das noch eine ganze Weile). Es sollte eine Möglichkeit geben, den zu unterstützen. ich sehe auch nicht, warum wir über entweder TMC oder TPEG entscheiden müssen.

Gehrke wrote:

Der Titel des Thread ist für mich etwas zu speziell oder suggestiv. Ich finde die Diskussion sollte darum Kreisen, wie (für das adaptive Routing) Vekehrsinformationen wie TMC und/oder TPEG zusammen mit OSM-Daten verwendet werden können und wie man das am besten umsetzt.

Vorschlag? Ändere ich gerne.

wambacher wrote:

Gehrke wrote:

Der Titel des Thread ist für mich etwas zu speziell oder suggestiv. Ich finde die Diskussion sollte darum Kreisen, wie (für das adaptive Routing) Vekehrsinformationen wie TMC und/oder TPEG zusammen mit OSM-Daten verwendet werden können und wie man das am besten umsetzt.

Vorschlag? Ändere ich gerne.

Z.B. "Unterstützung und Abbildung von TMC- oder TPEG-Informationen" ?

Als logisches "Oder" zu verstehen.

Gehrke wrote:

ich sehe auch nicht, warum wir über entweder TMC oder TPEG entscheiden müssen.

Wenn TPEG wirklich keine spezielle Unterstützung seitens OSM benötigt, ist die Frage wohl eher: TMC weiterpflegen oder nicht? Wenn wir es schaffen könnten, TMC korrekt und vollständig zu haben, bevor der Standard sich selbst überholt hat, wäre ich dafür. Wenn nicht, halte ich es auch nur für Ballast, der Neulingen wie mir damals an allen Ecken und Enden im JOSM Fehler um die Ohren wirft 🤔
Insgesamt kenne ich mich mit TMC aber zu wenig aus, als dass ich mehr sagen könnte als: Ich hätte gerne Verkehrsinfos auf OSM-Karten ausgewertet 😉

Ich bin derzeit nicht informiert genug, um mir eine qualifizierte Meinung zum Thema zu machen. Ich denke aber, dass eine Trennung von Routen-Relationen und TMC/TPEG sinnvoll ist.

Bevor wir entscheiden, die bestehenden TMC-Infos komplett zu vernichten, sollten wir aber einschätzen können, wie falsch/defekt/veraltet sie wirklich sind. Bei den TMC-Areas gibt es ja vielleicht gar nicht so viel Korrekturbedarf.

Gehrke wrote:

TMC ist de facto aktueller Standard (und das noch eine ganze Weile). Es sollte eine Möglichkeit geben, den zu unterstützen. ich sehe auch nicht, warum wir über entweder TMC oder TPEG entscheiden müssen.

TMC mag ja Standard sein, aber unsere Daten sind so schrottig, daß sie mMn niemand vernünftig verwenden kann. Frederik hat ja 1-2 potentielle Anwender genannt, aber deren Statement dazu fehlt noch. Ist kein Wunder, die müssen ja nicht unser Forum lesen.

Also: Wer TMC "verteidigen" will, muß (mir) aktive Anwender nachweisen.

Ich werde die Daten jedenfalls nicht pflegen - obwohl es mir gestern durchaus gelungen ist, einen fehlenden TMC-Point nachzutragen. Löschen werde ich sie auch (noch) nicht.

Meine Auswertung der Bundesstraßen wird ab sofort TMC-Daten ignorieren. oops, falscher Thread 😉

Gruß
walter

Topic-Vorschlag: "Überarbeitung von TMC / TPEG" - das wollte ich gerade als Thread aufmachen, aber ihr wart schneller 😉 Hier also mein Senf primär zu TMC:

Zunächst einmal ein paar allgemeine Infos zu TMC und TPEG. Wozu ist das gut? Es handelt sich um Protokolle, um Verkehrsinformationen zu übertragen die z.B. von Navigationsgeräten ausgewertet werden können, um Staus oder gesperrte Straßen zu umfahren, oder um Autofahrer vor Gefahrensituationen wie Wetterbedingungen oder Unfällen zu warnen. Infos dazu gibt es hier:

http://de.wikipedia.org/wiki/Traffic_Message_Channel
http://de.wikipedia.org/wiki/Transport_ … erts_Group
http://www.tisa.org/technologies/tmc/
http://www.tisa.org/technologies/tpeg/

Der Standard ist als ISO 14819 verfügbar. Für OSM interessant ist dabei vor allem der Location Code Standard ISO 14819-3, in dem angegeben ist, wie geografische Punkte in Form von Location Code Tabellen codiert werden. Für Auswerter / Navi-Programme ist außerdem der Event Code Standard ISO 14819-2 wichtig, in dem die Codierung von Ereignissen wie Staus oder Unfällen angegeben ist.

Die Idee von TMC in OSM besteht darin, dass man mit dem Tagging von Location Codes in OSM unmittelbar die Straßen finden kann, auf die sich ein Location Code und damit eine Verkehrsmeldung bezieht. Allerdings ist das derzeitige in Deutschland vorhandene Tagging, das aus einem Import stammt, mehr als unübersichtlich und entzieht sich einer Wartung:

http://wiki.openstreetmap.org/wiki/DE:T … rt_Germany

Ein besseres und übersichtlicheres Tagging wurde hier vorgeschlagen:

http://wiki.openstreetmap.org/wiki/DE:P … TMC_scheme

Das mag noch nicht perfekt sein, könnte aber als Grundlage für die Erarbeitung eines finalen Proposals dienen. Wie das genau aussehen soll, kann und muss man sich natürlich überlegen. Das sollte der erste Schritt sein, wenn wir TMC weiterhin in OSM haben und vor allem auch pflegen wollen.

Das eigentliche Einpflegen der Daten scheint dagegen nicht besonders schwierig zu sein. Die Tabelle der deutschen Location Codes (ca. 46300 Codes) bekommt man auf jeden Fall hier umsonst vom BASt:

http://www.bast.de/cln_030/nn_42544/DE/ … start.html

Darin enthalten sind die Location Codes, die offiziellen deutschen Bezeichnungen der Event Codes (interessant für Auswerter) und eine kurze, aber verständliche Beschreibung der mitgelieferten Daten. Die Location Code Tabelle gibt es u.a. als CSV-Datei. Für jeden Location Code findet man dort z.B.:

• Location Code Nummer
• Objektklasse (Fläche, Linie oder Punkt)
• Typ (Verwaltungsbezirk, Straße, Straßenabschnitt, Kreuzung...)
• Subtyp (Autobahnkreuz, Autobahndreieck, Autobahnausfahrt...)
• Koordinaten (WGS84)
• Referenz auf übergeordnetes Gebiet ("dieser Punkt ist im LK Gifhorn")
• Referenz auf übergeordnete Straße oder Segment ("dieser Parkplatz liegt am A 7 Abschnitt Hamburg - Hannover")
• Referenz auf benachbarte Punkte entlang der übergeordneten Straße (vorhergehende / nächste Ausfahrt etc.)
• Namen und Referenznummern von Objekten - Straßen, Straßensegmenten, Parkplätzen, Rastanlagen...
• Namen von Anfang und Ende eines Straßensegments (Hamburg - Hannover o.ä.)
• Zusatzinformationen (Parkplatz nur in nördlicher Fahrtrichtung vorhanden, Autobahn kann nur in westlicher Richtung befahren werden...)

Damit ist es auf jeden Fall sehr einfach, GPX-Dateien zu erstellen, die dann, nach Region sortiert, die dortigen Features enthalten und einem Mapper als Quelle dienen können. Die Daten an sich sollten also kein Problem darstellen. Für den Anfang wichtiger und vermutlich nicht ganz einfach ist wohl die Erarbeitung eines sinnvollen, wartbaren Taggings. Man könnte vielleicht so vorhehen:

• Bessere Dokumentation der verfügbaren Daten und des TMC-Datenmodells im Wiki
• Grafische Übersicht der Daten?
• Erarbeitung eines Tagging-Schemas, z.B. basierend auf dem o.g. Proposal
• Bereitstellung der Daten z.B. als GPX oder in einer anderen für Mapper aufbereiteten Form
• Einpflegen der Daten und Bereinigung / Löschung der veralteten TMC-Daten

So weit der Stand der Dinge. Der erste Punkt dürfte wohl keiner großen Diskussion bedürfen, den werde ich deshalb in Angriff nehmen und dabei auch die Wiki-Seite zu TMC etwas überarbeiten / ausbauen:

http://wiki.openstreetmap.org/wiki/TMC

EDIT: Naja, das war eigentlich als zusammenfassender un einleitender Eröffnungspost gedacht 😉 Also ich denke, wenn wir uns hier überlegen, ob wir TMC in modenisierter Form erfassen (und ich sage nicht behalten - den derzeitigen Datenbestand behalten halte ich für sinnlos), sollte auf jeden Fall umrissen werden, was genau das für Daten sind, wie sie aussehen und was sie aussagen. Siehe eben dieser Post.

Nadjita wrote:

Wenn TPEG wirklich keine spezielle Unterstützung seitens OSM benötigt, ist die Frage wohl eher: TMC weiterpflegen oder nicht?

Ich mag noch nicht glauben, dass Geo-Koordinaten alleine ausreichen. TPEG-Loc gibt z.B. ja auch Infos zu Ausfahrten etc. an. Aus dem Wikipedia-Artikel:

Um die oben genannten Ziele zu erreichen, werden neben den Ortskoordinaten im Koordinatensystem WGS84 (World Geodetic System 1984) weitere Informationen übertragen, die einen Bezug zur Umgebung herstellen sollen. Die Übertragung mit Hilfe von WGS84-Koordinaten ist deshalb sinnvoll, da dieses Referenzierungssystem unter anderem von GPS verwendet wird und einen weltweiten De-facto-Standard darstellt.

Zur Beschreibung eines Punktes, der zwischen zwei Autobahnausfahrten A und B liegt, werden beispielsweise neben den Koordinaten des Punktes auch die Namen der Ausfahrten verwendet. Die Vorteile dieser Angaben liegen auf der Hand: Ein Navigationssystem erhält die genaue Information, wo sich dieser Punkt befindet. PDAs ohne Kartenmaterial hingegen können ihren Nutzern zumindest ungefähr beschreiben, dass sich der genannte Punkt zwischen den beiden Ausfahrten A und B befindet.

Auch wenn man keinen "TPEG-Code" bräuchte, müsste OSM zumindest gewisse Voraussetzungen erfüllen (z.B. Ausfahrtnamen o.ä.), um die Zusatzinformationen zu verarbeiten.

Nadjita wrote:

Wenn wir es schaffen könnten, TMC korrekt und vollständig zu haben, bevor der Standard sich selbst überholt hat, wäre ich dafür. Wenn nicht, halte ich es auch nur für Ballast, der Neulingen wie mir damals an allen Ecken und Enden im JOSM Fehler um die Ohren wirft 🤔

Da TMC in Millionen von Navis verwendet wird, gehe ich nicht davon aus, das in weniger als 5-10 Jahren stirbt.

Gehrke wrote:

Z.B. "Unterstützung und Abbildung von TMC- oder TPEG-Informationen" ?

Als logisches "Oder" zu verstehen.

Es gibt keine TPEG-Informationen, die man irgendwie in den OSM-Daten unterstützen müsste/könnte - das ist ja gerade das Reizvolle daran (für mich).

Gruss
walter

was man eventuell bräuchte, ist ein Software-Modul, daß aus der von TPEG per Funk/Inet/Wlan/? übermittelten GPS-Position "DA ist ein Stau in Richtung xxx", die richtige Stelle sucht.

wambacher wrote:

Wer TMC "verteidigen" will, muß (mir) aktive Anwender nachweisen.

Ich bin nicht generell für TMC, sondern für ein behutsames Vorgehen. Aber ich sage auch, OSM sollte nicht nur die schützen, die es derzeit aktiv nutzen, sondern auch bestrebt sein, mehr Nutzer/Anwender zu gewinnen. Die Katze beißt sich in den Schwanz, wenn wir nur unterstützen wollen, was schon genutzt wird.

Es gibt auch den Ansatz von Telenav ein eigenes Segmentierungssystem für OSM zu verwenden. Ob jetzt dieses oder noch ein anderes, ich denke es wäre zielführender sich Gedanken zu machen wie sowas für OSM aussehen könnte. Mit Einbezug von Überlegungen wie dies möglichst mapper-freundlich gemacht und auch zur Meldung (automatich oder manuell) von Problemen genutzt werden kann.

Die Segmentierungen eines Drittystems (TMC oder was auch immer) dann darauf abzubilden kann dann extern geschehen. Ich denke dies wäre auch eher im Sinn des Projektes als proprietäre Daten (TMC) in OSM zu importieren, die in weiten Teilen der Welt nur gegen Lizenzgebühren erhältlich sind.

Simon

wambacher wrote:

Es gibt keine TPEG-Informationen, die man irgendwie in den OSM-Daten unterstützen müsste/könnte - das ist ja gerade das Reizvolle daran (für mich).

Wäre ja schön. Wie wird eine Warnung "Klotz auf der Fahrbahn" bei Autobahnen einer Fahrtrichtung zugeordnet? Durch zwei Koordinaten, die eine Richtung beschreiben? Klingt irgendwie hässlich.

SimonPoole wrote:

Es gibt auch den Ansatz von Telenav ein eigenes Segmentierungssystem für OSM zu verwenden. Ob jetzt dieses oder noch ein anderes, ich denke es wäre zielführender sich Gedanken zu machen wie sowas für OSM aussehen könnte. Mit Einbezug von Überlegungen wie dies möglichst mapper-freundlich gemacht und auch zur Meldung (automatich oder manuell) von Problemen genutzt werden kann.

Die Segmentierungen eines Drittystems (TMC oder was auch immer) dann darauf abzubilden kann dann extern geschehen. Ich denke dies wäre auch eher im Sinn des Projektes als proprietäre Daten (TMC) in OSM zu importieren, die in weiten Teilen der Welt nur gegen Lizenzgebühren erhältlich sind.

Klingt gut. Wie robust wäre dieses externe Mapping bei Änderungen wie aufgetrennten Wegen? Wenn man das auf Segmente von intakten Routenrelationen beziehen könnte, wäre das wohl gangbar.

Gehrke wrote:

wambacher wrote:

Es gibt keine TPEG-Informationen, die man irgendwie in den OSM-Daten unterstützen müsste/könnte - das ist ja gerade das Reizvolle daran (für mich).

Wäre ja schön. Wie wird eine Warnung "Klotz auf der Fahrbahn" bei Autobahnen einer Fahrtrichtung zugeordnet? Durch zwei Koordinaten, die eine Richtung beschreiben? Klingt irgendwie hässlich?

Komisch ist es schon, aber da muß man erst mal durch die Spezifikationen von TPEG durchsteigen um zu verstehen, wie das wirklich funktioniert/funktionieren soll - was ich auch noch nicht gemacht habe. Dazu ist das Thema hier noch zu frisch.

Aber eines ist mir klar: Es werde im Datenbestand der Anwendung/des Navis keinerlei TPEG-spezifischen Daten benötigt, kein TPEG-Point, TPEG-Segment oder gar TPEG-Area. Die kriegen das irgendwie hin und das reicht mir momentan.

Gruss
walter

ps: Total OT: 7 PLZ-Rels missing, bin schon dran.

Gehrke wrote:

...

Klingt gut. Wie robust wäre dieses externe Mapping bei Änderungen wie aufgetrennten Wegen? Wenn man das auf Segmente von intakten Routenrelationen beziehen könnte, wäre das wohl gangbar.

So viel ich weiss ist bei TTL (den Telenav Vorschlag einfach mal als Beispiel genommen, siehe auch http://wiki.openstreetmap.org/w/images/ … ations.pdf ) dies eine einfache ID, sprich es überlebt mindestens so gut (oder so schlecht) wie das aktuelle TMC Gewusel.

IMHO ist es aber eher den Mappern beizu bringen, die "OSMTrafficId" an einem Objekt nicht zu entfernen, als irgendwelchen undurchsichtigen TMC-Salat. Desweiteren könnte man, wenn tatsächlich ein OSM-weites System und nicht nur ein Deutsches eingeführt würde, dies auch in den Editoren ohne grossen Aufwand speziell behandeln..

Simon

Der Vollständigkeit halber hier noch mal der TMC-Link von Infoware/Geofabrik:

http://osm-tmc.infoware.de/tmc/

So ein OSM-eigenes System wäre natürlich auch nett, wenn man denn hinterher gut z.B. einen TMC-Verkehrhinweis in eine OSM-Streckeninformation übersetzen kann. In so einem Fall sollte man es zumindest so weit kompatibel / allgemein halten, dass man von TMC, TPEG oder anderen Quellen für Verkehrsinfos eindeutig und umfassend übersetzen kann. Das mag nicht unbedingt einfach sein, aber auch nicht unbedingt unmöglich. Wie schwer genau, kann ich schwer einschätzen.

Den Vorteil z.B. von TMC (und in Zukunft TPEG) sehe ich darin, dass es sich um einen wohldefinierten Standard handelt, den eine Gruppe von Leuten in einem gewisse Zeit dauernden Prozess erarbeitet hat. Da steckt also schon viel Überlegung drin, die man für einen eigenen Standard erst einmal auf die Beine stellen müsste.

Nach einem ersten Blick auf den TPEG-Loc-Standard ISO TS 14234-6 finde ich ehrlich gesagt nicht ganz überzeugend, wie man dort ein Objekt sicher finden soll... Dort ist als Beispiel eine Beschreibung für "Terminal 1 des Flughafens Frankfurt" angegeben - viel Spaß beim Entziffern:

location_co-ordinates
location_type:␣nodal␣area␣(loc01_2)
mode_type_list
mode_of_transport:␣aircraft␣(loc05_9)
mode_of_transport:␣railway␣(loc05_2)
point
WGS␣84
longitude:␣E␣8.56964
latitude:␣N␣50.05062
radius␣of␣expansion:␣3␣km
descriptor
type:␣tpeg-ilc1␣(loc03_7)
text:␣A03
descriptor
type:␣tpeg-ilc2␣(loc03_8)
text:␣B43
descriptor
type:␣tpeg-ilc3␣(loc03_9)
text:␣Hugo-Eckener-Ring
descriptor
type:␣node␣name␣(loc03_2)
text:␣Frankfurt␣Airport

Also das auszuwerten stelle ich mir gruselig vor, jedenfalls deutlich komplexer als eine einfache ID. Und wenn dann noch ein Tippfehler in einem Straßennamen ist, klappt das Matching auch nicht mehr.

SimonPoole wrote:

So viel ich weiss ist bei TTL (den Telenav Vorschlag einfach mal als Beispiel genommen, siehe auch http://wiki.openstreetmap.org/w/images/ … ations.pdf ) dies eine einfache ID, sprich es überlebt mindestens so gut (oder so schlecht) wie das aktuelle TMC Gewusel.

Ich denke, wir sind und einig darin, dass das aktuelle TMC-Gewusel unbrauchbar ist und aufgeräumt / abgelöst / rausgeworfen werden sollte. Es sollte also eher verglichen werden zwischen einem OSM-eigenen System und einem neuen, besseren TMC-Mapping, das nicht so ein Gewusel darstellt. Dann hätte man vermutlich in beiden Fällen eine einfache ID.

IMHO ist es aber eher den Mappern beizu bringen, die "OSMTrafficId" an einem Objekt nicht zu entfernen, als irgendwelchen undurchsichtigen TMC-Salat. Desweiteren könnte man, wenn tatsächlich ein OSM-weites System und nicht nur ein Deutsches eingeführt würde, dies auch in den Editoren ohne grossen Aufwand speziell behandeln..

Ein neues Tagging sollte auf jeden Fall international einheitlich sein, gar keine Frage - egal ob nun TMC oder OSM-eigen. Es stimmt natürlich, dass TMC nicht den ganzen Globus abdeckt. Hier in Estland ist es z.B. (derzeit) nicht im Einsatz, aber wohl in Planung (so weit ich ein Proposal verstanden habe, das ich auf der Webseite des hiesigen Straßenbauamtes gefunden habe). Was für Systeme es in anderen Ländern gibt, wo es kein TMC gibt, habe ich noch nicht herausgefunden.

MHohmann wrote:

So ein OSM-eigenes System wäre natürlich auch nett, wenn man denn hinterher gut z.B. einen TMC-Verkehrhinweis in eine OSM-Streckeninformation übersetzen kann. In so einem Fall sollte man es zumindest so weit kompatibel / allgemein halten, dass man von TMC, TPEG oder anderen Quellen für Verkehrsinfos eindeutig und umfassend übersetzen kann. Das mag nicht unbedingt einfach sein, aber auch nicht unbedingt unmöglich. Wie schwer genau, kann ich schwer einschätzen.

Ich würde in keinem Fall Perfektion anstreben (Deutsche Krankheit), sondern einfach gut genug, sprich es muss nicht jede Feinheit jedes Systems 1 zu 1 abbildbar sein.

Ein neues Tagging sollte auf jeden Fall international einheitlich sein, gar keine Frage - egal ob nun TMC oder OSM-eigen. Es stimmt natürlich, dass TMC nicht den ganzen Globus abdeckt. Hier in Estland ist es z.B. (derzeit) nicht im Einsatz, aber wohl in Planung (so weit ich ein Proposal verstanden habe, das ich auf der Webseite des hiesigen Straßenbauamtes gefunden habe). Was für Systeme es in anderen Ländern gibt, wo es kein TMC gibt, habe ich noch nicht herausgefunden.

Es geht weniger darum wie verbreitet TMC ist, sondern das die entsprechenden Tabellen für andere Länder nur gegen Geld erhältlich sind.

Das Hauptproblem sind ja weniger die vielen Punkt-Lokationen, sondern vielmehr die aufwendige Pflege der vielen Routen. Wie wäre es also mit dem Vorschlag, zumindest diese Punkte soweit möglich vollständig in OSM zu haben? Also, folgende Informationen, sortiert in absteigender Wichtigkeit (!):

1. Alle (wichtigen) Punkte mit TMC-ID, Typ erfassen. Das lässt sich einfach validieren und ist auch überschaubarer Aufwand.
2. Alle wichtigen Punkte mit einem Tag versehen, mit welchen anderen Punkten sie durch Strecken verbunden sind (tmc_connected_to=id1;id2;id3)
3. Eine saubere Form der bisherigen TMC-Routen einführen und diese Routen dort anlegen, wo man Wert auf solche Details legt.

SimonPoole wrote:

Es geht weniger darum wie verbreitet TMC ist, sondern das die entsprechenden Tabellen für andere Länder nur gegen Geld erhältlich sind.

Na gut, das klingt in der Tat nach einem ziemlichen Showstopper - ich war davon ausgegangen, dass zumindest die Location Codes frei verfügbar wären, und dass nur der TMC-Empfang selbst in anderen Ländern verschlüsselt wäre. Wenn man in OSM eine Unterstützung für Verkehrinfos einbaut, sollte man das natürlich möglichst so tun, dass es auch global funktioniert.

MHohmann wrote:

Nach einem ersten Blick auf den TPEG-Loc-Standard ISO TS 14234-6 finde ich ehrlich gesagt nicht ganz überzeugend, wie man dort ein Objekt sicher finden soll...

1000 links in thread, nur den kann ich nicht finden. bei iso selber mal eben 162 CH abdrücken, hab ich ehrlich keine Lust.

Gruss
walter

wambacher wrote:

1000 links in thread, nur den kann ich nicht finden. bei iso selber mal eben 162 CH abdrücken, hab ich ehrlich keine Lust.

Dafür hab ich auch nur Google bemüht - braucht wohl etwas [link:ftp://218.22.27.69/%E6%95%B0%E5%AD%97%E5%A4%9A%E5%AA%92%E4%BD%93%E5%B9%BF%E6%92%AD%E5%90%84%E7%B1%BB%E6%A0%87%E5%87%86%E6%94%B6%E9%9B%86/TPEG%E6%A0%87%E5%87%86/Binary/ISO%20TS%2018234-6-2006.pdf Google-Foo].

Ich habe gerade http://www.openlr.org/ entdeckt - das soll wohl ein offenes Location Referencing sein, entwickelt von TomTom. Ich schaue mir gerade deren Whitepaper an, werde aber noch nicht wirklich schlau daraus ob das für OSM irgendwie interessant ist.

Ohne jetzt die genauen Termine zu kennen: Aber wäre das Thema "TMC/TPEG" nicht auch etwas für eine der OSM-/GIS-Konferenzen?! Hier könnte dann auch auf die Zukunft von TMC und TPEG geschaut werden und was die Anforderungen von Routing-Software an das Vorhandensein von TMC-/TPEG-Informationen im Kartenmaterial angeht.

Ggf. wäre es auch sinnvoll, mal bei den Machern von Navigationssoftware nachzufragen, wie aktuell die in OSM vorhandenen TMC-Informationen ausgelesen werden (@MHohmann, ich glaube, Du hattest das Thema im vorangegangenen Thread mal angesprochen).

Mit diesen Informationen und den Informationen, die Frederick schon bereitgestellt hat bzw. vorliegen hat, könnte dann ein neues TMC-/TPEG-Schema aufgesetzt werden, was dann auch zukunftsweisend ist. Ich denke, das bringt mehr, als im "trüben zu fischen".

MHohmann wrote:

wambacher wrote:

1000 links in thread, nur den kann ich nicht finden. bei iso selber mal eben 162 CH abdrücken, hab ich ehrlich keine Lust.

Dafür hab ich auch nur Google bemüht - braucht wohl etwas [link:ftp://218.22.27.69/%E6%95%B0%E5%AD%97%E5%A4%9A%E5%AA%92%E4%BD%93%E5%B9%BF%E6%92%AD%E5%90%84%E7%B1%BB%E6%A0%87%E5%87%86%E6%94%B6%E9%9B%86/TPEG%E6%A0%87%E5%87%86/Binary/ISO%20TS%2018234-6-2006.pdf Google-Foo].

Danke, auf Seite 77 steht genau das, von dem Frederik geschrieben hat: es werden die Koordinaten des Punktes übermittelt und/oder der Name der Straße mit einigen anderen Namen für Brücken ,Kreisverkehre und ähnlichen benannten Objekten. Der Rest ist der Job des "Providers", der das Zeug dann auf das Endgerät bringt.

Damit ist das Thema für mich vorerst erledigt.

Gruss
walter

wegen der Komplexität der TPEG-Information: Die ist nicht für den Mapper sondern nur für den Auswerter relevant.

Ich habe die TMC-Rohdaten von der BASt genommen und alle Punkte und -Verbindungen in ein GPX umgesetzt, das man dann in JOSM laden kann.

Hier als Beispiel die Region nördlich von Frankfurt (direkt in den Großstädten erkennt man wegen der Zahl der Knoten nichts mehr)

Straßennetz DE (png)

Ich kenne mich damit nicht aus. Aber ich denke es ist wichtig, dass das System auch abwärtskompatibel ist. Und am besten wird es natürlich auch sein, je mehr Systeme unterstützt werden. So wie es scheint ist TMC rein passiv und funktioniert durch UKW. Funktioniert das dann auch wenn man ein TPEG-fähiges Gerät hat bzw. funktioniert TPEG auch wenn TMC nicht mehr in OSM ist auf einem alten Gerät?

Was ich gerade sehe: TPEG soll auch für den öffentlichen Personenverkehr gemacht werden/sein. Heißt das, dass dies eine Art Fahrplanauskunft ist und ÖPNV-Routing ohne weitere Daten ermöglicht?

wambacher wrote:

Danke, auf Seite 77 steht genau das, von dem Frederik geschrieben hat: es werden die Koordinaten des Punktes übermittelt und/oder der Name der Straße mit einigen anderen Namen für Brücken ,Kreisverkehre und ähnlichen benannten Objekten. Der Rest ist der Job des "Providers", der das Zeug dann auf das Endgerät bringt.

Richtig, TPEG orientiert sich an Namen, und die sind ohnehin in OSM enthalten. Ein "TPEG-Tagging" können wir damit also abhaken, weil es in TPEG keine gesondert zu erfassenden Informationen gibt.

wegen der Komplexität der TPEG-Information: Die ist nicht für den Mapper sondern nur für den Auswerter relevant.

Richtig, genau darauf habe ich mich bezogen. Aus der Perspektive des Auswerters ist es ein Graus, solche Daten auswerten zu müssen. Das geht bei TMC um ein vielfaches einfacher, weil man nur Nummern abgleichen muss, und nicht aus so einer Beschreibung wie in meinem Beispiel oben schlussfolgern muss, was denn nun für ein Objekt gemeint ist - auf den Frankfurter Flughafen wäre ich ja noch gekommen, aber auf Terminal 1 nicht, und eine Ausdehnung von 3km wie dort angegeben hat das auch nicht (sondern eher der ganze Flughafen). Dazu kommt noch, dass es bei Straßen- und Ortsnamen ja gelegentlich das leidige Problem mit den Varianten gibt - seien es nun Unterschiede zwischen Straßenschild und amtlicher Liste oder was auch immer. Zusammen mit der Position mag man in den meisten Fällen ja als Mensch noch die richtige Straße finden, aber für eine Auswertesoftware ist das nicht ganz so einfach.

Insofern sehe ich TPEG auch sonst als abgehakt an.

Wir müssen also zumindest nicht befürchten, dass TMC so schnell auf dem Markt verschwindet und durch TPEG ersetzt wird. Gerade von Open Source Software wird wohl eher ein einfacheres System wie TMC implementiert, oder eben etwas anderes, das vergleichbar einfach ist. Bleibt also weiterhin die Frage, wie man sowas in OSM implementiert, und ob man etwas eigenes entwickeln will, oder einen bereits vorhandenen Standard nutzen.

@mueschel: Ah, hübsch, genau an sowas hatte ich gedacht 🙂

MHohmann wrote:

Aus der Perspektive des Auswerters ist es ein Graus, solche Daten auswerten zu müssen. Das geht bei TMC um ein vielfaches einfacher, weil man nur Nummern abgleichen muss, und nicht aus so einer Beschreibung wie in meinem Beispiel oben schlussfolgern muss, was denn nun für ein Objekt gemeint ist (...). Dazu kommt noch, dass es bei Straßen- und Ortsnamen ja gelegentlich das leidige Problem mit den Varianten gibt - seien es nun Unterschiede zwischen Straßenschild und amtlicher Liste oder was auch immer. Zusammen mit der Position mag man in den meisten Fällen ja als Mensch noch die richtige Straße finden, aber für eine Auswertesoftware ist das nicht ganz so einfach.

Insofern sehe ich TPEG auch sonst als abgehakt an.

Ich finde das praktisch und methodisch auch problematisch. Die Auswerter müssen viel mehr Hirnschmalz in die Software stecken und robust verschiedene (Falsch-)Schreibungen erkennen. Und schon bei TMC bekommen es die meldenden Stellen anscheinend oft nicht hin, die richtige Fahrtrichtung anzugeben. Wie soll das erst werden, wenn da mehr oder weniger Freitext für Objektnamen reingemüllt wird?

Gehrke wrote:

Ich finde das praktisch und methodisch auch problematisch. Die Auswerter müssen viel mehr Hirnschmalz in die Software stecken und robust verschiedene (Falsch-)Schreibungen erkennen. Und schon bei TMC bekommen es die meldenden Stellen anscheinend oft nicht hin, die richtige Fahrtrichtung anzugeben. Wie soll das erst werden, wenn da mehr oder weniger Freitext für Objektnamen reingemüllt wird?

Verstehe ich nicht. Für eine genaue Positionsangabe werden Koordinaten übertragen. Da weißt dann auf 'nen Meter genau wo der Stau anfängt und wo er aufhört. Also hier (http://www.mdr.de/mdr-info/Dab-verkehr100.html) klingt das sehr positiv (gut, Eigenwerbung muss man vielleicht rausfiltern 😉).

Hallo ihr TMC-Helden,

bevor ihr weiter über "Sein oder Nichtsein" von TMC in den OSM-Daten diskutiert, prüft doch bitte mal ob es eine Anwendung für OSM-Daten gibt die TMC-Daten empfnagen, decodieren und anzeigen kann.

Wenn diese Anwendung dann auch noch entsprechend verbreitet ist kann man vielleicht darüber nachdenken die TMC-Daten zu aktualisieren.

Meine Erfahrung mit TMC und TMC+ (muß man bezahlen) sind mehr als schlecht, die Warnungen kommen spät oder garnicht.

Für die Nutzung von OSM-Daten über Handy/Tablet ist eine Übertragung von Verkehrsflussdaten über UMTS/LTE viel sinnvoller und wenn dann auch noch die aktuellen Baustelleninfos von Bund und Ländern einfiesst das beste.

MfG

Senni

Schina02 wrote:

Gehrke wrote:

Ich finde das praktisch und methodisch auch problematisch. Die Auswerter müssen viel mehr Hirnschmalz in die Software stecken und robust verschiedene (Falsch-)Schreibungen erkennen. Und schon bei TMC bekommen es die meldenden Stellen anscheinend oft nicht hin, die richtige Fahrtrichtung anzugeben. Wie soll das erst werden, wenn da mehr oder weniger Freitext für Objektnamen reingemüllt wird?

Verstehe ich nicht. Für eine genaue Positionsangabe werden Koordinaten übertragen. Da weißt dann auf 'nen Meter genau wo der Stau anfängt und wo er aufhört. Also hier (http://www.mdr.de/mdr-info/Dab-verkehr100.html) klingt das sehr positiv (gut, Eigenwerbung muss man vielleicht rausfiltern 😉).

Mit reinen Geo-Koordinaten (die ja auch im Zweifel gar nicht auf dem OSM-Way liegen) ist es eben oft nicht getan. Stichwort Fahrtrichtung/Streckenabschnitt. Das sind dann benannte Objekte. Aus Deinem Artikel:

"Jetzt kommt aber noch dazu, dass wir über TPEG Informationen zum Verkehrsfluss übertragen - wie schnell in diesem Autobahnabschnitt grad gefahren wird. Das heisst, man kann daran schon ablesen, löst sich der Stau auf oder nicht. Das müssen nicht Sie ablesen, das macht am Ende ihr Navi. Weil es am Ende die diese Informationen zusammensetzt: Wie lang ist der Stau? Und wie ist die Durchschnittsgeschwindigkeit in diesem Abschnitt?"

Aber, zugegeben, ich weiß nicht genau, wie das bei TPEG geht und wie robust Navis das interpretieren können. Letztendlich ist das auch egal, weil wir hier nicht entscheiden müssen, ob TMC oder TPEG besser sind. Wir entscheiden jetzt doch eher darüber, ob und wie TMC (noch) unterstützt werden kann.

Was fehlt ist jemand aus der Praxis (Navi-Software-Anbieter, Meldestellen), der/die uns sagt, wie es mit TMC und TPEG weitergeht und wie z.B. Baustelleninfos derzeit gemeldet werden.

sennewald63 wrote:

bevor ihr weiter über "Sein oder Nichtsein" von TMC in den OSM-Daten diskutiert, prüft doch bitte mal ob es eine Anwendung für OSM-Daten gibt die TMC-Daten empfnagen, decodieren und anzeigen kann.

Ich hatte ja schon Navit als Beispiel gebracht, wo es geplant / in Arbeit ist. Nur wird sowas weder von Navit noch von irgendeiner anderen OSM-basierten Software umgesetzt, wenn keine oder nur unbrauchbare Daten vorhanden sind. Niemand wird sich die Mühe machen, etwas zu implementieren, das er dann mangels Daten nicht nutzen kann. Das ist ja das berühmte Henne-Ei-Problem: Irgendwo muss man mal anfangen.

Wenn diese Anwendung dann auch noch entsprechend verbreitet ist kann man vielleicht darüber nachdenken die TMC-Daten zu aktualisieren.

Nicht zu aktualisieren! Sondern zu ersetzen. Entweder durch ein komplett neues TMC-Tagging oder ein wie auch immer geartetes, neues System, das am Ende auch mit TMC-Meldungen etwas anfangen kann.

Meine Erfahrung mit TMC und TMC+ (muß man bezahlen) sind mehr als schlecht, die Warnungen kommen spät oder garnicht.

Die Erfahrung habe zumindest in Deutschland ich nicht gehabt, gerade deshalb vermisse ich TMC (oder etwas vergleichbares) hier etwas. Und ich fand es immer schade, dass nur mein Auto-Navi mit proprietärem Datenmaterial TMC kann.

Für die Nutzung von OSM-Daten über Handy/Tablet ist eine Übertragung von Verkehrsflussdaten über UMTS/LTE viel sinnvoller und wenn dann auch noch die aktuellen Baustelleninfos von Bund und Ländern einfiesst das beste.

Wenn man entsprechende Hardware, Software und Datenquellen hat, ja. Das trifft auf die meisten Navis aber nicht zu.

Hallo,

eine App die Stau, Baustellen und Verkehrsfluss darstellen soll gibt es z.Bsp. hier http://www.adac.de/mobile_angebote/maps … geId=20010 oder seht euch mal das nicht so sehr beliebte google an.

Wenn ich mir die Artikel aus 2010 zu Navit z.Bsp. http://www.linux-community.de/Internal/ … er-Polizei durchlese, stellt sich eben auch die Frage wann TMC in Navit eingebunden wird.
Leider muß man natürlich auch Fragen weshalb das für opensource so offene Brandenburg seine Geodaten nicht frei gibt.

Die BASt-Daten hatten 2013 Version 12, die in OSM vorhanden sind Version 8 oder 9, wenn ich da rückrechne bin ich wieder bei 2009/2010.

Bei der ganzen Sache steht doch eigentlich auch die Man-power mit zur Diskussion. Wollen wir viel Zeit in etwas einbringen dessen Nutzen nicht absehbar ist.
TMC würde seit dem Datenimport laufen. Es ist doch bestimmt sinnvoller, die Kraft in die bereits laufenden Projekte zu stecken.
Die Überarbeitung der Straßensysteme ist z.Bsp. angebracht, denn hier haben bestimmt einige was davon.

Das sind jetzt erstmal nur Denkanstöße.

Wenn die Entscheidung für die TMC-Überarbeitung gefallen ist werde ich euch in meinem Umfeld nach Möglichkeit unterstützen.

MfG

Senni

Daten nicht in OSM auf zu nehmen, weil sie sich ändern können halte ich nicht für einen zielführenden Ansatz. Mit der Begründung müssten dann ja auch Buslinien und vor allem Öffnungszeiten etc. von OSM ausgeschlossen werden.

Auch die Frage ob wir ein OSM eigenes System aufbauen wollen/können sollte hinterfragt werden. Denn das würde bedeuten das die Punkte wieder eigene IDs bekommen, welche weltweit eindeutig sein müssten. Das kann aber nur gewährleistet werden, wenn diese automatisch vergeben würden. Was passiert dann beim löschen und neuanlegen von Punkten? Das Gleiche wie mit der OSMID der Objekte! deshalb kann mich der Ansatz auch nicht überzeugen.

Was die Genauigkeit der TPEG Meldungen angeht, so darf bezweifelt werden, dass die Abweichung bei nur einem halben Meter liegt. Allein schon die Breite einer 8-streifigen Autobahn bringt schon eine immense Ungenaugkeit. Darüberhinaus muss natürlich auch darüber nachgedacht werden, wie die Meßwerte entstehen sollen. Bei GPS wird die genauigkeit nicht erreicht. Und feste Sensoren werden sicher nicht in einer solchen Dichte verbaut werden.

Was ist jetzt der Unterschied bei Verkehrsdaten über LTE? Eigentlich keiner. Sie werden nur automatisch verarbeitet und nicht redaktionell wie bei TMC. Es handelt sich dabei um die Verfolgung von Standortdaten, welche entweder von einem Mobilfunkanbieter stammen oder wie bei Googel auf Bassis der Verfolgung der Geräte mit eigener Software. Dabei ist immer zu hinterfragen, wie das matching passiert. Denn die Software muss unterscheiden zwischen Fußgängern und Autofahren oder jenen die im Bus sitzen.
Außerdem ist die Aussagekraft der Daten nur dann gegeben, wenn die Stichprobe hinreichend groß und vor allem aktuell ist.

Das alles würde mich dazu verleiten TMC doch besser in OSM abzubilden. Wenn es in kurzer Zeit gelingen sollte ein automatching zu erstellen, so würde das viel Arbeit abnehmen und man müsste bei Änderungen der Version nur die geänderten Daten abgleichen. Dafür würde sich OSMI und/oder Notes anbieten.
Das diese tabellen in vielen Ländern geld kosten ist zwar schade, aber nicht zu ändern. Umso besser wäre es wenn wir die daten in OSM hätten. Entweder mittels lokaler Sponsoren, wie Radiosendern, oder eben über einen Spendenaufruf wie für neue Hardware. Auch in deutschland sollen ja Daten schon für OSm gekauft worden sein. Vielleicht hat ja auch Bing ein Interesse daran.

sennewald63 wrote:

Wenn ich mir die Artikel aus 2010 zu Navit z.Bsp. http://www.linux-community.de/Internal/ … er-Polizei durchlese, stellt sich eben auch die Frage wann TMC in Navit eingebunden wird.

Derzeit hat Navit bereits eine Funktion, um Routen unter Berücksichtigung auf Verkehrsstörungen zu berechnen. Was noch fehlt ist der Teil, der Navit sagt, wo sich gerade eine solche befindet. Dafür fehlen im wesentlichen noch 3 Komponenten: 1. Zugriff auf eine TMC-Datenquelle, 2. Decodierung der rohen TMC-Daten, 3. Lokalisieren der Verkehrsstörung auf der Karte und Eintragen in den Routinggraphen. Die Schwierigkeit von 1. hängt von der Datenquelle ab - da müsste man schauen, was für Daten ein RDS/TMC-Empfänger liefert. Wenn der sich unter Linux wie ein Character-Device verhält, aus dem man einfach einen Datenstrom bekommt, ist das einfach. 2. ist sehr einfach umzusetzen, dafür muss man "nur" ISO 14819-2 implementieren, und das sieht wirklich simpel aus, zumindest für mich als einer der Navit-Entwickler. 3. hängt stark davon ab, wie gut die Karte TMC oder etwas ähnliches unterstützt. Wenn TMC sauber getaggt ist, ist das ein Kinderspiel - wenn man fehleranfällige Dinge wie Straßennamen matchen muss ist es alles andere als einfach.

Bei der ganzen Sache steht doch eigentlich auch die Man-power mit zur Diskussion. Wollen wir viel Zeit in etwas einbringen dessen Nutzen nicht absehbar ist.

Ich denke der Nutzen wäre hier nicht kleiner als der von z.B. Busrouten. Die wurden vielleicht anfangs nur auf einer Karte angezeigt, weil für mehr die Datenlage einfach zu dünn war. Inzwischen fragt selten jemand nach deren Sinn und sie werden fleißig gemappt.

TMC würde seit dem Datenimport laufen.

...ist mit dem derzeitigen Mapping, durch das kaum jemand durchsteigt, aber schwer zu implementieren und unmöglich zu warten.

Es ist doch bestimmt sinnvoller, die Kraft in die bereits laufenden Projekte zu stecken.
Die Überarbeitung der Straßensysteme ist z.Bsp. angebracht, denn hier haben bestimmt einige was davon.

Ich habe natürlich keinen Zweifel am Sinn anderer Projekte, es soll hier auch keine Manpower abgezogen werden. Es ist ja bei OSM immer so, dass jeder das mappt, das ihn interessiert - seien es nun Straßen, Bahnlinien mit Signalen oder Busrouten. Und wenn sich jemand für TMC interessiert und es mappen möchte, warum nicht? Es ist doch jedem selbst überlassen und nicht etwa zentral organisiert, wer seine Kraft in welches Projekt steckt.

Noch eine Anmerkung: Auch wenn ich nun immer TMC geschrieben habe, will ich nicht zwangsläufig an TMC an sich festhalten, sondern meinetwegen kann es gerne auch ein anderes Verkehrsinfosystem sein, oder eben ein "Meta-System", in das man andere Verkehrsdaten übersetzen kann. Ich hatte nur deshalb TMC anfangs im Sinn, weil es ein derzeit weit verbreiteter Standard ist und ich es wünschenswert fände, eben diese Daten nutzen zu können, und in OSM etwas zumindest hinreichend kompatibles zu haben. Damit will ich aber nicht ausschließen, andere Quellen für Verkehrsinfos zu nutzen und das Tagging in OSM so zu gestalten, dass diese genutzt werden können. (Ein konkretes Beispiel habe ich derzeit nicht dafür, auch deshalb habe ich oben immer TMC geschrieben.)

Bevor das hier in "Klein-Klein" endet, sollte man m.E. mal den "großen Wurf" (Top-Down) diskutieren: Den bereits vorgeschlagenen Ansatz der vollständigen Neutralisierung.

Gruß Klaus

Beim probeweisen Umsetzen von TMC- zu normalen route-Relationen (B 312) habe ich festgestellt, dass beim Import der TMC-Daten in 2010 nur ein kleiner Teil der für die Auswertung der TMC-Meldungen benötigten Daten übernommen wurde ( siehe http://forum.openstreetmap.org/post.php … qid=389226).

Das was im Moment in OSM an TMC-Daten vorhanden ist, sieht zwar respektheischend aus, ist für ernsthafte TMC-Anwendungen aber wohl nur rudimentär zu gebrauchen.

viw wrote:

Daten nicht in OSM auf zu nehmen, weil sie sich ändern können halte ich nicht für einen zielführenden Ansatz. Mit der Begründung müssten dann ja auch Buslinien und vor allem Öffnungszeiten etc. von OSM ausgeschlossen werden.

+1.

Auch die Frage ob wir ein OSM eigenes System aufbauen wollen/können sollte hinterfragt werden. Denn das würde bedeuten das die Punkte wieder eigene IDs bekommen, welche weltweit eindeutig sein müssten. Das kann aber nur gewährleistet werden, wenn diese automatisch vergeben würden. Was passiert dann beim löschen und neuanlegen von Punkten? Das Gleiche wie mit der OSMID der Objekte! deshalb kann mich der Ansatz auch nicht überzeugen.

+1. Wenn man hier etwas eigenes aufziehen wollte, müsste das anders strukturiert sein als diese OSMID-Geschichte - allerdings sehe ich nicht, wie das dann aussehen sollte.

Was die Genauigkeit der TPEG Meldungen angeht, so darf bezweifelt werden, dass die Abweichung bei nur einem halben Meter liegt. Allein schon die Breite einer 8-streifigen Autobahn bringt schon eine immense Ungenaugkeit. Darüberhinaus muss natürlich auch darüber nachgedacht werden, wie die Meßwerte entstehen sollen. Bei GPS wird die genauigkeit nicht erreicht. Und feste Sensoren werden sicher nicht in einer solchen Dichte verbaut werden.

+1.

Das alles würde mich dazu verleiten TMC doch besser in OSM abzubilden. Wenn es in kurzer Zeit gelingen sollte ein automatching zu erstellen, so würde das viel Arbeit abnehmen und man müsste bei Änderungen der Version nur die geänderten Daten abgleichen. Dafür würde sich OSMI und/oder Notes anbieten.

Ja, das wäre ideal. Aber dafür braucht es erst einmal ein Tagging-Schema. Wenn man das hat, kann man sich überlegen, was für Tools man für einen (halb-)automatisierten Import bräuchte.

Das diese tabellen in vielen Ländern geld kosten ist zwar schade, aber nicht zu ändern. Umso besser wäre es wenn wir die daten in OSM hätten.

Eben. Damit würden die Daten auch für kleinere FOSS Projekte überhaupt erst zugänglich.

Entweder mittels lokaler Sponsoren, wie Radiosendern, oder eben über einen Spendenaufruf wie für neue Hardware. Auch in deutschland sollen ja Daten schon für OSm gekauft worden sein. Vielleicht hat ja auch Bing ein Interesse daran.

Gute Idee eigentlich. Fragt sich nur, wie viel das kosten würde - das sollte man als erstes rausfinden. Man könnte auch OSM-basierte Router wie Skobbler fragen, denn dort bestünde sicher ein Interesse an solchen Daten. Vom Navit-Projekt kann ich Martin (cp15) fragen, er hat eine Softwarefirma und bietet Routinglösungen an - das wäre dann ein Projekt, bei dem auch Navit (endlich) eine TMC-Funktion bekommen sollte. Hier im Forum kann ich auch mal Marek fragen - die Firma, bei der er arbeitet, hätte vielleicht auch Interesse.

toc-rox wrote:

Bevor das hier in "Klein-Klein" endet, sollte man m.E. mal den "großen Wurf" (Top-Down) diskutieren: Den bereits vorgeschlagenen Ansatz der vollständigen Neutralisierung.

Also ich denke, wir haben uns bereits darauf geeinigt, den bisherigen TMC-Datenbestand komplett rauszuwerfen. Das dürfte also erledigt sein, von mir aus kann da ein Kahlschlag gemacht werden. Und um den geht es in dieser Diskussion auch schon gar nicht mehr, so weit ich das sehen kann.

Die Diskussion ist doch schon lange beim nächsten Schritt angekommen: nämlich dabei, wie wir stattdessen TMC oder ein anderes System für Verkehrsmeldungen unterstützen. Und die Optionen dazu hat viw ja schon ganz gut aufgelistet. Was also machen wir nach dem Kahlschlag?

MHohmann wrote:

Also ich denke, wir haben uns bereits darauf geeinigt, den bisherigen TMC-Datenbestand komplett rauszuwerfen. Das dürfte also erledigt sein, von mir aus kann da ein Kahlschlag gemacht werden. Und um den geht es in dieser Diskussion auch schon gar nicht mehr, so weit ich das sehen kann.

Aber die TMC-Relationen bitte erst nach Migration der Routen in Standard-OSM. Die ganzen TMC-Tags bringen nicht viel, aber für die Bereinigung der Straßen-Relationen (anderer Thread) kann man die TMC-Routen-Schnipsel ganz gut gebrauchen.

seichter wrote:

Aber die TMC-Relationen bitte erst nach Migration der Routen in Standard-OSM. Die ganzen TMC-Tags bringen nicht viel, aber für die Bereinigung der Straßen-Relationen (anderer Thread) kann man die TMC-Routen-Schnipsel ganz gut gebrauchen.

Ich meinte auch nicht, dass es sofort sein müsste 😉 Nur dass ich nicht daran festhalte, und IMHO auch niemand sonst hier im Thread.

MHohmann wrote:

Also ich denke, wir haben uns bereits darauf geeinigt, den bisherigen TMC-Datenbestand komplett rauszuwerfen. Das dürfte also erledigt sein, von mir aus kann da ein Kahlschlag gemacht werden. Und um den geht es in dieser Diskussion auch schon gar nicht mehr, so weit ich das sehen kann.

Bitte nichts überstürzt löschen!

Der Bayerische Rundfunk verwendet die OSM TMC-Relationen für sein Verkehrsfunk-Redaktionssystem und lässt den dafür benötigten Datenbestand von einer Firma in OSM pflegen. Die Zukunft wird eindeutig durch TPEG bestimmt und die Rundfunkanstalten werden nach dem derzeitigen Probebetrieb die aktuellen Verkehrtsdaten zukünftig unter einer freien Lizenz jededermann zur Verfügung stellen. Für eine Überganszeit von mindestens 10 Jahren werden weiterhin TMC-Informationen ausgestrahlt. Die Untersuchungen, ob man zukünftig für die Codierung der Verkehrsmeldungen auf den OSM-Datenbestand zugreifen wird, laufen seit Mitte vergangenen Jahres. Wie bereits von Frederik erwähnt, ist beabsichtigt, die TMC-Informationen automatisiert in einem offenen parallelen System zu OSM zu pflegen. Daher lohnt es sich nicht mehr, viel Aufwand in die Pflege der TMC-Relationen zu stecken, aber für ein generelles Löschen ist es definitiv noch zu früh.

Joachim

DD1GJ wrote:

Daher lohnt es sich nicht mehr, viel Aufwand in die Pflege der TMC-Relationen zu stecken, aber für ein generelles Löschen ist es definitiv noch zu früh.

Danke für diesen substantiellen Hinweis.
Das heißt für mich, ich werde so vorgehen wie bisher: TMC-Relation kopieren und bearbeiten, die alte Relation lassen.

Ich bin auch gegen ein komplettes Löschen.

Ich sehe hier viele Point-Locations, die vollkommen in Ordnung sind und bei denen es beim Anlegen einige Handarbeit gekostet hat (nicht von mir, sondern von irgendwem in 2008/9). Z.B. gibt es einen Punkt, der keine Kreuzungen markiert sondern einen Ort. Die zugehörigen Kreuzungen und Abzweigungen sind allerdings 5 Stück die rund um den Ort verteilt liegen. Das wird man nie mit einem halb-automatischen Import wieder hinbekommen!
Die TMC-Relationen sind hingegen in vielen Fällen nicht brauchbar und können bei Bedarf auch recht schnell aus den (dann hoffentlich kompletten) Bundesstraßen-Relationen wiederhergestellt werden durch simples kopieren des entsprechenden Abschnittes.
Ich finde übrigens diese Anwendung von Relationen bei komplexeren Kreuzungen recht elegant:
http://www.openstreetmap.org/relation/1381302/history
Vorteile: Die einzelnen Knoten werden nicht zugemüllt mit Tags, es ist kein Problem, mehree Locations an einen Knoten zu taggen und komplexere Anlagen können in ihrer Gesamtheit erfasst werden.

Also aus meiner Sicht:
- Aufräumen bei den Relationen - JA
- Umstellen auf ein einfacheres Tagging bei den Punkten - JA (auch wenn das wirklich nicht kompliziert ist - nur wegen der langen Tags kompliziert aussieht)
- Kompletter Kahlschlag - NEIN, auf keinen Fall.

Wir dürfen auch nicht vergessen, dass es hier "nur" um 30.000 Punkte geht - das ist weniger Arbeit zu kontrollieren als im Augenblick für die OSMBugs gemacht wird!

DD1GJ wrote:

Bitte nichts überstürzt löschen!

Alles klar, danke für die Info! Das hatte ich Missverstanden - ich hatte gedacht, die Daten wären nur experimentell genutzt worden. In diesem Fall sollten sie natürlich vorerst in dieser Form erhalten bleiben, bis wir etwas besseres haben, und Nutzer wie der BR darauf vorbereitet sind.

Datenstand TMC-Inspector?

Welcher TMC-Datenstand steht denn hinter den TMC-Daten des TMC-Inspectors?

Ich hab einige Diskrepanzen zwischen dem TMC-Inspectors und der LCL-Liste (V. 12.0) des BaSt. Aufgefallen ist mit das bei der B 97/ B 156 in Sprengberg Ähm... Spremberg. Der TMC-Inspector arbeitet anscheinend nicht mit aktuellen Daten, für Spremberg ohne den neutrassierten Abschnitt der B 97.

Sven

@MHohmann

ich bin ja auch interessiert aktuelle Daten in meinem Navi zu haben und Verkehrsmeldungen zu empfangen.
Um zu testen was so ein TMC-Empfänger liefert kann man ja mit so etwas mal spielen "TomTom TMC-Empfänger und USB-Autoladegerät, inkl. Micro USB Adapter" , wird in einem großen Online-Logistikunternehmen für um die 15 Euro angeboten. Um die Daten Bundesweit zu empfangen müsstest du dann Empfänger verteilen. Problemm ist du bekommst nur TMC, TMC+ mußt du dir eine Lizenz kaufen, bei Medion/Gopal liegt die bei ca. 20 Euro pro Gerät.

Eine andere Möglichkeit wäre doch aber die Verkersmeldungsseiten der Rundfunksender / Automobilclubs auszulesen, deren Lizensen muss / sollte man aber auch beachten.

Grüße nach Estland und tausche nicht alles in Euros

Senni

sennewald63 wrote:

Um zu testen was so ein TMC-Empfänger liefert kann man ja mit so etwas mal spielen "TomTom TMC-Empfänger und USB-Autoladegerät, inkl. Micro USB Adapter" , wird in einem großen Online-Logistikunternehmen für um die 15 Euro angeboten.

Ja, die Hardware zu bekommen dürfte einfach sein. Ich frage mich, wie es mit der Softwareanbindung aussieht und wie man die Daten (z.B. unter Linux) ausliest. Bei GPS-Empfängern und NMEA ist das ja relativ einfach, vielleicht geht es bei TMC ähnlich.

Um die Daten Bundesweit zu empfangen müsstest du dann Empfänger verteilen.

Ja, in Deutschland ist das möglich, hier gibt es leider (noch) kein TMC 😉 Mit so einem Empfänger könnte ich hier also wohl leider nur RDS empfangen (so weit ich weiß, wird TMC auf dem gleichen Träger gesendet) und damit vielleicht sehen, ob das Gerät funktioniert, aber keine Daten bekommen, um den TMC-Empfang zu testen.

Eine andere Möglichkeit wäre doch aber die Verkersmeldungsseiten der Rundfunksender / Automobilclubs auszulesen, deren Lizensen muss / sollte man aber auch beachten.

Prinzipiell ja, aber das geht auch nur, wenn man gerade Internetzugang hat. Den habe ich z.B. unterwegs nicht.

Grüße nach Estland und tausche nicht alles in Euros

Also da Estland den Euro seit 1. Januar 2011 hat und Deutschland seit 1. Januar 2002, gibt es wohl nicht viel Grund zu tauschen 😉

Noch eine halbspontane Anregung zu einem etwaigen OSM-eigenen ID-System (ohne viel Ahnung von den Algorithmen und Anforderungen von Auswertern/Nutzern zu haben):

Ich könnte mir vorstellen, dass wir zusammengehörige Nodes/Ways, die gemeinsam ein wichtiges "Punktobjekt" darstellen (im Sinne von Systemen wie TMC, also z.B. Kreuzung, Autobahnausfahrt, Kreisverkehr, ...) jeweils in eine Relation packen (type=traffic_object, traffic_object=crossroads/..., description="Kreuzung A-Straße/B-Straße"/...) – oder einfach eine Fläche (closed way) (mit den entsprechenden Tags) um das Objekt herum eintragen (mein Favorit). Diese Relationen/Flächen bekommen keine explizite ID. Stattdessen suchen die Auswerter an den erwarteten Koordinaten nach Relationen/Flächen des passenden Typs (, was man beschleunigen könnte, wenn man erstmal schaut, ob die Relationen/Flächen aus dem letzten Suchdurchlauf noch da sind).

Im Wesentlichen wäre das eine Hilfestellung für Auswerter, wichtige "Punktobjekte" mit grob bekannten Koordinaten zu identifizieren, die in OSM aus mehreren ways und nodes bestehen, und sie auseinanderzuhalten, ohne IDs zu taggen.

Die Wege zwischen den Punktobjekten könnte man in eine Streckenrelation packen (type=traffic_object, traffic_object=road_segment), zusammen mit den Relationen/Flächen der Punktobjekte mit den Rollen to/from. Eine Identifizierung mit Streckenobjekten aus externen Datenbanken fände dann einfach über die verbundenen Punktobjekte statt – womit man auch hier keine explizite ID bräuchte.

Um einen Überblick zu bekommen und etwas Licht in das "abstrakte Datengewusel" zu bringen, als das die TMC-Daten den meisten Mappern wohl bisher erscheinen, habe ich auch mal, ähnlich wie mueschel, die deutschen TMC-Daten in GPX umgewandelt, der Handlichkeit halber aber in etwas kleinere Dateien zerteilt, und ein paar davon auf einer Karte dargestellt:

http://manuelhohmann.dyndns.org/osm/TMC.html

Dort sieht man nun die L 140 von NRW, die A 2 sowie die A 10 (Berliner Ring). Wenn man einen Punkt anklickt erhält man die Infos, die in der vom BASt gelieferten CSV-Datei enthalten sind. Dazu werde ich noch ein wenig im Wiki dokumentieren, aber zunächst einmal die wichtigsten und für uns interessanten Daten:

• LOCATIONCODE - eindeutige Codenummer dieses Punktes in der Tabelle
• TYPE, SUBTYPE - Objekttyp, z.B. Autobahnkreuz, Kreisverkehr, Parkplatz, Rastplatz...
• ROADNUMBER - ref der zugehörigen Straße
• FIRST_NAME - Name des Objektes
• AREA_REFERENCE - Location Code des Verwaltungsgebietes
• LINEAR_REFERENCE - Location Code der zugehörigen Straße oder Straßensegments
• NEGATIVE_OFFSET, POSITIVE_OFFSET - Location Codes der benachbarten Punkte entlang dieser Straße
• X_KOORD, Y_KOORD - WGS84-Koordinaten

Die Location Codes und ihre Koordinaten liegen außer in der .csv-Datei auch in mehreren .dat-Dateien in einem international standardisierten TMC-CSV-Format vor. Im gleichen Format findet man auch die TMC-Daten von Schweden, Norwegen und Italien, die Links dazu habe ich im Wiki gefunden. Wie es mit anderen Ländern und generell der Nutzung in OSM aussieht, habe ich bisher noch nicht eruiert.

Zu der Erläuterung:

MHohmann wrote:

LOCATIONCODE - eindeutige Codenummer dieses Punktes in der Tabelle

TYPE, SUBTYPE - Objekttyp, z.B. Autobahnkreuz, Kreisverkehr, Parkplatz, Rastplatz...

ROADNUMBER - ref der zugehörigen Straße

FIRST_NAME - Name des Objektes

AREA_REFERENCE - Location Code des Verwaltungsgebietes

LINEAR_REFERENCE - Location Code der zugehörigen Straße oder Straßensegments

NEGATIVE_OFFSET, POSITIVE_OFFSET - Location Codes der benachbarten Punkte entlang dieser Straße

X_KOORD, Y_KOORD - WGS84-Koordinaten

sollte noch mit gelistet werden, was ich hier geschrieben hatte:

streckenkundler wrote:

Was anscheinend keiner so richtig mitbekommen hat: in der LCL-Tabelle des BaSt ist zugleich eine Netzknotenliste (mit Koodinaten !!!) enthalten. Netzknoten ist zwar nichts, was man direkt in OSM braucht oder da hineingehört, Wichtig ist die Liste dennoch, weil man so anhand der Netzknoten sie auch ändernden Straßenabschnitte identifizieren kann. Leider ist die nicht vollständig: Hessen, Thüringen, Saarland und Schleswig-Holstein fehlen. Nomenklatur des Netzknotens ist recht einfach: die ersten vier Ziffern bezeichnen die Meßtischblattnummer. Dann schließt sich eine laufende Nummer pro Meßtischblatt an. Es ist zwar keine vollständige Netzknotenliste, aber alle, die Landesstraßen, Bundtesstraßen und Autobahnen identifizierenden Nummern sollten enthalten sein.

Sven

Hi, obwohl TMC nicht -mehr- mein Ding ist, möchte ich doch auf eine sehr gute PostGIS-Erweiterung hinweisen:

Das aktuelle PostGIS (schlage 2.0 oder höher vor) unterstützt Topologien.

Topologien bestehen aus Knoten, Kanten und Flächen (Nodes, Edges und Areas) und werden von Postgis als eigene Datentypen/Objekte verwendet. Das wartet geradezu auf TMS.

Die Doku ist ein wenig dürftig, aber wer sich wirklich dafür interessiert (z.B. Routing), wird da schon was finden können.

http://trac.osgeo.org/postgis/wiki/User … isTopology
http://postgis.net/docs/Topology.html

ach ja: Ich hab nichts gegen TMS, ich kenne inzwischen einigermaßen die Daten und deren Struktur, schaue da gerne nach und verwende die auch als Referenz - ich will die nur nicht mehr in OSM drin haben.

Gruß
walter

ps2: Zum Thema "eindeutige ID" schlage ich die Verwendung von UUIDs vor. Die sind aber bei osm-Talk mehrfach abgeblockt worden, ohne daß die Ablehner eine Alternative angeboten hätten

Aus dem Route-Schwester-Thread:

DoDoMR wrote:

Das Hauptproblem ist aus meiner Sicht, dass die TMC-Relationen type=TMC enthalten, wodurch der für Straßen-Relationen notwendige type=route ausgeschlossen ist. Insofern muss es, sofern für TMC-Anwendungen der type=TMC unabdingbar ist, zwangsläufig zwei Relationen (TMC- und route-Relationen) geben. Ob es tatsächlich für TMC bei Relationen bleibt, oder ob ggf. andere Informationen in OSM (oder wo auch immer) gespeichert, wird im Rahmen des anderen Thread geklärt.

"type=TMC" gefällt mir auch gar nicht. Entweder es ist ein Node oder eine Relation für Gebiete (type=boundary|multipolygon) oder Abschnitte (type=route).
Dann könnte z.B. "boundary|route=tmc" sein. Letztlich benötigt wird aber nur die TMC-ID, egal ob die nun direkt in OSM ist oder extern mit der passenden OSM-Relation verknüpft wird.

Kann die betreuende Firma das für den BR nicht schnell umstellen? Das ist ja nur eine kleine, einfache SQL-Abfrage.

wambacher wrote:

ach ja: Ich hab nichts gegen TMS, ich kenne inzwischen einigermaßen die Daten und deren Struktur, schaue da gerne nach und verwende die auch als Referenz - ich will die nur nicht mehr in OSM drin haben.

Das aktuelle TMC-Tagging will wohl auf die Dauer niemand hier in OSM drin haben, es wird nur eben noch genutzt. Deshalb ist ja auch völlig unstrittig, dass wir es rauswerfen, sobald wir etwas besseres haben (und das stattdessen genutzt werden kann). Genau darum geht es doch. Klar dass man dafür die Struktur verstehen muss, gerade deshalb versuche ich ja sie zu dokumentieren, damit auch andere außer uns beiden und den aktiven Postern hier sie verstehen und wir ein besseres Tagging bekommen 😉 Das geht nur nicht von heute auf morgen.

Worin genau besteht denn nun der Nutzen von PostGIS-Topologien im Zusammenhang mit TMC?

MHohmann wrote:

Worin genau besteht denn nun der Nutzen von PostGIS-Topologien im Zusammenhang mit TMC?

Ganz "einfach": TMC-Daten bestehen aus Points, Lines und Areas und Topologieen bestehen aus Nodes, Edges und Areas - andere Worte für die gleichen Begriffe.

Ein Datensatz aus der Location-Liste ist genau ein Topologie-Element, ohne auch nur irgendwas zusammensuchen zu müssen.

In PostGIS kann man ja geometrische Operationen mit den GIS-Objekten machen (Welche Linien schneiden sich wo? Welche Fläche ist die grösste?, ...) Und mit der Topology-Extension geht das auch mit Topologischen Objekten - und die Location-Liste von TMC besteht zu 100% aus topologischen Objekten.
Geht so in Richtung Graphen, Routing. Da wird sowas gebraucht. Und TMC ist auch nicht anderes.

Ist für dich allerdings wohl nur theoretisch interessant, da die Einarbeitung relativ mühsam ist. Und ich bin auch noch nicht sehr vertraut damit.

Gruß
walter

wambacher wrote:

Ganz "einfach": TMC-Daten bestehen aus Points, Lines und Areas und Topologieen bestehen aus Nodes, Edges und Areas - andere Worte für die gleichen Begriffe.

Na gut, so weit war ich noch mitgekommen, aber ich hatte bis eben gedacht, solche Objekte wären ohnehin schon in PostGIS vorhanden und nicht erst durch eine "Topologie-Erweiterung". IMHO werden doch auch OSM-Objekte schon seit längerem in PostGIS abgebildet, und die sind doch auch nichts anderes, oder? Wobei:

In PostGIS kann man ja geometrische Operationen mit den GIS-Objekten machen (Welche Linien schneiden sich wo? Welche Fläche ist die grösste?, ...) Und mit der Topology-Extension geht das auch mit Topologischen Objekten - und die Location-Liste von TMC besteht zu 100% aus topologischen Objekten.
Geht so in Richtung Graphen, Routing. Da wird sowas gebraucht. Und TMC ist auch nicht anderes.

...und ein GIS-Objekt ist kein topologisches Objekt (oder umgekehrt) - d.h. das ist nicht das gleiche?

Ist für dich allerdings wohl nur theoretisch interessant, da die Einarbeitung relativ mühsam ist. Und ich bin auch noch nicht sehr vertraut damit.

Ja, das fürchte ich auch 😉 Mit PostGIS hatte ich bisher noch nichts zu tun. Aber man weiß ja nie, was man nicht noch irgendwann mal brauchen wird...

MHohmann wrote:

ich hatte bis eben gedacht, solche Objekte wären ohnehin schon in PostGIS vorhanden und nicht erst durch eine "Topologie-Erweiterung". IMHO werden doch auch OSM-Objekte schon seit längerem in PostGIS abgebildet, und die sind doch auch nichts anderes, oder? ..

Nö, die sind wirklich was anderes. egal.

Gruss
walter

Ich habe hier einen Vorschlag zum Thema mapping von Punkt-Lokationen (meistens Kreuzungen). Hier ist eine Kreuzung, die zwei TMC Koordinaten hat:
http://www.openstreetmap.org/node/32906938

Dieser Knoten sowie der zweite Zentrale Kreuzungsknoten dieser Kreuzung sind Teil von zwei Relationen, die jeweils alle Infos zu diesem TMC-Punkt enthalten.
Leider zeigt osm.org/browse nicht den Typ der Relation an, aber das kann sich ja noch ändern.

Damit sind zwei zentrale Kritikpunkte hoffentlich behoben: Tag-Chaos an Punkten und Wegen sowie der Problemfall mehrerer überlagernder Punkte.
Was haltet ihr von dieser möglichen Lösung?

Die einzelnen Routen-Teilstücke werde ich in den nächsten Tagen hinzufügen. Das genaue Tagging innerhalb der Relation steht jetzt (noch) nicht zur Diskussion, das ist das alte Schema.

Hallo ins Forum,

grundsätzlich bin ich ja interessiert, dass Daten ala TMC ins Gerät kommen.
Ich benutze aber seit diesem Jahr kein Navi mehr, sondern alles geht über ein 7 Zoll Tablet mit OSMAND oder Mapfactor Navigator als Navi-Software.
Mein Gedankengang war dabei von teuren Kartenupdates der reinen Navi's weck zu kommen.

Hier wurde auch schon kräftig über TMC über Internet diskutiert http://www.car-pc.info/phpBB2/viewtopic … sc&start=0
und eine Anwendung auch benannt die Navi-Software verschiedenen Betriebssyteme erweitert.
Man würde also nicht bei 0 Anfangen müssen, ob allerdings die TMC-Tags von OSM dabei genutzt werden weiss ich nicht.

Ich kling mich jetzt für ein paar Tage aus.

MfG

Senni

Gehrke wrote:

woodpeck wrote:

Wenn man sich bei der Software Muehe gibt, kann man meiner Ansicht nach ueber 95% der TMC-Segmente vollautomatisch aus OSM herleiten (nach dem Motto: Ich weiss aus der BASt-Tabelle, dass das Segment X von ungefaehr hier bis ungefaehr dort geht und A5 heisst, nun such ich mir mit einem Routing-Algorithmus in OSM die Strassenstuecke, die damit am wahrscheinlichsten gemeint sind).

Da klingen meine Alarmglocken. Ist es wirklich besser, das TMC/OSM-Mapping zu "raten" als es explizit aufzuschreiben? Kann ich kaum glauben.

Sagen wir es mal so. Aus Nutzersicht waere es natuerlich toll, wenn ich jederzeit aktuelle Strassendaten mit durchgaengigen, korrekten TMC-Informationen bekommen koennte - so dass ich ohne komplizierte Logik eine Anfrage wie "ich hab hier eine Staumeldung fuer Segmente A,B,C, welche OSM-Ways sind betroffen" stellen kann und richtige und vollstaendige Antworten bekomme. Das waere fuer mich als Nutzer das beste.

(Selbst in dieser perfekten Welt waere vieles nicht trivial - wenn zum Beispiel ein Meldungstyp "Fahrbahnverengung" den TMC-Code eines Rastplatzes betrifft, dann sind damit *andere* Asphaltflaechen gemeint als wenn fuer den identischen TMC-Code ein "Rastplatz gesperrt"-Meldungstyp rausgeht - der gleiche TMC-Code betrifft mal die Autobahn, die am Rastplatz vorbeifuehrt, und mal die highway=services-Flaeche, die neben der Autobahn liegt. Aber das nur am Rande!)

Aber diese aus Nutzersicht tolle Welt werden wir nie hinkriegen, wir werden auch mit manueller Instandhaltung nie 100% erreichen, und es wird auch immer wieder passieren, dass irgendwas bei uns nicht fehlt, sondern schlicht falsch ist - weil ein Weg gesplittet und eine Relation nicht kopiert wurde, was auch immer, die meisten hier kennen das ja zur Genuege.

Selbst wenn bei uns alles ok ist, so kaemen doch neue Listen von der BASt, an die wir unsere Daten regelmaessig anpassen muessten (und das, obwohl sich in der realen Welt gar nichts aendert - auch komisch, oder).

Das heisst, dass ernsthafte Nutzer sich *eh* nie 100% auf OSM verlassen koennen, sondern die OSM-Infos mit geeigneten Routing-Algorithmen ueberpruefen muessen.

Wir koennten also maximal etwas liefern, was *ein bisschen* besser ist als das, was man sich selber ausrechnen kann. Im Unterschied zu dem, was man sich selber ausrechnen kann, wuerde unseres aber staendig mit Arbeitszeit "nachgefuettert" werden muessen. Und es wuerde die Arbeit unbeteiligter Mapper an anderen Dingen beeintraechtigen (weil die sich damit auseinandersetzen muessten, was das seltsame TMC-Tag da jetzt soll).

Unterm Strich, wenn man den moeglichen Nutzen auf die eine Waagschale legt und den Aufwand und die stoerenden Seiten auf die andere, scheinen mir die negativen Seiten zu ueberwiegen.

Bye
Frederik

woodpeck wrote:

Aber diese aus Nutzersicht tolle Welt werden wir nie hinkriegen, wir werden auch mit manueller Instandhaltung nie 100% erreichen, und es wird auch immer wieder passieren, dass irgendwas bei uns nicht fehlt, sondern schlicht falsch ist - weil ein Weg gesplittet und eine Relation nicht kopiert wurde, was auch immer, die meisten hier kennen das ja zur Genuege.

Selbst wenn bei uns alles ok ist, so kaemen doch neue Listen von der BASt, an die wir unsere Daten regelmaessig anpassen muessten (und das, obwohl sich in der realen Welt gar nichts aendert - auch komisch, oder).

Wo ist OSM denn je zu 100% fertig/aktuell? Es wird immer etwas geben was wir zwar erfassen können aber nicht vollständig erfasst ist bzw. nicht mehr aktuell ist.

Man braucht sich nur einmal die Postleitzahlen anschauen. Diese erfüllen dann auch den Tatbestand der Änderung ohne das sich etwas in der realen Welt ändert.

woodpeck wrote:

Das heisst, dass ernsthafte Nutzer sich *eh* nie 100% auf OSM verlassen koennen, sondern die OSM-Infos mit geeigneten Routing-Algorithmen ueberpruefen muessen.

Wir koennten also maximal etwas liefern, was *ein bisschen* besser ist als das, was man sich selber ausrechnen kann. Im Unterschied zu dem, was man sich selber ausrechnen kann, wuerde unseres aber staendig mit Arbeitszeit "nachgefuettert" werden muessen. Und es wuerde die Arbeit unbeteiligter Mapper an anderen Dingen beeintraechtigen (weil die sich damit auseinandersetzen muessten, was das seltsame TMC-Tag da jetzt soll).

Dies würde ziemlich vieles in OSM in Frage stellen. Sei es bei Adressen die angabe des landes der Plz oder ähnliches.

Ähnliches gilt für die Routen des ÖPNV. Auch Relationen von Straßen könnte man sich sparen, da diese ebenfalls aus externen Quellen mehr oder weniger genau über unser Netz gelegt werden können.

Die Frage ob man andere Nutzer damit behindert möchte ich grundsätzlich anzweifeln. Aber man läuft natürlich Gefahr, dass Nutzer die das nicht verstehen es weder pflegen noch darauf Rücksicht nehmen. Aber das gilt bei allen Datenstrukturen in OSM. Warum sonst gehen Grenzen und Küstenlinien immer wieder mal auseinander? Bestimmt nicht weil jemand da böse absichten hat.

woodpeck wrote:

Unterm Strich, wenn man den moeglichen Nutzen auf die eine Waagschale legt und den Aufwand und die stoerenden Seiten auf die andere, scheinen mir die negativen Seiten zu ueberwiegen.

Und das bestätigt meine Ansicht, daß wir uns mit TMC-Daten in OSM nicht rumärgern beschäftigen sollten.

tl;dr: Werden nicht gebraucht, sind permanent zu pflegen, "stören" -> weg damit.

als Referenz "wie hängt das alles zusammen? Welche Straßen ... gibt es?" allerdings prima zu verwenden.

Gruss
walter

woodpeck wrote:

Aber diese aus Nutzersicht tolle Welt werden wir nie hinkriegen, wir werden auch mit manueller Instandhaltung nie 100% erreichen, und es wird auch immer wieder passieren, dass irgendwas bei uns nicht fehlt, sondern schlicht falsch ist - weil ein Weg gesplittet und eine Relation nicht kopiert wurde, was auch immer, die meisten hier kennen das ja zur Genuege.

Natürlich erwartet (hoffentlich) niemand, dass die Daten, die in OSM vorhanden sind, zu 100% perfekt wären. Wenn wir wirklich ein perfektes Mapping, oder meinetwegen auch nur ein perfektes Straßenrouting, als Ziel anstreben würden, könnten wir gleich sämtliche Straßendaten in die Tonne hauen, mit dem Argument, dass diese immer Fehler enthalten, weil sie manuell gemappt sind. Natürlich enthalten OSM-Daten Fehler, so wie jede andere Karte auch, aber es ist doch gerade die Stärke von OSM, dass diese Fehler von einer Community behoben werden können, sobald sie jemand entdeckt oder meldet, im Gegensatz zu kommerziellen Karten, wo der Nutzer auf ein Update hoffen und dafür bezahlen müsste.

Selbst wenn bei uns alles ok ist, so kaemen doch neue Listen von der BASt, an die wir unsere Daten regelmaessig anpassen muessten (und das, obwohl sich in der realen Welt gar nichts aendert - auch komisch, oder).

So weit ich das bisher sehen kann, ändern sich bei einem solchen Update nicht auf einen Schlag alle Location Codes, sondern es gibt graduelle Änderungen. Die meisten Codes wären von einem Update also gar nicht betroffen. Man könnte genau so argumentieren, dass Verwaltungsgrenzen nicht in OSM gehören, weil es ja ständig Gemeindereformen gibt - und man da die Daten ändern muss, obwohl man in der realen Welt keinen Unterschied sieht.

Das heisst, dass ernsthafte Nutzer sich *eh* nie 100% auf OSM verlassen koennen, sondern die OSM-Infos mit geeigneten Routing-Algorithmen ueberpruefen muessen.

Es geht ja auch gar nicht darum, sich zu 100% auf die Daten zu verlassen. Natürlich müssen die Daten überprüft werden. Es ist aber wesentlich einfacher, vorhandene Daten auf ihre Konsistenz und Richtigkeit hin zu überprüfen, als sie komplett auszurechnen.

Wir koennten also maximal etwas liefern, was *ein bisschen* besser ist als das, was man sich selber ausrechnen kann. Im Unterschied zu dem, was man sich selber ausrechnen kann, wuerde unseres aber staendig mit Arbeitszeit "nachgefuettert" werden muessen. Und es wuerde die Arbeit unbeteiligter Mapper an anderen Dingen beeintraechtigen (weil die sich damit auseinandersetzen muessten, was das seltsame TMC-Tag da jetzt soll).

Das ist doch aber genau das gleiche Problem wie z.B. bei Busrouten, wobei die sogar noch in größerer Zahl vorhanden sein dürften und sich dynamischer ändern. Natürlich kann ein Nutzer sich diese auch selbst von den ÖPNV-Unternehmen holen statt aus OSM und man würde so das Risiko vermeiden, dass ein Mapper eine Busroutenrelation zerschießt. Das hätte man aber auch keine OSM-ÖPNV-Karten. Deshalb sollte es natürlich das Ziel eines wie auch immer gestalteten Tagging sein, es so einfach wie nur möglich zu halten, damit auch Nutzer, die sich mit TMC nicht auskennen, damit keine Probleme bekommen.

Dazu kommt noch das IMHO beste Argument von viw: Wenn wir es schaffen sollten, TMC-Rohdaten von anderen Ländern zu erwerben mit der Möglichkeit sie "in nicht mehr roher Form" einzupflegen (meinetwegen über eine Spende oder was auch immer), könnten wir die aufgearbeiteten Daten als Teil der OSM-Karte auch FOSS-Routing-Projekten anbieten, die sich die Rohdaten selbst nicht leisten können. Als wenn das kein signifikanter Nutzen wäre...

woodpeck wrote:

Selbst wenn bei uns alles ok ist, so kaemen doch neue Listen von der BASt, an die wir unsere Daten regelmaessig anpassen muessten (und das, obwohl sich in der realen Welt gar nichts aendert - auch komisch, oder).

Das Update lässt sich hervorragend automatisieren - >95% aller Punkte ändern sich nicht, die anderen Änderungen sind klein (neue Segmente, neue Punkte) und lassen sich in eine einfache ToDo-Liste umsetzen. Buslinien sind um Größenordnungen schwerer instandzuhalten, und da beschwert sich niemand, dass die nicht in OSM gehören würden!

woodpeck wrote:

Und es wuerde die Arbeit unbeteiligter Mapper an anderen Dingen beeintraechtigen (weil die sich damit auseinandersetzen muessten, was das seltsame TMC-Tag da jetzt soll).

Das trifft auf jedes beliebige andere Tag auch zu. Wie steht es mit den 3D-Attributen für Gebäude? Das ist ein noch viel größeres Gemenge an unterschiedlichen Dingen, und viele haben Werte die man ohne Nachschlagen nicht interpretieren kann.

MHohmann wrote:

So weit ich das bisher sehen kann, ändern sich bei einem solchen Update nicht auf einen Schlag alle Location Codes, sondern es gibt graduelle Änderungen.

Ja, insbesondere: Ein einmal vergebener Code wird auf keinen Fall neu an anderer Stelle vergeben! Alte Daten sind also höchstens ungenau, aber in keinem Fall komplett falsch.

mueschel wrote:

Ich habe hier einen Vorschlag zum Thema mapping von Punkt-Lokationen (meistens Kreuzungen). Hier ist eine Kreuzung, die zwei TMC Koordinaten hat:
http://www.openstreetmap.org/node/32906938

Dieser Knoten sowie der zweite Zentrale Kreuzungsknoten dieser Kreuzung sind Teil von zwei Relationen, die jeweils alle Infos zu diesem TMC-Punkt enthalten.
Leider zeigt osm.org/browse nicht den Typ der Relation an, aber das kann sich ja noch ändern.

Damit sind zwei zentrale Kritikpunkte hoffentlich behoben: Tag-Chaos an Punkten und Wegen sowie der Problemfall mehrerer überlagernder Punkte.
Was haltet ihr von dieser möglichen Lösung?

Grundsätzlich gefällt mir, dass man auf diese Weise TMC-Locations in Form von OSM-Objekten abbilden kann, in diesem Fall also als eine Relation. Allerdings sehe ich das Schema etwas problematisch im Hinblick auf zukünftige Bearbeitungen an dieser Kreuzung. Angenommen, jemand teilt die B 521 und L 3209 gemäß einer baulichen Trennung in je zwei Wege auf*. Dann kommen zwei weitere Kreuzungspunkte hinzu. Jemand, der das TMC-Tagging nicht kennt, wird die aber nicht zur TMC-Relation hinzufügen, wie es eigentlich dem korrekten Tagging entsprechen würde. Vielleicht löscht er auch Punkte oder ersetzt sie. Damit würde so ein (ziemlich wahrscheinlicher) Edit das TMC-Tagging aus der Bahn werfen, z.B. weil man die TMC-Punkte dann nur noch auf einer von zwei Richtungsfahrbahnen findet und es so aussieht, als würde man sie in der anderen Richtung gar nicht passieren. So ein Fehler dürfte auch schwer automatisiert zu finden sein, denn wenn man nur prüft, ob eine TMC-Relation an der richtigen Stelle vorhanden ist, findet man ja eine solche - sie ist aber nicht vollständig.

• Nehmen wir mal hypothetisch an, die Kreuzung würde genau so umgebaut werden.
  

MHohmann wrote:

Grundsätzlich gefällt mir, dass man auf diese Weise TMC-Locations in Form von OSM-Objekten abbilden kann, in diesem Fall also als eine Relation. Allerdings sehe ich das Schema etwas problematisch im Hinblick auf zukünftige Bearbeitungen an dieser Kreuzung. Angenommen, jemand teilt die B 521 und L 3209 gemäß einer baulichen Trennung in je zwei Wege auf*. Dann kommen zwei weitere Kreuzungspunkte hinzu. Jemand, der das TMC-Tagging nicht kennt, wird die aber nicht zur TMC-Relation hinzufügen, wie es eigentlich dem korrekten Tagging entsprechen würde. Vielleicht löscht er auch Punkte oder ersetzt sie. Damit würde so ein (ziemlich wahrscheinlicher) Edit das TMC-Tagging aus der Bahn werfen, z.B. weil man die TMC-Punkte dann nur noch auf einer von zwei Richtungsfahrbahnen findet und es so aussieht, als würde man sie in der anderen Richtung gar nicht passieren. So ein Fehler dürfte auch schwer automatisiert zu finden sein, denn wenn man nur prüft, ob eine TMC-Relation an der richtigen Stelle vorhanden ist, findet man ja eine solche - sie ist aber nicht vollständig.

Also ich würde sagen so ein Locationcode ist keine einmalige Sache. Denn sonst würde man in Berlin beispielsweise ein Problem bekommen. http://www.openstreetmap.org/#map=18/52.56736/13.47575
Der Locationcode teilt die B2 in Höhe der Brücke und eigentlich auch gleichzeitig die Darßerstraße. Das kann aber kein gemeinsamer Punkt auf beiden Straßen sein.

Dann muss es in jede Richtung ein TMC Segment geben. Dies kann man sehrwohl automatisch validieren, indem man schaut ob die relation vom richtigen Start- zum Endpunkt geht und geschlossen ist.

Oder habe ich da etwas falsch verstanden?

viw wrote:

Also ich würde sagen so ein Locationcode ist keine einmalige Sache. Denn sonst würde man in Berlin beispielsweise ein Problem bekommen. http://www.openstreetmap.org/#map=18/52.56736/13.47575
Der Locationcode teilt die B2 in Höhe der Brücke und eigentlich auch gleichzeitig die Darßerstraße. Das kann aber kein gemeinsamer Punkt auf beiden Straßen sein.

Ja, völlig richtig. Genau deshalb hat diese Kreuzung / Straßenverbindung zwei TMC-Locations, einmal 21558 entlang der B 2 und einmal 26858 entlang der L 1193 / Darßer Straße. Jedem TMC-Punkt ist eindeutig eine Straße bzw. ein Straßensegment zugeordnet, und wenn sich zwei Straßen kreuzen, die beide TMC-Codes haben, dann hat deren Kreuzung (mindestens) zwei Location Codes. So auch im Beispiel von mueschel (wobei es dort ja sogar gemeinsame Punkte auf beiden Straßen gibt).

Dann muss es in jede Richtung ein TMC Segment geben. Dies kann man sehrwohl automatisch validieren, indem man schaut ob die relation vom richtigen Start- zum Endpunkt geht und geschlossen ist.

Ja, das sollte im Prinzip gehen. Das wäre ja letztlich das gleiche Vorgehen wie bei einer Busroute, einmal in Vorwärtsrichtung und einmal in Rückwärtsrichtung.

Apropos, in den TMC-LCLs hat jeder Punkt außerdem eine Information darüber, ob man die zugehörige Straße an dieser Stelle in positiver bzw. negativer Richtung befahren bzw. verlassen kann. Das kann man also durchaus auch validieren - führt eine Straße dorthin bzw. weg, die eine Verbindung zum nächsten Knoten darstellt?

Damit ziehe ich meinen Einwand aus dem letzten Post zurück, was eine automatische Validierung angeht. Allerdings würde ich das Tagging ein wenig modifizieren. Ich würde es so machen, dass beim kompletten Durchfahren einer TMC-Route jeder TMC-Punkt, der zu dieser Route gehört, genau einmal in Form eines Nodes auf der Strecke durchfahren wird. Beim Beispiel von mueschel werden beim Durchfahren der B 521 von Westen nach Norden aber zwei Nodes durchfahren, die Mitglied der gleichen TMC-Relation sind, wobei diese Relation Teil der TMC-Route auf der B 521 ist. Stattdessen würde ich lieber nur einen Node (in diesem Fall http://www.openstreetmap.org/node/32906938) aufnehmen, da dieser immer durchfahren wird, egal in welcher Richtung. Wenn es an einer Kreuzung getrennte Richtungfahrbahnen gibt, braucht es dann genau zwei Nodes, einen pro Richtung, meinetwegen mit Rollen forward und backward o.ä. in der Relation, ähnlich wie z.B. bei Bushaltestellen.

MHohmann wrote:

Damit ziehe ich meinen Einwand aus dem letzten Post zurück, was eine automatische Validierung angeht. Allerdings würde ich das Tagging ein wenig modifizieren. Ich würde es so machen, dass beim kompletten Durchfahren einer TMC-Route jeder TMC-Punkt, der zu dieser Route gehört, genau einmal in Form eines Nodes auf der Strecke durchfahren wird. Beim Beispiel von mueschel werden beim Durchfahren der B 521 von Westen nach Norden aber zwei Nodes durchfahren, die Mitglied der gleichen TMC-Relation sind, wobei diese Relation Teil der TMC-Route auf der B 521 ist. Stattdessen würde ich lieber nur einen Node (in diesem Fall http://www.openstreetmap.org/node/32906938) aufnehmen, da dieser immer durchfahren wird, egal in welcher Richtung. Wenn es an einer Kreuzung getrennte Richtungfahrbahnen gibt, braucht es dann genau zwei Nodes, einen pro Richtung, meinetwegen mit Rollen forward und backward o.ä. in der Relation, ähnlich wie z.B. bei Bushaltestellen.

Das ganze verstehe ich noch nicht. Was machst du denn bei einer richtungsgetrennten Fahrbahn welche von einer Landstraße ohne Trennung der Richtung gekreutz wird? Dann hast du auch zwei Knoten wegen der getrennten Straße. Aber durchfährst entweder zwei Punkte bei der nicht getrennten Straße oder es bleibt ein Stück frei.
Und was machst du wenn sich zwei Straßen mit getrennten Fahrbahnen treffen? Vielleicht sollte man das mal grafisch im Wiki verewigen.
Aber es sollte doch eigentlich über ein neues tagging nachgedacht werden statt das alte zu modifizieren?
Ich finde es schade das die Nutzer sich bisher nicht gemeldet haben. Insbesondere BR und SWR wären von Vorteil.

viw wrote:

Das ganze verstehe ich noch nicht. Was machst du denn bei einer richtungsgetrennten Fahrbahn welche von einer Landstraße ohne Trennung der Richtung gekreutz wird? Dann hast du auch zwei Knoten wegen der getrennten Straße. Aber durchfährst entweder zwei Punkte bei der nicht getrennten Straße oder es bleibt ein Stück frei.

Also, wie oben beschrieben gehört zu einer TMC-Punkt-Location immer eindeutig eine TMC-Route. Nehmen wir an, in diesem Beispiel sind beide kreuzenden Straßen A (getrennt) und B (nicht getrennt) TMC-Routen. Dann hat die Kreuzung zwei verschiedene Location Codes, 1 mit Referenz auf A und 2 mit Referenz auf B.

In diesem Fall würde ich es dann so machen, dass ich 1 auf die beiden Kreuzungsnodes tagge. Wenn ich nun entlang von Straße A fahre, durchfahre ich immer genau einen dieser beiden Knoten. Was beim Durchfahren von Straße B und diesen beiden Nodes passiert, ist egal, da 1 nicht zu B gehört. Dagegen würde ich 2 auf einem Node in der Mitte der Kreuzung taggen, zwischen den beiden Kreuzungsnodes. Dieser Node wird dann genau einmal durchfahren, wenn man Straße B entlang fährt. Auch hier ist wieder egal, was beim Durchfahren von Straße A passiert, weil 2 nicht zu A gehört.

Auf diese Weise kann man die beiden Fahrbahnen von A jeweils so in zwei Teilstücke unterteilen, dass jeweils eines davon auf jeder Seite von Location 1 liegt. Ebenso kann man Straße B nun an Location 2 in zwei Teile aufteilen.

Und was machst du wenn sich zwei Straßen mit getrennten Fahrbahnen treffen?

In dem Fall würde ich die Nodes immer genau zwischen zwei Kreuzungsnodes setzen. Location 1 wäre also an Nodes auf den beiden Richtungsfahrbahnen von A, die zwischen den beiden Richtungsfahrbahnen von B liegen.

Vielleicht sollte man das mal grafisch im Wiki verewigen.

Ja, gute Idee, ich werde das mal versuchen zu zeichnen.

Aber es sollte doch eigentlich über ein neues tagging nachgedacht werden statt das alte zu modifizieren?

Das denke ich auch. Das war auch nur eine Überlegung, mit welchen OSM-Objekten man generell eine TMC-Location assoziieren könnte. Ob man das nun besser als Relation taggt oder mittels eines TMC-Schlüssel an diesen Punkten wie im Proposal im Wiki ist eine andere Frage, da bin ich mir selbst noch nicht ganz sicher. Aber auf jeden Fall sollten die Tags, egal ob an Relation oder Node, einfacher sein als dieses cid_X:tabcd_Y-Gewirr, das kein Mensch versteht. tmc:point=*, tmc:road=*, tms:segment=* würde ich eher im Sinn haben.

Ich finde es schade das die Nutzer sich bisher nicht gemeldet haben. Insbesondere BR und SWR wären von Vorteil.

Sehe ich auch so, gerade von denen wäre es doch gut zu wissen, was gewünscht ist. Insofern kann ich zumindest als Navit-Entwickler und damit hoffentlich zukünftiger Nutzer ein wenig die Perspektive der Router einbringen.

Von der Sache her dürfte es abfragetechnisch (für Anwendungen, die TMC-Daten aus OSM verarbeiten) für TMC egal sein, ob die Relation type=road oder type=TMC ist. Da so oder so beides ausgewertet werden muß.

Ist die Master-Relation type=road und die Slave-Relation type=TMC wird entweder erst "type=road" ausgewertet um auf das das "type=TMC" - Segment zu kommen, oder beides wird eh gleichzeitig ausgewertet. Die für die Auswertung relevante Information hier steckt in dem Tag des LCL-Codes, der für den betreffenden Straßenabschitt in einer Relation mit type=TMC steckt.

Betrachtet man eine Master-Reation "type=road" mit den Slave-Relationen "type=TMC" so steckt der für die TMC-Meldung auszuwertende LCL-Code in der Slave-Relation type=TMC. Im LCL-Code in der Master-Relation steckt nur die gesamte betreffende Straße drin. Bei TMC-Master-Slave-Relationen hat man immer mehrere LCL-Codes: der erste für die gesamte Straße, der zweite für das jeweilige Segment. Hinzu kommen die LCK-Codes der Knotenpunkte.
Beachten muß man dabei auch, daß nicht zwingend eine Straße immer in Segmenten geteilt ist. In der o.g. Liste sind eine Reihe von Straßen drin, die nicht segmentiert sind, also nur einen LCL-Code haben (dann zuzüglich zweier Punkte: Start und Ende).

In der Auswertung braucht sowieso lediglich nur der LCL-Code abgefragt zu werden. Je nachdem, welche Nummer man hat, landet man am Startpunkt der Straße, am Code des Gesamtverlaufes der Straße, an einem ihrer Abschnitte oder einem ihrer Zwischenpunkte oder sonstwo...

Ich betrachte daher die saubere Trennung zwischen Straßen- und TMC- Relationen als unproblematisch, im Gegenteil, die dann entstehenden TMC-Relationen erfahren eine Überarbeitung, zu mindestens in Hinblick der Vollständigkeit der Elemente.

Sven

MHohmann wrote:

Ich würde es so machen, dass beim kompletten Durchfahren einer TMC-Route jeder TMC-Punkt, der zu dieser Route gehört, genau einmal in Form eines Nodes auf der Strecke durchfahren wird. Beim Beispiel von mueschel werden beim Durchfahren der B 521 von Westen nach Norden aber zwei Nodes durchfahren, die Mitglied der gleichen TMC-Relation sind, wobei diese Relation Teil der TMC-Route auf der B 521 ist. Stattdessen würde ich lieber nur einen Node (in diesem Fall http://www.openstreetmap.org/node/32906938) aufnehmen, da dieser immer durchfahren wird, egal in welcher Richtung

Überlegt hatte ich das, aber in komplexen Situationen sehe ich das als nicht ganz so brauchbar an. Ich denke aber, dass es kein Problem ist Knoten an einer komplexen Kreuzung "großzügig" mit in die TMC-Relation aufzunehmen, auch wenn dann mehrere Knoten befahren werden. TMC-Abschnitte von einem Knoten zum anderen sollten dann immer von letzten erreichten Knoten bei A zum ersten erreichten Knoten bei B gehen. Man sollte allerdings wohl noch den Übergang von einem Segment auf ein kreuzendes im Auge behalten - dafür müsste auch ein Knoten der Abbiegespur an "meiner" Kreuzung noch mit aufgenommen werden.

Das

mueschel wrote:

Überlegt hatte ich das, aber in komplexen Situationen sehe ich das als nicht ganz so brauchbar an. Ich denke aber, dass es kein Problem ist Knoten an einer komplexen Kreuzung "großzügig" mit in die TMC-Relation aufzunehmen, auch wenn dann mehrere Knoten befahren werden. TMC-Abschnitte von einem Knoten zum anderen sollten dann immer von letzten erreichten Knoten bei A zum ersten erreichten Knoten bei B gehen. Man sollte allerdings wohl noch den Übergang von einem Segment auf ein kreuzendes im Auge behalten - dafür müsste auch ein Knoten der Abbiegespur an "meiner" Kreuzung noch mit aufgenommen werden.

Das kann man durchaus machen, die Auswertung sollte auf jeden Fall kein Problem sein. Die Problematik sehe ich eher darin, so ein Tagging zu validieren, wenn jemand die Kreuzung bearbeitet hat. Woran erkennt man, dass alle aufzunehmenden Nodes in der Relation enthalten sind? Wenn es immer genau einen bzw. einen pro Richtung gibt, ist das eindeutig.

Aber du hast Recht, bei komplexeren Kreuzungen stellt sich natürlich die Frage, wo denn dieser eine Knoten sein soll. Genau so bei Autobahnausfahrten - bei der Ausfahrt, der Einfahrt oder dazwischen?

Schina02 wrote:

Ich kenne mich damit nicht aus. Aber ich denke es ist wichtig, dass das System auch abwärtskompatibel ist. Und am besten wird es natürlich auch sein, je mehr Systeme unterstützt werden. So wie es scheint ist TMC rein passiv und funktioniert durch UKW. Funktioniert das dann auch wenn man ein TPEG-fähiges Gerät hat bzw. funktioniert TPEG auch wenn TMC nicht mehr in OSM ist auf einem alten Gerät?

TPEG ist nur ein Container, es kommt darauf an was man hineinpackt. In TPEG kann man auch TMC Loc-Referenzierungen angeben. Das tut man auch gerne weil diese schön kurz sind und alle Navis TMC verstehen. Siehe TPEG-TEC
Im übrigen steht im TPEG exakt das drinn was auch in TMC drinn steht, was sonst?

Was ich gerade sehe: TPEG soll auch für den öffentlichen Personenverkehr gemacht werden/sein. Heißt das, dass dies eine Art Fahrplanauskunft ist und ÖPNV-Routing ohne weitere Daten ermöglicht?

Nein. TPEG ist ein Container wo man im Header sagen kann was kommt. So hat man für die ÖPNV ein Container gemacht, der allerdings gefüllt werden soll. Ganze Fahrpläne zu broadcasten wäre hirnrissig, es reicht die Verspätungen und aktuelle An- und Abfahrten in 20-30 Minuten Umkreis. Idee dabei war die Locationlisten zu verbinden - also Parkhaus zu Bahnsteig, und so den Reisenden durchzunavigieren.

Ich habe mal die frei verfügbaren Location Code Tabellen von Deutschland, Italien, Schweden und Norwegen in eine Datenbank geladen und ein paar Abfragen dazu erstellt. Das ganze ist sicher weder perfekt noch komplett, aber zumindest die Straßen werden schon einmal auf Wunsch angezeigt, zusammen mit den dazugehörigen Wegpunkten. Hier ist die Startseite:

http://manuelhohmann.dyndns.org/osm/TMC.html

Die Daten gibt es als einfache Kartenansicht oder auch gleich zum Download als GPX. Wenn jemand einen Fehler finden sollte oder etwas nicht funktioniert, oder sich jemand ein Feature wünscht, einfach bei mir melden, dann schaue ich, was ich machen kann.

MHohmann wrote:

Ich habe mal die frei verfügbaren Location Code Tabellen von Deutschland, Italien, Schweden und Norwegen in eine Datenbank geladen und ein paar Abfragen dazu erstellt. Das ganze ist sicher weder perfekt noch komplett, aber zumindest die Straßen werden schon einmal auf Wunsch angezeigt, zusammen mit den dazugehörigen Wegpunkten. Hier ist die Startseite:

http://manuelhohmann.dyndns.org/osm/TMC.html

Die Daten gibt es als einfache Kartenansicht oder auch gleich zum Download als GPX. Wenn jemand einen Fehler finden sollte oder etwas nicht funktioniert, oder sich jemand ein Feature wünscht, einfach bei mir melden, dann schaue ich, was ich machen kann.

Na dann wollen wir mal Wünsche wünschen. Wie wäre es das ganze als WMS zur Einbindung in JOSM?

Also ich könnte mir vorstellen in meinem Bereich wenigstens die Locationcodes anzulegen. Dann sollten wir aber noch darüber sprechen nach welchem Schema das am besten geschehen sollte.

MHohmann wrote:

Wenn jemand einen Fehler finden sollte oder etwas nicht funktioniert, oder sich jemand ein Feature wünscht, einfach bei mir melden, dann schaue ich, was ich machen kann.

erst mal Danke für die Arbeit.

Wir sollten aber bei den Daten durchaus vorsichtig sein.

Ich hab mit mal die B 87 angeschaut. Die wird im TMC an einigen Stellen noch auf ihrer Altstrecke geführt: z.B. zwischen Lützen und Weißenfels. Die TMC-Daten gehen hier über einen Abschnitt, der offensichtlich schon als Landesstraße heruntergestuft wurde, nur im TMC noch nicht. Auch in Thüringen gibt es an zwei Stellen solche Diskrepanzen.

stellt Sven fest

viw wrote:

Na dann wollen wir mal Wünsche wünschen. Wie wäre es das ganze als WMS zur Einbindung in JOSM?

Puh, das klingt nach "viel" Arbeit - wenn ich das richtig sehe, müsste ich dafür Tiles rendern und einen Tileserver aufsetzen... Das geht derzeit ein wenig über meine Fähigkeiten, da müsste ich mich erst einmal einarbeiten, und das kann eine Weile dauern. Für die Arbeit mit JOSM habe ich die GPX-Dateien gebastelt, aber du hast natürlich Recht, da sieht man so zunächst nur eine Straße und nicht, was sonst noch so vorhanden ist. Ich werde mal versuchen, größere Daten nach Land / Bundesland zu bauen, damit man mehr Übersicht hat.

Also ich könnte mir vorstellen in meinem Bereich wenigstens die Locationcodes anzulegen. Dann sollten wir aber noch darüber sprechen nach welchem Schema das am besten geschehen sollte.

Sehe ich auch so. Ich werde mal Skizzen zu dem obigen Taggingvorschlägen basteln.

streckenkundler wrote:

Wir sollten aber bei den Daten durchaus vorsichtig sein.

Ich hab mit mal die B 87 angeschaut. Die wird im TMC an einigen Stellen noch auf ihrer Altstrecke geführt: z.B. zwischen Lützen und Weißenfels. Die TMC-Daten gehen hier über einen Abschnitt, der offensichtlich schon als Landesstraße heruntergestuft wurde, nur im TMC noch nicht. Auch in Thüringen gibt es an zwei Stellen solche Diskrepanzen.

Ja, sehe ich auch so. Das ist mir bei der B 5 auch aufgefallen. Allerdings frage ich mich, wenn das die Version 12.0 ist und derzeit auch von den TMC-Sendern Version 12.0 ausgestrahlt wird, ob die Meldungen sich dann tatsächlich auf den alten Streckenverlauf beziehen. IMHO müssten sie das, da es ja keine neuere Location Code Tabelle gibt, in der der neue Verlauf eingetragen ist.

MHohmann wrote:

viw wrote:

Na dann wollen wir mal Wünsche wünschen. Wie wäre es das ganze als WMS zur Einbindung in JOSM?

Puh, das klingt nach "viel" Arbeit - wenn ich das richtig sehe, müsste ich dafür Tiles rendern und einen Tileserver aufsetzen... Das geht derzeit ein wenig über meine Fähigkeiten, da müsste ich mich erst einmal einarbeiten, und das kann eine Weile dauern. Für die Arbeit mit JOSM habe ich die GPX-Dateien gebastelt, aber du hast natürlich Recht, da sieht man so zunächst nur eine Straße und nicht, was sonst noch so vorhanden ist. Ich werde mal versuchen, größere Daten nach Land / Bundesland zu bauen, damit man mehr Übersicht hat.

Nein Tiles muss man dafür gerade nicht rendern. Das muss man nur wenn man einen TMS anbieten möchte.
Ich weiß ja nicht was du im Hintergrund zu laufen hast:
http://wiki.openstreetmap.org/wiki/User … /Mapserver
http://wiki.openstreetmap.org/wiki/User … /Geoserver
Bei beiden Servern kann man eine Postgisdatenbank als Layer einbinden. Auch Shapefiles sind kein Problem.

Das Problem mit den GPX Daten ist, dass ich die betreffenden Orts-Straßen nicht finden konnte:
http://osm-tmc.infoware.de/tmc/?view=tm … h_tmc_tags
Zum Beispiel die Darßer Straße. Die Locationnodes hattest du aber zum Beispiel für den Wartenberger Weg auch in deiner Datenbank.

viw wrote:

Nein Tiles muss man dafür gerade nicht rendern. Das muss man nur wenn man einen TMS anbieten möchte.

Ah, verstehe.

Ich weiß ja nicht was du im Hintergrund zu laufen hast:
http://wiki.openstreetmap.org/wiki/User … /Mapserver
http://wiki.openstreetmap.org/wiki/User … /Geoserver
Bei beiden Servern kann man eine Postgisdatenbank als Layer einbinden. Auch Shapefiles sind kein Problem.

Derzeit nichts dergleichen, nicht einmal PostGIS - auf meinem Server habe ich nur eine ganz simple MySQL-Datenbank, in die ich direkt die Tabellen so geladen habe, wie sie von den jeweiligen Ländern angeboten werden. Daraus sucht mein Skript dann zusammen, was für eine GPX-Datei nötig ist.

Das Problem mit den GPX Daten ist, dass ich die betreffenden Orts-Straßen nicht finden konnte:
http://osm-tmc.infoware.de/tmc/?view=tm … h_tmc_tags
Zum Beispiel die Darßer Straße. Die Locationnodes hattest du aber zum Beispiel für den Wartenberger Weg auch in deiner Datenbank.

Ja, stimmt. Derzeit zeigt meine Liste nur komplette Straßen an, in diesem Fall ist das die L 1139, die aber nicht auf der ganzen Strecke diesen Namen hat. Deshalb taucht der auch nicht in der Liste auf, sondern nur am Node als rnid (road name id). Ich werde dazu später mal eine Suchfunktion für Namen basteln und die Anzeige etwas strukturieren, damit man auch Segmente und Punkte auflisten kann, ohne gleich die komplette DB runterladen zu müssen. Derzeit kann man Punkte nur finden, indem man ihren Location Code von Hand in den Link eingibt.

Was natürlich auch praktisch wäre: statt Werten wie pol_lcd die entsprechenden OSM-Tags auszugeben. Aber nur, wenn ich mir was wünschen darf 😉

Nadjita wrote:

Was natürlich auch praktisch wäre: statt Werten wie pol_lcd die entsprechenden OSM-Tags auszugeben. Aber nur, wenn ich mir was wünschen darf 😉

Das kann ich gerne einbauen, sobald wir ein modernisiertes Tagging-Schema haben 😉 Mit dem derzeitgen Tag-Gewusel kommt man ja kaum zurecht.

MHohmann wrote:

Nadjita wrote:

Was natürlich auch praktisch wäre: statt Werten wie pol_lcd die entsprechenden OSM-Tags auszugeben. Aber nur, wenn ich mir was wünschen darf 😉

Das kann ich gerne einbauen, sobald wir ein modernisiertes Tagging-Schema haben 😉 Mit dem derzeitgen Tag-Gewusel kommt man ja kaum zurecht.

Naja ähm wenn wir dann schon soweit wären, könnte man vielleicht auch gleich ein Matching auf die OSM-Daten vorberteiten. Knoten suchen der in der Nähe liegt und Bestandteil der Straßen ist. Falls unzutreffend frei lassen und die Ganze Sache natürlich bearbeitbar. ;-) Also quasie ein Editor für TMC, welcher aber in einer externen Datenbank funktioniert und so einen sauberen Import ermöglichen würde. Bzw. das von woodpeck angesprochene externe Matching verbessert/ermöglicht/vereinfacht.

viw wrote:

Naja ähm wenn wir dann schon soweit wären, könnte man vielleicht auch gleich ein Matching auf die OSM-Daten vorberteiten. Knoten suchen der in der Nähe liegt und Bestandteil der Straßen ist. Falls unzutreffend frei lassen und die Ganze Sache natürlich bearbeitbar. ;-) Also quasie ein Editor für TMC, welcher aber in einer externen Datenbank funktioniert und so einen sauberen Import ermöglichen würde. Bzw. das von woodpeck angesprochene externe Matching verbessert/ermöglicht/vereinfacht.

Also das ist schon wieder eine ganz andere Größenordnung... Daten aus einer DB grafisch auf einer Karte darzustellen ist eine Sache. Aber das mit Daten aus einer zweiten Datenbank zu verknüpfen, mittels "unscharfer" Suche Koordinaten von Punkten "in der Nähe" finden und dann auch noch wissen, welches die richtige Straße ist (ebenfalls eine "unscharfe" Suche), ist dann doch um Längen schwieriger. Vor allem bei komplexeren Kreuzungen dürfte das schwierig werden. Ich kann mal schauen, ob mir dazu etwas einfällt, vielleicht hat auch jemand anders eine Idee, aber versprechen kann ich da nichts.

Das ist ja genau der Grund, weshalb ich dafür plädiere, die Daten in OSM aufzunehmen. Wenn sie einmal getaggt sind, ist es extrem einfach, die zugehörigen OSM-Objekte zu finden, indem man die getaggten Location Codes sucht. Wenn die Daten extern sind, braucht es eben dieses Matching, und das ist deutlich komplexer.

MHohmann wrote:

Also das ist schon wieder eine ganz andere Größenordnung... Daten aus einer DB grafisch auf einer Karte darzustellen ist eine Sache. Aber das mit Daten aus einer zweiten Datenbank zu verknüpfen, mittels "unscharfer" Suche Koordinaten von Punkten "in der Nähe" finden und dann auch noch wissen, welches die richtige Straße ist (ebenfalls eine "unscharfe" Suche), ist dann doch um Längen schwieriger. Vor allem bei komplexeren Kreuzungen dürfte das schwierig werden. I

Hi Hi ;-) Als geeigneten Testkandidaten hätte ich 37183 im Angebot. Der Knoten besteht nämlich logisch gesehen aus zwei T-Kreuzungen, die einen Kilometer auseinanderliegen.

Na das kann ja lustig werden 😉 Als schöne Testfälle fallen mir noch 46170, 35762, 26227, 35625, 24042 und 46263 ein - alle bis auf den ersten liegen ziemlich dicht beisammen:

http://osm-tmc.infoware.de/tmc/?view=tm … h_tmc_tags

Man beachte auch das derzeitige Tagging in blau... Bei solchen Fällen müsste man sich erst einmal überlegen, welche Nodes man überhaupt wie taggt bzw. in eine TMC-Relation einbaut. Bei den beiden getrennten T-Kreuzungen bzw. Einmündungen ist das ja noch relativ klar (einer ist sozusagen der Anfang der Kreuzung, der andere das Ende - es sind ja zwei Punkte, also fast so als ob die Straße hier zwei weitere Straßen schneiden würde - nur dass eben dazwischen kein Verbindungsstück sitzt, das zur gleichen Straße gehört).

MHohmann wrote:

Bei solchen Fällen müsste man sich erst einmal überlegen, welche Nodes man überhaupt wie taggt bzw. in eine TMC-Relation einbaut. Bei den beiden getrennten T-Kreuzungen bzw. Einmündungen ist das ja noch relativ klar (einer ist sozusagen der Anfang der Kreuzung, der andere das Ende - es sind ja zwei Punkte, also fast so als ob die Straße hier zwei weitere Straßen schneiden würde - nur dass eben dazwischen kein Verbindungsstück sitzt, das zur gleichen Straße gehört).

Die Masse dürfte alles in der LCL-Tabelle des BaSt drinne stehen.
Betrachten Wir die Linien-Datensätze. Hier greife ich wieder auf die mir recht gut bekannte B 87 zu.

Es gibt 2 Datentypen: L1 und L3

L1 mit LCL 50449 beschreibt den Gesamtverlauf
L3 beschreibt die Segmente. Hier ergibt sich die Zugehörigkeit aus der Spalte "LINEAR_REFERENCE" = 50449, also B 87.
Jedes einzelne Segment hat wiederum seinen eigenen LCL. In den Spalten "positive" steht der LCL-Code des folgenden, in der Spalte "negative" der LCL-Code des vorherigen Anschnittes.

Ahnlich verhält es sich mit den Punkten P1 und P3 Wichtig für Straßen sind zunächst Punkte des Type P1 (Kreuzungen, ect.) Auch hier die Punktfolge aus LCL-Code, der Angabe in Positive und Angabe in negative. Aus den Spalten Type und Subtype ergubt sich die Kreuzungsart des Punktes

Bei den Punkten sind die LCL-Codes in der Spalte "Intersectioncode" interessant: "Verweis auf Lokation (Loc_Id) einer anderen Straße an gleicher Stelle (zirkuläre Verkettung)". Hier wird anscheinend auf den LCL-Code der kreuzenden/ abgehenden/ einmündenden Straße verwiesen.

Auch interessant ist die Spalte "Interrupts_road". Hiewr wird jeweils der Punkt angegeben, zwischen denen die referenzierte Straße (=LCL-Code Spalte "Linear_Reference") unterbrochen ist.

Beachten sollte man die Spalte "ACTUALITY" Für die B 87 ist der Abschnitt Naumburg-Leipzig der 7.10.2011, für den Rest der Strecke der 25.7.2002. (Soviel zur Aktualität).

Segment-Beispiel B87

1. nach LCL
9049->43818->9050->9051->9052

2. nach First_name-second_name

Ilmenau-Naumburg-> Naumburg-Leipzig-> Leipzig-Torgau-> Torgau-Luckau-> Luckau-Frankfurt(Oder)

Aus den Angaben in den Spalten Negative und Positive geht die Reihung der Segmente bervorin dem der Folgende (Positive) und der vorhergehende (negative) LCL-Code des Gementes genannt wird.

Sinnvoll halte ich die Eingabe der Daten nur, wenn man konsequent die Segmente anwendet. Das wird aber für die Masse von uns nicht leistbar sein. Nur die Angabe des LCL-Codes für die gesamte Straße betrachte ich als vertane Arbeit.

Ob der Komplexität der LCL-Tabelle bin ich der Meinung, daß die dahintersteckende Struktur (die ich hier nur angerissen habe) nur in einer auf OSM aubbauenden Lösung am besten untergebracht ist, nicht in OSM selbst.
Ziemlich zu Denken gibt mir die Aktualität: 33190 von 46396 Datensätze der BaSt-Tabelle stammen von vor 2011... richtig bewerten kann ich das nicht.

Noch ein Wort zur Spalte "Admin_County". Eine Sortierung der Daten unterhalb der Bundesstraßen nach dieser Spalte wäre sehr schön.

Ich hoffe meine Zeilen nützen was...

Sven

streckenkundler wrote:

Die Masse dürfte alles in der LCL-Tabelle des BaSt drinne stehen.

...

Also die Datenstruktur war mir so weit schon klar. Trotzdem danke für die Zusammenfassung 🙂

Meine Frage war hier eher, wenn ich eine Kreuzung aus vielen OSM-Nodes habe, wie genau behandle ich diese? Auf welchen OSM-Nodes tagge ich die Punkt-Locations, wo genau enden die Segmente (auf welchem OSM-Node)? Das sehe ich aus den Daten noch nicht so ganz.

Beachten sollte man die Spalte "ACTUALITY" Für die B 87 ist der Abschnitt Naumburg-Leipzig der 7.10.2011, für den Rest der Strecke der 25.7.2002. (Soviel zur Aktualität).

Ziemlich zu Denken gibt mir die Aktualität: 33190 von 46396 Datensätze der BaSt-Tabelle stammen von vor 2011... richtig bewerten kann ich das nicht.

Naja, wenn sich eine Straße nicht verändert, muss man auch keine Daten ändern. Ich denke, das spricht eher dafür, dass der Aufwand zum aktuell halten der Daten gering ist, weil sie sich selten ändern.

Sinnvoll halte ich die Eingabe der Daten nur, wenn man konsequent die Segmente anwendet. Das wird aber für die Masse von uns nicht leistbar sein. Nur die Angabe des LCL-Codes für die gesamte Straße betrachte ich als vertane Arbeit.

Was genau meinst du damit? Warum sollte das nicht leistbar sein?

Ob der Komplexität der LCL-Tabelle bin ich der Meinung, daß die dahintersteckende Struktur (die ich hier nur angerissen habe) nur in einer auf OSM aubbauenden Lösung am besten untergebracht ist, nicht in OSM selbst.

So weit ich das sehe, gibt und gab es nicht die Absicht, die kompletten Tabellen in OSM abzubilden. Das halte ich auch nicht für sinnvoll. Für sinnvoll halte ich es dagegen, nur solche Informationen abzubilden, die einen direkten Ortsbezug haben. Das sind also insbesondere die Punkt-Locations, die jeweils eine Koordinate haben, sowie die Straßen bzw. Segmente, die mit OSM-Ways abgebildet werden können. Mehr nicht.

Noch ein Wort zur Spalte "Admin_County". Eine Sortierung der Daten unterhalb der Bundesstraßen nach dieser Spalte wäre sehr schön.

Gute Idee. Jetzt kann man unter Deutschland die Bundesländer auswählen und von dort weiter abwärts gehen. Es werden jeweils die dortigen Straßen aufgelistet.

viw wrote:

Das Problem mit den GPX Daten ist, dass ich die betreffenden Orts-Straßen nicht finden konnte:
http://osm-tmc.infoware.de/tmc/?view=tm … h_tmc_tags
Zum Beispiel die Darßer Straße. Die Locationnodes hattest du aber zum Beispiel für den Wartenberger Weg auch in deiner Datenbank.

Jetzt gibt es dafür eine Suchfunktion auf der Startseite - und die findet nun auch die Darßer Straße 🙂 Achtung, die Suche unterscheidet Groß- und Kleinschreibung und ist nicht "unscharf", sondern sucht nach Vorkommen des exakten Begriffs irgendwo im Namen (nicht Straßennummer).

MHohmann wrote:

Meine Frage war hier eher, wenn ich eine Kreuzung aus vielen OSM-Nodes habe, wie genau behandle ich diese? Auf welchen OSM-Nodes tagge ich die Punkt-Locations, wo genau enden die Segmente (auf welchem OSM-Node)? Das sehe ich aus den Daten noch nicht so ganz.

Na, ich hab mir das mal an der der B96 angeschaut... Grundsätzlicher Unterschied ist, daß bei den TMC-Daten ausschließlich Straßenachsenbezogen gearbeitet wird. Das heißt ich habe bei den TMC-Daten pro Straße nur eine Linie, egal ob ich eine bauliche Trennung in unterschiedliche Fahrspuren habe (Autobahnen) oder nicht.

Wenn du dir die LCL-Codes 18 und 19 anschaust: an einem Koordinatenpunkt (X-Y-Koordinaten) treffen sich zwei LCL-Codes von Punkten. Es können auch mehr sein(3 LCL-Codes hab ich auch schon gesehen)... Da wir bei OSM (sofern vorhanden) bauliche Trennung erfassen, lassen sich diese TMC-Punkte nicht so einfach setzen. Im Prinzip müssten das immer stur Punkte mit TMC-Tag in der Mitte der jeweiligen Kreuzung sein. Daran lassen sich aber nicht die Straßen anbinden. Ich sehe da grundsätzliche Unterschiede in den Methodiken: TMC rein Straßenachsen-basierend, ohne Rücksicht auf bauliche Trennung -- OSM: berücksichtigt Kreuzungen, Kreisverkehre, bauliche Trennungen von Fahrspuren.

Für TMC in OSM müsste man eigentlich eine Daten-Ebene aus dem Straßennetz generieren, die sämtliche bauliche Trennungen verwirft und pro Straße (auch wenn sie getrennte Fahrspuren hat) nur eine Straßenache hat... Hm...

MHohmann wrote:

Naja, wenn sich eine Straße nicht verändert, muss man auch keine Daten ändern. Ich denke, das spricht eher dafür, dass der Aufwand zum aktuell halten der Daten gering ist, weil sie sich selten ändern.

...oder eben auch dafür, daß die TMC-Daten in ungenügender Weise den realen Straßenwidmungen angepasst werden, und somit weiter veraltern.

MHohmann wrote:

streckenkundler wrote:

Sinnvoll halte ich die Eingabe der Daten nur, wenn man konsequent die Segmente anwendet. Das wird aber für die Masse von uns nicht leistbar sein. Nur die Angabe des LCL-Codes für die gesamte Straße betrachte ich als vertane Arbeit.

Was genau meinst du damit? Warum sollte das nicht leistbar sein?

Nun, die derzeit gültige Tabelle hat 46395 Datensätze: 5180 Straßen sowie deren Segmente. Ich denke mal die LCL-Codes der Segmente (und deren Zwischenpunkte?) ist das wichtige an der Geschichte und nicht die der gesamten Straße. Schließlich soll und kann darüber ein betreffender Abschnitt recht genau idetifiziert werden, und das klappt nur, wenn Segmente (Type L3 und Punkte (Type P1) eingepflegt sind (=26391 Datensätze).

Sven... unsicher seihend

streckenkundler wrote:

Na, ich hab mir das mal an der der B96 angeschaut... Grundsätzlicher Unterschied ist, daß bei den TMC-Daten ausschließlich Straßenachsenbezogen gearbeitet wird. Das heißt ich habe bei den TMC-Daten pro Straße nur eine Linie, egal ob ich eine bauliche Trennung in unterschiedliche Fahrspuren habe (Autobahnen) oder nicht.

Ja, richtig.

Für TMC in OSM müsste man eigentlich eine Daten-Ebene aus dem Straßennetz generieren, die sämtliche bauliche Trennungen verwirft und pro Straße (auch wenn sie getrennte Fahrspuren hat) nur eine Straßenache hat... Hm...

Oder einem TMC-Punkt entspricht eine Gruppe von sagen wir mal 4 (nicht unbedingt verschiedenen) OSM-Nodes: Für jede Fahrtrichtung ein Anfang und Ende des Kreuzungsbereiches (d.h. erster + letzter abzweigender OSM-Way). Bei kompletter baulicher Trennung sind die dann alle verschieden, bei Kreisverkehren hat man einen pro Ausfahrt, ohne bauliche Trennung ist es nur ein Node an der Kreuzung der Straßen. Dann weiß man genau, wo ein OSM-Way-Teilstück zwischen zwei TMC-Locations anfängt und aufhört.

...oder eben auch dafür, daß die TMC-Daten in ungenügender Weise den realen Straßenwidmungen angepasst werden, und somit weiter veraltern.

In dem Zusammenhang frage ich mich, worauf sich denn dann die TMC-Meldungen im Rundfunk beziehen. Wenn die weiterhin die aktuell gültige (also nach deiner Aussage veraltete) Tabelle benutzen, sind sie ja im Einklang mit den Daten in der Tabelle - und nicht mit den neuen Widmungen der Straßen. Diesen Zusammenhang halte ich für wichtig.

Nun, die derzeit gültige Tabelle hat 46395 Datensätze: 5180 Straßen sowie deren Segmente. Ich denke mal die LCL-Codes der Segmente (und deren Zwischenpunkte?) ist das wichtige an der Geschichte und nicht die der gesamten Straße. Schließlich soll und kann darüber ein betreffender Abschnitt recht genau idetifiziert werden, und das klappt nur, wenn Segmente (Type L3 und Punkte (Type P1) eingepflegt sind (=26391 Datensätze).

Ja, stimmt schon, das sind eine Menge Daten - aber wenn man bedenkt, wie viel mehr schon gemappt wurde...

streckenkundler wrote:

Für TMC in OSM müsste man eigentlich eine Daten-Ebene aus dem Straßennetz generieren, die sämtliche bauliche Trennungen verwirft und pro Straße (auch wenn sie getrennte Fahrspuren hat) nur eine Straßenache hat... Hm...

Oder man müsste zu diesem Punkt bzw. dessen Koordinate die jeweils passende Straße in der korrekten Richtung zu finden - war da nicht was am Anfang dieser Diskussion?

Gruß
walter

streckenkundler wrote:

Für TMC in OSM müsste man eigentlich eine Daten-Ebene aus dem Straßennetz generieren, die sämtliche bauliche Trennungen verwirft und pro Straße (auch wenn sie getrennte Fahrspuren hat) nur eine Straßenache hat... Hm...

Warum das? TMC kennt sehr wohl Richtungen und auch Objekte die es nur in einer Fahrtrichtung gibt. Wenn es z.B. eine Ausfahrt an einer Autobahn nur in einer Fahrtrichtung gibt, ist das in den Daten enthalten.

MHohmann wrote:

Oder einem TMC-Punkt entspricht eine Gruppe von sagen wir mal 4 (nicht unbedingt verschiedenen) OSM-Nodes: Für jede Fahrtrichtung ein Anfang und Ende des Kreuzungsbereiches (d.h. erster + letzter abzweigender OSM-Way). Bei kompletter baulicher Trennung sind die dann alle verschieden, bei Kreisverkehren hat man einen pro Ausfahrt, ohne bauliche Trennung ist es nur ein Node an der Kreuzung der Straßen. Dann weiß man genau, wo ein OSM-Way-Teilstück zwischen zwei TMC-Locations anfängt und aufhört.

Das finde ich gut.

Mir ist gerade noch ein Problem mit den TMC-Segmenten aufgefallen: Längere Straßen sind in Segmente aufgeteilt, und zwar so, dass jeder TMC-Punkt eindeutig zu einem Segment gehört. Ein Segment endet also an einem Punkt, das nächste Segment fängt aber erst am nächsten an. Ein Beispiel:

Die A 39 (50108) besteht aus den 3 Segmenten 7091 (Salzgitter - Braunschweig), 7092 (Braunschweig - Wolfsburg) und 7058 (Lüneburg - Hamburg). Letzteres ist nicht mit den beiden ersten verbunden, hier reicht das Segment von Anfang bis Ende der jeweiligen Streckenführung. Anders ist es bei den beiden ersten Segmenten: Ersteres geht bis 11064 (Braunschweig-Süd), zweiteres fängt aber erst bei 13278 (Heidbergtunnel) an. Die Strecke zwischen diesen beiden Punkten gehört damit also keinen der beiden Segmente an. Trotzdem gehört sie natürlich zur A 39 und damit der Straße 50108.

Für das Tagging würde ich daher schlussfolgern, dass die TMC-Segmente nicht mit OSM-Wegen abgebildet werden sollten, weil es Wegstücke gibt, die zu keinem Segment gehören. Stattdessen sollten TMC-Segmente besser mit TMC-Punkten verknüpft werden, die wie weiter oben gepostet mit OSM-Nodes verbunden werden könnten.

Die OSM-Ways würden sich also bestenfalls zur Abbildung von TMC-Links eignen, d.h. Verbindungen zwischen zwei benachbarten TMC-Punkten, wie im Proposal beschrieben. Ob man das aber nun wie dort mit Tags macht oder mit Routen-Relationen ist eine andere Frage...

Das sind jetzt nur nächtliche Ideen, kein Tagging-Entwurf, aber zumindest könnte es irgendwie in diese Richtung gehen 😉

MHohmann wrote:

Jetzt gibt es dafür eine Suchfunktion auf der Startseite - und die findet nun auch die Darßer Straße 🙂 Achtung, die Suche unterscheidet Groß- und Kleinschreibung und ist nicht "unscharf", sondern sucht nach Vorkommen des exakten Begriffs irgendwo im Namen (nicht Straßennummer).

Die Suchfunktion bringt tatsächlich 4 Treffer. Aber das sind nur einzelne Punkte. Mhhh.

Hier habe ich noch etwas interessantes gefunden:
http://manuelhohmann.dyndns.org/osm/tmc … &lcd=57868

wambacher wrote:

Oder man müsste zu diesem Punkt bzw. dessen Koordinate die jeweils passende Straße in der korrekten Richtung zu finden -

Die ergibt sich bei einem Punkt aus zwei Angaben: "Linear_Reference": Zugehörigkeit zum Segment, "Negative" dem zugehörigen, vorherigen Punkt und "Positive" als folgenden Punkt. Ansonsten siehe folgendes...

mueschel wrote:

TMC kennt sehr wohl Richtungen und auch Objekte die es nur in einer Fahrtrichtung gibt.

Aber erst mal nicht in den LCL-Codes der Liniensegmenten.

mueschel wrote:

Wenn es z.B. eine Ausfahrt an einer Autobahn nur in einer Fahrtrichtung gibt, ist das in den Daten enthalten.

Wo genau? hast du ein Beispiel? In den Daten der BaSt-Tabelle sehe ich erst mal keine getrennten LCL-Codes für unterschiedliche Fahrtrichtungen. Normale Autobahnausfahrten (Typ P1 Subtyp 3) haben keine Fahrtrichtungsangaben. Aus "Negative" und "Positive" ergeben sich nur der vorherige und nachfolgende Punkt (Erfassungsrichtung??).

Fahrtrichtung könnte man aber nur angeben, wenn man da zusätzlich zu den Liniensegmenten auch die Punkt-Codes angibt in einer Reihenfolge angibt:

"LCL 7092 zwischen LCL 11068 und LCL 11069" oder aber "LCL 7092 zwischen LCL 11069 und LCL 11066" wäre:

"A 39 Braunschweig-Wolfsburg zwischen Mörse und Fallersleben-Süd" oder "A 39 Braunschweig-Wolfsburg zwischen Fallersleben-Süd und Mörse"

Aus dem LCL-Code des Punktes und den Angaben in "Negative" und "Positive" kann man höchstens die Erfassungsrichtung schließen, Sicher bin ich mir nicht.

Welche Aussagen die Spalten "IN_POSITIVE", "OUT_POSITIVE", "IN_NEGATIVE", "OUT_NEGATIVE", "PRESENT_POSITIVE", "PRESENT_NEGATIVE" ist mit noch nicht ganz klar.

Sven

viw wrote:

Die Suchfunktion bringt tatsächlich 4 Treffer. Aber das sind nur einzelne Punkte. Mhhh.

Ja, richtig. Offenbar hat keine Straße bzw. kein Segment in den Tabellen diesen Namen, sondern nur die 4 Punkte.

Hier habe ich noch etwas interessantes gefunden:
http://manuelhohmann.dyndns.org/osm/tmc … &lcd=57868

Das ist vielleicht eine dumme Frage, aber warum genau ist dieses Stadion interessant? 😉 Ja, die Tabellen enthalten auch POIs, hier vom Typ P6.12 Stadion.

streckenkundler wrote:

mueschel wrote:

Wenn es z.B. eine Ausfahrt an einer Autobahn nur in einer Fahrtrichtung gibt, ist das in den Daten enthalten.

Wo genau? hast du ein Beispiel? In den Daten der BaSt-Tabelle sehe ich erst mal keine getrennten LCL-Codes für unterschiedliche Fahrtrichtungen. Normale Autobahnausfahrten (Typ P1 Subtyp 3) haben keine Fahrtrichtungsangaben. Aus "Negative" und "Positive" ergeben sich nur der vorherige und nachfolgende Punkt (Erfassungsrichtung??).

Eben genau daraus: 😄

Welche Aussagen die Spalten "IN_POSITIVE", "OUT_POSITIVE", "IN_NEGATIVE", "OUT_NEGATIVE", "PRESENT_POSITIVE", "PRESENT_NEGATIVE" ist mit noch nicht ganz klar.

IN_POSITIVE: Man kann hier in positiver Richtung einfahren.
OUT_POSITIVE: Man kann hier, vorher in positiver Richtung fahrend, ausfahren.
PRESENT_POSITIVE: Diese Einrichtung (Parkplatz, Rastplatz...) ist in positiver Fahrtrichtung vorhanden.
Gleiches gilt natürlich für *_NEGATIVE. Wenn eine Straße z.B. eine Einbahnstraße ist, kann man an jedem ihrer Punkte nur in der gleichen Richtung einfahren.

Leider sind nicht alle Daten in allen Ländern vorhanden. INTERSECTIONS gibt es in Deutschland und Norwegen, dagegen nicht in Schweden und Italien. In Norwegen scheinen IN_*, OUT_* und PRESENT_* immer 1 zu sein (ob das auch der Realität entspricht, habe ich jetzt nicht nachgeprüft), in Schweden dagegen immer 0 (was sicher nicht der Realität entspricht).

Zum international einheitlichen Format, das in allen 4 Ländern verfügbar ist, gibt es hier eine Erklärung:
http://212.113.105.12/library/BOOKS/GPS … le_Req.pdf
In Deutschland gibt es zusätzlich auch eine CSV-Datei in anderem Format, die Daten sind aber im Wesentlichen gleich. In meine Datenbank habe ich die internationalen Tabellen 1:1 eingelesen.

MHohmann wrote:

IN_POSITIVE: Man kann hier in positiver Richtung einfahren.
OUT_POSITIVE: Man kann hier, vorher in positiver Richtung fahrend, ausfahren.
PRESENT_POSITIVE: Diese Einrichtung (Parkplatz, Rastplatz...) ist in positiver Fahrtrichtung vorhanden.
Gleiches gilt natürlich für *_NEGATIVE. Wenn eine Straße z.B. eine Einbahnstraße ist, kann man an jedem ihrer Punkte nur in der gleichen Richtung einfahren.

Hm... das hätte man in dem PDF "Attributliste zur LCL12.pdf" etwas verständlicher schreiben können.

Wie man das jetz aber in OSM umsetzt... Bei einer normalen Autobahnauffahrt haben wir ja 4 Punkte: Jeweils pro Fahrtrichtung eine Auffahrt und Abfahrt. TMC hat nur einen, da Straßenachsenbasierend... Möglich wäre also eine Relation pro Straßenanschlußpunkt mit den zugehörigen Elementen (z.B. *_Link ways) und in der Relation der zugehörige TMC-LCL-Code... Ein Gedanke der mir irgendwie nicht behagt. 😐

Sven

streckenkundler wrote:

Hm... das hätte man in dem PDF "Attributliste zur LCL12.pdf" etwas verständlicher schreiben können.

Ja, richtig, die ist etwas kryptisch...

Wie man das jetz aber in OSM umsetzt... Bei einer normalen Autobahnauffahrt haben wir ja 4 Punkte: Jeweils pro Fahrtrichtung eine Auffahrt und Abfahrt. TMC hat nur einen, da Straßenachsenbasierend... Möglich wäre also eine Relation pro Straßenanschlußpunkt mit den zugehörigen Elementen (z.B. *_Link ways) und in der Relation der zugehörige TMC-LCL-Code...

Ja, so in etwa könnte man es wohl machen, wobei ich allerdings wohl statt der *_link Ways eher die Punkte auf der Autobahn genommen hätte, an denen besagte Ways von der Autobahn abzweigen bzw. darauf treffen. Mit einer solchen Relation scheint es mir derzeit auch am saubersten zu sein, da ein OSM-Node ja durchaus zu mehreren TMC-Punkten gehören kann (z.B. bei einer einfachen Kreuzung ohne bauliche Trennung, wenn beide Straßen TMC-Routen sind). So spart man sich Schlüssel mit Mehrfachwerten und Semikola am Node selbst.

Ein Gedanke der mir irgendwie nicht behagt. 😐

Könntest du etwas genauer sagen, was dir nicht behagt? Vielleicht lässt sich die Idee verbessern. So ganz schlüssig bin ich mir da nämlich auch noch nicht. Gerade für einfache Kreuzungen klingt das nach mit Kanonen auf Spatzen schießen, extra einen Relation mit nur einem Punkt anzulegen.

Jetzt habe ich endlich auch verstanden, wie INTERRUPTSROAD funktioniert - du hattest es zwar erklärt, aber ich hatte es falsch verstanden 😉 Am Beispiel der B 70 (50435): Dort ist die Straße zwischen den Punkten 17 und 24935 unterbrochen, d.h. sie besteht aus unverbundenen Teilstücken. Eines davon endet bei 17, das nächste beginnt bei 24935. Im Feld INTERRUPTSROAD dieser beiden Punkte ist daher jeweils der Location Code des anderen Punktes eingetragen.

MHohmann wrote:

streckenkundler wrote:

Ein Gedanke der mir irgendwie nicht behagt. 😐

Könntest du etwas genauer sagen, was dir nicht behagt? Vielleicht lässt sich die Idee verbessern. So ganz schlüssig bin ich mir da nämlich auch noch nicht. Gerade für einfache Kreuzungen klingt das nach mit Kanonen auf Spatzen schießen, extra einen Relation mit nur einem Punkt anzulegen.

Ja weil das Relationsgewusel um eine Faccette reicher wird. Wobei es bei bei solchen Autobahnanschlüssen durchaus eine elegante Lösung ist. Bei Einfachen Kreuzungen ist das auch nicht nötig, ein TMC-Tag am Kreuzungspunkt, feddich... Aber was ist heute noch einfach. Kreuzungen mit baulich getrennten Spuren nommen immer mehr in Mode...

Sven

streckenkundler wrote:

Aber was ist heute noch einfach. Kreuzungen mit baulich getrennten Spuren nommen immer mehr in Mode...

Gerade bei Hauptverkehrsstraßen, und darauf beziehen sich ja die meisten TMC-Routen. Na gut, ich denke, das ist ein Argument für Relationen. Ich werde mal ein Proposal dazu aufsetzen.

streckenkundler wrote:

Ja weil das Relationsgewusel um eine Faccette reicher wird. Wobei es bei bei solchen Autobahnanschlüssen durchaus eine elegante Lösung ist. Bei Einfachen Kreuzungen ist das auch nicht nötig, ein TMC-Tag am Kreuzungspunkt

Ich würde für Relationen plädieren, aus mehrere Gründen:
- Reicht ein einziges Tag wirklich aus? Ich bin mir da noch nicht sicher. Es braucht eher 2-3 TMC-Tags um eine Location abzubilden und wenn diese Tags dann an einem Knoten hängen haben wir wieder eine unübersichtliche Sitation.
- Wenn die Kreuzung doch einmal detailierter gemappt wird, kann man einem TMC-unerfahreren Mapper recht einfach beibringen "in diese Relation kommen alle relevanten Knoten der Kreuzung"
- Ganz wichtig: Viele Locations haben mehrere Codes. Mit Relationen kein Problem, mit einem tag am Knoten wird das sehr unschön.

Für die Zukunft kann ein Blick auf die TMC-Informationen die per UKW verteilt werden auch nicht schaden. Ich habe mir mal einen Empfänger genommen und ein kleines Script geschrieben, das die Daten auseinanderpflückt und in die einzelnen Teile aufspaltet. Das hier sind die momentanen Meldungen in Frankfurt. Unten habe ich die erste Meldung dann mal (noch von Hand) übersetzt - allerdings sind das alles feste Textbausteine, die man auch automatisch erzeugen kann. Die genauen Formulierungen sind in der Event_List vom BaST enthalten.
Vielleicht hat ja jemand Lust, solche Meldungen auf einer Karte darzustellen - zumindest grob nach Location-Liste, bis die OSM-TMC-Daten funktionsfähig sind?

Ev␣␣201␣␣␣␣␣␣␣␣␣LC␣11611␣␣␣␣␣␣␣␣Diver␣1␣Dir␣neg␣Exten␣0␣(9)AddEvent␣63␣␣(6)Suppl␣162
Ev␣␣703␣␣␣␣␣␣␣␣␣LC␣22492␣␣␣␣␣␣␣␣Diver␣1␣Dir␣pos␣Exten␣0␣(9)AddEvent␣25␣␣(6)Suppl␣4␣␣␣␣␣␣(1)Control␣2
Ev␣␣406␣␣␣␣␣␣␣␣␣LC␣23982␣␣␣␣␣␣␣␣Diver␣1␣Dir␣pos␣Exten␣0␣(6)Suppl␣4
Ev␣␣701␣␣␣␣␣␣␣␣␣LC␣22496␣␣␣␣␣␣␣␣Diver␣1␣Dir␣pos␣Exten␣0␣(6)Suppl␣4␣␣␣␣␣␣(9)AddEvent␣401␣(1)Control␣2
Ev␣␣701␣␣␣␣␣␣␣␣␣LC␣11401␣␣␣␣␣␣␣␣Diver␣1␣Dir␣pos␣Exten␣0␣(9)AddEvent␣407␣(6)Suppl␣4
Ev␣␣108␣␣␣␣␣␣␣␣␣LC␣10853␣␣␣␣␣␣␣␣Diver␣1␣Dir␣neg␣Exten␣2␣(2)Length␣11␣␣␣␣(1)Control␣6
Ev␣␣334␣␣␣␣␣␣␣␣␣LC␣11533␣␣␣␣␣␣␣␣Diver␣0␣Dir␣pos␣Exten␣1␣Dura␣0

Ev␣␣201␣␣␣␣␣␣=>␣Unfall
LC␣11611␣␣␣␣␣=>␣A5␣Bensheim
Diver␣1␣␣␣␣␣␣=>␣die␣empfohlene␣Umleitung␣kann␣benutzt␣werden
Dir␣neg␣␣␣␣␣␣=>␣in␣negativer␣Richtung
Exten␣0␣␣␣␣␣␣=>␣Ausdehnung␣0␣TMC␣Locations
AddEvent␣63␣␣=>␣Gefahr␣durch␣Gegenstände␣auf␣der␣Fahrbahn
Suppl␣162␣␣␣␣=>␣in␣der␣Ein/Ausfahrt

Oh toll, so hab ich mir das gewünscht 🙂 Könntest du vielleicht die Rohdaten von deinem Sample bereitstellen? An so einer Übersetzung würde ich mich auch gerne versuchen, und sie letztlich dann auch für Navit implementieren. Nur leider habe ich hier keinen TMC-Empfang, da das System in Estland (noch) nicht im Einsatz ist, und damit keine Daten...

Ja, sowas auf der Karte darzustellen halte ich für eine gute Idee. Prinzipiell würde ich mich zumindest daran beteiligen wollen, sowas aufzusetzen. Die Frage ist nur, wo man die Daten am besten hernimmt. Von sennewald63 gab es dazu den Vorschlag, dass ein paar Leute aus verschiedenen Teilen Deutschland TMC-Daten empfangen und an einen Server übermitteln, der sie dann auswertet und auf der Karte darstellt. (So ähnlich funktionieren Luftraum-Hobbyisten-Seiten wie Flightradar24.)

mueschel wrote:

Ich habe mir mal einen Empfänger genommen und ein kleines Script geschrieben, das die Daten auseinanderpflückt und in die einzelnen Teile aufspaltet.

Das würde ich hier in Bremen auch gerne mal machen. Was brauche ich denn, um die Signale/Daten in den Computer zu bekommen?

Gehrke wrote:

rauche ich denn, um die Signale/Daten in den Computer zu bekommen?

Du brauchst einen TMC-Empfänger, den du dann noch mit einem passenden Interface für den PC versehen musst. Z.B. gibt es hier eine Umbauanleitung für ein spezielles Modell. Ich habe hier einen Empfänger direkt an einem Raspberry Pi hängen, dafür musste ich nur den Stecker wechseln.

MHohmann wrote:

Könntest du vielleicht die Rohdaten von deinem Sample bereitstellen? An so einer Übersetzung würde ich mich auch gerne versuchen

Mein Code: http://github.com/mueschel/TmcDecoder
Ein kurzer Ausschnitt der RDS Daten: http://osm.mueschelsoft.de/RDSraw.bin

Wunderbar, danke! Der Link zum Code müsste wohl https://github.com/mueschel/TmcDecoder sein 😉 Ja, so hatte ich mir das vorgestellt. Die Daten kommen ja letztlich über einen seriellen Port, also genau wie die NMEA-Daten aus einem GPS-Empfänger. Und das zu decodieren sollte ja nicht schwer sein (auch wenn ich nicht genug von Perl verstehe, um das zu erkennen, aber in C ist es sicher auch nicht schwerer 😉).

Der Link ist schon korrigiert, gleich zwei Tippfehler auf einmal 🤔
Viel echtes "perlisch" sollte mein Code nicht enthalten, nur zwei Zeilen, der Rest sollte sich aus dem Kontext ergeben. Dekodieren muss man die Sachen bitweise, das ist kein ASCII wie bei NMEA. Bei Fragen kannst du mir gerne eine PN schreiben.

Hat jemand schonmal darüber nachgedacht das Smartphone dafür zu verwenden?
Fast alle diese Dinger haben doch ein UKW Radio drin und zugreifen kann man darüber sicher auch über Android, oder?

Gleich der erste Versuch: http://www.freesoftwhere.org/category/rds/
oder hier: http://www.sesma.eu/windowsmobile/en/hypergps.htm

Das hat mir doch keine Ruhe gelassen. Hier noch etwas:
http://sourceforge.net/apps/mediawiki/t … ageChannel

Das sieht ja klasse aus 🙂 Vor allem beim letzten Link ist eine Menge technische Dokumentation dabei, da hat sich offenbar schon jemand viele Gedanken gemacht. So in etwa stelle ich mir auch die Implementierung in Navit vor.

Zu Android kann ich persönlich nicht viel sagen, da ich selbst kein Android habe und auch kein Smartphone, sondern "nur" ein Wifi-Tablet mit Ubuntu. Von daher bräuchte ich hier etwas Unterstützung was die Implementierung angeht, da ich mich mit der Android-Entwicklung überhaupt nicht auskenne und eben kein Testsystem habe. Das gleiche gilt für Windows / Windows Phone. Aber in beiden Fällen dürfte das nur die Datenanbindung an die TMC-Hardware betreffen, die Auswertung läuft dann ja wie bei Linux auch.

Gerade habe ich herausgefunden, dass auch die Location Codes für Belgien kostenlos bezogen werden können:
http://www.technum.be/en/rds-tmc

Skizzen und Proposal sind in Arbeit...

Für windows mobile hätte ich hier was: http://forum.xda-developers.com/showthread.php?t=497977
Bei Android scheint es noch nicht ganz soweit zu sein aber hier gibt es schon mal eine Libary: http://mmbtools.crc.ca/content/view/53/33/

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 … ection.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.

MHohmann wrote:

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.

Das Ganze ist auch mehr verwirrend als zielführend. Daher ergibt sich die Frage ob es nicht ausreichend ist die TMC Segmente mit Start und Endknoten zu erfassen und die Richtung wegzulassen, da diese sich ja gemäß Definition ergibt. Oder habe ich das einfach nur falsch gedeutet?

Auch nach zweifachem Lesen habe ich nichts gefunden, das ich bemängeln würde.

MHohmann wrote:

Bleibt noch die Frage, was die positive und was die negative Fahrtrichtung sein sollen.

Ich würde mich hier an den TMC-Standard halten. Ich sehe da kein Problem - man muss einfach geografisch denken und nicht aus Autofahrer-Sicht, dann ist alles direkt eindeutig.

Zur tabcd: Wenn ich das richtig verstehe, ändert sich die tabcd nicht, nur die Versionsnummer wird bei einem Update geändert. Erst wenn jemand eine völlig neue Tabelle anlegt, dann gäbe es eine neue tabcd. Würde es deswegen nicht Sinn machen, auch die Version einzutragen? Das enthält zwar keine wirkliche Information, aber dem Mapper zeigt es direkt, wie aktuell die Daten sind, und ob sie seit dem letzten Update jemand überprüft hat.

Für ein vollständiges mapping bei Autobahnkreuzen könnte sich optional anbieten, die Wege der Links mit Rolle in_positive, out_negative etc. zu versehen. Mit dieser Information kann man dann auch direkt die richtige Straße markieren wenn eine Ausfahrt gesperrt ist.

viw wrote:

Das Ganze ist auch mehr verwirrend als zielführend. Daher ergibt sich die Frage ob es nicht ausreichend ist die TMC Segmente mit Start und Endknoten zu erfassen und die Richtung wegzulassen, da diese sich ja gemäß Definition ergibt. Oder habe ich das einfach nur falsch gedeutet?

Ja, damit hast du vermutlich Recht, man muss das wohl nicht explizit taggen. Was genau meinst du in diesem Zusammenhang mit "TMC Segmente mit Start und Endknoten erfassen"?

mueschel wrote:

Zur tabcd: Wenn ich das richtig verstehe, ändert sich die tabcd nicht, nur die Versionsnummer wird bei einem Update geändert. Erst wenn jemand eine völlig neue Tabelle anlegt, dann gäbe es eine neue tabcd. Würde es deswegen nicht Sinn machen, auch die Version einzutragen? Das enthält zwar keine wirkliche Information, aber dem Mapper zeigt es direkt, wie aktuell die Daten sind, und ob sie seit dem letzten Update jemand überprüft hat.

Richtig, die tabcd bleibt gleich, so lange keine komplett neue Tabelle angelegt wird. Ich hatte mir auch anfangs überlegt, die Versionsnummer zu taggen, damit man den Datenstand erfasst hat, bin dann aber doch zu dem Schluss gekommen, dass es vielleicht eher Nachteile hätte. In so einem Fall müsste man alle TMC-Relationen ändern und die Versionsnummer anpassen, sobald eine neue Tabelle herauskommt - und nicht nur die, bei denen sich etwas ändert. Zugegeben, das meiste könnte man davon automatisch machen, und nur die Relationen einem Nutzer überlassen, bei denen sich wirklich etwas ändert. Allerdings würde das auch zusätzlich die History dieser Relationen füllen. Lohnt sich das wirklich?

Für ein vollständiges mapping bei Autobahnkreuzen könnte sich optional anbieten, die Wege der Links mit Rolle in_positive, out_negative etc. zu versehen. Mit dieser Information kann man dann auch direkt die richtige Straße markieren wenn eine Ausfahrt gesperrt ist.

Sehr gute Idee. Bei einfachen Autobahnausfahrten stelle ich mir das mit so einem Tagging dann relativ simpel vor, weil es ja in jeder Richtung eine Auf- und Ausfahrt gibt. Ich frage mich gerade, wie denn eine TMC-Nachricht codiert würde, wenn ein Teil eines Autobahnkreuzes gesperrt ist, also z.B. man nicht von der A 2 aus Richtung Osten kommend auf die A 7 nach Süden fahren kann, alles andere aber möglich ist. Dann ist ja weder generell die Ausfahrt aus der A 2 gesperrt, noch die Einfahrt in die A 7, sondern eben nur dieser eine Link.

MHohmann wrote:

ch frage mich gerade, wie denn eine TMC-Nachricht codiert würde, wenn ein Teil eines Autobahnkreuzes gesperrt ist

Kein Thema, haben wir gerade in Wetzlar Ost: http://www.openstreetmap.org/#map=17/50.57138/8.54780
Nicht möglich sind: Ost->Nord, Ost->Süd und Nord->West (alle Links die die Lahnbrücke berühren), laut TMC auch Nord->Ost, laut Mitteilung auf hessen.de aber nicht.
In den TMC-Meldungen:

Ev␣␣406␣␣␣␣␣␣␣␣␣LC␣23982␣␣␣␣␣␣␣␣Dir␣pos␣Exten␣0␣(6)Suppl␣4
B49␣Anschlussstelle␣Wetzlar␣Ost,␣Einfahrt␣gesperrt,␣aus␣Richtung␣Gießen,␣eine␣Umleitung␣ist␣eingerichtet
Ev␣␣701␣␣␣␣␣␣␣␣␣LC␣11401␣␣␣␣␣␣␣␣Dir␣pos␣Exten␣0␣(9)AddEvent␣407␣(6)Suppl␣4
A45␣Anschlussstelle␣Wetzlar␣Ost,␣in␣Richtung␣Süden,␣Baustelle,␣Ausfahrt␣gesperrt,␣eine␣Umleitung␣ist␣eingerichtet

Es gibt noch Möglichkeiten, "erste Ausfahrt", "zweite Ausfahrt" und "Ausfahrt Richtung XY" zu kodieren, das lässt sich also alles genau ausdrücken.

MHohmann wrote:

viw wrote:

Das Ganze ist auch mehr verwirrend als zielführend. Daher ergibt sich die Frage ob es nicht ausreichend ist die TMC Segmente mit Start und Endknoten zu erfassen und die Richtung wegzulassen, da diese sich ja gemäß Definition ergibt. Oder habe ich das einfach nur falsch gedeutet?

Ja, damit hast du vermutlich Recht, man muss das wohl nicht explizit taggen. Was genau meinst du in diesem Zusammenhang mit "TMC Segmente mit Start und Endknoten erfassen"?

Naja ein TMC Segment ist für mich eine Relation von einem Startpunkt (node) mit einem der Reihenfolge nach sortierten Weg zu einem Endpunkt (node) die beiden nodes müssen am Anfang bzw. Ende des ersten bzw. letzten Wegstückes liegen.

Ich habe es mit den GTFS Segmenten ähnlich gemacht, wobei die Haltestellen nicht Bestandteil des Weges sein müssen. Das könnte man für die TMC nodes auch so machen, wenn man möchte. (Aber du schlugst ja vor lieber vier Knoten in einer Relation zusammenzufassen.)

mueschel wrote:

Kein Thema, haben wir gerade in Wetzlar Ost: http://www.openstreetmap.org/#map=17/50.57138/8.54780
Nicht möglich sind: Ost->Nord, Ost->Süd und Nord->West (alle Links die die Lahnbrücke berühren), laut TMC auch Nord->Ost, laut Mitteilung auf hessen.de aber nicht.
In den TMC-Meldungen:

Ev␣␣406␣␣␣␣␣␣␣␣␣LC␣23982␣␣␣␣␣␣␣␣Dir␣pos␣Exten␣0␣(6)Suppl␣4
B49␣Anschlussstelle␣Wetzlar␣Ost,␣Einfahrt␣gesperrt,␣aus␣Richtung␣Gießen,␣eine␣Umleitung␣ist␣eingerichtet
Ev␣␣701␣␣␣␣␣␣␣␣␣LC␣11401␣␣␣␣␣␣␣␣Dir␣pos␣Exten␣0␣(9)AddEvent␣407␣(6)Suppl␣4
A45␣Anschlussstelle␣Wetzlar␣Ost,␣in␣Richtung␣Süden,␣Baustelle,␣Ausfahrt␣gesperrt,␣eine␣Umleitung␣ist␣eingerichtet

Es gibt noch Möglichkeiten, "erste Ausfahrt", "zweite Ausfahrt" und "Ausfahrt Richtung XY" zu kodieren, das lässt sich also alles genau ausdrücken.

Ah, verstehe. So 100% sehe ich es aus der Datenstruktur noch nicht, aber da muss ich noch mal die Spezifikation gründlicher lesen 😉 Ja, damit klappt das natürlich wunderbar. Dann müsste man nur schauen, wie man es so taggt, dass man mit den übertragenen Infos auch wirklich eindeutig den zugehörigen Link finden kann.

viw wrote:

Naja ein TMC Segment ist für mich eine Relation von einem Startpunkt (node) mit einem der Reihenfolge nach sortierten Weg zu einem Endpunkt (node) die beiden nodes müssen am Anfang bzw. Ende des ersten bzw. letzten Wegstückes liegen.

Ich habe es mit den GTFS Segmenten ähnlich gemacht, wobei die Haltestellen nicht Bestandteil des Weges sein müssen. Das könnte man für die TMC nodes auch so machen, wenn man möchte. (Aber du schlugst ja vor lieber vier Knoten in einer Relation zusammenzufassen.)

Ja, so eine Idee habe ich auch noch im Hinterkopf - also TMC-Links (ich nenne sie mal lieber so, weil es Verbindungen zwischen zwei TMC-Punkten sind, und der Begriff Segment schon für ein größeres Straßenteilstück benutzt wird) durch Routenrelationen abzubilden. Das hatte ich oben noch nicht aufgelistet, weil ich da noch am überlegen bin, aber das wäre sozusagen der zweite Teil, zusätzlich zu den reinen Punkten - oder meinenwegen auch alternativ? Ich finde die Punkte deshalb praktisch, weil man viele Informationen einmalig in so einen Punkt packen und den dann referenzieren kann - und eben Link-Roads damit einbeziehen wie von mueschel vorgeschlagen.

Proposal ist angelegt und wird demnächst weiter mit Inhalt gefüllt.

MHohmann wrote:

Ja, so eine Idee habe ich auch noch im Hinterkopf - also TMC-Links (ich nenne sie mal lieber so, weil es Verbindungen zwischen zwei TMC-Punkten sind, und der Begriff Segment schon für ein größeres Straßenteilstück benutzt wird) durch Routenrelationen abzubilden.

Das wäre dann sinngemäß identisch mit dem Ansatz des Proposals "vereinfachtes TMC" (siehe #8). Da gibt es sogar ein paar rudimentäre Realisierungen, z.B. die B 297 bei Tübingen.

seichter wrote:

Das wäre dann sinngemäß identisch mit dem Ansatz des Proposals "vereinfachtes TMC" (siehe #8). Da gibt es sogar ein paar rudimentäre Realisierungen, z.B. die B 297 bei Tübingen.

Ja, richtig. Dort sollte es mit Tags an den Ways selbst gelöst werden. IMHO wäre eine Routenrelation sinnvoller, weil man an der die ganzen Tags nur einmal setzen muss und nicht an jedem Wegstück. Da kann man natürlich auch verschiedener Auffassung sein...

Das Proposal an sich finde ich gut, deshalb würde ich auch einiges davon einfließen lassen. Genau daher stammt ja diese Idee mit dem Taggen von Links, also ich habe das nicht selbst ausgedacht 😉

MHohmann wrote:

viw wrote:

Naja ein TMC Segment ist für mich eine Relation von einem Startpunkt (node) mit einem der Reihenfolge nach sortierten Weg zu einem Endpunkt (node) die beiden nodes müssen am Anfang bzw. Ende des ersten bzw. letzten Wegstückes liegen.

Ich habe es mit den GTFS Segmenten ähnlich gemacht, wobei die Haltestellen nicht Bestandteil des Weges sein müssen. Das könnte man für die TMC nodes auch so machen, wenn man möchte. (Aber du schlugst ja vor lieber vier Knoten in einer Relation zusammenzufassen.)

Ja, so eine Idee habe ich auch noch im Hinterkopf - also TMC-Links (ich nenne sie mal lieber so, weil es Verbindungen zwischen zwei TMC-Punkten sind, und der Begriff Segment schon für ein größeres Straßenteilstück benutzt wird) durch Routenrelationen abzubilden. Das hatte ich oben noch nicht aufgelistet, weil ich da noch am überlegen bin, aber das wäre sozusagen der zweite Teil, zusätzlich zu den reinen Punkten - oder meinenwegen auch alternativ? Ich finde die Punkte deshalb praktisch, weil man viele Informationen einmalig in so einen Punkt packen und den dann referenzieren kann - und eben Link-Roads damit einbeziehen wie von mueschel vorgeschlagen.

Proposal ist angelegt und wird demnächst weiter mit Inhalt gefüllt.

Naja wozu benötigt man die Information der Punkte? Insbesondere wenn sie an großen Kreuzungen doch eher Relationen sind?
Vielleicht reichen die Relationen der TMC-Links ja aus. Und auch die anderen Probleme ließen sich mit Relationen von Wegen mit den entsprechenden tags lösen. Dann gibt es eben keinen Start- oder Endpunkt, sondern eine Richtung oder was auch sonst diesen Weg als den richtigen identifizieren würde.

viw wrote:

Naja wozu benötigt man die Information der Punkte? Insbesondere wenn sie an großen Kreuzungen doch eher Relationen sind?
Vielleicht reichen die Relationen der TMC-Links ja aus.

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.

Und auch die anderen Probleme ließen sich mit Relationen von Wegen mit den entsprechenden tags lösen. Dann gibt es eben keinen Start- oder Endpunkt, sondern eine Richtung oder was auch sonst diesen Weg als den richtigen identifizieren würde.

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 .

mueschel wrote:

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.

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...

mueschel wrote:

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.

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.

mueschel wrote:

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.

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.

mueschel wrote:

- 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

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.

mueschel wrote:

- 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.

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.

viw wrote:

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.

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.

Eventuell gibt es bei Ausfahrten auch die gleichen Meldungen wie bei Parkplätzen.

Das kann sein, da muss man wohl einfach mal die elektronischen Ohren offen halten und schauen, was so reinkommt.

Allerdings nehmen bei neugebauten/sanierten Strecken diese Zwischenstücke ab.
http://www.openstreetmap.org/#map=16/51.0624/13.6038

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.

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.

Sehe ich auch so.

Man kann in Relationen (Sammlungen) sowohl die einzelnen Location Relationen aber auch die vielleicht einzeln vorkommenden Nodes zu den Regionen vereinigen.

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.

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 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.

mueschel wrote:

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:

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.

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).

MHohmann wrote:

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

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.

viw wrote:

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.

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.

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.

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.

mueschel wrote:

Ü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.

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.

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 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.

mueschel wrote:

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

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.

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.

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.

mueschel wrote:

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

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

Ja, das sehe ich so.

Die Komplexität der notwendigen Arbeit beim Anlegen der Relationen:
- Anlegen der Relation an sich mit den notwendigen Attributen: für beides identisch (evtl kleiner bei 4, weil u.U. keine eigene Relation benötigt wird)
- Arbeit für das Erkennen welche Wege zur Relation gehören müssen: steigt mit der größere des Gebiets das ich absuchen muss, steigt mit der Zahl der Members der Relation
- Arbeit beim Hinzufügen von members: Direkt abhängig von der Zahl der Elemente

Dazu kommt:
- Aufwand der Maintenance bzw. Gefahr der unabsichtlichen Beschädigung: Im wesentlichen abhängig von der Zahl der Wegstücke, insbesondere von der Zahl der Kreuzungen mit anderen Wegen.

Also dem kann ich nicht zustimmen. Ich markieren die Elemente der Reihe nach. Bei einer Straße und Autobahn ist das ganz einfach, weil man alle Abschnitte bis zu nächsten Kreuzung wählt. Dann kann man die Relation mit einem Klick erstellen und fügt die Tags hinzu. Außerdem erkennt man ob die Stücke alle zusammenhängen indem man sich den Bereich im Josm anschaut der dafür vorgesehen ist. Da ist es egal ob das 5 oder 15 Member sind.
komplexer finde ich an Autobahn Auf- und Abfahrten. Dort muss man nämlich die richtigen Tags finden. Also Fahrtrichtung und Co.

Die Gefahr der beschädigung bei langen Relationen ist durchaus höher. Aber auch die Wahrscheinlichkeit das wenigstens einige Member an der richtigen Stelle überleben auch. Damit sind Streckensperrungen immer wirksam. Nur bei reduzierten Geschwindigkeiten etc. wirkt das nicht mehr auf den gesamten Abschnitt.
Bei kurzen Relationen oder den Punkten geht jedoch mit der Löschung einzelner Punkte schon sämtliche Informationen verloren. Es kann beispielsweise keine Verbindung zwischen Benachbarten Punkten gefunden werden. Wenn zwei Punkte einer Fahrbahn entfallen.

Inzwischen habe ich den vorgeschlagenen 4-Stufen-Plan mal im Proposal aufgeschrieben. Die ersten beiden Stufen sind in Kombination ein Mittelding zwischen den beiden Vorschlägen, dass entweder TMC-Punkte oder TMC-Links mehr Vorteile haben. Ich denke, dass man so die Vorteile von beiden ausnutzen kann - relativ einfaches Mappen, Robustheit gegenüber Fehlern, automatische Validierbarkeit und Nutzen für den Anwender. Die anderen Stufen bauen darauf auf. Wenn sich eine Stufe im Laufe des Proposals als unvorteilhaft herausstellt, kann sie auch wegfallen.

Daneben habe ich auch noch ein wenig an der TMC-Dokumentation gearbeitet und selbst ein wenig mit dem Entschlüsseln von TMC-Meldungen herumprobiert. Dabei habe ich u.a. eine interessante Meldung gefunden, bei der an Location 58:1:22492 ein Tunnel gesperrt ist. Nun ist aber diese Location in den TMC-Tabellen ein Ort (P3.37) und kein Tunnel (P3.1), d.h. die Verbindung zwischen diesem Punkt und dem Tunnel ist nicht logischer / datentechnischer Natur, sondern nur durch die geografische Nähe gegeben, was ein Auffinden dieses Tunnels nicht einfacher macht... Dennoch wäre es natürlich möglich, wenn der Tunnel Teil von geeigneten TMC-Links ist, die an diesem Punkt enden.

MHohmann wrote:

Dabei habe ich u.a. eine interessante Meldung gefunden, bei der an Location 58:1:22492 ein Tunnel gesperrt ist. Nun ist aber diese Location in den TMC-Tabellen ein Ort (P3.37) und kein Tunnel (P3.1), d.h. die Verbindung zwischen diesem Punkt und dem Tunnel ist nicht logischer / datentechnischer Natur, sondern nur durch die geografische Nähe gegeben

Kleinere Objekte wie dieser Tunnel haben keine eigene Location. Es ist also einer der Tunnel auf der angegeben Strecke (es könnte ja mehrere geben) - aus diesem Grund macht es wohl auch keinen Sinn, hier genauere Informationen bekommen zu wollen als es TMC an sich hergibt. Wenn es auf dem TMC-Link nur einen Tunnel gibt, dann lässt sich dieser natürlich auch schnell finden und entsprechend markieren.
http://osm.org/go/0GKsSzWo

mueschel wrote:

Kleinere Objekte wie dieser Tunnel haben keine eigene Location. Es ist also einer der Tunnel auf der angegeben Strecke (es könnte ja mehrere geben) - aus diesem Grund macht es wohl auch keinen Sinn, hier genauere Informationen bekommen zu wollen als es TMC an sich hergibt. Wenn es auf dem TMC-Link nur einen Tunnel gibt, dann lässt sich dieser natürlich auch schnell finden und entsprechend markieren.
http://osm.org/go/0GKsSzWo

Ja, genau so dachte ich mir das auch.

MHohmann wrote:

Inzwischen habe ich den vorgeschlagenen 4-Stufen-Plan mal im Proposal aufgeschrieben. Die ersten beiden Stufen sind in Kombination ein Mittelding zwischen den beiden Vorschlägen, dass entweder TMC-Punkte oder TMC-Links mehr Vorteile haben. Ich denke, dass man so die Vorteile von beiden ausnutzen kann - relativ einfaches Mappen, Robustheit gegenüber Fehlern, automatische Validierbarkeit und Nutzen für den Anwender. Die anderen Stufen bauen darauf auf. Wenn sich eine Stufe im Laufe des Proposals als unvorteilhaft herausstellt, kann sie auch wegfallen.

Das klingt doch erstmal sehr interessant.

Ich habe mich noch einmal an die Auswertung dieser TMC-Meldungen gemacht:

mueschel wrote:

Kein Thema, haben wir gerade in Wetzlar Ost: http://www.openstreetmap.org/#map=17/50.57138/8.54780
Nicht möglich sind: Ost->Nord, Ost->Süd und Nord->West (alle Links die die Lahnbrücke berühren), laut TMC auch Nord->Ost, laut Mitteilung auf hessen.de aber nicht.
In den TMC-Meldungen:

Ev␣␣406␣␣␣␣␣␣␣␣␣LC␣23982␣␣␣␣␣␣␣␣Dir␣pos␣Exten␣0␣(6)Suppl␣4
B49␣Anschlussstelle␣Wetzlar␣Ost,␣Einfahrt␣gesperrt,␣aus␣Richtung␣Gießen,␣eine␣Umleitung␣ist␣eingerichtet
Ev␣␣701␣␣␣␣␣␣␣␣␣LC␣11401␣␣␣␣␣␣␣␣Dir␣pos␣Exten␣0␣(9)AddEvent␣407␣(6)Suppl␣4
A45␣Anschlussstelle␣Wetzlar␣Ost,␣in␣Richtung␣Süden,␣Baustelle,␣Ausfahrt␣gesperrt,␣eine␣Umleitung␣ist␣eingerichtet

Übersetzt habe ich sie jetzt genau so. Mich wundert hier aber, dass Hessen Mobil hier nicht übereinstimmt und stattdessen eine andere Richtung als gesperrt angibt, ebenso wie oben im OSM-Link zu sehen. Die TMC-Meldung ist jetzt natürlich schon ein paar Tage alt, aber die Sperrung besteht wohl langfristig.

Das TMC-Punkt Proposal nimmt langsam Gestalt an. Ich habe die Zusatztags dort mal einfach cid=* statt tmc:cid=* etc. genannt, da ja aus dem type=tmc:point (was ich einfacher finde als type=tmc, tmc:type=point) klar ist, dass es eine TMC-Relation ist und was cid=* etc. hier bedeuten.

Ach ja, weiß zufällig jemand, wie man mit der JOSM-Remote-Funktion eine Relation mit bestimmten Tags erstellen kann, der ein Mapper dann die Relationselemente hinzufügen kann? Das würde das Mappen nämlich deutlich erleichtern, weil JOSM so automatisch den nötigen Bereich herunterladen und alle Tags wie in den Tabellen angegeben basteln würde, das vermeidet Tippfehler bei den Location Codes.

MHohmann wrote:

Ach ja, weiß zufällig jemand, wie man mit der JOSM-Remote-Funktion eine Relation mit bestimmten Tags erstellen kann, der ein Mapper dann die Relationselemente hinzufügen kann? Das würde das Mappen nämlich deutlich erleichtern, weil JOSM so automatisch den nötigen Bereich herunterladen und alle Tags wie in den Tabellen angegeben basteln würde, das vermeidet Tippfehler bei den Location Codes.

Also ich dachte nicht das remotecontrol deine Wünsche (schon) erfüllen kann.
http://wiki.openstreetmap.org/wiki/JOSM … f_Commands

Aber der letzte Absatz zeigt einen möglichen aufwendigeren Weg:
"Other plugins that register additional commands can specify a similar setting to disable the specific command registered by this plugin."

Über den Umweg "import" könnte es auch mit RemoteControl funktionieren.

Instructs JOSM to download the specified OSM file and add it to the current data set.

Die URL zeigt auf ein Server-seitiges Script, das eine frische Relation mit allen Tags als OSM-File zurückliefert.

Ja, diese Import-Funktion scheint sowas zu machen... So ein Script, das eine entsprechende OSM-XML-Datei erzeugt, kann ich sicher basteln. Da muss ich wohl nur noch rausfinden, was ich da für Werte als ID eintrage, damit JOSM erkennt, dass das eine neue Relation sein soll. JOSM benutzt dafür ja negative Zahlen, so weit ich weiß der Reihe nach -1, -2, -3... - aber mein Server weiß ja nicht, welche Zahl beim User, der grad JOSM offen hat, als nächstes kommt. Vielleicht kann man stattdessen auch gar nichts reintun, vielleicht braucht es ein action="create"... Ich probiere mal damit rum.

Evtl. könnte man bei einem Wert wie -100000 anfangen und von dort aus weiter Richtung -inf zählen. Damit man ggfs. auch mehrere Relationen in einer JOSM-Session aufmachen kann, müsste man entweder auf dem Server den aktuellen Wert halten und bei jedem Aufruf runterzählen oder die relation id irgendwie von einem tmc-Bestandteil ableiten.

<?xml␣version='1.0'␣encoding='UTF-8'?>
<osm␣version='0.6'␣upload='true'␣generator='tmc␣relation␣creator'>
<relation␣id='-100000'␣action='create'␣visible='true'>
<tag␣k='bla'␣v='blubber'␣/>
</relation>
</osm>

TMC-Punkte, von denen man die Koordinaten kennt, könnte man natürlich auch gleich mit aufnehmen und dann in JOSM per 'Merge' in bestehende Ways einbauen. Hochladen, fertig.

couchmapper wrote:

Evtl. könnte man bei einem Wert wie -100000 anfangen und von dort aus weiter Richtung -inf zählen. Damit man ggfs. auch mehrere Relationen in einer JOSM-Session aufmachen kann, müsste man entweder auf dem Server den aktuellen Wert halten und bei jedem Aufruf runterzählen oder die relation id irgendwie von einem tmc-Bestandteil ableiten.

Letzteres klingt da so ziemlich am einfachsten. Man könnte es z.B. mit id = -(10000000 * cid + 100000 * tabcd + lcd) versuchen, das ist immer noch unter 10^9 und sollte damit klein genug sein, außerdem ist es eindeutig.

TMC-Punkte, von denen man die Koordinaten kennt, könnte man natürlich auch gleich mit aufnehmen und dann in JOSM per 'Merge' in bestehende Ways einbauen. Hochladen, fertig.

Sowas ähnliches hatte ich mir auch überlegt, allerdings hängen die Rollen dieser Nodes wohl von der Geometrie des zu mappenden TMC-Punktes ab (Autobahnkreuz vs. einfache Ampelkreuzung ohne Richtungsfahrbahnen). Man muss also erst einmal die Geometrie kennen, bevor man Member mit Rollen erstellen kann. Mal schauen, ob sich da was automatisieren lässt... Bei einer Autobahn ist es auf jeden Fall klar (getrennte Richtungsfahrbahnen, Einfahrt != Ausfahrt, also immer 4 Nodes).

MHohmann wrote:

Ich habe mich noch einmal an die Auswertung dieser TMC-Meldungen gemacht:

mueschel wrote:

Ev␣␣406␣␣␣␣␣␣␣␣␣LC␣23982␣␣␣␣␣␣␣␣Dir␣pos␣Exten␣0␣(6)Suppl␣4
B49␣Anschlussstelle␣Wetzlar␣Ost,␣Einfahrt␣gesperrt,␣aus␣Richtung␣Gießen,␣eine␣Umleitung␣ist␣eingerichtet
Ev␣␣701␣␣␣␣␣␣␣␣␣LC␣11401␣␣␣␣␣␣␣␣Dir␣pos␣Exten␣0␣(9)AddEvent␣407␣(6)Suppl␣4
A45␣Anschlussstelle␣Wetzlar␣Ost,␣in␣Richtung␣Süden,␣Baustelle,␣Ausfahrt␣gesperrt,␣eine␣Umleitung␣ist␣eingerichtet

Übersetzt habe ich sie jetzt genau so. Mich wundert hier aber, dass Hessen Mobil hier nicht übereinstimmt und stattdessen eine andere Richtung als gesperrt angibt, ebenso wie oben im OSM-Link zu sehen. Die TMC-Meldung ist jetzt natürlich schon ein paar Tage alt, aber die Sperrung besteht wohl langfristig.

Hessen Mobil ist sich da auch nicht so ganz einig, ich hatte diese Pressemitteilung hier gelesen:
http://mobil.hessen.de/irj/HSVV_Interne … c0cf46.htm
Ich werde mal den Mapper fragen, der das eingetragen hat. Der scheint sich dort ja auszukennen.

MHohmann wrote:

Das TMC-Punkt Proposal nimmt langsam Gestalt an.

Dinge die mir aufgefallen sind:
- Die junction reference sollte nicht ref=* heißen - ref ist ein schon sehr oft benutztes Tag, das hier in einem anderen Zusammenhang benutzt würde.

- Ich würde noch klar machen, dass alle Tags der Relation aus den Tabellen vorgegeben werden - hier hat der Mapper keine Arbeit. Es ist nur notwendig, die richtigen Member in die Relation hinzuzufügen.

- Evtl. könnte man eine Referenz einbauen, zu welcher Straße diese Location gehört - du hast zwar ein intersects=* vorgesehen, womit ich weiß, welche Straße geschnitten wird, aber ich weiß nicht, auf welche Straße sich der Punkt selbst bezieht.

- Die Verwendung von intersects in der Art einer Ring-Liste wie TMC sie benutzt finde ich für die OSM-DB eher weniger geeignet, weil man mehrere Zugriffe braucht, um alle Teile einer Kreuzung zu bekommen. Warum das intersects nicht weglassen und bei Bedarf durch eine Relation type=tmc:junction ersetzen? (Nur falls wir eine Anwendung für diese Information finden & in Stufe 3 oder 4 des Proposals)

- Wie stellst du dir das mapping von RoadName, FirstName und SecondName aus der LCL auf das name-Tag vor?

- Kann man cid und tabcd eventuell zusammenfassen um die Zahl der fixen Tags zu reduzieren? table=58:1 oder etwas in der Art?

- Generell wäre ich für mehr sprechende Namen: 'lcd' versteht niemand, der sich nicht mit TMC befasst. Warum nicht einfach 'ref', was generell für eine Referenznummer benutzt wird?

- Den Typ einer Location halte ich für eine wichtige Information, die für die Einordnung einer Meldung gebraucht wird. evtl als location=P1.8 für einen Kreisel

mueschel wrote:

Hessen Mobil ist sich da auch nicht so ganz einig, ich hatte diese Pressemitteilung hier gelesen:
http://mobil.hessen.de/irj/HSVV_Interne … c0cf46.htm
Ich werde mal den Mapper fragen, der das eingetragen hat. Der scheint sich dort ja auszukennen.

Gute Idee.

mueschel wrote:

- Die junction reference sollte nicht ref=* heißen - ref ist ein schon sehr oft benutztes Tag, das hier in einem anderen Zusammenhang benutzt würde.

Gut, vielleicht junction_ref=*?

- Ich würde noch klar machen, dass alle Tags der Relation aus den Tabellen vorgegeben werden - hier hat der Mapper keine Arbeit. Es ist nur notwendig, die richtigen Member in die Relation hinzuzufügen.

Ja, das kommt da auf jeden Fall noch rein. Dafür mache ich einen Extra-Abschnitt zum Thema "semiautomatischer Import" oder so.

- Evtl. könnte man eine Referenz einbauen, zu welcher Straße diese Location gehört - du hast zwar ein intersects=* vorgesehen, womit ich weiß, welche Straße geschnitten wird, aber ich weiß nicht, auf welche Straße sich der Punkt selbst bezieht.

Gute Idee. Das wollte ich eigentlich über eine zweite Relation machen, in der alle Punkte einer Straße sind, aber man kann es auch an die Punkte selbst taggen.

- Die Verwendung von intersects in der Art einer Ring-Liste wie TMC sie benutzt finde ich für die OSM-DB eher weniger geeignet, weil man mehrere Zugriffe braucht, um alle Teile einer Kreuzung zu bekommen. Warum das intersects nicht weglassen und bei Bedarf durch eine Relation type=tmc:junction ersetzen? (Nur falls wir eine Anwendung für diese Information finden & in Stufe 3 oder 4 des Proposals)

An diese Ring-Liste hatte ich gar nicht gedacht, sondern eher an eines der Name-Felder (müsste SecondName sein), das einem den Namen der kreuzenden Straße oder etwas vergleichbares sagt, und zwar auch dann, wenn besagte Straße nicht in TMC erfasst ist.

- Wie stellst du dir das mapping von RoadName, FirstName und SecondName aus der LCL auf das name-Tag vor?

Für name=* hatte ich nur FirstName im Sinn, SecondName ist der Name der kreuzenden Straße und RoadName... Könnte ein eigenes Tag bekommen.

- Kann man cid und tabcd eventuell zusammenfassen um die Zahl der fixen Tags zu reduzieren? table=58:1 oder etwas in der Art?

Kann man auch machen. Ich fand eine Trennung für klarer.

- Generell wäre ich für mehr sprechende Namen: 'lcd' versteht niemand, der sich nicht mit TMC befasst. Warum nicht einfach 'ref', was generell für eine Referenznummer benutzt wird?

Ich frage mich, ob diese ganzen Relationen überhaupt jemand versteht oder verstehen muss, der sich nicht mit TMC befasst... Wer sie nutzen will, befasst sich ja damit.

- Den Typ einer Location halte ich für eine wichtige Information, die für die Einordnung einer Meldung gebraucht wird. evtl als location=P1.8 für einen Kreisel

Das würde ich vielleicht class=* nennen und stattdessen lcd=* durch location=* ersetzen.

Jetzt wird's kompliziert mit den quotes... Ich mache es mal mit Einrückungen.
Zu Wetzlar Ost: Der Mapper (Hans Wurst) weiß auch nichts genaueres, außer dass diese beiden gemappten Auffahrten wirklich gesperrt sind.

Evtl. könnte man eine Referenz einbauen, zu welcher Straße diese Location gehört

Gute Idee. Das wollte ich eigentlich über eine zweite Relation machen, in der alle Punkte einer Straße sind, aber man kann es auch an die Punkte selbst taggen.

Diese Relation existiert ja fast zwangsläufig, aber den zusätzlichen Tag würde ich als "User convenience" begrüßen.

Den Typ einer Location halte ich für eine wichtige Information.

Das würde ich vielleicht class=* nennen und stattdessen lcd=* durch location=* ersetzen.

class klingt gut. Statt location wäre ich noch bei ref - der lcd entspricht exakt der Definition von ref laut wiki ""ref" stands for "reference" and is used for reference numbers or codes."

Die Verwendung von intersects in der Art einer Ring-Liste wie TMC sie benutzt...

An diese Ring-Liste hatte ich gar nicht gedacht, sondern eher an eines der Name-Felder (müsste SecondName sein)

Wie wäre es dann mit einem etwas anderen Key, z.B. connects_to=* ?

Ich frage mich, ob diese ganzen Relationen überhaupt jemand versteht oder verstehen muss, der sich nicht mit TMC befasst...

Besser wäre es - ich denke genau das ist eines der Hauptprobleme bei der Akzeptanz der Daten.

Für name=* hatte ich nur FirstName im Sinn, SecondName ist der Name der kreuzenden Straße und RoadName... Könnte ein eigenes Tag bekommen.

Gerade in größeren Städten dürfte "FirstName / RoadName" eine recht sinnvolle Wahl sein. Das sollte man wohl dem Mapper überlassen.

Ich lasse die Quotes mal weg und fasse die Änderungen zusammen, die ich eingebaut habe:

• cid=* und tabcd=* zu table=* für Location Code Tabelle zusammengefasst.
• lcd=* in ref=* für Location Code umbenannt.
• ref=* in junction_ref=* für Ausfahrtnummer etc. umbenannt.
• class=* für Klasse, Typ, Subtyp hinzugefügt.
• road_ref=*, seg_ref=* und area_ref=* für Location Codes von übergeordneten Locations hinzugefügt.
• road_name=* für den Straßennamen hinzugefügt.

intersects=* habe ich erst einmal so gelassen, weil ich den Namen logisch finde - das Tag gibt ja an, welche Straße hier gekreuzt wird, und auf englisch ist das eben "to intersect".

Ja, es stimmt natürlich, dass Verständlichkeit der Daten ein wichtiges Ziel ist. Das versuche ich in dem Proposal auch so weit wie möglich umzusetzen. Allerdings sollte es sowohl für den Mapper als auch für den Nutzer der Daten verständlich sein, und letzterer wird eben am ehesten die TMC-Begriffe kennen und sich dann wundern, warum bei OSM alles anders heißt. Am besten sind deshalb Tags, die für beide verständlich sind.

Wird so einigermaßen deutlich, wie die Rollen den Nodes an einer Kreuzung zuzuordnen sind? Ich habe dafür ein paar Skizzen gebastelt.

https://wiki.openstreetmap.org/wiki/Pro … TMC_Points

Es geht im Moment ein wenig langsam voran, da ich momentan nicht viel Freizeit zur Verfügung habe... Das aktuelle Semester geht zu Ende, da ist alles etwas stressig, selbst wenn man nicht mehr zu den Studierenden gehört 😉

EDIT: Import-Skript für TMC-Punkte funktioniert (derzeit aber nur lokal auf meinem Rechner freigeschaltet, um versehentliche Uploads zu vermeiden).

Die Erklärungen in der Tabelle und die Zeichnungen sind gut verständlich - denke ich.
Irgendwie erschlägt einen beim ersten Blick die lange Erklärung aber ziemlich. Vielleicht eine Zeichnung einer komplexen Kreuzung nach oben und die restlichen Beispiele getrennt davon?
Wir sollten uns überlegen, ob die Rollen zwingend gefordert werden oder nur recommended sind - falls letzteres, dann sollte man das etwas kleiner darstellen.
Mit den Namen der Rollen kann ich mich nicht so recht anfreunden, die klingen mir etwas kompliziert. Der Unterschied zwischen posdir (in Richtung negativer Location) und posside (auf der Seite der positiven Location) ist zwar durch die TMC-Definitionen so gegeben, aber wird beim Mappen sicher für einiges Kopfzerbrechen sorgen.
Wie wäre es mit etwas wie from_pos, to_pos, from_neg, to_neg? Das sollte auch bei den anderen Varianten ähnlich machbar sein.

mueschel wrote:

Irgendwie erschlägt einen beim ersten Blick die lange Erklärung aber ziemlich. Vielleicht eine Zeichnung einer komplexen Kreuzung nach oben und die restlichen Beispiele getrennt davon?

Ja, das deckt sich mit meinem Eindruck. Ich denke, ich werde es genau so machen, dass man ein "typisches" Beispiel ganz oben hat, dass dann unten weiter erklärt wird.

Wir sollten uns überlegen, ob die Rollen zwingend gefordert werden oder nur recommended sind - falls letzteres, dann sollte man das etwas kleiner darstellen.

Ich würde sie entweder erforderlich machen oder ganz weglassen. Wenn man sie optional macht, hat man sie stellenweise getaggt und stellenweise nicht - davon hat man als Auswerter nicht viel. Ich bin mir nicht sicher, ob man sie wirklich braucht. Als Anwendung hatte ich mir gedacht, dass ein Router daraus ableiten kann, in welche Richtung er einen TMC-Punkt durchfährt, wenn er die benachbarten Punkte nicht durchfährt (z.B. weil er die Straße vorher an anderer Stelle verlässt).

Mit den Namen der Rollen kann ich mich nicht so recht anfreunden, die klingen mir etwas kompliziert. Der Unterschied zwischen posdir (in Richtung negativer Location) und posside (auf der Seite der positiven Location) ist zwar durch die TMC-Definitionen so gegeben, aber wird beim Mappen sicher für einiges Kopfzerbrechen sorgen.
Wie wäre es mit etwas wie from_pos, to_pos, from_neg, to_neg? Das sollte auch bei den anderen Varianten ähnlich machbar sein.

Ja, das stimmt leider, mit den aktuellen Rollen bin ich auch noch nicht wirklich zufrieden. Ich hatte auch ursprünglich eine ähnliche Idee, wie du hier vorschlägst, nur die Namen für das Zusammenlegen von Rollen, wenn es nur zwei Nodes sind, bereiten mir noch etwas Kopfzerbrechen. Normalerweise fallen ja immer zwei Nodes zusammen, die "nebeneinander" liegen, wenn man sich das Quadrat ABCD im Proposal ansieht. Deshalb hatte ich mir überlegt, dass jeweils nebeneinander liegende Nodes eine ähnliche Rolle bekommen könnten, damit man sie gut zusammenlegen kann.

MHohmann wrote:

Wir sollten uns überlegen, ob die Rollen zwingend gefordert werden oder nur recommended sind - falls letzteres, dann sollte man das etwas kleiner darstellen.

Ich würde sie entweder erforderlich machen oder ganz weglassen. Wenn man sie optional macht, hat man sie stellenweise getaggt und stellenweise nicht - davon hat man als Auswerter nicht viel. Ich bin mir nicht sicher, ob man sie wirklich braucht. Als Anwendung hatte ich mir gedacht, dass ein Router daraus ableiten kann, in welche Richtung er einen TMC-Punkt durchfährt, wenn er die benachbarten Punkte nicht durchfährt (z.B. weil er die Straße vorher an anderer Stelle verlässt).

Ich bin für weglassen! Denn die Dinge ergeben sich später aus den Links. Bis dahin hat der Router aber deutlich mehr Arbeit, weil er sich die Route berechnen müsste und dann die Richtung aus dem nächsten Punkt ableiten kann.

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?

Den TMC-Viewer habe ich auch etwas erweitert.

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:

http://manuelhohmann.dyndns.org/osm/tmc … &lcd=10509
http://manuelhohmann.dyndns.org/osm/tmc … &lcd=12342
http://manuelhohmann.dyndns.org/osm/tmc … &lcd=12358
http://manuelhohmann.dyndns.org/osm/tmc … &lcd=28381

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?

Hallo,

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. :+1:

MHohmann wrote:

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?

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…

couchmapper wrote:

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?

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.

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.

Sollte jetzt funktionieren.

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 weiter vorangeschritten und nimmt bereitwillig Verbesserungsvorschläge entgegen 😉

rayquaza wrote:

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…

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.

Christopher

Christopher wrote:

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.

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.

Da ich die LCL nicht genau kenne, kann es sein, dass es fälle gibt, in denen es kein Prev oder Next gibt?

Ja, am Anfang und Ende einer Straße.

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.

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 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.

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.

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.

Gute Idee. Wenn du etwas interessantes findest, lass es mich wissen 🙂

Wie soll man einen TMC-point taggen, der auf einen Kreisverkehr fällt?

Z.B. so:

http://www.openstreetmap.org/relation/3507087
http://www.openstreetmap.org/relation/3507088

http://manuelhohmann.dyndns.org/osm/tmc … &lcd=22793
http://manuelhohmann.dyndns.org/osm/tmc … &lcd=28350

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.

Hi MHohmann,

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.
- Fragezeichen in den Augen hatte ich bei aufwendigen Kreuzungen wie http://www.openstreetmap.org/relation/3513436 hier Kreuzt die L792 die L79. dabei gibt es 2 schnitt-punkte, wenn man von der einen auf die andere Straße abbiegen will. Hier habe ich wie auch bei http://www.openstreetmap.org/relation/3513432 die 2 Schnittpunkte der Straßen eingetragen.
- 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.

Christopher

Christopher wrote:

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

Super 🙂

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.

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.

- Fragezeichen in den Augen hatte ich bei aufwendigen Kreuzungen wie http://www.openstreetmap.org/relation/3513436 hier Kreuzt die L792 die L79. dabei gibt es 2 schnitt-punkte, wenn man von der einen auf die andere Straße abbiegen will. Hier habe ich wie auch bei http://www.openstreetmap.org/relation/3513432 die 2 Schnittpunkte der Straßen eingetragen.

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.

- 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

Sieht gut aus. Hier würden vielleicht die äußeren Punkte reichen, aber so macht es sicher Sinn, das würde ich so lassen.

Allgemein: Ich habe noch einige alte TMC-Punkte gefunden. Teilweise existieren sie als Relation auch auch direkt an den Nodes.

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.

Ü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.

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.

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.

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...

Die Statistik habe ich überarbeitet:

• Deutschland erledigt
• Deutschland offen
• Deutschland abweichend

MHohmann wrote:

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

[...] Die Links dazu gibt es nach Ländern aufgeteilt unten auf der TMC-Startseite

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.

KonB wrote:

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.

Das Beispiel packe ich auch noch ins Wiki.

Hallo,

ich bin durch keep right auf diese ehemalige TMC-Relation gestoßen.

http://www.openstreetmap.org/relation/1342152

Alle Tags wurden gelöscht.

Ich habe von TMC keine Ahnung, kann sich das einmal jemand anschauen?

Gruß
Rainer

Die Relation sollte wohl dieses TMC-Segment darstellen. Warum die Tags gelöscht wurden ist mir allerdings auch nicht ersichtlich.

MHohmann wrote:

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.

Vielleicht zum Verständnis der Sache:
Ja so habe ich das auch verstanden wie du, denn wenn man jetzt einen Unfall betrachtet ist es ja so, dass der TMC-Punkt der Unfall selbst ist, der Stau entwicklet sich ja in einer Richtung was durch den Extend der Meldung geschieht. Bei Verlängerung des Staus muss dann kein neuer Punkt "übermittelt", sondern nur der Extend erhöht werden. Im RDS-Programm RDS-Surveyor wird der Extend auch als growth (Wachstum) bezeichnet.
Der Extend beschreibt vom Prinzip her das Wachstum entgegen der Fahrtrichtung.

Wenn ich jetzt dein Beispiel betrachte ist es so das der Parkplatz Richtung Köln negativ ist. Wenn ich jetzt von diesem Punkt den Vorgängerpunkt ansehe, so sehe ich mir einen Punkt an, der vom Parkplatz aus in Richtung Frankfurt liegt. So hast du dein Parkplatz genau richtig eingetragen!

Es ist schon sehr verwirrend mit dem Positiv und Negativ, da muss man beim taggen tierisch aufpassen. Oder man muss hier noch irgendwelche Hilfen/Anzeigen mit Richtungspfeilen anbieten, sodass die Richtung z.B. in deiner Anwendung zu sehen wie sie zu taggen ist.

Christopher wrote:

Oder man muss hier noch irgendwelche Hilfen/Anzeigen mit Richtungspfeilen anbieten, sodass die Richtung z.B. in deiner Anwendung zu sehen wie sie zu taggen ist.

Ja, sehr gute Idee. Ich werde mal versuchen, sowas zu basteln. Das müsste man doch eigentlich hinbekommen...

Moin,

MHohmann wrote:

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):

ich habe mir mal die TMC-Punkte angeschaut, die ich damals beim Import eingetragen habe.
Die Informationen hatte ich damals so übernommen, wie sie von Sven Anders Tools angegeben wurden (ohne mir damals weitere Gedanken zu machen, wie es sein müsste)

Beispiel A 210, Anschlüsse Bredenbek (10604), Achterwehr (10605), Melsdorf (10606)
Die positive Richtung wurde damals für die Fahrtrichtung Rendsburg - Kiel (10604 - 10605 - 10606), die negative Richtung für die Fahrtrichtung Kiel -Rendsburg (10606 - 10605 - 10604) angegeben.

Die Angaben positiv/negativ bezogen sich auf die Erfassungsrichtung (ebenso wie Next- und PreviousLocationCode).
positiv, Next: in Erfassungsrichtung
negativ, Previous: entgegengesetzt der Erfassungsrichtung

Bei allen Angaben in der LocationCodeList bedeutet "POSITIV" in Erfassungsrichtung.
Warum das jetzt bei den Events genau andersherum kommt, ist mir etwas schleierhaft ...
Edit: Gefunden:

The␣'PN'␣bit␣(Positive/Negative)␣indicates␣the␣direction␣of␣queue␣events,
it's␣opposite␣to␣the␣road␣direction␣since␣it␣represent␣the␣direction␣of␣the
growth␣of␣a␣queue␣(or␣any␣directional␣event).

Tolle Logik ...
Ich wäre jetzt aber eher abgeneigt, diese Verdrehung in den OSM-TMC-Tags zu manifestieren, das gibt garantiert Kuddelmuddel.
Die Erfassungsrichtung der TMC-LocationCode-Daten ist eindeutig - insofern sollte der Begriff "positiv" in den OSM-TMC-Daten auch einheitlich auf diese angewendet werden.
Die Umsetzung der Events (positiv bedeutet negativ der Erfassungsrichtung) sollte man m. E. in der TMC-Software verstecken - denn damit hat ein Mapper ja so gar keine Berührungspunkte.

Gruß
Georg

Weil hier ein paar Mal der Bayerische Rundfunk genannt wurde:
Ja, wir nutzen das bisherige TMC Tagging auf Node-Basis. Es ist zwar nicht optimal, aber war bereits vor dem Start der BR-Verkehrskarte in Bayern recht anständig befüllt. Wir haben dann nach Möglichkeit die LCL-Änderungen auf Autobahnen und Bundesstraßen in Bayern nachgepflegt und kleinere Mapping-Fehler behoben. Auf dieser Basis läuft die Karte http://traffic.BR.de

Ich finde die Idee, das TMC Mapping zu erneuern gut, allerdings würde ich darum bitten, die alten Tags und Relationen noch eine ganze Weile drin zu lassen. Denn selbst wenn alle Punkte neu getagged sind, müssten wir noch unsere Anwendung inkl. Routing umschreiben und dafür müsste es erstmal ein neues Projekt inkl. Budget geben. Sprich eine Löschung der alten TMC-Tags in OSM würde einen baldigen Tod der interaktiven Verkehrskarte beim BR bedeuten.

Was das neue Proposal angeht: die LCL-Versionsnummern würde ich drin lassen. Die häufigste Änderung an TMC Locations ist, dass die Straßenverwaltung neue Zwischenpunkte einfügt, um Störungen präziser anzugeben. Wegen der Angabe von prev und next müssen dann immer vier alte Nodes angefasst werden. Das ist lästig, aber man sieht an der Versionsummer immer auf einen Blick, was schon aktuell ist.

Unsere größten Probleme bei der Umsetzung von TMC-Meldungen auf der Karte waren:
- Erkennung der "richtigen" OSM-Nodes zu einer TMC Location (diese sind ja richtungsabhängig und die Richtung in OSM und TMC Locationliste stimmen nicht überein).
- Finden der richtigen Abschnitte (also gerichtete Menge von OSM Nodes), also ein simples Routing entlang einer Straße. Das ginge viel leichter, wenn die TMC-Pärchen an den Ways vermerkt wären. Leider müsste man dazu aber viele Ways zerlegen, da die TMC-Node häufig nicht am Rand eines OSM-Ways liegen, sondern mittendrin.
- was auch schwierig ist, dass viele TMC-Locations nur in einer Richtung definiert sind. An manchen Stellen gibt es die im OSM-Modell nicht, an anderen Stellen existieren sie in der Gegenrichtung als "Phantom-Nodes"

Vielleicht lassen sich diese Dinge im neuen Modell vermeiden, was die Darstellung von TMC-Daten sehr vereinfachen würde.

Zunächst ein paar kleine Updates:

• Die Statistik hat jetzt ein User-Ranking - damit mal als Mapper auch seine Ergebnisse sieht 😉
• Eine Anzeige für ungültige TMC-Relationen gibt es jetzt auch. Dort wird angezeigt, welche TMC-Relationen es gibt, für die gar kein Punkt existiert. Aktuell ist das ein Punkt in München, der in Version 12.0 der LCL vorhanden war, aber nicht in 13.0 - den habe ich zu Testzwecken mal drin gelassen.
• Wenn man sich nun Straßen oder Punkte auf Straßen ansieht, zeigen Pfeile die Erfassungsrichtung (d.h. vom negativen zum positiven) Offset an. Allerdings können diese auch mal etwas von der tatsächlichen Straßenrichtung abweichen, weil in den Tabellen nur der jeweils vorherige und nächste Punkt eingetragen ist, nicht der Verlauf der Straße dazwischen.

GeorgFausB wrote:

Die Angaben positiv/negativ bezogen sich auf die Erfassungsrichtung (ebenso wie Next- und PreviousLocationCode).
positiv, Next: in Erfassungsrichtung
negativ, Previous: entgegengesetzt der Erfassungsrichtung

Gut, das bestätigt meine Vermutung. Wobei man vielleicht noch sagen könnte, dass sich positiv und negativ hier auf die Fahrtrichtung bezieht.

Bei allen Angaben in der LocationCodeList bedeutet "POSITIV" in Erfassungsrichtung.

Ich habe mir eben extra noch einmal die ISO 14819-3 vorgenommen - so ein Murks aber auch, du hast völlig Recht. Ich hatte gedacht, dass sich alle Angaben auf diese "umgedrehte" Richtung beziehen, also insbesondere auch ob ein Rastplatz auf der positiven / negativen Seite vorhanden ist. Das ist ja aber gar nicht der Fall, sondern es sind tatsächlich nur die Events und der Rest nicht! Siehe z.B. dieser Rastplatz - der ist als "auf der positiven Seite" eingetragen, und da fährt man in Erfassungsrichtung (dem roten Pfeil folgend). Also wer sich sowas ausdenkt...

Warum das jetzt bei den Events genau andersherum kommt, ist mir etwas schleierhaft ...
Edit: Gefunden:

The␣'PN'␣bit␣(Positive/Negative)␣indicates␣the␣direction␣of␣queue␣events,
it's␣opposite␣to␣the␣road␣direction␣since␣it␣represent␣the␣direction␣of␣the
growth␣of␣a␣queue␣(or␣any␣directional␣event).

Tolle Logik ...

Naja, ich fände sie toll, wenn das konsequent für alle Angaben so wäre (was ich bis heute dachte), aber so stimme ich dir zu.

Ich wäre jetzt aber eher abgeneigt, diese Verdrehung in den OSM-TMC-Tags zu manifestieren, das gibt garantiert Kuddelmuddel.
Die Erfassungsrichtung der TMC-LocationCode-Daten ist eindeutig - insofern sollte der Begriff "positiv" in den OSM-TMC-Daten auch einheitlich auf diese angewendet werden.
Die Umsetzung der Events (positiv bedeutet negativ der Erfassungsrichtung) sollte man m. E. in der TMC-Software verstecken - denn damit hat ein Mapper ja so gar keine Berührungspunkte.

Ja, das denke ich auch. Na gut, zum Glück ist bisher nur ein Parkplatz mit positive und negative getaggt, und im Wiki lässt sich das ja auch schnell umdrehen.

Allerdings stellt sich mir jetzt wieder genau diese Frage mit dem besagten gesperrten Parkplatz Weilbach. Ein Ereignis mit Richtung negative bedeutet ja nun, dass man in positiver Richtung fährt, also ist dann auch der positive Parkplatz gesperrt. Ja, na schön, dann muss man sich damit bei der Auswertung rumschlagen, aber nicht beim Mappen.

TrafficJam wrote:

Weil hier ein paar Mal der Bayerische Rundfunk genannt wurde:
Ja, wir nutzen das bisherige TMC Tagging auf Node-Basis. Es ist zwar nicht optimal, aber war bereits vor dem Start der BR-Verkehrskarte in Bayern recht anständig befüllt. Wir haben dann nach Möglichkeit die LCL-Änderungen auf Autobahnen und Bundesstraßen in Bayern nachgepflegt und kleinere Mapping-Fehler behoben. Auf dieser Basis läuft die Karte http://traffic.BR.de

Danke auf jeden Fall für die Rückmeldung!

Ich finde die Idee, das TMC Mapping zu erneuern gut, allerdings würde ich darum bitten, die alten Tags und Relationen noch eine ganze Weile drin zu lassen. Denn selbst wenn alle Punkte neu getagged sind, müssten wir noch unsere Anwendung inkl. Routing umschreiben und dafür müsste es erstmal ein neues Projekt inkl. Budget geben. Sprich eine Löschung der alten TMC-Tags in OSM würde einen baldigen Tod der interaktiven Verkehrskarte beim BR bedeuten.

Das sehe ich genau so, diese alten Daten sollen auf jeden Fall so lange drin bleiben, wie sie genutzt werden.

Was das neue Proposal angeht: die LCL-Versionsnummern würde ich drin lassen. Die häufigste Änderung an TMC Locations ist, dass die Straßenverwaltung neue Zwischenpunkte einfügt, um Störungen präziser anzugeben. Wegen der Angabe von prev und next müssen dann immer vier alte Nodes angefasst werden. Das ist lästig, aber man sieht an der Versionsummer immer auf einen Blick, was schon aktuell ist.

Das mit den vier alten Nodes sehe ich gerade nicht ganz... Welche Nodes müssen da angefasst werden und warum? Aber gut, wenn die Versionsnummern genutzt werden, dann spricht das natürlich dafür, sie ebenfalls zu taggen. Ich werde mal sehen, dass ich das Proposal und mein Tool entsprechend update.

Unsere größten Probleme bei der Umsetzung von TMC-Meldungen auf der Karte waren:
- Erkennung der "richtigen" OSM-Nodes zu einer TMC Location (diese sind ja richtungsabhängig und die Richtung in OSM und TMC Locationliste stimmen nicht überein).

Ist das genau diese Problematik mit dem positive / negative, das bei Events genau andersherum verläuft als in den Tabellen? Oder ist das noch ein weiteres Problem. Ach ja, apropos: Sollten die Nodes selbst auch eine Information tragen, auf welcher Richtungsfahrbahn sie liegen? So wie jetzt im Proposal gelistet ist das nämlich nicht der Fall, weil ich dachte, es wäre redundant.

- Finden der richtigen Abschnitte (also gerichtete Menge von OSM Nodes), also ein simples Routing entlang einer Straße. Das ginge viel leichter, wenn die TMC-Pärchen an den Ways vermerkt wären. Leider müsste man dazu aber viele Ways zerlegen, da die TMC-Node häufig nicht am Rand eines OSM-Ways liegen, sondern mittendrin.

Sehe ich auch so, genau das Argument hatte viw hier im Thread ebenfalls gebracht - dafür ist Stufe 2 des Proposals vorgesehen.

- was auch schwierig ist, dass viele TMC-Locations nur in einer Richtung definiert sind. An manchen Stellen gibt es die im OSM-Modell nicht, an anderen Stellen existieren sie in der Gegenrichtung als "Phantom-Nodes"

Auch das soll das Proposal klären. Es gibt ein Tag "present", das angibt, ob dieser TMC-Punkt nur in einer oder in beiden Richtungen vorhanden ist. "Phantom-Nodes" soll es nicht geben.

Vielleicht lassen sich diese Dinge im neuen Modell vermeiden, was die Darstellung von TMC-Daten sehr vereinfachen würde.

Schauen wir mal 🙂 Einiges müsste sich bestimmt machen lassen.

GeorgFausB wrote:

Die Angaben positiv/negativ bezogen sich auf die Erfassungsrichtung
positiv, Next: in Erfassungsrichtung
negativ, Previous: entgegengesetzt der Erfassungsrichtung

Ich habe mich daran gewöhnt, dass die TMC Events gegen die Fahrtrichtung laufen, denn dahinter steckt eine gewisse Logik: Oft die die Ursache einer Verkehrsstörung stationär (Unfall, Baustelle...) und damit wächst ein Stau entgegen der Fahrtrichtung an. D.h. der Locationcode im TMC-Event gibt die Position der Stauursache an und die Extents die Länge des Rückstaus.
Natürlich kann es auch mal passieren, dass bei der Erfassung in Dreher passiert und eine TMC Meldung falschrum kodiert ist. Aber auch in der TMC Locationlist gibt es immer wieder Fehler. Das ist halt das Schicksal von Menschen gepflegten System. Daher würde ich nicht zu viel Zeit auf einzelne Ausreißer verwenden.

MHohmann wrote:

Aber gut, wenn die Versionsnummern genutzt werden, dann spricht das natürlich dafür, sie ebenfalls zu taggen. Ich werde mal sehen, dass ich das Proposal und mein Tool entsprechend update.

Da die Versionsnummer zur Identifikation der richtigen LCL dient, würde ich sie der Einfachheit halber an das table-Attribut anhängen: table=58:1:13

TrafficJam wrote:

Die häufigste Änderung an TMC Locations ist, dass die Straßenverwaltung neue Zwischenpunkte einfügt, um Störungen präziser anzugeben. Wegen der Angabe von prev und next müssen dann immer vier alte Nodes angefasst werden. Das ist lästig, aber man sieht an der Versionsummer immer auf einen Blick, was schon aktuell ist.

MHohmann wrote:

Das mit den vier alten Nodes sehe ich gerade nicht ganz... Welche Nodes müssen da angefasst werden und warum?

Die Frage ist, wie redundant man den Straßenverlauf angeben möchte. Die LCL macht das ja an den Punkten fest, d.h. jeder Knoten kennt seinen Vorgänger und Nachfolger. Dein Proposal für TMC Nodes greift das auf, d.h. ich weiß (im Gegensatz zu OSM) allein durch Ansehen einer Knoteninformation nicht nur, dass er Teil einer Relation (Straße) ist, sondern wie er sich in das Umfeld einfügt. In OSM ist das ja die Aufgabe der Ways. Man kann nun entweder den Weg gehen, dass man diese Kontextinfo (prev/next) in jeden Knoten packt oder in die Ways oder in beides (wie im Proposal mit neg/pos_offset in TMC node sowie in TMC links). Für denjenigen, der TMC Events auf einer OSM-Karte darstellen will, ist das praktisch, aber für die Pflege der TMC-Infos in OSM ist es aufwändig, wenn die Info an mehreren Stellen aktualisiert werden muss.
Beispiel: Es wird auf einer Autobahn zwischen die Knoten 1234 und 7890 der Knoten 5555 eingefügt. Dann muss ich nicht nur den neuen Knoten 5555 anlegen, sondern in positiver Richtung beim 1234 einen neuen Nachfolger und in negativer Richtung einen neuen Vorgänger eintragen. Analog noch einmal bei 7890.

Unsere größten Probleme bei der Umsetzung von TMC-Meldungen auf der Karte waren:
- Erkennung der "richtigen" OSM-Nodes zu einer TMC Location (diese sind ja richtungsabhängig und die Richtung in OSM und TMC Locationliste stimmen nicht überein).

MHohmann wrote:

Ist das genau diese Problematik mit dem positive / negative, das bei Events genau andersherum verläuft als in den Tabellen? Oder ist das noch ein weiteres Problem. Ach ja, apropos: Sollten die Nodes selbst auch eine Information tragen, auf welcher Richtungsfahrbahn sie liegen? So wie jetzt im Proposal gelistet ist das nämlich nicht der Fall, weil ich dachte, es wäre redundant.

Mit der Richtung der Events hat das nur bedingt zu tun.
Bei der Darstellung eines TMC Events, z.B. der Sperrung einer AB-Anschlusstelle steht man ja vor folgender Herausforderung: Ich bekomme in der TMC-Meldung einen TMC Locationcode und eine Richtungsangabe und versuche diese einem OSM-Node zuzuordnen.
Im bisherigen TMC-Mapping suche ich dafür einen Node mit der richtigen TMC-Id und der gleichen Richtung (pos/neg).
Wie das Deinem Proposal - also ohne Kodierung der TMC Direction im Node - gehen soll, ist mir noch nicht ganz klar. Wie soll ich herausbekommen, welcher der beiden OSM-Nodes, die dem TMC-Punkt zugeordnet sind, ist der korrekte?

Noch eine grundsätzliche Frage zum Proposal:
Dieses packt relativ viele Informationen aus TMC hinein. Das ist zwar einerseits schön, weil man nicht immer in der TMC LCL nachsehen muss, aber für das reine Mapmatching sind diese Infos eigentlich nicht nötig. Beispielsweise braucht man die class (also den TMC type) und Referenzen auf andere Straßen nicht. Diese Infos sind in OSM zwar anders, aber auch vorhanden.
Die Frage, die sich mir stellt: kann man die ganzen TMC Infos weitgehend automatisiert importieren (und auch automatisiert jährlich bei neuen LCL-Versionen fortschreiben), dann kann man recht viele Attribute reinpacken. Oder will man sich auf das Nötigste für ein effizientes Map Matching beschränken und nimmt in Kauf, dass man die TMC LCL als Zweitreferenz braucht, wenn man Details zu den TMC-Infos braucht? Letzteres Vorgehen bietet sich an, wenn man hauptsächlich manuell pflegt.

TrafficJam wrote:

TrafficJam wrote:

Die häufigste Änderung an TMC Locations ist, dass die Straßenverwaltung neue Zwischenpunkte einfügt, um Störungen präziser anzugeben. Wegen der Angabe von prev und next müssen dann immer vier alte Nodes angefasst werden. Das ist lästig, aber man sieht an der Versionsummer immer auf einen Blick, was schon aktuell ist.

MHohmann wrote:

Das mit den vier alten Nodes sehe ich gerade nicht ganz... Welche Nodes müssen da angefasst werden und warum?

Die Frage ist, wie redundant man den Straßenverlauf angeben möchte. Die LCL macht das ja an den Punkten fest, d.h. jeder Knoten kennt seinen Vorgänger und Nachfolger. Dein Proposal für TMC Nodes greift das auf, d.h. ich weiß (im Gegensatz zu OSM) allein durch Ansehen einer Knoteninformation nicht nur, dass er Teil einer Relation (Straße) ist, sondern wie er sich in das Umfeld einfügt. In OSM ist das ja die Aufgabe der Ways. Man kann nun entweder den Weg gehen, dass man diese Kontextinfo (prev/next) in jeden Knoten packt oder in die Ways oder in beides (wie im Proposal mit neg/pos_offset in TMC node sowie in TMC links). Für denjenigen, der TMC Events auf einer OSM-Karte darstellen will, ist das praktisch, aber für die Pflege der TMC-Infos in OSM ist es aufwändig, wenn die Info an mehreren Stellen aktualisiert werden muss.
Beispiel: Es wird auf einer Autobahn zwischen die Knoten 1234 und 7890 der Knoten 5555 eingefügt. Dann muss ich nicht nur den neuen Knoten 5555 anlegen, sondern in positiver Richtung beim 1234 einen neuen Nachfolger und in negativer Richtung einen neuen Vorgänger eintragen. Analog noch einmal bei 7890.

Ich denke das es sinnvoller ist wenn die Links als Relationen von Wegen und von mir aus Start und Zielpunkt erfasst werden. Dann sucht sich der Auswerter nur die Relation 1234 nach 5555 und hat sofort die betroffenen Kanten in seinem Model.
Wenn ein neuer Knoten eingefügt wird dann wird die Relation kopiert und die überflüssigen wege werden gelöscht.
dann gibts weder positiv noch negativ noch doppelte Daten die inkonsitent sind.
An Auf- und Abfahrten macht man das ähnlich nur werden die Relationen anders benannt.

TrafficJam wrote:

Noch eine grundsätzliche Frage zum Proposal:
Dieses packt relativ viele Informationen aus TMC hinein. Das ist zwar einerseits schön, weil man nicht immer in der TMC LCL nachsehen muss, aber für das reine Mapmatching sind diese Infos eigentlich nicht nötig. Beispielsweise braucht man die class (also den TMC type) und Referenzen auf andere Straßen nicht. Diese Infos sind in OSM zwar anders, aber auch vorhanden.
Die Frage, die sich mir stellt: kann man die ganzen TMC Infos weitgehend automatisiert importieren (und auch automatisiert jährlich bei neuen LCL-Versionen fortschreiben), dann kann man recht viele Attribute reinpacken. Oder will man sich auf das Nötigste für ein effizientes Map Matching beschränken und nimmt in Kauf, dass man die TMC LCL als Zweitreferenz braucht, wenn man Details zu den TMC-Infos braucht? Letzteres Vorgehen bietet sich an, wenn man hauptsächlich manuell pflegt.

man kann sich streiten wieviele Informationen in OSM sinnvoll sind. Aber zum einen hat MHohmann dem Mapper mit seinen Tools schon viel Arbeit beim anlegen abgenommen und zum zweiten sollten wir über Deutschland hinaus schauen. Es war unter anderem auch ein Argument das diese Daten in anderen Ländern nicht so einfach zu beschaffen sind wie in Deutschland. Man sollte also im Sinne der Konsitenz und Verwendbarkeit auch an den rest von Europa/der Welt denken.

Hi MHohmann,

mit der Direction dachte ich wäre eindeutig, wenn ich mir jetzt aber dieses Beispiel ansehe: http://manuelhohmann.dyndns.org/osm/tmc … &lcd=33782
ist das aber irgendwie eigenartig. So hatten wir ja schon festgestellt, dass die Direction immer gegenläufig von Positiv-Offset ist. Bei diesem Beispiel ist ja im Osten Prev, im Westen Next. Damit ist die betroffene Fahrtrichtung bei Events mit Direction + in Richtung Osten. In dieser Richtung liegt ja auch der Parkplatz, allerdings ist in der LCL Postiv hinterlegt.

Übrigens zeigt der Pfeil auf deiner Webseite auf den Next-Point, demnach entgegen der Direction. (Lösung hierzu siehe Edit)

Des Weiteren habe ich noch einige Hinweise zu den Points. Und zwar sollte man vielleicht die Ways zwischen den Anfang und End-Nodes der Point-Relation mit aufnehmen, so ist eine Darstellung der Verkehrsbeeinträchtigung einfacher, denn es gibt durchaus komplizierte Kreuzungen. Hier sollten dann die Ways auch entsprechende Rollen bekommen, wenn hier getrennte Fahrspuren vorliegen.
Zum Thema Parkplatz auf Autobahnen: Auch hier sollte man vielleicht den Parkplatz für die Events wie "Carpark closed" usw. seperat erfassen. So wie du schon gemacht hast die Parkplatzfläche aber auch die Wege. In der Relation sollten diese gesondert mit einer Rolle aufgenommen werden, zusätzlich zur normalen Straße/Autobahn, da diese ja dann nicht davon betroffen ist, hier aber der Punkt liegt. Beispiel für Rollen:
Auf der Straße für Nodes+Ways: positiv / negativ
auf dem Parkplatz: parking:postiv / parking:negativ
so kann man unterscheiden zwischen den Events auf der Straße und dem Parkplatz

Denn die Extends aus einem Event laufen ja jeweils über die Points zum Parkplatz, nicht aber über die Parkplätze selbst, sondern über die dort vorbeiführende Straße. Übrigens wenn ein Parkplatz ausschliesslich auf der Gegenseite existiert, so existiert der Point doch auf beiden Seiten der Autobahn bzw. wird beim Extend berücksichtigt, hatte nämlich gerade so einen Fall.

Christopher

Edit:

Jetzt wo ich ein paar Minuten Ruhe finde ist mir das etwas klarer, auch das Posting von GeorgFausB macht da einiges Deutlich (habe ich vorhin übersehen):

Tolle Logik ...
Ich wäre jetzt aber eher abgeneigt, diese Verdrehung in den OSM-TMC-Tags zu manifestieren, das gibt garantiert Kuddelmuddel.
Die Erfassungsrichtung der TMC-LocationCode-Daten ist eindeutig - insofern sollte der Begriff "positiv" in den OSM-TMC-Daten auch einheitlich auf diese angewendet werden.
Die Umsetzung der Events (positiv bedeutet negativ der Erfassungsrichtung) sollte man m. E. in der TMC-Software verstecken - denn damit hat ein Mapper ja so gar keine Berührungspunkte.

Daher müsste man sich einigen wie man das in der Relation erfasst. Ich wäre jetzt dafür das so zu erfassen wie GeorgFausB, also nicht wie in deinem Beispiel sondern genau umgedreht, die Software müsste das dann selbstständig erkennen, dass es das umdrehen muss. Somit könnte man auch deine eingebauten Pfeile so nutzen wie sie da sind. Man sollte sich um die Hintergründe wirklich weniger Gedanken machen, das macht manchmal vieles einfacher.

TrafficJam wrote:

Da die Versionsnummer zur Identifikation der richtigen LCL dient, würde ich sie der Einfachheit halber an das table-Attribut anhängen: table=58:1:13

Das kann man natürlich auch machen. Ich hätte sie eher in ein eigenes Tag gepackt, version=13.0, weil dann alle TMC-Punkte einer Tabelle ein gemeinsames table-Tag haben, unabhängig von der Version. So kann man zuerst alle Punkte einer LCL zusammen abfragen und dann im zweiten Schritt die Version dieser Punkte testen. Aber vermutlich macht es keinen besonders großen Unterschied.

TrafficJam wrote:

Die Frage ist, wie redundant man den Straßenverlauf angeben möchte. Die LCL macht das ja an den Punkten fest, d.h. jeder Knoten kennt seinen Vorgänger und Nachfolger. Dein Proposal für TMC Nodes greift das auf, d.h. ich weiß (im Gegensatz zu OSM) allein durch Ansehen einer Knoteninformation nicht nur, dass er Teil einer Relation (Straße) ist, sondern wie er sich in das Umfeld einfügt. In OSM ist das ja die Aufgabe der Ways. Man kann nun entweder den Weg gehen, dass man diese Kontextinfo (prev/next) in jeden Knoten packt oder in die Ways oder in beides (wie im Proposal mit neg/pos_offset in TMC node sowie in TMC links). Für denjenigen, der TMC Events auf einer OSM-Karte darstellen will, ist das praktisch, aber für die Pflege der TMC-Infos in OSM ist es aufwändig, wenn die Info an mehreren Stellen aktualisiert werden muss.

viw wrote:

Ich denke das es sinnvoller ist wenn die Links als Relationen von Wegen und von mir aus Start und Zielpunkt erfasst werden. Dann sucht sich der Auswerter nur die Relation 1234 nach 5555 und hat sofort die betroffenen Kanten in seinem Model.
Wenn ein neuer Knoten eingefügt wird dann wird die Relation kopiert und die überflüssigen wege werden gelöscht.
dann gibts weder positiv noch negativ noch doppelte Daten die inkonsitent sind.
An Auf- und Abfahrten macht man das ähnlich nur werden die Relationen anders benannt.

Ich sehe das ähnlich wie viw, das ist nicht nur für eine Kartendarstellung hilfreich und sinnvoll, sondern auch für einen Router. Letztlich ist ja z.B. ein Stau ein lineares und kein punktförmiges Ereignis. Wenn man die Links erfasst, kann der Router den entsprechenden Straßenabschnitt im Routing herabstufen, wenn es dort einen Stau gibt. Ich hatte es nur deshalb etwas zurückgestellt, weil ich denke, dass das Mappen von Punkten einfacher ist, und dass man die Links später einfacher mappen kann, wenn man die Punkte hat. Aber gut, ein Link ist auch nicht schwerer zu mappen als eine Buslinie...

TrafficJam wrote:

Wie das Deinem Proposal - also ohne Kodierung der TMC Direction im Node - gehen soll, ist mir noch nicht ganz klar. Wie soll ich herausbekommen, welcher der beiden OSM-Nodes, die dem TMC-Punkt zugeordnet sind, ist der korrekte?

Das hatte ich tatsächlich erst in den TMC-Links vorgesehen, bzw. in einem etwas detaillierteren Mappen von Kreuzungen. Gerade z.B. bei einem Autobahnkreuz stelle ich es mir schwierig vor, herauszufinden, welcher Weg gesperrt ist - es sei denn, man mappt hier die Wege mit passenden Relationen. Letzteres hatte ich als "fortgeschrittene Ausbaustufe" gedacht, weil man sich dafür zunächst einmal ein passendes Tagging überlegen müsste.

Aber es stimmt natürlich, dass bei "einfachen" Ausfahrten die Information Sinn macht, auf welcher Seite der Autobahn ein Node liegt. Und da es ja offenbar genutzt wird, macht es natürlich Sinn, diese Information zu erfassen.

TrafficJam wrote:

Noch eine grundsätzliche Frage zum Proposal:
Dieses packt relativ viele Informationen aus TMC hinein. Das ist zwar einerseits schön, weil man nicht immer in der TMC LCL nachsehen muss, aber für das reine Mapmatching sind diese Infos eigentlich nicht nötig. Beispielsweise braucht man die class (also den TMC type) und Referenzen auf andere Straßen nicht. Diese Infos sind in OSM zwar anders, aber auch vorhanden.
Die Frage, die sich mir stellt: kann man die ganzen TMC Infos weitgehend automatisiert importieren (und auch automatisiert jährlich bei neuen LCL-Versionen fortschreiben), dann kann man recht viele Attribute reinpacken. Oder will man sich auf das Nötigste für ein effizientes Map Matching beschränken und nimmt in Kauf, dass man die TMC LCL als Zweitreferenz braucht, wenn man Details zu den TMC-Infos braucht? Letzteres Vorgehen bietet sich an, wenn man hauptsächlich manuell pflegt.

viw wrote:

man kann sich streiten wieviele Informationen in OSM sinnvoll sind. Aber zum einen hat MHohmann dem Mapper mit seinen Tools schon viel Arbeit beim anlegen abgenommen und zum zweiten sollten wir über Deutschland hinaus schauen. Es war unter anderem auch ein Argument das diese Daten in anderen Ländern nicht so einfach zu beschaffen sind wie in Deutschland. Man sollte also im Sinne der Konsitenz und Verwendbarkeit auch an den rest von Europa/der Welt denken.

Ich sehe es hier ähnlich wie viw. Zum einen sollte die Arbeit für den Mapper so weit wie nur möglich reduziert werden. Also sollte alles, was sich mittels maschineller Unterstützung machen lässt, auch so gemacht werden. Dazu gehört vor allem der Abgleich der gemappten Daten mit den LCLs und in Zukunft natürlich auch die Pflege der Daten, wenn ein neue Tabelle rauskommt. Zum anderen sollte natürlich auch dem Nutzer die Verwendung der Daten möglichst einfach gemacht werden. Wenn man die Daten zentral in OSM gebündelt hat, muss sich ein Anwender die Daten nicht für jedes Land einzeln zusammensuchen. Für Deutschland alleine ist das natürlich kein Problem, aber wenn man andere Länder anschaut, muss man zunächst einmal die zuständige Stelle finden und dann schauen, wie es dort überhaupt mit den Daten aussieht. Das kann man dem Anwender ersparen, wenn man für möglichst viele Länder die Daten so erfasst, dass er die LCL nicht mehr als Rohdaten braucht.

Christopher wrote:

mit der Direction dachte ich wäre eindeutig, wenn ich mir jetzt aber dieses Beispiel ansehe: http://manuelhohmann.dyndns.org/osm/tmc … &lcd=33782
ist das aber irgendwie eigenartig. So hatten wir ja schon festgestellt, dass die Direction immer gegenläufig von Positiv-Offset ist. Bei diesem Beispiel ist ja im Osten Prev, im Westen Next. Damit ist die betroffene Fahrtrichtung bei Events mit Direction + in Richtung Osten. In dieser Richtung liegt ja auch der Parkplatz, allerdings ist in der LCL Postiv hinterlegt.

Wenn du im letzten Satz "negativ" meintest, stimme ich damit überein 😉

Christopher wrote:

Übrigens zeigt der Pfeil auf deiner Webseite auf den Next-Point, demnach entgegen der Direction.

Richtig, das meinte ich mit "in der Erfassungsrichtung", d.h. von Prev nach Next.

Christopher wrote:

Des Weiteren habe ich noch einige Hinweise zu den Points, habe jetzt aber nicht genug zeit das auszufromulieren. Und zwar sollte man vielleicht die Ways zwischen den Nodes der Relation mit aufnehmen, so ist eine Darstellung der Verkehrsbeeinträchtigung einfache, denn es gibt durchaus komplizierte Kreuzungen.

Das hatte ich mir eigentlich "für später" überlegt, wenn man wirklich Kreuzungen mit den entsprechenden highway=*_link-Wegen im Detail erfassen möchte. Für sinnvoll halte ich es durchaus. Wenn es sich nur um den "durchgehenden" Weg handelt, kann man das aber auch durchaus in die tmc:point-Relation packen.

Christopher wrote:

Zum Thema Parkplatz auf Autobahnen: Auch hier sollte man vielleicht den Parkplatz für die Events "Carpark closed", ... seperat als Parkplatzfläche und die Wege in der Relation gesondert als rolle aufnehmen zusätzlich zur normalen Straße/Autobahn, da diese ja dann nicht davon betroffen ist, hier aber der Punkt liegt. Beispiel für Rollen:
Auf der Straße für Nodes+Ways: positiv / negativ
auf dem Parkplatz: parking:postiv / parking:negativ
so kann man unterscheiden zwischen den Events auf der Straße und dem parkplatz

Das könnte man wohl auch machen. An die Wege auf dem Parkplatz hatte ich bisher gar nicht gedacht, sondern nur an die Parkflächen und andere Einrichtungen. Für diese würde man dann keine Rollen brauchen, weil man ja am Objekt selbst sieht, was es ist - eben bei amenity=parking ein Parkplatz. Aber wenn man natürlich die Wege ebenfalls erfassen möchte, muss man diese durch passende Rollen unterscheiden.

Update: Bugfix im TMC-Viewer: Nun werden auch die Punkte auf einer Straße wieder in der Liste angezeigt.

Edit:

Christopher wrote:

Daher müsste man sich einigen wie man das in der Relation erfasst. Ich wäre jetzt dafür das so zu erfassen wie GeorgFausB, also nicht wie in deinem Beispiel sondern genau umgedreht, die Software müsste das dann selbstständig erkennen, dass es das umdrehen muss. Somit könnte man auch deine eingebauten Pfeile so nutzen wie sie da sind. Man sollte sich um die Hintergründe wirklich weniger Gedanken machen, das macht manchmal vieles einfacher.

Ja, sehe ich auch so. Ich ändere das im Proposal.

Ich habe gerade auch einmal ein paar Relationen eingetragen - das geht ja schon recht komfortabel.
Ein paar Fragen bleiben noch:

- die intersecting roads werden jetzt nicht erfasst? Wie erkenne ich in den Daten den Zusammenhang zwischen den (bei einer einfachen Kreuzung zwei) kreuzenden Straßen mit ihren eigenen Punkt-Relationen?

- Wie ist name=* gedacht? Soll da der exakte Name des TMC-Punktes stehen oder wie weit darf er abgewandelt werden um eine "logischere" oder präzisere Benennung zu erhalten?

Wollen wir uns irgendwo ein Gebiet herauspicken und dort mit vereinten Kräften versuchen, den TMC-Datensatz komplett zu erstellen? Dann kann man dort auch anfangen sich mit der Implementierung von Anwendungen zu befassen.

Heute Abend kam eine Mail aus Belgien von Technum, dem dortigen Vertreiber der TMC-Daten, dem ich eine Anfrage für die Verwendung der Daten in OSM geschickt hatte. Im Anhang der Mail: die belgische LCL, zur Verwendung in OSM 🙂

Belgien ist übrigens das erste Land in meiner Liste, das die Typen L7.0 und P4.0 benutzt, um einzelne highway=*_link zu erfassen. Ich frage mich, wie dazu eine TMC-Meldung aussieht und was man mit denen am besten macht...

mueschel wrote:

- die intersecting roads werden jetzt nicht erfasst? Wie erkenne ich in den Daten den Zusammenhang zwischen den (bei einer einfachen Kreuzung zwei) kreuzenden Straßen mit ihren eigenen Punkt-Relationen?

Hm... Für was sind die eigentlich gut? Ich sehe im Moment keinen wirklichen Anwendungsfall, daher hatte ich an sowas gar nicht gedacht. (Das soll natürlich nicht heißen, dass es keinen gibt.)

- Wie ist name=* gedacht? Soll da der exakte Name des TMC-Punktes stehen oder wie weit darf er abgewandelt werden um eine "logischere" oder präzisere Benennung zu erhalten?

In meinem Tool wird der Name derzeit einfach direkt aus der LCL übernommen bzw. mit dieser verglichen. Das heißt nicht, dass man es so machen muss... Ich habe da keine besonderen Präferenzen, was diesen Tag angeht. Wenn da mehr Freiheit zum Abwandeln gewünscht ist, lasse ich dem Relations-Checker da mehr Spielraum.

Wollen wir uns irgendwo ein Gebiet herauspicken und dort mit vereinten Kräften versuchen, den TMC-Datensatz komplett zu erstellen? Dann kann man dort auch anfangen sich mit der Implementierung von Anwendungen zu befassen.

Ja, das könnte man machen. Aber vielleicht sollte man vorher noch das Tagging so anpassen, wie von TrafficJam vorgeschlagen?

MHohmann wrote:

Ja, das könnte man machen. Aber vielleicht sollte man vorher noch das Tagging so anpassen, wie von TrafficJam vorgeschlagen?

Ich habe gerade den Überblick verloren - was war der Vorschlag, den ich übersehe?

MHohmann wrote:

mueschel wrote:

- die intersecting roads werden jetzt nicht erfasst? Wie erkenne ich in den Daten den Zusammenhang zwischen den (bei einer einfachen Kreuzung zwei) kreuzenden Straßen mit ihren eigenen Punkt-Relationen?

Hm... Für was sind die eigentlich gut? Ich sehe im Moment keinen wirklichen Anwendungsfall, daher hatte ich an sowas gar nicht gedacht.

Ich auch nicht - aber im Prinzip ist es sowas wie der gemeinsame Knoten bei sich schneidenden Wegen, der eine Verbindung von zwei Straßen im TMC-Netz darstellt.

Manuel, kannst du die Suchfunktion auf deiner TMC-Seite noch um die road-refs erweitern? Dann kann man einfach nach der B123 suchen. Und evtl. wäre case-insensitive ganz praktisch.

Edit:

MHohmann wrote:

In meinem Tool wird der Name derzeit einfach direkt aus der LCL übernommen bzw. mit dieser verglichen. Das heißt nicht, dass man es so machen muss...

Hier habe ich eine ganze Reihe von Kreuzungen, die alle den Namen "Vilbeler Landstraße" bekommen. Über den Roadname ließen sie sich eindeutig identifizieren, z.B. "Vilbeler Landstraße / Wilhelmshöher Straße" (36788)

Also, mal als Zusammenfassung was von Christopher und TrafficJam vorgeschlagen wurde:

• Statt nur zwei Punkte pro Richtung auf der Fahrbahn in die Relation aufzunehmen, könnte man das ganze Fahrbahnstück aufnehmen. Dann hat man zugleich den Fahrbahnverlauf drin und kann bei Meldungen wie "carriageway closed" genau diesen sperren bzw. auch auf der Karte darstellen.
• Zusätzlich könnte man die Zufahrten von Rastanlagen etc. erfassen. Dann müsste man durch Rollen klarstellen, welcher Weg Zufahrt ist und welcher Hauptfahrbahn.
• Durch Rollen könnte man anzeigen, auf welcher Seite / Richtungsfahrbahn ein Punkt / Wegstück liegt. Dann weiß man sofort, welches gesperrt ist. Diese Information ist übrigens auch im alten TMC-Tagging vorhanden.
• Die Versionsnummer der Tabelle könnte man mit aufnehmen, damit man bei einem Update leichter und schneller sieht, was schon aktuell ist und was noch nicht.

mueschel wrote:

Manuel, kannst du die Suchfunktion auf deiner TMC-Seite noch um die road-refs erweitern? Dann kann man einfach nach der B123 suchen.

Das kann ich mal in Angriff nehmen - allerdings sind die in anderen Feldern codiert. Aber mit ein wenig SQL-Magie geht das sicher.

mueschel wrote:

Und evtl. wäre case-insensitive ganz praktisch.

Das habe ich ehrlich gesagt schon versucht, aber so ganz will meine Datenbank das noch nicht... Mit MySQL habe ich bisher entweder einen "Textvergleich" bekommen, der dann case-insensitive ist, aber dann auch nicht mehr zwischen A, Ä etc. unterscheidet, oder wie jetzt einen "Binärvergleich", der dann aber auch case-sensitive ist...

MHohmann wrote:

Also, mal als Zusammenfassung was von Christopher und TrafficJam vorgeschlagen wurde:

• Statt nur zwei Punkte pro Richtung auf der Fahrbahn in die Relation aufzunehmen, könnte man das ganze Fahrbahnstück aufnehmen. Dann hat man zugleich den Fahrbahnverlauf drin und kann bei Meldungen wie "carriageway closed" genau diesen sperren bzw. auch auf der Karte darstellen.
• Zusätzlich könnte man die Zufahrten von Rastanlagen etc. erfassen. Dann müsste man durch Rollen klarstellen, welcher Weg Zufahrt ist und welcher Hauptfahrbahn.

...

Zu den Rollen habe ich mir mal ein paar gedanken gemacht, es gibt ja folgende Situationen:

• Einfache Landstraße mit nur einem Punkt: nur Node erfassen keine Rolle
• Landstraße mit auffauhrt zur Autobahn: 2 Nodes + Way zwischen ersten und letzen Auffahrt
• Bundsstraße 2-Spurig mit Abzweig auf 1-Spuriger Straße: 2 Nodes am Abzeig, Rolle entsprechend TMC positiv und negativ
• Autobahn an einer Auf-/Abfahrt: Erfassen der 4 Nodes, Auf-/Abfahrt-beginn je Richtung wie bisher, diese positv/negativ als Rolle zuweisen. Danach den Way zwischen Abfahrt und Auffahrt: auch die Rolle für die Richtung positiv / negativ wie bei den Nodes. Die Abfahrt als Way in die Relation aufnehmen, aber nur den Abschnitt der oneway=yes ist. Diesen je nach TMC-Richtung Rolle zuweisen: positiv:exit oder negativ:exit und das gleiche für die Auffahrten hier positiv:entry bzw. negativ:entry.
• Autobahn Rastplatz, nur aus 1 Richtung (Beispiel mit postiv) befahrbar/present: Nodes erfassen auf der Parkplatzseite wie bei Ausfahren mit der Rolle positiv sowie den Straßenabschnitt dazwischen. Auf der Gegenseite nur den Konten erfassen und mit negativ bezeichnen. Dann die Parkplatzstraße(n) sowie alle Einrichtungen und Flächen, die zum Parkplatz gehörden in die Relation packen und mit der Rolle positiv:parking markieren.
• mit Rastplatz auf beiden Seiten natürlich beide Seiten wie die positive erfassen.

Ist keine Rolle angegeben, so gelten die eingefügten Nodes und Ways für die Richtung positiv und negativ.
Die Rollenbezeichnung würde ich so herum wählen, da man schnell sieht was positiv und negativ ist. Andererseits kann man durch Angabe von postiv* alle Objekte in Positiver Richtung ermitteln was sicherlich auch für den Abruf in der Software schneller geht als *positiv.

Ich versuche mal je ein Beispiel für die Points zu mappen, wenn ich Zeit haben. Ich hoffe ich habe jetzt alle Situationen beschrieben die Auftreten können.

Einfache Landstraße mit nur einem Punkt: http://manuelhohmann.dyndns.org/osm/tmc … &lcd=34273
Einfache Landstraße mehrere Abbiegemöglichkieten: http://manuelhohmann.dyndns.org/osm/tmc … &lcd=34364
Landstraße mit Auffauhrt zur Autobahn/Kraftahrstraße: http://manuelhohmann.dyndns.org/osm/tmc … &lcd=34042
Bundsstraße 2-Spurig mit Abzweig auf 1-Spuriger Straße: http://manuelhohmann.dyndns.org/osm/tmc … &lcd=13230
Autobahn an einer Auf-/Abfahrt: http://manuelhohmann.dyndns.org/osm/tmc … &lcd=10200
Autobahn Rastplatz: http://manuelhohmann.dyndns.org/osm/tmc … &lcd=33782
Autobahnkreuz: http://manuelhohmann.dyndns.org/osm/tmc … &lcd=10201

Edit: Weiterer Beispiele:
Autobahndreieck: http://manuelhohmann.dyndns.org/osm/tmc … &lcd=10202

Beachte: auf der Seite von manuelhohmann ist die Darstellung durchaus noch nicht aktualisiert.

Zum Thema Anfangen in einer Region wäre es vielleicht so, dass man sich zuerst die Autobahnen vornimmt, da hier ja bekanntlich über die Systeme am meisten übertragen wird. Ich würde mich dann wenn ich lauft habe an den Berliner Ring/A10 wagen bzw. weiter machen.

Christopher

Im großen und ganzen finde ich diese Idee mit dem Mappen von Wegstücken ganz gut. Ein paar Anmerkungen / Ideen dazu:

• Wenn man ein Wegstück auf einer Fahrbahn oder Straße mappt, braucht man dann überhaupt noch dessen Endpunkte in der Relation? Die sollten doch jetzt eigentlich redundant, bzw. sogar überflüssig sein, würde ich denken. Das ist ja einfach der erste bzw. letzte Nodes des besagten Wegstückes.
• Bei den Auf- und Abfahrten hatte ich mir alternativ überlegt, die ähnlich die Links zu mappen - also als Wegstück von TMC-Punkt A zu TMC-Punkt B. Gerade bei einem Autobahnkreuz hat man ja mehrere solcher Verbindungswege, und es gibt durchaus TMC-Meldungen, in denen nur eine davon gesperrt bzw. betroffen ist. Das könnte man dann in etwa so taggen:

• type=tmc:ramp
• from_lcd=LCD von Punkt A
• to_lcd=LCD von Punkt B
• from_direction=Richtung des Fahrers auf Straße A vor dem Wechsel
• to_direction=Richtung des Fahrers auf Straße B nach dem Wechsel
• ordinal=Die wievielte Abfahrt an diesem Kreuz etc. ist das? (Wenn hier jemand einen besseren Key als "ordinal" hat, immer her damit - mir ist nichts besseres eingefallen als mich an ordinal number zu orientieren... Sinn dieses Tags ist es, Events wie "n-te Ausfahrt gesperrt" zu deuten.)

Damit hätte man dann auch die von mueschel vorgeschlagene Verbindung von Intersections: Zwei Punkte gehören dann zu einer Kreuzung / Intersection, wenn die zugehörigen TMC-Relationen einen gemeinsamen Node haben (einfache Kreuzung) oder durch eine TMC-Ramp verbunden sind (Autobahnkreuz, Ausfahrt etc.).
• Die Rollen sollten natürlich positive / negative heißen 😉

Ach ja, die Verzögerung auf meiner Seite kommt daher, dass ich die Relationen in der Kartenansicht derzeit von der Overpass-API abfrage, und da sind sie erst nach ein paar Minuten drin. So lange es relativ wenige Abfragen sind, sollte das unproblematisch sein, aber wenn es mehr werden sollten, muss ich wohl mit Extrakten und Diffs arbeiten, und dann weiß ich nicht, ob mein kleiner Server dafür ausreicht... Aber schauen wir erst einmal.

MHohmann wrote:

Wenn man ein Wegstück auf einer Fahrbahn oder Straße mappt, braucht man dann überhaupt noch dessen Endpunkte in der Relation? Die sollten doch jetzt eigentlich redundant, bzw. sogar überflüssig sein, würde ich denken. Das ist ja einfach der erste bzw. letzte Nodes des besagten Wegstückes.

Stimmt, die sind in dem Fall überflüssig.

MHohmann wrote:

Bei den Auf- und Abfahrten hatte ich mir alternativ überlegt, die ähnlich die Links zu mappen - also als Wegstück von TMC-Punkt A zu TMC-Punkt B. Gerade bei einem Autobahnkreuz hat man ja mehrere solcher Verbindungswege, und es gibt durchaus TMC-Meldungen, in denen nur eine davon gesperrt bzw. betroffen ist. Das könnte man dann in etwa so taggen:

• type=tmc:ramp
• from_lcd=LCD von Punkt A
• to_lcd=LCD von Punkt B
• from_direction=Richtung des Fahrers auf Straße A vor dem Wechsel
• to_direction=Richtung des Fahrers auf Straße B nach dem Wechsel
• ordinal=Die wievielte Abfahrt an diesem Kreuz etc. ist das? (Wenn hier jemand einen besseren Key als "ordinal" hat, immer her damit - mir ist nichts besseres eingefallen als mich an ordinal number zu orientieren... Sinn dieses Tags ist es, Events wie "n-te Ausfahrt gesperrt" zu deuten.)

Damit hätte man dann auch die von mueschel vorgeschlagene Verbindung von Intersections: Zwei Punkte gehören dann zu einer Kreuzung / Intersection, wenn die zugehörigen TMC-Relationen einen gemeinsamen Node haben (einfache Kreuzung) oder durch eine TMC-Ramp verbunden sind (Autobahnkreuz, Ausfahrt etc.).

Ja den Gedanken mit der ramp hatte ich am Anfang auch und habe diesen dann verworfen, weiß gar nicht mehr warum, habe mir bestimmt was aufgeschrieben/gezeichnet, ich suche mal.
Von der Sache her problemlos, denn wenn ich jetzt eine Ausfahrt habe, dann muss ich ja from_lcd mit passenden from_direction suchen. bei Auffahrten dann entsprechend to_*. Dann muss natürlich auch bei Ausfahrten der Autobahn die Straße im TMC sein, weiß nicht ob das überall so ist, aber ich würde mal sagen, dann kann die leer bleiben/entfallen.

Es gibt im TMC nämlich 2 Möglichkeiten soetwas anzugeben, habe ich gerade gefunden:

Location: 11915 (Autobahnkreuz A3/A6) extend 0 direction -
For destination: 10826
Events 201, 401: Unfall, geschlossen

bzw.

Location: 11154 (A4 Erfurt-West) extend 0 direction +
Events: 215, 1999: Unfall+stau, gefährlich Situation an der Einfahrt

MHohmann wrote:

Die Rollen sollten natürlich positive / negative heißen 😉

Aja Englisch ist nicht unbedingt meine Stärke. 😄

MHohmann wrote:

Ach ja, die Verzögerung auf meiner Seite kommt daher, dass ich die Relationen in der Kartenansicht derzeit von der Overpass-API abfrage, und da sind sie erst nach ein paar Minuten drin. So lange es relativ wenige Abfragen sind, sollte das unproblematisch sein, aber wenn es mehr werden sollten, muss ich wohl mit Extrakten und Diffs arbeiten, und dann weiß ich nicht, ob mein kleiner Server dafür ausreicht... Aber schauen wir erst einmal.

Schon klar, das das nicht komplett live möglich ist, war jetzt keine Kritik, nur ein Hinweis an die Leser.

Edit:

Da habe ich mein Beispiel:

Annahme Autobahnkreuz, als Kleeblatt bzw. die Abbildung von Wikipedia zeigt das ganze etwas: http://commons.wikimedia.org/wiki/File: … uteile.png
Wenn die Ways in tmc:ramp direkt von einem Point zum anderen in die Relation eingefügt wird, so sind der Einfahrts- und Aufahrtsbereich sowie Verteiler- und Verflechterfahrbahn doppelt in verschiedenen Relationen. Daher war meine Idee in tmc:ramp nur die Rampen (siehe Grafik) aufzunehmen und an den Points die Exit und Entrybereiche aufzunehmen.
Wenn jetzt die Applikation eine Meldung aufnimmt und den vollständigen Weg von einer zur anderen Straße sperrt, so könnten nicht betroffene Bereiche z.B. Einfahrt markiert werden, obwohl eine andere Richtung über die selbe Ausfahrt möglich wäre.

Edit #2:

An Autobahndreiecken, wo es diese Situation durchaus nicht gibt, wäre dann exit und entry der Points mit dem ramp gleichbedeutend.

Christopher wrote:

Von der Sache her problemlos, denn wenn ich jetzt eine Ausfahrt habe, dann muss ich ja from_lcd mit passenden from_direction suchen. bei Auffahrten dann entsprechend to_*. Dann muss natürlich auch bei Ausfahrten der Autobahn die Straße im TMC sein, weiß nicht ob das überall so ist, aber ich würde mal sagen, dann kann die leer bleiben/entfallen.

Stimmt, in dem Fall kann man die Tags einfach weglassen - oder man braucht sogar gar keine tmc:ramp, sondern kommt mit der Variante aus, wie von dir vorgeschlagen.

Christopher wrote:

Es gibt im TMC nämlich 2 Möglichkeiten soetwas anzugeben, habe ich gerade gefunden:

Location: 11915 (Autobahnkreuz A3/A6) extend 0 direction -
For destination: 10826
Events 201, 401: Unfall, geschlossen

bzw.

Location: 11154 (A4 Erfurt-West) extend 0 direction +
Events: 215, 1999: Unfall+stau, gefährlich Situation an der Einfahrt

Ich hätte da auch noch sowas anzubieten:

Event:␣407␣-␣(Q␣th)␣exit␣slip␣road␣closed
Location:␣11401
Direction:␣positive
Extent:␣0
Destination:␣23981
Stop␣time:␣243
Separator
Additional␣event:␣701␣-␣(Q␣sets␣of)␣roadworks
Supplementary␣information:␣4␣-␣diversion␣in␣operation

Event:␣406␣-␣(Q␣th)␣entry␣slip␣road␣closed
Location:␣23982
Direction:␣positive
Extent:␣0
Destination:␣11398
Stop␣time:␣243
Supplementary␣information:␣4␣-␣diversion␣in␣operation

Christopher wrote:

Schon klar, das das nicht komplett live möglich ist, war jetzt keine Kritik, nur ein Hinweis an die Leser.

Hatte ich auch nicht so aufgefasst, die Erklärung war auch nur als Hinweis gedacht 😉

Christopher wrote:

Annahme Autobahnkreuz, als Kleeblatt bzw. die Abbildung von Wikipedia zeigt das ganze etwas: http://commons.wikimedia.org/wiki/File: … uteile.png
Wenn die Ways in tmc:ramp direkt von einem Point zum anderen in die Relation eingefügt wird, so sind der Einfahrts- und Aufahrtsbereich sowie Verteiler- und Verflechterfahrbahn doppelt in verschiedenen Relationen. Daher war meine Idee in tmc:ramp nur die Rampen (siehe Grafik) aufzunehmen und an den Points die Exit und Entrybereiche aufzunehmen.
Wenn jetzt die Applikation eine Meldung aufnimmt und den vollständigen Weg von einer zur anderen Straße sperrt, so könnten nicht betroffene Bereiche z.B. Einfahrt markiert werden, obwohl eine andere Richtung über die selbe Ausfahrt möglich wäre.

Ja, gutes Beispiel, darüber hatte ich mir auch schon ein wenig den Kopf zerbrochen, also wo genau denn nun eine Ramp anfängt und aufhört... Das klingt so wie von dir vorgeschlagen eigentlich ganz schlüssig.

Christopher wrote:

An Autobahndreiecken, wo es diese Situation durchaus nicht gibt, wäre dann exit und entry der Points mit dem ramp gleichbedeutend.

Sehe ich auch so, wobei die Ramps dann zur durchgehenden Straße gehören müssten - aus Sicht der endenden Straße sind ja beide Ausfahrten z.B. positiv und beide Auffahrten negativ, weil die Straße dort in der anderen Richtung gar nicht existiert. So könnte man die Rampen also nicht unterscheiden. Aus der Sicht der durchgehenden Straße sind sie aber unterschiedlich.

MHohmann wrote:

Statt nur zwei Punkte pro Richtung auf der Fahrbahn in die Relation aufzunehmen, könnte man das ganze Fahrbahnstück aufnehmen.

Ach das. Ja, da bin ich dafür.

Christopher wrote:

MHohmann wrote:

Wenn man ein Wegstück auf einer Fahrbahn oder Straße mappt, braucht man dann überhaupt noch dessen Endpunkte in der Relation? Die sollten doch jetzt eigentlich redundant, bzw. sogar überflüssig sein, würde ich denken. Das ist ja einfach der erste bzw. letzte Nodes des besagten Wegstückes.

Stimmt, die sind in dem Fall überflüssig.

Ich würde sie trotzdem mappen: Einfach gemappte Points haben nur diese Punkte, die Wegstücke sind Zusatzinfo - dann aber etwas wegzuwerfen wenn diese Zusatzinfos gemappt werden halte ich für falsch.

Ein paar Neuigkeiten zum TMC-Viewer:

• Die Suche ist jetzt case-insensitive. (Warum bin ich nicht gleich auf die Idee gekommen, erst in Kleinbuchstaben zu konvertieren und dann zu vergleichen?)
• Neues Tag version=* eingebaut.
• Das Tag name=* wird jetzt zwar vorgeschlagen, aber später bei der Überprüfung ignoriert. Hier ist man also flexibel, was den Eintrag angeht. Auch name:lang=* wird bei der Überprüfung ignoriert.
• Von der spanischen Verkehrsbehörde habe ich die spanischen TMC-Codes zur Verwendung in OSM erhalten und in die Datenbank geladen 🙂 Bei denen sind übrigens alle Namen durchgehend groß geschrieben, allein schon deshalb sollte mehr Freiheit bei den name-Tags sinnvoll sein.

Suche nach Straßennummern ist in Arbeit. Ach ja, die Version 13.0 habe ich auch gleich mal an die bereits gemappten Relationen getaggt, jetzt zeigt der Viewer sie wieder als richtig an... Und an einem Prüfer für die Rollen bin ich auch dran.

Zum Glück ist langes Wochenende (Montag ist hier Feiertag, Jahrestag der Staatsgründung), aber ich habe trotzdem nicht das Gefühl, dass ich viel dazu kommen werde... Schauen wir mal.

Ich habe mich mal ran gemacht und nach meinen Vorstellungen ein Autobahnkreuz bzw. Autobahn+Kraftfahrstraße inkl. Rampen gemappt: http://www.openstreetmap.org/changeset/20717727
Hier habe ich an dem Point der Beiden Straßen die exit und entry-Fahrspuren, die alle Richtungen betreffen den positive/negative Richtungen zugewiesen. Hierzu die Rollen positive:exit und positve:entry bzw. als negative:* verwendet. Im nächsten Schritt alle Varianten der Überfahren von B101 zu A10 in je eine Rolle, danach von A10 auf B101, das macht dann 8 Relationen für die verschiedenen Überfahren, bei Autobahndreiecken wären es 4 Relationen. Die Überfahrten habe ich nur die Ways in die Relationen aufgenommen, die ausschließlich für die Überfahrt genutzt werden, nicht aber die Abschnitte die für mehrere Fahrtrichtungen verwendet werden.

Von der Sache her könnte man jetzt jede bisher erdenkliche Meldungen die die Überfahrten betreffen eindeutig markieren.
Wie ich beim Mappen mit bekommen habe wäre es aber sinnvoll, dann die Rampen entsprechend zu benennen, was ich jetzt nicht getan habe.

Eine weitere Idee, wie schon anfänglich diskutiert wäre die Erfassung der vollständigen Überfahrt von einer Straße auf die nächste. Was ich zuvor als nicht machbar bezeichnete würde ich jetzt nach reichlicher Überlegung gar nicht mal so so schlecht finden. Dafür werde ich mich jetzt mal an JOSM setzen und ein gleich aufgebautes Autobahnkreuz mappen. Wenn ich das fertig habe werde ich das Changeset hier posten und mit Begründung beschreiben. Dann können wir uns ja überlegen welche Variante wir nehmen.

Ich halte es für besser alle Daten und Rampen von einem TMC-Punkt in einer Relation zusammenzufassen. Wenn wir für jeden TMC-Punkt so viele Relationen anlegen müssen, wird das auf sehr wenig Gegenliebe bei anderen stoßen.
Mit passenden Rollen innerhalb einer Relation ist das sehr viel kompakter und weniger auffällig. Meine Vorstellung: Zusätzlich zu den schon beschlossenen Punkten, alle Wege einer Kreuzung in dieselbe Relation packen und mit entsprechenden Rollen versehen. Und zudem kann man auf einmal erkennen, was alles gemappt ist und was eventuell noch fehlt.

mueschel wrote:

Ich halte es für besser alle Daten und Rampen von einem TMC-Punkt in einer Relation zusammenzufassen. Wenn wir für jeden TMC-Punkt so viele Relationen anlegen müssen, wird das auf sehr wenig Gegenliebe bei anderen stoßen.
Mit passenden Rollen innerhalb einer Relation ist das sehr viel kompakter und weniger auffällig. Meine Vorstellung: Zusätzlich zu den schon beschlossenen Punkten, alle Wege einer Kreuzung in dieselbe Relation packen und mit entsprechenden Rollen versehen. Und zudem kann man auf einmal erkennen, was alles gemappt ist und was eventuell noch fehlt.

Ja, mir sind das auch recht viele Relationen und es ist aufwendig, aber alles in einer Relation packen ist auch recht schwer, da man in den Rollen die Ziele kodieren müsste.

wenn ich jetzt an einem TMC-Point 123 bin und die Kreuzende Straße 789 habe müsste ich die Straßen (Rampen) z.B. solche Rollen haben:

positive:exit:789:positive für die Überfahrt von Positiv nach positiv
bzw. positive:entry:789:negative für die Einfahrt von der Gegenrichtung
bzw. negative:exit:789 wenn es für alle Zielrichtungen ist.
oder negative:exit, wenn es keinen Zielstraße gibt, nur die Ausfahrt wie http://manuelhohmann.dyndns.org/osm/tmc … &lcd=57645

Probleme sehe ich, wenn sich ggf. mehr als 2 Straßen kreuzen (keine Ahnung ob es so etwas gibt, Könnte ich mir in Ballungszentren vorstellen), dann hätte man etliche Wege ggf. sogar doppelt mit verschiedenen Rollen drin. Das ist für Bearbeiter einer Straße noch komplizierter finde ich.

Christopher

So,

jetzt habe ich hier noch meine versprochene andere Variante: http://www.openstreetmap.org/changeset/20720679

Und zwar habe ich die Ways beider Richtungen wie gehabt nur mit positive und negative in die Relation aufgenommen. Im 2. Schritt habe ich wie zuvor die Rampen erfasst, allerdings die volle Strecke, von einem zum anderen Point. Jetzt habe ich die Rampen mal benannt, so sieht man besser von wo nach wo diese führen. Die Rollen *:exit und *:entry habe ich aus der tmc:point weg gelassen, da sie diese vollständig aus den tmc:ramp-Realtionen ermittelbar sind. So lassen sich die Exit-Ways mit Hilfe der Eigenschaften from_lcd und from_direction bzw. die Entry-Ways mit to_lcd und to_direction ermitteln.

Für die Ermittlung einer eindeutigen Sperrung der Wege, z.B. von A+ nach B-, muss zunächst die Relation form_lcd=A, from_direction=positive, to_lcd=B, to_direction=negative geladen werden. Im nächsten Schritt müsste für alle betroffenen Ways alle zugewiesenen tmc:ramp Relationen geladen werden. Gesperrt werden dürfen nur denjenigen Ways, die keiner weiteren tmc:ramp-Relation zugewiesen sind oder alle weiteren zugewiesenen Relationen sind auch als gesperrt gekennzeichnet.

Ich hoffe die Beschreibung ist einigermaßen verständlich. 🙄

Christopher

Es ist nicht notwendig, den to_lcd zu kennen, da dieser Code in keiner TMC-Meldung verwendet wird. Es gibt nur zwei Möglichkeiten: Entweder ist "die Ausfahrt" oder "die Einfahrt" gesperrt, oder es wird zusätzlich ein "direction"-Code angegeben. Dieser ist in der Regel der nächste durchfahrene Knoten.
D.h. diese Information wird nicht gebraucht und muss in den Rollen nicht aufgeführt werden.

Zunächst einmal die neuesten Änderungen am TMC-Viewer:

• Die Suchfunktion ist komplett überarbeitet. Allerdings kann man nach wie vor nicht nach "roadnumber" suchen - das hatte ich versucht, aber da ist zumindest bei meinen bisherigen versuchen die Performance eingebrochen. 20 Sekunden bei 100% CPU für die Suche nach einer Autobahn sind doch etwas viel. Ich versuche noch, da etwas zu basteln...
• Die Auswertung hat jetzt einen Rollenprüfer und zeigt damit fehlerhafte Rollen an - das sind derzeit solche, die nicht auf das Muster /^((positive|negative)(:[a-z]+)?)?$/ passen (übersetzt: die nicht entweder leer sind oder eine Richtung mit evtl. durch : abgetrennten Zusatz darstellen).

Die Beispiele mit den Rampen muss ich mir morgen mal in Ruhe ansehen. Grundsätzlich stimmt es schon, dass es ziemlich viele sind, wenn man jede einzelne als Relation mappt. Allerdings sehe ich die gleichen Probleme wie Christopher, wenn man sie stattdessen an die TMC-Punkte packen will: Zum einen verbindet eine Rampe immer zwei TMC-Punkte und kann daher nicht einem TMC-Punkt zugeordnet werden, zum anderen wird jede Rampe durch eine ganze Menge von Informationen gekennzeichet (from_lcd, from_direction, to_lcd, to_direction...), die man zwar durch : getrennt in Rollen packen könnte, was aber genau so unverständlich wäre wie das derzeitige Tagging.

Ich denke, man braucht durchaus alle Tags (from_lcd, from_direction, to_lcd, to_direction) für eine Rampe, um eine TMC-Meldung über deren Sperrung zu deuten. Angenommen, man hätte nur from_lcd, aber kein to_lcd - was macht man dann mit der Meldung "Einfahrt gesperrt", wenn nicht gemappt ist, welche Rampe in diesen Punkt einfährt? Aus dem gleichen Grund braucht man auch to_direction. Und selbst wenn eine Ausfahrt gesperrt ist, die durch Destination in der Meldung näher beschrieben ist, muss man doch wissen, wohin welche Rampe führt, damit man weiß, welche denn nun zu besagter Destination führt. Und da es auch die Meldung "n-te Ausfahrt gesperrt" gibt, braucht man an und für sich auch sowas wie das von mir vorgeschlagene "ordinal"...

EDIT: Ansonsten müsste man jede Rampe sowohl als exit als auch als entry in jeweils eine TMC-Punkt-Relation packen und damit jede Rampe doppelt mappen - was ich auch nicht optimal fände.

So ganz schlüssig, was man da am besten macht, bin ich mir da wirklich noch nicht...

Das wird nun aber wirklich sehr kompliziert. Was spricht denn dagegen, zunächst einmal einfach die entries und exits an sich zu erfassen, ohne die Information wohin sie führen. Damit hätten wir sicher 95% aller Rampen-bezogenen Meldungen abgedeckt. Die Möglichkeit "exit closed + destination" zu melden ließe sich von einem Router erkennen - wir wissen schließlich welche Strecke wir fahren wollen und durch welche Knoten sie hindurchfüht (auch der letzte gemappte Knoten des TMC-Punktes zu dem die Ausfahrt führt wird durchfahren!).
Die "n-te Ausfahrt gesperrt" stellt mich ohnehin vor Probleme - wie soll man das zählen, meistens gibt es ja Verzweigungen und die Ausfahrten fangen nicht alle getrennt an?

Es muss nicht alles in der OSM-DB vorhanden sein, es reicht wenn ein TMC-fähiger Router mit nicht zu großem Aufwand die passende Information berechnen kann. Keep it simple!

Updates:

• Der Auswerter erkennt jetzt neben "positive" und "negative" auch "both" als korrekt.
• Auf der Karte werden jetzt die Objekte mit einer neuen Farbcodierung dargestellt: grün sind TMC-Daten, rot sind Objekte mit Rolle positive(:...), blau sind Objekte mit Rolle negative(:...), magenta sind Objekte mit Rolle both(:...) oder leer, orange sind alle anderen Rollen / Fehler.

In Sachen Rampen ist mir gerade noch eine weitere Idee gekommen, wie man mit weniger Relationen auskommen könnte - und zwar mit einer Relation (zusätzlich zu den beiden TMC-Punkten) pro Kreuzung / Autobahnanschluss. Das funktioniert sogar, wenn sich dort mehr als zwei TMC-Punkte / Straßen treffen. Und so sehen die Tags dieser einen Relation aus:

• type=tmc:ramps
• table=cid:tabcd
• version=table version
• lcd:1 .. lcd:n=Location Codes der sich hier treffenden TMC-Punkte

Und so würden die Rollen aussehen:

• m:(positive|negative|both)-n:(positive|negative|both) - Dieses Teilstück wird durchfahren, wenn man vor der Kreuzung zum Punkt m in positiver / negativer / beliebiger Richtung unterwegs war und nach der Kreuzung vom Punkt n in positiver / negativer / beliebiger Richtung wegfährt.
• m:(positive|negative|both)- - Dieses Teilstück wird durchfahren, wenn man vor der Kreuzung zum Punkt m in positiver / negativer / beliebiger Richtung unterwegs war und es von dort aus mehrere Möglichkeiten zum Weiferfahren gibt.
• -n:(positive|negative|both) - Dieses Teilstück wird durchfahren, wenn man aus verschiedenen Richtungen kommend nach der Kreuzung vom Punkt n in positiver / negativer / beliebiger Richtung wegfährt.

Die Teilstück wären dabei in der "minimalistischen" Variante zu erfassen, wie Christopher sie in seinem ersten Beispiel hat. So sagt die Rolle für jedes Teilstück aus, wer sie durchfährt. Ich werde dazu mal ein Beispiel basteln.

EDIT: Beispiel siehe hier: http://www.openstreetmap.org/relation/3533117

mueschel wrote:

Die Möglichkeit "exit closed + destination" zu melden ließe sich von einem Router erkennen - wir wissen schließlich welche Strecke wir fahren wollen und durch welche Knoten sie hindurchfüht (auch der letzte gemappte Knoten des TMC-Punktes zu dem die Ausfahrt führt wird durchfahren!).

Ich denke hier vor allem an Nutzer wie den BR, die nicht routen wollen, sondern Meldungen auf einer Karte darstellen, ohne einen Router einzusetzen.

Die "n-te Ausfahrt gesperrt" stellt mich ohnehin vor Probleme - wie soll man das zählen, meistens gibt es ja Verzweigungen und die Ausfahrten fangen nicht alle getrennt an?

Da bin ich mir auch noch nicht im Klaren, man müsste sowas mal in der Praxis sehen...

• Der Tag-Prüfer ignoriert außer name jetzt auch road_name (sowie Sprachvarianten davon).
• Die OSM-Elemente kann man in der Karte jetzt auch anklicken und bekommt dann ihre ID als Link sowie die Rolle angezeigt. Außerdem sind Objekte mit Rollen, die ein ":" + Spezialisierung enthalten (wie positive:parking), jetzt farblich etwas abgesetzt. Etwas schneller laden sollten sie jetzt auch.

Ich habe mal ein wenig experimentiert und versucht, eine TMC-Meldung mittels der bereits gemappten Daten auszuwerten. So sieht das Ergebnis aus:

http://manuelhohmann.dyndns.org/osm/rdstmctest.html

Die Daten sind hier nicht live, das ist nur eine einmal gespeicherte Meldung, die dort gezeigt wird. Was man aber erkennen können sollte ist, dass aus den Rollen (positive, positive:parking) hier abgeleitet wird, was gesperrt ist und wo sich eine Baustelle befindet. Das lässt sich also problemlos auf einer Karte darstellen. Ich werde mal bei Gelegenheit versuchen, das auszubauen, allerdings habe ich selbst keine Live-TMC-Daten für eine Live-Demo aus eigener Quelle.

Hi,

du kannst ja mal den http://www.openrouteservice.org/ fragen, die haben TMC in ihren Daten drin. Woher die Daten sind und wie sie diese auf die Strassen mappen weiss ich allerdings nicht.

Christopher

Christopher wrote:

du kannst ja mal den http://www.openrouteservice.org/ fragen, die haben TMC in ihren Daten drin. Woher die Daten sind und wie sie diese auf die Strassen mappen weiss ich allerdings nicht.

Gute Idee, das wusste ich noch gar nicht. Das kann ich mal machen.

Übrigens, der Berliner Ring sieht schon ganz gut aus 😉 Ich habe mich mal der A 39 im Raum Wolfsburg zugewandt und zusätzlich zu den Points auch die Links dazwischen gemappt (sieht man jetzt auch im Viewer), nach dem etwas angepassten Proposal, als Test. Eigentlich braucht es ja keine separaten Relationen für die positive und negative Richtung, sondern man kann das einfach in die Rollen der Elemente packen.

Außerdem habe ich noch einen MapCSS-Stil für JOSM gebastelt, der TMC-Elemente mit positiver Rolle rot, mit negativer blau und ansonsten violett hinterlegt anzeigt.

Also, mueschel hatte ja schon vorgeschlagen, dass wir ja nun eigentlich das bestehende und inzwischen recht stabile Tagging nutzen könnten, um die TMC-Punkte in einer Gegend flächendeckend zu mappen und das sozusagen als Testgebiet zu nutzen. Die Idee finde ich ganz gut - fragt sich nur, wo man damit anfangen könnte / sollte. Am besten geeignet wäre natürlich eine Gegend, bei der jemand die passenden TMC-Meldungen empfängt 😉 Hessen käme daher wohl in Frage - aber Berlin wohl auch? Da bin ich sogar in 2 Wochen, für 5 Tage.

Für das leichtere Taggen von TMC-Links arbeite ich noch an einer Import-Hilfe für JOSM.

MHohmann wrote:

Übrigens, der Berliner Ring sieht schon ganz gut aus 😉

Danke, ich habe gleich die Fahrspuren korrigiert, daher bin ich da noch nicht ganz rum. Werde ich aber noch fertig stellen, Wenn das fertig ist mach ich dann die Links zwischen den Points.

MHohmann wrote:

Außerdem habe ich noch einen MapCSS-Stil für JOSM gebastelt, der TMC-Elemente mit positiver Rolle rot, mit negativer blau und ansonsten violett hinterlegt anzeigt.

Ja sieht gut aus, dann kann man auch schauen, ob alles dabei ist.

MHohmann wrote:

Also, mueschel hatte ja schon vorgeschlagen, dass wir ja nun eigentlich das bestehende und inzwischen recht stabile Tagging nutzen könnten, um die TMC-Punkte in einer Gegend flächendeckend zu mappen und das sozusagen als Testgebiet zu nutzen. Die Idee finde ich ganz gut - fragt sich nur, wo man damit anfangen könnte / sollte. Am besten geeignet wäre natürlich eine Gegend, bei der jemand die passenden TMC-Meldungen empfängt 😉 Hessen käme daher wohl in Frage - aber Berlin wohl auch? Da bin ich sogar in 2 Wochen, für 5 Tage..

Man könnte auch erst alle Autobahnen mappen, die werden weitestgehend von fast allen Stationen ausgesendet, wenn ich bei Berlin mein Navi anmache sehe ich auch Meldungen von Autobahnen, die am anderen Ende der Republik liegen. Aber eine Region wäre schon nicht schlecht, dann hat man auch die kleinen Straßen dabei. Bei dem verschlüsselten TMCpro soll das sehr gut sein mit den kleinen Straßen.

In 2 Wochen in Berlin? FOSSGIS denke ich mal. Dann kann man sich ja vielleicht treffen, ich werde auch vorbei schauen, wenn meine Abschlussarbeit dann soweit fast fertig ist.

Christopher

Christopher wrote:

Man könnte auch erst alle Autobahnen mappen, die werden weitestgehend von fast allen Stationen ausgesendet, wenn ich bei Berlin mein Navi anmache sehe ich auch Meldungen von Autobahnen, die am anderen Ende der Republik liegen.

Ja, gute Idee, die werden sicher auch am meisten genutzt.

In 2 Wochen in Berlin? FOSSGIS denke ich mal.

Leider nicht, sondern DPG-Frühjahrstagung 😉 Da bleibt für die FOSSGIS leider wenig Zeit...

Dann kann man sich ja vielleicht treffen, ich werde auch vorbei schauen, wenn meine Abschlussarbeit dann soweit fast fertig ist.

Wäre auf jeden Fall eine Idee, sich mal zusammenzusetzen für ein Brainstorming. Ich hatte dazu auch im Navit-Forum geschrieben, dass ich sicher etwas Zeit nach der Konferenz hätte - ein paar andere Leute aus dem Navit-Team sind auch vor Ort.

Im Laufe der Diskussion, gab es ja noch die Frage, ob man TMC-Knoten bei getrennten Richtungsfahrbahnen auch in der nicht-vorhandenen Richtung taggen sollte (also da, wo sie nicht "present" sind - also z.B. wenn auf der gegenüberliegenden Seite ein Parkplatz liegt).

Das ist sehr schwierig zu beantworten, denn das hängt ein wenig davon ab, in welcher Form man TMC-Eventdaten erhält:
Wenn man diese so erhält wie in RDS ausgestrahlt, also nur den Primary Node und die Extents, wäre es besser, wenn nur diejenigen getaggt wären, die auch wirklich present sind, denn dann könnte man sich einfach durch die Nodes hangeln und die Extends durchzählen (ohne irgendwelche andere Attribute auszuwerten).

Aber: Viele TMC-Quellen (z.B. die Exportformate der Verkehrsredaktionssysteme TIC und METAS) liefern nicht das Binärformat mit Extends, sondern Primary und Secondary Nodes (also von / bis). Dann stellt sich das Problem mit der Zählung von Extents nicht und zudem ist das Verfahren robuster gegen TMC-Versionsunterschiede (also wenn z.B. in einer neuen TMC-Locationliste ein neuer Zwischenpunkt eingefügt wird).

Wenn man nun die Locations auf Autobahnen einer Richtung weglassen müsse, die nicht "present" sind, stellt sich die Frage was man in den TMC-Knoten als neg_offset / pos_offset einträgt:
1. das was in der TMC-Liste steht
2. einen "korrigierten" Wert, der berücksichtigt, was auf dieser Fahrtrichtung die nächste / vorigen Location ist, die present ist.

Variante 2 geht mir zu weit weg von der TMC Locationlist und Variante 1 hat das Problem, dass die benachbarte Location (also die present ist) als vorige Location eine TMC Location Id trägt, die man niemals findet, wenn entgegen der TMC-Richtung (also in TMC-Eventrichtung der Extends) läuft.

Daher würde ich (wie Christopher auch schon schrieb), es so belassen, dass man die Locations auch in der Gegenrichtung tagged, obwohl sie nicht present sind. Dann kann man sich entlang der Fahrtrichtung (oder besser entgegen) mit den Offsets "durchhangeln" und muss nur beim Umgang mit Extents nur darauf achten, dass man dienjenigen nicht mitzählt, die nicht "present" sind.

Wenn Ihr das auch so seht, sollte man es noch im Proposal von MHohmann explizit erwähnen, dass die TMC Points auch in der Richtung getaggt werden sollten, in der sie nicht present sind.

TrafficJam wrote:

Im Laufe der Diskussion, gab es ja noch die Frage, ob man TMC-Knoten bei getrennten Richtungsfahrbahnen auch in der nicht-vorhandenen Richtung taggen sollte (also da, wo sie nicht "present" sind - also z.B. wenn auf der gegenüberliegenden Seite ein Parkplatz liegt).

...

Wenn man nun die Locations auf Autobahnen einer Richtung weglassen müsse, die nicht "present" sind, stellt sich die Frage was man in den TMC-Knoten als neg_offset / pos_offset einträgt:
1. das was in der TMC-Liste steht
2. einen "korrigierten" Wert, der berücksichtigt, was auf dieser Fahrtrichtung die nächste / vorigen Location ist, die present ist.

...

Daher würde ich (wie Christopher auch schon schrieb), es so belassen, dass man die Locations auch in der Gegenrichtung tagged, obwohl sie nicht present sind. Dann kann man sich entlang der Fahrtrichtung (oder besser entgegen) mit den Offsets "durchhangeln" und muss nur beim Umgang mit Extents nur darauf achten, dass man dienjenigen nicht mitzählt, die nicht "present" sind.

Wenn Ihr das auch so seht, sollte man es noch im Proposal von MHohmann explizit erwähnen, dass die TMC Points auch in der Richtung getaggt werden sollten, in der sie nicht present sind.

Ich glaube, dass du hier einem Irrtum unterliegst.
Die Bundes- und Landes-weiten Straßenverwaltungen representieren ihre Straßen noch abstrakter als es bei OSM eh schon der Fall ist. Sie benutzen eine Mittellinie auch bei getrennten Richtungsfahrbahnen. Von daher liegen die TMC-Location z.B. bei Autobahnen in der Regel zwischen den beiden Fahrbahnen. Wenn man in diesen Fällen in OSM also die TMC-Location in einer Richtung einträgt, so sollte man das immer auch für die Gegenrichtungen machen.

Dieses Verhalten ist auch einer der Gründe, warum TMC für Navis eine harte Nuss ist.

Edbert (EvanE)

TrafficJam wrote:

Im Laufe der Diskussion, gab es ja noch die Frage, ob man TMC-Knoten bei getrennten Richtungsfahrbahnen auch in der nicht-vorhandenen Richtung taggen sollte (also da, wo sie nicht "present" sind - also z.B. wenn auf der gegenüberliegenden Seite ein Parkplatz liegt).

Das ist sehr schwierig zu beantworten, denn das hängt ein wenig davon ab, in welcher Form man TMC-Eventdaten erhält:
Wenn man diese so erhält wie in RDS ausgestrahlt, also nur den Primary Node und die Extents, wäre es besser, wenn nur diejenigen getaggt wären, die auch wirklich present sind, denn dann könnte man sich einfach durch die Nodes hangeln und die Extends durchzählen (ohne irgendwelche andere Attribute auszuwerten).

[...]

Daher würde ich (wie Christopher auch schon schrieb), es so belassen, dass man die Locations auch in der Gegenrichtung tagged, obwohl sie nicht present sind. Dann kann man sich entlang der Fahrtrichtung (oder besser entgegen) mit den Offsets "durchhangeln" und muss nur beim Umgang mit Extents nur darauf achten, dass man dienjenigen nicht mitzählt, die nicht "present" sind.

Wenn Ihr das auch so seht, sollte man es noch im Proposal von MHohmann explizit erwähnen, dass die TMC Points auch in der Richtung getaggt werden sollten, in der sie nicht present sind.

Ich habe vor einiger Zeit mir einige Beispiele angesehen. Ich weiß jetzt nicht wo das mit dem weglassen der Points, wenn diese nicht present sind, steht. Hier wird ja nur eine Klasse wie Parkplatz festgelegt was dann bei Present ja soviel heißt dass der Parkplatz nur auf der einen Seite existiert.
Auf Radio MDR Jump hatte ich mir damals Beispiel in den TMC-Daten gesucht und mir diese ansehen. Man kann nämlich schöne mit deren Internetseite vergleichen, da habe ich 2/3 Beispiele gehabt, dort wurde der einseitige Parkplatz mit gezählt, das stimmte auch mit den Durchsagen im Radio so überein.

Ich habe den Berliner Ring mt Points versehen, dort sind wenn ich das jetzt noch richtig in Erinnerung habe fast alle Parkplätze einseitig, obwohl sie sich gegenüber liegen. Die heißen dann ...-Nord / -Süd bzw. Ost/West. Vielleicht finde ich ja mal ein Beispiel dann kann ich das hier reinstellen wo der Parkplatz mitgezählt wird

Christopher

Edit:

Sehr schönes Beispiel:

Location: 11867
Direction: negative
extend: 5 (bidirectional)
Personen auf der Fahrbahn.

Das ist die A6 zwischen Enkenbach-Alsenborn (17) und Wattenheim (18)

Zwischen den beiden Anschlüssen sind ausschliesslich Parkplätze die alle einen present haben. Auf der Staukarte von MDR JUMP (google) wird auch genau die Strecke zwischen den beiden Anschlussstellen angezeigt. Hier werden alle Points unabhängig vom present berücksichtigt.

Meldung auf der Seite:
A6 Kaiserslautern - Mannheim
Zwischen AS Enkenbach-Alsenborn und AS Wattenheim in beiden Richtungen Gefahr durch Personen auf der Fahrbahn

Na gut, schauen wir uns mal ein Beispiel von 3 TMC-Punkten A->B->C an, wobei B nur in positiver Richtung vorhanden ist. Wenn ich das richtig verstehe, wären die beiden Tagging-Varianten also folgende:

• Variante 1:

• lcd=A, pos_offset=B
• lcd=B, neg_offset=A, pos_offset=C
• lcd=C, neg_offset=B
• Variante 2:

• lcd=A, pos_offset=B
• lcd=B, pos_offset=C
• lcd=C, neg_offset=A

Für mich sieht 2 nach einer "kaputten" doppelt-verlinkten Liste aus. Ich würde hier ganz klar die 1 bevorzugen, zumal es so in den Location Code Lists drin ist und sich automatisch validieren lässt.

Das Problem bei 1 sehe ich nicht ganz. Nehmen wir mal an, es kommt eine Meldung rein mit Location = A, Extent = 2, Direction = Positive. Das ist also ein Ereignis, das sich von A aus in positiver Richtung bis C erstreckt und auf der negativen Seite vorhanden ist (wo B real nicht vorhanden ist). Wenn man nun nach dem Tagging 1 geht, hat man folgendes Vorgehen: Man findet eine tmc:point Relation mit lcd=A und pos_offset=B, dann eine mit lcd=B und pos_offset=C und schließlich eine mit lcd=C. Nun schaut man sich die weiteren Tags an. Die Relation zu B hat present=positive getaggt, also gibt es sie auf der nun relevanten, negativen Seite gar nicht. Beim Auswerten muss man sie also nicht weiter berücksichtigen. Man weiß also, dass die Meldung nur die tmc:point Relationen zu A und C betrifft (und die tmc:link Relationen mit neg_lcd=A, pos_lcd=B und mit neg_lcd=B, pos_lcd=C). Jetzt kann man diese Relationen nehmen und alle Elemente suchen, die die Rolle negative(:*) haben, und schon weiß man, dass diese betroffen sind.

Wenn eine Meldung mit Location "von A bis C" reinkommt, geht das Durchhangeln ganz genau so, nur ist das Abbruchkriterium dann nicht "gehe 2 Schritte weit", sondern "gehe bis C".

Dazu finde ich auch die Lösung von Christopher mit den Dummy-Nodes auf der gegenüberliegenden Fahrbahn gut, denn so hat man einen Anfangs- und Endpunkt für die dort liegenden TMC-Links.

Oder habe ich das falsch verstanden und eine Meldung, die sich auf A-C bezieht, würden in so einem Fall in TMC als Extent = 1 codiert werden? Das fände ich dann in der Tat sehr verwirrend... Ich kann es mir auch nicht vorstellen, denn im TMC-Standard heißt es in diesem Zusammenhang:

The extra attributes may be ignored on the receiver side. The use of 'illegal' combinations of locations and offsets is not allowed to the operator of the transmitter system, so messages that are broadcasted always are valid.

Mit "extra attributes" ist hier eben dieses present=positive und ähnliches gemeint. Es sollte also für den Auswerter egal sein, auf welcher Seite ein TMC-Punkt vorhanden ist. Das macht auch deshalb Sinn, weil in den Tables mancher Länder diese Information einfach fehlt (wobei wir sie in OSM aber trotzdem eintragen sollten).

Ich sehe das wie MHohmann und bin auch gegen eine "kaputte" doppelte Verlinkung (Var. 2).

MHohmann wrote:

Oder habe ich das falsch verstanden und eine Meldung, die sich auf A-C bezieht, würden in so einem Fall in TMC als Extent = 1 codiert werden?

Wenn die Quelle from A und to C angibt, gibt es kein Problem. Schwierig ist der Fall, wenn man nur Extent=1 erhält (als bei einer Quelle in binärer TMC-Kodierung).
Da scheint's vorgelwild zu sein. Manche Sender zählen wohl die Zwischenpunkt mit, die in der akt. Richtung nicht present sind (wie Christopher im Falle von MDR Jump schreibt) andere nicht.

Das TMC Compendium schreibt aber:

"The number of steps is the extent. The calculation is performed by following the Offset References, either in a positive or negative direction, starting at the primary location and going through to the secondary location. (Note: the number of steps from secondary to primary is not always identical to this number as there may be locations present for only one direction!)"

Das lese ich so, das eigentlich bei der Ermittlung der Extents diese Zwischenpunkte nicht mitgezählt werden sollten, oder?

EvanE wrote:

Die Bundes- und Landes-weiten Straßenverwaltungen representieren ihre Straßen noch abstrakter als es bei OSM eh schon der Fall ist. Sie benutzen eine Mittellinie auch bei getrennten Richtungsfahrbahnen. Von daher liegen die TMC-Location z.B. bei Autobahnen in der Regel zwischen den beiden Fahrbahnen. Wenn man in diesen Fällen in OSM also die TMC-Location in einer Richtung einträgt, so sollte man das immer auch für die Gegenrichtungen machen.

Das ist mir schon klar. In TMC gibt es nur einen Node, der beim Mapping auf OSM bei einer Autobahn auf (mind.) zwei OSM Nodes abgebildet wird. Diese liegen dann natürlich auf der jeweiligen Fahrbahn und haben ggf. leicht unterschiedliche TMC Tags, wenn man das Attribut present ansieht. Geanu für eine Eintragung auch auf der Gegenfahrbahn spreche ich mich ja auch aus. Es gab nur einen Beitrag, der solche "Phantomknoten" nicht wollte.

TrafficJam wrote:

Das lese ich so, das eigentlich bei der Ermittlung der Extents diese Zwischenpunkte nicht mitgezählt werden sollten, oder?

Nein, sie müssen mitgezählt werden. Sie befinden sich in der Kette von Punkten, und weil "extra attributes may be ignored" hat der Empfänger keine Möglicheit herauszufinden, dass er einen Punkt überspringen soll.

Der Punkt existiert als Knoten im TMC-Netz in beiden Richtungen, nur das zugeordnete Objekt (aka Parkplatz) existiert unter Umständen nicht in beiden Richtungen. Deswegen: Mappen in beiden Richtungen ist Pflicht und kann nicht wegdiskutiert werden.

TrafficJam wrote:

Da scheint's vorgelwild zu sein. Manche Sender zählen wohl die Zwischenpunkt mit, die in der akt. Richtung nicht present sind (wie Christopher im Falle von MDR Jump schreibt) andere nicht.

Na toll... Wie macht es denn der BR?

TrafficJam wrote:

Das TMC Compendium schreibt aber:

"The number of steps is the extent. The calculation is performed by following the Offset References, either in a positive or negative direction, starting at the primary location and going through to the secondary location. (Note: the number of steps from secondary to primary is not always identical to this number as there may be locations present for only one direction!)"

Das lese ich so, das eigentlich bei der Ermittlung der Extents diese Zwischenpunkte nicht mitgezählt werden sollten, oder?

Nach dem vierten Durchlesen des entsprechenden Abschnitts im TMC Compendium verstehe ich es auch so, dass die Anzahl der Schritte von A nach C i.A. nicht die Anzahl der Schritte von C nach A wäre - was dafür spräche, nur die Punkte zu zählen, die in der jeweiligen Richtung vorhanden sind. Das halte ich aber für völligen Murks und einen Fehler im TMC Compendium.

Hi ihr,

interessante Diskussion, mein Beispiel ist bidirectional negative. Das ist ja wieder ein Spezialfall. Weil die Fahrbahnen auf beiden Seiten betroffen sind. Das kann dann natürlich sein, dass dann alle berücksichtig werden. Es ist vielleicht so, dass nur bei monodirectional nicht alle Points mit entsprechendes present berücksichtigt werden. Ich suche nochmal ein Beispiel was monodirectional ist. Aber genau für dieses Beispiel ist es ja jetzt wichtig beide Richtungen zu haben, auch wenn es ohne möglich wäre. Aber warum nicht erfassen? Für die Software des Routings oder der Darstellung ist es doch schwieriger was nicht vorhandenes zu kompensieren als was vorhandenes zu ignorieren.

Christopher

Edit:

Beispiel:

Location: 11992
direction: negative
extend: 3 (monodirectional)

Hier sind zwischen 2 Anschlussstellen 2 gegenüberliegende Parkplätze, die einmal negative, einmal positiv in ihrem present sind. Demnach werden sie mit gezählt, egal welches Presnt, zumindets beim MDR. Ich kann das ja mal am Do/Fr. in der Region Berlin nachprüfen wie das da ist, da gibt's ja den RBB, die es warscheinlich auch so machen und aber noch mind. 1/2 private sender mit freeTMC.

Meldung von Jump:
Zwischen Kreuz Koblenz und AS Plaidt Wartungsarbeiten, 3 km Stau für LKW

Beim HR werden sie auch mitgezählt - hier gibt es zwei Meldungen für die Strecke zwischen Herborn-West und Dillenburg, eine pro Richtung:

d3␣68␣85␣42␣ea␣bd␣2c␣90
d3␣68␣85␣42␣58␣fd␣e9␣e7
d3␣68␣85␣42␣06␣a7␣e0␣00

Event:␣701␣-␣roadworks
Event:␣1851␣-␣temporary␣width␣limit␣6.3m
Urgency:␣normal
Road:␣7115␣-␣A45␣Gießen␣-␣Hagen
From:␣11406␣-␣26␣Herborn-West
To:␣11408␣-␣25␣Dillenburg
Extent:␣5
Stop␣time:␣end␣of␣November

A45 Gießen -> Hagen
Zwischen AS Herborn-West und AS Dillenburg Baustelle, vorübergehende Begrenzung der Breite auf 6,3 Meter bis 30.11.2014 13:00 Uhr

d3␣68␣85␣45␣aa␣c3␣2c␣8e
d3␣68␣85␣45␣68␣fd␣e9␣57
d3␣68␣85␣45␣1b␣d3␣ce␣d4
d3␣68␣85␣45␣0e␣80␣00␣00

Event:␣707␣-␣bridge␣maintenance␣work
Event:␣701␣-␣roadworks
Event:␣1851␣-␣temporary␣width␣limit␣5.8m
Urgency:␣normal
Road:␣7115␣-␣A45␣Hagen␣-␣Gießen
From:␣11408␣-␣25␣Dillenburg
To:␣11406␣-␣26␣Herborn-West
Extent:␣5
Stop␣time:␣end␣of␣November

A45 Hagen -> Gießen
Zwischen AS Dillenburg und AS Herborn-West Brückenarbeiten, Baustelle, vorübergehende Begrenzung der Breite auf 5,8 Meter bis 30.11.2014 13:00 Uhr

Beim Thema des mappings von Rampen haben wir ja inzwischen mehrere Vorschläge, aber sind wohl noch nicht zu einem wirklichen Ergebnis gekommen.

Manuels Vorschlag ( http://www.openstreetmap.org/relation/3533117 ) klingt gut für ein komplettes mapping. Ich weiß allerdings noch nicht, wie man die dort enthaltene Information wirklich nutzen kann in Verbindung mit üblichen Meldungen. Keines der Events sieht vor, dass die Location zu der eine Ausfahrt führt bzw. von der eine Einfahrt kommt genannt wird. Es wird immer nur eine Location und eventuell noch eine direction, in der Regel die nächste folgende Location in Fahrtrichtung, angegeben.
Außerdem sind sehr viele Locations mit Ein/Ausfahrten keine Verbindung zu einer anderen TMC-Location. Hier lässt sich das Schema zwar auch anwenden, aber es ist dann auch unnötig kompliziert (Eigene relation, komplizierte Namen der Rolle).

Würde es nicht in diesem einfachen Fall ohne eine vorhandene zweite Location Sinn machen, wie auch bei Parkplätzen mit Rollen direkt in der Punkt-Relation zu arbeiten? Ich würde die Rampen aufnehmen und mit den Rollen positive:exit, negative:exit, positive:entry und negative:entry versehen. Das spart Arbeit, sieht ordentlicher aus und enthält alle nötigen Informationen.

mueschel wrote:

Manuels Vorschlag ( http://www.openstreetmap.org/relation/3533117 ) klingt gut für ein komplettes mapping. Ich weiß allerdings noch nicht, wie man die dort enthaltene Information wirklich nutzen kann in Verbindung mit üblichen Meldungen. Keines der Events sieht vor, dass die Location zu der eine Ausfahrt führt bzw. von der eine Einfahrt kommt genannt wird. Es wird immer nur eine Location und eventuell noch eine direction, in der Regel die nächste folgende Location in Fahrtrichtung, angegeben.

Ich hatte mir dazu folgenden Algorithmus überlegt:

• Gegeben: Location (die betroffene Anschlussstelle), Direction (Fahrtrichtung positiv oder negativ bei besagter Location), Destination (Ziel-Location - wenn man diese ansteuert, ist die Meldung relevant).
• Finde die Straße, auf der die Destination liegt.
• Suche aus der tmc:ramps-Relation, die die Location enthält, den Punkt heraus, der auf der gleichen Straße liegt.
• Bestimme, ob die Destination von diesem gefundenen Punkt in positiver oder negativer Richtung liegt.
• Suche das Wegstück mit der passenden Rolle aus der tmc:ramps-Relation.

Mir ist nämlich aufgefallen, dass die angegebene Destination i.A. nicht einfach die nächste Location ist, sondern u.U. ziemlich weit weg sein kann - z.B. hier:

d3␣68␣85␣44␣c2␣bd␣2d␣07
d3␣68␣85␣44␣6b␣2d␣82␣8e
d3␣68␣85␣44␣1f␣e9␣e7␣6a
d3␣68␣85␣44␣04␣00␣00␣00

Event:␣701␣-␣roadworks
Event:␣1851␣-␣temporary␣width␣limit␣3.2m
Urgency:␣normal
Road:␣7124␣-␣A480␣Gießen␣-␣Reiskirchen
Location:␣11527␣-␣8␣Reiskirchener␣Dreieck
Extent:␣0
Destination:␣11650␣-␣1␣Hattenbacher␣Dreieck
Stop␣time:␣end␣of␣April

Deshalb macht es Sinn, die Ein- und Ausfahrten der jeweiligen Location zuzuordnen, zu der sie unmittelbar führen, sowie die Fahrtrichtung anzugeben, in die man dann einfährt bzw. aus der man ausfährt. Auf die Weise spielt es keine Rolle, welche Location genau als Destination angegeben wird. Das ganze ist auch Robust gegenüber dem Einfügen neuer Locations in die Liste bei einem Update, weil sich an der tmc:ramps-Relation dabei nichts ändert.

mueschel wrote:

Außerdem sind sehr viele Locations mit Ein/Ausfahrten keine Verbindung zu einer anderen TMC-Location. Hier lässt sich das Schema zwar auch anwenden, aber es ist dann auch unnötig kompliziert (Eigene relation, komplizierte Namen der Rolle).

Würde es nicht in diesem einfachen Fall ohne eine vorhandene zweite Location Sinn machen, wie auch bei Parkplätzen mit Rollen direkt in der Punkt-Relation zu arbeiten? Ich würde die Rampen aufnehmen und mit den Rollen positive:exit, negative:exit, positive:entry und negative:entry versehen. Das spart Arbeit, sieht ordentlicher aus und enthält alle nötigen Informationen.

Ja, das sehe ich ganz genau so. Mein Vorschlag war auch nur für komplexere Situationen gedacht, bei denen dieses einfachere Schema nicht ausreicht.

MHohmann wrote:

TrafficJam wrote:

wrote:
Da scheint's vogelwild zu sein. Manche Sender zählen wohl die Zwischenpunkte mit, die in der akt. Richtung nicht present sind (wie Christopher im Falle von MDR Jump schreibt) andere nicht.

Na toll... Wie macht es denn der BR?

Gute Nachrichten: Auch der BR zählt diese Locations bei der Extentermittlung mit. Das ergab eine Rückfrage bei der Verkehrsmeldestelle Bayern. Das gilt auch generell, nicht nur in Bayern. Zum Glück, das macht es einfach - sorry für die von mir geschaffene Verunsicherung. Es scheint also tatsächlich Fehler im TMC Compendium zu sein.

Was ich mich aber im Proposal immer noch frage:
Ist eine Angabe von present=positive bzw. present=negative im TMC Point wirklich sinnvoll?
Wenn ich mir nämlich die TMC Metadaten eines der entsprechenden OSM-Nodes ansehe, kann ich ihm ja leider nicht auf einen Blick ansehen, ob dieser nun auf der (aus TMC-Denke) positiven oder negativen Richtung liegt (sondern müsste mich dazu erst zum nächsten oder vorigen durchhandeln).
Wäre es daher nicht besser, das present-Feld wie im alten TMC-Mapping mit true/false/both belegen? Dann erkenne ich sofort im Node, ob er an dieser Stelle und in dieser Fahrtrichtung vorhanden ist.

TrafficJam wrote:

Gute Nachrichten: Auch der BR zählt diese Locations bei der Extentermittlung mit. Das ergab eine Rückfrage bei der Verkehrsmeldestelle Bayern. Das gilt auch generell, nicht nur in Bayern. Zum Glück, das macht es einfach - sorry für die von mir geschaffene Verunsicherung. Es scheint also tatsächlich Fehler im TMC Compendium zu sein.

Gut zu wissen 🙂

TrafficJam wrote:

Was ich mich aber im Proposal immer noch frage:
Ist eine Angabe von present=positive bzw. present=negative im TMC Point wirklich sinnvoll?
Wenn ich mir nämlich die TMC Metadaten eines der entsprechenden OSM-Nodes ansehe, kann ich ihm ja leider nicht auf einen Blick ansehen, ob dieser nun auf der (aus TMC-Denke) positiven oder negativen Richtung liegt (sondern müsste mich dazu erst zum nächsten oder vorigen durchhandeln).
Wäre es daher nicht besser, das present-Feld wie im alten TMC-Mapping mit true/false/both belegen? Dann erkenne ich sofort im Node, ob er an dieser Stelle und in dieser Fahrtrichtung vorhanden ist.

Hm... Den Einwand verstehe ich nicht ganz... Vielleicht gibt es hier noch ein Missverständnis bei den TMC-Daten? Was genau sollte true/false/both aussagen, das negative/positive nicht aussagt?

Die doppelt verlinkte Liste der TMC-Punkte mittels neg_off_lcd und pos_off_lcd in den originalen TMC-Daten ist unabhängig davon, auf welcher Seite ein Punkt vorhanden ist. Auch ein Punkt, der nur auf einer Seite vorhanden ist, ist immer in dieser Liste vorhanden, egal in welcher Richtung man sie nun abgeht. Ebenso ist es auch im vorgeschlagenen OSM-Tagging, wo pos_offset und neg_offset genau diese komplette doppelt verlinkte Liste abbilden.

Manuel, kannst du in deinen TMC-Viewer noch eine kleine Verbesserung einbauen? Wenn zu einem Punkt eine Relation gefunden wird, kannst du ihn dann in einer anderen Farbe darstellen, vielleicht ein Ring ohne Füllung? Dann sieht man wo noch etwas zu machen ist und erkennt auch, wenn mehrere Punkte übereinander liegen.
Ansonsten lohnt es sich auch, immer mal einen Blick in die Area-Locations zu werfen - da gibt es doch einige enthaltene Punkte ohne Koordinaten, z.B. die Parkhäuser in Frankfurt.

So in etwa? 😉

Ach ja, dabei ist mir bei deinen Punkten gerade aufgefallen ist, dass die Nodes auf der Straße keine Rollen haben (und deshalb pink sind). Wir hatten uns irgendwo hier im Thread überlegt, bei Straßen mit getrennten Richtungsfahrbahnen auch diesen Nodes die Rollen "positive" und "negative" zu geben, um zu unterscheiden, auf welcher Seite sie liegen, auch wenn man keinen Router benutzt. Das habe ich im Wiki noch nicht dokumentiert, sorry. Wäre super, wenn du das noch einbauen könntest, so wie hier. Gute Arbeit auf jeden Fall, sieht schon sehr schön aus 🙂

Vielleicht gibt es hier noch ein Missverständnis bei den TMC-Daten? Was genau sollte true/false/both aussagen, das negative/positive nicht aussagt?

Ganz einfach der Bezug zur aktuellen Richtung. Es wird ja z.B. eine TMC Location auf zwei OSM Nodes abgebildet. Daher kann in der TMC Locationlist nur abstrakt drinstehen, den Parkplatz gibt es nur in positiver Richtung. In den OSM Points habe ich aber den direkten Bezug, auf welcher der beiden Richtungen sich der aktuelle Node gerade befinder. Wenn ich nun beim einem der beiden OSM Nodes present=true stehen habe und in der Gegenrichtung present=false, sehe ich auf einen Blick, ob die Location (der Parkplatz) in dieser Richtung nun da ist oder nicht - ohne erst indirekt ermitteln zum müssen, ob sich der OSM Node auf der positiven oder negativen TMC-Richtung befindet.

Eine noch bessere Alternative wäre ein weiteres Attribut direction einzufügen (postive/negative/both), dann hätte ich auch alle nötigen Informationen an einer Stelle. Wenn ich also einen TMC Event darstellen möchte, der an der TMC Location x einen Unfall in positiver Fahrtrichtung beinhaltet, hole ich mir die OSM-Nodes zu lcd=x. Dann erhalte ich zwei Ergebnisse und muss entscheiden, welcher Node der in postiver Richtung ist. Wenn dies direkt in den Attributen steht, fällt mir das natürlich leichter als wenn ich benachbarte Nodes (oder Ways) auswerten muss, um die Richtung zu erkennen.

Ah, aber das sollte im vorgeschlagenen Taggingschema doch möglich sein, oder nicht? Also angenommen ich habe einen Location Code und möchte ermitteln, welche Elemente davon vorhanden sind, dann gehe ich folgendermaßen vor:

• Suche die zugehörige tmc:point Relation, die den entsprechenden Location Code als lcd hat.
• Lese das Tag present=* dieser Relation aus um zu ermitteln, auf welcher Seite die Location vorhanden ist.
• Lese die Member dieser Relation inkl. ihrer Rollen aus. Wenn die Rolle z.B. "positive" (oder "positive:parking" etc.) ist, ist das Objekt auf der positiven Seite (das entspricht dem von dir vorgeschlagen direction). Ein Vergleich mit dem bereits ausgelesenen present=* der Relation sagt dann, ob hier wirklich etwas vorhanden ist, oder ob das nur ein Dummy-Node ist.

Der Unterschied zu deinem Vorschlag ist im wesentlichen, dass nach dem von mir ausgearbeiteten Tagging-Schema an den OSM Nodes gar keine TMC-Tags sitzen, also kann dort auch kein present=*, direction=* untergebracht werden. Stattdessen steckt die komplette Information in der tmc:point Relation. (Auf die Weise sind die TMC-Information sauber von anderen OSM-Daten getrennt.) In dieser Relation kann man den einzelnen Elementen, also Nodes und Ways, nur eine Rolle (also einen einzelnen String) zuweisen. Und für diese Rollen hatte ich mir genau das überlegt, was du als direction vorschlägst. Ich sollte das auch noch im Wiki dokumentieren...

Siehe dazu auch dieses Beispiel. Wie man an den verschiedenen Farben sieht, kann der Auswerter hier nicht nur unterscheiden, auf welcher Seite ein Objekt liegt, sondern auch, ob es z.B. zum Parkplatz oder zur Hauptfahrbahn gehört. Ein Klick auf die farbigen Elemente zeigt ihre Rollen und die Zugehörigkeit zu den Relationen an.

MHohmann wrote:

Ach ja, dabei ist mir bei deinen Punkten gerade aufgefallen ist, dass die Nodes auf der Straße keine Rollen haben (und deshalb pink sind).

Ja klar, mache ich. Zuerst wollte ich mal sehen, wo es Probleme geben könnte in der Stadt. Zum Einen gibt es recht merkwürdige Kreuzungen ( http://manuelhohmann.dyndns.org/osm/tmc … &lcd=36882 ), und dann auch Ampelkreuzungen wo gar keine Kreuzung ist oder falsche Straßennamen an Knoten.

Deine Änderung sieht gut aus - und gerade bei Autobahnenabfahrten ist es sehr schön, dort sind jetzt jeweils zwei Knoten mit der Nummer der Abfahrt im Kreis versehen :-) .

Solche Problemstellen sind mir auch entlang der A39 in Höhe Braunschweig aufgefallen. Dort sind z.B. die Abfahrt BS-Rüningen-Nord und das Dreieck Braunschweig-Südwest regelrecht verschlungen, da sind die Rampen untereinander verbunden. Ähnlich sieht es aus bei Kreuz Braunschweig-Süd, Heidbergtunnel und Braunschweig-Südstadt. Das so zu mappen, dass ein Router keinen TMC-Punkt verpasst und alle beim Routing berücksichtigt, ist schon eine vertrackte Angelegenheit.

Neue Features im TMC Viewer:

• In der TMC Punkt Ansicht werden jetzt auch die Tags der tmc:link Relationen angezeigt und können in JOSM geladen bzw. importiert werden, z.B. hier.
• Für tmc:link Relationen gibt es jetzt einen Statistik-Report mit Überprüfung von Tags und Rollen.

Die vorhandenen Frankfurter points sollten jetzt auch fast alle ihre Rolle gefunden haben. Und schon wieder habe ich zwei Verbesserungsvorschläge :-)
Wenn an einem Punkt zwei tmc:points liegen, dann habe ich nur Zugriff auf einen der Punkte und keine Möglichkeit den zweiten zu bekommen. Da könnte man in der Liste mit Infos noch einen Punkt einfügen "Other TMC Points at this location: #1, #2".
Ein weiterer Punkt: Wenn ich auf ein OSM-Objekt klicke, dann bekomme ich einen Link zum Objekt und einen zur Relation. Kannst du auch noch einen Link zum TMC-Punkt einfügen?

mueschel wrote:

Die vorhandenen Frankfurter points sollten jetzt auch fast alle ihre Rolle gefunden haben.

Super 🙂

mueschel wrote:

Wenn an einem Punkt zwei tmc:points liegen, dann habe ich nur Zugriff auf einen der Punkte und keine Möglichkeit den zweiten zu bekommen. Da könnte man in der Liste mit Infos noch einen Punkt einfügen "Other TMC Points at this location: #1, #2".

Done. So langsam wird die Liste ziemlich lang 😉

mueschel wrote:

Ein weiterer Punkt: Wenn ich auf ein OSM-Objekt klicke, dann bekomme ich einen Link zum Objekt und einen zur Relation. Kannst du auch noch einen Link zum TMC-Punkt einfügen?

Done. Das gleiche habe ich auch gleich für die pos_lcd und neg_lcd der tmc:link Relationen gemacht.

Ich habe mir noch ein wenig Gedanken darüber gemacht, welche Rollen man den tmc:point Membern geben könnte, die angeben, um welche Art von Objekt es sich handelt. Wir haben ja schon sowas wie positive:exit, negative:entry etc. in Gebrauch. Spontan bin ich dabei auf diese Liste gekommen, da alle diese Objekte in TMC-Meldungen vorkommen können (weil sie z.B. geschlossen sind):

• *:entry - Einfahrt in die Straße, zu der dieser TMC-Punkt gehört.
• *:exit - Ausfahrt aus der Straße, zu der dieser TMC-Punkt gehört.
• *:ramp - Bidirektionale Ein- und Ausfahrt der Straße, zu der dieser TMC-Punkt gehört. Beispiel.
• *:parking - Parkplatz (analog zu amenity=parking).
• *:fuel - Tankstelle (analog zu amenity=fuel).
• *:restaurant - Restaurant / Raststätte (analog zu amenity=restaurant).

Dabei stellt sich mir die Frage, was man mit Zufahrten z.B. zu einer Tank- und Rastanlage macht. Die Zufahrt an sich ist ja weder Parkplatz, noch Tankstelle oder Restaurant.

MHohmann wrote:

Dabei stellt sich mir die Frage, was man mit Zufahrten z.B. zu einer Tank- und Rastanlage macht. Die Zufahrt an sich ist ja weder Parkplatz, noch Tankstelle oder Restaurant.

Aus Sicht der Autobahn sind es ja im wesentlichen :entry und :exit. Das würde aber zu Verwirrungen führen - ist exit jetzt die Ausfahrt von der Autobahn oder die Ausfahrt von der Tankstelle? Ich schlage einfach :link vor - das ist neutral und kann für beliebige zusätzliche Straßenstücke verwendet werden.
Die Definition von :ramp mit "Bidirektional" ist nicht ganz komplett - es kann ja durchaus auch unidirektional sein, z.B. für die Verflechtungsstrecken, die gleichzeitig Ein- und Ausfahrt, aber nur in einer Fahrtrichtung sind.

mueschel wrote:

Aus Sicht der Autobahn sind es ja im wesentlichen :entry und :exit. Das würde aber zu Verwirrungen führen - ist exit jetzt die Ausfahrt von der Autobahn oder die Ausfahrt von der Tankstelle? Ich schlage einfach :link vor - das ist neutral und kann für beliebige zusätzliche Straßenstücke verwendet werden.

Ich würde das dann vielleicht eher :ramp nennen, um Verwirrung mit tmc:link zu vermeiden. In dem Sinne ist es ja genau sowas wie die Verflechtungsstrecke, weil man auf einem Parkplatzweg von der Hauptfahrbahn weg und wieder darauf zurück fährt. Man könnte aber solche Wege, die z.B. nur speziell zur Tankstelle führen, durchaus als :fuel erfassen, und diese im Fall einer geschlossenen Tankstelle dann auch sperren.

mueschel wrote:

Die Definition von :ramp mit "Bidirektional" ist nicht ganz komplett - es kann ja durchaus auch unidirektional sein, z.B. für die Verflechtungsstrecken, die gleichzeitig Ein- und Ausfahrt, aber nur in einer Fahrtrichtung sind.

Stimmt, das Wort ist ungünstig gewählt. Ich meinte damit, dass diese Strecke sowohl bein Ein- als auch beim Ausfahren genutzt wird, also in diesem Sinne "bidirektional", obwohl der Verkehr natürlich nur in eine Richtung fließt.

Auf der CeBIT hatte die ARD einen eigenen Stand (Halle 6), auf dem sie die Vorzüge von TPEG schwärmerisch dargestellt hat (O-Ton: "TMC ist ein Trampelpfad, TPEG eine Autobahn" 🙄). Es wurden u.a. auch Verkehrsmeldungen auf eine OSM-Karte gezeichnet.

Ach ja, im Nebensatz hieß es noch, "Wir senden zwar TPEG, verarbeiten kann es bisher aber keiner." 🤣

Gehrke wrote:

Ach ja, im Nebensatz hieß es noch, "Wir senden zwar TPEG, verarbeiten kann es bisher aber keiner." 🤣

Was mich nicht wundert 😉 Die Meldungen sind für Menschen schön auslesbar, aber für eine Maschine kaum zu verstehen...

In Frankfurt geht's voran. Allerdings sieht man in der Innenstadt dann doch an einigen Stellen vor Problemen:

- Sehr viele Punkte können nur in einer Fahrtrichtung erreicht werden (Einbahnstraßen...), sind laut TMC aber doch in beiden Richtungen vorhanden. Teilweise, z.B. bei der B3 südlich des Mains verläuft die TMC-Route entlang der einen Richtungsfahrbahn und die andere Richtung wird von einem anderen tmc:segment abgedeckt, das gar keinen Bezug zur B3 hat...

- An manchen Stellen schließt sich ein TMC-Punkt direkt an den nächsten an - Dazwischen gibt es dann keinen tmc:link. Sollte man das irgendwie kenntlich machen?

- Die Schreibweise von Straßennamen ist an vielen Stellen falsch. Hier korrigiere ich nach bestem Wissen bzw. mache die Punkte an einer Stelle wenigstens konsistent.

- Als zusätzliche Rolle "(positive|negative|both):attraction" oder ":poi". Z.B. hier: 37341

- Wie sollen kleine TMC-Areas gemappt werden, die eigentlich die Funktion eines Punktes erfüllen? Z.B. hier: 36467

- Bei Kreuzungen bin ich dazu übergegangen den Beginn der Location nicht unbedingt an die Stelle zu setzen "an der man als erstes die Hauptfahrbahn verlässt", sondern entweder auf die Ampel oder den Beginn der getrennt gemappten Spuren, je nachdem, was früher kommt. Damit umfasst der tmc:point eher die tatsächliche Kreuzung als den doch meist recht willkürlich gelegenen ersten Abzweig. Beispiel: 36847

mueschel wrote:

- Sehr viele Punkte können nur in einer Fahrtrichtung erreicht werden (Einbahnstraßen...), sind laut TMC aber doch in beiden Richtungen vorhanden. Teilweise, z.B. bei der B3 südlich des Mains verläuft die TMC-Route entlang der einen Richtungsfahrbahn und die andere Richtung wird von einem anderen tmc:segment abgedeckt, das gar keinen Bezug zur B3 hat...

Hast du da zufällig den passenden Link zur Hand? Ich finde es gerade nicht.

- An manchen Stellen schließt sich ein TMC-Punkt direkt an den nächsten an - Dazwischen gibt es dann keinen tmc:link. Sollte man das irgendwie kenntlich machen?

Ja, das ist mir auch schon aufgefallen - vor allem bei Parkplätzen, die z.B. ja nach Richtung unterschiedlich heißen, aber praktisch auf gleicher Höhe sind. Da ist mir auch noch nichts gutes eingefallen - man könnte die tmc:link Relation einfach weglassen, dann muss das mein Vollständigkeitsprüfer nur irgendwie verstehen...

- Die Schreibweise von Straßennamen ist an vielen Stellen falsch. Hier korrigiere ich nach bestem Wissen bzw. mache die Punkte an einer Stelle wenigstens konsistent.

Ja, würde ich auch so machen.

- Als zusätzliche Rolle "(positive|negative|both):attraction" oder ":poi". Z.B. hier: 37341

Gute Idee. Ich würde hier :poi nehmen und alles wie Sporteinrichtungen, Messen etc. darunter zusammenfassen, da ja aus class=* klar wird, um was es sich handelt. Für mich klingt :attraction sonst zu eingeschränkt nach tourist=attraction.

- Wie sollen kleine TMC-Areas gemappt werden, die eigentlich die Funktion eines Punktes erfüllen? Z.B. hier: 36467

Naja, ein Parkhaus kann man auch als Fläche sehen. Ich würde sowas als tmc:area mappen (wenn ich denn das Proposal dazu fertig habe, das kommt noch) und eine Fläche erfassen. Dann kann ein Auswerter schlussfolgern, dass sich eine Meldung (z.B. Parkplatz geschlossen) nicht nur auf die Member auswirkt, sondern auf alles in der Fläche (Wege, Parkflächen).

- Bei Kreuzungen bin ich dazu übergegangen den Beginn der Location nicht unbedingt an die Stelle zu setzen "an der man als erstes die Hauptfahrbahn verlässt", sondern entweder auf die Ampel oder den Beginn der getrennt gemappten Spuren, je nachdem, was früher kommt. Damit umfasst der tmc:point eher die tatsächliche Kreuzung als den doch meist recht willkürlich gelegenen ersten Abzweig. Beispiel: 36847

Ja, das kann man sicher so machen, so lange nicht jemand "vorher" abbiegen kann, ohne den gemappten TMC-Punkt zu "erwischen". Dann würde ihn ein Router ja nicht mehr finden.

MHohmann wrote:

mueschel wrote:

- Sehr viele Punkte können nur in einer Fahrtrichtung erreicht werden (Einbahnstraßen...), sind laut TMC aber doch in beiden Richtungen vorhanden. Teilweise, z.B. bei der B3 südlich des Mains verläuft die TMC-Route entlang der einen Richtungsfahrbahn und die andere Richtung wird von einem anderen tmc:segment abgedeckt, das gar keinen Bezug zur B3 hat...

Hast du da zufällig den passenden Link zur Hand? Ich finde es gerade nicht.

Wenn nur eine Richtung vorhanden ist, dann würde ich auch nur 1 Richtung mappen, je nachdem was auf der Strecke vorhanden ist.
Ich hatte jetzt mit meiner Arbeit zu tun, daher konnte ich mich sehr wenig mit dem Thema befassen, aber ich habe auch schon sowas gesehen, die B101 in Berlin ist etwas merkwürdig, da sie am Ende je Richtung ein Segment hat, weil dort 2 völlig getrennte Straßen auf die nächste Straße führen:
http://manuelhohmann.dyndns.org/osm/tmc … &lcd=32871
http://manuelhohmann.dyndns.org/osm/tmc … 1&lcd=8447

MHohmann wrote:

- An manchen Stellen schließt sich ein TMC-Punkt direkt an den nächsten an - Dazwischen gibt es dann keinen tmc:link. Sollte man das irgendwie kenntlich machen?

Ja, das ist mir auch schon aufgefallen - vor allem bei Parkplätzen, die z.B. ja nach Richtung unterschiedlich heißen, aber praktisch auf gleicher Höhe sind. Da ist mir auch noch nichts gutes eingefallen - man könnte die tmc:link Relation einfach weglassen, dann muss das mein Vollständigkeitsprüfer nur irgendwie verstehen...

Ich habe ja die A10 gemappt, da gab es auch sowas. Ich habe meist einzelne Punkte vor/hinter den Ausfahrten von den Parkplätzen gemappt. Allerdings habe ich vorher immer die paralell verlaufenden Auffahrten raus geschmissen und durch die entsprechenden turn:lanes ersetzt, damit ich das Ordentlich hinbekomme. Siehe http://manuelhohmann.dyndns.org/osm/tmc … 1&lcd=7015

Nach erfolgreicher Rückkehr aus Berlin habe ich nun auch den Relationsprüfer so modifiziert, dass er auch bei den Tags intersects, note und description Abweichungen zulässt. An TMC Areas wird demnächst auch gearbeitet, sobald ich etwas Zeit dafür habe.

Beim Treffen mit !i! und Christopher in Berlin ist mir noch die Idee gekommen, ob es nicht Garmin-Auto-Navis gibt, die TMC können (ja, gibt es) und wie die ihre Location Code Tabellen speichern - entweder als Teil der Landkarte (gmapsupp.img) oder als separate, fest einprogrammierte Tabelle / Teil der Firmware. Falls ersteres der Fall sein sollte, müsste es doch sogar möglich sein, diese Daten bei einer aus OSM generierten Karte im Garmin-Format ebenfalls zu erzeugen. Allerdings scheint mkgmap das nicht zu können. Weiß zufällig jemand mehr darüber? Das wäre natürlich toll, wenn man die gemappten TMC-Daten so gleich nutzen könnte.

Apropos, bisher sind 520 TMC-Punkte in Deutschland erfasst, so kann es ruhig weitergehen 🙂 Ich habe mir im Moment die A 7 vorgenommen und arbeite daran nordwärts.

Moin,

MHohmann wrote:

ob es nicht Garmin-Auto-Navis gibt, die TMC können (ja, gibt es) und wie die ihre Location Code Tabellen speichern - entweder als Teil der Landkarte (gmapsupp.img) oder als separate, fest einprogrammierte Tabelle / Teil der Firmware.

wenn ich mich recht erinnere, dann wurden bei meinem letzten Update TMC-Informationen als Extra-Update angeboten/eingespielt.
Daraus schließe ich erstmal, dass diese Informationen nicht unbedingt direkt in der Karte (gmapsupp.img) enthalten sind / sein müssen.
Zumindest liegen noch Zusatzinformationen außerhalb der Karte.

Gruß
Georg

Ja, das scheint eine Extra-Datei zu sein - allerdings ist auf der Seite auch von "compatible maps" die Rede, also scheint es da zumindest eine Verbindung zur Karte zu geben. Tatsächlich erscheinen mir 280 kb für eine weltweite Abdeckung etwas klein. Ich schaue mal, ob ich da noch was rausfinden kann.

Edit: Diese Datei scheint tatsächlich nur eine Liste von TMC-Anbietern, Frequenzen und deren Zuständigkeitsbereichen zu enthalten, aber nicht die eigentlichen TMC Location Codes.

Ich habe jetzt mal ein Proposal zum Mappen von TMC Areas aufgesetzt, weil die Frage aufgetaucht war, wie man denn eine solche erfassen würde (am Beispiel eines Parkhauses in Frankfurt). Als Beispiel habe ich mal einen Landkreis gemappt, der Viewer kann das jetzt auch anzeigen (wenn auch noch nicht perfekt), Import funktioniert auch. Verbesserungsvorschläge sind natürlich immer gerne gesehen 😉

MHohmann wrote:

Ich habe jetzt mal ein Proposal zum Mappen von TMC Areas aufgesetzt, weil die Frage aufgetaucht war, wie man denn eine solche erfassen würde (am Beispiel eines Parkhauses in Frankfurt). Als Beispiel habe ich mal einen Landkreis gemappt, der Viewer kann das jetzt auch anzeigen (wenn auch noch nicht perfekt), Import funktioniert auch. Verbesserungsvorschläge sind natürlich immer gerne gesehen 😉

Also zumindest hier sind die TMC-Areas bereits flächendeckend erfasst: http://www.openstreetmap.org/relation/959810

JohnDoe23 wrote:

Also zumindest hier sind die TMC-Areas bereits flächendeckend erfasst: http://www.openstreetmap.org/relation/959810

Richtig, nach dem alten Schema. Ich werde mal schauen, ob man diese alten Daten als Hilfe für das Mappen nach dem neuen Schema nutzen kann - es sollte ja eigentlich möglich sein, die zugehörige Relation zu finden, wenn sie solche TMC-Tags hat, und dann gleich als Member für die tmc:area Relation vorschlagen.

MHohmann wrote:

Richtig, nach dem alten Schema. Ich werde mal schauen, ob man diese alten Daten als Hilfe für das Mappen nach dem neuen Schema nutzen kann - es sollte ja eigentlich möglich sein, die zugehörige Relation zu finden, wenn sie solche TMC-Tags hat, und dann gleich als Member für die tmc:area Relation vorschlagen.

Das wäre von Vorteil, weil es auch Areas gibt, die nicht sofort ins Auge stechen bzw. so leicht auffindbar sind wie die Verwaltungsgrenzen, z.B.: http://www.openstreetmap.org/relation/611246
Das würde die Erfassung nach dem neuen Schema wohl erleichtern.

JohnDoe23 wrote:

Das wäre von Vorteil, weil es auch Areas gibt, die nicht sofort ins Auge stechen bzw. so leicht auffindbar sind wie die Verwaltungsgrenzen, z.B.: http://www.openstreetmap.org/relation/611246
Das würde die Erfassung nach dem neuen Schema wohl erleichtern.

Ja, das stimmt. Ich habe noch mal ein wenig gebastelt - jetzt gibt es im TMC-Viewer die Funktionen "Search in old OSM-TMC data" zur Suche mittels Overpass-API und Anzeige in einer Karte und "Import old OSM-TMC data into editor" zum Laden dieser Daten in einen Editor via Remote Control. Damit kann man nun z.B. auch den Bayerischen Wald direkt suchen und laden.

Dank der Programmierarbeit von Christopher hat nun jede Straße bzw. jedes Segment einen Statusbericht, der auch auf der Viewer-Seite verlinkt ist.

Außerdem ist die A 2 jetzt mit allen Punkten und Links erfasst.

Ich interessiere mich für die TMC Area Codes. Ich glaube, ich habe die eben für alle Gebietskörperschaften in AL6 oder höher (AL5, AL4, AL2) komplettiert - nach dem alten Tagging.

Gibt es einen Vorschlag, wie das Schema hierfür in Zukunft aussehen soll?

Gehrke wrote:

Ich interessiere mich für die TMC Area Codes. Ich glaube, ich habe die eben für alle Gebietskörperschaften in AL6 oder höher (AL5, AL4, AL2) komplettiert - nach dem alten Tagging.

Gibt es einen Vorschlag, wie das Schema hierfür in Zukunft aussehen soll?

jo, mein Vorschlag: TMC sterben lassen, da technisch überholt.

duck&weg
walter

wambacher wrote:

mein Vorschlag: TMC sterben lassen, da technisch überholt.

Das ist so zu absolut formuliert. Ich habe mich in den letzten Tagen mit dem Themenkomplex TMC/TPEG u.ä. beruflich beschäftigt. Auch wenn TMC als Übertragungskanal über Radio/RDS irgendwann ersetzt wird, gilt das nicht unbedingt für Location Codes und Alert-C, die in TMC verwendet werden. Die BASt u.a. werden wohl neben TPEG-Loc u.a. weiterhin auch mit diesen Codes arbeiten (vgl. Verortung in DATEX II).

Gehrke wrote:

Ich interessiere mich für die TMC Area Codes. Ich glaube, ich habe die eben für alle Gebietskörperschaften in AL6 oder höher (AL5, AL4, AL2) komplettiert - nach dem alten Tagging.

Gibt es einen Vorschlag, wie das Schema hierfür in Zukunft aussehen soll?

Ja, hier: https://wiki.openstreetmap.org/wiki/Pro … /TMC_Areas
Siehe dazu auch dieser Post.

wambacher wrote:

jo, mein Vorschlag: TMC sterben lassen, da technisch überholt.

Ich habe von dir schon deutlich konstruktivere Beiträge gesehen, die weniger an Spam erinnern.

MHohmann wrote:

Gehrke wrote:

Gibt es einen Vorschlag, wie das (TMC-Area-)Schema in Zukunft aussehen soll?

Ja, hier: https://wiki.openstreetmap.org/wiki/Pro … /TMC_Areas

Hmm, das lässt sich aber schwer mit boundary-Relationen vereinbaren. Man müsste dann quasi alle Gebietskörperschaften für TMC duplizieren. Das fände ich wirklich falsch. Es mag ja spezifische TMC-Areas geben (?), aber da sie sich oft 1:1 auf Gebietskörperschaften beziehen, würde ich doch eher einen einfachen Tag für den LOCATIONCODE in TMC/Alert-C an der Grenzrelation erwarten (mit Berücksichtung der Tabelle), z.B. "tmc-locode" o.s.ä.

Version und Type finde ich für den Fall auch entbehrlich, da implizit. "area_lcd" sollte man spatial herleiten können oder eben aus der Tabelle ablesen.

Ich würde nicht versuchen, die komplette TMC-Tabelle abzubilden, sondern nur den Link zu ihr ermöglichen.
Für die Zukunft kann ich mir auch eine indirekte TMC-Verknüpfung über Wikidata vorstellen.

MHohmann wrote:

Ich habe von dir schon deutlich konstruktivere Beiträge gesehen, die weniger an Spam erinnern.

nee, kein Spam, da ich zu keinerlei dadurch bevorzugten Personen/Gruppen/Firmen Kontakt habe. Ich bin (und bleibe) halt nur der Ansicht, daß TMC mittelfristig obsolet sein wird.

Gruss
walter

Gehrke wrote:

Hmm, das lässt sich aber schwer mit boundary-Relationen vereinbaren. Man müsste dann quasi alle Gebietskörperschaften für TMC duplizieren. Das fände ich wirklich falsch. Es mag ja spezifische TMC-Areas geben (?), aber da sie sich oft 1:1 auf Gebietskörperschaften beziehen, würde ich doch eher einen einfachen Tag für den LOCATIONCODE in TMC/Alert-C an der Grenzrelation erwarten (mit Berücksichtung der Tabelle), z.B. "tmc-locode" o.s.ä.

Das ist in dem Proposal extra berücksichtigt - es sollen auf keinen Fall Flächen-Relationen für TMC dupliziert werden. Stattdessen kommt die bereits bestehende Boundary-Relation als Element in eine neue TMC-Relation:

TMC-Area-Proposal wrote:

...either by adding already existing boundary or multipolygon relations as members to the TMC area relation...

Der Vorteil gegenüber Tags an bereits bestehenden Objekten liegt darin, dass so TMC-Daten von anderen Daten getrennt sind und sauber entfernt werden können, wenn TMC langfristig einmal durch ein anderes System abgelöst werden sollte und die Daten nicht mehr genutzt werden. Diese Fragestellung ist hier im Thread ja schon öfter aufgetaucht.

Gehrke wrote:

Version und Type finde ich für den Fall auch entbehrlich, da implizit. "area_lcd" sollte man spatial herleiten können oder eben aus der Tabelle ablesen.

Ich würde nicht versuchen, die komplette TMC-Tabelle abzubilden, sondern nur den Link zu ihr ermöglichen.
Für die Zukunft kann ich mir auch eine indirekte TMC-Verknüpfung über Wikidata vorstellen.

Den Standpunkt kann man natürlich auch vertreten. Die Idee, hier möglichst viele Daten zu taggen, basiert auf der Tatsache, dass die TMC-Tabellen nicht für jedes Land so einfach zu bekommen sind wie für Deutschland. Allein die 8 bereits in meinem TMC-Viewer sichtbaren Tabellen bzw. die dafür zuständigen Stellen zu finden und zu kontaktieren waren ein gewisser Aufwand, den man anderen Endanwendern so ersparen könnte.

Gehrke wrote:

wambacher wrote:

mein Vorschlag: TMC sterben lassen, da technisch überholt.

Das ist so zu absolut formuliert. Ich habe mich in den letzten Tagen mit dem Themenkomplex TMC/TPEG u.ä. beruflich beschäftigt. Auch wenn TMC als Übertragungskanal über Radio/RDS irgendwann ersetzt wird, gilt das nicht unbedingt für Location Codes und Alert-C, die in TMC verwendet werden. Die BASt u.a. werden wohl neben TPEG-Loc u.a. weiterhin auch mit diesen Codes arbeiten (vgl. Verortung in DATEX II).

Wenn man jetzt argumentiert, dass es technisch überholt ist und sowieso irgendwann wegfällt, warum dann noch Tankstellen mit Benzin erfassen? Das Öl ist auch irgendwann alle. Oder brauchen wir vielleicht ja keine Straßen, weil jeder nun durch die lüfte fliegt.

Ich gehe davon aus, dass es großflächig noch mindestens 10 Jahre Bestand hat. Zumal für 2015 eine Abschaltung in Deutschland der analogen UKW-Frequenzen, ohne einen weiteren Termin zu nennen, gekippt wurde. Und damit steht und fällt die RDS bzw. TMC. Der Nachfolger DAB(+) ist sofern man sich die Verbreitung in Deutschland ansieht an vielen Stellen noch lückenhaft. Das Digitalradio fordert wohl eine Abschaltung zum Jahr 2018.
Einzig Norwegen ist mir ein bekanntes Land, dort soll das analoge Radio 2017 abgeschalten werden. Österreich hat beim DAB erst eine halbes Jahr Testbetrieb. Ich erinnere nur an den digitalen Polizeifunk, der schon seit der WM 2006 in Deutschland laufen sollte.

Hier kann man mal die derzeitige Verbreitung von TMC und TPEG im vergleich sehen:
http://www.tisa.org/technologies/tpeg/tpeg-world-map/
http://www.tisa.org/technologies/tmc/tmc-world-map/

da ist auch zu sehen, dass noch einige Staaten die Einführung von TMC planen.

Und wie gesagt: Man muss den Verortungs- und Eventstandard, den TMC verwendet, vom Übertragungsstandard TMC/RDS trennen.

MHohmann wrote:

die bereits bestehende Boundary-Relation (kommt) als Element in eine neue TMC-Relation (...)
Der Vorteil gegenüber Tags an bereits bestehenden Objekten liegt darin, dass so TMC-Daten von anderen Daten getrennt sind und sauber entfernt werden können, wenn TMC langfristig einmal durch ein anderes System abgelöst werden sollte und die Daten nicht mehr genutzt werden. Diese Fragestellung ist hier im Thread ja schon öfter aufgetaucht.

Achso, dann hatte ich das nicht sorgfältig genug gelesen. Um den Code eines Landkreises zu erfahren, müsste ich dann aber eine TMC-Area-Relation suchen, die den Landkreis als Member enthält. Klingt nicht gerade straightforward aber praktikabel.

MHohmann wrote:

Die Idee, hier möglichst viele Daten zu taggen, basiert auf der Tatsache, dass die TMC-Tabellen nicht für jedes Land so einfach zu bekommen sind wie für Deutschland. Allein die 8 bereits in meinem TMC-Viewer sichtbaren Tabellen bzw. die dafür zuständigen Stellen zu finden und zu kontaktieren waren ein gewisser Aufwand, den man anderen Endanwendern so ersparen könnte.

Okay, verstehe das Argument. Aber dann die Details vielleicht doch besser außerhalb OSM und eher z.B. in Wikidata.

Gehrke wrote:

Achso, dann hatte ich das nicht sorgfältig genug gelesen. Um den Code eines Landkreises zu erfahren, müsste ich dann aber eine TMC-Area-Relation suchen, die den Landkreis als Member enthält. Klingt nicht gerade straightforward aber praktikabel.

Hm... An die Suchrichtung hatte ich bisher weniger gedacht, aber das stimmt natürlich. Na gut, z.B. bei der Overpass-API gibt es ja die "Membership Resolution" Operatoren, die genau das machen, also scheint es zumindest machbar zu sein.

Gehrke wrote:

Okay, verstehe das Argument. Aber dann die Details vielleicht doch besser außerhalb OSM und eher z.B. in Wikidata.

Sowas könnte man sich auch überlegen, allerdings frage ich mich, wie es dann mit Offline-Anwendungen aussieht. Die OSM-Daten kann man sich ja einfach runterladen und in ein gewünschtes Format konvertieren. Wenn man die Details außerhalb hat, müsste man sich die zusätzlich laden. Speziell bei Wikidata sehe ich das Problem, dass selbst für eine Online-Anwendung der API-Zugriff etwas langsam wäre (dazu hatte ich neulich etwas gelesen).

MHohmann wrote:

Wenn man die Details außerhalb hat, müsste man sich die zusätzlich laden. Speziell bei Wikidata sehe ich das Problem, dass selbst für eine Online-Anwendung der API-Zugriff etwas langsam wäre (dazu hatte ich neulich etwas gelesen).

Das stimmt. Wikidata ist noch quälend langsam und man kann dort ja auch nur explizit eingeführte Eigenschaften eintragen. TMC-Codes sind bisher wohl nicht dabei.

In erster Linie aus Performancegründen ist meine TMC-Anwendung nun auf den OSM-Dev-Server umgezogen und läuft dort gleich wesentlich flüssiger (was sich vor allem bei langen Strecken wie der A 2 und A 7 bemerkbar macht). Hier ist die neue Adresse:

http://mhohmann.dev.openstreetmap.org/tmc/TMC.html

Als nächstes geplant ist eine Web-API, die RDS-Daten in einem geeigneten Rohformat nimmt, wie es z.B. aus einem RDS-Empfänger kommt, und daraus dann die TMC-Meldungen extrahiert, um sie z.B. auf einer Online-Karte anzuzeigen, oder die dann einfach die betroffenen OSM-Objekte liefert.

Das Erfassen von TMC-Punkten geht inzwischen auch einigermaßen voran, auch wenn es naturgemäß Zeit in Anspruch nimmt. Aber die Daten so nutzen zu können ist ja immer eine gute Motivation 😉

Auf dem Dev-Server gibt es nun eine kleine Demo-Anwendung zur Decodierung von TMC-Meldungen und ihrer Lokalisierung mittels der in OSM gemappten Daten. Bisher ist sie noch sehr arm an Features (mehr ein "proof of concept"), wird aber noch ausgebaut. Ideen und Vorschläge sind natürlich immer gerne gesehen. Den Quelltext dazu gibt es auch, ebenso den Quelltext zum TMC Viewer.

Zunächst einmal gibt es einen RDS-Parser. Diesen kann man mit RDS-Datengruppen füttern - eine Datengruppe hat 4 Blöcke zu je 16 Bit. Angeben kann man die Daten z.B. im Hex-Format, eine Gruppe pro Zeile. Leerzeichen spielen keine Rolle. Das kann also z.B. so aussehen:

d321␣4401␣bb9f␣3ec0
d321␣8408␣0865␣27d5

Alternativ kann man auch eine Datei hochladen, auch andere Formate sind möglich. Als Ergebnis bekommt man dann eine Liste von decodierten RDS-Daten. Ausgewertet werden hier die Gruppen 4A (Zeitangabe) und 8A (TMC-Daten). Im Beispiel oben ist die erste Gruppe eine Zeitangabe und die zweite entspricht einer kompletten (Single Group) TMC-Meldung. Die Daten werden als Tabelle angezeigt. Die Zeitstempel werden benutzt, um festzustellen, wann genau eine Meldung empfangen wurde, da die Zeitangaben in der Meldung relativ zu diesem Zeitpunkt sind.

Klickt man nun auf den Event-Code (erste Spalte) einer Meldung, erhält man die decodierte Meldung - alle Daten in lesbare Form übersetzt und interpretiert. Im Beispiel werden sie auch auf der Karte angezeigt. Das ist allerdings noch nicht für alle Events implementiert (tatsächlich habe ich es im Moment nur für Code 101 = "stationary traffic" aktiviert), daran arbeite ich noch. (Man möchte ja auch z.B. Ein- und Ausfahrten oder Parkplätze finden.) Natürlich klappt das auch nur da, wo schon etwas nach dem neuen TMC-Schema gemappt ist - so z.B. für Stau in der Gegenrichtung.

Als nächstes werde ich das für weitere Events aktivieren und dann auch noch etwas hübscher machen, z.B. mit verschiedenen Farben für Staus, Baustellen, Unfälle...

EDIT: Inzwischen ist das für alle Events und mehrfarbig implementiert!

Dieser 11-seitige Faden wird langsam etwas unhandlich, zumal hier auch sehr viele technische Informationen vergraben sind.

MHohmann wrote:

...Das Erfassen von TMC-Punkten geht inzwischen auch einigermaßen voran, auch wenn es naturgemäß Zeit in Anspruch nimmt. Aber die Daten so nutzen zu können ist ja immer eine gute Motivation 😉

was hier irgendwie zu kurz kommt, bzw. untergeht:

Wie sollen denn die TMC-Locations gemappt werden?
Muss sich jeder, der hier den einen oder anderen TMC-Punkt mappen will, die TMC-Liste selbst besorgen, oder ist die bereits irgendwo für OSM-Members-verlinkt?
Verbleiben die Version 9 Daten in der Datenbank oder sollen sie durch die v13 - Daten ersetzt werden oder läuft das alles parallel?

Wie schon gesagt, etwas unübersichtlich das Ganze und manchmal etwas viel Prosa.

Vieleicht sollte auf dem Eingangspost eine Art von Zusammenfassung erscheinen, mit Proposal-Links oder allem was dem Mappen zweckdienlich ist. Diese Zusammenfassung sollte dann auch aktualisiert werden.
Oder das ganze gleich in einen Wiki-Artikel hinterlegen....

Bis da noch etwas mehr Stuktur reinkommt, bleibt mir nichts anderes übrig, als das TMC-Mapping mangels Durchblick zu ignorieren.

geodreieck4711 wrote:

Dieser 11-seitige Faden wird langsam etwas unhandlich, zumal hier auch sehr viele technische Informationen vergraben sind.

Ja, da hast du leider Recht.

Wie sollen denn die TMC-Locations gemappt werden?
Muss sich jeder, der hier den einen oder anderen TMC-Punkt mappen will, die TMC-Liste selbst besorgen, oder ist die bereits irgendwo für OSM-Members-verlinkt?

Die Liste mit den TMC-Punkten findest du für OSM-Members / Mapper aufbearbeitet im TMC-Viewer:
http://mhohmann.dev.openstreetmap.org/tmc/TMC.html
Dort sind die kompletten Location Code Tabellen für 8 Länder hinterlegt, auch für Deutschland. Für das Mappen gibt es dort auch fertige Tools, d.h. du kannst die Daten z.B. direkt in JOSM oder Merkaartor importieren, mittels der Remote-Control-Funktion. Außerdem wird angezeigt, ob die Daten schon gemappt sind.

Verbleiben die Version 9 Daten in der Datenbank oder sollen sie durch die v13 - Daten ersetzt werden oder läuft das alles parallel?

Derzeit bleiben die Version 9 Daten noch in der Datenbank, weil sie noch (u.a. vom BR für seine Staumeldewebseite) genutzt werden. Erst wenn die Version 13 Daten weit genug gemappt sind und man sich auch dort auf die neuen Daten eingerichtet hat, die alten also nicht mehr genutzt werden, kann da etwas gelöscht werden, aber nicht vorher.

Vieleicht sollte auf dem Eingangspost eine Art von Zusammenfassung erscheinen, mit Proposal-Links oder allem was dem Mappen zweckdienlich ist. Diese Zusammenfassung sollte dann auch aktualisiert werden.

Ja, das ist eine gute Idee. Das hatte ich mir auch schon überlegt, der Eingangspost stammt ja von wambacher, und wenn wir ihn dazu motivieren könnten, wäre das eine tolle Sache. Zumindest ein fetter Link zum Wiki in der Form "hier gibt es alles wichtige" wäre gut, dann kann man alles weitere dort hinterlegen.

Oder das ganze gleich in einen Wiki-Artikel hinterlegen....

Das ist die beste Lösung. Etwas habe ich ja schon eingebaut, siehe dazu:
http://wiki.openstreetmap.org/wiki/TMC

Bis da noch etwas mehr Stuktur reinkommt, bleibt mir nichts anderes übrig, als das TMC-Mapping mangels Durchblick zu ignorieren.

Wer Struktur möchte, der soll Struktur bekommen 😉 Ich werde auf jeden Fall mal die Proposals und wichtigen Wiki-Seiten, die es bisher schon zu TMC gibt, auf obiger TMC-Wiki-Hauptseite verlinken.

Edit: So, jetzt sieht die Wiki-Seite doch schon übersichtlicher und hilfreicher aus.
@wambacher: Könntest du die bitte im Eingangspost verlinken, mit einem dicken fetten "Hier gibt es die Infos zu TMC und alles wichtige zum Mappen von TMC aus diesem Thread kompakt im Wiki." oder so ähnlich? Danke!

Update zum RDS-Parser: Unter http://mhohmann.dev.openstreetmap.org/rds/RDS.html kann man jetzt RDS-Daten in verschiedenen Formaten eingeben, entweder per Copy & Paste, als URL oder als Datei. Außerdem kann man angeben, welche Location Code Tabelle benutzt werden soll, um die Location Codes zuzuordnen.

Hier mal ein Beispiel aus Frankreich:
http://mhohmann.dev.openstreetmap.org/r … e_Info.rds

Außerdem erkennt der TMC-Message-Decoder jetzt deutlich mehr Event-Codes und färbt die Meldungen auf der Karte auch danach ein:
http://mhohmann.dev.openstreetmap.org/r … 1399404060

Habe mich innerhalb meines Großraumes mal ein bisschen durch die Liste geklickt, und mit der Suchfunktion gespielt....

kann es sein, das die

MHohmann wrote:

Die Liste mit den TMC-Punkten findest du für OSM-Members / Mapper aufbearbeitet im TMC-Viewer:
http://mhohmann.dev.openstreetmap.org/tmc/TMC.html
Dort sind die kompletten Location Code Tabellen für 8 Länder hinterlegt, auch für Deutschland. Für das Mappen gibt es dort auch fertige Tools, d.h. du kannst die Daten z.B. direkt in JOSM oder Merkaartor importieren, mittels der Remote-Control-Funktion. Außerdem wird angezeigt, ob die Daten schon gemappt sind.

Liste rechtschreibtechnisch Fehler enthält ?

http://mhohmann.dev.openstreetmap.org/t … &lcd=32409

Hier lese ich Lainburg, muss aber 100%ig Leinburg heissen.....

geodreieck4711 wrote:

kann es sein, das die Liste rechtschreibtechnisch Fehler enthält ?

Ja, das kann gut sein, ich bin auch schon über einige gestolpert. Das sind offenbar Rechtschreibfehler in den Daten vom BASt. Teilweise sind die Koordinaten auch etwas weiter weg als sie sein sollten - da muss man dann die richtige Stelle zuerst suchen...

http://mhohmann.dev.openstreetmap.org/t … &lcd=32409
Hier lese ich Lainburg, muss aber 100%ig Leinburg heissen.....

In OSM ist auch Leinburg drin.

Finnland hat eine neue Location Code Liste (Version 2.1) herausgegeben - die Daten sind auch schon im TMC-Viewer importiert.

Da mich KonB darauf aufmerksam gemacht hat, dass die Dokumentation im Wiki dem Tagging etwas hinterherhinkt, habe ich mich mal daran gemacht, das etwas aufzuarbeiten. Auf der tmc:point-Wikiseite habe ich jetzt einen Abschnitt mit Beispielen angelegt. Da kann ich sicher noch weitere Beispiele einbauen (Kreisverkehr, Rastplatz?). Insbesondere ging es um die Frage, dass im Wiki bisher nur vom Erfassen von Nodes die Rede war, dass die derzeit gemappten TMC-Relationen aber auch Ways enthalten und dass letzteres bisher nicht dokumentiert war. Das sei hiermit nachgeholt - danke nochmal für den Hinweis!

Vieleicht sollte man das mal als Wochen/Monatsaufgabe vorschlagen, damit da mal was vorwärts geht.......

Ja, das wäre eine Idee. Ich komme leider in letzter Zeit generell wenig zum mappen, schaue aber regelmäßig in http://mhohmann.dev.openstreetmap.org/t … stats.html und http://mhohmann.dev.openstreetmap.org/t … stats.html rein und fixe Bugs, wenn ich dort welche finde. Vor ein paar Wochen war ich in Finnland, habe dort ein wenig gemappt und mit einem USB-Radioempfänger + SDR ("software defined radio", d.h. Demodulation erfolgt per Software im Computer) das RDS-Signal rausgesucht und darin auch TMC-Meldungen gefunden. Die Location Codes sind in Finnland zwar verschlüsselt, aber die Schlüssel kann man mehr oder weniger "raten", wenn man genug Daten hat. Ziel dieser Aktion war aber vor allem, den Empfang von RDS- und insbesondere TMC-Daten in der Praxis zu testen. Die Sender in Estland haben zwar auch RDS, aber eben kein TMC.

Ich werde auch noch mal mit dem BR Kontakt aufnehmen und dort anfragen, ob man ein paar Live-Daten für eine Demo bereitstellen könnte, um zu schauen, wie es mit den bisher in Bayern gemappten Daten aussehen würde / könnte. Ein paar Autobahnen (auf die beziehen sich ja die meisten Meldungen) haben wir dort ja schon drin. Es ist immer eine gute Motivation, wenn man Fortschritte auch sehen kann. Die Daten könnte man z.B. in meinen RDS-TMC-Web-Viewer packen und dürfte dann Staumeldungen auf der Karte sehen, sofern die TMC Locations schon gemappt sind.

Seit dem letzten Post hat der RDS-TMC-Viewer einige Updates erhalten. Inzwischen beherrscht er alle Event Codes, zeigt Meldungen je nach Schwere des Problems in anderer Farbe an, frisst andere Datentypen als Eingabe und hat ein paar Bugs weniger. Siehe auch die History bei GitHub.

geodreieck4711 wrote:

Vieleicht sollte man das mal als Wochen/Monatsaufgabe vorschlagen, damit da mal was vorwärts geht.......

nö, ich würde das ganz sanft einschlafen lassen.

duck & weg
walter

wambacher wrote:

nö, ich würde das ganz sanft einschlafen lassen.

Du hast hier schon mehr als einmal deine Meinung dazu kundgetan und mitgeteilt was du tun würdest. Das hilft aber in keiner Weise bei dem hier diskutierten Projekt, weshalb solche Beiträge wie deiner von oben nur als Spam und Störung des Diskussionsverlaufs zu werten sind.

... & weg

Das ist der einzige sinnvolle und positive Teil deines Beitrags.

MHohmann wrote:

wambacher wrote:

nö, ich würde das ganz sanft einschlafen lassen.

Du hast hier schon mehr als einmal deine Meinung dazu kundgetan und mitgeteilt was du tun würdest.

Jo, stimmt.

wikipedia wrote:

Ein Forum im allgemeinen Sinn ist ein realer Ort oder ein virtueller (Internetforum) Raum, wo Fragen gestellt und beantwortet werden und Menschen miteinander Ideen und Meinungen austauschen können.

Herrscht hier Meinungsverbot? Oder lässt du nur Meinungen durchgehen, die dir in den Kram passen?

Nun denn, schaun 'mer mal. Ich halt mich mal wieder einige Monate raus.

Gruss
walter

wambacher wrote:

Herrscht hier Meinungsverbot? Oder lässt du nur Meinungen durchgehen, die dir in den Kram passen?

Es ist nichts verboten, sondern nur hinderlich, wenn jemand das Thema einer Diskussion dadurch stört, dass er mehrfach den gleichen kontraproduktiven Inhalt wiederholt. Der wurde schon beim ersten Mal gelesen, ihn noch weiter zu propagieren bringt niemandem etwas.

Ich poste auch nicht in deinen Threads zum Thema Residentials Map, dass das Mappen von Ortsschildern doch irrelevanter Unfug ist und man solche Sachen wie die Auswertung dessen sterben lassen sollte, und das nicht obwohl, sondern gerade weil es mir schlichtweg egal ist, wenn jemand seine Zeit mit so einem Thema verbringen will oder nicht. Wer sich an diesem Thread aktiv beteiligt, verbringt seine Zeit eben mit TMC und der Nutzung von OSM in Verbindung mit Verkehrsmeldungen, und dessen Nutzen ist mir persönlich eher ersichtlich als der von Ortsschildern.

wambacher wrote:

Nun denn, schaun 'mer mal. Ich halt mich mal wieder einige Monate raus.

Du kannst gerne zur Diskussion beitragen, wenn du etwas hilfreiches dazu beizutragen hast - egal ob das nun heute, nächste Woche oder in ein paar Monaten sein soll. Das muss nichts sein, dass mit meiner Meinung übereinstimmt, wir sind hier schließlich keine Diktatur, es sollte nur konstruktiv sein und kein "Lasst euren Mist doch sein", wie in deinen letzten Beiträgen hier. Wenn das dagegen eine Ankündigung sein soll, in ein paar Monaten wieder den gleichen Spam zu posten, dann kannst du es auch gleich endgültig sein lassen und dich komplett raushalten, damit würdest du dann ebenfalls helfen.

Hier mal zwischendurch eine kleine Overpass-Query, die den aktuellen Status des TMC-Mappings innerhalb des gewählten Bildschirmausschnitts zeigt:
http://overpass-turbo.eu/s/5HU
Für ganz Deutschland bekommt man da 30MB an Daten, da man einige Autobahnen komplett bekommt. Die reinen TMC-Relationen nehmen natürlich viel weniger Platz in Anspruch (aber ohne ihre Member sieht man eben nichts auf der Karte).

Wegen eines Rollbacks der Overpass-API sind obige Overpass-Abfrage sowie die Auswertungen unter http://mhohmann.dev.openstreetmap.org/t … stats.html und http://mhohmann.dev.openstreetmap.org/t … stats.html derzeit nicht aktuell, sondern auf dem Stand vom 22. Oktober, werden aber wieder auf den neusten Stand gebracht.

da ergibt sich aber dann das Problem, dass in den Statusauswertungen z.B.
http://mhohmann.dev.openstreetmap.org/t … 1&lcd=7159
es so erscheint, als wären die link u. point-relationen noch nicht angelegt.
das kann dann unter Umständen zu doppelten Relationen führen, bis das Problem beseitigt ist......

Stimmt, guter Punkt. Ich habe den Overpass-Server in meinen Abfrage-Skripten auf die Instanz http://api.openstreetmap.fr/oapi/ umgestellt, die von dem Rollback nicht betroffen ist. Jetzt sollten alle TMC-Skripte wieder aktuelle Daten anzeigen. Die Auswertung ist jetzt auch wieder auf dem neuesten Stand, ich habe sie gerade einmal durchlaufen lassen.

Heute Abend habe ich die aktuelle TMC Location Code Tabelle 2.9 für Belgien bekommen und auch gleich in die Datenbank übernommen. Dabei habe ich auch gleich Italien auf die neueste Version 3.3 gebracht.