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 joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de