Was mich nicht wundert 
Die Meldungen sind für Menschen schön auslesbar, aber für eine Maschine kaum zu verstehen…
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
Hast du da zufällig den passenden Link zur Hand? Ich finde es gerade nicht.
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…
Ja, würde ich auch so machen.
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.
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).
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.
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/tmcview.php?cid=58&tabcd=1&lcd=32871
http://manuelhohmann.dyndns.org/osm/tmcview.php?cid=58&tabcd=1&lcd=8447
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/tmcview.php?cid=58&tabcd=1&lcd=7015
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.
Moin,
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
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.
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
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.
Das wäre von Vorteil, weil es auch Areas gibt, die nicht sofort ins Auge stechen bzw. so leicht auffindbar sind wie die Verwaltungsgrenzen, z.B.: http://www.openstreetmap.org/relation/611246
Das würde die Erfassung nach dem neuen Schema wohl erleichtern.
Ja, das stimmt. Ich habe noch mal ein wenig gebastelt - jetzt gibt es im TMC-Viewer die Funktionen “Search in old OSM-TMC data” zur Suche mittels Overpass-API und Anzeige in einer Karte und “Import old OSM-TMC data into editor” zum Laden dieser Daten in einen Editor via Remote Control. Damit kann man nun z.B. auch den Bayerischen Wald direkt suchen und laden.
Dank der Programmierarbeit von Christopher hat nun jede Straße bzw. jedes Segment einen Statusbericht, der auch auf der Viewer-Seite verlinkt ist.
Außerdem ist die A 2 jetzt mit allen Punkten und Links erfasst.
Ich interessiere mich für die TMC Area Codes. Ich glaube, ich habe die eben für alle Gebietskörperschaften in AL6 oder höher (AL5, AL4, AL2) komplettiert - nach dem alten Tagging.
Gibt es einen Vorschlag, wie das Schema hierfür in Zukunft aussehen soll?
jo, mein Vorschlag: TMC sterben lassen, da technisch überholt.
duck&weg
walter
Das ist so zu absolut formuliert. Ich habe mich in den letzten Tagen mit dem Themenkomplex TMC/TPEG u.ä. beruflich beschäftigt. Auch wenn TMC als Übertragungskanal über Radio/RDS irgendwann ersetzt wird, gilt das nicht unbedingt für Location Codes und Alert-C, die in TMC verwendet werden. Die BASt u.a. werden wohl neben TPEG-Loc u.a. weiterhin auch mit diesen Codes arbeiten (vgl. Verortung in DATEX II).
Ja, hier: https://wiki.openstreetmap.org/wiki/Proposed_features/Relation:tmc/TMC_Areas
Siehe dazu auch dieser Post.
Ich habe von dir schon deutlich konstruktivere Beiträge gesehen, die weniger an Spam erinnern.
Hmm, das lässt sich aber schwer mit boundary-Relationen vereinbaren. Man müsste dann quasi alle Gebietskörperschaften für TMC duplizieren. Das fände ich wirklich falsch. Es mag ja spezifische TMC-Areas geben (?), aber da sie sich oft 1:1 auf Gebietskörperschaften beziehen, würde ich doch eher einen einfachen Tag für den LOCATIONCODE in TMC/Alert-C an der Grenzrelation erwarten (mit Berücksichtung der Tabelle), z.B. “tmc-locode” o.s.ä.
Version und Type finde ich für den Fall auch entbehrlich, da implizit. “area_lcd” sollte man spatial herleiten können oder eben aus der Tabelle ablesen.
Ich würde nicht versuchen, die komplette TMC-Tabelle abzubilden, sondern nur den Link zu ihr ermöglichen.
Für die Zukunft kann ich mir auch eine indirekte TMC-Verknüpfung über Wikidata vorstellen.
nee, kein Spam, da ich zu keinerlei dadurch bevorzugten Personen/Gruppen/Firmen Kontakt habe. Ich bin (und bleibe) halt nur der Ansicht, daß TMC mittelfristig obsolet sein wird.
Gruss
walter
Das ist in dem Proposal extra berücksichtigt - es sollen auf keinen Fall Flächen-Relationen für TMC dupliziert werden. Stattdessen kommt die bereits bestehende Boundary-Relation als Element in eine neue TMC-Relation:
Der Vorteil gegenüber Tags an bereits bestehenden Objekten liegt darin, dass so TMC-Daten von anderen Daten getrennt sind und sauber entfernt werden können, wenn TMC langfristig einmal durch ein anderes System abgelöst werden sollte und die Daten nicht mehr genutzt werden. Diese Fragestellung ist hier im Thread ja schon öfter aufgetaucht.
Den Standpunkt kann man natürlich auch vertreten. Die Idee, hier möglichst viele Daten zu taggen, basiert auf der Tatsache, dass die TMC-Tabellen nicht für jedes Land so einfach zu bekommen sind wie für Deutschland. Allein die 8 bereits in meinem TMC-Viewer sichtbaren Tabellen bzw. die dafür zuständigen Stellen zu finden und zu kontaktieren waren ein gewisser Aufwand, den man anderen Endanwendern so ersparen könnte.