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
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
