[Talk-de] Status Fahrradwege-Tags

[Markus]

Hallo Frederik,

> Eigentlich ist es eher nach Art von OSM, zu taggen, was "da ist"

Das finde ich einen guten Grundsatz.

Trotzdem erlebe ich seit Jahren die immer wieder gleichen Diskussionen 
mit m.E. nicht wirklich befriedigenden Ergebnissen. Ich vermute die 
Ursache in unklaren Zielen und einer folglich mangelnden Systematik.

Vielleicht ist inzwischen die Zeit reif, da genauer hinzuschauen?

Ziel unserer ganzen Datensammlerei ist ja, damit coole Anwendungen zu 
ermöglichen. Im Wesentlichen sind das Karten und Router, plus hin und 
wieder Spezialkarten und Statistiken.
Der Anwender will wissen, wie es irgendwo "aussieht", und ober einen Weg 
"benutzen" kann. Je genauer man diese Fragen ausdrücken kann, desto 
klarer werden die Anforderungen an die Datenerfassung.

_Weg_
Bezüglich Wege macht es einen Unterschied, welches Transportmittel zur 
Verfügung steht, und welche Fertigkeiten ich mitbringe. Entsprechend 
müssten die Daten darüber Auskunft geben, ob ich mit gegebenem 
Transportmittel und Fertigkeiten den Weg nutzen kann, bzw welche 
Transportmittel und Fertigkeiten erforderlich sind.

Beispiel: Es ist ein Unterschied, ob ich einen 40-Tonner, ein Motorrad 
oder einen Kinderwagen benutze. Beim Motorrad macht es einen 
Unterschied, ob ich eine Harley oder eine Enduro habe, und ob ich mit 
einer Enduro umgehen kann oder sie nur auf Asphalt benutze.
Selbst als "Fussgänger" macht es einen Unterschied, ob ich "Oma mit 
Gehhilfe" bin oder "Wanderer" oder "erfahrener Kletterer".

Und es macht einen Unterschied, ob man "darf" oder "kann".
*Dürfen* ist verordnet (access).
*Können* ergibt sich aus der Kombination von Oberfläche, 
Oberflächenzustand, Steigung, Tragfähigkeit, Wetterbedingung, etc.
plus meinen Fertigkeiten.

Probleme mit den Attributen ergeben sich m.E. immer dann, wenn 
unterschiedliche Klassen in einem Schlüssel vermengt werden.
(z.B. "technisch möglich" mit "gesetzlich erlaubt", oder 
"Oberflächenmaterial" mit "Holprigkeit", oder
"Wartungszuständigkeit" mit "Verbindungscharakter", etc).

Solche Vermengungen erzeugen immer

> irgendwelche Schwammkategorien

_Schlüssel_
Schlüssel sollten m.E. immer möglichst eindeutig sein und immer 
möglichst nur eine Klasse beschreiben.

_Werte_
Werte sollten m.E. immer möglichst objektiv unterscheidbare 
Eigenschaften beschreiben. Diese können messbar sein (Meter, Tonnen, 
Grad, etc), oder definierte Stufen (1=mit PKW befahrbar, 2=mit Traktor 
befahrbar):

> Art und Groesse der Kiesel- oder Schottersteine,
> Frequenz und Groesse der Schlagloecher usw. in Zahlen

In der Kombination müssten die Attribute so sein, dass

> jeder sich dann darauf seinen persoenlichen Reim machen kann.

Bzw eben genau für seine Frage eine erfüllende Antwort findet.
Und dafür muss erst die *Frage bekannt* sein.

Hier haben wir ein Problem zu bewältigen, an dem OSM schon immer 
Schwierigkeiten hat: jeder Datensammler geht von seinen eigenen Fragen 
aus, erfindet dafür "tags" und sammelt dazu Werte, aber kommuniziert die 
Frage nicht ;-)
Und so entsteht ein unnötig wirres System mit vielen Missverständnissen 
und sich immer wiederholenden Diskussionen.

> mit "smoothness" zum Gespoett der internationalen OSMer gemacht

Der Ansatz von "smoothness" ist m.E. ein sinnvoller.
Daraus lässt sich Benutzbarkeit ableiten.

Zum Gespött wird man nur, wenn man nicht erklärt wozu der Schlüssel gut 
ist und wenn man einen wirren Wertekatalog benutzt.
Aber das können wir ja ändern :-)

> "smoothness" eine Neuauflage des "tracktype"

In "tracktype" werden verschiedene Klassen verwurschtelt.
"smoothness" erfasst die "Holprigkeit" (unabhängig vom Material).

> Ein kleines bisschen sind wir da also auch Wegbereiter

:-)

> Ich denke, wir tun dem Projekt insgesamt keinen Gefallen, wenn wir
> staendig neue Sachen erfinden, die alle "irgendwie so aehnlich" sind,

Ja, an vielen Stellen schaffen wir bisher ein "mehr desselben".
Besser wären durchdachtere (neue) Konzepte (z.B. klare Klassentrennung, 
eindeutige Schlüssel, definierte Wertekataloge).

> Wir haben tracktype, wir haben surface, nun noch smoothness

Das sind m.E. alles Entwickungen in die richtige Richtung.
Wir müssen nur noch *eindeutigere Beschreibungen* erstellen, die auch 
für Neue *verständlich und nachvollziehbar* sind.

> irgendwelche Eignungstags

Solche führen m.E. in eine ungünstige Richtung.
Die Eignung sollte m.E. aus den objektiven Werten Werten abgeleitet 
werden. Das macht dann die Anwendung bzw der Anwender.

> Kann man das einem neuen Mapper halbwegs verstaendlich machen

Das ist eine entscheidende Voraussetzung.
Hilfreich sind anschauliche Beispiele, und unterstützende Editoren.

Dabei ist es m.E. eher unerheblich, ob beispielsweise "snoothness" mit 
1..7 oder mit "verygood".."verybad" bezeichnet ist, solange es für jede 
Stufe eine für jedermann nachvollziehbare (Bild)-Beschreibung gibt.

Das Schöne an unserer Community ist ja dass wir durch vielfältige 
Erfahrungen ein optimales Ergebnis kombinieren können.
Voraussetzung dafür ist m.E., dass wir unsere verschiedenen Ziele 
deklarieren und kommunizieren - damit wir gegenseitig gemeinsam 
verstehen, was wozu gut ist - und transparent herausfinden können, wie 
wir es noch sinnvoll verbessern können.

Gruss, Markus