[Talk-de] Wie erreichen wir einheitliche Tagdefinitionen?

[Jochen Topf]

On Sat, Oct 30, 2010 at 10:49:31PM +0200, Stephan Wolff wrote:
> Am 30.10.2010 09:45, schrieb Jochen Topf:
>
>> Das ist keine Anarchie. Das ist ein bei OSM seit Jahren bewährtes Verfahren. Es
>> wirkt manchmal frustrierend, gerade auf Neueinsteiger. Aber es funktioniert.
>> Langfristig setzt sich so nämlich die Mehrheit der an einem Thema
>> interessierten durch. Wenn man meint, dass eine bestimmte Sichtweise richtig
>> ist, dann muss man das nicht in einem speziellen (selbsternannten) Gremium
>> durchsetzen. Stattdessen muss man die Leute überzeugen, die die eigentliche
>> Arbeit machen. Das ist am Anfang bei einer neuen Idee schwierig, wird aber mit
>> jedem weitern Mapper einfacher und irgendwann kippt die generelle Meinung und
>> die Meisten sind zufrieden mit dem neuen Tag oder einer neuen Sichtweise.
>
> Dieses Verfahren funktioniert recht gut, wenn man neue Tags einführt um
> bislang nicht erfasste Objekte oder Eigenschaften zu beschreiben.
> Das Verfahren funktioniert nicht, wenn man etablierte Tags vor einer
> Umdeutung schützen will (z.B. Verwendung von "natural=beach" für
> Sandbunker auf dem Golfplatz) oder mehrere inkompatible Definitionen
> hat, die sich in den Daten nicht unterscheiden lassen (z.B. width-Tag
> für Straßen).

Also das mit dem Sandbunker auf dem Golfplatz, der als natural=beach getagged ist,
lassen wir mal weg. Das ist kein echtes Problem. Die paar Stellen, wo es das auf
der Welt gibt, sind ein Witz. Beim width-Tag für Straßen sehe ich das Problem
schon eher.

In beiden Fällen ist es aber so: Warum genau ist das denn ein Problem? Ist es
in der Praxis ein Problem? Will jemand die Anzahl der Sandkörner auf allen
Stränden dieser Welt berechnen und stören ihn dabei die Sandbunker? Und die
Straßenbreite? Gibt es jemand, der Routing für Schwerlast-Transporte macht,
wo das eine Rolle spielt? Vielleicht tue ich da jemandem Unrecht, aber ich
habe bisher keine Anwendunge gesehen, die diese Daten auch nutzen. Und solange
die keiner nutzt, ist es eben nicht ganz klar, was es bedeutet.

Letztlich ist jede Definition eines Tags, die sich *nicht* auf eine Nutzung
stützt, völlig beliebig. Und vorallem auch immer wieder verfeinerbar. Selbst
wenn wir die Straßenbreite genau definieren, z.B. als den Innenabstand zwischen
den weißen Linien am Straßenrand, dann haben wir nur eine Teildefinition, weil
es auch Straßen gibt, die keine weißen Linien am Rand haben.

Die perfekten Definitionen, die immer wieder gefordert werden, existieren doch
in der Wirklichkeit nicht. Daher gibt es die Diskussionen, weil jeder das mit
gleichem Recht anders sehen kann. Erst wenn eine Nutzung der Daten dazukommt,
machen die Definitionen auch Sinn. Das ist ein anderer Ansatz hier. Wir
definieren nicht nach theoretischen ontologischen Gesichtspunkten, sondern nach
der Nutzung.

Ich fände es sogar sinnvoll, da noch viel weiter zu gehen. Also z.B. einen Tag
zu haben, der sagt: "Dies ist die Straßenbreite nach Par. 386 der StVo". Und
jemand anderes hat die "Straßenbreite zwischen den weißen Linien" und jemand
anderes "Breite des geteerten Bereiches" oder was auch immer. Bei der Nutzung
kann man sich dann aussuchen, was man nimmt. Und da wo nur das eine oder andere
Tag ist, kann man schaun, was man nimmt.

Die Verschiedenheit, die der Grund für die Diskussion ist, einfach
totzuschlagen, das kann es doch nicht sein.

Es gibt durchaus Fälle, wo es auf die Verschiedenheit nicht ankommt. Z.B. ist
es grad egal, ob es oneway=yes oder oneway=true heißt. Der Informationsgehalt
ist der gleiche. Früher mal, gab es beide Versionen sehr häufig. Inzwischen hat
sich die Meinung durchgesetzt, dass "yes" die bessere Variante ist. Daher ist
das nun hauptsächlich so dokumentiert (im Wiki steht: 'oneway=yes (discouraged
alternative: "true", "1")' und es gibt wohl auch Bots, die das umsetzen.

