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…
Nö, die sind wirklich was anderes. egal.
Gruss
walter
Ich habe hier einen Vorschlag zum Thema mapping von Punkt-Lokationen (meistens Kreuzungen). Hier ist eine Kreuzung, die zwei TMC Koordinaten hat:
http://www.openstreetmap.org/node/32906938
Dieser Knoten sowie der zweite Zentrale Kreuzungsknoten dieser Kreuzung sind Teil von zwei Relationen, die jeweils alle Infos zu diesem TMC-Punkt enthalten.
Leider zeigt osm.org/browse nicht den Typ der Relation an, aber das kann sich ja noch ändern.
Damit sind zwei zentrale Kritikpunkte hoffentlich behoben: Tag-Chaos an Punkten und Wegen sowie der Problemfall mehrerer überlagernder Punkte.
Was haltet ihr von dieser möglichen Lösung?
Die einzelnen Routen-Teilstücke werde ich in den nächsten Tagen hinzufügen. Das genaue Tagging innerhalb der Relation steht jetzt (noch) nicht zur Diskussion, das ist das alte Schema.
Hallo ins Forum,
grundsätzlich bin ich ja interessiert, dass Daten ala TMC ins Gerät kommen.
Ich benutze aber seit diesem Jahr kein Navi mehr, sondern alles geht über ein 7 Zoll Tablet mit OSMAND oder Mapfactor Navigator als Navi-Software.
Mein Gedankengang war dabei von teuren Kartenupdates der reinen Navi’s weck zu kommen.
Hier wurde auch schon kräftig über TMC über Internet diskutiert http://www.car-pc.info/phpBB2/viewtopic.php?t=15793&postdays=0&postorder=asc&start=0
und eine Anwendung auch benannt die Navi-Software verschiedenen Betriebssyteme erweitert.
Man würde also nicht bei 0 Anfangen müssen, ob allerdings die TMC-Tags von OSM dabei genutzt werden weiss ich nicht.
Ich kling mich jetzt für ein paar Tage aus.
MfG
Senni
Sagen wir es mal so. Aus Nutzersicht waere es natuerlich toll, wenn ich jederzeit aktuelle Strassendaten mit durchgaengigen, korrekten TMC-Informationen bekommen koennte - so dass ich ohne komplizierte Logik eine Anfrage wie “ich hab hier eine Staumeldung fuer Segmente A,B,C, welche OSM-Ways sind betroffen” stellen kann und richtige und vollstaendige Antworten bekomme. Das waere fuer mich als Nutzer das beste.
(Selbst in dieser perfekten Welt waere vieles nicht trivial - wenn zum Beispiel ein Meldungstyp “Fahrbahnverengung” den TMC-Code eines Rastplatzes betrifft, dann sind damit andere Asphaltflaechen gemeint als wenn fuer den identischen TMC-Code ein “Rastplatz gesperrt”-Meldungstyp rausgeht - der gleiche TMC-Code betrifft mal die Autobahn, die am Rastplatz vorbeifuehrt, und mal die highway=services-Flaeche, die neben der Autobahn liegt. Aber das nur am Rande!)
Aber diese aus Nutzersicht tolle Welt werden wir nie hinkriegen, wir werden auch mit manueller Instandhaltung nie 100% erreichen, und es wird auch immer wieder passieren, dass irgendwas bei uns nicht fehlt, sondern schlicht falsch ist - weil ein Weg gesplittet und eine Relation nicht kopiert wurde, was auch immer, die meisten hier kennen das ja zur Genuege.
Selbst wenn bei uns alles ok ist, so kaemen doch neue Listen von der BASt, an die wir unsere Daten regelmaessig anpassen muessten (und das, obwohl sich in der realen Welt gar nichts aendert - auch komisch, oder).
Das heisst, dass ernsthafte Nutzer sich eh nie 100% auf OSM verlassen koennen, sondern die OSM-Infos mit geeigneten Routing-Algorithmen ueberpruefen muessen.
Wir koennten also maximal etwas liefern, was ein bisschen besser ist als das, was man sich selber ausrechnen kann. Im Unterschied zu dem, was man sich selber ausrechnen kann, wuerde unseres aber staendig mit Arbeitszeit “nachgefuettert” werden muessen. Und es wuerde die Arbeit unbeteiligter Mapper an anderen Dingen beeintraechtigen (weil die sich damit auseinandersetzen muessten, was das seltsame TMC-Tag da jetzt soll).
Unterm Strich, wenn man den moeglichen Nutzen auf die eine Waagschale legt und den Aufwand und die stoerenden Seiten auf die andere, scheinen mir die negativen Seiten zu ueberwiegen.
Bye
Frederik
Wo ist OSM denn je zu 100% fertig/aktuell? Es wird immer etwas geben was wir zwar erfassen können aber nicht vollständig erfasst ist bzw. nicht mehr aktuell ist.
Man braucht sich nur einmal die Postleitzahlen anschauen. Diese erfüllen dann auch den Tatbestand der Änderung ohne das sich etwas in der realen Welt ändert.
Dies würde ziemlich vieles in OSM in Frage stellen. Sei es bei Adressen die angabe des landes der Plz oder ähnliches.
Ähnliches gilt für die Routen des ÖPNV. Auch Relationen von Straßen könnte man sich sparen, da diese ebenfalls aus externen Quellen mehr oder weniger genau über unser Netz gelegt werden können.
Die Frage ob man andere Nutzer damit behindert möchte ich grundsätzlich anzweifeln. Aber man läuft natürlich Gefahr, dass Nutzer die das nicht verstehen es weder pflegen noch darauf Rücksicht nehmen. Aber das gilt bei allen Datenstrukturen in OSM. Warum sonst gehen Grenzen und Küstenlinien immer wieder mal auseinander? Bestimmt nicht weil jemand da böse absichten hat.
Und das bestätigt meine Ansicht, daß wir uns mit TMC-Daten in OSM nicht rumärgern beschäftigen sollten.
tl;dr: Werden nicht gebraucht, sind permanent zu pflegen, “stören” → weg damit.
als Referenz “wie hängt das alles zusammen? Welche Straßen … gibt es?” allerdings prima zu verwenden.
Gruss
walter
Natürlich erwartet (hoffentlich) niemand, dass die Daten, die in OSM vorhanden sind, zu 100% perfekt wären. Wenn wir wirklich ein perfektes Mapping, oder meinetwegen auch nur ein perfektes Straßenrouting, als Ziel anstreben würden, könnten wir gleich sämtliche Straßendaten in die Tonne hauen, mit dem Argument, dass diese immer Fehler enthalten, weil sie manuell gemappt sind. Natürlich enthalten OSM-Daten Fehler, so wie jede andere Karte auch, aber es ist doch gerade die Stärke von OSM, dass diese Fehler von einer Community behoben werden können, sobald sie jemand entdeckt oder meldet, im Gegensatz zu kommerziellen Karten, wo der Nutzer auf ein Update hoffen und dafür bezahlen müsste.
So weit ich das bisher sehen kann, ändern sich bei einem solchen Update nicht auf einen Schlag alle Location Codes, sondern es gibt graduelle Änderungen. Die meisten Codes wären von einem Update also gar nicht betroffen. Man könnte genau so argumentieren, dass Verwaltungsgrenzen nicht in OSM gehören, weil es ja ständig Gemeindereformen gibt - und man da die Daten ändern muss, obwohl man in der realen Welt keinen Unterschied sieht.
Es geht ja auch gar nicht darum, sich zu 100% auf die Daten zu verlassen. Natürlich müssen die Daten überprüft werden. Es ist aber wesentlich einfacher, vorhandene Daten auf ihre Konsistenz und Richtigkeit hin zu überprüfen, als sie komplett auszurechnen.
Das ist doch aber genau das gleiche Problem wie z.B. bei Busrouten, wobei die sogar noch in größerer Zahl vorhanden sein dürften und sich dynamischer ändern. Natürlich kann ein Nutzer sich diese auch selbst von den ÖPNV-Unternehmen holen statt aus OSM und man würde so das Risiko vermeiden, dass ein Mapper eine Busroutenrelation zerschießt. Das hätte man aber auch keine OSM-ÖPNV-Karten. Deshalb sollte es natürlich das Ziel eines wie auch immer gestalteten Tagging sein, es so einfach wie nur möglich zu halten, damit auch Nutzer, die sich mit TMC nicht auskennen, damit keine Probleme bekommen.
Dazu kommt noch das IMHO beste Argument von viw: Wenn wir es schaffen sollten, TMC-Rohdaten von anderen Ländern zu erwerben mit der Möglichkeit sie “in nicht mehr roher Form” einzupflegen (meinetwegen über eine Spende oder was auch immer), könnten wir die aufgearbeiteten Daten als Teil der OSM-Karte auch FOSS-Routing-Projekten anbieten, die sich die Rohdaten selbst nicht leisten können. Als wenn das kein signifikanter Nutzen wäre…
Das Update lässt sich hervorragend automatisieren - >95% aller Punkte ändern sich nicht, die anderen Änderungen sind klein (neue Segmente, neue Punkte) und lassen sich in eine einfache ToDo-Liste umsetzen. Buslinien sind um Größenordnungen schwerer instandzuhalten, und da beschwert sich niemand, dass die nicht in OSM gehören würden!
Das trifft auf jedes beliebige andere Tag auch zu. Wie steht es mit den 3D-Attributen für Gebäude? Das ist ein noch viel größeres Gemenge an unterschiedlichen Dingen, und viele haben Werte die man ohne Nachschlagen nicht interpretieren kann.
Ja, insbesondere: Ein einmal vergebener Code wird auf keinen Fall neu an anderer Stelle vergeben! Alte Daten sind also höchstens ungenau, aber in keinem Fall komplett falsch.
Grundsätzlich gefällt mir, dass man auf diese Weise TMC-Locations in Form von OSM-Objekten abbilden kann, in diesem Fall also als eine Relation. Allerdings sehe ich das Schema etwas problematisch im Hinblick auf zukünftige Bearbeitungen an dieser Kreuzung. Angenommen, jemand teilt die B 521 und L 3209 gemäß einer baulichen Trennung in je zwei Wege auf*. Dann kommen zwei weitere Kreuzungspunkte hinzu. Jemand, der das TMC-Tagging nicht kennt, wird die aber nicht zur TMC-Relation hinzufügen, wie es eigentlich dem korrekten Tagging entsprechen würde. Vielleicht löscht er auch Punkte oder ersetzt sie. Damit würde so ein (ziemlich wahrscheinlicher) Edit das TMC-Tagging aus der Bahn werfen, z.B. weil man die TMC-Punkte dann nur noch auf einer von zwei Richtungsfahrbahnen findet und es so aussieht, als würde man sie in der anderen Richtung gar nicht passieren. So ein Fehler dürfte auch schwer automatisiert zu finden sein, denn wenn man nur prüft, ob eine TMC-Relation an der richtigen Stelle vorhanden ist, findet man ja eine solche - sie ist aber nicht vollständig.
*Nehmen wir mal hypothetisch an, die Kreuzung würde genau so umgebaut werden.