[Talk-de] Routerhärtetest

Heiko Jacobs heiko.jacobs at gmx.de
Mo Jun 22 21:52:03 UTC 2009


Moin

 > Und vielleicht sollten wir die Diskussion nach ka-geo oder PM verlagern,
 > damit wir den Rest auf talk-de nicht mir unserer Lokaldiskussion nervsägen.

Die Diskussion hat eher prinzipiellen Charakter genommen und nur eine eher
kleine lokale Komponente.

> Bevor wir uns in unwesentlichen Details verlieren, sollten wir vielleicht 
> wieder zurück zum ursprünglichen Problem kommen. Kannst Du in ein paar dürren 
> Worten beschreiben, was jetzt in Deinem Augen besser als vorher ist?

Unten mal als Fullquote die Vor- und Nachteile beider Modelle zum
Nachschlagen ...

Von den Mängeln separater Wege trafen hier zu:
1. Zusammenhang Fahrbahn/Radweg geht verloren, dieser gehört nun mal zum
    "straßenbegleitenden Radweg". Würden nach deutschem Recht Radweg und
    Fahrbahn unterschiedliche Ziele oder Eigenschaften (Vorfahrtslage) haben,
    entfiele die Eigenschaft "strßanbegleitend" und damit die
    Benutzungspflicht.
    Ich hatte in einem anderen Beitrag schon gemailt, dass ORS sich da
    durchaus schon mal irrt und Fahrbahn und Radweg verwexelt. Kann jetzt
    nicht mehr passieren
2. Entscheidend ist das bei derzeitiger Rendertechnik vor allem beim Rendern
    (Überlagerung von Radweg und Fahrbahn in dne allermeisten Zoomleveln)

3. trifft nicht zu
4. ist schon bei 1. verwurstelt
5. ist hier nicht relevant

Von den Mängeln gemeinsamer Wege:
1. traf hier nicht zu
2. ist hier theoretisch gegeben, hat aber bei einer Einrichtungsfahrbahn
    eines 2-ways-highway keine praktische Relevanz für Router und Renderer
    (Mittellinie verschwindet meist ab 16), s.a. anderer Beitrag dazu
3. hat hier auch keine Relevanz, weil alle möglichen Fahrtbeziehungen
    erfasst sind

wegen 4. habe ich diesen thread gestartet.

Kurzum: Die potentiellen Vorteile des Modells getrennter Wege wurden hier
nicht genutzt, die Vorteile des gemeinsamen Weges (rechtl. Zusammenhang 
Fahrbahn/Radweg bei straßenbegleitenden Radwegen abgebildet, besseres
Rendering bei den Renderern, die das schon können) treffen zu.
Abwägung daher zugunsten der Vorteile gemeinsamer wege.

Heiko Jacobs schrieb:
 > Martin Koppenhoefer schrieb:
 >> Am 19. Juni 2009 14:08 schrieb Sven Geggus <lists at fuchsschwanzdomain.de>:
 >>> *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
 > Talk-de at openstreetmap.org
 > http://lists.openstreetmap.org/listinfo/talk-de





Mehr Informationen über die Mailingliste Talk-de