[Talk-de] Wie kann man besseres Autorouting fuer Fahrradfaher erreichen. Ideen und Konstruktive Vorschlaege

[Felix Hartmann]

On 03.05.2010 20:33, Torsten Leistikow wrote:
> Felix Hartmann schrieb am 03.05.2010 14:14:
>    
>> Die einzige Loesung ist daher ein subjektives Tag eizufuehren pro
>> Verkehrsmedium.
>>      
> Ich denke, dass Problem bei dem Ansatz ist, dass man nicht EIN subjektives Tag
> pro Medium benutzen kann, da jeder Mapper eine andere Subjektive Meinung haben
> wird. In EINEM Tag kann aber jeweils nur die Meinung des letzten Mappers erfasst
> werden.
>
> Statt also eine einzelne Bewertung zu erfassen, muesste man zaehlen, wie viele
> Mapper die Benutzung einer Strasse befuerworten bzw. davon abraten:
>
> Mapper-A meint class.bicycle=2
> Mapper-B meint class.bicycle=1
> Mapper-C meint class.bicycle=3
> Mapper-D meint class.bicycle=-1
>
> Das ergibt in Summe class.bicycle=1.25
>
> (Das gleiche Schema ist natuerlich auch auf die spezialisierten Tags
> class.bicycle.mtb usw. anwendbar.)
>
> Einem deartigen Ansatz wuerde ich schon zutrauen, dass er ueber die Zeit das
> OSM-Routing (fuers Fahrrad oder auch allgemein) drastisch verbessern wuerde.
> Allerdings kann ich momentan keinen Vorschlag aus dem Aermel schuetteln, wie man
> das am Besten per OSM-Tagging erfassen koennte.
>
> Gruss
> Torsten
>    
Das Problem ist mehr, dass wir uns ueber Probleme die noch lange nicht 
auftauchen den Kopf zerbrechen. Sollte dies wirklich einmal so sein, 
dass edit wars um class:bicycle losgehen, kann man noch immer reagieren. 
Ich denke jedoch es ist so wie bei tracktype. Auch hier herscht kein 
Konsens, aber das vorhandensein der Daten die in 90% der Faelle passen, 
ist der Grund warum Autorouting in OSM ueberhaupt die kommerziellen 
Daten schlaegt. Es ist egal ob darum gestritten wird ob etwas 1.5 oder 2 
ist, wenn man es mit 0 vergleicht. Je mehr Information vorhanden ist, 
desto mehr Crosschecks kann man fahren, welche die Datenqualitaet wieder 
erhoehen.

Ausserdem ist der Respekt an vorhandenen Daten in OSM recht groß. Wenn 
Mapper-b mein class=bicycle=2, aber -1 ist eingetragen. Dann benutzt er 
halt class:bicycle:commute=2. Wir brauchen hier vielleicht 5-6 Keys in 
denen sich 99% der Fahrradfahrer zuordnen koennen. Es werden aber kaum 
mehr als 2 bis vielleicht ganz ab und zu 3 Keys gesetzt werden. Denn im 
Gelaende haben wir zwei Gruppen. Technische Mountainbiker und 
Crosscountry. Die Feindifferenzierung uebernimmt mtb:scale. Hier braucht 
es eigentlich nur einen Key, der aussagt, der Weg ist schwer und 
interessant, oder schwer aber nicht interessant, Die Cross-Country Riege 
ueberschneidet sich mit den Trekking und Tourenfahrer. Jene wiederrum 
sind am kompliziertesten. Die Rennradfahrer dagegen haben recht 
aehnliche Ansichten wie die "Commuter" - also Biker die pro Tag 10-40km 
pro Weg zur Arbeit fahren. Der Wochenendradler dagegen, interessiert 
sich meisten eh nicht mehr wenn primary oder secondary dasteht, also 
braucht man hier fuer ihn auch keinen extra Tag.

Die einzige valide Frage die ich mir also Stelle. Wollen wir 5-6 
seperate Keys die jeder fuer sich Haupteigenschaften zusammenfassen. 
(etwa Verkehr der behindert/stoert (wobei hier Fußgaenger auf Wegen 
genauso zaehlen wie Autofahrer auf Straßen), Landschaft, Schnelles 
vorankommen (vor allem in Staedten), fuer den Wochenendfahrer gefuehlte 
Sicherheit (wobei dies meist denen wichtig ist, die sowieso kaum Rad 
fahren), Anspruch und Variabilitaet fuer Mountainbiker, und das 
allerwichtigste ein Key der dann beschreibt was ein Cycleway genauer ist 
- also ein Weg in der Landschaft, ein Weg 2m neben der Straße (immer 
interessant in Kombination mit Geschwindigkeit), und dann noch 
Rechtliche Probleme - also attraktive Straße mit daneben herlaufendem 
unattraktiven Radweg der aber Benuetzungspflichtig ist). Oder lassen wir 
dies, und nehmen stattdessen einfach Fahrradfahrertypen - was fuer die 
User deutlich einfacher ist. Denn man braucht sich keine komplizierten 
Tags merken, sondern benutzt halt die 1-2 Anforderungsprofile die man 
meist hat. Ausserdem ist es leichter verwertbar. Der Nachteil ist, dass 
es eventuell Situationen gibt, wo das Profil einfach wiederspruechlich 
ist, diese Situationen sind aber sicherlich die Ausnahmen - in etwa so 
wie die leidige Diskussion zu Fahrspuren mit Gras in der Mitte, die 
einige statt objektiv zu taggen, unbedingt auf einen tracktype mappen 
moechten (hier hat uebrigens niemand gemeckert, dass man die Information 
ganz weglaesst, es ging nur drum wie man es stattdessen beschreibt).

Mein Vorschlag waer hier, wer fuer Eigenschaften ist, sollte bitte ein 
Konzept ausarbeiten wie dies aussieht. Dann schauen wir ob eher dass 
Konezpt der Eigenschaften oder die Klassen sinnvoll sind, und wie schwer 
es fuer den Mapper umzusetzen ist. (In JOSM kommt es erfahrungsgemaeß 
erst als Preset rein, wenn wir mal 20-30.000 Wege so klassifiziert 
haben, und die Vorteile deutlich werden). Daraufhin entscheiden wir 
entweder per Vote, oder danach welches der beiden Konezpte die 
Kartenersteller als umsetzbar sehen und dies auch sofort tun. (denn ohne 
Nutzen wird es nicht eingetragen). Meiner Meinung nach sind Profile 
leichter umsetzbar fuer beide, Mapper und Renderer - aber ich lasse mich 
gerne ueberzeugen dass wie bestimmte Eigenschaften stattdessen taggen.
> _______________________________________________
> Talk-de mailing list
> Talk-de at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de
>