Am 16. September 2009 07:18 schrieb Marcus Wolschon <mar...@wolschon.biz>: > On 2009-09-15, André Riedel <riedel.an...@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. _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de