Martin Koppenhoefer schrieb: > Am 19. Juni 2009 14:08 schrieb Sven Geggus <[email protected]>: >> *argh* warum sind an der Rheinbrücke die Fahrradwege entfernt? Die sind >> baulich getrennt und sollten daher IMO definitiv separat eingetragen werden.
> ja, einfach grauenhaft. Allerdings steht im Wiki ausdrücklich, dass > cycleway=track für _baulich_ getrennte Radwege zu verwenden sei. Genau. Beide mapping-Varianten sind derzeit erlaubt. > Ich habe mir vor ein paar Tagen die Freiheit herausgenommen, dort > wenigstens einen Hinweis zur Alternative (getrennter Radweg) > anzubringen, aber noch besser würde ich die Abschaffung von > cycleway=track finden, bzw. einen Hinweis, dass es sich dabei um eine > Interimslösung handelt, bis alle solchen Wege separat gemappt sind. Das halte ich für sehr verfrüht. BEIDE Modelle haben teilweise gravierende Nachteile, die noch SEHR FERN einer befriedigenden Lösung sind, daher ist derzeit keines der beiden Modelle aufgebbar und durch das andere ersetzbar, sondern man muss gut abwägen, welches der beiden man wo nimmt. Separate ways haben als Mangel: 1. Weder Renderer, noch Router haben derzeit die Möglichkeit, die Zusammenhänge verschiedener paralleler Wege zu erkennen. Beim Rendern führt das zu nicht vermeidbaren Überlagerungen, bei Routern zu falschem Routen, es wird u.U. die Fahrbahn genommen statt der Radweg (was nun wiederum offenbar schon einige Mapper veranlasste, Fahrbahnen mit bicycle=no zu taggen, was aber von der Theorie her einfach falsch ist. Die Diskussion darüber hier liegt paar Wochen zurück...) Gut, das Problem ließe sich mit Relationen zumindestens im Datenmodell relativ flott erledigen. Aber: 2. ALLE derzeitigen Renderer sind nicht mal im entferntesten dazu in der Lage, dieses Problem irgendwann in den Griff zu kriegen und daraus eine vernünftige Darstellung zu erzeugen ohne Überlappungen. Einfacher Grund: Keiner der Renderer fasst die Geometrie der Objekte lesend oder gar schreibend/modifizierend an. Das wäre aber notwendig, um Überlappungen a) festzustellen (Abstandsberechnungen, Parallelität, ...) und b) als Konsequenz aus einer festgestellten Überlappung einen oder beide Wege zu verschieben (kartographischer Fachausdruck dafür: Verdrängung) mitsamt des Problems nur teilweiser Verdrängung und Anpassung der Übergänge (man stelle sich einen mäandrierenden Fluss neben gerader Straße vor: Nur da, wo der Fluss der Straße zu nahe kommt, muss er verschoben werden) und der Entscheidung, was verdrängt was und was bleibt (vermutlich über Relationen steuerbar) Womöglich sind die Berechnungen so komplex (selbst wenn man ihr mit Relationen auf die Sprünge hilft), dass man veränderte Geometrien vorab berechnen muss mitsamt Zwischenablage und von Mechanismen, Ursprungsgeometrie und abgeleitete Geometrie zeitnah aneinander anzupassen. 3. Schon das Mappen solcher komplexen Wegenetze überfordert manche Mapper, man sieht es an diversen Kreuzungen, wo sehr viel Phantasie in die Verknüpfung der Wege gesteckt wird, vor allem, wenn verschiedene Modelle aufeinander treffen. (Geh- oder Radweg in Hauptstraße separat gemappt, in Querstraße nicht: wie verbandelt man nun alles korrekt?) 4. Ein darauf aufbauendes Routing wird abenteuerlich, wenn man nicht sehr aufpasst mit den Verknüpfungen aller Wege. Und die Routinganweisungen werden auch abenteuerlich durch mehrfaches Abbiegen, was real aber nicht da ist, sondern nur den Verknüpfungen des Datenmodells und seiner Üergänge geschuldet ist. Und was zählt als Abbiegen (davon hatten wir es auch schon vor einiger Zeit...) Angehängte Tags haben diese Probleme nicht: der logische Zusammenhang der zusammen gehörenden Infrastruktur ist stets auf einfachste Weise da. Renderer rendern es zunehmend akzeptabel und ohne Überlappungen (Osmarender, Opencyclemap schon halb (lane), bald ganz (track), Mapnik hat dieselbe Technik, sollte es also auch irgendwann können). Router, die überhaupt in der Lage sind, radrelevante Tags auszuwerten, sollten es auch einfacher haben so. Das Mappen ist einfacher, übersichtlicher, keine komplexen Kreuzungsgeflechte... Angehängte Wege haben als Mangel: 1. Es gibt noch kein allgemein akzeptiertes Tagging-Modell, um Eigenschaften anzuhängen, die nur für einen Teil des ways gelten, nämlich für den Hautp-highway ODER einen der angehängten cycleways ODER footways, womöglich auch noch zu allem Unglück links und rechts unterschiedlich. Es entsteht ein undurchschaubares Kraut- und Rüben-Tagging, wenn man mal so die diversen Vorschläge liest mit Kaskaden von Doppelpunkten etc. ... 2. Ungelöst ist auch das verwandte Problem der nur einseitigen Wege oder links- und rechtsseitig unterschiedlichen Wege (rechts track, links lane oder nix, rechts gemeinsamer Weg, links getrennter Geh-/Radweg, ...) und das nicht nur beim Taggen, sondern auch vorrangig beim Rendern, denn wie oben bei den separaten ways erfordert es entweder a) ein Verschieben von Geometrien ider b) ein Warten auf einen neuen SVG-Standard, der nicht nur in Wegrichtung Strichlieren erlaubt (dasharray) sondenr auch quer zum Weg Muster oder dezentriertes Zeichnen zulässt. Steht für den neuen SVG-Standard zur Diskussion, las ich vor paar Monaten in den Drafts, aber wie da der aktuelle Stand ist und wenn positiv, wann man in OSM darauf bauen könnte... 3. Komplexe lokale geometrische Strukturen können nicht abgebildet werden. Wege irgendeiner Art, die seitlich anschließen, kannman nicht danach unterscheiden, ob sie nur bis zum Geh-/Radweg gehen oder ganz bis zur Fahrbahn (wichtig für's Routing). Eventuelle Einschränkungen von Fahrbeziehungen gehen verloren 4. ganz einfach gestrickte Router könnten Probleme haben (daher ja die Frage ganz am Anfang des threads, wie die dort genannten Router prinzipiell arbeiten und am konkreten Beispiel) Wenn ich da aus einer zurückliegenden Diskussion an die Garmin-Karten denke, bei denen nur eine beschränkte Auswahl an Linienelementen verfügbar ist und, zumindestens damals, nur ein sehr beschränkt leistungsfähiger Auswahlmechanismus für die tags existierte (was sich aber wohl verbessert haben soll), dann könnte es gut sein, dass eine allumfassende Karte für das Routing mit allen Verkehrsarten schwierig ist. Eventuell muss man dann verschiedene Datensätze supporten, einen für Autos, dem bei der Umwandlung cycleway-, bicycle- und motorroad-tags egal sind, einen für Fahrräder, dem genau das wichtig ist, aber die Unterscheidung motorway/trunk völlig nebensächlich, einen für Lkws, der alle residentials, services, ... zur Klasse "meiden" zusammenfasst, Feldwege ganz weglässt, dafür mautpflichtige und nichtmautpflichtige Straßen unterscheidet und auf maxheight und maxweight achtet etc. Separate Wege können dagegen über unterschiedliche Seiten und Eigenshaften und Verknüpfngen nur müde lächeln: alles kein Problem. Und für jeden Routingwunsch der passende Weg da (wobei die Zusammenhänge fehlen, womit sich der Kreis schließt...) > Gerade bei baulich getrennten Wegen ist man sich ja grundsätzlich > einig, dass sie getrennt gemappt werden, und daher ist track > eigentlich Quatsch und widerspricht dem allgemeinen Datenmodell. 5. fällt mir gerade noch ein: wohin gehören dann lanes? Baulich gehören sie zur Fahrbahn, sie sind ja auf dieser. Rechtlich gehören richtige Radstreifen (breiter, durchgezogene Linie) aber meiner Erinnerung nach NICHT zur Fahrbahn, Angebotsstreifen (schmaler, gestrichelte Linie) aber sehr wohl. Insgesamt wird das ganze nochviel komplexer, wenn man an schon existierende Sachen wie (Straßen)bahnen in der Mitte oder auf der Fahrbahn (oder an der Seite), Anliegerfahrbahnen etc. denkt und an die schon gelesenen Vorschläge mit Erfassung von Park- und Grünstreifen und eines Tages dann noch der Graben neben der Straße, die Böschung samt Winkel und Höhe, Zahl der Spuren mit deren Funktion (siehe anderer thread), Baumallee, ... > Das Löschen von detaillierten Informationen zugunsten gröberer > parametrisierter Modelle ist sicher ein (respektloser) Graus. Wie geagt habenbeide Modelle schwerwiegende Nachteile. Deswegen muss man abwägen, wann man welches Modell anwendet. In diesem Falle ... ... hatten Radwege und Fahrbahn keine speziellen tags, die nur für eins gelten (wenn mal jemand lanes dranhängt, wird wohl jede Software davon ausgehen, dass damit nicht der cycleway gemeint ist...) Und es sind auch keine wichtigen tags absehbar, die in naher Zukunft nötig wären. surface=paved oder surface=asphalt gilt hier für alle. ... hängt der Radweg ziemlich nahe an der Fahrbahn. Stellenweise klebt der Radweg wirklich direkt am Bordstein der Fahrbahn, stellenweise nur durch einen schmalen Grünstreifen abgetrennt, stellenweise immerhin mit einer Leitplanke abgetrennt. Nur an einer Stelle kommen paar Meter zusammen (kurz vor Knielingen auf der Südseite) ... teilt sich der Radweg wegen dieser Eigenschaft "straßenbegleitender Radweg" mit der Hauptfahrbahn die Eigenschaft "oneway". Straßenbegleitende Radwege müssen für die Freigabe in Gegenrichtung explizit freigegeben sein. Das sind sie aber nicht. Wer genau drauf achtet, wird feststellen, dass die Wegweisung auf die andere Rheinseite sauber auf die richtige Seite führt. Das nur nebenbei, weil man oneway ja auch an separate ways hängen kann. Und weil sich in der Praxis kaum ein Radler dran hält... ... gibt es trotz dieser teilweise Trennungen keine Probleme mit unterschiedlichen Fahrtbeziehungen bei von quer kommenden Wegen, die für Router relevant wären, da es wegen der baulichen Trennung in der Mitte egal ist, ob eine Leitplanke von der Fahrbahn trennt oder nicht: man kann eh nicht "links abbiegen". ... sind es also typische straßenbegleitende Radwege ohne Besonderheiten (außer der, das sowas neben trunks eher selten vorkommt, es sei denn bei großen Flussbrücken, da sogar eher häufiger und womöglich sogar an Autobahnen) ... gilt das auf längerer Strecke (Rheinbrücke inklusive bis Abfahrt Knielingen. Auf einem kürzeren Abschnitt hätte sich die Umstellung nicht gelohnt.) weswegen ich auch den einen vergleichsweise kurzen Abschnitt mit größerer Distanz "mitgenommen" habe. ... ist die so getaggt besser sichtbare Eigenschaft "straßenbegleitender Radweg" = über eine längere Strecke hautnaher Kontakt zu SEHR VIEL Verkehr eigentlich sogar eine wertvolle Zusatzinfo. Ein potentieller Tourenradler, der Karlsruhe und seine Rheinbrücke nicht kennt, wird so vielleicht eher stutzig und fragt sich dann womöglich, ob er sich das antun will oder ob er nicht lieber einen anderen Weg zur Rheinbrücke als den kürzesten (und ausgeschilderten) nimmt. Bei einem separat getaggten way hat man im Übrigen eher die Erwartung, etwas vorzufinden, das typischer für außerörtliche Radwege an Landstraßen ist: nämlich eine Trennung von Fahrbahn und Radweg durch Gebüsch oder eine Baumreihe. Das gibt's hier nicht. Hier werden nur taube Feinstaubfetischisten wirklich glücklich... ... sieht das Rendering bei den Renderern, die das schon unterstützen (oder bald werden) deutlich besser aus, während die separaten Wege deutlich schneller verdeckt (und damit völlig unsichtbar) waren oder die Straße erschlugen (cyclemap) Kurzum: kein Nachteil des Anhänge-Modells greift hier wirklich, aber die Nachteile des Separat-Modells greifen. Es geht keine Information verloren, weil bisher keine zusätzlichen Infos da waren, die nur an einen der ways gehörten, und auch keine von extremer Wichtigkeit absehbar sind. Im Gegenteil ist nun die vorher nicht so deutlich erkennbare Eigenschaft "straßenbegleitender Radweg" deutlicher gemacht worden. Deswegen liegt hier die Entscheidung zugunsten des Anhänge-Modells nahe. An anderen Stellen fiel meine Entshceidung auch schon anders aus. Je nachdem, welche Vorteile überwiegen. Radfähige Router sollten eigentlich mit beiden Arten zurecht kommen. Ein cycleway=... zu ignorieren, wäre ziemlich daneben. Es hängt ja bspw. auch die Einbahnstraßenfreigabe da dran... Das ORS erstmal drüber stolperte und Umwege routete, lag ja an der seltenen Kombination mit highway=trunk und der falschen Priorisierung des trunks über den cycleway. Aber zum Aufdecken solcher Probleme sind ja Rheinbrücken da ;-) Nur so können die Router verbessert werden. Und um die Möglichkeiten und Probleme weiterer Router ging es ja am Anfang dieses threads. Also ran ans Testen!!! ;-) Gruß Heiko "Mueck" Jacobs _______________________________________________ Talk-de mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-de
