Bevor das hier in “Klein-Klein” endet, sollte man m.E. mal den “großen Wurf” (Top-Down) diskutieren: Den bereits vorgeschlagenen Ansatz der vollständigen Neutralisierung.
Gruß Klaus
Beim probeweisen Umsetzen von TMC- zu normalen route-Relationen (B 312) habe ich festgestellt, dass beim Import der TMC-Daten in 2010 nur ein kleiner Teil der für die Auswertung der TMC-Meldungen benötigten Daten übernommen wurde ( siehe http://forum.openstreetmap.org/post.php?tid=23731&qid=389226).
Das was im Moment in OSM an TMC-Daten vorhanden ist, sieht zwar respektheischend aus, ist für ernsthafte TMC-Anwendungen aber wohl nur rudimentär zu gebrauchen.
+1.
+1. Wenn man hier etwas eigenes aufziehen wollte, müsste das anders strukturiert sein als diese OSMID-Geschichte - allerdings sehe ich nicht, wie das dann aussehen sollte.
+1.
Ja, das wäre ideal. Aber dafür braucht es erst einmal ein Tagging-Schema. Wenn man das hat, kann man sich überlegen, was für Tools man für einen (halb-)automatisierten Import bräuchte.
Eben. Damit würden die Daten auch für kleinere FOSS Projekte überhaupt erst zugänglich.
Gute Idee eigentlich. Fragt sich nur, wie viel das kosten würde - das sollte man als erstes rausfinden. Man könnte auch OSM-basierte Router wie Skobbler fragen, denn dort bestünde sicher ein Interesse an solchen Daten. Vom Navit-Projekt kann ich Martin (cp15) fragen, er hat eine Softwarefirma und bietet Routinglösungen an - das wäre dann ein Projekt, bei dem auch Navit (endlich) eine TMC-Funktion bekommen sollte. Hier im Forum kann ich auch mal Marek fragen - die Firma, bei der er arbeitet, hätte vielleicht auch Interesse.
Also ich denke, wir haben uns bereits darauf geeinigt, den bisherigen TMC-Datenbestand komplett rauszuwerfen. Das dürfte also erledigt sein, von mir aus kann da ein Kahlschlag gemacht werden. Und um den geht es in dieser Diskussion auch schon gar nicht mehr, so weit ich das sehen kann.
Die Diskussion ist doch schon lange beim nächsten Schritt angekommen: nämlich dabei, wie wir stattdessen TMC oder ein anderes System für Verkehrsmeldungen unterstützen. Und die Optionen dazu hat viw ja schon ganz gut aufgelistet. Was also machen wir nach dem Kahlschlag?
Aber die TMC-Relationen bitte erst nach Migration der Routen in Standard-OSM. Die ganzen TMC-Tags bringen nicht viel, aber für die Bereinigung der Straßen-Relationen (anderer Thread) kann man die TMC-Routen-Schnipsel ganz gut gebrauchen.
Ich meinte auch nicht, dass es sofort sein müsste 
Nur dass ich nicht daran festhalte, und IMHO auch niemand sonst hier im Thread.
Bitte nichts überstürzt löschen!
Der Bayerische Rundfunk verwendet die OSM TMC-Relationen für sein Verkehrsfunk-Redaktionssystem und lässt den dafür benötigten Datenbestand von einer Firma in OSM pflegen. Die Zukunft wird eindeutig durch TPEG bestimmt und die Rundfunkanstalten werden nach dem derzeitigen Probebetrieb die aktuellen Verkehrtsdaten zukünftig unter einer freien Lizenz jededermann zur Verfügung stellen. Für eine Überganszeit von mindestens 10 Jahren werden weiterhin TMC-Informationen ausgestrahlt. Die Untersuchungen, ob man zukünftig für die Codierung der Verkehrsmeldungen auf den OSM-Datenbestand zugreifen wird, laufen seit Mitte vergangenen Jahres. Wie bereits von Frederik erwähnt, ist beabsichtigt, die TMC-Informationen automatisiert in einem offenen parallelen System zu OSM zu pflegen. Daher lohnt es sich nicht mehr, viel Aufwand in die Pflege der TMC-Relationen zu stecken, aber für ein generelles Löschen ist es definitiv noch zu früh.
Joachim
Danke für diesen substantiellen Hinweis.
Das heißt für mich, ich werde so vorgehen wie bisher: TMC-Relation kopieren und bearbeiten, die alte Relation lassen.
Ich bin auch gegen ein komplettes Löschen.
Ich sehe hier viele Point-Locations, die vollkommen in Ordnung sind und bei denen es beim Anlegen einige Handarbeit gekostet hat (nicht von mir, sondern von irgendwem in 2008/9). Z.B. gibt es einen Punkt, der keine Kreuzungen markiert sondern einen Ort. Die zugehörigen Kreuzungen und Abzweigungen sind allerdings 5 Stück die rund um den Ort verteilt liegen. Das wird man nie mit einem halb-automatischen Import wieder hinbekommen!
Die TMC-Relationen sind hingegen in vielen Fällen nicht brauchbar und können bei Bedarf auch recht schnell aus den (dann hoffentlich kompletten) Bundesstraßen-Relationen wiederhergestellt werden durch simples kopieren des entsprechenden Abschnittes.
Ich finde übrigens diese Anwendung von Relationen bei komplexeren Kreuzungen recht elegant:
http://www.openstreetmap.org/relation/1381302/history
Vorteile: Die einzelnen Knoten werden nicht zugemüllt mit Tags, es ist kein Problem, mehree Locations an einen Knoten zu taggen und komplexere Anlagen können in ihrer Gesamtheit erfasst werden.
Also aus meiner Sicht:
- Aufräumen bei den Relationen - JA
- Umstellen auf ein einfacheres Tagging bei den Punkten - JA (auch wenn das wirklich nicht kompliziert ist - nur wegen der langen Tags kompliziert aussieht)
- Kompletter Kahlschlag - NEIN, auf keinen Fall.
Wir dürfen auch nicht vergessen, dass es hier “nur” um 30.000 Punkte geht - das ist weniger Arbeit zu kontrollieren als im Augenblick für die OSMBugs gemacht wird!
Alles klar, danke für die Info! Das hatte ich Missverstanden - ich hatte gedacht, die Daten wären nur experimentell genutzt worden. In diesem Fall sollten sie natürlich vorerst in dieser Form erhalten bleiben, bis wir etwas besseres haben, und Nutzer wie der BR darauf vorbereitet sind.
Datenstand TMC-Inspector?
Welcher TMC-Datenstand steht denn hinter den TMC-Daten des TMC-Inspectors?
Ich hab einige Diskrepanzen zwischen dem TMC-Inspectors und der LCL-Liste (V. 12.0) des BaSt. Aufgefallen ist mit das bei der B 97/ B 156 in Sprengberg Ähm… Spremberg. Der TMC-Inspector arbeitet anscheinend nicht mit aktuellen Daten, für Spremberg ohne den neutrassierten Abschnitt der B 97.
Sven
ich bin ja auch interessiert aktuelle Daten in meinem Navi zu haben und Verkehrsmeldungen zu empfangen.
Um zu testen was so ein TMC-Empfänger liefert kann man ja mit so etwas mal spielen “TomTom TMC-Empfänger und USB-Autoladegerät, inkl. Micro USB Adapter” , wird in einem großen Online-Logistikunternehmen für um die 15 Euro angeboten. Um die Daten Bundesweit zu empfangen müsstest du dann Empfänger verteilen. Problemm ist du bekommst nur TMC, TMC+ mußt du dir eine Lizenz kaufen, bei Medion/Gopal liegt die bei ca. 20 Euro pro Gerät.
Eine andere Möglichkeit wäre doch aber die Verkersmeldungsseiten der Rundfunksender / Automobilclubs auszulesen, deren Lizensen muss / sollte man aber auch beachten.
Grüße nach Estland und tausche nicht alles in Euros
Senni
Ja, die Hardware zu bekommen dürfte einfach sein. Ich frage mich, wie es mit der Softwareanbindung aussieht und wie man die Daten (z.B. unter Linux) ausliest. Bei GPS-Empfängern und NMEA ist das ja relativ einfach, vielleicht geht es bei TMC ähnlich.
Ja, in Deutschland ist das möglich, hier gibt es leider (noch) kein TMC Mit so einem Empfänger könnte ich hier also wohl leider nur RDS empfangen (so weit ich weiß, wird TMC auf dem gleichen Träger gesendet) und damit vielleicht sehen, ob das Gerät funktioniert, aber keine Daten bekommen, um den TMC-Empfang zu testen.
Prinzipiell ja, aber das geht auch nur, wenn man gerade Internetzugang hat. Den habe ich z.B. unterwegs nicht.
Also da Estland den Euro seit 1. Januar 2011 hat und Deutschland seit 1. Januar 2002, gibt es wohl nicht viel Grund zu tauschen
Noch eine halbspontane Anregung zu einem etwaigen OSM-eigenen ID-System (ohne viel Ahnung von den Algorithmen und Anforderungen von Auswertern/Nutzern zu haben):
Ich könnte mir vorstellen, dass wir zusammengehörige Nodes/Ways, die gemeinsam ein wichtiges “Punktobjekt” darstellen (im Sinne von Systemen wie TMC, also z.B. Kreuzung, Autobahnausfahrt, Kreisverkehr, …) jeweils in eine Relation packen (type=traffic_object, traffic_object=crossroads/…, description=“Kreuzung A-Straße/B-Straße”/…) – oder einfach eine Fläche (closed way) (mit den entsprechenden Tags) um das Objekt herum eintragen (mein Favorit). Diese Relationen/Flächen bekommen keine explizite ID. Stattdessen suchen die Auswerter an den erwarteten Koordinaten nach Relationen/Flächen des passenden Typs (, was man beschleunigen könnte, wenn man erstmal schaut, ob die Relationen/Flächen aus dem letzten Suchdurchlauf noch da sind).
Im Wesentlichen wäre das eine Hilfestellung für Auswerter, wichtige “Punktobjekte” mit grob bekannten Koordinaten zu identifizieren, die in OSM aus mehreren ways und nodes bestehen, und sie auseinanderzuhalten, ohne IDs zu taggen.
Die Wege zwischen den Punktobjekten könnte man in eine Streckenrelation packen (type=traffic_object, traffic_object=road_segment), zusammen mit den Relationen/Flächen der Punktobjekte mit den Rollen to/from. Eine Identifizierung mit Streckenobjekten aus externen Datenbanken fände dann einfach über die verbundenen Punktobjekte statt – womit man auch hier keine explizite ID bräuchte.
Um einen Überblick zu bekommen und etwas Licht in das “abstrakte Datengewusel” zu bringen, als das die TMC-Daten den meisten Mappern wohl bisher erscheinen, habe ich auch mal, ähnlich wie mueschel, die deutschen TMC-Daten in GPX umgewandelt, der Handlichkeit halber aber in etwas kleinere Dateien zerteilt, und ein paar davon auf einer Karte dargestellt:
http://manuelhohmann.dyndns.org/osm/TMC.html
Dort sieht man nun die L 140 von NRW, die A 2 sowie die A 10 (Berliner Ring). Wenn man einen Punkt anklickt erhält man die Infos, die in der vom BASt gelieferten CSV-Datei enthalten sind. Dazu werde ich noch ein wenig im Wiki dokumentieren, aber zunächst einmal die wichtigsten und für uns interessanten Daten:
-
LOCATIONCODE - eindeutige Codenummer dieses Punktes in der Tabelle
-
TYPE, SUBTYPE - Objekttyp, z.B. Autobahnkreuz, Kreisverkehr, Parkplatz, Rastplatz…
-
ROADNUMBER - ref der zugehörigen Straße
-
FIRST_NAME - Name des Objektes
-
AREA_REFERENCE - Location Code des Verwaltungsgebietes
-
LINEAR_REFERENCE - Location Code der zugehörigen Straße oder Straßensegments
-
NEGATIVE_OFFSET, POSITIVE_OFFSET - Location Codes der benachbarten Punkte entlang dieser Straße
-
X_KOORD, Y_KOORD - WGS84-Koordinaten
Hi, obwohl TMC nicht -mehr- mein Ding ist, möchte ich doch auf eine sehr gute PostGIS-Erweiterung hinweisen:
Das aktuelle PostGIS (schlage 2.0 oder höher vor) unterstützt Topologien.
Topologien bestehen aus Knoten, Kanten und Flächen (Nodes, Edges und Areas) und werden von Postgis als eigene Datentypen/Objekte verwendet. Das wartet geradezu auf TMS.
Die Doku ist ein wenig dürftig, aber wer sich wirklich dafür interessiert (z.B. Routing), wird da schon was finden können.
http://trac.osgeo.org/postgis/wiki/UsersWikiPostgisTopology
http://postgis.net/docs/Topology.html
ach ja: Ich hab nichts gegen TMS, ich kenne inzwischen einigermaßen die Daten und deren Struktur, schaue da gerne nach und verwende die auch als Referenz - ich will die nur nicht mehr in OSM drin haben.
Gruß
walter
ps2: Zum Thema “eindeutige ID” schlage ich die Verwendung von UUIDs vor. Die sind aber bei osm-Talk mehrfach abgeblockt worden, ohne daß die Ablehner eine Alternative angeboten hätten
Aus dem Route-Schwester-Thread:
“type=TMC” gefällt mir auch gar nicht. Entweder es ist ein Node oder eine Relation für Gebiete (type=boundary|multipolygon) oder Abschnitte (type=route).
Dann könnte z.B. “boundary|route=tmc” sein. Letztlich benötigt wird aber nur die TMC-ID, egal ob die nun direkt in OSM ist oder extern mit der passenden OSM-Relation verknüpft wird.
Kann die betreuende Firma das für den BR nicht schnell umstellen? Das ist ja nur eine kleine, einfache SQL-Abfrage.
Das aktuelle TMC-Tagging will wohl auf die Dauer niemand hier in OSM drin haben, es wird nur eben noch genutzt. Deshalb ist ja auch völlig unstrittig, dass wir es rauswerfen, sobald wir etwas besseres haben (und das stattdessen genutzt werden kann). Genau darum geht es doch. Klar dass man dafür die Struktur verstehen muss, gerade deshalb versuche ich ja sie zu dokumentieren, damit auch andere außer uns beiden und den aktiven Postern hier sie verstehen und wir ein besseres Tagging bekommen Das geht nur nicht von heute auf morgen.
Worin genau besteht denn nun der Nutzen von PostGIS-Topologien im Zusammenhang mit TMC?
Ganz “einfach”: TMC-Daten bestehen aus Points, Lines und Areas und Topologieen bestehen aus Nodes, Edges und Areas - andere Worte für die gleichen Begriffe.
Ein Datensatz aus der Location-Liste ist genau ein Topologie-Element, ohne auch nur irgendwas zusammensuchen zu müssen.
In PostGIS kann man ja geometrische Operationen mit den GIS-Objekten machen (Welche Linien schneiden sich wo? Welche Fläche ist die grösste?, …) Und mit der Topology-Extension geht das auch mit Topologischen Objekten - und die Location-Liste von TMC besteht zu 100% aus topologischen Objekten.
Geht so in Richtung Graphen, Routing. Da wird sowas gebraucht. Und TMC ist auch nicht anderes.
Ist für dich allerdings wohl nur theoretisch interessant, da die Einarbeitung relativ mühsam ist. Und ich bin auch noch nicht sehr vertraut damit.
Gruß
walter
Na gut, so weit war ich noch mitgekommen, aber ich hatte bis eben gedacht, solche Objekte wären ohnehin schon in PostGIS vorhanden und nicht erst durch eine “Topologie-Erweiterung”. IMHO werden doch auch OSM-Objekte schon seit längerem in PostGIS abgebildet, und die sind doch auch nichts anderes, oder? Wobei:
…und ein GIS-Objekt ist kein topologisches Objekt (oder umgekehrt) - d.h. das ist nicht das gleiche?
Ja, das fürchte ich auch Mit PostGIS hatte ich bisher noch nichts zu tun. Aber man weiß ja nie, was man nicht noch irgendwann mal brauchen wird…