Überarbeitung von TMC / TPEG

streckenkundler · 2014-01-10 11:54:51

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

Last edited by streckenkundler (2014-01-10 11:55:12)

MHohmann · 2014-01-10 12:25:20

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.

viw · 2014-01-10 12:46:15

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.

MHohmann · 2014-01-10 13:33:29

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.

Last edited by MHohmann (2014-01-10 13:35:31)

Nadjita · 2014-01-10 14:40:42

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

MHohmann · 2014-01-10 15:08:22

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.

viw · 2014-01-10 15:25:04

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.

MHohmann · 2014-01-10 18:10:02

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.

Last edited by MHohmann (2014-01-10 18:11:12)

mueschel · 2014-01-10 18:29:15

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.

MHohmann · 2014-01-10 19:20:48

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

streckenkundler · 2014-01-10 21:50:00

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

MHohmann · 2014-01-10 22:51:38

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

streckenkundler · 2014-01-10 23:46:35

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

MHohmann · 2014-01-11 00:21:54

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

wambacher · 2014-01-11 00:51:42

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

mueschel · 2014-01-11 01:32:51

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.

MHohmann · 2014-01-11 02:45:54

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

viw · 2014-01-11 10:44:09

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

streckenkundler · 2014-01-11 11:04:58

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

Last edited by streckenkundler (2014-01-11 11:06:30)

MHohmann · 2014-01-11 13:03:04

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.

Last edited by MHohmann (2014-01-11 13:03:47)

streckenkundler · 2014-01-11 13:33:18

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

MHohmann · 2014-01-11 14:27:01

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.

streckenkundler · 2014-01-11 15:01:14

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

MHohmann · 2014-01-11 15:13:45

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.

mueschel · 2014-01-11 15:18:17

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.

Announcement

#76 2014-01-10 11:54:51

Re: Überarbeitung von TMC / TPEG

#77 2014-01-10 12:25:20

Re: Überarbeitung von TMC / TPEG

#78 2014-01-10 12:46:15

Re: Überarbeitung von TMC / TPEG

#79 2014-01-10 13:33:29

Re: Überarbeitung von TMC / TPEG

#80 2014-01-10 14:40:42

Re: Überarbeitung von TMC / TPEG

#81 2014-01-10 15:08:22

Re: Überarbeitung von TMC / TPEG

#82 2014-01-10 15:25:04

Re: Überarbeitung von TMC / TPEG

#83 2014-01-10 18:10:02

Re: Überarbeitung von TMC / TPEG

#84 2014-01-10 18:29:15

Re: Überarbeitung von TMC / TPEG

#85 2014-01-10 19:20:48

Re: Überarbeitung von TMC / TPEG

#86 2014-01-10 21:50:00

Re: Überarbeitung von TMC / TPEG

#87 2014-01-10 22:51:38

Re: Überarbeitung von TMC / TPEG

#88 2014-01-10 23:46:35

Re: Überarbeitung von TMC / TPEG

#89 2014-01-11 00:21:54

Re: Überarbeitung von TMC / TPEG

#90 2014-01-11 00:51:42

Re: Überarbeitung von TMC / TPEG

#91 2014-01-11 01:32:51

Re: Überarbeitung von TMC / TPEG

#92 2014-01-11 02:45:54

Re: Überarbeitung von TMC / TPEG

#93 2014-01-11 10:44:09

Re: Überarbeitung von TMC / TPEG

#94 2014-01-11 11:04:58

Re: Überarbeitung von TMC / TPEG

#95 2014-01-11 13:03:04

Re: Überarbeitung von TMC / TPEG

#96 2014-01-11 13:33:18

Re: Überarbeitung von TMC / TPEG

#97 2014-01-11 14:27:01

Re: Überarbeitung von TMC / TPEG

#98 2014-01-11 15:01:14

Re: Überarbeitung von TMC / TPEG

#99 2014-01-11 15:13:45

Re: Überarbeitung von TMC / TPEG

#100 2014-01-11 15:18:17

Re: Überarbeitung von TMC / TPEG

Board footer