[Talk-de] Status Fahrradwege-Tags

Mi Mär 2 01:13:52 UTC 2011

Hallo,

kurz zu mir selbst.  Ich lese ab und an die Diskussionen auf dieser
Liste mit und versuche gute Vorschläge bei meiner Arbeit an OSM
umzusetzen.  Ich tagge seit 2008 im Südraum Leipzig und lege mehr Wert
auf Qualität (so wie die Masse, schätze ich), als schnell die DB zu
stopfen.  Über das Tagging zu Radrouten und -wegen wurde auf dieser
Liste schon viel diskutiert.  Ich will daher kurz mein Anliegen einordnen.

Es geht mir um das Taggen von Fahrradwegen (nicht Radroutenrelationen
o.ä.).  Ich habe mir oft gedacht, dass das bisherige tagging der Radwege
nicht nur schlecht, sondern für vielerlei Zwecke auch völlig
unzureichend ist - wobei das nicht heißt, dass ich es aus Mangel an
besseren Ideen nicht selbst verwendet habe.  Also es geht um Radwege und
ihre Nutzbarkeit für unterschiedliche Arten von Radlern.

Momentan gibt es genau zwei etablierte Tags, die einen mit _Radwegen_
arbeitenden Radfahrer interessieren und weniger etablierte:

- mtb: (mountainbike namespace, healthy and alive)
- smoothness (hat sich nie so richtig durchgesetzt, weil Einschätzung
größtenteils subjektiv)

Lasst mich weiterhin festhalten, wofür genau die tags momentan verwendet
werden:

  bicycle=*
  1) im Wiki:  klar als Zugangsbeschränkung (beschilderter Radweg,
offizielle Nutzungsart, usw.)
  2) in-the-wild:  jeder Weg, der als "für Radfahrer geeignet" erscheint
bekommt bicycle=yes verpasst

  surface=*
  ) beschreibt objektiv die Oberflächenbeschaffenheit
  ) nicht aber den Zustand!!

  smoothness=*
  ) hilft mir nicht zu entscheiden, ob ich z.B. mit trekking bike dort
fahren kann, weil
    a) die subjektive Ansicht des Taggenden im Wert steckt und
    b) ich die Entscheidungsbasis des Taggenden nicht kenne (ein Inliner
wird strenger
        sein, als z.B. ein Radfahrer, etc.)

Was will ich also ändern, was sind meine Ideen?

  Ziele:
  a) sowohl Mensch als auch Maschine (routing services)
     sollen in der Lage sein, eine für Radfahrer geeignete
     Route aus den Daten abzuleiten
  b) der Taggende soll objektiv entscheiden und nach
     Möglichkeit mit wenigen Werten arbeiten können, um
     a) zu erreichen

  (praktischer) Ansatz:  (Idee während des Radelns :) )
  1) es gibt im wesentlichen 3 Kategorien von Radfahrern,
       welche i.d.R. ihre Präferenzen nach den unterschiedlichen
       Wegoberflächen/-beschaffenheiten richten (wichtig!)
  2) "Monotonie":  MTB < Trekking < RaceBike
      ein MTB kann auch auf ausgewiesenen trekking und
      race Strecken fahren, umgekehrt geht dies i.d.R. nicht,
      bzw. ist nicht erwünscht (ich kenne niemanden, der
      sein Rennrad auf unpassenden trails schrottet)

  konkreter Tagging-Vorschlag:
  *) bicycle:mtb=(alle mgl. Zugangsbeschränkungen)
  *) bicycle:trek=(alle mgl. Zugangsbeschränkungen)
  *) bicycle:race=(alle mgl. Zugangsbeschränkungen)
  *) bicycle=(alle mgl. Zugangsbeschränkungen)

  Implikationen:
  _) bicycle:race impliziert, sofern für die anderen Tags nichts angegeben,
     bicycle:trek
     bicycle:mtb
     bicycle
    mit demselben Wert
  _) bicycle:trek impliziert, sofern für die anderen Tags nichts angegeben,
     bicycle:mtb
     bicycle
    mit demselben Wert
  _) bicycle:mtb impliziert keine weiteren bicycle Tags

  _) bicycle impliziert, sofern für die anderen Tags nichts angegeben,
     bicycle:trek
     bicycle:mtb
    mit demselben Wert

Wobei letzteres die Rückwärtskompatibilität zu bestehendem Tagging
gewährleistet.
Beispiele

*) ich habe einen sandigen Fußweg, der auch von MTBlern benutzt wird:
  bicycle=no
  bicycle:mtb=yes
  foot=yes
  highway=path
  surface=sand