> Das Problem frustriert nicht nur Neueinsteiger sondern auch viele aktive
> Mapper und Anwender.
>
>> Wenn man ein spezielles Gremium hat, dann gibt es zwei mögliche Folgen:
>> Entweder hat es nicht die Macht, etwas durchzusetzen. Dann wird es ignoriert.
>> Oder es hat diese Macht, dann werden sich alle Mapper, die der Meinung des
>> Gremiums nicht zustimmen, von OSM abwenden.
>
> Angenommen, das Gremium hätte die Macht, den ersten Absatz des Wikis
> aller in den Map_Features genannten Tags zu setzen und gegen Änderungen
> Dritter zu schützen.
> Falls das Gremium nach Abwägung der Vor- und Nachteile definiert "width  
> beschreibt bei Straßen die Breite der Fahrbahn", würden sich dann die  
> Befürworter einer anderen Definition von OSM abwenden? Ich vermute, dass
> die Motivation der meisten Mapper durch eine eindeutige Definition
> steigen würde.

Das verschiebt das Problem doch nur. Nehmen wir an, das Gremium hat Unsinn
beschlossen, z.B. weil da Leute aus bestimmten Ländern drinsitzen, die die
Gepflogenheiten in anderen Ländern nicht kennen und daher im besten Glauben
das richtige zu tun, etwas beschlossen haben, was nicht überall funktioniert.
Oder weil da keine Leute drinsitzen, die programmieren können, und sie daher
ein Tag so definiert haben, dass es programmtechnisch nicht sinnvoll ausgewertet
werden kann.

Entweder müssen jetzt alle mit dieser Definition leben (weil ja nur das
offizielle Gremium das auch wieder ändern kann) oder man wird im zweiten Satz
des Wikis schreiben: "Das da oben bitte ignorieren, weil wir das in der Praxis
inzwischen anders handhaben, weil es sich als Unsinn herausgestellt hat." Wäre
das nicht noch verwirrender?

Wenn das ein paarmal passiert, geben die Leute irgendwann auf, auf das Gremium
zu hören. Oder, wenn es zu viele Leute gibt, die sklavisch dem Gremium
nachlaufen, dann verlassen halt die Leute das Projekt, die sich damit nicht
abfinden wollen.

Wenn ich wirklich davon ausgehen kann, dass das Gremium bessere Entscheidungen
trifft als sich durch unsere sogenannte Anarchie herausbilden, dann wäre ich
sofort für so ein Gremium. Aber das bezweifle ich doch sehr. Wo nehmen die ihre
Kompetenz her? Warum wissen die besser, welche Definiton der Straßenbreite so
wichtig ist, dass sie das "width"-Tag bekommt während die andere sich mit
"width_defined_by_stvo_1234" begnügen muss?

>> OSM verwendet schon das richtige Verfahren. Sonst wäre das Projekt nicht so
>> weit gekommen. Ein Problem haben damit vor allem die Leute, die versuchen, die
>> Welt, die nunmal sehr komplex ist, in ein simples Schema zu pressen.
>
> Es gibt sicherlich komplexe Objekte, die nicht einfach in OSM korrekt  
> abzubilden sind. Aber wir scheitern schon an einfachen Dingen. Eine
> Tankstelle für Autos und eine für Boote kann in der Realität jedes Kind
> unterscheiden. Aus den OSM-Daten kann man den Unterschied oft nicht
> erkennen.

Auch hier liegt das Problem wieder an dem ontologischen Ansatz. Wenn man sich
überlegt, dass eine Tankstelle für Boote in erster Linie eigentlich eine
Tankstelle ist, dann verwendet man das gleiche Tag.

Wenn man sich beim Taggen aber gleich sagt: "Ok, ich will hier eine
Bootstankstelle taggen. Dafür gibts noch keinen Tag. Welchen nehme ich jetzt?
Soll ich den normalen Tankstellentag nehmen? Hm, vielleicht nicht so gut, weil
der ist bisher nur definiert für Auto-Tankstellen. Vielleicht hat da schon
jemand eine Karte aller Tankstellen gemacht oder eine Routing-Software kann die
nächste Tankstelle finden. Das könnte zu Verwirrungen führen.  Also nehme ich
da mal einen neuen Tag für." Dann wäre das Problem keines gewesen.

Das ist also wieder die Argumentation von der Nutzung her. Mir hat das am
Anfang auch Probleme bereitet, aber ich hab mich da umstimmen lassen. Das beste
Beispiel, wo das so gelaufen ist, sind im Bau befindliche Straßen. Wenn man
das schematisch "richtig" machen wollte, hätte man die "highway=residential,
construction=yes" taggen müssen oder sowas. Aber dann wären sie in jeder Software,
die das "construction"-Tag nicht beachtet, als fertige Straßen erschienen. Also
hat man "highway=construction, construction=residential" genommen. Das it zwar
irgendwie ziemlich eklig, funktioniert aber in der Praxis sehr gut, weil die
allermeisten Leute, die sich für Straßen interessieren, nur die fertigen Straßen
interessiert. Die Leute, die die im Bau befindlichen Straßen auswerten wollen,
haben dadurch aber etwas mehr Arbeit.

Anfangs gab es beide Arten des Taggings parallel, aber es hat sich mit der Zeit
die Version mit highway=construction durchgesetzt. Weil sie in der Praxis besser
funktioniert. Ganz ohne Gremium.

