Hi, Ich habe mir mit Harald Körtge von Skobbler einen Skypetermin ausgemacht am Sonntag 15.1. ab ca. 19:00.
Falls noch jemand teilnehmen will, bitte mir kurz eine Nachricht schicken mit dem eigenen Skypenamen. Nachfolgend noch seine letzte Mail zu dem Thema. vg, Martin Hallo Martin, ich finde es erst einmal super, dass Ihr euch mit dem Thema beschäftigt. Ich denke auch das ist eines der wichtigsten Themen, die an einer guten Navigation im OSM fehlen (neben den fehlenden Sign Posts evtl). Bei den beiden professionellen Datenanbietern hat sich der Weg, so wie ich ihn in der PNG Grafik erläutert habe durchgesetzt. Dieses ist in Guidance Komponenten recht einfach zu implementieren. In Deinem Beispiel sprichst Du auch noch über die Lanemarkings (gestrichelte Linie, Symbole auf der Straße etc.), dieses sollte meiner Meinung nach erst der zweite Schritt sein. Meiner Meinung nach ist folgende Priorität wichtig: 1. Anzahl der Spuren je Fahrtrichtung 2. Verbindungen (Konnektivität) zwischen den Fahrspuren und deren Folgesegmenten (Ways) 3. Spezielle Spurmarkierungen, die genauere Informationen über einen Wechsel etc. geben. Wie gesagt, bei Navteq/TeleAtlas funktioniert das ganz gut. Probleme gibt es dort allerdings, da insbesondere Beschleuniguns- und Verzögerungsstreifen und kurze Abbiegespuren häufig fehlen und damit manchmal zur Verwirrung beitragen. Ich bin voll Deiner Meinung, dass man es möglichst vermeiden sollte, das Taggen über Relationen zu lösen (Ist schwierig zu mappen und auch zu intepretieren). Für die Fahrspuren selbst sollte man ein Tag für Vorwärts und Rückwärts haben (z.B. LANES_FORWARD,LANES_BACKWARD) Attribute die für spezielle Fahrzeuge gesperrt sind, würde ich evtl. einzeln kodieren. Eine Klassifizierung nach rechts,links, halb rechts etc. ist meiner Meinung nach schon bei den Turn restrictions teilweise problematisch, da nicht immer eindeutig. Ich würde hier wirklich lieber das Folgesegment angeben: key="LANECONNECTIVITY_FORWARD" value="1->1->id="folgeWayId;2->2->id=andereFolgeWayId;..." " // meint Spur 1 geht auf die Spur 1 des Folgesegments 'folgeWayId' usw. Hiermit wird die Konnektivität eindeutig definiert. Ich glaube das es gar nicht so entscheidend ist, wie die Daten im OSM kodiert sind, sondern wie einfach es ist, diese zu erfassen (gutes Beispiel m.E. Turnrestriction in JOSM). Das gleich Kodierungsschema könnte man übrigens auch für SignPosts verwenden: folgeWayid->Hamburg;anderefolgeWayId->Bremen oder so ähnlich. Dann könnte man bei der Berechnung der Route auch gleich sagen, wenn die Route über das aktuelle Segment und folgeWayId geht: Fahren Sie Richtung Hamburg. Anmerkung: FolgeWayId muss nicht zwangsweise die nächste WayId sein, sondern lediglich diejenige, die die Unterscheidung zu anderen Zielen ermöglicht. Wir können uns gerne nochmals ausführlicher darüber unterhalten, ggf. auch per Skype, wir müssten aber für Voice Skype Calls eher einen Termin Richtung abends finden. Viele Grüße Harald ________________________________ Von: Martin Vonwald [[email protected]] Gesendet: Freitag, 13. Januar 2012 12:18 An: Oliver Kühn; Harald Körtge Betreff: Re: AW: Re: FW: WG: Fahrspuren-Tagging Danke Oliver, hallo Harald! Also wie schon geschrieben, versuchen wir gerade das Fahrspur-Tagging aufzuwerten und dabei wäre uns jeder Input von eurer Seite sehr wertvoll. Schließlich wollen wir ja, dass die Daten auch verwendet werden ;-) Da derzeit noch nichts fertig diskutiert ist, hier mal kurz der aktuelle Stand: * Im lanes Tag beschreiben wir von links nach rechts (aus Sicht des OSM-Ways) die einzelnen Spuren. * Die Art der Spur wird zB durch forward oder right beschrieben * Verläuft die Spur gegen die Richtung des OSM-Ways schreibt man die Art groß, ansonsten klein * Die Spur-Trennung wird durch Symbole wie , (wechseln möglich) oder | (wechseln nicht möglich) beschrieben. * In Diskussion sind auch bauliche Trennungen (Verkehrsberuhigung, kleine Inseln bei Kreuzungen) durch z.b. #grass# zu beschreiben. * Falls notwendig können die Eigenschaften der einzelnen Spuren durch Tags wie lanes:<nummer>:<key>=<value> beschrieben werden, also z.B. lanes:4:bicycle=designated. Einfaches Beispiel: RIGHT,FORWARD|forward,forward+right lanes:3:hgv=no * Spur ganz links: gegen OSM-Way-Richtung, Rechtsabbieger * Zweite Spur: gegen OSM-Way-Richtung, Geradeaus * Dritte Spur: in OSM-Way-Richtung, Geradeaus * Vierte Spur: in OSM-Way-Richtung, Geradeaus und Rechtsabbieger * Wechseln zwischen zweiter und dritter ist nicht erlaubt * Auf der dritten Spur dürfen LKWs nicht fahren Soweit so gut. Nur an die Verbindung der einzelnen Spuren von einem OSM-Way zum nächsten hat noch niemand gedacht. Unser Hauptproblem ist, dass das ganze sehr einfach bleiben muss, sonst wird es niemand verwenden. Wir müssen hier also zusätzlichen Nutzen gegen Aufwand abwägen. Theoretisch könnten wir diese Lanes-Connectivity mit Relationen darstellen, aber das ist meiner Meinung nach absoluter Overkill. Was denkst du prinzipiell zu dem bisherigen Vorschlag? vg, Martin
_______________________________________________ Talk-at mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-at
