Überarbeitung von TMC / TPEG

viw · 2014-01-13 18:00:52

mueschel wrote:

Gegen die ausschließliche Verwendung von Links sprechen einige Punkte:
- Punkte kann ich automatisch überprüfen, weil Daten aus der TMC-Datenbank mit denen in OSM übereinstimmen müssen. Bei Links, die in keiner anderen Datenbank auftauchen und erst aus den TMC-Daten rekonstruiert werden müssen wird es kompliziert.

Es ist klar welcher punkt mit welchem Punkt zu verbinden ist. Damit ist auch klar welche Links existieren müssen. Damit kann man die Links zwischen Punkten sehr leicht auf Vollständigkeit prüfen.

mueschel wrote:

- Viele Meldungen beziehen sich gerade nicht auf Links, sondern auf Punkte. Wie stellst du "Ausfahrt gesperrt" dar? Dabei nützen dir Links nichts, du musst über die Struktur eines Punktes Bescheid wissen - genau das leistet das Proposal von Manuel

Wie will ich denn umsetzen das Auffahrt XY gesperrt ist? Es muss also einen Weg geben, der diese Eigenschaft Auffahrt zu TMC Loc bietet. Diesen kann ich anhand der Tags der Relation erkennen und unbenutzbar machen. dann heißt die Relation nicht mehr TMC Link sondern TMC Auffahrt.

mueschel wrote:

- Es gibt keine Möglichkeit, Links automatisch anzulegen. Das ist eine sehr große Arbeit die von Hand gemacht werden muss, weil ich sehr viele Member in die Relation aufnehmen muss. Locations sind viel einfacher. Ein Element ist für die Basis-Funktionalität ausreichend.

Diese Arbeit muss entweder einmal in OSM gemacht werden, oder nachher in jeder Routingsoftware automatisch. Außerdem hast du ja das gleiche Problem wenn du am Autobahnkreuz eben vier dieser Punkte in einer Location relation anlegen musst. Es wäre also das Gleiche.

Bei allen Routern die ich kenne werden zum Routing Kanten verwendet und keine Punktobjekte. damit müssen also die Eigenschaften von Punktobjekten in Kanten übersetzt werden. Diese Arbeit nimmst du mit den Relationen ab.

MHohmann · 2014-01-13 20:32:35

Also, ich denke eine mögliche Lösung hier wäre eine Kombination von Elementen aus beidem, d.h. es sollte sowohl Relationen für TMC-Punkte als auch für TMC-Links, d.h. die Strecken zwischen Punkten geben. Allerdings sollten die TMC-Punkt-Relationen im Gegensatz zu meinem Vorschlag nicht unbedingt besagte OSM-Nodes enthalten, sondern ebenfalls OSM-Ways. Bei einem Autobahnkreuz hätte man also Routenrelationen für die Verbindungen zwischen den beiden Autobahnen, genau wie bei den Links zwischen TMC-Punkten. Auf diese Weise lässt sich eine gesperrte Ausfahrt viel besser lokalisieren als wie von mir vorgeschlagen mit 4 Nodes pro Autobahnkreuz.

Hier mal ein einfaches Beispiel, wie das aussehen könnte - zu taggen als Routenrelation, die dort beginnt und endet, wo man die Hauptfahrbahnen von A 2 und A 7 verlässt bzw. befährt:

type=tmc
tmc:type=ramp
tmc:cid=58
tmc:tabcd=1
tmc:from_point=10509 (AK Hannover-Ost auf der A 2)
tmc:from_road=50080 (A 2)
tmc:from_dir=positive (positive Richtungsfahrbahn der A 2 nach TMC-Logik)
tmc:to_point=12342 (AK Hannover-Ost auf der A 7)
tmc:to_road=50163 (A 7)
tmc:to_dir=negative (negative Richtungsfahrbahn der A 7 nach TMC-Logik)

Damit hätte man nun diese Verbindung eindeutig erfasst und könnte aus einer Verkehrsmeldung ableiten, was gesperrt ist. Allerdings braucht man so für jedes Autobahnkreuz 8 Relationen, und so ganz beantwortet das nicht alle Fragen nach dem Tagging...

