Nein, sie müssen mitgezählt werden. Sie befinden sich in der Kette von Punkten, und weil “extra attributes may be ignored” hat der Empfänger keine Möglicheit herauszufinden, dass er einen Punkt überspringen soll.
Der Punkt existiert als Knoten im TMC-Netz in beiden Richtungen, nur das zugeordnete Objekt (aka Parkplatz) existiert unter Umständen nicht in beiden Richtungen. Deswegen: Mappen in beiden Richtungen ist Pflicht und kann nicht wegdiskutiert werden.
Na toll… Wie macht es denn der BR?
Nach dem vierten Durchlesen des entsprechenden Abschnitts im TMC Compendium verstehe ich es auch so, dass die Anzahl der Schritte von A nach C i.A. nicht die Anzahl der Schritte von C nach A wäre - was dafür spräche, nur die Punkte zu zählen, die in der jeweiligen Richtung vorhanden sind. Das halte ich aber für völligen Murks und einen Fehler im TMC Compendium.
Hi ihr,
interessante Diskussion, mein Beispiel ist bidirectional negative. Das ist ja wieder ein Spezialfall. Weil die Fahrbahnen auf beiden Seiten betroffen sind. Das kann dann natürlich sein, dass dann alle berücksichtig werden. Es ist vielleicht so, dass nur bei monodirectional nicht alle Points mit entsprechendes present berücksichtigt werden. Ich suche nochmal ein Beispiel was monodirectional ist. Aber genau für dieses Beispiel ist es ja jetzt wichtig beide Richtungen zu haben, auch wenn es ohne möglich wäre. Aber warum nicht erfassen? Für die Software des Routings oder der Darstellung ist es doch schwieriger was nicht vorhandenes zu kompensieren als was vorhandenes zu ignorieren.
Christopher
Edit:
Beispiel:
Location: 11992
direction: negative
extend: 3 (monodirectional)
Hier sind zwischen 2 Anschlussstellen 2 gegenüberliegende Parkplätze, die einmal negative, einmal positiv in ihrem present sind. Demnach werden sie mit gezählt, egal welches Presnt, zumindets beim MDR. Ich kann das ja mal am Do/Fr. in der Region Berlin nachprüfen wie das da ist, da gibt’s ja den RBB, die es warscheinlich auch so machen und aber noch mind. 1/2 private sender mit freeTMC.
Meldung von Jump:
Zwischen Kreuz Koblenz und AS Plaidt Wartungsarbeiten, 3 km Stau für LKW
Beim HR werden sie auch mitgezählt - hier gibt es zwei Meldungen für die Strecke zwischen Herborn-West und Dillenburg, eine pro Richtung:
d3 68 85 42 ea bd 2c 90
d3 68 85 42 58 fd e9 e7
d3 68 85 42 06 a7 e0 00
Event: 701 - roadworks
Event: 1851 - temporary width limit 6.3m
Urgency: normal
Road: 7115 - A45 Gießen - Hagen
From: 11406 - 26 Herborn-West
To: 11408 - 25 Dillenburg
Extent: 5
Stop time: end of November
d3 68 85 45 aa c3 2c 8e
d3 68 85 45 68 fd e9 57
d3 68 85 45 1b d3 ce d4
d3 68 85 45 0e 80 00 00
Event: 707 - bridge maintenance work
Event: 701 - roadworks
Event: 1851 - temporary width limit 5.8m
Urgency: normal
Road: 7115 - A45 Hagen - Gießen
From: 11408 - 25 Dillenburg
To: 11406 - 26 Herborn-West
Extent: 5
Stop time: end of November
Beim Thema des mappings von Rampen haben wir ja inzwischen mehrere Vorschläge, aber sind wohl noch nicht zu einem wirklichen Ergebnis gekommen.
Manuels Vorschlag ( http://www.openstreetmap.org/relation/3533117 ) klingt gut für ein komplettes mapping. Ich weiß allerdings noch nicht, wie man die dort enthaltene Information wirklich nutzen kann in Verbindung mit üblichen Meldungen. Keines der Events sieht vor, dass die Location zu der eine Ausfahrt führt bzw. von der eine Einfahrt kommt genannt wird. Es wird immer nur eine Location und eventuell noch eine direction, in der Regel die nächste folgende Location in Fahrtrichtung, angegeben.
Außerdem sind sehr viele Locations mit Ein/Ausfahrten keine Verbindung zu einer anderen TMC-Location. Hier lässt sich das Schema zwar auch anwenden, aber es ist dann auch unnötig kompliziert (Eigene relation, komplizierte Namen der Rolle).
Würde es nicht in diesem einfachen Fall ohne eine vorhandene zweite Location Sinn machen, wie auch bei Parkplätzen mit Rollen direkt in der Punkt-Relation zu arbeiten? Ich würde die Rampen aufnehmen und mit den Rollen positive:exit, negative:exit, positive:entry und negative:entry versehen. Das spart Arbeit, sieht ordentlicher aus und enthält alle nötigen Informationen.
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.
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.
Ja, das sehe ich ganz genau so. Mein Vorschlag war auch nur für komplexere Situationen gedacht, bei denen dieses einfachere Schema nicht ausreicht.
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.
Gut zu wissen 
Hm… Den Einwand verstehe ich nicht ganz… Vielleicht gibt es hier noch ein Missverständnis bei den TMC-Daten? Was genau sollte true/false/both aussagen, das negative/positive nicht aussagt?
Die doppelt verlinkte Liste der TMC-Punkte mittels neg_off_lcd und pos_off_lcd in den originalen TMC-Daten ist unabhängig davon, auf welcher Seite ein Punkt vorhanden ist. Auch ein Punkt, der nur auf einer Seite vorhanden ist, ist immer in dieser Liste vorhanden, egal in welcher Richtung man sie nun abgeht. Ebenso ist es auch im vorgeschlagenen OSM-Tagging, wo pos_offset und neg_offset genau diese komplette doppelt verlinkte Liste abbilden.
Manuel, kannst du in deinen TMC-Viewer noch eine kleine Verbesserung einbauen? Wenn zu einem Punkt eine Relation gefunden wird, kannst du ihn dann in einer anderen Farbe darstellen, vielleicht ein Ring ohne Füllung? Dann sieht man wo noch etwas zu machen ist und erkennt auch, wenn mehrere Punkte übereinander liegen.
Ansonsten lohnt es sich auch, immer mal einen Blick in die Area-Locations zu werfen - da gibt es doch einige enthaltene Punkte ohne Koordinaten, z.B. die Parkhäuser in Frankfurt.
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 
Ganz einfach der Bezug zur aktuellen Richtung. Es wird ja z.B. eine TMC Location auf zwei OSM Nodes abgebildet. Daher kann in der TMC Locationlist nur abstrakt drinstehen, den Parkplatz gibt es nur in positiver Richtung. In den OSM Points habe ich aber den direkten Bezug, auf welcher der beiden Richtungen sich der aktuelle Node gerade befinder. Wenn ich nun beim einem der beiden OSM Nodes present=*true *stehen habe und in der Gegenrichtung present=false, sehe ich auf einen Blick, ob die Location (der Parkplatz) in dieser Richtung nun da ist oder nicht - ohne erst indirekt ermitteln zum müssen, ob sich der OSM Node auf der positiven oder negativen TMC-Richtung befindet.
Eine noch bessere Alternative wäre ein weiteres Attribut *direction *einzufügen (postive/negative/both), dann hätte ich auch alle nötigen Informationen an einer Stelle. Wenn ich also einen TMC Event darstellen möchte, der an der TMC Location x einen Unfall in positiver Fahrtrichtung beinhaltet, hole ich mir die OSM-Nodes zu lcd=x. Dann erhalte ich zwei Ergebnisse und muss entscheiden, welcher Node der in postiver Richtung ist. Wenn dies direkt in den Attributen steht, fällt mir das natürlich leichter als wenn ich benachbarte Nodes (oder Ways) auswerten muss, um die Richtung zu erkennen.
Ah, aber das sollte im vorgeschlagenen Taggingschema doch möglich sein, oder nicht? Also angenommen ich habe einen Location Code und möchte ermitteln, welche Elemente davon vorhanden sind, dann gehe ich folgendermaßen vor:
Suche die zugehörige tmc:point Relation, die den entsprechenden Location Code als lcd hat.
Lese das Tag present=* dieser Relation aus um zu ermitteln, auf welcher Seite die Location vorhanden ist.
Lese die Member dieser Relation inkl. ihrer Rollen aus. Wenn die Rolle z.B. “positive” (oder “positive:parking” etc.) ist, ist das Objekt auf der positiven Seite (das entspricht dem von dir vorgeschlagen direction). Ein Vergleich mit dem bereits ausgelesenen present=* der Relation sagt dann, ob hier wirklich etwas vorhanden ist, oder ob das nur ein Dummy-Node ist.
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.
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/tmcview.php?cid=58&tabcd=1&lcd=36882 ), und dann auch Ampelkreuzungen wo gar keine Kreuzung ist oder falsche Straßennamen an Knoten.
Deine Änderung sieht gut aus - und gerade bei Autobahnenabfahrten ist es sehr schön, dort sind jetzt jeweils zwei Knoten mit der Nummer der Abfahrt im Kreis versehen .
Solche Problemstellen sind mir auch entlang der A39 in Höhe Braunschweig aufgefallen. Dort sind z.B. die Abfahrt BS-Rüningen-Nord und das Dreieck Braunschweig-Südwest regelrecht verschlungen, da sind die Rampen untereinander verbunden. Ähnlich sieht es aus bei Kreuz Braunschweig-Süd, Heidbergtunnel und Braunschweig-Südstadt. Das so zu mappen, dass ein Router keinen TMC-Punkt verpasst und alle beim Routing berücksichtigt, ist schon eine vertrackte Angelegenheit.
Neue Features im TMC Viewer:
In der TMC Punkt Ansicht werden jetzt auch die Tags der tmc:link Relationen angezeigt und können in JOSM geladen bzw. importiert werden, z.B. hier.
Für tmc:link Relationen gibt es jetzt einen Statistik-Report mit Überprüfung von Tags und Rollen.
Die vorhandenen Frankfurter points sollten jetzt auch fast alle ihre Rolle gefunden haben. Und schon wieder habe ich zwei Verbesserungsvorschläge
Wenn an einem Punkt zwei tmc:points liegen, dann habe ich nur Zugriff auf einen der Punkte und keine Möglichkeit den zweiten zu bekommen. Da könnte man in der Liste mit Infos noch einen Punkt einfügen “Other TMC Points at this location: #1, #2”.
Ein weiterer Punkt: Wenn ich auf ein OSM-Objekt klicke, dann bekomme ich einen Link zum Objekt und einen zur Relation. Kannst du auch noch einen Link zum TMC-Punkt einfügen?
Super
Done. So langsam wird die Liste ziemlich lang 
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).
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.
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.
Stimmt, das Wort ist ungünstig gewählt. Ich meinte damit, dass diese Strecke sowohl bein Ein- als auch beim Ausfahren genutzt wird, also in diesem Sinne “bidirektional”, obwohl der Verkehr natürlich nur in eine Richtung fließt.
Auf der CeBIT hatte die ARD einen eigenen Stand (Halle 6), auf dem sie die Vorzüge von TPEG schwärmerisch dargestellt hat (O-Ton: “TMC ist ein Trampelpfad, TPEG eine Autobahn” 
). Es wurden u.a. auch Verkehrsmeldungen auf eine OSM-Karte gezeichnet.
Ach ja, im Nebensatz hieß es noch, “Wir senden zwar TPEG, verarbeiten kann es bisher aber keiner.” 
