[Talk-de] Wie erreichen wir einheitliche Tagdefinitionen?

[Peter Wendorff]

Am 04.11.2010 03:16, schrieb Stephan Wolff:
> Moin,
>
> ich hatte in den letzten Tagen sehr wenig Zeit und antworte daher erst
> so spät.
>
> Am 31.10.2010 09:19, schrieb Jochen Topf:
>> On Sat, Oct 30, 2010 at 10:49:31PM +0200, Stephan Wolff wrote:
>>> 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.
>
> Ja, das kein wirklich bedeutendes Problem. Solange das Tag nur zum
> Erstellen von Karten benutzt wird, ist es irrelevant. Falls jemand
> eine Anwendung mit OSM-Daten erstellen will, die den Weg zum nächsten
> Strand ermittelt, wird er merken, dass in einigen Gegenden die
> Routen zum Golfplatz führen. Leider gibt es in OSM viele solcher
> kleiner Probleme.
>
>> Beim width-Tag für Straßen sehe ich das Problem
>> schon eher.
>
>>  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.
>
> M. E. muss erst eine sinnvolle Definition erfolgen, bevor man die
> Daten danach erfassen und am Ende gemäß der Definition auswerten kann.
> Man kann nicht eine Anwendung schreiben und die Mapper aufzufordern,
> für diese Anwendung width als Fahrbahnbreite einzugeben.
Ich denke, eine Kombination aus beidem wäre vielleicht sinnvoll:
Wir können uns als Mapper ausdenken, was wir erfassen wollen und wie wir 
es erfassen wollen.
Wir können uns dabei auch überlegen, welche Anwendungen wir damit 
unterstützen, und wo es Probleme gibt.
Je nachdem, was man dabei betrachtet, kommen unterschiedliche Aspekte 
zum Tragen und sind unterschiedliche Konzepte besser oder schlechter 
geeignet.

Vielleicht fehlt uns eine Art "Anwendungsmatrix" im Wiki.
Das ist jetzt kein fein durchdachtes Konzept, sondern eine relativ 
schnell niedergeschriebene Gedankenskizze:
Soweit ich weiß, gibt es kein "formales" Statement, dass und wie ein 
Key/Tag/Proposal/Schema von einer oder mehreren Anwendungen genutzt wird.

Die in den letzten Wochen vorgestellten Tools gehen teilweise in die 
Richtung, aber eben noch nicht mit einem systematischen Ansatz: Wenn ich 
das richtig verstanden habe, werden quasi ausgewählte Anwendungen mehr 
oder weniger manuell ausgewertet und in diese Systeme eingepflegt.

Ein Statement per Wiki-Template á la "Key wird auf Mapnik gerendert 
als...", "Key wird unterstützt von XY's Garmin-Maps", "Weg wird in 
Routenplaner Z berücksichtigt" wäre vielleicht ganz sinnvoll.

Wie gesagt: das ist eine kurze Idee, noch nicht mehrfach durchdacht etc.
> Sobald die Bedeutung von width klar ist, könnte man enge Straßen in
> der Karte schmaler zeichnen. Osmarender wertet width für Flüsse aus.
> Solange nicht klar ist, ob eine Straße im Gewerbegebiet mit 20m
> Gesamtbreite und 7m Fahrbahnbreite oder eine enge Altstadtstraße mit
> 7m Gesamtbreite und 4m Fahrbahnbreite das Tag width=7 erhält, kann
> man es nicht nutzen.
richtig.
Aber beim beispiel width befürchte ich, wird sich das auch nicht mehr 
ohne weiteres ändern lassen, solange man beim Tag width (alleine) bleibt.
Hier wäre eine Aufdröselung vielleicht ganz sinnvoll (da ich die 
englisch korrekten Begriffe nicht kenne, bewusst "falsch" deutsche 
Begriffe):
width:fahrbahn; width:strassenkörper; width:mitBankett; 
width:mitBöschung; width:mitGehweg etc.

width wäre hier ein generischer Tag, der auch weiterhin nicht für alle 
Auswertungen geeignet ist, aber vielleicht für eine eher heuristische 
Auswertung als Grundlage dienen kann.
>> 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.
> Eine Definition wird nicht perfekt sein. Gegenüber der jetzigen 
> Situation wäre eine Beschreibung wie
>   width bei Straßen: mittlere Breite der Fahrbahn als Innenabstand
>   zwischen den weißen Linien am Straßenrand (sofern vorhanden)
>   sonst als Abstand zwischen den Kantsteinen, sonst als Breite der
>   Asphalt-, Beton- oder Schotterfläche.
> ein großer Fortschritt.
Ja, aber bitte nicht in width, sondern wie gesagt in width:*, weil width 
gefährlich oft "einfach so" verwendet werden wird (abgesehen von der 
Problematik alter Daten vor der Definitionsgebung)

>> 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.
> Du setzt voraus, dass jeder bereit ist, seine eigene Meinung zu
> hinterfragen und ggf. zu ändern. In den Diskussionen in der Liste
> beharrt meist jeder auf seinem Standpunkt.
Das ist ein Problem - aber das müsste sich auch bei "Einrichtung" eines 
Gremiums ändern - das muss sich SOWIESO ändern.
Auch wenn ein Gremium eine Definition vorschreibt, muss jemand danach 
von seinem Standpunkt abrücken,oder das Gremium ist wirkungslos.
> Natürlich ist ein allgemeiner Konsens die Ideallösung. Die meisten
> Gemeinschaften (Staaten, Parteien, Vereine, Verbände) haben aber
> Mechanismen (direkte Abstimmungen aller oder Wahl von Vertretern),
> um eine Entscheidung auch gegen den Willen einer Minderheit
> durchzusetzen.
...brauchen dazu aber Mittel wie Sanktionen, Strafen oder sogar Gewalt, 
weil das ohne eben auch nicht funktioniert.
Das ist in OSM aber nicht möglich, sieht man von dem Versuch eines 
Ausschlusses ab.
Jemanden auszuschließen, der an anderer Stelle aber vielleicht sehr gute 
und wertvolle Arbeit leistet, ist aber alles andere als förderlich.

Gruß
Peter