Also dem kann ich nicht zustimmen. Ich markieren die Elemente der Reihe nach. Bei einer Straße und Autobahn ist das ganz einfach, weil man alle Abschnitte bis zu nächsten Kreuzung wählt. Dann kann man die Relation mit einem Klick erstellen und fügt die Tags hinzu. Außerdem erkennt man ob die Stücke alle zusammenhängen indem man sich den Bereich im Josm anschaut der dafür vorgesehen ist. Da ist es egal ob das 5 oder 15 Member sind.
komplexer finde ich an Autobahn Auf- und Abfahrten. Dort muss man nämlich die richtigen Tags finden. Also Fahrtrichtung und Co.
Die Gefahr der beschädigung bei langen Relationen ist durchaus höher. Aber auch die Wahrscheinlichkeit das wenigstens einige Member an der richtigen Stelle überleben auch. Damit sind Streckensperrungen immer wirksam. Nur bei reduzierten Geschwindigkeiten etc. wirkt das nicht mehr auf den gesamten Abschnitt.
Bei kurzen Relationen oder den Punkten geht jedoch mit der Löschung einzelner Punkte schon sämtliche Informationen verloren. Es kann beispielsweise keine Verbindung zwischen Benachbarten Punkten gefunden werden. Wenn zwei Punkte einer Fahrbahn entfallen.
Inzwischen habe ich den vorgeschlagenen 4-Stufen-Plan mal im Proposal aufgeschrieben. Die ersten beiden Stufen sind in Kombination ein Mittelding zwischen den beiden Vorschlägen, dass entweder TMC-Punkte oder TMC-Links mehr Vorteile haben. Ich denke, dass man so die Vorteile von beiden ausnutzen kann - relativ einfaches Mappen, Robustheit gegenüber Fehlern, automatische Validierbarkeit und Nutzen für den Anwender. Die anderen Stufen bauen darauf auf. Wenn sich eine Stufe im Laufe des Proposals als unvorteilhaft herausstellt, kann sie auch wegfallen.
Daneben habe ich auch noch ein wenig an der TMC-Dokumentation gearbeitet und selbst ein wenig mit dem Entschlüsseln von TMC-Meldungen herumprobiert. Dabei habe ich u.a. eine interessante Meldung gefunden, bei der an Location 58:1:22492 ein Tunnel gesperrt ist. Nun ist aber diese Location in den TMC-Tabellen ein Ort (P3.37) und kein Tunnel (P3.1), d.h. die Verbindung zwischen diesem Punkt und dem Tunnel ist nicht logischer / datentechnischer Natur, sondern nur durch die geografische Nähe gegeben, was ein Auffinden dieses Tunnels nicht einfacher macht… Dennoch wäre es natürlich möglich, wenn der Tunnel Teil von geeigneten TMC-Links ist, die an diesem Punkt enden.
Kleinere Objekte wie dieser Tunnel haben keine eigene Location. Es ist also einer der Tunnel auf der angegeben Strecke (es könnte ja mehrere geben) - aus diesem Grund macht es wohl auch keinen Sinn, hier genauere Informationen bekommen zu wollen als es TMC an sich hergibt. Wenn es auf dem TMC-Link nur einen Tunnel gibt, dann lässt sich dieser natürlich auch schnell finden und entsprechend markieren. http://osm.org/go/0GKsSzWo
Ich habe mich noch einmal an die Auswertung dieser TMC-Meldungen gemacht:
Übersetzt habe ich sie jetzt genau so. Mich wundert hier aber, dass Hessen Mobil hier nicht übereinstimmt und stattdessen eine andere Richtung als gesperrt angibt, ebenso wie oben im OSM-Link zu sehen. Die TMC-Meldung ist jetzt natürlich schon ein paar Tage alt, aber die Sperrung besteht wohl langfristig.
Das TMC-Punkt Proposal nimmt langsam Gestalt an. Ich habe die Zusatztags dort mal einfach cid=* statt tmc:cid=* etc. genannt, da ja aus dem type=tmc:point (was ich einfacher finde als type=tmc, tmc:type=point) klar ist, dass es eine TMC-Relation ist und was cid=* etc. hier bedeuten.
Ach ja, weiß zufällig jemand, wie man mit der JOSM-Remote-Funktion eine Relation mit bestimmten Tags erstellen kann, der ein Mapper dann die Relationselemente hinzufügen kann? Das würde das Mappen nämlich deutlich erleichtern, weil JOSM so automatisch den nötigen Bereich herunterladen und alle Tags wie in den Tabellen angegeben basteln würde, das vermeidet Tippfehler bei den Location Codes.
Aber der letzte Absatz zeigt einen möglichen aufwendigeren Weg:
“Other plugins that register additional commands can specify a similar setting to disable the specific command registered by this plugin.”
Ja, diese Import-Funktion scheint sowas zu machen… So ein Script, das eine entsprechende OSM-XML-Datei erzeugt, kann ich sicher basteln. Da muss ich wohl nur noch rausfinden, was ich da für Werte als ID eintrage, damit JOSM erkennt, dass das eine neue Relation sein soll. JOSM benutzt dafür ja negative Zahlen, so weit ich weiß der Reihe nach -1, -2, -3… - aber mein Server weiß ja nicht, welche Zahl beim User, der grad JOSM offen hat, als nächstes kommt. Vielleicht kann man stattdessen auch gar nichts reintun, vielleicht braucht es ein action=“create”… Ich probiere mal damit rum.
Evtl. könnte man bei einem Wert wie -100000 anfangen und von dort aus weiter Richtung -inf zählen. Damit man ggfs. auch mehrere Relationen in einer JOSM-Session aufmachen kann, müsste man entweder auf dem Server den aktuellen Wert halten und bei jedem Aufruf runterzählen oder die relation id irgendwie von einem tmc-Bestandteil ableiten.
TMC-Punkte, von denen man die Koordinaten kennt, könnte man natürlich auch gleich mit aufnehmen und dann in JOSM per ‘Merge’ in bestehende Ways einbauen. Hochladen, fertig.
Letzteres klingt da so ziemlich am einfachsten. Man könnte es z.B. mit id = -(10000000 * cid + 100000 * tabcd + lcd) versuchen, das ist immer noch unter 10^9 und sollte damit klein genug sein, außerdem ist es eindeutig.
Sowas ähnliches hatte ich mir auch überlegt, allerdings hängen die Rollen dieser Nodes wohl von der Geometrie des zu mappenden TMC-Punktes ab (Autobahnkreuz vs. einfache Ampelkreuzung ohne Richtungsfahrbahnen). Man muss also erst einmal die Geometrie kennen, bevor man Member mit Rollen erstellen kann. Mal schauen, ob sich da was automatisieren lässt… Bei einer Autobahn ist es auf jeden Fall klar (getrennte Richtungsfahrbahnen, Einfahrt != Ausfahrt, also immer 4 Nodes).
Die junction reference sollte nicht ref=* heißen - ref ist ein schon sehr oft benutztes Tag, das hier in einem anderen Zusammenhang benutzt würde.
Ich würde noch klar machen, dass alle Tags der Relation aus den Tabellen vorgegeben werden - hier hat der Mapper keine Arbeit. Es ist nur notwendig, die richtigen Member in die Relation hinzuzufügen.
Evtl. könnte man eine Referenz einbauen, zu welcher Straße diese Location gehört - du hast zwar ein intersects=* vorgesehen, womit ich weiß, welche Straße geschnitten wird, aber ich weiß nicht, auf welche Straße sich der Punkt selbst bezieht.
Die Verwendung von intersects in der Art einer Ring-Liste wie TMC sie benutzt finde ich für die OSM-DB eher weniger geeignet, weil man mehrere Zugriffe braucht, um alle Teile einer Kreuzung zu bekommen. Warum das intersects nicht weglassen und bei Bedarf durch eine Relation type=tmc:junction ersetzen? (Nur falls wir eine Anwendung für diese Information finden & in Stufe 3 oder 4 des Proposals)
Wie stellst du dir das mapping von RoadName, FirstName und SecondName aus der LCL auf das name-Tag vor?
Kann man cid und tabcd eventuell zusammenfassen um die Zahl der fixen Tags zu reduzieren? table=58:1 oder etwas in der Art?
Generell wäre ich für mehr sprechende Namen: ‘lcd’ versteht niemand, der sich nicht mit TMC befasst. Warum nicht einfach ‘ref’, was generell für eine Referenznummer benutzt wird?
Den Typ einer Location halte ich für eine wichtige Information, die für die Einordnung einer Meldung gebraucht wird. evtl als location=P1.8 für einen Kreisel
Ja, das kommt da auf jeden Fall noch rein. Dafür mache ich einen Extra-Abschnitt zum Thema “semiautomatischer Import” oder so.
Gute Idee. Das wollte ich eigentlich über eine zweite Relation machen, in der alle Punkte einer Straße sind, aber man kann es auch an die Punkte selbst taggen.
An diese Ring-Liste hatte ich gar nicht gedacht, sondern eher an eines der Name-Felder (müsste SecondName sein), das einem den Namen der kreuzenden Straße oder etwas vergleichbares sagt, und zwar auch dann, wenn besagte Straße nicht in TMC erfasst ist.
Für name=* hatte ich nur FirstName im Sinn, SecondName ist der Name der kreuzenden Straße und RoadName… Könnte ein eigenes Tag bekommen.
Kann man auch machen. Ich fand eine Trennung für klarer.
Ich frage mich, ob diese ganzen Relationen überhaupt jemand versteht oder verstehen muss, der sich nicht mit TMC befasst… Wer sie nutzen will, befasst sich ja damit.
Das würde ich vielleicht class=* nennen und stattdessen lcd=* durch location=* ersetzen.
Jetzt wird’s kompliziert mit den quotes… Ich mache es mal mit Einrückungen.
Zu Wetzlar Ost: Der Mapper (Hans Wurst) weiß auch nichts genaueres, außer dass diese beiden gemappten Auffahrten wirklich gesperrt sind.
Evtl. könnte man eine Referenz einbauen, zu welcher Straße diese Location gehört
Gute Idee. Das wollte ich eigentlich über eine zweite Relation machen, in der alle Punkte einer Straße sind, aber man kann es auch an die Punkte selbst taggen.
Diese Relation existiert ja fast zwangsläufig, aber den zusätzlichen Tag würde ich als “User convenience” begrüßen.
Den Typ einer Location halte ich für eine wichtige Information.
Das würde ich vielleicht class=* nennen und stattdessen lcd=* durch location=* ersetzen.
class klingt gut. Statt location wäre ich noch bei ref - der lcd entspricht exakt der Definition von ref laut wiki ““ref” stands for “reference” and is used for reference numbers or codes.”
Die Verwendung von intersects in der Art einer Ring-Liste wie TMC sie benutzt…
An diese Ring-Liste hatte ich gar nicht gedacht, sondern eher an eines der Name-Felder (müsste SecondName sein)
Wie wäre es dann mit einem etwas anderen Key, z.B. connects_to=* ?
Ich frage mich, ob diese ganzen Relationen überhaupt jemand versteht oder verstehen muss, der sich nicht mit TMC befasst…
Besser wäre es - ich denke genau das ist eines der Hauptprobleme bei der Akzeptanz der Daten.
Für name=* hatte ich nur FirstName im Sinn, SecondName ist der Name der kreuzenden Straße und RoadName… Könnte ein eigenes Tag bekommen.
Gerade in größeren Städten dürfte “FirstName / RoadName” eine recht sinnvolle Wahl sein. Das sollte man wohl dem Mapper überlassen.
Ich lasse die Quotes mal weg und fasse die Änderungen zusammen, die ich eingebaut habe:
cid=* und tabcd=* zu table=* für Location Code Tabelle zusammengefasst.
lcd=* in ref=* für Location Code umbenannt.
ref=* in junction_ref=* für Ausfahrtnummer etc. umbenannt.
class=* für Klasse, Typ, Subtyp hinzugefügt.
road_ref=, seg_ref= und area_ref=* für Location Codes von übergeordneten Locations hinzugefügt.
road_name=* für den Straßennamen hinzugefügt.
intersects=* habe ich erst einmal so gelassen, weil ich den Namen logisch finde - das Tag gibt ja an, welche Straße hier gekreuzt wird, und auf englisch ist das eben "to intersect".
Ja, es stimmt natürlich, dass Verständlichkeit der Daten ein wichtiges Ziel ist. Das versuche ich in dem Proposal auch so weit wie möglich umzusetzen. Allerdings sollte es sowohl für den Mapper als auch für den Nutzer der Daten verständlich sein, und letzterer wird eben am ehesten die TMC-Begriffe kennen und sich dann wundern, warum bei OSM alles anders heißt. Am besten sind deshalb Tags, die für beide verständlich sind.
Es geht im Moment ein wenig langsam voran, da ich momentan nicht viel Freizeit zur Verfügung habe… Das aktuelle Semester geht zu Ende, da ist alles etwas stressig, selbst wenn man nicht mehr zu den Studierenden gehört
EDIT: Import-Skript für TMC-Punkte funktioniert (derzeit aber nur lokal auf meinem Rechner freigeschaltet, um versehentliche Uploads zu vermeiden).
Die Erklärungen in der Tabelle und die Zeichnungen sind gut verständlich - denke ich.
Irgendwie erschlägt einen beim ersten Blick die lange Erklärung aber ziemlich. Vielleicht eine Zeichnung einer komplexen Kreuzung nach oben und die restlichen Beispiele getrennt davon?
Wir sollten uns überlegen, ob die Rollen zwingend gefordert werden oder nur recommended sind - falls letzteres, dann sollte man das etwas kleiner darstellen.
Mit den Namen der Rollen kann ich mich nicht so recht anfreunden, die klingen mir etwas kompliziert. Der Unterschied zwischen posdir (in Richtung negativer Location) und posside (auf der Seite der positiven Location) ist zwar durch die TMC-Definitionen so gegeben, aber wird beim Mappen sicher für einiges Kopfzerbrechen sorgen.
Wie wäre es mit etwas wie from_pos, to_pos, from_neg, to_neg? Das sollte auch bei den anderen Varianten ähnlich machbar sein.
Ja, das deckt sich mit meinem Eindruck. Ich denke, ich werde es genau so machen, dass man ein “typisches” Beispiel ganz oben hat, dass dann unten weiter erklärt wird.
Ich würde sie entweder erforderlich machen oder ganz weglassen. Wenn man sie optional macht, hat man sie stellenweise getaggt und stellenweise nicht - davon hat man als Auswerter nicht viel. Ich bin mir nicht sicher, ob man sie wirklich braucht. Als Anwendung hatte ich mir gedacht, dass ein Router daraus ableiten kann, in welche Richtung er einen TMC-Punkt durchfährt, wenn er die benachbarten Punkte nicht durchfährt (z.B. weil er die Straße vorher an anderer Stelle verlässt).
Ja, das stimmt leider, mit den aktuellen Rollen bin ich auch noch nicht wirklich zufrieden. Ich hatte auch ursprünglich eine ähnliche Idee, wie du hier vorschlägst, nur die Namen für das Zusammenlegen von Rollen, wenn es nur zwei Nodes sind, bereiten mir noch etwas Kopfzerbrechen. Normalerweise fallen ja immer zwei Nodes zusammen, die “nebeneinander” liegen, wenn man sich das Quadrat ABCD im Proposal ansieht. Deshalb hatte ich mir überlegt, dass jeweils nebeneinander liegende Nodes eine ähnliche Rolle bekommen könnten, damit man sie gut zusammenlegen kann.
Ich bin für weglassen! Denn die Dinge ergeben sich später aus den Links. Bis dahin hat der Router aber deutlich mehr Arbeit, weil er sich die Route berechnen müsste und dann die Richtung aus dem nächsten Punkt ableiten kann.
