Also ich werd wenn nichts dazwischen kommt mit skypen. Name bekommst per IM.
LG Thomas Am 13. Januar 2012 13:48 schrieb Martin Vonwald <[email protected]>: > 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 > > -- mfg Soldier Boy
_______________________________________________ Talk-at mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-at
