Überarbeitung von TMC / TPEG

MHohmann · 2014-03-05 23:54:09

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.

TrafficJam · 2014-03-06 09:31:49

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.

MHohmann · 2014-03-06 09:57:05

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.

mueschel · 2014-03-06 23:34:20

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.

MHohmann · 2014-03-07 08:36:37

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

Last edited by MHohmann (2014-03-07 08:38:02)

TrafficJam · 2014-03-07 08:48:34

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.

MHohmann · 2014-03-07 09:56:47

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.

Last edited by MHohmann (2014-03-07 10:01:20)

mueschel · 2014-03-07 12:58:31

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

MHohmann · 2014-03-07 16:33:34

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.

MHohmann · 2014-03-07 23:27:27

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.

mueschel · 2014-03-08 00:22:25

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?

MHohmann · 2014-03-08 08:19:32

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.

mueschel · 2014-03-09 19:23:46

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.

MHohmann · 2014-03-09 22:01:33

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.

Gehrke · 2014-03-15 13:12:13

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

Last edited by Gehrke (2014-03-15 13:12:49)

MHohmann · 2014-03-15 14:52:55

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

mueschel · 2014-03-15 16:49:31

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

MHohmann · 2014-03-17 01:46:46

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.

Christopher · 2014-03-17 10:26:54

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

MHohmann · 2014-03-24 22:23:39

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.

GeorgFausB · 2014-03-25 08:52:20

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

MHohmann · 2014-03-25 09:40:53

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.

Last edited by MHohmann (2014-03-25 09:55:43)

MHohmann · 2014-03-28 23:33:11

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

JohnDoe23 · 2014-03-28 23:51:57

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

MHohmann · 2014-03-29 00:07:54

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.

Announcement

#226 2014-03-05 23:54:09

Re: Überarbeitung von TMC / TPEG

#227 2014-03-06 09:31:49

Re: Überarbeitung von TMC / TPEG

#228 2014-03-06 09:57:05

Re: Überarbeitung von TMC / TPEG

#229 2014-03-06 23:34:20

Re: Überarbeitung von TMC / TPEG

#230 2014-03-07 08:36:37

Re: Überarbeitung von TMC / TPEG

#231 2014-03-07 08:48:34

Re: Überarbeitung von TMC / TPEG

#232 2014-03-07 09:56:47

Re: Überarbeitung von TMC / TPEG

#233 2014-03-07 12:58:31

Re: Überarbeitung von TMC / TPEG

#234 2014-03-07 16:33:34

Re: Überarbeitung von TMC / TPEG

#235 2014-03-07 23:27:27

Re: Überarbeitung von TMC / TPEG

#236 2014-03-08 00:22:25

Re: Überarbeitung von TMC / TPEG

#237 2014-03-08 08:19:32

Re: Überarbeitung von TMC / TPEG

#238 2014-03-09 19:23:46

Re: Überarbeitung von TMC / TPEG

#239 2014-03-09 22:01:33

Re: Überarbeitung von TMC / TPEG

#240 2014-03-15 13:12:13

Re: Überarbeitung von TMC / TPEG

#241 2014-03-15 14:52:55

Re: Überarbeitung von TMC / TPEG

#242 2014-03-15 16:49:31

Re: Überarbeitung von TMC / TPEG

#243 2014-03-17 01:46:46

Re: Überarbeitung von TMC / TPEG

#244 2014-03-17 10:26:54

Re: Überarbeitung von TMC / TPEG

#245 2014-03-24 22:23:39

Re: Überarbeitung von TMC / TPEG

#246 2014-03-25 08:52:20

Re: Überarbeitung von TMC / TPEG

#247 2014-03-25 09:40:53

Re: Überarbeitung von TMC / TPEG

#248 2014-03-28 23:33:11

Re: Überarbeitung von TMC / TPEG

#249 2014-03-28 23:51:57

Re: Überarbeitung von TMC / TPEG

#250 2014-03-29 00:07:54

Re: Überarbeitung von TMC / TPEG

Board footer