Was macht man mit den geraden Zwischenstücken auf der Hauptfahrbahn? Brauchen die auch eine Relation? Wie wird eigentlich gemeldet, dass ein solches gesperrt ist? Das gleiche gilt für solche Zwischenstücke bei einer Autobahnausfahrt.
Was macht man bei einer ganz einfachen Kreuzung mit nur einem Node? Gar keine Relation - also letztlich gar nichts? Würde Sinn machen.
Wie kann man TMC-Gebiete mappen? Im TMC-Datenmodell gehört jeder Punkt einem Gebiet an. Wenn man also eine Relation pro Punkt hätte, könnte man diese Relationen alle zusammen in eine weitere Relation packen und die dann als TMC-Gebiet taggen. Das geht nicht, wenn man für manche TMC-Punkte gar keine Relation hat. Links zwischen Punkten gehören nicht zu einem Gebiet, sondern sind ausgedehnte Objekte. Hier würden sich vielleicht eher anbieten, TMC-Gebiete als Multipolygone zu mappen, ähnlich den Verwaltungsgrenzen. Allerdings sehe ich da eine ähnliche Problematik wie bei den Postleitzahlen und den Wahlkreisen, wenn man noch eine solche Flächenkategorie einführt, die eng mit Verwaltungsgrenzen verknüpft ist. Nützlich sind solche Gebiete dennoch, weil über TMC Wetterwarnungen dafür übermittelt werden können.

viw · 2014-01-13 20:57:44

Sind die Zwischenstücke wirklich wichtig? Es ist doch nur wichtig im Zweifelsfall zu verhindern das auf oder abgefahren werden kann. Man dürfte dann also für diese Relation nur die jeweils exklusiven Wege benutzen. Wenn das Zwischenstück dann gesperrt ist, dann ist sind davon zwei Auf- bzw. Abfahrten gestört/gesperrt. Halte ich für kein Problem.
Eventuell gibt es bei Ausfahrten auch die gleichen Meldungen wie bei Parkplätzen. Allerdings nehmen bei neugebauten/sanierten Strecken diese Zwischenstücke ab.
http://www.openstreetmap.org/#map=16/51.0624/13.6038

Relationen können auch nur ein Element enthalten, aber es ist auch ein Node möglich. Sollte das jedoch wieder ein doppelter sein, sind Relationen wegen der doppelten Tags besser.

Man kann in Relationen (Sammlungen) sowohl die einzelnen Location Relationen aber auch die vielleicht einzeln vorkommenden Nodes zu den Regionen vereinigen.

Warum die Links nicht zu den Regionen gehören sollen, weiß ich nicht. Insbesondere wenn hier Wetterinformationen oder sowas geliefert werden, sind das ja nicht nur Punkte sondern wieder vorallem die Wege die davon betroffen sind.

Last edited by viw (2014-01-13 20:59:52)

mueschel · 2014-01-13 21:36:40

Das sieht schon wieder nach einem komplexen System aus. Ich bin dagegen, mit Links als Grundlage zu arbeiten. Lasst mich meine Überlegungen etwas weiter ausführen:

TMC wird sicher ein Randthema in OSM bleiben - die meisten Mapper werden auch mit einem neuen Schema keine Lust haben sich damit zu beschäftigen. Das führt zu zwei Dingen: Die Wartung muss einfach bleiben, weil sich nicht viele Mapper dafür begeistern lassen. Und, das grundlegende Konzept muss in ein oder zwei Sätzen allgemeinverständlich erklärbar bleiben, sonst wird das ganze nicht akzeptiert.
Auch das Eintragen darf nicht in zu viel Arbeit ausarten. Deswegen sollten wir das ganze modular angehen mit einfachen Dingen, mit denen man das meiste umsetzen kann zuerst.
Schauen wir uns die nötige Arbeit an: Punkt-Locations anlegen, wie zuerst von Manuel beschrieben: Wir reden von 26k Lokationen. Bei komplexen Kreuzungen eine Relation mit vier Punkten wie vorgeschlagen - das ist eine absolut überschaubare Aufgabe (ich will nicht sagen, dass es wenig Arbeit ist, aber das ist machbar). Mit diesen Punkten lassen sich schon viele Dinge machen, zum Beispiel Meldungen auf der Karte platzieren.
Dann der Vorschlag von viw: Link-Relationen anlegen. Es gibt grob geschätzt ebenfalls 26k Links zwischen Punkten, allerdings sind in vielen Fällen zwei Relationen, je eine pro Fahrtrichtung notwendig. Mittlerer Abstand zwischen den Knoten sind vielleicht 5km mit vielleicht 10 ways. Wir haben also mehr Relationen mit viel mehr Members zu pflegen.
Welche Variante ist robuster gegen unabsichtliches Beschädigen? Ich weiß es nicht.
Ein wichtiger weiterer Punkt: Die Link-Relationen lassen sich in vielen Fällen (gerade bei Autobahnen) automatisch gewinnen: Es gibt ohnehin die Straßenrelationen, die von relativ vielen Leuten gepflegt werden. Nun braucht es nur einen Algorithmus der sich diejenigen Wegstücke der Straße herauspickt, die den passenden Knoten von Anfangs- und Endpunktlokation enthalten und dann die dazwischenliegenden Wegstücke herausfinden. Dafür ist nur ein gewöhnlicher Routing-Algorithmus notwendig - mit Programmierarbeit, aber ohne zusätzliche zu pflegende Relationen.

