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
_______________________________________________
Talk-de mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-de