Und es ist auch für den Gelegenheitsnutzer irgendwie logischer. Wenn ich an
"Tankstelle" denke, dann stelle ich mir keine Boots-Tankstelle vor. Und das
wird auch für die Mehrheit so gelten. Manchmal ist die einfachste Lösung die
beste. Frag mal Deine Oma, was eine Tankstelle ist. Sie wird wahrscheinlich was
sagen wie "Da kann man mit dem Auto hinfahren und Benzin tanken". (Nur besser
keinen Teenager fragen. Für den ist ne "Tanke" was, wo man sich zu jeder Tages-
und Nachtzeit Alkohol besorgen kann. :-)

>> Es ist ein gewisser Druck da, sich zu einigen, weil sonst die
>> Daten nicht nützlich sind.Andersherum heißt das auch, dass es eigentlich keine
>> Rolle spielt, wenn man sich nicht einigt, solange keiner die Daten nutzt. Die
>> Endlos-Diskussionen entstehen eigentlich meistens an irgendwelchen
>> Nebenkriegsschauplätzen, wo keiner die Daten wirklich nutzt.
>
> Ich habe einen anderen Eindruck. Bei den meisten Diskussionen geht es  
> nicht um akademische Unterschiede oder Spitzfindigkeiten, sondern um
> die Abgrenzung häufig verwendeter Tags. Am Ende der Diskussionen gab
> es sehr häufig keine Einigung.
> Viele Daten können nicht sinnvoll ausgewertet werden, wenn mehr als
> 10% der Mapper eine von der Mehrheit abweichende Definition nutzen.

Kannst Du mir Beispiele nennen? Welche Tags sind das, die häufig verwendet
werden und wo die Definition so unklar ist, dass eine wichtige Anwendungen
nicht funktioniert?

>> Letztlich wird es aber immer darauf hinauslaufen, dass sich jemand die Mühe
>> macht, Entscheidungen und Nicht-Entscheidungen im Wiki zu dokumentieren.
>
> Ich glaube nicht, dass man damit eine Legitimation schaffen kann. Was  
> sagt es aus, wenn drei Diskussionsteilnehmer einen Vorschlag
> unterstützen und ein Teilnehmer vehement dagegen ist?

Das sagt genau das aus. Es gab eine Diskussion. Das sind die Punkte, die
vorgebracht wurden. Einigen Leuten gefiel das, anderen das. Dann kann sich der
nächste eine Meinung bilden und dann das machen, was er für richtig hält. Das
Problem sind nicht die verschiedenen Meinungen. Das Problem ist die fehlende
Dokumentation von Fakten und Meinungen.

Was den von mir beschriebenen Prozess der Entscheidungsfindung und Bildung
eines Community Consens vorran bringt, ist die Dokumentation jedes Schrittes
und darauf aufbauend der nächste Schritt. Wenn ich mir gerade selbst überlege,
welcher Tag für irgendwas Sinn machen könnte und ich habe keinerlei Vorwissen
oder so, dann denke ich mir irgendwas aus. Aber wenn ich sehe, da gab es schon
Diskussionen, dann kann ich dieses "Vorwissen" mit in meine Entscheidung
einbringen. Vielleicht sehe ich dadurch, dass eine Variante, die ich überlegt
hatte, in anderen Ländern nicht funktionieren würde oder so. Dann kann ich die
schonmal rausnehmen.

>>  Ich habe z.B. mit Taginfo versucht,
>> ein System zu schaffen, wo man besser *sehen* kann, was wer so mit Tags macht.
>
> Das Tool ist zweifellos nützlich und technisch gut aufgebaut. Es hilft
> zu Erkennen, wozu ein Tag nützlich sein kann. Es hilft aber nicht zu
> Erkennen, wofür ein Tag nicht verwendet werden sollte.
> Ich sehe nicht, welches Problembeispiel aus meinem ersten Beitrag man
> mit Taginfo oder einem vergleichbaren Tool lösen könnte.

Es hilft zu sehen, was schon verwendet wurde. Wenn ich sehe, dass da schon
100.000 Tankstellen mit amenity=fuel getagged sind, dann sollte ich vielleicht
davon ausgehen, dass es nicht so sinnvoll ist, diesen Tag umzudefinieren als
"kann auch eine Tankstelle für Space Shuttles sein".

Aber Du hast natürlich recht, dass das Taginfo viele Fragen (noch) nicht
beantworten kann. Eine Sache, woran ich arbeite, ist noch mehr Datenquellen
einzubinden. Konkret sind das demnächst erstmal die Editoren (JOSM muss
ausgebaut werden, Potlatch und Merkaartor sind in Arbeit). Aber auch die
Datennutzer sollen da mit rein. Wenn ich sehen kann, dass in der XYZ-Karte das
ABC-Tag verwendet wird, sagt mir das ja auch was. Ich weiss allerdings noch
nicht so richtig, wie ich die vielen vielen Karten und sonstige Nutzungen von
OSM da alle reinbringen kann, aber das gehört mal in einen anderen Thread.

Jochen
-- 
Jochen Topf  jochen at remote.org  http://www.remote.org/jochen/  +49-721-388298