Mein Vorschlag: Zunächst werden Punkt-Locations gemappt, wie beschrieben mit einigen Knoten. Dazu können dann noch Wege mit entsprechenden Rollen in die Relation eingepflegt werden, um Auf/Abfahrten und ähnliches zu kennzeichnen. Zusätzlich können Link-Relationen angelegt werden, die den genauen Streckenverlauf zwischen den Punkten angeben - zum Beispiel bei komplizierteren Streckenverläufen oder einfach der Vollständigkeit halber.

MHohmann · 2014-01-13 21:51:32

viw wrote:

Sind die Zwischenstücke wirklich wichtig? Es ist doch nur wichtig im Zweifelsfall zu verhindern das auf oder abgefahren werden kann. Man dürfte dann also für diese Relation nur die jeweils exklusiven Wege benutzen. Wenn das Zwischenstück dann gesperrt ist, dann ist sind davon zwei Auf- bzw. Abfahrten gestört/gesperrt. Halte ich für kein Problem.

Ich würde sie für nicht mehr oder weniger wichtig halten als die Wege der Ausfahrten. Schließlich können hier genau so Sperrungen, Bauarbeiten oder ähnliche Meldungen vorliegen. Die Frage ich nur, wie sowas in einer TMC-Meldung codiert wird (ich versuche das rauszufinden), dann könnte man vielleicht genau das auf dieses Zwischenstück taggen. In diesem Proposal gibt es Tags für die Zwischenstücke - allerdings nicht für die Auf- bzw. Abfahrten.

Eventuell gibt es bei Ausfahrten auch die gleichen Meldungen wie bei Parkplätzen.

Das kann sein, da muss man wohl einfach mal die elektronischen Ohren offen halten und schauen, was so reinkommt.

Allerdings nehmen bei neugebauten/sanierten Strecken diese Zwischenstücke ab.
http://www.openstreetmap.org/#map=16/51.0624/13.6038

Naja, auf der A 4 hat man ja immerhin noch ein Zwischenstück zwischen Beginn (Abzweig zur A 17) und Ende (Auffahrt von der A 17 auf die A 4) des Dreiecks, das zu keinem der beiden TMC-Links (A 4 östlich bzw. westlich des Dreiecks) gehört. Genau so ist die Lage ja auch bei Parkplätzen oder einfachen Ausfahrten.

Relationen können auch nur ein Element enthalten, aber es ist auch ein Node möglich. Sollte das jedoch wieder ein doppelter sein, sind Relationen wegen der doppelten Tags besser.

Sehe ich auch so.

Man kann in Relationen (Sammlungen) sowohl die einzelnen Location Relationen aber auch die vielleicht einzeln vorkommenden Nodes zu den Regionen vereinigen.

Das kann man machen. Wenn man da aber einen einzelnen Node reinpackt, wo taggt man dann dessen Location Code? Eine Relation wäre dann doch wieder besser.

Warum die Links nicht zu den Regionen gehören sollen, weiß ich nicht. Insbesondere wenn hier Wetterinformationen oder sowas geliefert werden, sind das ja nicht nur Punkte sondern wieder vorallem die Wege die davon betroffen sind.

Das liegt daran, dass das TMC-Datenmodell an sich keine Links zwischen Punkten kennt, sondern nur Punkte, Straßen als ganzes (oder Segmente) und Flächen. Punkte, Segmente, Straßen und Flächen können eine Referenz auf eine sie enthaltende Fläche haben - Links dagegen nicht, sondern nur ihre Endpunkte. Für eine lange Bundesstraße kann dann z.B. die Referenz auf die Fläche Deutschland weisen, aber das hilft einem nicht wesentlich, wenn nur für einen Teil Deutschlands eine Warnmeldung kommt.

viw · 2014-01-14 07:03:58

mueschel wrote:

