[Talk-de] Taskforce: Integration von OpenLR

[André Riedel]

Am 16. September 2009 07:18 schrieb Marcus Wolschon <Marcus at wolschon.biz>:
> On 2009-09-15, André Riedel <riedel.andre at gmail.com> wrote:
>> Ich bin der Meinung, dass wir nicht die LCL in den OSM-Daten abbilden
>> müssen, sondern nur diese Teile, dass man eindeutig ein Punkt oder
>> Segment bestimmen kann. Andere in den LCL-Daten enhaltene
>> Informationen gibt es vielfach schon in OSM und müssen so nicht extra
>> an das Element gehängt werden.
>
> Welche Informationen meinst du?

Ich meine die Informationen, dass wir nicht in die OSM-Daten schreiben
müssen, dass Punkt 11181 in der Gemeinde Lichtenau in
Sachsen/Deutschland ist.

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

>> Erster Vorschlag auf Basis meines bisherigen TMC-Verständnis:
>>
>> So wie ich das jetzt gesehen, habe gehören zur Beschreibung eines
>> Objektes mit einem Location Code auf jeden Fall der Ländercode (CID)
>> und Tabellennummer (TABCD) dazu. Da man bisher davon ausgeht, dass
>> folgende LCL-Versionen (Location Code List) zu älteren
>> Navigationsgeräten kompatibel sein sollten, kann man die Version
>> vielleicht vernachlässigen. Sie sollte aber auf jeden Fall bei der
>> Eingabe im Changeset erscheinen.
>>
>> Bisher gibt es folgende Version zur Abbildung der Raststätte
>> "Auerswalder Blick":
>> TMC:cid_81:tabcd_1:LocationCode = 11181
>>
>> 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.

>> Da man eine Autobahn mit nur einer Linie und die beidseitige
>> Raststätte mit nur einem Punkt auf der Linie abbildet, diese in den
>> OSM-Daten aber aus einer Linie pro Fahrtrichtung und zwei Nodes
>> besteht, bieten sich für fast alle Varianten Relationen an. Nur
>> einmalig vorhandene OSM-Elemente, wie Parkplätze, Seen,
>> Gemeindegrenzen usw., können jedoch dirket mit den TMC-Daten ergänzt
>> werden.
>
> 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

>> Für mich stellt sich jetzt die Frage, wie mit den Linien-Abschnitten
>> (Segments) verfahren werden soll. Im Moment bevorzuge ich die
>> Variante, dass man pro Segment (von einem Location Code-Punkt zum
>> nächsten) eine Relation erstellt und alle eingeschlossenen Wege als
>> Kind hinzufügt.
>
> Das wird sehr, sehr viel manuelles Relationen-Anlegen.
> Grundsätzlich gerne aber es macht es nicht leichter.
>
>> Aber wie benennen, denn oft haben diese Segmente keine
>> eigene ID und werden nur durch den Vorgänger und Nachfolger bestimmt.
>
> ist ein Problem.

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.