[Talk-de] Status Fahrradwege-Tags

Christian Müller cmue81 at gmx.de
Mi Mär 2 20:26:53 UTC 2011


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





Mehr Informationen über die Mailingliste Talk-de