[Talk-de] Routerhärtetest

[Heiko Jacobs]

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