Das sieht schon wieder nach einem komplexen System aus. Ich bin dagegen, mit Links als Grundlage zu arbeiten. Lasst mich meine Überlegungen etwas weiter ausführen:
Schauen wir uns die nötige Arbeit an: Punkt-Locations anlegen, wie zuerst von Manuel beschrieben: Wir reden von 26k Lokationen. Bei komplexen Kreuzungen eine Relation mit vier Punkten wie vorgeschlagen - das ist eine absolut überschaubare Aufgabe (ich will nicht sagen, dass es wenig Arbeit ist, aber das ist machbar). Mit diesen Punkten lassen sich schon viele Dinge machen, zum Beispiel Meldungen auf der Karte platzieren.
Dann der Vorschlag von viw: Link-Relationen anlegen. Es gibt grob geschätzt ebenfalls 26k Links zwischen Punkten, allerdings sind in vielen Fällen zwei Relationen, je eine pro Fahrtrichtung notwendig. Mittlerer Abstand zwischen den Knoten sind vielleicht 5km mit vielleicht 10 ways. Wir haben also mehr Relationen mit viel mehr Members zu pflegen.
Welche Variante ist robuster gegen unabsichtliches Beschädigen? Ich weiß es nicht.
Ein wichtiger weiterer Punkt: Die Link-Relationen lassen sich in vielen Fällen (gerade bei Autobahnen) automatisch gewinnen: Es gibt ohnehin die Straßenrelationen, die von relativ vielen Leuten gepflegt werden. Nun braucht es nur einen Algorithmus der sich diejenigen Wegstücke der Straße herauspickt, die den passenden Knoten von Anfangs- und Endpunktlokation enthalten und dann die dazwischenliegenden Wegstücke herausfinden. Dafür ist nur ein gewöhnlicher Routing-Algorithmus notwendig - mit Programmierarbeit, aber ohne zusätzliche zu pflegende Relationen.

Wo das Thema komplex ist, weiß ich noch nicht. TMC-Links sind einfach nur eine Zusammenfassung aller Wege zwischen zwei Punkten. Das ist das was jeder Router braucht um die Informationen zu verarbeiten.
Will ich hingegen Meldungen auf der Karte darstellen, reichen die ungefairen Koordinaten der BaSt aus. Viel besser wird es mit Relationen für Autobahnen auch nicht.
Der Rechenaufwand auf Autobahnen die Links zu erzeugen ist bei zwei Relationen je 4 Punkte auch nicht gerade schnell gemacht. Vielleicht haben wir auch 52k Links. Aber dann ist die gesamte Arbeit gemacht. Jede Routingsoftware weiß welche Wege gemeint sind. Arbeit wird nicht doppelt und dreifach gemacht. Links sind robuster als einzelne Knoten wenn sie aus mehreren Membern bestehen.

MHohmann · 2014-01-14 08:39:41

Vielleicht hilft folgende Idee weiter, die ich letzte Nacht um 1:24 hatte - da war mein Computer schon aus: ein 4-Stufen Plan.

