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:
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
-
nach LCL
9049->43818->9050->9051->9052 -
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
Ja, richtig.
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.
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.
Ja, stimmt schon, das sind eine Menge Daten - aber wenn man bedenkt, wie viel mehr schon gemappt wurde…
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
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.
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
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/tmc2map.php?cid=58&tabcd=1&lcd=57868
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…
Aber erst mal nicht in den LCL-Codes der Liniensegmenten.
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
Ja, richtig. Offenbar hat keine Straße bzw. kein Segment in den Tabellen diesen Namen, sondern nur die 4 Punkte.
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.
Eben genau daraus: 
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/TMC_Location_table_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.
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
Ja, richtig, die ist etwas kryptisch…
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.
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.
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
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.
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.