Überarbeitung von TMC / TPEG

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.

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.

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

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.

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

Ü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

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?

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?

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.

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.

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

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.

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

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.

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:Ajoessen/Mapserver
http://wiki.openstreetmap.org/wiki/User:Ajoessen/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=tmc&lon=13.45273&lat=52.56054&zoom=14&overlays=tmc_points,ways_with_tmc_tags_ok,link_ways_with_too_many_ends,ways_with_tmc_tags_error,nodes_with_tmc_tags_ok,nodes_with_tmc_tags_error,connection_and_end_nodes_ok,connection_and_end_nodes_error,ways_with_tmc_tags_non_areas,ways_with_tmc_tags_areas,ways_in_rels_with_tmc_tags,tmc_areas,nodes_with_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.

Ah, verstehe.

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.

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

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.

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.

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=tmc&lon=10.02721&lat=53.56968&zoom=18&overlays=tmc_database,missing_tmc_links,tmc_links,tmc_points,ways_with_tmc_tags_ok,link_ways_with_too_many_ends,ways_with_tmc_tags_error,nodes_with_tmc_tags_ok,nodes_with_tmc_tags_error,connection_and_end_nodes_ok,connection_and_end_nodes_error,ways_with_tmc_tags_non_areas,ways_with_tmc_tags_areas,ways_in_rels_with_tmc_tags,tmc_areas,nodes_with_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).

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

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.

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.

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

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.

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.

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

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…

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

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