Stufe 1: TMC-Punkte
Die Punkte werden so gemappt, wie ursprünglich von mir vorgeschlagen und wie von mueschel favorisiert, d.h. als eine Relation pro TMC-Punkt, die jeweils bis zu 4 OSM-Nodes enthält. Das sollte sich relativ einfach machen lassen und könnte mit einer automatischen Validierung sowie einer Karte, auf der die Punkte angezeigt werden, unterstützt werden. Zusätzlich kann man (automatisch) Relationen für TMC-Segmente und TMC-Straßen erstellen, die aus den TMC-Punkten dieser Objekte bestehen.
Mit dieser Stufe kann ein Router bereits feststellen, welche Punkte auf der von ihm berechneten Route liegen - denn die gemappten Nodes sind immer dort, wo sich Wege teilen, und die erfasst ein Router ohnehin in seinem Routinggraphen. Er kann also unmittelbar erkennen, ob eine TMC-Meldung für diese Route relevant ist oder nicht.
Stufe 2: TMC-Links
Die Links werden so gemappt, wie von viw favorisiert - als Routen-Relationen, die jeweils zwei TMC-Punkte auf der gleichen Straße verbinden. Die Start- und Endpunkte sind dabei jeweils die zuvor in den TMC-Punkten erfassten Nodes. Das lässt sich nicht nur leicht validieren, sondern auch halbautomatisch erstellen - mit einem Router sucht man die Strecke zwischen zwei Nodes heraus und überprüft sie dann auf Richtigkeit. Am Ende hat man ein Netzwerk aus Punkten und Links (Mathematiker nennen es einen Graphen), das sich auf Konsistenz und Vollständigkeit prüfen lässt.
Mit dieser Stufe wird es nun zusätzlich möglich, TMC-Meldungen zu lokalisieren, ohne dafür eine Route berechnet zu haben (und ohne für jede Meldung eigens eine solche berechnen zu müssen). Das verringert deutlich den Rechenaufwand. Stattdessen kann ein Router nun jede TMC-Meldung, die auf einem oder mehreren solchen Links liegt, direkt diesen zuordnen und so den dortigen Zeitverlust für die Routenplanung einbauen.
Stufe 3: TMC-Gebiete
Jeder Punkt, jedes Segment und jede Straße ist im TMC-Datenmodell (maximal) einem Gebiet zugeordnet. Auch Gebiete sind wieder übergeordneten Gebieten zugeordnet. Das lässt sich dadurch abbilden, dass die entsprechenden Relationen für TMC-Punkte etc. in Relationen aufgenommen werden, die dann jeweils ein Gebiet beschreiben. Diese Relationen lassen sich automatisch erstellen, sobald man die Informationen aus Stufe 1 erfasst hat (man könnte es also auch vorziehen).
Mit dieser Stufe bekommt man zusätzlich die Möglichkeit, Meldungen zu lokalisieren, die sich auf ein TMC-Gebiet beziehen - also z.B. Wetterwarnungen oder ähnliches. Diese lassen sich nun auf Straßen und Punkte abbilden und können dem Benutzer beim Befahren des Gebiets als Warnhinweis gezeigt oder auf der Karte dargestellt werden.
Stufe 4: Detaillierte Kreuzungen
Als letztes kann man noch Kreuzungen / Autobahnkreuze, die etwas komplexer sind, im Detail erfassen, d.h. mit Verbindungsstücken zwischen den kreuzenden Straßen, wie oben von mir vorgeschlagen. Diese Verbindungen sind auch wieder Routen, die aber diesmal jeweils zu einer Kreuzung von TMC-Straßen gehören.
Mit dieser Stufe kann man nun zusätzlich TMC-Meldungen lokalisieren, die sich auf gesperrte Ausfahrten beziehen - genau so wie es die TMC-Links schon für Meldungen entlang der Straßen ermöglichen, d.h. ohne ein Routing dafür zu benutzen. Damit hat man nun ein komplettes Bild, welche Strecken frei sind und welche gesperrt.

Diese 4 Stufen sollten dabei jeweils separate Proposals sein, d.h. man kann sie nacheinander ausarbeiten, vorschlagen und dann natürlich auch in die Tat umsetzen. Jede Stufe bietet einen Zugewinn gegenüber der vorherigen. Außerdem wird das Mapping einer Stufe dadurch erleichtert, dass die Daten der vorherigen Stufe bereits vorhanden sind. Auf jeder Stufe kann man außerdem automatische Konsistenz- und Vollständigkeitsprüfungen laufen lassen.

Das ganze System, TMC-Informationen in Relationen zu packen, hat noch einen Vorteil: Sollte TMC in der Zukunft abgelöst und nicht mehr benutzt werden, lassen sich alle TMC-Informationen in einem automatisierten Vorgang rauswerfen, indem man diese Relationen löscht. Damit ist sichergestellt, das wir keine schwer zu entsorgenden Altlasten produzieren (was ja ein paar Mal als Gegenargument gegen das Erfassen von TMC angeführt wurde).

viw · 2014-01-14 11:16:16

MHohmann wrote:

Vielleicht hilft folgende Idee weiter, die ich letzte Nacht um 1:24 hatte - da war mein Computer schon aus: ein 4-Stufen Plan.

Ich bin mir nicht ganz sicher ob diese Reihenfolge richtig ist. Aber ich gehöre auch nicht zu den Nutzern dieser Daten. Wenn insbesondere du als Entwickler der Navigationssoftware meinst das in dieser Reihenfolge die meisten Erfolge zu erziehlen sind, dann bitte.
Meine bedenken liegen lediglich darin, dass man zwar die Meldungen überprüfen kann, ob sie eine route betreffen, nicht aber welche Konsequenzen man daraus ziehen müsste.
Beispiel Streckensperrung. Klar ist der node auf meiner Route. Aber ist es die Gegenrichtung? Ist es die Auffahrt? Ist es nur die Weiterfahrt wo ich ohnehin abfahren will etc.

MHohmann · 2014-01-14 11:44:50

viw wrote:

Ich bin mir nicht ganz sicher ob diese Reihenfolge richtig ist. Aber ich gehöre auch nicht zu den Nutzern dieser Daten. Wenn insbesondere du als Entwickler der Navigationssoftware meinst das in dieser Reihenfolge die meisten Erfolge zu erziehlen sind, dann bitte.

