[Talk-de] OSM (noch) ziemlich Fahrradunfreundlich

[qbert biker]

Hallo,

erstmal danke für diese sehr präzise Darstellung der Probleme, im Prinzip sind
wir uns relativ einig, denk ich mal.

Die Vereinfachung in meiner Darstellung sollte nichts verharmlosen, sondern 
eben zeigen, dass mit den vielen ways wenig oder nichts gewonnen wird.

-------- Original-Nachricht --------
> Datum: Thu, 21 Aug 2008 21:07:11 +0200
> Von: Daniel Maliga <osm at maliga.de>
> An: Openstreetmap allgemeines in Deutsch <talk-de at openstreetmap.org>
> Betreff: Re: [Talk-de] OSM (noch) ziemlich Fahrradunfreundlich

> Hallo,
> 
> qbert biker schrieb:
> > Die typischen Radwege direkt an der Straße oder die die nur über 
> > den typischen Minigrünstreifen getrennt sind aber absolut parallel zur
> > Straße verlaufen, lassen sich über ein Attribut besser beschreiben. 
> 
> Theoretisch ist es es angemessen, straßenbegleitende Radwege als Tags
> der Straße zu realisieren. Praktisch mangelt es an passenden Tags für
> die in Deutschland möglichen und vor allem auch in der Praxis
> vorkommenden Möglichkeiten:
> 
> - Schutzstreifen
> - Radfahrstreifen
> - freigegebener Fußweg
> - nicht benutzungspflichtiger Radweg mit Gehweg daneben
> - benutzungspflichtiger Radweg mit Gehweg daneben
> - benutzungspflichtiger gemeinsamer Rad-/Fußweg

Modelltechnisch lässt sich alles, was parallel zu einer Straße verläuft, sauber
attributieren. Die Nodes bilden den zentralen Polygonzug und dann wird der 
Rest aufgebaut. Sinnvollerweise trennt man dabei zwischen physischen und
administrativen Argumenten. 

Also von der Mitte aus gesehen gibts dann eben eine Fahrbahn mit ein paar
Metern Breite an die sich dann vielleicht ein Grünstreifen anschliesst und dann der
Fahradweg und dann der Fußgängerbereich. Solange das alles (näherungsweise)
Parallelen zum zentralen Polygonzug sind, reicht es die Breite anzugeben, um alles 
eindeutig geometrisch zu definieren. Oder eben als Default über praxisnahe 
Ersatzwerte.

> Die letzten beiden können dann auch noch linksseitig vorkommen, so dass
> sie in beide Richtungen zu befahren sind. In der Praxis kommen dann auch
> noch Konstrukte vor, die eigentlich nicht vorgesehen und deshalb auch
> hier nicht aufgezählt sind.

Die dann zu betrachten sind, wenn sie auftreten ;). Mit 'es könnte ja doch noch was
ganz anderes kommen' schwebt man immer in der Gefahr, sich das Modell so
komplett zu versauen, dass man gar nix zustande bekommt. Aber Links != rechts ist
eine Sache die wirklich konkret ist und in OSM schon lange ungelöst vor sich 
hindämmert...

> Dazu kommt noch die Frage, auf welcher Seite der Straße ein getaggter
> Radweg ist (abhängig von der Richtung des Ways, "cycleway=opposite"-
> Konstrukte?), und was man macht, wenn auf beiden Seiten der Straße
> Radverkehrsanlagen vorhanden sind, die ja auch nicht gleichartig sein
> müssen.

Ein gutes Modell bezieht sich auf den Normallfall und stellt Regeln für die
Ausnahme zur Verfügung. Der Normalfall ist eher die symmetrische Straße.
Das mit 'opposite' wurde AFAIK nötig, weil OSM sehr richtungsbezogen 
arbeitet. Wenn ein Way in eine Richung eingestellt ist, hängen u.U. viele 
andere Attribute dran (Einbahnstraße, etc.). Alles nicht unbedingt schön, aber
das System ist in dieser Hinsicht schon etwas eingafahren. 
 
> Meiner Ansicht nach kann man das alles mit den gegenwärtig definierten
> Tags nicht ausreichend und eindeutig ausdrücken. Insbesondere die Frage
> der Benutzungspflicht ist überhaupt nicht behandelt, aber für eine
> brauchbare Routing-Software immens wichtig.

Primär muss eine brauchbare Routing-SW einen Weg erstmal finden, um
ihn einbeziehen zu können. In diesem Sinne führen die vielen unverbundenen
Ways erstmal nicht zum Ziel. Zum andern sollte vermieden werden, dass 
der Graph als Basis des Routings unnötig total zerfleddert wird. 

Ich will an den Router die Anfrage stellen können, dass er mir vorwiegend
Straßen raussucht, auf denen in meiner Fahrtrichtung Fahhradwege 
vorhanden sind und das geht über die Attributsschiene bestens. Die 
Benutzungspflicht ist ein einfach nochmal ein ergänzendes Attribut, das aber
nur Sinn macht, wenn dem Router klar ist, dass die Strasse überhaupt 
einen Fahhradweg hat. Bei einem unabhängigen Way weiss der Router 
nix von der Straße, die sich als Alternative darstellt.  

> Straßenbegleitende Radwege oder gar Radfahrstreifen/Schutzstreifen als
> eigene Ways zu mappen, ist in meinen Augen eine ganz schlechte Lösung,
> da die Beziehung zwischen Straße und dazugehörigem Radweg verloren geht.

Exakt...

> Man müsste außerdem an jeder Einmündung die entsprechenden Kreuzungen
> zwischen den Ways schaffen, was eine große Fehlerquelle darstellt. Ich
> hatte neulich hier schon ein Beispiel, wo genau das vom Mapper vergessen
> wurde.

In den von mir beobachteten Fällen: Eher der Standard denn die Ausnahme :(

> Als Konsequenz daraus berücksichtige ich momentan straßenbegleitende
> Radwege überhaupt nicht. Die wesentliche Information, dass man die
> Straße an sich als Radfahrer benutzen kann und darf, ist ja vorhanden
> (bei Z.254 setze ich natürlich "bicycle=no").
> 
> Ich würd mich gern dransetzen, eine Lösung für dieses Problem zu
> entwickeln, bräuchte aber Hilfe, da ich nicht weiß, wie ich verfahren
> muss, damit ich mir nicht umsonst den Kopf zerbreche. Also
> Vorgehensweise bzgl. Proposal etc., sowie einen Einblick, was im
> Datenmodell möglich und erwünscht ist...

*seufz* wenn es denn ein Datenmodell geben würde. Ich bin jetzt 1 1/2 Jahre
gegen Betonmauern gelaufen und halte mich deshalb hinsichtlich eines
sauber durchdefinierten Datenmodells zurück. Ich hab die SW zusammen 
um mit dem Router zu spielen und bin zu allen Schandtaten bereit, Aber die
Hoffnung, dass man sich bei OSM darauf einigt, dass ein präzises 
dokumentiertes Datenmodell Vorteile bringt, habe ich leider aufgegeben.

Grüsse Hubert.

PS. ich machs mir nicht zu einfach, eher im Gegenteil ;)
-- 
GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry Passion!
http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/6169196