Re: [Talk-de] Abstraktionsebenen und Fahrerinformation
On Thu, 12 Mar 2009 15:22:04 +0100, Garry garr...@gmx.de wrote: Du machst es Dir hier sehr einfach... Stell Dir einen Stop-and Go Verkehr im Bereich der Ausfahrt vor. Verwendest Du den Point of no return als Kriterium für die Ausfahrt kann Dir das Navi auch noch auf den letzten Metern eine Umleitungsempfehlung geben. Verwendest Du aber den Beginn des Verzögerungsstreifens und hast diesen dann schon als separate Spur getaggt entfällt diese Möglichkeit was unter Umständen mehrer Stunden Stau stehen bedeuten kann. Das macht beim erfassen keine Mehrarbeit, bringt aber deutlich besseren Nutzen! Ich zweifle wiederholt sein keine Mehrarbeit an. Du willst zusätzliche Daten erfassen. Natürlich macht das Mehrarbeit. Oder woher glaubst du soll die Information über Anfang und Ende der Spuren kommen? Da muss sich der Fahrer erstmal wärend der Fahrt notieren ob er am Anfang oder sonstwo auf den Verzögerungsstreifen gewechselt hat und irgendeine Art von Markierung finden wo dieser Streifen genau aufgehört hat. Damit er später die Punkt entsprechend über seinen GPX-Track zeichnen kann und dein zusätzliches Tag setzen kann. Hast du im Tag eine Angabe in Metern, muss er mit zusätzlichen Plugins oder komplexen Formeln rauskriegen wie viele Meter das jetzt waren. Die bisherige Qualität der Daten ist ausreichend und andere Punkte (Hausnummern, fehlende Ortschaften, Qualitätssicherung) wichtier. Aber wenn du deine zusätzlichen Daten erfassen willst, schön. Bisher sehe ich kein proposed Feature von dir im Wiki. Ob es sinnvoll ist oder nicht entscheidet am Ende eh derjenige, der es mapped oder eben nicht. Dir ist bekannt, wie der weitere Weg um ein neues Tag bekannt zu machen ist. Gehe ihn oder lass es bleiben. Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abstraktionsebenen und Fahrerinformation
Original-Nachricht Datum: Fri, 13 Mar 2009 12:31:46 +0100 Von: marcus.wolsc...@googlemail.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Abstraktionsebenen und Fahrerinformation Ich zweifle wiederholt sein keine Mehrarbeit an. Nicht nur keine Mehrarbeit, sondern weniger Arbeit, weil das offensichtliche einfach per Definition erschlagen wird. Die normale Laenge der Einfeadelspur ist eine bauliche Groesse, die man nicht im Einzelfall erfassen muss. Man macht es nur fuer die wenigen Ausnahmen, wenn sie z.B. stark abweicht. Ansonsten ersetzt man das Malen der parallelen Spur (==Mehraufwand) durch die Definition, dass der Knoten an die gut erkennbare echte Trennung der Spuren zu setzten ist. Das reicht fuer eine saubere Netzabbildung und fuer eine gute Visualisierung. Oder woher glaubst du soll die Information über Anfang und Ende der Spuren kommen? Der eine Punkt ist der Trennungspunkt und der ist sehr gut rauszufinden, egal ob man von Bild oder Track erfasst. Der andere Punkt ist neaherungsweise ueber die Bauvorschriften 1a rauszufinden, ohne dass man die Info in der Karte verankern muss. Da muss sich der Fahrer erstmal wärend der Fahrt notieren ob er am Anfang oder sonstwo auf den Verzögerungsstreifen gewechselt hat und irgendeine Art von Markierung finden wo dieser Streifen genau aufgehört hat. Warum sollte er das muessen? Der Trennungspunkt ist geometrisch gut zu erkennen. Eine Ausfahrt ist i.A. neaherungsweise ein Kreissegment, das in ein kurzes Geradenstueck uebergeht, das einen Schnittpunkt zur Autobahn selber hat. Der Schnittpunkt ist auf ein paar Meter genau der Trennungspunkt. Der Anfang der Ausfaedelspur ist dagegen weder auf Tracks, noch auf unseren Bildern gut zu erkennen (mit google gehts, aber das ist verboten :( ) Damit er später die Punkt entsprechend über seinen GPX-Track zeichnen kann und dein zusätzliches Tag setzen kann. Hast du im Tag eine Angabe in Metern, muss er mit zusätzlichen Plugins oder komplexen Formeln rauskriegen wie viele Meter das jetzt waren. Oder mal in die Bauvorschriften schaun oder alternativ die Pfosten zaehlen (==50m/Pfosten). Was das zusaetzliche Tag angeht: Kann man machen, muss man aber nicht. Es ist kein grosser mangel, wenn die Einfeadelspur nicht explizit drin ist. Es ist nur suboptimal, wenn sie als etwas drin ist, was sie nicht ist: eine baulich getrennte eigene Fahrbahn, denn das ist immmer noch die gaengigste Regel, wann man einen eigenen Link einfuehren soll (Abstraktion). Dir ist bekannt, wie der weitere Weg um ein neues Tag bekannt zu machen ist. Gehe ihn oder lass es bleiben. Die OSM-Regel ist immer noch, dass jeder tags einfuehren kann wie er lustig ist und die Abstimmung nur Vorschlagscharakter hat, sagt Fred ;) -- Nur bis 16.03.! DSL-Komplettanschluss inkl. WLAN-Modem für nur 17,95 ¿/mtl. + 1 Monat gratis!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abstraktionsebenen und Fahrerinformation
On Fri, 13 Mar 2009 13:24:46 +0100, qbert biker qbe...@gmx.de wrote: Original-Nachricht Datum: Fri, 13 Mar 2009 12:31:46 +0100 Von: marcus.wolsc...@googlemail.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Abstraktionsebenen und Fahrerinformation Ich zweifle wiederholt sein keine Mehrarbeit an. Nicht nur keine Mehrarbeit, sondern weniger Arbeit, weil das offensichtliche einfach per Definition erschlagen wird. Die normale Laenge der Einfeadelspur ist eine bauliche Groesse, die man nicht im Einzelfall erfassen muss. Man macht es nur fuer die wenigen Ausnahmen, wenn sie z.B. stark abweicht. Ansonsten ersetzt man das Malen der parallelen Spur (==Mehraufwand) durch die Definition, dass der Knoten an die gut erkennbare echte Trennung der Spuren zu setzten ist. Das reicht fuer eine saubere Netzabbildung und fuer eine gute Visualisierung. Oder woher glaubst du soll die Information über Anfang und Ende der Spuren kommen? Der eine Punkt ist der Trennungspunkt und der ist sehr gut rauszufinden, egal ob man von Bild oder Track erfasst. Der andere Punkt ist neaherungsweise ueber die Bauvorschriften 1a rauszufinden, ohne dass man die Info in der Karte verankern muss. Da muss sich der Fahrer erstmal wärend der Fahrt notieren ob er am Anfang oder sonstwo auf den Verzögerungsstreifen gewechselt hat und irgendeine Art von Markierung finden wo dieser Streifen genau aufgehört hat. Ein paar Denkanstösse, damit du deinen Vorschlag besser ausarbeiten kannst: Warum sollte er das muessen? Der Trennungspunkt ist geometrisch gut zu erkennen. Geht so. Eine Ausfahrt ist i.A. neaherungsweise ein Kreissegment, Definitiv nicht. Zumindest in Deutschland ist das üblicherweise eine Schleppkurve und kein Kreis. das in ein kurzes Geradenstueck uebergeht, das einen Schnittpunkt zur Autobahn selber hat. Der Schnittpunkt ist auf ein paar Meter genau der Trennungspunkt. Wie findest du diesen Schnittpunkt wenn du dich nicht mehr erinnertst ob du genau am Anfang des Verzögerungs- Steifens oder irgendwo in der Mitte gewechselt bist? Damit er später die Punkt entsprechend über seinen GPX-Track zeichnen kann und dein zusätzliches Tag setzen kann. Hast du im Tag eine Angabe in Metern, muss er mit zusätzlichen Plugins oder komplexen Formeln rauskriegen wie viele Meter das jetzt waren. Oder mal in die Bauvorschriften schaun oder alternativ die Pfosten zaehlen (==50m/Pfosten). Gute Idee für Deutschland. Nur haben ich da meist mit Abbiegen zu tun und nicht mit zählen und erfasst maximal mit einem Surveyor-Knopfdruck auf (N)ote die Nummer der Ausfahrt und was mir an Daten für das Signposting (Was auf dem Schild stand. Wesentlich wichtiger für Fahranweisungen durch ein Navi) noch im Kopf ist. Danach habe ich mit dem Drängler hinter mir zu tun. Was das zusaetzliche Tag angeht: Kann man machen, muss man aber nicht. Es ist kein grosser mangel, wenn die Einfeadelspur nicht explizit drin ist. Wenn man das nicht ausmisst, kann man keine Spuren welche eben nicht die default-Länge haben erfassen und in dem Fall wäre das ganze sinnlos dafür ein Tag zu haben dass nie gesetzt ist. Es ist nur suboptimal, wenn sie als etwas drin ist, was sie nicht ist: eine baulich getrennte eigene Fahrbahn, denn das ist immmer noch die gaengigste Regel, wann man einen eigenen Link einfuehren soll (Abstraktion). Ah..du willst auf eine Generelle Regel hinaus, dass wo nichts getagged ist implizit ein Verzögerungsstreifen existiert, dessen Länge sich nach dem Enthalten-Sein in dem (leider nicht konsistenten oder auch nur vollständigen) Grenz-Polygon des Landes richtet und in einer Tabelle im Wiki nachgeschlagen werden kann? Ich schlage vor du fängst an die Bauvorschriften zumindest erstmal aller westlichen Länger zu studieren und diese Default-Länge für die verschiedenen Arten von Ausfahrten (motorway-motorway_link, trunk-trunk_link und primary-primary_link) zusammenzutragen. Sag bescheid, wenn du mit West+Mittel-Europa, Nordamerika und den wichtigsten asiatischen Längern fertig bist. Dir ist bekannt, wie der weitere Weg um ein neues Tag bekannt zu machen ist. Gehe ihn oder lass es bleiben. Die OSM-Regel ist immer noch, dass jeder tags einfuehren kann wie er lustig ist und die Abstimmung nur Vorschlagscharakter hat, sagt Fred ;) Ich sagte auch bekannt machen. Wenn niemand das Tag kennt, wird es niemand nutzen. Ich kann mir schwer vorstellen, dass sonderlich viele Leute die Deutsche Talk-Mailing-Liste lesen. Vor allem da die wenigsten Mapper deutsch sprechen. Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abstraktionsebenen und Fahrerinformation
Original-Nachricht Datum: Fri, 13 Mar 2009 13:40:07 +0100 Von: marcus.wolsc...@googlemail.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Abstraktionsebenen und Fahrerinformation Ein paar Denkanstösse, damit du deinen Vorschlag besser ausarbeiten kannst: Eigentlich ist es kein Vorschlag, sondern die Erleuterung, warum es alle so machen und nicht anders. Wie findest du diesen Schnittpunkt wenn du dich nicht mehr erinnertst ob du genau am Anfang des Verzögerungs- Steifens oder irgendwo in der Mitte gewechselt bist? Irgendwie gibts hier ein Missverstaendnis: Ich setze die Node an den Point of no return, also wenn die Ausfahrt einen eindeutigen unuebersehbaren Knick macht. Der ist auf allen meinen Tracks und auf den Luftbildern sehr gut erkennbar. Ich brauche mich an nichts zu erinnern, sondern ich trage ein, was ich sehe. Wenn ich versuche, den kleinen Schlenkerer zu erfassen, wenn ich in die Ausfaedelspur gewechselt bin, da habe ich genau dieses Problem und deshalb lasse ich es. Gute Idee für Deutschland. Es gibt aehnliches auch fuer andere Laender. In Portugal sind sie eben entsprechend kuerzer. Das zaehlen macht man auch nur ein paar mal und uebertraegts dann weiter. Wenn man das nicht ausmisst, kann man keine Spuren welche eben nicht die default-Länge haben erfassen und in dem Fall wäre das ganze sinnlos dafür ein Tag zu haben dass nie gesetzt ist. Deshalb hatte ich geschrieben, dass es allgemeine Dinge beschreibt. Man kann es tun, wenn man unbedingt den Anfang der Ausfeadelspur drin haben will, kann es aber auch bleiben lassen, weil die Dinger eh fast immer gleich lang sind (==Redundanz). Ah..du willst auf eine Generelle Regel hinaus, dass wo nichts getagged ist implizit ein Verzögerungsstreifen existiert, dessen Länge sich nach dem Enthalten-Sein in dem (leider nicht konsistenten oder auch nur vollständigen) Grenz-Polygon des Landes richtet und in einer Tabelle im Wiki nachgeschlagen werden kann? In erster Linie will ich darauf hinaus, dass die meisten die Existenz des Streifens gar nicht interessiert. Die, die es interessiert, haben die Moeglichkeit genau so vorzugehen und dann eine viel genauere Abbildung erhalten als wenn Mapper versuchen, jeden einzelnen Streifen mit ueber Schlenkerer im track abzubilden und eigene Fahrbahnen einzuzeichnen, die es so gar nicht gibt. Man muss das fuer Deutschland oder vielleicht die Bundeslaender einmal machen, also eine mickrige Zahl im Vergleich zu tausenden, ueberkomplex und ungenau abgebildeten Ein/Ausfahrten. Manchmal ist es wirklich eine eigene parallele Fahrbahn - wie soll man das unterscheiden? Oder ist das auch unwichtig und ein paar Hausnummern sind viel wichtiger? -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abstraktionsebenen und Fahrerinformation
Original-Nachricht Datum: Wed, 11 Mar 2009 17:32:24 +0100 Von: Garry garr...@gmx.de An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Abstraktionsebenen und Fahrerinformation Hallo, Man sollte auch bedenken dass solche Aus/Einfädelstreifen nicht selten nict in vollem Umfang nutzbar sind - Tagesbaustellen, liegengebliebenes Fahrzeug, Ummarkierung, Zugeschneit,... Von daher könnte eine zu detaillierte Wiedergabe dieser Fahrstreifen der Orientierung ehr Schaden als nützen wenn die Realität anderst aussieht als es die Darstellung erwarten lässt. In der Höhe der Ausfahrt erfordert der Fahspurwechsel erhöhte Aufmerksamkeit so dass man nicht durch unnötige Informationen abgelenkt werden sollte. Nur um Sicherzustellen, das ich da nix falsch verstehe: Die Genauigkeit der Darstellung im Navi darf sich nicht auf die Genauigkeit der Erfassung durchschlagen. Das Navi (bzw. Datenvorverarbeitung und Programmierung) kann beliebig Daten weglassen, die den Fahrer verwirren koennten, aber in die allgemeine Datenbank gehoeren sie rein. (Wir taggen ja nicht fuer... ;)) Grundsaetzlich sind wir uns doch alle einig, dass wir die Realitaet so genau wie moeglich abbilden wollen. Einschraenkungen gibts hoechstens bei der Qualiteat der Messungen oder beim Datenumfang. Von typisch würde ich hier nicht ausgehen - es kommt alles vor von nicht vorhanden bis in den Kilometer-Bereich. Naja - finde eine Ein-Ausfahrt auf einer deutschen BAB, die nicht die Mindestlaenge hat, wenn sie nicht als Notausfahrt, etc. gekennzeichnet ist. Die Beschleunigungsspur ist ein Baumerkmal einer Autobahn. Bei trunk wirds spannend (bezieht sich trunk noch auf kreuzungsfrei?), denn da ist alles moeglich. Allerdings ist eine Beschleunigungsspur immer eindeutig ueber (Anfang oder Ende) und Laenge beschrieben. Eine Markierung am Point of no return deckt mit einem einzigen node den kompletten Bereich für alle vorkommenden Bereiche in den Grundeigenschaften ab. Eben. Gruesse Hubert -- Nur bis 16.03.! DSL-Komplettanschluss inkl. WLAN-Modem für nur 17,95 ¿/mtl. + 1 Monat gratis!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abstraktionsebenen und Fahrerinformation
qbert biker schrieb: Man sollte auch bedenken dass solche Aus/Einfädelstreifen nicht selten nict in vollem Umfang nutzbar sind - Tagesbaustellen, liegengebliebenes Fahrzeug, Ummarkierung, Zugeschneit,... Von daher könnte eine zu detaillierte Wiedergabe dieser Fahrstreifen der Orientierung ehr Schaden als nützen wenn die Realität anderst aussieht als es die Darstellung erwarten lässt. In der Höhe der Ausfahrt erfordert der Fahspurwechsel erhöhte Aufmerksamkeit so dass man nicht durch unnötige Informationen abgelenkt werden sollte. Nur um Sicherzustellen, das ich da nix falsch verstehe: Die Genauigkeit der Darstellung im Navi darf sich nicht auf die Genauigkeit der Erfassung durchschlagen. Das Navi (bzw. Datenvorverarbeitung und Programmierung) kann beliebig Daten weglassen, die den Fahrer verwirren koennten, aber in die allgemeine Datenbank gehoeren sie rein. (Wir taggen ja nicht fuer... ;)) Ja, schon klar. Nur sollte man darauf achten dass die Pflichtdaten (hier verlässt der Fahrstreifen die Autobahn)im Vordergrund stehen sollte und nicht die Luxusdaten (hier geht die rechte Fahrspur in eine Ausfahrt über). Grundsaetzlich sind wir uns doch alle einig, dass wir die Realitaet so genau wie moeglich abbilden wollen. Einschraenkungen gibts hoechstens bei der Qualiteat der Messungen oder beim Datenumfang. Ja - nur sollten wir uns auch bewusst sein dass wir nie fertig werden und uns diesem Idealzustand immer nur annähren können. Daher sollte man sehr darauf achten dass die wichtigen Informationen pflegeleicht (leicht überprüfbar)erfasst werden können. In diesem Fall also der Point of no return der an jeder Ausfahrt vorhanden ist - gleich wie lang der Verzögerungsstreifen ist. Naja - finde eine Ein-Ausfahrt auf einer deutschen BAB, die nicht die Mindestlaenge hat, wenn sie nicht als Notausfahrt, etc. gekennzeichnet ist. Die Beschleunigungsspur ist ein Baumerkmal einer Autobahn. Bei trunk wirds spannend (bezieht Bei Neubauten bzw. sanierten Autobahnen mag das zutreffen - mir waren noch einige reguläre Ausfahrten bekannt die praktisch keinen Beschleunigungs/Verzögerungsstreifen hatten. Würde mich wundern wenn die in den letzten 5 Jahren alle ausgebaut wurden. Wenn man noch die Parkplätze dazu zählt dann gibt es definitv noch einige ohne Fädelstreifen. sich trunk noch auf kreuzungsfrei?), denn da ist alles moeglich. Ja, alles andere gerechtfertigt keine Verwendung von einem separaten highway-tag. Wobei man hier die deutsche Umsetzung von trunk nicht mit denen aus den Herkunfrsländern gleich setzen darf da dieses zu Konflickten führt. Allerdings ist eine Beschleunigungsspur immer eindeutig ueber (Anfang oder Ende) und Laenge beschrieben. Das ist richtig - habe auch nichts dagegen dass diese in den Daten enthalten sind - nur eben nicht als separater Way zu Beginn der Ausfahrt. Eine Markierung am Point of no return deckt mit einem einzigen node den kompletten Bereich für alle vorkommenden Bereiche in den Grundeigenschaften ab. Eben. Gruesse Hubert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abstraktionsebenen und Fahrerinformation
marcus.wolsc...@googlemail.com schrieb: On Wed, 11 Mar 2009 10:57:44 +0100, qbert biker qbe...@gmx.de wrote: Die Praezision der Anweisungen und Empfehlungen haengt von der Qualitaet der Datenbasis ab und das zu 100%. Wenn in der Karte die Information fehlt, dass es an einer Kreuzung eine Linksabbiegerspur gibt, weiss das Navi nix davon und kann auch keine Information abgeben. Wenn das Navi annimmt, dass der Knoten am Ende der Ausfeadelspur ist und er ist am Anfang, wird es sich um ein gutes Stueck verrechnen. Bei was soll er sich da verrechnen? An dem Punkt, wo ein highway=motorway und ein highway=motorwa_link sind wird eine Abbiege-Markierung in die dargestellte Karte gezeichent. 2Km oder so vorher wird das erste Mal darauf hingewiesen, dass man demnächst abbiegen muss und wohin. 600-800m vorher das nächste Mal und 300m vorher jetzt. Da der Fahrter kompetent genug ist sein Fahrzeug im Strassenverkehr zu bedienen und das GPS eh nie genaue Koordinaten bekommt wird er entsprechen der Fahrspuren und Schilder da abbiegen. Vollkommen egal ob da gerade der Verzögerungsstreifen anfängt oder ob der erst in 300m anfängt. 300m sind schon eine ganze Menge die ein Navi zumindest im Rahmen der Richtgeschwindigkeit (und natürlich unterhalb) deutlich unterscheiden kann. Insbesondere an Autobahnkreuzen und ähnlichen Abfahrten folgen die Entscheidungspunkte nicht selten deutlich dichter aufeinander. Wir machen hier keine Audio-Navigation für Blinde. Ein Navi ist ein Hilfsmittel, damit der Fahrer weiss welche Strassen er zu seinem Ziel nehmen muss und mehr nicht. Es ist kein Ding dass einem unfähigen Fahrzeugführer sagt wann du welchen Hebel bedienen musst. Du machst es Dir hier sehr einfach... Stell Dir einen Stop-and Go Verkehr im Bereich der Ausfahrt vor. Verwendest Du den Point of no return als Kriterium für die Ausfahrt kann Dir das Navi auch noch auf den letzten Metern eine Umleitungsempfehlung geben. Verwendest Du aber den Beginn des Verzögerungsstreifens und hast diesen dann schon als separate Spur getaggt entfällt diese Möglichkeit was unter Umständen mehrer Stunden Stau stehen bedeuten kann. Das macht beim erfassen keine Mehrarbeit, bringt aber deutlich besseren Nutzen! Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abstraktionsebenen und Fahrerinformation
Georg Feddern schrieb: Deswegen wurde am anderen Orte (ich meine im Forum) vorgeschlagen, den motorway_link am Ende der Ausfädelung anzusetzen, den motorway_junction aber am Beginn der Ausfädelung einzutragen. Damit stünden die benötigten Informationen geografisch zur Verfügung. Selbst eine geschwindigkeitsabhängige Berechnung kann die Länge der Ausfädelung nicht berücksichtigen. Halte ich für keine so gute Idee, damit geht der automatische Bezug verloren und muss in irgendeiner Form manuell wieder hergestellt werden. Das ist dann fehleranfällig... Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abstraktionsebenen und Fahrerinformation
On Tue, 10 Mar 2009 19:26:38 +0100, qbert biker qbe...@gmx.de wrote: Der Haken an der Sache ist, dass ein Informationssystem, das nur die Daten der aktuellen Position hat, viel zu spät eine Meldung an den Fahrer geben würde. Ein Lösungsansatz wäre, die Abfahrt, also den Verzweigungsknoten an den Anfang der Ausfädelspur zu setzen, aber dann wird die Abstraktion gebrochen und dem System die Information vorenthalten, dass ein Wechsel durchaus noch moeglich ist. Denkfehler. Das ist ein Verzögerungsstreifen. Den befährt man an seinem Anfang und nutzt die Länge um zu vergögern. Weiter hinten kann man nicht mehr sicher wechseln, da kein Platz mehr zum verzögern ist und man evtl. die Tempo 80 oder gar Tempo 60 -Kurve nicht mehr bekommt. Ergo sollte dein System früh genug die Anweisung geben und der Fahrer hat sie dann schon gehört, ist informiert dass er abbiegen sollte und entscheidet selber ob und wie er das tut. Entsprechend der Verkehrs- Situation und seiner eigenen Einschätzung. Eine erst in dem Moment, in dem er rüber ziehen sollte gegebene Anweisung ist viel zu spät. Schliesslich muss der Fahrer mehr tun als nur das Lenkrad zu drehen. (Ist da einer neben mir? Blinker setzen. Entfernung und Geschwindigkeit einschätzen. Geht hinter mir noch einer rüber? Wie stark kann und muss ich verzögern ohne jemanden vor oder hinter mir zu gefährden? Wie eng ist die Kurve da vorne?) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abstraktionsebenen und Fahrerinformation
Original-Nachricht Datum: Wed, 11 Mar 2009 08:11:49 +0100 Von: marcus.wolsc...@googlemail.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Abstraktionsebenen und Fahrerinformation Denkfehler. Noe, deshalb habe ich auch Abstraktion in den Titel geschrieben. Das ist ein Verzögerungsstreifen. Den befährt man an seinem Anfang und nutzt die Länge um zu vergögern. Weiter hinten kann man nicht mehr sicher wechseln, da kein Platz mehr zum verzögern ist und man evtl. die Tempo 80 oder gar Tempo 60 -Kurve nicht mehr bekommt. Jetzt ist die Abstraktionsebene dein persoenliches Fahrverhalten :) Bei diesem Ansatz werden der bauliche Zustand, Markierungen und die verkehrlichen Regelungen wild zusammengeschmissen. Ein Wechsel ist auf der ganzen Laenge moeglich und auch erlaubt, wenn es der Verkehr zulaesst. Ergo sollte dein System früh genug die Anweisung geben und der Fahrer hat sie dann schon gehört, ist informiert dass er abbiegen sollte und entscheidet selber ob und wie er das tut. Entsprechend der Verkehrs- Situation und seiner eigenen Einschätzung. Das ist richtig. Das System sollte mind. 1km vorher wissen, dass da die Ausfahrt kommt und eine Anweisung geben. Die Frage ist, wie man das in den Daten verankert. Wenn jemand den Abzweigungspunkt an den Anfang der Ausfaedelspur setzt, weil sein Infosystem nicht zurueckrechnen kann und ihm immer zu spaet die Anweisung gibt, wird die Abstraktion gebrochen, ohne dass ein echter Vorteil entsteht. Es wird immer noch zu spaet angesagt, dass man ausfahren soll (das soll ja vor dem Beginn der Ausfaedelspur passieren) und man hat eine Ausfahrt, die nicht mehr der Realiteat entspricht. Jeder Versuch, baulichen Zustand, Markierungen und persoenliche Fahrerfahrungen direkt in ein Netz zu codieren, also die Abstraktionsebenen zu vermischen, fuehrt zu Informationsverlust. Wenn jemand meint, dass er ja immer gleich am Anfang der Spur rausfaehrt und da den 'point of no return' setzt, verwischt den realen Bauzustand, den andere fuer andere Abbildungen vielleicht gerne nutzen wollen. Deshalb die Anforderung, den passenden Punkt fuer die Anweisung von einem intelligenten Algorithmus flexibel berechnen zu lassen, der auf eine moeglichst genaue Abbildung der ersten Abstraktionsebene, der bauliche Zustand, zugreift. Und dieser bauliche Zustand wird am besten richtig erfasst, wenn man die Verzweigung setzt, wo sie wirklich ist und das ist Bereich um die schraffierte Fleache. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abstraktionsebenen und Fahrerinformation
Original-Nachricht Datum: Wed, 11 Mar 2009 08:11:49 +0100 Von: marcus.wolsc...@googlemail.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Abstraktionsebenen und Fahrerinformation Denkfehler. Noe, deshalb habe ich auch Abstraktion in den Titel geschrieben. Das ist ein Verzögerungsstreifen. Den befährt man an seinem Anfang und nutzt die Länge um zu vergögern. Weiter hinten kann man nicht mehr sicher wechseln, da kein Platz mehr zum verzögern ist und man evtl. die Tempo 80 oder gar Tempo 60 -Kurve nicht mehr bekommt. Jetzt ist die Abstraktionsebene dein persoenliches Fahrverhalten :) Bei diesem Ansatz werden der bauliche Zustand, Markierungen und die verkehrlichen Regelungen wild zusammengeschmissen. Ein Wechsel ist auf der ganzen Laenge moeglich und auch erlaubt, wenn es der Verkehr zulaesst. Ergo sollte dein System früh genug die Anweisung geben und der Fahrer hat sie dann schon gehört, ist informiert dass er abbiegen sollte und entscheidet selber ob und wie er das tut. Entsprechend der Verkehrs- Situation und seiner eigenen Einschätzung. Das ist richtig. Das System sollte mind. 1km vorher wissen, dass da die Ausfahrt kommt und eine Anweisung geben. Die Frage ist, wie man das in den Daten verankert. Wenn jemand den Abzweigungspunkt an den Anfang der Ausfaedelspur setzt, weil sein Infosystem nicht zurueckrechnen kann und ihm immer zu spaet die Anweisung gibt, wird die Abstraktion gebrochen, ohne dass ein echter Vorteil entsteht. Es wird immer noch zu spaet angesagt, dass man ausfahren soll (das soll ja vor dem Beginn der Ausfaedelspur passieren) und man hat eine Ausfahrt, die nicht mehr der Realiteat entspricht. Jeder Versuch, baulichen Zustand, Markierungen und persoenliche Fahrerfahrungen direkt in ein Netz zu codieren, also die Abstraktionsebenen zu vermischen, fuehrt zu Informationsverlust. Wenn jemand meint, dass er ja immer gleich am Anfang der Spur rausfaehrt und da den 'point of no return' setzt, verwischt den realen Bauzustand, den andere fuer andere Abbildungen vielleicht gerne nutzen wollen. Deshalb die Anforderung, den passenden Punkt fuer die Anweisung von einem intelligenten Algorithmus flexibel berechnen zu lassen, der auf eine moeglichst genaue Abbildung der ersten Abstraktionsebene, der bauliche Zustand, zugreift. Und dieser bauliche Zustand wird am besten richtig erfasst, wenn man die Verzweigung setzt, wo sie wirklich ist und das ist Bereich um die schraffierte Fleache. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de -- Nur bis 16.03.! DSL-Komplettanschluss inkl. WLAN-Modem für nur 17,95 ¿/mtl. + 1 Monat gratis!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abstraktionsebenen und Fahrerinformation
On Wed, 11 Mar 2009 09:00:35 +0100, qbert biker qbe...@gmx.de wrote: Das ist richtig. Das System sollte mind. 1km vorher wissen, dass da die Ausfahrt kommt und eine Anweisung geben. Die Frage ist, wie man das in den Daten verankert. Garnicht. Der Zeitpunkt wann eine Fahranweisung angesagt werden soll ist eine Einstellung des Navis und nicht der Karte. Wenn jemand den Abzweigungspunkt an den Anfang der Ausfaedelspur setzt, weil sein Infosystem nicht zurueckrechnen kann und ihm immer zu spaet die Anweisung gibt, wird die Abstraktion gebrochen, ohne dass ein echter Vorteil entsteht. Du machst die Sache hier wesentlich komplizierter als sie ist. Wenn das Navi die Anweisungen zu spät gibt geht der Nutzer in die Einstellungen des Navis und sagt dass er früher benachrichtigt werden will. Er wird nicht anfangen sämtliche Autobahn-Auffahrten der Karte zu verändern. Deshalb die Anforderung, den passenden Punkt fuer die Anweisung von einem intelligenten Algorithmus flexibel berechnen zu lassen, der auf eine moeglichst genaue Abbildung der ersten Abstraktionsebene, der bauliche Zustand, zugreift. Und dieser bauliche Zustand wird am besten richtig erfasst, wenn man die Verzweigung setzt, wo sie wirklich ist und das ist Bereich um die schraffierte Fleache. Mach bitte einen Vorschlag (der kompatibel zum existierenden Kartenmaterial ist) wie man deiner Meinung nach Ausfahrten genauer erfassen kann oder stell das als konkrete Frage zur Diskussion. Dein Gerede von Abstraktionsebenen verwirrt nur unnötig. Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abstraktionsebenen und Fahrerinformation
Original-Nachricht
Datum: Wed, 11 Mar 2009 09:47:26 +0100
Von: marcus.wolsc...@googlemail.com
An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org
Betreff: Re: [Talk-de] Abstraktionsebenen und Fahrerinformation
Garnicht. Der Zeitpunkt wann eine Fahranweisung angesagt werden soll
ist eine Einstellung des Navis und nicht der Karte.
Garnicht ist moeglich aber vielleicht zu wenig. Die Information,
dass man sich in 500m rechts einordnen kann, muss ja erstmal
auch gewonnen werden. Bei deutschen Autobahnen ist sie zwar
implizit vorhanden, da jede Ein-/Ausfahrt eine Beschleunigungsspur
haben muss, aber wo der Referenzpunkt ist, bleibt offen.
Du machst die Sache hier wesentlich komplizierter als sie ist.
Eigentlich hab ich sie vereinfacht, aber das schrecklich
kompliziert ausgedrueckt.
Wenn das Navi die Anweisungen zu spät gibt geht der Nutzer
in die Einstellungen des Navis und sagt dass er früher benachrichtigt
werden will. Er wird nicht anfangen sämtliche Autobahn-Auffahrten
der Karte zu verändern.
Das Navi braucht dazu mindestens einen sicheren Referenzpunkt
und ggf. Zusatzinfos bei normalen Strassen, ob ueberhaupt eine
Einfaedelspur vorhanden ist.
Mach bitte einen Vorschlag (der kompatibel zum existierenden
Kartenmaterial ist) wie man deiner Meinung nach Ausfahrten
genauer erfassen kann oder stell das als konkrete Frage zur
Diskussion.
Mein Vorschlag ist kompatibel zu allen anderen digitalen Karten,
und zur deutschen Mappinginfoseite. Mein Vorschlag kann nicht
kompatibel zur existierenden Karte sein, weil es in der realen
Karte wild gemischt wird (siehe andere Antwort und Diskussion
zum Thema im Januar).
Dein Gerede von Abstraktionsebenen verwirrt nur unnötig.
Na ja, dann kann ich verwirren oder garnix sagen und in diesem
Fall hab ich mich feurs verwirren entschieden ;)
Keine Ahnung obs jemand schafft, das exakter und gleichzeitig
weniger verwirrend darzustellen, der Dreh- und Angelpunkt
bleibt die Abstraktion. Wenn ich einen Link in eine digitale
Karte einzeichne, bezieht der sich auf alle Spuren dieser
Verbindung und ich kann sie alle benutzen, um von A nach B
zu kommen. Das ist die gaengige Abstraktion aller geangigen
Karten, die auch OSM mehr oder weniger implizit uebernommen
hat (siehe Aenderungen bei strassenseitigen Fahrradwegen).
Wenn man diese Abstraktion als Leitbild nimmt, macht man einen
objektiven Fehler, wenn man den Knoten an den Anfang der
Einfaedelspur setzt und die Einfaedelspur als unabhaengigen
Link darstellt. bzw. man verschleiert die Information,
wo Anfang und Ende dieser Spur ist. Die Einfaedelspur ist
eine Spur der Autobahn (Parallelitaet und Wechselmoeglichkeit).
Die Varienten sind:
Knoten immer am Ende der Ausfaedelspur: Der Knoten ist der
Referenzpunkt fuers Navi
Knoten immer am Anfang der Ausfaedelspur: Es gibt einen
fixen Referenzpunkt fuers Navi, aber die Netzkodierung
ist ungenauer.
Knoten irgendwo zwischen Anfang und Ende ('intuitiv'):
Referenzpunkt fuers Navi kann nur geschaetzt werden.
--
Nur bis 16.03.! DSL-Komplettanschluss inkl. WLAN-Modem für nur
17,95 ¿/mtl. + 1 Monat gratis!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abstraktionsebenen und Fahrerinformation
Am Mittwoch 11 März 2009 schrieb marcus.wolsc...@googlemail.com: On Wed, 11 Mar 2009 09:00:35 +0100, qbert biker qbe...@gmx.de wrote: Das ist richtig. Das System sollte mind. 1km vorher wissen, dass da die Ausfahrt kommt und eine Anweisung geben. Die Frage ist, wie man das in den Daten verankert. Garnicht. Der Zeitpunkt wann eine Fahranweisung angesagt werden soll ist eine Einstellung des Navis und nicht der Karte. richtig! wenn eine berechnete route vorliegt, weiss das system jederzeit, wo die ausfahrten kommen. daraus einen entsprechenden punkt fuer die anweisung (z.B. geschwindigkeitsabhaengig) zu berechnen, ist nicht schwer. dazu braucht man keinen eintrag in der datenbasis... signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abstraktionsebenen und Fahrerinformation
Hallo. Am Mittwoch, 11. März 2009 schrieb qbert biker: Garnicht ist moeglich aber vielleicht zu wenig. Die Information, dass man sich in 500m rechts einordnen kann, muss ja erstmal auch gewonnen werden. Bei deutschen Autobahnen ist sie zwar implizit vorhanden, da jede Ein-/Ausfahrt eine Beschleunigungsspur haben muss, aber wo der Referenzpunkt ist, bleibt offen. Der frühest mögliche Punkt an dem man sich konkret einordnen kann sollte der Referenzpunkt sein. Du machst die Sache hier wesentlich komplizierter als sie ist. Eigentlich hab ich sie vereinfacht, aber das schrecklich kompliziert ausgedrueckt. Nein, IMHO hast du ein Problem beschrieben, das es gar nicht gibt. Klar, einerseits hast du recht, man will die Realität abbilden. Die Realität im verkehrsrechtlichen Sinne sagt aber, dass dein angestrebter Wechselzeitpunkt der Beginn der Abbiegespur ist, da kannst du jeden Fahrlehrer fragen. Klar darfst du auch später noch wechseln, aber das kann man ja ignorieren. Entweder du hast ein perfektes Assistenz-System, dann hast du bereits am Beginn des Verzögerunsstreifens gewechselt (weil du ja dann auch schon rechtzeitig vorher auf den rechten Fahrstreifen gewechselt hast). Oder du traust dem Fahrer noch etwas Kompetenz zu, dann wird er auch wechseln wenn sein Auto gar nicht weiß dass man das noch darf. Die Realität in der Kartendarstellung sagt, dass die Fahrbahn dort breiter wird, das machen unsere Renderer momentan ganz schön. Knoten immer am Anfang der Ausfaedelspur: Es gibt einen fixen Referenzpunkt fuers Navi, aber die Netzkodierung ist ungenauer. Und wo ist das Problem? Wer einen Bedarf an der zusätzlichen Information hat, kann immernoch die beiden Fahrstreifen (die dann parallel verlaufen) mit einer Spurwechsel-Relation zusammenfassen. Man sollte sich halt erst eine gute Erklärung ausdenken warum man das braucht, sonst macht keiner mit und es macht keinen Spass. :) Vielleicht magst du kurz das Szenario beschreiben, in dem du die spätere Wechselmöglichkeit in der Praxis brauchst. Gruß, Bernd -- Fachbegriffe der Informatik (#403): Strategische Entscheidung Wir haben zwar keine Ahnung, aber die Präsentationen sahen toll bunt aus, die Verkäufer haben uns zugelabert und trugen Schlips und Anzug. Lediglich das Geräusch, das entstand, als der anwesende Techniker (wer hat den eigentlich eingeladen, der trägt ja noch nichtmal Anzug) seinen Kopf mehrfach gegen die Tischplatte schlug, hat etwas gestört. (Alexander Schreiber) signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abstraktionsebenen und Fahrerinformation
Original-Nachricht Datum: Wed, 11 Mar 2009 10:42:44 +0100 Von: Guenther Meyer d@sordidmusic.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Abstraktionsebenen und Fahrerinformation richtig! wenn eine berechnete route vorliegt, weiss das system jederzeit, wo die ausfahrten kommen. daraus einen entsprechenden punkt fuer die anweisung (z.B. geschwindigkeitsabhaengig) zu berechnen, ist nicht schwer. dazu braucht man keinen eintrag in der datenbasis... naja... Der Route kommt vom Router und der hat sie anhand der digitalen Karte berechnet. Wenn die Karte falsch ist, oder die Annahmen, die der Router ueber die Karte trifft, falsch sind, ist auch die gegebene Information falsch. Die Praezision der Anweisungen und Empfehlungen haengt von der Qualitaet der Datenbasis ab und das zu 100%. Wenn in der Karte die Information fehlt, dass es an einer Kreuzung eine Linksabbiegerspur gibt, weiss das Navi nix davon und kann auch keine Information abgeben. Wenn das Navi annimmt, dass der Knoten am Ende der Ausfeadelspur ist und er ist am Anfang, wird es sich um ein gutes Stueck verrechnen. -- Nur bis 16.03.! DSL-Komplettanschluss inkl. WLAN-Modem für nur 17,95 ¿/mtl. + 1 Monat gratis!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abstraktionsebenen und Fahrerinformation
Am Mittwoch 11 März 2009 schrieb qbert biker: Garnicht ist moeglich aber vielleicht zu wenig. Die Information, dass man sich in 500m rechts einordnen kann, muss ja erstmal auch gewonnen werden. Bei deutschen Autobahnen ist sie zwar implizit vorhanden, da jede Ein-/Ausfahrt eine Beschleunigungsspur haben muss, aber wo der Referenzpunkt ist, bleibt offen. der punkt sollte der anfang der spur sein, um den fahrer immer rechtzeitig darauf hinweisen zu koennen. Wenn das Navi die Anweisungen zu spät gibt geht der Nutzer in die Einstellungen des Navis und sagt dass er früher benachrichtigt werden will. Er wird nicht anfangen sämtliche Autobahn-Auffahrten der Karte zu verändern. Das Navi braucht dazu mindestens einen sicheren Referenzpunkt und ggf. Zusatzinfos bei normalen Strassen, ob ueberhaupt eine Einfaedelspur vorhanden ist. ob der punkt der beginn einer spur ist, oder direkt die ausfahrt (bei nicht vorhandener separater spur), ist egal. er sollte den fruehestmoeglichsten zeitpunkt angeben, an dem die aktuelle fahrtrasse geaendert werden kann. wie das dann letztendlich passiert, hat der fahrer jeweils selbst zu verantworten. Keine Ahnung obs jemand schafft, das exakter und gleichzeitig weniger verwirrend darzustellen, der Dreh- und Angelpunkt bleibt die Abstraktion. Wenn ich einen Link in eine digitale Karte einzeichne, bezieht der sich auf alle Spuren dieser Verbindung und ich kann sie alle benutzen, um von A nach B zu kommen. Das ist die gaengige Abstraktion aller geangigen Karten, die auch OSM mehr oder weniger implizit uebernommen hat (siehe Aenderungen bei strassenseitigen Fahrradwegen). Wenn man diese Abstraktion als Leitbild nimmt, macht man einen objektiven Fehler, wenn man den Knoten an den Anfang der Einfaedelspur setzt und die Einfaedelspur als unabhaengigen Link darstellt. bzw. man verschleiert die Information, wo Anfang und Ende dieser Spur ist. Die Einfaedelspur ist eine Spur der Autobahn (Parallelitaet und Wechselmoeglichkeit). nochmal: die wechselmoeglichkeit bzw. laenge der spur ist irrelevant fuer eine benachrichtigung. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abstraktionsebenen und Fahrerinformation
Am Mittwoch 11 März 2009 schrieb qbert biker: Der Route kommt vom Router und der hat sie anhand der digitalen Karte berechnet. Wenn die Karte falsch ist, oder die Annahmen, die der Router ueber die Karte trifft, falsch sind, ist auch die gegebene Information falsch. Die Praezision der Anweisungen und Empfehlungen haengt von der Qualitaet der Datenbasis ab und das zu 100%. Wenn in der Karte die Information fehlt, dass es an einer Kreuzung eine Linksabbiegerspur gibt, weiss das Navi nix davon und kann auch keine Information abgeben. dann traegt man eben eine linksabbiegerspur ein... Wenn das Navi annimmt, dass der Knoten am Ende der Ausfeadelspur ist und er ist am Anfang, wird es sich um ein gutes Stueck verrechnen. ...oder auch nicht. linksabbiegerspuren an kreuzungen sind nicht sooo lang, dass das was ausmachen wuerde. der zeitpunkt der benachrichtung sollte so oder so vorher erfolgen. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abstraktionsebenen und Fahrerinformation
On Wed, 11 Mar 2009 10:57:44 +0100, qbert biker qbe...@gmx.de wrote: Die Praezision der Anweisungen und Empfehlungen haengt von der Qualitaet der Datenbasis ab und das zu 100%. Wenn in der Karte die Information fehlt, dass es an einer Kreuzung eine Linksabbiegerspur gibt, weiss das Navi nix davon und kann auch keine Information abgeben. Wenn das Navi annimmt, dass der Knoten am Ende der Ausfeadelspur ist und er ist am Anfang, wird es sich um ein gutes Stueck verrechnen. Bei was soll er sich da verrechnen? An dem Punkt, wo ein highway=motorway und ein highway=motorwa_link sind wird eine Abbiege-Markierung in die dargestellte Karte gezeichent. 2Km oder so vorher wird das erste Mal darauf hingewiesen, dass man demnächst abbiegen muss und wohin. 600-800m vorher das nächste Mal und 300m vorher jetzt. Da der Fahrter kompetent genug ist sein Fahrzeug im Strassenverkehr zu bedienen und das GPS eh nie genaue Koordinaten bekommt wird er entsprechen der Fahrspuren und Schilder da abbiegen. Vollkommen egal ob da gerade der Verzögerungsstreifen anfängt oder ob der erst in 300m anfängt. Wir machen hier keine Audio-Navigation für Blinde. Ein Navi ist ein Hilfsmittel, damit der Fahrer weiss welche Strassen er zu seinem Ziel nehmen muss und mehr nicht. Es ist kein Ding dass einem unfähigen Fahrzeugführer sagt wann du welchen Hebel bedienen musst. Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abstraktionsebenen und Fahrerinformation
Original-Nachricht Datum: Wed, 11 Mar 2009 10:59:17 +0100 Von: Guenther Meyer d@sordidmusic.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Abstraktionsebenen und Fahrerinformation der punkt sollte der anfang der spur sein, um den fahrer immer rechtzeitig darauf hinweisen zu koennen. Genau da liegt das Problem. Das navi muss _vor_ dem Beginn der Spur den Hinweis geben und es ist egal, ob es Punkt-500m rechnet oder Punkt-Laenge der Einfeadelspur-500m. Was hier vorgeschlagen wird, ist, die primaere Struktur des Netzes zu aendern nur weil das navi nicht richtig nach hinten rechnen kann. Die Laenge der Einfeadelspur kann man implizit voraussetzen (z.B. BaB-Bauvorschriften) oder explizit als Parameter angeben. Es gibt _keinen_ Grund, deshalb den Knoten zu verschieben, solange alle Informationen zur Fahrerinformation vorhanden sind. nochmal: die wechselmoeglichkeit bzw. laenge der spur ist irrelevant fuer eine benachrichtigung. Nochmal: Eine existierende Information ist besser als eine fehlende Information und wer will heute schon festlegen, wer welche Informationen wann braucht? -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abstraktionsebenen und Fahrerinformation
On Wed, 11 Mar 2009 11:20:45 +0100, qbert biker qbe...@gmx.de wrote: ... z.B. die Induktionsschleifen in den Ein- Ausfahrten abhaengig von den Ausfahrtsknoten referenziert, nicht vom Anfang der Einfaedelspur. Und last but not least kann es nicht unbedingt schaden, etwas kompatibel zum Rest der Welt zu sein, auch wenn der nur aus poesen, spiessigen GISlern besteht, die alles besser wissen und nur die Mapper versklaven wollen ;) Dann bitte ich dich uns mal das Datenmodell der spiessigen GISler zu erklären, mit dem diese Fahrspuren beschreiben und mach ein paar Vorschläge wie man diese Information verständlich in unser Datenmodell als Zusatzinformation aufnehmen kann. Bisher mappen wir ja keine Asphalt-Streifen sondern den Graphen des Strassennetzes. (von nicht wirklich verwendeten Tags zur Strassen- Breite mal abgesehen) Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abstraktionsebenen und Fahrerinformation
Bisher mappen wir ja keine Asphalt-Streifen sondern den Graphen des Strassennetzes. (von nicht wirklich verwendeten Tags zur Strassen- Breite mal abgesehen) Freilich mappt ihr (wir) Asphaltstreifen. Die auf denen wir fahren und die, die wir von den Bildern abmahlen. Ansonsten gibts noch die Spuranzahl als Parameter (nimmt auch fast keiner her) und ein paar andere Sachen fehlen noch, z.B. spurgenaue Kreuzungsabbildung. Bei letzterem denke ich derzeit ueber den internal_divider nach. -- Nur bis 16.03.! DSL-Komplettanschluss inkl. WLAN-Modem für nur 17,95 ¿/mtl. + 1 Monat gratis!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abstraktionsebenen und Fahrerinformation
Original-Nachricht Datum: Wed, 11 Mar 2009 10:48:52 +0100 Von: Bernd Wurst be...@bwurst.org An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] Abstraktionsebenen und Fahrerinformation Die Realität im verkehrsrechtlichen Sinne sagt aber, dass dein angestrebter Wechselzeitpunkt der Beginn der Abbiegespur ist, da kannst du jeden Fahrlehrer fragen. Wir mappen doch nicht fuers Verkehrsrecht ;) Klar darfst du auch später noch wechseln, aber das kann man ja ignorieren. Warum soll man es ignorieren, wenn man es ohne Mehraufwand exakt abbilden kann? Oder du traust dem Fahrer noch etwas Kompetenz zu, dann wird er auch wechseln wenn sein Auto gar nicht weiß dass man das noch darf. In der ersten Ebene der Abstraktion gibts noch gar keinen Fahrer, sondern ein Teerband, das fuer den Fussgaenger ebenso existent ist wie fuer den Autofahrer. Das ist der bauliche Zustand, fuer Fussgaenger und Fahrradfahrer ein Hinderniss, fuer den Autofahrer ein Verkehrsweg. Wenn ich eine Strasse in erster Ordnung abbilde ist die Kompetenz des Fahrers erstmal Nebensache. Die Realität in der Kartendarstellung sagt, dass die Fahrbahn dort breiter wird, das machen unsere Renderer momentan ganz schön. Na ja, Autobahn ist breiter als Fussweg, aber ansonsten ists mit der genauen Abbildung nicht weit her, was ja auch durchaus richtig ist, es soll ja nicht alles in Details absaufen. Dazu gibts dann die Moeglichkeit, das mit Spezialprogrammen zu machen (siehe unten). Und wo ist das Problem? Wer einen Bedarf an der zusätzlichen Information hat, kann immernoch die beiden Fahrstreifen (die dann parallel verlaufen) mit einer Spurwechsel-Relation zusammenfassen. Nachtraegliches symbolisches Zusammenflicken von getrennten Links? Da gruselts mir... Vielleicht magst du kurz das Szenario beschreiben, in dem du die spätere Wechselmöglichkeit in der Praxis brauchst. Gut, zuerst ist die Abbildung genauer und kommt mit weniger Eingangsinformationen aus. Der Parallellink blaeht die Datenbasis auf, ohne Mehrwert zu bilden. Nebenbei macht das auch noch Arbeit, die man sich sparen kann. Die Szenarien, die mir spontan einfallen sind neben genauerer Fahrerassistenz ein exakte bildliche Darstellung aller Spuren und Spuruebergaenge. Die zweite ist die Verwendung der karte in Verkehrssimulationen. Konkret werden z.B. die Induktionsschleifen in den Ein- Ausfahrten abhaengig von den Ausfahrtsknoten referenziert, nicht vom Anfang der Einfaedelspur. Und last but not least kann es nicht unbedingt schaden, etwas kompatibel zum Rest der Welt zu sein, auch wenn der nur aus poesen, spiessigen GISlern besteht, die alles besser wissen und nur die Mapper versklaven wollen ;) -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abstraktionsebenen und Fahrerinformation
Hallo. Am Mittwoch, 11. März 2009 schrieb qbert biker: Wir mappen doch nicht fuers Verkehrsrecht ;) Nein, aber es ist neben den gerenderten Karten IMHO die Anwendung, die die meisten Mapper anspornt, die Karten für ein normales Navi nutzen zu können. Klar darfst du auch später noch wechseln, aber das kann man ja ignorieren. Warum soll man es ignorieren, wenn man es ohne Mehraufwand exakt abbilden kann? Deine Mail klingt irgendwie so gar nicht nach ohne Mehraufwand. ;-) Und wo ist das Problem? Wer einen Bedarf an der zusätzlichen Information hat, kann immernoch die beiden Fahrstreifen (die dann parallel verlaufen) mit einer Spurwechsel-Relation zusammenfassen. Nachtraegliches symbolisches Zusammenflicken von getrennten Links? Da gruselts mir... Naja, siehe Linienbündel-Diskussion. Auch wenn mir das biherige Ergebnis noch nicht vollständig gefällt, so kam doch recht deutlich dabei heraus, dass separates Zeichnen und nachträgliches Zusammenfassen die Methode mit der größten Flexibilität zu sein scheint. Zumindest sind mir keine ernstgemeinten Vorschläge begegnet, mehrere Fahrstreifen oder Abbiege- und Verzögerungsstreifen sinnvoll abzubilden. Vielleicht magst du kurz das Szenario beschreiben, in dem du die spätere Wechselmöglichkeit in der Praxis brauchst. Gut, zuerst ist die Abbildung genauer und kommt mit weniger Eingangsinformationen aus. Die momentane Eingangsinformation ist folgende + `+.+ \ Direkt beteiligt sind also maximal 2 Nodes, die man sich sparen könnte wenn man den Verzögerungsstreifen anders abbilden will. Da man aber (davon gehe ich aus) definitiv einen Node setzen will an dem Punkt an dem der Verzögerungsstreifen beginnt, ist es ein Node (ohne Tags), der gespart werden kann. Wie du die Situation mit weniger Overhead beschreiben willst, darauf bin ich sehr gespannt! Der Parallellink blaeht die Datenbasis auf, ohne Mehrwert zu bilden. Nebenbei macht das auch noch Arbeit, die man sich sparen kann. Welche Arbeit? Und last but not least kann es nicht unbedingt schaden, etwas kompatibel zum Rest der Welt zu sein, auch wenn der nur aus poesen, spiessigen GISlern besteht, die alles besser wissen und nur die Mapper versklaven wollen ;) Wissen wir denn, zu welcher Abbildungsform wir damit kompatibel sein möchten? Ich kenne bisher nur das OSM-Datenmodell und keine Modelle der Konkurrenz. Natürlich wissen hier viele auch wie das in anderen Daten modelliert wird. Aber so lange das nicht mal irgendwo irgendwie publik gemacht wird, gehe ich davon aus dass wir zu etwas kompatibel sein wollen was wir nur erahnen können. Das finde ich ne lustige Vorstellung und ich würde persönlich dann lieber bei unserem Modell bleiben. Gruß, Bernd -- Ein Huhn ist weiter nichts als die Methode eines Eis, ein weiteres Ei zu machen. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abstraktionsebenen und Fahrerinformation
On Wed, 11 Mar 2009 11:40:03 +0100, qbert biker qbe...@gmx.de wrote: Ich schliess das jetzt ab. Dir mag die Ungenauigkeit egal sein - ich finde es schade, wenn man seine Arbeit in unpraezisen Mischmasch steckt, wenn es auch die Moeglichkeit der genauen Abbildung gibt. Wir arbeiten überall mit unpräzisen Daten, da man bei den OSM-Daten nie davon ausgehen kann, dass irgendwas vollständig oder exakt nach irgendwelchen Regeln getagged ist. Selbst wenn du ein Tagging- Schema für Abbiege-Spuren vorschlägst kann man sich nicht blind darauf verlassen, dass auch der hinterletzte Highway in Brasilien tatsächlich so getagged ist. Der echte Trennungspunkt ist auf Luftbildern und aus Tracks deutlich leichter und besser zu reproduzieren als der kleine Schlenkerer, wenn man auf die Auslaufspur ausgeschwenkt ist. Es gibt keinen wirklichen objektiven Grund, die Spur in einen eigenen Link auszulagern, ausser dem subjektiven Empfinden des Autofahrers, da abgebogen zu sein. Ich glaube du solltest dir das tag highway=motorway_link ansehen. Du scheinst das nict verstanden zu haben. Ein highway_link ist keine Auslaufspur sonder die gesammte Autobahn-Auffahrt/ das Autobahn-Kreuz. Und jetzt sag endlich mal was genau du mappen willst und wie. Du kannst deine Spuren ja gerne haben aber WERDE ENDLICH KONKRET. Fahrspuren wurden hier und im Wiki schon mehrfach vorgeschlagen und es gab kein richtiges Ergebniss. Was du taggen willst hast du ja hinreichend klar gemacht und jetzt sag endlich mal WIE und wir können anfangen Fortschritte. Für sinnloses Rumgeblubber ohne konkreten, produktiven Nutzen für die Verbesserung unserer Karte hab ich keine Zeit. Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abstraktionsebenen und Fahrerinformation
Am Mittwoch 11 März 2009 schrieb qbert biker: Original-Nachricht Datum: Wed, 11 Mar 2009 10:59:17 +0100 Von: Guenther Meyer d@sordidmusic.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Abstraktionsebenen und Fahrerinformation der punkt sollte der anfang der spur sein, um den fahrer immer rechtzeitig darauf hinweisen zu koennen. Genau da liegt das Problem. Das navi muss _vor_ dem Beginn der Spur den Hinweis geben und es ist egal, ob es Punkt-500m rechnet oder Punkt-Laenge der Einfeadelspur-500m. Was hier vorgeschlagen wird, ist, die primaere Struktur des Netzes zu aendern nur weil das navi nicht richtig nach hinten rechnen kann. Die Laenge der Einfeadelspur kann man implizit voraussetzen (z.B. BaB-Bauvorschriften) oder explizit als Parameter angeben. Es gibt _keinen_ Grund, deshalb den Knoten zu verschieben, solange alle Informationen zur Fahrerinformation vorhanden sind. wer spricht hier davon, knoten zu verschieben? soweit ich weiss, ist es gaengige praxis bei osm, eine ausfahrtspur an deren beginn von der hauptfahrbahn abzuweigen, und solange bis sie wirklich wegfuehrt, parallel nebenher zu fuehren. der abzweigknoten ist bekannt, und kann fuer die berechnung der ansage benutzt werden. was brauchst du mehr? natuerlich waere es schoener, den echten spurenverlauf abzubilden. aber dazu braucht es erst mal ein vernuenftiges modell, um das in osm einzubringen. und es muss auch konsequent benutzt werden, wenn du darauf setzen willst... nochmal: die wechselmoeglichkeit bzw. laenge der spur ist irrelevant fuer eine benachrichtigung. Nochmal: Eine existierende Information ist besser als eine fehlende Information und wer will heute schon festlegen, wer welche Informationen wann braucht? klar, du kannst eintragen, wazs du fuer sinnvoll haeltst. aber erwarte nicht, dass sich die masse der mapper die arbeit macht; erst recht nicht, wenn kein signifikanter mehrwert daraus gewonnen werden kann ;-) signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abstraktionsebenen und Fahrerinformation
Moin, qbert biker schrieb: Original-Nachricht wenn eine berechnete route vorliegt, weiss das system jederzeit, wo die ausfahrten kommen. daraus einen entsprechenden punkt fuer die anweisung (z.B. geschwindigkeitsabhaengig) zu berechnen, ist nicht schwer. dazu braucht man keinen eintrag in der datenbasis.. Die Praezision der Anweisungen und Empfehlungen haengt von der Qualitaet der Datenbasis ab und das zu 100%. Wenn in der Karte die Information fehlt, dass es an einer Kreuzung eine Linksabbiegerspur gibt, weiss das Navi nix davon und kann auch keine Information abgeben. Wenn das Navi annimmt, dass der Knoten am Ende der Ausfeadelspur ist und er ist am Anfang, wird es sich um ein gutes Stueck verrechnen. Deswegen wurde am anderen Orte (ich meine im Forum) vorgeschlagen, den motorway_link am Ende der Ausfädelung anzusetzen, den motorway_junction aber am Beginn der Ausfädelung einzutragen. Damit stünden die benötigten Informationen geografisch zur Verfügung. Selbst eine geschwindigkeitsabhängige Berechnung kann die Länge der Ausfädelung nicht berücksichtigen. Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abstraktionsebenen und Fahrerinformation
Am Mittwoch 11 März 2009 schrieb qbert biker: Original-Nachricht Datum: Wed, 11 Mar 2009 11:24:19 +0100 Von: marcus.wolsc...@googlemail.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Abstraktionsebenen und Fahrerinformation Wir machen hier keine Audio-Navigation für Blinde. Ein Navi ist ein Hilfsmittel, damit der Fahrer weiss welche Strassen er zu seinem Ziel nehmen muss und mehr nicht. Es ist kein Ding dass einem unfähigen Fahrzeugführer sagt wann du welchen Hebel bedienen musst. Ich schliess das jetzt ab. Dir mag die Ungenauigkeit egal sein - ich finde es schade, wenn man seine Arbeit in unpraezisen Mischmasch steckt, wenn es auch die Moeglichkeit der genauen Abbildung gibt. naja, das ist immer sache der anwendung: um zum beispiel eine karte zu malen, reicht es zu wissen, dass highway= motorway was dickeres ist, als highway=secondary. da brauchts nicht mehr information. fuer viele reicht das. um aber routing fuer verschiedene fortbewegungsarten oder spurgenaue navigation zu realisierenmuss wesentlich mehr information her. das schwierige daran, ist eine definierte und vor allem moeglichst EINFACHE abbildung zu entwickeln... Technisch besser reproduzierbar ist der Verlauf der Spur in jedem Fall dann, wenn man ihn als das beschreibt, was er ist: Eine Parallele zu den anderen Autobahnspuren mit Wechselmoeglichkeit und einer bestimmten Laenge. ja gut, dann versuch mal folgendes menschen- und maschinenlesbar (osm-style halt) und so, dass es der gewoehnliche mapper versteht, zu beschreiben: gegeben sei eine autobahn, drei spuren, betrachtet wird nur eine fahrtrichtung, beginnend 200m vor der ausfahrt: 0m drei fahrspuren, wechsel beliebig moeglich 200mverbreiterung um eine spur nach rechts (beginn der ausfahrt) 400meine fuenfte fahrspur wird rechts angefuegt 600mdie rechten beiden fahrspuren werden physisch von den anderen getrennt 800mdie rechte fahrspur zweigt ab und entfernt sich (richtung abc), der rest geradeaus weiter 1000m die rechte fahrspur teilt sich in eine abzweigende, sich entfernende (richtung xyz) und eine geradeaus weiterfuehrende spur 1400m an die rechte fahrspur fuegt sich eine von rechts kommende spur an 1600m die kommende neue rechte spur endet 1800m die physische abtrennung von den linken drei spuren endet - vier fahrspuren 2000m die rechte fahrspur endet - drei fahrspuren bei einem autobahnkreuz hast du das ganze viermal auf relativ engem raum. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abstraktionsebenen und Fahrerinformation
Original-Nachricht Datum: Wed, 11 Mar 2009 11:49:08 +0100 Von: Bernd Wurst be...@bwurst.org An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Abstraktionsebenen und Fahrerinformation Deine Mail klingt irgendwie so gar nicht nach ohne Mehraufwand. ;-) Uebersetzt: Setze die Node dahin, wo sie gut erkennbar ist. Spar dir den Versuch, den Anfang der Abbiegespur abzuschaetzen und reinzupfriemeln. Spar die den Aufwand, ein Linienbuendel zu basteln und ihm nachher die Information hinterherzuschieben dass es eigentlich nur ein Objekt ist. Naja, siehe Linienbündel-Diskussion. Die ist mir entgangen und wenn es dabei um das geht, was ich jetzt vermute (das Pferd von hinten aufzuzaeumen, weil man keine saubere Attributierung eines Querschnitts hinbekommt) habt ihr mich wohl demnaechst endgueltig los. Na ja, manche wirds freuen ;) Die momentane Eingangsinformation ist folgende + `+.+ \ oder +==+==+==+==+ `+-+-+-+-+.+ \ Z.B. wegen einer Kurve. Direkt beteiligt sind also maximal 2 Nodes, die man sich sparen könnte Minimal zwei Nodes und eine elende Pfriemelei, das optisch einigermassen gut aussehen zu lassen. +==+==+==+==+=== \ 1 2 3 4 5 Ist einfacher und genauer. Man kann jetzt an Node 1 hinterlegen, dass da eine Abbiegespur beginnt, oder besser, man kann an Node 5 hinterlegen dass der Kreuzung eine Einfeadelspur von soundsoviel Metern vorgestellt ist oder man kann einfach gar nix machen und der Preprocessor, der die Daten fuers Navi aufbereitet, fuegt die Info automatisch ein. Das geht problemlos, indem er erkennt, dass es eine Autobahn ist und es Bauvorschriften ueber die Laenge der Einfeadelspur gibt. Wie du die Situation mit weniger Overhead beschreiben willst, darauf bin ich sehr gespannt! Siehe oben. Man leasst die Maschine denken. Wissen wir denn, zu welcher Abbildungsform wir damit kompatibel sein möchten? Ich kenne bisher nur das OSM-Datenmodell und keine Modelle der Konkurrenz. Ein offenes Beispiel sind die AND-shape-Daten des Niederlande- Imports. und ich würde persönlich dann lieber bei unserem Modell bleiben. Mit dem kleinen Schoenheitsfehler, dass OSM kein Attributsmodell hat, ausser vielen Vorschlaegen und dem Prinzip: 'jeder macht es wie er will' :) -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abstraktionsebenen und Fahrerinformation
Original-Nachricht Datum: Wed, 11 Mar 2009 12:39:37 +0100 Von: Guenther Meyer d@sordidmusic.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Abstraktionsebenen und Fahrerinformation 0mdrei fahrspuren, wechsel beliebig moeglich motorway lanes=3 200m verbreiterung um eine spur nach rechts (beginn der ausfahrt) nix, siehe unten 400m eine fuenfte fahrspur wird rechts angefuegt motorway lanes=5 outlane 200 600m die rechten beiden fahrspuren werden physisch von den anderen getrennt Knoten - Das Zusammenlaufen der Spuren kann man errechnen Gradeaus lane=3 rechts lanes=2 800m die rechte fahrspur zweigt ab und entfernt sich (richtung abc), der rest geradeaus weiter Noch ein Knoten Gradeaus lanes=2 rechts lanes=1 1000m die rechte fahrspur teilt sich in eine abzweigende, sich entfernende (richtung xyz) und eine geradeaus weiterfuehrende spur Auch ein Knoten lanes=1 und lanes=1 1400m an die rechte fahrspur fuegt sich eine von rechts kommende spur an Wieder die Hauptrichtung? motorway lanes=3 in_lane=400m 1600m die kommende neue rechte spur endet implizit oben erfasst 1800m die physische abtrennung von den linken drei spuren endet - vier fahrspuren Eine physisch getrennte Fahrbahn ist immer ein eigener Link. Bei den lanes kann ich dir nicht folgen 2000m die rechte fahrspur endet - drei fahrspuren bei einem autobahnkreuz hast du das ganze viermal auf relativ engem raum. Ist ueberhaupt kein Problem. Was eigenstaendig laeuft, bleibt eigenstaendig. Alle Spuren ineinander ueberzufuehren geht problemlos, wenn sie sauber erfasst sind. Ich brauch fuer eine exakte vollstaendige Darstellung nur das echte Netz 'physische Trennung' und die Spuren. Eine Abstraktion von Ein/Ausfaedelspuren ist zwar nicht notwendig, erleichtert die Sache aber etwas. Problematisch wirds nur bei sowas: 2 - - - - 3 Also von Spur 2 nach 3 darf man nicht, von 3 nach 2 schon. Hier wuerde ich den internal_divider verwenden mit den durchnummerierten Spuren: internal_divider 2,3,oneway -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abstraktionsebenen und Fahrerinformation
On Wed, 11 Mar 2009 13:02:01 +0100, qbert biker qbe...@gmx.de wrote: Du scheinst das nict verstanden zu haben. Ein highway_link ist keine Auslaufspur sonder die gesammte Autobahn-Auffahrt/ das Autobahn-Kreuz. Nein, ich habe nur das Problem, dass ich lange vor OSM schon mit digitalen Karten gearbeitet habe und Probleme und Vorteile des ganzen Prozesses vom Erstellen bis zum Routing abstrakt begreife, ohne auf ein konkretes Modell festgelegt zu sein *seufz* Du bist hier aber in einem Projekt welches bereits ein konkretes Datenmodell hat, was nicht durch eine Diskussion auf einer landes- spezifischen Mailing-Liste geändert wird. Insofern wirst du es wohl ertragen müssen, wenn deine Aussagen zur Auswertung ihrer Machbarkeit und des damit verbundenen Aufwandes sowie der Nebebeffekte auf das konkrete Projekt bezogen werden, für welches diese Liste existiert. Und jetzt sag endlich mal was genau du mappen willst und wie. Du kannst deine Spuren ja gerne haben aber WERDE ENDLICH KONKRET. Ich habe die besten Erfahrungen gemacht, wenn man den Graphen (Links, Nodes) einfach haelt und Eigenschaften als Attribute abbildet. also -+ \ statt -+--- \+--+\ Jetzt einfach an den Ausfahrtsknoten (oben) die Info dranheangen, dass da eine Ausfaedelspur von X Metern davorhaengt und alle koennen zufrieden sein. Wunderbar. Hast du schon einen möglichen Namen und Werte für dein Tag? Denkst du es sollte auch für Abbiege-Spuren ausserhalb von Autobahnen Verwendung finden? Wenn ja, wie könnte man das Problem des dann nicht mehr implizierten oneway=yes lösen? (= auf welcher Seite des Knoten wäre der Verzögerungs- Streifen wenn es sich um keine Einbahnstrasse handelt) Wie integriert es sich mit anderen Vorschlägen welche sich um Fahrspuren und ihre Eigenschaften und Einschränkungen kümmern? Wenn wir hier einen Vorschlag zusammen bekommen könnte man den auf der internationalen talk-liste mal vorstellen und im Wiki als proposed feature eintragen. Dann wird sich zeigen ob Leute das einleuchtend und nützlich genug finden um es zu taggen und ob genug getaggte Daten zusammenkommen, dass der Einbau entsprechender Regeln für ihre Nutzung durch die wenigen Entwickler in ihre jeweiligen Anwendungen Sinn macht. Fahrspuren wurden hier und im Wiki schon mehrfach vorgeschlagen und es gab kein richtiges Ergebniss. Fahrspuren sind der Parameter lane, glaub ich. Wenn ich eine Autobahn mit 3 Fahrspuren habe lanes=3 oder aehnlich und die Info, dass von A nach B eine Einfeadelspur ist, ist das die vierte lane. Ganz einfach, ganz pragmatisch und sehr gaengig. Die Anzahl ja aber ich meinte die Linien-Bündel -Diskussion welche über die blosse anzahl hinausgehen sollte und wohl auch Abbiege-Spuren und Verzögerungs-Streifen behandelt hat. Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abstraktionsebenen und Fahrerinformation
So, ein kleiner Einschub hier, weil ich den Fokus der Diskussion zu eng finde: qbert biker schrieb: +==+==+==+==+=== \ 1 2 3 4 5 Ist einfacher und genauer. Man kann jetzt an Node 1 hinterlegen, dass da eine Abbiegespur beginnt, oder besser, man kann an Node 5 hinterlegen dass der Kreuzung eine Einfeadelspur von soundsoviel Metern vorgestellt ist oder man kann einfach gar nix machen und der Preprocessor, der die Daten fuers Navi aufbereitet, fuegt die Info automatisch ein. Schön, jetzt hast du dir das einfachste Beispiel rausgepickt: Abbiegespuren mit aus dem Kontext eindeutiger Position. Die Linienbündel-Ansätze mit eigenen OSM-Objekten für Spuren (seien es jetzt eigene Ways oder Relationen), so unzulänglich sie auch noch sein mögen, ließen sich aber immerhin auch für alle möglichen anderen Spurinfos, Radwege, Bürgersteige samt deren relativer Anordnung, Breite, Oberflächenbeschaffenheit usw nutzen. Funktioniert das mit deinem Modell auch oder ist das eine ausschließlich auf die Anforderungen eines heutigen Standard-Autonavis zugeschnittene Lösung, die mit darüber hinausgehenden Detailinfos nicht zurecht kommt? Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abstraktionsebenen und Fahrerinformation
Original-Nachricht Datum: Wed, 11 Mar 2009 13:35:34 +0100 Von: marcus.wolsc...@googlemail.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Abstraktionsebenen und Fahrerinformation Du bist hier aber in einem Projekt welches bereits ein konkretes Datenmodell hat, Das halte ich fuer eine sehr positv formulierte Wunschvorstellung ;) Die Diskussion hier zeigt doch, dass dieses Datenmodell es nicht mal schafft, Einigkeit ueber die Abbildung einer Autobahnabfahrt zu schaffen. Ich formuliere die Dinge allgemein, die unabheangig von der Auspreagung eines konkreten Modells sind. Klingt dann vielleicht etwas unverdaulich, basiert aber nicht auf Wunschvorstellungen. Wunderbar. Hast du schon einen möglichen Namen und Werte für dein Tag? Denkst du es sollte auch für Abbiege-Spuren ausserhalb von Autobahnen Verwendung finden? Freilich Wenn ja, wie könnte man das Problem des dann nicht mehr implizierten oneway=yes lösen? (= auf welcher Seite des Knoten wäre der Verzögerungs- Streifen wenn es sich um keine Einbahnstrasse handelt) way-Knoten-relation? Die Spur befindet sich auf dem way der zum Knoten hinfuehrt und der Knoten hat die Daten (bei einem normalen Linksabbieger z.B..) Wie integriert es sich mit anderen Vorschlägen welche sich um Fahrspuren und ihre Eigenschaften und Einschränkungen kümmern? keine Ahnung, das ist euer Problem. Ich kann das aus meiner relativ unabheangigen Sicht darstellen und auch mal einen Nachmittag hier beim mailen verbringen, aber ich kann nicht MBs in mail, wiki, und wasauchimmer verfolgen, um auf dem laufenden zu bleiben. Wenn wir hier einen Vorschlag zusammen bekommen könnte man den auf der internationalen talk-liste mal vorstellen und im Wiki als proposed feature eintragen. Dann wird sich zeigen ob Leute das einleuchtend und nützlich genug finden um es zu taggen und ob genug getaggte Daten zusammenkommen, dass der Einbau entsprechender Regeln für ihre Nutzung durch die wenigen Entwickler in ihre jeweiligen Anwendungen Sinn macht. Ich habs dargestellt - lassts euch durch den Kopf gehen und macht was draus oder verwerft es. Das was ich dargestellt habe ist allgemeiner Natur. Die Anzahl ja aber ich meinte die Linien-Bündel -Diskussion welche über die blosse anzahl hinausgehen sollte und wohl auch Abbiege-Spuren und Verzögerungs-Streifen behandelt hat. Und an mir vorbeigegangen ist - wenn ich naeher drueber nachdenk, ists wohl auch besser so. Es ist ein prinzipielles Problem bei Modellen die ohne echte Struktur und ohne Leitlinie entstehen. Sie neigen dazu, einfache Dinge in bemerkenswerte Komplexitaet ausarten zu lassen ;) -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abstraktionsebenen und Fahrerinformation
Schön, jetzt hast du dir das einfachste Beispiel rausgepickt: Abbiegespuren mit aus dem Kontext eindeutiger Position. Die Linienbündel-Ansätze mit eigenen OSM-Objekten für Spuren (seien es jetzt eigene Ways oder Relationen), so unzulänglich sie auch noch sein mögen, ließen sich aber immerhin auch für alle möglichen anderen Spurinfos, Radwege, Bürgersteige samt deren relativer Anordnung, Breite, Oberflächenbeschaffenheit usw nutzen. Um es klarzustellen: Ich beziehe mich hier nicht exclusiv auf OSM, denn solche Dinge sollten abstrakt definiert werden. Ohne jetzt die Linienbuendeldiskussion konkret zu kennen, scheint das wieder mal eine eierlegende Wollmilchsau werden zu sollen, die alles oder nichts definiert. Ich habe kein Problem damit, fuer eine Trivialsituation, die 1000 mal vorkommt einen eigenen Loesungsweg zu definieren, der den einen Ausnahmefall nicht erschleagt. Autobahnein-/ ausfahrten sind so ein Trivialproblem, die man fast komplett mit einer einfachen Definition erschlagen kann. Ansonsten war ich Anfangs bei der Radwegdiskussion mit dabei, als Leute anfingen, Radwege schief und krumm neben die Strassen zu malen. Ich war und bin der Meinung, dass der beste Ansatz der Parallellinienansatz ist. Ist ein Radweg bautechnisch von der Fahrbahn abhaengig, ist es ein Objekt und ein Linienbuendel ist ueberfluessig. Wenn das Basismodell (nodes, ways, relations -jeweils mit der Beschraenkung auf eine Attributsebene) zu schwach ist, um komplexe Attribute aufzunehmen, sollte man mal drueber nachdenken ob man auf den richtigen Weg ist, statt ein Preudonetz mit Linienbuendeln aufzubleahen. Funktioniert das mit deinem Modell auch oder ist das eine ausschließlich auf die Anforderungen eines heutigen Standard-Autonavis zugeschnittene Lösung, die mit darüber hinausgehenden Detailinfos nicht zurecht kommt? Das Prinzip, dass man alles, was von einer Basislinie abhaengig ist, als Parallellinie abzubilden kann, ist universell und es ist naturgemaess die effizienteste Abbildung. -- Nur bis 16.03.! DSL-Komplettanschluss inkl. WLAN-Modem für nur 17,95 ¿/mtl. + 1 Monat gratis!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abstraktionsebenen und Fahrerinformation
Am Mittwoch 11 März 2009 schrieb qbert biker: Original-Nachricht Datum: Wed, 11 Mar 2009 12:39:37 +0100 Von: Guenther Meyer d@sordidmusic.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Abstraktionsebenen und Fahrerinformation 0m drei fahrspuren, wechsel beliebig moeglich motorway lanes=3 200mverbreiterung um eine spur nach rechts (beginn der ausfahrt) nix, siehe unten warum hier nicht motorway lanes=4? physisch ist das in dem bereich mit einer vierspurigen autobahn fast identisch, der einzige unterschied ist die meist etwas breitere strichellinie zwischen den beiden rechten spuren. 400meine fuenfte fahrspur wird rechts angefuegt motorway lanes=5 outlane 200 600mdie rechten beiden fahrspuren werden physisch von den anderen getrennt Knoten - Das Zusammenlaufen der Spuren kann man errechnen Gradeaus lane=3 rechts lanes=2 800mdie rechte fahrspur zweigt ab und entfernt sich (richtung abc), der rest geradeaus weiter Noch ein Knoten Gradeaus lanes=2 rechts lanes=1 ok, kam vielleicht nicht ganz richtig rueber: 3 spuren autobahn sind immer noch vorhanden, die separate abbiegespur trennt sich; waere also gradeaus lanes=3, daneben ab knoten gradeaus und rechts jeweils lanes=1. 1000m die rechte fahrspur teilt sich in eine abzweigende, sich entfernende (richtung xyz) und eine geradeaus weiterfuehrende spur Auch ein Knoten lanes=1 und lanes=1 die drei spuren weiterfuehrende autobahn links daneben vernachlaessigst du, nehm ich an? 1400m an die rechte fahrspur fuegt sich eine von rechts kommende spur an Wieder die Hauptrichtung? motorway lanes=3 in_lane=400m waere fuer mich ein knoten, nach dem lanes=2 1600m die kommende neue rechte spur endet implizit oben erfasst wo ist der vorteil dieser methode? ich finde, es ist einfacher, wenn man beim simplen lanes-modell bleibt, anstatt ein zusaetzliches attribut einzufuegen. 1800m die physische abtrennung von den linken drei spuren endet - vier fahrspuren Eine physisch getrennte Fahrbahn ist immer ein eigener Link. Bei den lanes kann ich dir nicht folgen hmm, vielleicht haette ich es aufzeichnen sollen... im grossen und ganzen haette ich das recht aehnlich gemacht: - was physisch getrennt ist, ist ein eigener way - was zusammen ist, wird durch lanes verbreitert. 2000m die rechte fahrspur endet - drei fahrspuren bei einem autobahnkreuz hast du das ganze viermal auf relativ engem raum. Ist ueberhaupt kein Problem. Was eigenstaendig laeuft, bleibt eigenstaendig. Alle Spuren ineinander ueberzufuehren geht problemlos, wenn sie sauber erfasst sind. Ich brauch fuer eine exakte vollstaendige Darstellung nur das echte Netz 'physische Trennung' und die Spuren. Eine Abstraktion von Ein/Ausfaedelspuren ist zwar nicht notwendig, erleichtert die Sache aber etwas. Problematisch wirds nur bei sowas: 2 - - - - 3 Also von Spur 2 nach 3 darf man nicht, von 3 nach 2 schon. Hier wuerde ich den internal_divider verwenden mit den durchnummerierten Spuren: internal_divider 2,3,oneway was sagt mir da, in welche richtung ich wechseln darf? die reihenfolge, die du so definierst? signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abstraktionsebenen und Fahrerinformation
2009/3/11 Guenther Meyer d@sordidmusic.com: nochmal: die wechselmoeglichkeit bzw. laenge der spur ist irrelevant fuer eine benachrichtigung. Ja, weil die Router eh schon mindestens einen Kilometer vorher warnen und das Verhalten oft sogar eingestellt werden kann. Und da uns die Länge der vorangehenden Spur aus diesem und anderen Gründen egal sein kann, gibt es keinen vernünftigen Grund, im Falle von Autobahnausfahrten unser Datenmodell zu brechen(eine Fahrbahn=ein way). Was soll also die Aufregung? Ich mappe schon von Anfang an so, wie Hubert es vorschlägt. Navit kommt damit klar, Garmin kommt damit klar... wer nicht? Mappen für einen hypothetischen Router, der nicht früh genug warnt, ist m.E. schon schlimmer als für einen konkret existierenden Renderer zu mappen... ;-) Grüße, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abstraktionsebenen und Fahrerinformation
Original-Nachricht Datum: Wed, 11 Mar 2009 19:34:51 +0100 Von: Guenther Meyer d@sordidmusic.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Abstraktionsebenen und Fahrerinformation warum hier nicht motorway lanes=4? Ist eine Alternative. Wollte eigentlich nur eine moegliche Vereinfachung demonstrieren, bei der man nicht wegen jeder Einfädelspur nochmal aufteilen muss. physisch ist das in dem bereich mit einer vierspurigen autobahn fast identisch, der einzige unterschied ist die meist etwas breitere strichellinie zwischen den beiden rechten spuren. Man kann auch die normale Einfädelspur per lane und Abschnittsbildung abbilden, allerdings könnte man sich das Leben einfacher machen, wenn man ein tag vergibt, das alles pauschal beschreibt. Da ich selber eine Visualisierung habe, die auf Spuren auflöst, habe ich das bei komplexen Autobahnkreuzungen auch ausprobiert - funzt ganz gut. die drei spuren weiterfuehrende autobahn links daneben vernachlaessigst du, nehm ich an? Ich hatte 'physisch getrennt' in Erinnerung und das bedeutet einen eigenen Link und Trennungsknoten. Ich denke, dass eine dieser Seitenspuren im Autobahnkreuz gemeint ist und die kann man nur als eigenen Link sinnvoll abbilden. wo ist der vorteil dieser methode? ich finde, es ist einfacher, wenn man beim simplen lanes-modell bleibt, anstatt ein zusaetzliches attribut einzufuegen. Ich bin da gar nicht abgeneigt, dir zuzustimmen. Allerdings sind Ein-/Ausfahrten häufiger als Kreuze und auch in Kreuzen kann man Muster bilden wie die Einfädelspur und die duplizieren. Ein anderes Experiment ist, dass man die Idee mit den wiederholenden Mustern weiterspinnt und Makros bildet, die z.B. ein Standardkreuz komplett abbilden. hmm, vielleicht haette ich es aufzeichnen sollen... Es kam schon rueber, was gemeint war, denk ich. im grossen und ganzen haette ich das recht aehnlich gemacht: - was physisch getrennt ist, ist ein eigener way - was zusammen ist, wird durch lanes verbreitert. genau. was sagt mir da, in welche richtung ich wechseln darf? die reihenfolge, die du so definierst? Eine Definition der Zaehlrichtung, z.B. linke Spur ist 1 und dann wird hochgezaelt (GB invers). Es hat sich in meinen Tests bewaehrt, links anzufangen, weil die linke Spur normalerweise sehr stabil ist, das Durcheinander ist meistens rechts. Ich definiere auch für meine Visualisierung den linken Rand als die Linie, die den Node-Koordinaten entspricht. Bei einer Ueberhöhung der Fahrbahnbreite wird dann nicht die Gegenfahrbahn 'ueberkleckst' (wie bei den SVG-Renderern), sondern die die Richtungen 'wachsen' voneinander weg. -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abstraktionsebenen und Fahrerinformation
Am Mittwoch 11 März 2009 schrieb qbert biker: Original-Nachricht Datum: Wed, 11 Mar 2009 19:34:51 +0100 Von: Guenther Meyer d@sordidmusic.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Abstraktionsebenen und Fahrerinformation warum hier nicht motorway lanes=4? Ist eine Alternative. Wollte eigentlich nur eine moegliche Vereinfachung demonstrieren, bei der man nicht wegen jeder Einfädelspur nochmal aufteilen muss. naja, vereinfachung ist relativ: entweder man hat im prinzip nur lanes auszuwerten, und dafuer viele aufteilungen, oder man spart sich die aufteilungen, muss dafuer aber zusaetzlich andere attribute auswerten... physisch ist das in dem bereich mit einer vierspurigen autobahn fast identisch, der einzige unterschied ist die meist etwas breitere strichellinie zwischen den beiden rechten spuren. Man kann auch die normale Einfädelspur per lane und Abschnittsbildung abbilden, allerdings könnte man sich das Leben einfacher machen, wenn man ein tag vergibt, das alles pauschal beschreibt. Da ich selber eine Visualisierung habe, die auf Spuren auflöst, habe ich das bei komplexen Autobahnkreuzungen auch ausprobiert - funzt ganz gut. alles mit einem tag pauschal zu beschreiben stell ich mir schwierig vor... und wenn man hier zum beispiel mit lanes = 3 + 1 taggen wuerde? die drei spuren weiterfuehrende autobahn links daneben vernachlaessigst du, nehm ich an? Ich hatte 'physisch getrennt' in Erinnerung und das bedeutet einen eigenen Link und Trennungsknoten. Ich denke, dass eine dieser Seitenspuren im Autobahnkreuz gemeint ist und die kann man nur als eigenen Link sinnvoll abbilden. richtig, so wars gedacht. wo ist der vorteil dieser methode? ich finde, es ist einfacher, wenn man beim simplen lanes-modell bleibt, anstatt ein zusaetzliches attribut einzufuegen. Ich bin da gar nicht abgeneigt, dir zuzustimmen. Allerdings sind Ein-/Ausfahrten häufiger als Kreuze und auch in Kreuzen kann man Muster bilden wie die Einfädelspur und die duplizieren. Ein anderes Experiment ist, dass man die Idee mit den wiederholenden Mustern weiterspinnt und Makros bildet, die z.B. ein Standardkreuz komplett abbilden. es ist eigentlich egal, ob es ein kreuz, ein dreieck, eine ausfahrt, oder sonstwas ist; das schema bleibt das gleiche... hmm, vielleicht haette ich es aufzeichnen sollen... Es kam schon rueber, was gemeint war, denk ich. im grossen und ganzen haette ich das recht aehnlich gemacht: - was physisch getrennt ist, ist ein eigener way - was zusammen ist, wird durch lanes verbreitert. genau. was sagt mir da, in welche richtung ich wechseln darf? die reihenfolge, die du so definierst? Eine Definition der Zaehlrichtung, z.B. linke Spur ist 1 und dann wird hochgezaelt (GB invers). Es hat sich in meinen Tests bewaehrt, links anzufangen, weil die linke Spur normalerweise sehr stabil ist, das Durcheinander ist meistens rechts. klingt logisch. Ich definiere auch für meine Visualisierung den linken Rand als die Linie, die den Node-Koordinaten entspricht. Bei einer Ueberhöhung der Fahrbahnbreite wird dann nicht die Gegenfahrbahn 'ueberkleckst' (wie bei den SVG-Renderern), sondern die die Richtungen 'wachsen' voneinander weg. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abstraktionsebenen und Fahrerinformation
Original-Nachricht Datum: Wed, 11 Mar 2009 20:41:57 +0100 Von: Guenther Meyer d@sordidmusic.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Abstraktionsebenen und Fahrerinformation naja, vereinfachung ist relativ: entweder man hat im prinzip nur lanes auszuwerten, und dafuer viele aufteilungen, oder man spart sich die aufteilungen, muss dafuer aber zusaetzlich andere attribute auswerten... Exakt, ich hatte mich bei einem anderen System für zweiteres entschieden und fand es handlicher. Aber es bleibt Geschmackssache und einen grossartigen Vorteil kann ich bei keiner Variante ausmachen. Grüsse Hubert -- Nur bis 16.03.! DSL-Komplettanschluss inkl. WLAN-Modem für nur 17,95 ¿/mtl. + 1 Monat gratis!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abstraktionsebenen und Fahrerinformation
qbert biker schrieb: Hallo Liste, ich les ja nicht mehr so viel mit, weils etwas unuebersichtlich geworden ist hier und mir die Zeit fehlt, mich durch alles durchzuwerkeln, aber letztens sind mir bei einer Diskussion um Autobahneinfahrten ein paar Sachen eingefallen, die vielleicht den einen oder anderen interessieren. Um Dingen wie 'OSM ist anders' und 'wir mappen nicht für...' vorzubeugen, beziehe ich mich auf ein abstraktes Fahrerinformationssystem. Wie und was sich dann auf OSM abbilden lässt, soll jeder für sich selbst entscheiden oder gleich alles verwerfen ;) Ein Fahrerinformationssystem soll aus den gebotenen Daten Meldungen erzeugen können, die ihn möglichst gut durch das Verkehrsdickicht leiten. Ein relativ einfacher Fall ist das Ein- und Ausfahren von der Autobahn. Der Vorgang besteht aus zwei Phasen, das Einordnen und das Verlassen der Autobahn. Eine bewährte Abstraktion ist, alle Spuren einer Fahrbahn zwischen denen man wechseln kann, zu einer Verbindung (link) zusammenzufassen. Auch die Einfaedelspur ist so eine Spur und bis zu deren Ende kann man sich noch umorientieren und wieder auf die Autobahn zurück. Am Ende der Ausfädelspur beginnt eine eigene Fahrbahn mit unabhaengigen Verlauf. Dem traegt man Rechnung, indem man den Knoten exakt an den Verzeigungspunkt setzt und die Einfädelspur selber als Spur der Autobahn zurechnet (bei der Einfahrt entsprechend invers). Der Haken an der Sache ist, dass ein Informationssystem, das nur die Daten der aktuellen Position hat, viel zu spät eine Meldung an den Fahrer geben würde. Ein Lösungsansatz wäre, die Abfahrt, also den Verzweigungsknoten an den Anfang der Ausfädelspur zu setzen, aber dann wird die Abstraktion gebrochen und dem System die Information vorenthalten, dass ein Wechsel durchaus noch moeglich ist. Man sollte auch bedenken dass solche Aus/Einfädelstreifen nicht selten nict in vollem Umfang nutzbar sind - Tagesbaustellen, liegengebliebenes Fahrzeug, Ummarkierung, Zugeschneit,... Von daher könnte eine zu detaillierte Wiedergabe dieser Fahrstreifen der Orientierung ehr Schaden als nützen wenn die Realität anderst aussieht als es die Darstellung erwarten lässt. In der Höhe der Ausfahrt erfordert der Fahspurwechsel erhöhte Aufmerksamkeit so dass man nicht durch unnötige Informationen abgelenkt werden sollte. Eine Wiedergabe der Beschilderung entsprechenden den Werbedarstellungen der neueren Spurgetreuen Navis in Zielrichtung rechtzeitig vor der Ausfaht erscheint da hilfreicher. Wird die Abstraktion beibehalten und der Verzweigungsknoten bleibt am Ende der Ausfädelspur gibts folgende Möglichkeiten, dem Informationssystem mitzuteilen, wann der Wechsel moeglich ist: A) Markierung (z.B. expliziter Knoten) am Anfang der Ausfädelspur B) Zusaetzlicher Parameter am Entscheidungsknoten, der die Laenge der Einfeadelspur angibt. C) Auswertung von externen Regeln (Bab - BaST) Bei B und C muss das Informationssystem den eigentlichen Entscheidungspunkt zurückrechnen, was durch eine Vorverarbeitung der Eingangsdaten geschehen kann. Wenn z.B. bekannt ist, dass auf deutschen Autobahahnen die Ein- Ausfädelspuren typischerweise eine gewisse Länge haben, kann das von der Vorverarbeitung ausgewertet werden, ohne dass der Mapper sich gross drum kümmern muss. Er trägt nur ein, wo der Verzeigungsknoten ist, den Rest übernimmt ein Algorithmis, der bei Bedarf auch die Position der Vorbeschilderung (Baken, 1km, usw.) errechnet. Von typisch würde ich hier nicht ausgehen - es kommt alles vor von nicht vorhanden bis in den Kilometer-Bereich. Eine Markierung am Point of no return deckt mit einem einzigen node den kompletten Bereich für alle vorkommenden Bereiche in den Grundeigenschaften ab. Gegebenfalls kann man ja noch eine max. Abbiegegeschwindigkeit angeben bzw. aus dem Kurvenradius errechnen lassen um rechtzeitig auf überhöhte Geschwindigkeit hinweisen zu können. Schwieriger ist die Frage, ob man bei durchgezogenen Linien, die die Spuren einer Fahrtrichtung trennen, z.B. um den Abbiegeverkehr zu harmonisieren von der Abstraktion abgehen soll. Die beste Lösung, die mir bisher dazu eingefallen ist, ist analog zum divider, der internal_divider, der Spuren einer Fahrtrichtung trennt. Damit kann man dem Fahrer rechtzeitig mitteilen, dass er nicht abbiegen kann, wenn er die Spur nicht wechseln kann, wenn er der internal divider erreicht hat. Ich kenne die durchgezogen Linie überwiegend für Einfädelspuren um die Effektivität des *Beschleunigungs*streifen zu unterstützen, seltner bei Verzögerungsstreifen. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Abstraktionsebenen und Fahrerinformation
Hallo Liste, ich les ja nicht mehr so viel mit, weils etwas unuebersichtlich geworden ist hier und mir die Zeit fehlt, mich durch alles durchzuwerkeln, aber letztens sind mir bei einer Diskussion um Autobahneinfahrten ein paar Sachen eingefallen, die vielleicht den einen oder anderen interessieren. Um Dingen wie 'OSM ist anders' und 'wir mappen nicht für...' vorzubeugen, beziehe ich mich auf ein abstraktes Fahrerinformationssystem. Wie und was sich dann auf OSM abbilden lässt, soll jeder für sich selbst entscheiden oder gleich alles verwerfen ;) Ein Fahrerinformationssystem soll aus den gebotenen Daten Meldungen erzeugen können, die ihn möglichst gut durch das Verkehrsdickicht leiten. Ein relativ einfacher Fall ist das Ein- und Ausfahren von der Autobahn. Der Vorgang besteht aus zwei Phasen, das Einordnen und das Verlassen der Autobahn. Eine bewährte Abstraktion ist, alle Spuren einer Fahrbahn zwischen denen man wechseln kann, zu einer Verbindung (link) zusammenzufassen. Auch die Einfaedelspur ist so eine Spur und bis zu deren Ende kann man sich noch umorientieren und wieder auf die Autobahn zurück. Am Ende der Ausfädelspur beginnt eine eigene Fahrbahn mit unabhaengigen Verlauf. Dem traegt man Rechnung, indem man den Knoten exakt an den Verzeigungspunkt setzt und die Einfädelspur selber als Spur der Autobahn zurechnet (bei der Einfahrt entsprechend invers). Der Haken an der Sache ist, dass ein Informationssystem, das nur die Daten der aktuellen Position hat, viel zu spät eine Meldung an den Fahrer geben würde. Ein Lösungsansatz wäre, die Abfahrt, also den Verzweigungsknoten an den Anfang der Ausfädelspur zu setzen, aber dann wird die Abstraktion gebrochen und dem System die Information vorenthalten, dass ein Wechsel durchaus noch moeglich ist. Wird die Abstraktion beibehalten und der Verzweigungsknoten bleibt am Ende der Ausfädelspur gibts folgende Möglichkeiten, dem Informationssystem mitzuteilen, wann der Wechsel moeglich ist: A) Markierung (z.B. expliziter Knoten) am Anfang der Ausfädelspur B) Zusaetzlicher Parameter am Entscheidungsknoten, der die Laenge der Einfeadelspur angibt. C) Auswertung von externen Regeln (Bab - BaST) Bei B und C muss das Informationssystem den eigentlichen Entscheidungspunkt zurückrechnen, was durch eine Vorverarbeitung der Eingangsdaten geschehen kann. Wenn z.B. bekannt ist, dass auf deutschen Autobahahnen die Ein- Ausfädelspuren typischerweise eine gewisse Länge haben, kann das von der Vorverarbeitung ausgewertet werden, ohne dass der Mapper sich gross drum kümmern muss. Er trägt nur ein, wo der Verzeigungsknoten ist, den Rest übernimmt ein Algorithmis, der bei Bedarf auch die Position der Vorbeschilderung (Baken, 1km, usw.) errechnet. Etwas schwieriger wird es innerorts, aber auch da können Automatismen typische Konstellationen zurückrechnen. Oft ist die einfache Angabe, dass es zu einer Abbiegebeziehung eine Linksabbiegerspur gibt ausreichend und das deckt die Masse an Situationen ab. Schwieriger ist die Frage, ob man bei durchgezogenen Linien, die die Spuren einer Fahrtrichtung trennen, z.B. um den Abbiegeverkehr zu harmonisieren von der Abstraktion abgehen soll. Die beste Lösung, die mir bisher dazu eingefallen ist, ist analog zum divider, der internal_divider, der Spuren einer Fahrtrichtung trennt. Damit kann man dem Fahrer rechtzeitig mitteilen, dass er nicht abbiegen kann, wenn er die Spur nicht wechseln kann, wenn er der internal divider erreicht hat. So, das wars schon - frohes Mapping noch -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abstraktionsebenen und Fahrerinformation
qbert biker schrieb: Hallo Liste, ich les ja nicht mehr so viel mit, weils etwas unuebersichtlich geworden ist hier und mir die Zeit fehlt, mich durch alles durchzuwerkeln, aber letztens sind mir bei einer Diskussion um Autobahneinfahrten ein paar Sachen eingefallen, die vielleicht den einen oder anderen interessieren. Um Dingen wie 'OSM ist anders' und 'wir mappen nicht für...' vorzubeugen, beziehe ich mich auf ein abstraktes Fahrerinformationssystem. Wie und was sich dann auf OSM abbilden lässt, soll jeder für sich selbst entscheiden oder gleich alles verwerfen ;) Ein Fahrerinformationssystem soll aus den gebotenen Daten Meldungen erzeugen können, die ihn möglichst gut durch das Verkehrsdickicht leiten. Ein relativ einfacher Fall ist das Ein- und Ausfahren von der Autobahn. Der Vorgang besteht aus zwei Phasen, das Einordnen und das Verlassen der Autobahn. Eine bewährte Abstraktion ist, alle Spuren einer Fahrbahn zwischen denen man wechseln kann, zu einer Verbindung (link) zusammenzufassen. Auch die Einfaedelspur ist so eine Spur und bis zu deren Ende kann man sich noch umorientieren und wieder auf die Autobahn zurück. Zu mindest nach meiner Erfahrung und Beobachtung wird hier die Ausfahrt jeweils (meist ein bisschen geschätzt) ab dem Beginn der Einfädelspur gemappt. D.h. ein Stück parallel zur Autobahn/Straße und dann knickts eben ab. Andere Ausfahrten (ohne Einfädelspur) werden dem entsprechend anders gemappt. Finde ich so sehr intuitiv und sinnvoll. Aber ich denke ansonsten kann man, wie du auch erwähnst, das Problem halbwegs gut mit Algorithmen lösen. Imo muss man doch eh vorher sagen, dass in 1,5 Km die Abfahrt kommt und dann kann man ja nochmal 200m davor ansagen etc. Für den User ist das nicht so wichtig, weil er zum einen die Entfernung nicht so gut schätzen kann (d.h. eine leicht falsch berechnete Ansage fällt kaum oder gar nicht auf) und zum anderen sowieso auf Schilder etc. achten muss. Wie du sagst, ist es innerorts schwieriger, aber da sind die Geschwindigkeiten nicht so hoch, d.h. man muss nicht so früh warnen bzw. der User hat mehr Zeit und es gibt nicht so häufig Einfädelspuren. Ich glaube, ich weiß halbwegs worauf du hinaus willst, aber sehe nicht so ganz das Problem. Im Übrigen lehrt mich meine Erfahrung mit (kommerziellen) Autonavigationssystemen, dass die schlimmen Fehler an ganz anderen Stellen liegen (v.a. schlechtes Kartematerial bzw. falsch/ unoptimal berechnete Route) Just my 2 cents Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abstraktionsebenen und Fahrerinformation
Original-Nachricht Datum: Tue, 10 Mar 2009 20:40:01 +0100 Von: Jonas Krückel (John07) o...@jonas-krueckel.de An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Abstraktionsebenen und Fahrerinformation Zu mindest nach meiner Erfahrung und Beobachtung wird hier die Ausfahrt jeweils (meist ein bisschen geschätzt) ab dem Beginn der Einfädelspur gemappt. D.h. ein Stück parallel zur Autobahn/Straße und dann knickts eben ab. Andere Ausfahrten (ohne Einfädelspur) werden dem entsprechend anders gemappt. Finde ich so sehr intuitiv und sinnvoll. Intuitiv in dem Sinn, dass man auf den tracks meist den Spurwechsel sehen kann und das entsprechend darstellt. Die echte Netzdarstellung ist nicht immer so intuitiv, verschluckt aber weniger Informationen. Zieht man die Einfädelspur auf einen eigenen Link, ist die Information, dass man noch wechseln kann, erstmal futsch. Die Abbildung wird dadurch ungenauer. Auch wenn man jetzt noch vorne rechnet und die Einfädelspur in Fahrtrichtung definiert, kann man jetzt im Modell trotzdem nicht mehr zurück auf die Autobahn, weil keine Verbindung besteht. Abstraktion ist ein meachtiges Hilfsmittel, aber nur wenn man sie konsequent anwendet. -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