Sicher nicht unmittelbar die meisten Erfolge. Dafür braucht es sicher die von dir vorgeschlagenen Links. Aber ich denke, die sind einfacher zu generieren und zu überprüfen, wenn man schon die Punkte hat - letztere dürften einfacher zu setzen sein. Und ja, die Überlegung mit den Nodes auf der Route kommt tatsächlich daher, dass ich mich gefragt habe, welche Information ich z.B. bei einem Router wie nutzen könnte.

Meine bedenken liegen lediglich darin, dass man zwar die Meldungen überprüfen kann, ob sie eine route betreffen, nicht aber welche Konsequenzen man daraus ziehen müsste.
Beispiel Streckensperrung. Klar ist der node auf meiner Route. Aber ist es die Gegenrichtung? Ist es die Auffahrt? Ist es nur die Weiterfahrt wo ich ohnehin abfahren will etc.

Das sollte sich schon ablesen lassen. Wenn ich Beispiel die Meldung bekomme "Stau auf der Strecke ab Punkt 1 in positiver Richtung mit Ausdehnung bis zum nächsten Punkt" dann kann ich aus der TMC-Punkt-Relation ablesen, welches dieser nächste Punkt ist. Dann kann ich überprüfen, ob beide Punkte auf meiner Strecke liegen, ob ich also den Abschnitt überhaupt durchfahre. Als nächstes kann ich überprüfen, in welcher Reihenfolge ich die beiden Punkte durchfahre, um zu wissen, ob die positive Richtung für mich relevant ist.

Klar, Auffahrten kann man so noch nicht wirklich umfassend behandeln - vielleicht eingeschränkt. Wenn ich eine Meldung der Form "Auffahrt gesperrt von Punkt 1 in Richtung Straße 2 / Punkt 3 in positiver Richtung" kann ich überprüfen, ob meine Route den Punkt 1 enthält sowie den folgenden Punkt auf Straße 2, oder eben Punkt 3. Wirklich umfassend kann man das dann in Stufe 4, die aber auch den größten Aufwand bedeutet.

Sinn dieses Planes ist es deshalb vor allem, schon mit relativ kleinem Aufwand ein (wenn auch noch nicht in vollem Umfang) nutzbares System zu bekommen, dessen Nutzen man in verdaulichen Happen weiter ausbauen kann. Am Ende hätte man ja durchaus sowohl Links als auch Punkte, und ich denke, in dieser Reihenfolge ist es einfacher, beides aufzubauen. Natürlich könnte man stattdessen auch zuerst Links mappen und dann Punkte generieren o.ä., das halte ich persönlich allerdings für etwas aufwändiger, da ein Link mehr Daten (alle Wegstücke) braucht, die man sich zusammenklicken muss. Wenn man dagegen die Punkte hat und z.B. das JOSM-Routing-Plugin, ist sowas schneller generiert und geprüft.

mueschel · 2014-01-14 19:46:02

Die Stufen 1 und 2 entsprechen ja auch meiner Ansicht, da bin ich also dafür.
Und wie gesagt, die meisten Links kann eine halbwegs intelligente Software von selbst bestimmen indem die Straßen-Relation (die von vielen Usern verstanden und aktiv gepflegt wird, im Gegensatz zu den TMC-Relationen) analysiert werden.

Über Stufe 3 bin ich mir nicht im klaren: Ist das wirklich notwendig? Punkte und Links brauchen wir, um die Einträge in der TMC-Tabelle auf OSM-Objekte zu mappen. Bei Areas ist das nicht nötig - aus der TMC-Tabelle bekomme ich eine Liste an enthaltenen Punkten, und diese kann ich dann in OSM suchen.

Stufe 4 hingegen würde ich als optional in 1 und 2 integrieren - in Form von Wegen mit einer bestimmten Rolle innerhalb der Punkt-Relationen.

MHohmann · 2014-01-14 23:48:44

mueschel wrote:

Über Stufe 3 bin ich mir nicht im klaren: Ist das wirklich notwendig? Punkte und Links brauchen wir, um die Einträge in der TMC-Tabelle auf OSM-Objekte zu mappen. Bei Areas ist das nicht nötig - aus der TMC-Tabelle bekomme ich eine Liste an enthaltenen Punkten, und diese kann ich dann in OSM suchen.

Das könnte man auch machen. Ich hatte mir nur gedacht, wenn man auch noch diese (relativ wenigen, verglichen mit den Punkten) Codes einbaut, braucht es die externe Tabelle nicht mehr, um den richtigen Ort zu finden.