*) ich habe einen fein geschotterten Waldweg:
  bicycle=yes
  bicycle:trek=yes   (:mtb wird impliziert, :trek eigentlich auch, ist
aber für Menschen da, um zu sehen, dass man sich hier nach dem
erweiterten Schema Gedanken gemacht hat - man könnte auch nur :trek
verwenden, dass bricht dann aber die Kompatibilität)
  foot=yes
  highway=track
  surface=fine_gravel

*) eine asphaltierte Straße, die für Rennräder geeignet ist
  bicycle=yes
  bicycle:race=yes   (:mtb, :trek werden impliziert, können aber
angegeben werden, z.B. auch wenn es für unterschiedliche Radtypen
unterschiedliche Zugangsbeschränkungen gibt)
  foot=yes
  highway=secondary
  surface=asphalt

*) eine (alte) asphaltierte Straße, die nicht für Rennräder geeignet ist
  bicycle=yes
  bicycle:race=no
  foot=yes
  highway=secondary
  surface=asphalt

*) eine (alte) asphaltierte Straße, die so kaputt ist, dass man sie
selbst mit Trekking-Rädern meiden sollte/nicht mehr befahren kann
  bicycle=yes
  bicycle:trek=no
  bicycle:race=no
  foot=yes
  highway=unclassified
  surface=asphalt

*) eine (alte) asphaltierte Straße (Alternative, semantisch äquivalent)
  bicycle=no
  bicycle:mtb=yes
  foot=yes
  highway=secondary
  surface=asphalt

Was sind die Vorteile einer Adaption dieses Schemas, dieser Erweiterung?

  - Zugangsaussagen pro Fahrradtyp
  - Wiederverwendung etablierter Werte (eW) für die neuen Tags
(bicycle:[mtb|trek|race=eW)
  - leichtere, objektivere Ableitung der Werte für den Mapper (vgl.
smoothness)
  - präziseres Routing möglich
  - Karten ließen sich für den jew. Fahrradtyp erstellen
  - ideellerweise taggen die Radfahrer Wege, die den jew. Radtyp auch nutzen
    (Rennradler nutzen also bicycle:race, Trekker bicycle:trek, etc.)
  - eine Aussage zum Oberflächen_zustand_ eines Weges lässt sich dann grazil
    aus der Verbindung von bicycle*=* und surface=* ableiten  (das wäre
zumindest
    objektiver als eine subjektive Schlaglochbewertung)

  - und final, was ich persönlich ideal fände, aber noch nicht gecoded
habe (tm):
  - Mgl. Routing-Service, der für Radfahrer eine Strecke berechnet (gibt
es schon) und dann
     auf zwei Verteilungsbalken die statistische Verteilung von

              bicycle:race=[all yes's] | bicycle:trek=[all yes's] |
bicycle:mtb=[all yes's]
     und   surface_value1 | surface_value2 | ... | surface_valueN

     angibt.  Die beiden Verteilungsbalken sollen dann auf den Werten
angeklickt werden können,
     um z.B. den Anteil des Wertetyps an der Gesamtstrecke zu erhöhen. 
Der Routing-Algorithmus
     rechnet also immer wiederholt, mit dem Zwang (constraint), den
zuletzt gewählten Wert an-
     teilig zu vergrößern.  In der Praxis kann die Strecke dadurch
länger werden, aber das ist dem
     Radfahrer unter Umständen lieber, als (für ihn) schlechte Strecken
zu fahren.
   - Beispiel

        Routingalgorithmus findet mit der Vorgabe Trekking-Bike eine Route,
        die Verteilungen sehen so aus:

                    b:race=72% | b:trek=24% | b:mtb=4%

                    asphalt=69% | concrete=3% | paving_stones=8% |
ground=8% | gravel=8% | sand=3% | grass=1%

        Klickt der Nutzer auf eine Prozentzahl, versucht der Algorithmus
den Streckenanteil
        dieses Typs zu erhöhen oder zu verringern (je nach Wunsch).

Danke schonmal für eure Lesemühen, ich bin gespannt, was ihr davon
haltet? ..
Ich bitte um Verzeihung, falls sich diese Gedanken mit einer bereits im
Gange befindlichen Diskussion überschneiden.

Viele Grüße und
gute Nacht,

Christian
(aka cmuelle8, cm8, ..)

--
Falls Sie irgendwann durch oder mit diesem "geistigen Eigentum" in die
Gewinnzone schlittern sollten, bedenken Sie bitte, mich oder andere
Kinder, insofern diese Ökonomie sie uns gönnt, vor dem Verhungern zu
bewahren.  Vielen Dank.