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? 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.) > 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. > wird, aber ein OSM-Oldi geht wahrscheinlich davon aus das links die > Eigenschaft steht und rechts der Wert. Tut sie. "Der LocationCode dieses Objektes nach 81:1 lautet 11181". > Also warum nicht in folgendes > ändern. Es wird dadurch nicht lesbarer, aber für leichter zuordbar da > es ein Telefonnummer ähnelt. > TMC:LocationCode=81:1:11181 (nach dem Schema CID:TABCD:LCD) Das funktioniert nicht, da ein Objekt in mehreren Ländern in deren jeweiliger LCL steht. > 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. > 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. Marcus _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