Stufe 4 hingegen würde ich als optional in 1 und 2 integrieren - in Form von Wegen mit einer bestimmten Rolle innerhalb der Punkt-Relationen.

Das hatte ich mir anfangs auch überlegt, bin dann aber davon abgekommen, weil z.B. eine Verbindung zwischen zwei Autobahnen nicht zu einer TMC-Punkt-Relation gehören müsste, sondern zu zweien - weil ein Autobahnkreuz zwei Location Codes hat. Ich habe es auch deshalb hinten angestellt, weil es die meiste Arbeit macht und ein Proposal komplexer macht. Stufen 1 und 2 lassen sich einfacher und zügiger realisieren.

mueschel · 2014-01-15 13:25:31

Ich halte 2 für deutlich komplexer als 4:
- Die Einträge von 4 umfassen jeweils nur sehr wenige Wege (in der Regel 1-5, längere Auf/Abfahrten sind wohl selten vorhanden), und diese liegen in einem räumlich sehr kleinen Bereich
- Bei den meisten Locations ist 4 nicht notwendig, weil sie nicht komplex gemappt sind

Hast du über meine Idee, die Links für Stufe 2 automatisch aus den Straßenrelationen zu extrahieren nachgedacht? Wenn dem so ist, dann wäre eine Menge Arbeit nicht notwendig.

MHohmann · 2014-01-15 14:01:53

mueschel wrote:

Ich halte 2 für deutlich komplexer als 4:
- Die Einträge von 4 umfassen jeweils nur sehr wenige Wege (in der Regel 1-5, längere Auf/Abfahrten sind wohl selten vorhanden), und diese liegen in einem räumlich sehr kleinen Bereich
- Bei den meisten Locations ist 4 nicht notwendig, weil sie nicht komplex gemappt sind

Na gut, das stimmt. Ich bin mir noch nicht ganz schlüssig, wie man sowas am besten taggen könnte / sollte, aber das kann man sich ja überlegen.

Hast du über meine Idee, die Links für Stufe 2 automatisch aus den Straßenrelationen zu extrahieren nachgedacht? Wenn dem so ist, dann wäre eine Menge Arbeit nicht notwendig.

Ja, wobei ich da noch nicht 100% schlüssig bin. Also automatisch generieren sollte durchaus möglich sein, allerdings frage ich mich, wie fehleranfällig das ist. Was ich auf jeden Fall für realistisch halten würde wäre zunächst einmal eine automatische Generierung, die sich dann ein Mapper ansieht, nötigenfalls korrigiert und dann die fertige Relation hochlädt. Auf diese Weise wäre die Arbeit deutlich geringer.

viw · 2014-01-15 15:17:14

mueschel wrote:

Ich halte 2 für deutlich komplexer als 4:
- Die Einträge von 4 umfassen jeweils nur sehr wenige Wege (in der Regel 1-5, längere Auf/Abfahrten sind wohl selten vorhanden), und diese liegen in einem räumlich sehr kleinen Bereich
- Bei den meisten Locations ist 4 nicht notwendig, weil sie nicht komplex gemappt sind

Du leitest die Komplexität einfach aus der Anzahl der Elemente einer Relation ab?

mueschel · 2014-01-15 15:26:55

Ja, das sehe ich so.

Die Komplexität der notwendigen Arbeit beim Anlegen der Relationen:
- Anlegen der Relation an sich mit den notwendigen Attributen: für beides identisch (evtl kleiner bei 4, weil u.U. keine eigene Relation benötigt wird)
- Arbeit für das Erkennen welche Wege zur Relation gehören müssen: steigt mit der größere des Gebiets das ich absuchen muss, steigt mit der Zahl der Members der Relation
- Arbeit beim Hinzufügen von members: Direkt abhängig von der Zahl der Elemente

Dazu kommt:
- Aufwand der Maintenance bzw. Gefahr der unabsichtlichen Beschädigung: Im wesentlichen abhängig von der Zahl der Wegstücke, insbesondere von der Zahl der Kreuzungen mit anderen Wegen.

viw · 2014-01-15 17:14:20

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.

MHohmann · 2014-01-17 22:00:27

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.

mueschel · 2014-01-17 22:14:43

MHohmann wrote:

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

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

Last edited by mueschel (2014-01-17 22:15:15)

MHohmann · 2014-01-17 22:25:59

mueschel wrote:

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

Ja, genau so dachte ich mir das auch.

