[Talk-de] Taskforce: Integration von OpenLR

Marcus Wolschon Marcus at Wolschon.biz
Mi Sep 16 19:02:38 UTC 2009


2009/9/16 André Riedel <riedel.andre at gmail.com>:
> Am 16. September 2009 07:18 schrieb Marcus Wolschon <Marcus at wolschon.biz>:
>> Außer den OSM-Objekten welche einem Ort entsprechen
>> braucht man die verkettete Liste der LCL-Elemenet um eine Nachricht
>> auswerten zu können (Nachricht sagt: Von LocationCode 3 bis
>> 2 Schritte nach vorne.)
>
> Es wird also nur ein Node angegeben und dann wieviel Nodes auf dem
> selben Segment durchlaufen werden müssen? Gibt es noch mehr
> Verständliche Beispiele dieser TMC-Nachrichten, damit man das System
> besser verstehen kann.

Lass und bie der richtigen Terminologie bleiben um OSM und LCL -Entitäten
nicht durcheinander zu bringen.

Eine Nachricht kann sagen, "Stau an dem Objekt 1234 bis 3 Schritte zurück".
Dann heißt dass 1234, sein Vorgänger, dessen
Vorgänger, ... .
1234 kann dabei ein Point sein, ein Segment oder eine Road.
(All diese Entitäten haben Vorgänger und Nachfolger.)

Jeder dieser Points in der LCL kann durchaus mehere Nodes und Ways
in OSM sein und es kann auch für vorwärts eine andere Menge von Ways
als für Rückwärts sein.
Einfaches Beispiel wäre ein Point mitten auf
freier Strecke auf einer Autobahn = 2 Nodes, eine rpro Richtung.
Oder ein Autobahnkreuz  = je 2 Auf/Abfahrten pro Richtung
Oder ein Kreizverkehr in einer Bundesstrasse = 1 Way aber der gleiche
vorwärte wie rückwärts.

Bei Kreuzungen gibt es noch Intersections.
d.H. eine als Ring verkettere Folge von Points.
Alle haben die gleiche Koordinate aber jede gehört zu
einem anderen Segment einer anderen Road.
>>> Für ein Programm ist es wahrscheinlich egal, ob die eindeutig
>>> Bestimmung durch den OSM-Key, den OSM-Value oder durch beide möglich
>>
>> nicht wirklich. Mit dem jetzigen Schhema kann man gegeben
>> die empfangenen CID und Tabcd -Paare in einem simplen Index
>> nach dem key suchen und erhält genau die OSM-Elemente welche
>> man braucht.
>
> Das geht andersrum auch. Such einfach nach allen Elementen mit dem
> Schlüssel "TMC:LocationCode" , welche den Wert "81:1:11181" haben.

Das hieße alle Elemente deiner Karte welche inen
TMC:LocationCode haben aus der Datenbank/Datei zu laden
um 99.99% davon im Vergleich des Wertes wegzuwerfen.
Das wären die Strassennetze ganzer Kontinente von denen
wir reden.

>> Vorsicht: Das sind je nach Richtung (Richtung in der verketteten Liste
>> der LCL-Elemente) 2 verschiedene Strassen/Rastplätze.
>> Es wird immer gesendet ob die Richtung vorwärts oder rückwärts
>> gemeint ist.
>
> Gut dann muss diese Information noch angehängt werden. Aber welches
> OSM-Objekt würdest du als Rastplatz taggen. Siehe dazu das Beispiel:
> http://osm.org/go/0MIeIXDw

Ich würde für Vorwärts und für Rückwärte jeweils alle Service-Roads
der jeweiligen Seite so taggen. Da alle von einem Ereigniss z.B. Sperrung
der Rastanlage wegen Feuer betroffen wären und nicht nur ein Punkt auf einer
dieser Strassen.
Besser etwas zu viel als zu wenig.  So dass der Bereich bei einem Event auc
tatsächlich gemieden wird.

> Gerade für solche Abschnitte empfiehlt sich doch eine Relation. Da es
> zwischen zwei TMC-Punkte (bspw. Kreuzungen) mehrere Wege gibt, muss
> man den korrekten Weg irgendwie beschreiben. Also entweder an alle ein
> tmc:cid:tabcd:segment = start-end oder alle Wege in die Relation. Auf
> Grund der Sortiermöglichkeiten seit API 0.6 kann man damit sogar die
> TMC-Richtung abbilden.

Ich würde pro Richtung eine Relation machen.
So bleibt das robuster.

Für simple Fälle z.B. Point ist nur ein Node oder ein Way eines
Kreisverkehres aber direkt das Objekt taggen.
Sonst wird man bei den ganzen simpel gelageten Bundestrassen
und wichtigen Landstrassen mechugge.

Marcus




Mehr Informationen über die Mailingliste Talk-de