Am 02.03.2011 19:35, schrieb Andreas Perstinger:
On 2011-03-02 18:27, Christian Müller wrote:
Am 02.03.2011 18:16, schrieb Simon Poole:
Ein "trekking bike" ist in etwa so Englisch wie ein "handy".
Beim Handy gibt es wenigstens eine richtige Übersetzung (mobile phone).
Und nochmals: es ist nicht sinnvoll die Eignung für bestimmte
Fahrzeugtypen zu taggen, wenn die Fahrzeugtypen selber nicht halbwegs
klar definiert sind (wir taggen ja auch nicht typische residentials in
Bergdörfern mit lambo=no oder subaru=yes).
bitte dann den korrekten namespace verwenden
motorcar:lambo=yes
motorcar:subaru=no
;-)
Dann mach halt einen besseren Vorschlag..
Ich denke, das Grundproblem bei Deinem Vorschlag ist, dass Du das
Problem der unzureichenden bzw. lückenhaften Kennzeichnung der
Tauglickeit von Wegen mit Fahrradtypen lösen willst, deren Einteilung
genauso subjektiv ist, wie smoothness oder tracktype. Dadurch wird mMn
die Situation nicht klarer.
Eben doch. Natürlich bleibt die Subjektivität, aber mit der
Klassenbildung trage ich das (subjektive) Urteil, ob ein Weg benutzbar
ist, oder nicht, an die konkreten Nutzer heran. Das habe ich auch schon
in anderen mails geschrieben. Das ist ein feiner, wesentlicher
Unterschied zu smoothness, wo jeder kommen kann, und einem Wegnutzer
(Rennradler, Trekker, MTBler) vorsetzen kann, wofür er den Weg als
geeignet erachtet. Und das _ohne_ dass derjenige, der die Daten nutzt,
eine Vorstellung davon hat, wie derjenige der smoothness=* erfasst hat,
den Weg benutzt hat.
Wozu erfassen wir (hauptsächlich) den Oberflächenzustand -> um dem
Datennutzer eine Entscheidungshilfe zu seiner geplanten Nutzung dieses
Weges zu geben. /Wer/, wenn nicht ähnliche Nutzer, kann dem Datennutzer
am besten/ehesten mitteilen, ob der Weg für ihn brauchbar ist?
smoothness=* ist einfach nicht das gleiche. Der Ansatz der Erfassung
für einen Fahrradtyp kommuniziert einem Nutzer gleichen Fahrradtyps
wesentlich mehr, als typ-unspezifische tags, weil er i.d.R. davon
ausgehen kann/darf, dass sich die gleiche Zielgruppe mit der Erfassung
solcher tags beschäftigt. Zieht dazu bitte einfach die Parallele zu den
Mountainbikern - die handhaben das schon so.
Ein Fußgänger wird kaum für einen MTB-Profi Daten erfassen, weil er
_nicht weiß_ inwiefern die Strecke für MTB geeignet ist. Also gibt es
den mtb: namespace. Warum dort aufhören und alle anderen Fahrradtypen
in einen Topf werfen? Ich finde bei der Erfassung von smoothness ist es
fast weniger die Subjektivität, die eine Rolle spielt, als vielmehr
noch, dass der Anwender nicht darauf vertrauen kann, dass die
Einschätzung des Datenerfassers /für sein Anwendungsgebiet/ eine
richtige ist.
Das ist, mit der Gewißheit, dass der Erfassende zur gleichen
Radlerkategorie wie man selbst gehört, immer noch nicht gegeben, aber
die Einschätzung wird _wesentlich_ qualifiziert sein, als eine fachfremde.
Es geht mir nicht darum, smoothness zu ersetzen oder zu verbessern - das
schrieb ich von Anfang an. Mein Ansatz hat mit smoothness=* eigentlich
überhaupt nichts zu tun. Dass einige dass hier so zu einem Brei
vermengen, mag daran liegen, dass viele aus dem Oberflächenzustand
direkt die Nutzbarkeit für ihren Radtyp ableiten. Das ist nicht falsch,
aber mit meinem Vorschlag geht es mir ganz konkret darum, die
Verwendbarkeit von Daten dadurch zu erhöhen, dass die Fachleute/Mapper
eines Radtyps auf genau die Datennutzer desselben Radtyps treffen.
Wenn es um Verwendbarkeit geht, und Verwendbarkeit eine subjektive Sache
ist, dann können wir Präzision nur auf die Art und Weise erreichen, dass
die Erfasser von Daten der gleichen/ähnlichen Gruppe entspringen, wie
die Nutzer der Daten. Dazu müssen die Tags aber kommunizieren, /wer/
erfasst hat, bzw. /wer/ adressiert wird. Das tut smoothness nicht.
Es gibt auch nicht "die" Programmiersprache, sondern viele
anwendungsspezifische (DSL) - nicht, weil man keine generelle Sprache
hat, die DSL überflüssig machen können, sondern weil DSL dem Problem
kurz, bündig und adequat begegnen können. Von der Anwendersicht lässt
sich generalisieren, wenn die Kriterien messbar sind und objektiviert
werden können, smoothness ist hier bereits ein Grenzfall.
Smoothness versucht die Quadratur des Kreises, indem /jeder/ kommen kann
und eine passende Verwendbarkeit für /spezifische/ Anwender erfasst.
Das funktioniert einfach nicht. Der Kommunikationskanal ist hier
gebrochen - smoothness=* ist, kommunikationstechnisch betrachtet ein
Broadcast ohne Absenderadresse. Bei der ganzen konservativen Denke,
frage ich mich, wie es die MTBler geschafft haben, eine ganze Reihe von
Änderungen beizusteuern. Vermutlich haben die ohne viel fuzz gleich
Tatsachen geschaffen :)
Gruß,
Christian
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