viw · 2014-01-18 10:18:56

MHohmann wrote:

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.

Das klingt doch erstmal sehr interessant.

MHohmann · 2014-01-19 10:49:58

Ich habe mich noch einmal an die Auswertung dieser TMC-Meldungen gemacht:

mueschel wrote:

Kein Thema, haben wir gerade in Wetzlar Ost: http://www.openstreetmap.org/#map=17/50.57138/8.54780
Nicht möglich sind: Ost->Nord, Ost->Süd und Nord->West (alle Links die die Lahnbrücke berühren), laut TMC auch Nord->Ost, laut Mitteilung auf hessen.de aber nicht.
In den TMC-Meldungen:
Ev  406         LC 23982        Dir pos Exten 0 (6)Suppl 4
B49 Anschlussstelle Wetzlar Ost, Einfahrt gesperrt, aus Richtung Gießen, eine Umleitung ist eingerichtet
Ev  701         LC 11401        Dir pos Exten 0 (9)AddEvent 407 (6)Suppl 4
A45 Anschlussstelle Wetzlar Ost, in Richtung Süden, Baustelle, Ausfahrt gesperrt, eine Umleitung ist eingerichtet

Ü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.

viw · 2014-01-19 11:09:45

MHohmann wrote:

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.

Also ich dachte nicht das remotecontrol deine Wünsche (schon) erfüllen kann.
http://wiki.openstreetmap.org/wiki/JOSM … f_Commands

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."

couchmapper · 2014-01-19 11:19:25

Über den Umweg "import" könnte es auch mit RemoteControl funktionieren.

Instructs JOSM to download the specified OSM file and add it to the current data set.

Die URL zeigt auf ein Server-seitiges Script, das eine frische Relation mit allen Tags als OSM-File zurückliefert.

Last edited by couchmapper (2014-01-19 11:23:05)

MHohmann · 2014-01-19 12:47:30

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.

couchmapper · 2014-01-19 13:22:41

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.

<?xml version='1.0' encoding='UTF-8'?>
<osm version='0.6' upload='true' generator='tmc relation creator'>
  <relation id='-100000' action='create' visible='true'>
    <tag k='bla' v='blubber' />
  </relation>
</osm>

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.

Last edited by couchmapper (2014-01-19 13:32:39)

Announcement

#126 2014-01-13 18:00:52

Re: Überarbeitung von TMC / TPEG

#127 2014-01-13 20:32:35

Re: Überarbeitung von TMC / TPEG

#128 2014-01-13 20:57:44

Re: Überarbeitung von TMC / TPEG

#129 2014-01-13 21:36:40

Re: Überarbeitung von TMC / TPEG

#130 2014-01-13 21:51:32

Re: Überarbeitung von TMC / TPEG

#131 2014-01-14 07:03:58

Re: Überarbeitung von TMC / TPEG

#132 2014-01-14 08:39:41

Re: Überarbeitung von TMC / TPEG

#133 2014-01-14 11:16:16

Re: Überarbeitung von TMC / TPEG

#134 2014-01-14 11:44:50

Re: Überarbeitung von TMC / TPEG

#135 2014-01-14 19:46:02

Re: Überarbeitung von TMC / TPEG

#136 2014-01-14 23:48:44

Re: Überarbeitung von TMC / TPEG

#137 2014-01-15 13:25:31

Re: Überarbeitung von TMC / TPEG

#138 2014-01-15 14:01:53

Re: Überarbeitung von TMC / TPEG

#139 2014-01-15 15:17:14

Re: Überarbeitung von TMC / TPEG

#140 2014-01-15 15:26:55

Re: Überarbeitung von TMC / TPEG

#141 2014-01-15 17:14:20

Re: Überarbeitung von TMC / TPEG

#142 2014-01-17 22:00:27

Re: Überarbeitung von TMC / TPEG

#143 2014-01-17 22:14:43

Re: Überarbeitung von TMC / TPEG

#144 2014-01-17 22:25:59

Re: Überarbeitung von TMC / TPEG

#145 2014-01-18 10:18:56

Re: Überarbeitung von TMC / TPEG

#146 2014-01-19 10:49:58

Re: Überarbeitung von TMC / TPEG

#147 2014-01-19 11:09:45

Re: Überarbeitung von TMC / TPEG

#148 2014-01-19 11:19:25

Re: Überarbeitung von TMC / TPEG

#149 2014-01-19 12:47:30

Re: Überarbeitung von TMC / TPEG

#150 2014-01-19 13:22:41

Re: Überarbeitung von TMC / TPEG

Board footer