Re: [Talk-de] Konzept für straßenbegleitende Wege
Am 01.01.2012 23:17, schrieb Georg Feddern: Der 1.) Fall funzt tatsächlich nur, wenn der Router erkennen kann, dass der straßenbegleitende Radweg zu einer primary gehört. Einfacher Ansatz: Statt einem banalen yes könnte man als Würg-around die Straßenklasse angeben. Der Würg-around klappt aber auch nur, wenn es nur um die Straßenklasse geht. Wie schaut es aus, wenn alle Straßen mit einer maxspeed über 50 schlechter dastehen sollen oder mit mehr als 1 Spur je Richtung oder unbeleuchtet. Gleiches ist aber auch andersrum nötig. Bspw. nur dort langrouten, wenn der Radweg auch asphaltiert ist usw. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für straßenbegleitende Wege
Moin Sven! Am 31.12.2011 11:16, schrieb Sven Anders: Danke für die ausführlichen und konstruktiven Kommentare. Straßen, für die ein straßenbegleitender Radweg als eigener way existiert, erhalten ein Zusatztag: attendant_cycleway_exists=yes Alternativ: attendant_ways=cyleway;pedestrian Ja, das ist sinnvoller. Straßenbegleitende Radwege erhalten ein Zusatztag attendant_cycleway=yes Alternativ: attendant=yes Ebenfalls besser. Getrennten Richtungsfahrbahnen einer Straße erhalten ein Zusatztag, das ihre Lage beschreibt. Bei einer grob in Ost-West-Richtung verlaufenden Straße wäre dies dual_carriageway=north (Nordfahrbahn in Fahrtrichtung West) und dual_carriageway=south , bei Nord-Süd-Strecken analog dual_carriageway=east|west. Bei Nordwest-Südost-Stecken hat der Mapper freie Wahl. b) die Richtungsangaben, machen IMHO bei vielen Straßen Probleme, z.B. Serbentienen oder auch Wohnstraßen die im Kreis gehen etc. Tritt das Problem häufig auf? Die meisten Straßen mit durchgängig getrennten Richtungsfahrbahnen sind Durchgangsstraßen mit wenigen Richtungswechseln. Solche Straßen sind in der Regel ohnehin segmentiert, so dass man dem Westring dual_carriageway=east|west, dem Nordring dual_carriageway=north|south, etc. zuweisen kann. Falls es irgendwo eine im Kreis laufende Wohnstraße mit Mittelstreifen gibt, müsste man sie für meinen Vorschlag einmal auftrennen. vielleicht reicht es aus ein Tag wie linienbuendel=-1 highway=cyleway linienbuendel=0 highway=primary oneway=true linienbuendel=1 highway=primary oneway=true linienbuendel=2 highway=cyleway Ich wollte vermeiden, dass der Mapper eine von zwei meist gleichberechtigten Richtungsfahrbahnen als Referenz auswählen muss. Deshalb habe ich die neutrale Bezeichnung east|west vorgeschlagen. Die Zählung kann man ohne eine Relation, die die ways zusammenfasst, kaum auswerten. Dann hat man aber ein deutlich komplexeres Datenmodell. Für die von mir genannten Vorteile ist die Zählung unnötig. Das Konzept kommt ohne zusätzliche Relationen aus und ist kompatibel zu den bislang vorhandenen Daten und Anwendungen. Vorteile: - Renderer können in kleinem Zoomlevel (z=12) bei Straßen mit Mittelstreifen nur eine Doppellinie statt zwei überlappender Fahrbahnen zeichnen. Bei beiden Vorschlägen gegeben, bei mir wird dann nur linienbündel=0 (Default) gerendert Zweigleisige Bahnstrecken können als dickere Linie dargestellt werden. Dein Vorschlag: Mir nicht ganz klar, wie man herausbekommt, das da 10 Bahnlinen nebeneinander laufen um die noch dicker zu malen. Mein Vorschlag hilft nur um ein- und mehrgleisige Strecken zu unterscheiden. Wenn ich es richtig verstanden habe, gehören in Deutschland maximal zwei Gleise zu einer Bahnstrecke. 10 nebeneinander liegende Gleise wären wie bisher nur als Verbreiterung bis zum mittleren Zoomlevel erkennbar. - Renderer können Einbahnstraßenpfeile bei Straßen mit Mittelstreifen vermeiden (bei vielen Stadtplänen üblich) Beide Vorschläge: Ist glaube ich mit einfacher Logik nicht so einfach heraus zu bekommen. Dafür müsste man die Wege doch in einer Relation packen. Ich dachte, die Logik sei trivial. dual_carriageway=... kommt nur bei Richtungsfahrbahnen vor (Pfeile unnötig), aber nie bei echten Einbahnstraßen (Pfeile wichtig). Deine Variante linienbuendel=Zahl bietet diese Unterscheidung nicht. Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für straßenbegleitende Wege
Moin Andreas! Am 31.12.2011 13:06, schrieb Andreas Labres: Hallo! Ich will mich da gar nicht groß einmischen, schlage aber vor, die komplexesten Problemstellungen im Auge zu behalten! Z.B. auf der Wiener Ringstraße gibt es, ausgehend von einer Mittellinie der Straße: - im Schnitt zwei Fahrspuren (1) - Straßenbahngleise (G) - eine Alleereihe - einen Gehweg (2) - einen Radweg (3) - eine Alleereihe - eine Nebenfahrbahn (4) - einen Gehsteig (5) Sofern diese Objekte bislang als Einzellinien erfasst sind (ich kenne die Straße nicht), würde man folgende Tags hinzufügen: zu (1): attendant_ways=cyleway;footway zu (2): attendant=yes zu (3): attendant=yes zu (4): attendant_ways=footway zu (5): attendant=yes Wenn zwei Straßenbahngleise nebeneinander liegen zu (G, östliches Gleis) dual_carriageway=east zu (G, westliches Gleis) dual_carriageway=west Selbst bei den komplexesten Problemstellungen wäre der Zusatzaufwand überschaubar. Ein Renderer oder Router _kann_ diese Zusatztags auswerten, um die Darstellung im mittleren Zoomlevel bzw. die Routingansagen zu verbessern. Einbahnen in beliebiger Richtung (entgegen der Richtung der Hauptfahrbahn), Radwege detto, außerdem Varianten wie Abbiegespuren, Haltestellen-Plattformen, Grünstreifen, etc. Nichts davon würde verändert. Hilfreich wäre sicher auch ein Zahlenwert, wie weit das jeweilige Ding von der Mittellinie weg ist. - Sodass man wirklich einen Straßenquerschnitt modellieren kann. Du hast meinen Vorschlag missverstanden. Ich möchte keine neue Methode einführen, um Straßenquerschnitte zu modellieren. Das geschieht weiterhin über die einzelnen ways. Mein Vorschlag soll nur helfen, einige Nachteile auszugleichen, die sich durch die parallelen Einzelwege ergeben. Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für straßenbegleitende Wege
Am 31.12.2011 12:29, schrieb Henning Scholland: Es bleiben also nur unzählige Relationen (fände ich suboptimal, da sehr fehleranfällig) Ja, fehleranfällig, mühsam für den Mapper, kompliziert für den Renderer. oder aber ein mehrfaches eintragen von den relevanten Informationen. Mehrfaches eintragen macht Arbeit und provoziert widersprüchliche Daten. Dazu bräuchte es an den straßenbegleitenden Wegen ein straßenbegleitend=yes und die üblichen Taggs für diesen Weg. Das entspricht meinem Vorschlag. An dem Hauptweg bräuchte es dann die Taggs wie cycleway:left/right=yes|no|oneway, cycleway:left/right:surface=... usw. Warum sollten diese Informationen am Hauptweg nochmals stehen? Der Router sieht doch beide ways und berechnet nach Vorgaben des Nutzers die bessere Alternative. Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für straßenbegleitende Wege
Servus, erstmal noch ein Gutes Neues Jahr! Straßen, für die ein straßenbegleitender Radweg als eigener way existiert, erhalten ein Zusatztag: attendant_cycleway_exists=yes Unabhängig vom Rest des Vorschlags möchte ich jetzt doch noch eine Anmerkung machen: attendant klingt für micht nicht ganz optimal - ich denke da spontan an flight attendant. Auch die Wörterbücher meines Vertrauens brachten eher eine andere Bedeutung zu Tage. Es soll ja vermutlich um verbunden oder zugehörig gehen. Da wären accompanying oder associated vermutlich besser. Insgesamt sollten wir wohl am besten einen Muttersprachler zu Rate ziehen. Grüße, Michael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für straßenbegleitende Wege
Am 01.01.2012 16:15, schrieb Stephan Wolff: Am 31.12.2011 12:29, schrieb Henning Scholland: oder aber ein mehrfaches eintragen von den relevanten Informationen. Mehrfaches eintragen macht Arbeit und provoziert widersprüchliche Daten. Dazu bräuchte es an den straßenbegleitenden Wegen ein straßenbegleitend=yes und die üblichen Taggs für diesen Weg. Das entspricht meinem Vorschlag. An dem Hauptweg bräuchte es dann die Taggs wie cycleway:left/right=yes|no|oneway, cycleway:left/right:surface=... usw. Warum sollten diese Informationen am Hauptweg nochmals stehen? Der Router sieht doch beide ways und berechnet nach Vorgaben des Nutzers die bessere Alternative. Spontan fallen mir zwei Fälle ein, wo alle Information an einem Hauptweg nötig sind. 1.) Stell dir vor, du möchtest unter keinen umständen entlang einer primary fahren. Nach deinem Schema könnte der Router zwar die primary an sich sperren, auf dem Radweg daneben würde er mich aber lang routen. FEHLER 2.) Ich möchte unter keinen Umständen auf Straßen fahren, die über straßenbegleitende Radwege verfügen. Ähnliches Problem wie oben. Der Router sperrt zwar den Radweg, routet aber munter über den Hauptweg. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für straßenbegleitende Wege
2011/12/30 Stephan Wolff s.wo...@web.de Moin, in OSM werden immer Wege im Detail erfasst. Straßenbegleitende Rad- und Fußwege werden zu eigenen ways, zweigleisige Bahnstrecken zu zwei Einzellinien. Dies hat natürlich viele Vorteile, verursacht aber auch suboptimale Karten in kleinem bis mittlerem Zoomlevel oder unnötige Routinganweisungen. Früher oder später werden wir uns wohl auch mit Fahrspurmapping beschäftigen müssen. Das Konzept kommt ohne zusätzliche Relationen aus... Ganz schlecht! Das ist doch gerade so ein Fall, für den die Relationen erfunden worden sind: Mehrere Objekte stehen in relation zueinander! Ich sehe garkeinen anderen langfristig sinnvollen Weg als eine Relation für sowas. Vlt. mit type=road oder so. Da könnte man dann viele Sachen auf einmal erledigen. Nicht nur das Verknüpfen mit straßenbegleitenden Wegen, sondern auch das Verknüpfen mit area:highway=* oder Fahrspuren. Selbst die associatedStreet-Relationen könnten darin aufgehen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für straßenbegleitende Wege
Moin, Am 01.01.2012 20:05, schrieb Henning Scholland: Spontan fallen mir zwei Fälle ein, wo alle Information an einem Hauptweg nötig sind. 1.) Stell dir vor, du möchtest unter keinen umständen entlang einer primary fahren. Nach deinem Schema könnte der Router zwar die primary an sich sperren, auf dem Radweg daneben würde er mich aber lang routen. FEHLER 2.) Ich möchte unter keinen Umständen auf Straßen fahren, die über straßenbegleitende Radwege verfügen. Ähnliches Problem wie oben. Der Router sperrt zwar den Radweg, routet aber munter über den Hauptweg. möglicherweise habe ich jetzt etwas übersehen, aber ich habe den Vorschlag so verstanden, dass an beiden Wegen (Straße und Rad/Fußweg) ein Hinweis auf straßenbegleitend steht. Demzufolge müsste der Router im 2.) Fall nur _beide_ Wege meiden - Du möchtest ja straßenbegleitend generell vermeiden. Der 1.) Fall funzt tatsächlich nur, wenn der Router erkennen kann, dass der straßenbegleitende Radweg zu einer primary gehört. Einfacher Ansatz: Statt einem banalen yes könnte man als Würg-around die Straßenklasse angeben. Wie von mehreren erkannt und von Stephan zugegeben ist dies kein Ersatz für Linienbündel oder Straßenquerschnitt - aber eine einfache Router- und Renderhilfe. Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für straßenbegleitende Wege
Moin! Am 01.01.2012 21:02, schrieb Robert S.: 2011/12/30 Stephan Wolffs.wo...@web.de Das Konzept kommt ohne zusätzliche Relationen aus... Ganz schlecht! Relationen sind doch kein Selbstzweck. Das ist doch gerade so ein Fall, für den die Relationen erfunden worden sind: Mehrere Objekte stehen in relation zueinander! Ich möchte Radwege unterscheiden in straßenbegleitend und eigenständig. Die Klassifikation ist gerade der Zweck, für den die Tags erfunden worden sind. Ich sehe garkeinen anderen langfristig sinnvollen Weg als eine Relation für sowas. Vlt. mit type=road oder so. Da könnte man dann viele Sachen auf einmal erledigen. Nicht nur das Verknüpfen mit straßenbegleitenden Wegen, sondern auch das Verknüpfen mit area:highway=* oder Fahrspuren. Selbst die associatedStreet-Relationen könnten darin aufgehen. Kannst du ein konkretes Relationsmodell nennen, welches die von mir genannten Vorteile bietet? Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für straßenbegleitende Wege
Moin Michael! Am 01.01.2012 18:08, schrieb Michael Krämer: Es soll ja vermutlich um verbunden oder zugehörig gehen. Da wären accompanying oder associated vermutlich besser. Insgesamt sollten wir wohl am besten einen Muttersprachler zu Rate ziehen. Danke, du hast sicherlich recht. Google findet zu associated footway signifikant mehr Treffer als zu attendant footway. Ich wollte primär das Grundkonzept diskutieren und hatte die Tagnamen in der ersten Mail deshalb auch als Platzhalter bezeichnet. Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für straßenbegleitende Wege
Hallo Stephan, Am 30.12.2011 18:39, schrieb Stephan Wolff: in OSM werden immer Wege im Detail erfasst. Straßenbegleitende Rad- und Fußwege werden zu eigenen ways, zweigleisige Bahnstrecken zu zwei Einzellinien. Dies hat natürlich viele Vorteile, verursacht aber auch suboptimale Karten in kleinem bis mittlerem Zoomlevel oder unnötige Routinganweisungen. Ich habe mir Gedanken gemacht, wie man einige Nachteile vermeiden kann. Vermutlich wurden ähnliche Konzepte schon diskutiert, aber ich habe sie mangels geeigneter Stichworte nicht gefunden. Im Workshop Linienbündel [1] werden andere Ideen verglichen. Im folgenden steht das Wort Radweg für alle Radwege, Fußwege, kombinierten Fahrrad-/Fußwege und Reitwege. Die Tagnamen sind nur Platzhalter für bessere Namen. Die Iddee finde ich gut und eine echte Invoation zu den bisherigen Lösungen. Ich hatte schon vor langen mal vor einen Tagging-Vorschlag zu machen (statt highway=primary für eine spur sowass wie carryway=primary und carryway=cycleway). Mein Vorschlag hat aber viele Nachteil insbesondrere das bestehende Anwendungen nichts damit anfangen können. Straßen, für die ein straßenbegleitender Radweg als eigener way existiert, erhalten ein Zusatztag: attendant_cycleway_exists=yes Alternativ: attendant_ways=cyleway;pedestrian Straßenbegleitende Radwege erhalten ein Zusatztag attendant_cycleway=yes Alternativ: attendant=yes (Das es ein cycleway ist, ergibt sich ja schon). Getrennten Richtungsfahrbahnen einer Straße erhalten ein Zusatztag, das ihre Lage beschreibt. Bei einer grob in Ost-West-Richtung verlaufenden Straße wäre dies dual_carriageway=north (Nordfahrbahn in Fahrtrichtung West) und dual_carriageway=south , bei Nord-Süd-Strecken analog dual_carriageway=east|west. Bei Nordwest-Südost-Stecken hat der Mapper freie Wahl. Unschön finde ich an den Tagnamen a) das das Wort cycleway drinn vorkommt und es deshalb diverse Tags für das selbe gibt b) die Richtungsangaben, machen IMHO bei vielen Straßen Probleme, z.B. Serbentienen oder auch Wohnstraßen die im Kreis gehen etc. vielleicht reicht es aus ein Tag wie linienbuendel=-1 highway=cyleway linienbuendel=0 highway=primary oneway=true linienbuendel=1 highway=primary oneway=true linienbuendel=2 highway=cyleway einzutragen (für linienbündel muss man noch einen guten Vorschlag finden). Dabei sollte 0 möglichst in der Mitte sein, man kann dann abschätzen welche Wege vermutlich zusammen gehören. Routing bei Linienbündeln finde ich im übrigen ziemlich kompliziert. Beispiel; Ein Radwegrouting für eine Große Bundesstraße: 3+Y2+ A--AA A--AA +AA+++1++ +--+ +--+ +--X -=Straßenspur +=Radweg A=Ampel X,Y,1,2,3=Namen Das korrete Radwegrouting wenn die Straße so dick ist, das man sie normalerweise mit dem Rad nicht queren kann für X nach Y geht über 1,AA,2 bzw. AA,3(Schieben) wenn der Radweg 3 nicht in beide Richtungen freigegeben ist. Für zweigleisige Bahnstrecken werden dieselben Tags benutzt. Das Konzept kommt ohne zusätzliche Relationen aus und ist kompatibel zu den bislang vorhandenen Daten und Anwendungen. Vorteile: - Renderer können in kleinem Zoomlevel (z=12) bei Straßen mit Mittelstreifen nur eine Doppellinie statt zwei überlappender Fahrbahnen zeichnen. Bei beiden Vorschlägen gegeben, bei mir wird dann nur linienbündel=0 (Default) gerendert Zweigleisige Bahnstrecken können als dickere Linie dargestellt werden. Dein Vorschlag: Mir nicht ganz klar, wie man herausbekommt, das da 10 Bahnlinen nebeneinander laufen um die noch dicker zu malen. Mein Vorschlag: Wenn wir an die 0 raliway noch die Anzahl spuren dranpacken ja. - Renderer können in kleinem bis mittlerem Zoomlevel (z=15) straßenbegleitende Radwege unterdrücken und die Straße durch z.B. andere Randfarbe kennzeichnen. Ja. - Renderer können Einbahnstraßenpfeile bei Straßen mit Mittelstreifen vermeiden (bei vielen Stadtplänen üblich) Beide Vorschläge: Ist glaube ich mit einfacher Logik nicht so einfach heraus zu bekommen. Dafür müsste man die Wege doch in einer Relation packen. Das Problem ist ja: Der Hauptway ist oneway=true. Wie findest du den zweiten Weg mit oneway=true und bist dir 100% sicher, das er nicht zu einer anderen Straße gehört. vielleicht bräuchte man da noch ein Tag: linenbuendel_oneway=no (das kann ja default sein). - Renderer können Straßennamen und Ref-Nummern nur für eine Richtungsfahrbahn (z.B. north und west) zeichnen. Die Karte wird übersichtlicher. Ja - Router können leichter erkennen, das mehrere ways zur selben Straße gehören und Zielpunkte je nach Verkehrsmittel besser berechnen. Ja - Router können Anweisungen optimieren (Fahren sie auf den straßenbegleitenden Radweg.) Ja - für manche Auswertung/Statistik kann die Unterscheidung zwischen echten Einbahnstraßen und Richtungsfahrbahnen oder zwischen
Re: [Talk-de] Konzept für straßenbegleitende Wege
Hallo, für ein gutes Routing braucht es an einer Linie alle Informationen. Entweder direkt getaggt oder so getaggt, dass ein dummer Rechner diese Infos automatisch kombinieren kann. Räumliche Nähe sowie annähernde Parallelität als Band empfinde ich nicht als ein sinnvolles Band, da dies eher einem Raten entspricht. Es bleiben also nur unzählige Relationen (fände ich suboptimal, da sehr fehleranfällig) oder aber ein mehrfaches eintragen von den relevanten Informationen. Dazu bräuchte es an den straßenbegleitenden Wegen ein straßenbegleitend=yes und die üblichen Taggs für diesen Weg. An dem Hauptweg bräuchte es dann die Taggs wie cycleway:left/right=yes|no|oneway, cycleway:left/right:surface=... usw. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für straßenbegleitende Wege
Hallo! Ich will mich da gar nicht groß einmischen, schlage aber vor, die komplexesten Problemstellungen im Auge zu behalten! Z.B. auf der Wiener Ringstraße gibt es, ausgehend von einer Mittellinie der Straße: - im Schnitt zwei Fahrspuren - Straßenbahngleise - eine Alleereihe - einen Gehweg - einen Radweg - eine Alleereihe - eine Nebenfahrbahn - einen Gehsteig Einbahnen in beliebiger Richtung (entgegen der Richtung der Hauptfahrbahn), Radwege detto, außerdem Varianten wie Abbiegespuren, Haltestellen-Plattformen, Grünstreifen, etc. Und das auf der anderen Seite nochmal. Sprich es können da durchaus Dinge doppelt vorkommen, bedenkt das. Hilfreich wäre sicher auch ein Zahlenwert, wie weit das jeweilige Ding von der Mittellinie weg ist. - Sodass man wirklich einen Straßenquerschnitt modellieren kann. N.B.: anachb.at macht das so und kann damit auch routen... entsprechend komplex sind Kreuzungspunkte... /al ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für straßenbegleitende Wege
Hallo, Am Freitag, 30. Dezember 2011 18:39:38 schrieb Stephan Wolff: Moin, in OSM werden immer Wege im Detail erfasst. Straßenbegleitende Rad- und Fußwege werden zu eigenen ways, zweigleisige Bahnstrecken zu zwei Einzellinien. Dies hat natürlich viele Vorteile, verursacht aber auch suboptimale Karten in kleinem bis mittlerem Zoomlevel oder unnötige Routinganweisungen. Ich habe mir Gedanken gemacht, wie man einige Nachteile vermeiden kann. Vermutlich wurden ähnliche Konzepte schon diskutiert, aber ich habe sie mangels geeigneter Stichworte nicht gefunden. Im Workshop Linienbündel [1] werden andere Ideen verglichen. Für Dokumentation und Diskussion wird erst Zeit sein, wenn das Projekt beendet ist. (s.u.) Im folgenden steht das Wort Radweg für alle Radwege, Fußwege, kombinierten Fahrrad-/Fußwege und Reitwege. Die Tagnamen sind nur Platzhalter für bessere Namen. Straßen, für die ein straßenbegleitender Radweg als eigener way existiert, erhalten ein Zusatztag: attendant_cycleway_exists=yes Straßenbegleitende Radwege erhalten ein Zusatztag attendant_cycleway=yes sidepath:refname=irgendwas am Radweg sidepath:cycleway:left=irgendwas (aber genau das selbe) am Hauptweg (s.u.) [,,,] Das Konzept kommt ohne zusätzliche Relationen aus und ist kompatibel zu den bislang vorhandenen Daten und Anwendungen. Vorteile: - Renderer können in kleinem Zoomlevel (z=12) bei Straßen mit Mittelstreifen nur eine Doppellinie statt zwei überlappender Fahrbahnen zeichnen. Zweigleisige Bahnstrecken können als dickere Linie dargestellt werden. - Renderer können in kleinem bis mittlerem Zoomlevel (z=15) straßenbegleitende Radwege unterdrücken und die Straße durch z.B. andere Randfarbe kennzeichnen. - Renderer können Einbahnstraßenpfeile bei Straßen mit Mittelstreifen vermeiden (bei vielen Stadtplänen üblich) - Renderer können Straßennamen und Ref-Nummern nur für eine Richtungsfahrbahn (z.B. north und west) zeichnen. Die Karte wird übersichtlicher. [...] - für manche Auswertung/Statistik kann die Unterscheidung zwischen echten Einbahnstraßen und Richtungsfahrbahnen oder zwischen eigenständigen und straßenbegleitenden Radwegen nützlich sein. Nachteile: - ein weiterer Tag pro way muss eingegeben und gepflegt werden - manche ways müssen aufgespalten werden (z.B. wenn nur eine Teilstrecke einer Straße einen Radweg besitzt) Wurde ein solches Konzept schon diskutiert? In Lübeck habe ich zur Zeit einen Fahrradstadtplan in Zusammenarbeit mit dem ADFC in Arbeit, der als gedrucktes Exemplar im März auf den Markt kommen soll. Da habe ich noch größere Probleme, denn der ADFC möchte in 1:2 die straßenbegleitenden Radwege in 3 Qualitätsstufen lagegenau an der Hauptstraße haben (links gut, rechts schlecht etc. pp.). Gerade in Lübeck haben wir zur Zeit ein paar Mapper, die wie wild Rad- und Fußwege als eigene ways taggen, bauliche Trennungen hin oder her. (Wenn sich da bei Mapnik endlich mal was bewegen würde, wäre das ganze Problem wahrscheinlich nicht aufgetreten :-( ). Zur Zeit haben wir eine Absprache, dass ich die street-Relation benutze. Da werden alle Straßen, die begleitende Wege haben, mit sämtlichen Wegen erfasst. Um die entsprechenden Radwegetags auf den richtigen Straßenabschnitt verteilen zu können, reicht das aber noch nicht. Deshalb wird zur Zeit an dem Straßenabschnitt und am Radwegeabschnitt ein tag angebracht, dass einen beliebigen Kommentar enthält, innerhalb der betreffenden street-Relation aber eindeutig sein muss. Anhand dieses Kommentars fügt ein sql-script die Tags wieder an die richtigen Abschnitte des Hauptweges, denn nur so ist es mit machbarem Aufwand möglich, die Radwege zu zeichnen. Bei dem Maßstab verschwinden sie sonst unter der Straßendecke oder verdecken die Straße (20m = 1mm). So ganz optimal ist das System sicher auch nicht. Im Prinzip müsste man die Relationen erweitern, so dass zusätzlich zur Role ein oder mehrere Tags gesetzt werden könnten. Dann könnte man die entsprechenden Abschnitte über eine Relation lagerichtig zusammenführen. Im Moment bräuchte man für jeden Abschnitt eine eigene Relation, wenn man die Tags nicht direkt an die ways setzen wollte. Das ist in einer Innenstadt nicht handhabbar. Wäre es so oder ähnlich umsetzbar? Wir setzen es gerade um. Rechtfertigen die Vorteile den Zusatzaufwand? Ich sehe keine Alternative, außer dass man aus OSM-Daten eben nur 1:1 bis 1:10 zeichnen kann ;-) Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für straßenbegleitende Wege
Am 31.12.2011 13:06, schrieb Andreas Labres: Ich will mich da gar nicht groß einmischen, schlage aber vor, die komplexesten Problemstellungen im Auge zu behalten! dem stimme ich auch absolut zu: beim ersten Lesen schien mir die Idee auch etwas einfach gestrickt... Guten Rutsch nach 2012, Michael. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Konzept für straßenbegleitende Wege
Moin, in OSM werden immer Wege im Detail erfasst. Straßenbegleitende Rad- und Fußwege werden zu eigenen ways, zweigleisige Bahnstrecken zu zwei Einzellinien. Dies hat natürlich viele Vorteile, verursacht aber auch suboptimale Karten in kleinem bis mittlerem Zoomlevel oder unnötige Routinganweisungen. Ich habe mir Gedanken gemacht, wie man einige Nachteile vermeiden kann. Vermutlich wurden ähnliche Konzepte schon diskutiert, aber ich habe sie mangels geeigneter Stichworte nicht gefunden. Im Workshop Linienbündel [1] werden andere Ideen verglichen. Im folgenden steht das Wort Radweg für alle Radwege, Fußwege, kombinierten Fahrrad-/Fußwege und Reitwege. Die Tagnamen sind nur Platzhalter für bessere Namen. Straßen, für die ein straßenbegleitender Radweg als eigener way existiert, erhalten ein Zusatztag: attendant_cycleway_exists=yes Straßenbegleitende Radwege erhalten ein Zusatztag attendant_cycleway=yes Getrennten Richtungsfahrbahnen einer Straße erhalten ein Zusatztag, das ihre Lage beschreibt. Bei einer grob in Ost-West-Richtung verlaufenden Straße wäre dies dual_carriageway=north (Nordfahrbahn in Fahrtrichtung West) und dual_carriageway=south , bei Nord-Süd-Strecken analog dual_carriageway=east|west. Bei Nordwest-Südost-Stecken hat der Mapper freie Wahl. Für zweigleisige Bahnstrecken werden dieselben Tags benutzt. Das Konzept kommt ohne zusätzliche Relationen aus und ist kompatibel zu den bislang vorhandenen Daten und Anwendungen. Vorteile: - Renderer können in kleinem Zoomlevel (z=12) bei Straßen mit Mittelstreifen nur eine Doppellinie statt zwei überlappender Fahrbahnen zeichnen. Zweigleisige Bahnstrecken können als dickere Linie dargestellt werden. - Renderer können in kleinem bis mittlerem Zoomlevel (z=15) straßenbegleitende Radwege unterdrücken und die Straße durch z.B. andere Randfarbe kennzeichnen. - Renderer können Einbahnstraßenpfeile bei Straßen mit Mittelstreifen vermeiden (bei vielen Stadtplänen üblich) - Renderer können Straßennamen und Ref-Nummern nur für eine Richtungsfahrbahn (z.B. north und west) zeichnen. Die Karte wird übersichtlicher. - Router können leichter erkennen, das mehrere ways zur selben Straße gehören und Zielpunkte je nach Verkehrsmittel besser berechnen. - Router können Anweisungen optimieren (Fahren sie auf den straßenbegleitenden Radweg.) - für manche Auswertung/Statistik kann die Unterscheidung zwischen echten Einbahnstraßen und Richtungsfahrbahnen oder zwischen eigenständigen und straßenbegleitenden Radwegen nützlich sein. Nachteile: - ein weiterer Tag pro way muss eingegeben und gepflegt werden - manche ways müssen aufgespalten werden (z.B. wenn nur eine Teilstrecke einer Straße einen Radweg besitzt) Wurde ein solches Konzept schon diskutiert? Wäre es so oder ähnlich umsetzbar? Rechtfertigen die Vorteile den Zusatzaufwand? Viele Grüße Stephan [1] http://wiki.osm.org/wiki/WikiProject_Germany/Workshops/Linienb%C3%BCndel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
