[Talk-de] Wie erreichen wir einheitliche Tagdefinitionen?
Stephan Wolff
s.wolff at web.de
Do Nov 4 02:16:06 UTC 2010
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.
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.
> 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.
>> 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?
>
> 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?
Es ist doch nicht wichtig, welche Definition durch das Wort "width" und
welche durch ein anderes Wort wie "fullwidth" in der Datenbank intern
repräsentiert wird. Falls die Mapper die zweite Definition sinnvoller
finden, setzten sie eben nur den Wert für "fullwidth". Trotzdem sind
Mehrdeutigkeiten damit vermieden.
>> 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.
Ein Mapper sagt: "Ich möchte, dass meine Bootstankstelle in der Karte
erscheint. In der Karte erkennt man am Standort der Tankstelle den
Unterschied. Deshalb verwende ich das gleiche Tag".
Ein zweiter Mapper meint: "Router müssen an den Daten erkennen, ob eine
Tankstelle Boote oder Autos versorgt. Deshalb sollten Bootstankstellen
nicht "amenity=fuel" verwenden".
Beide Begründungen sind prinzipiell legitim. Darf der zweite Mapper den
Eintrag des ersten einfach in "amenity=boat_fuel" ändern? Darf der erste
Mapper das Tag zurücksetzen? Irgendwann muss man eine Seite enttäuschen.
Man kann einen langen Editwar mit Arbeit und Ärger auf beiden Seiten
abwarten. Wenn man frühzeitig eine Entscheidung trifft, kann man den
Nachteile durch Änderung der Regeln im Router oder Renderer vermeiden.
> 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?
>
path/footway: Gleicher Weg wird unterschiedlich in der Mapnikkarte
dargestellt - keine Unterscheidung Trampelpfad vs. offizieller Weg
Suche der nächstgelegenen Tankstelle für PKW
Suche des nächstgelegenen Flugplatzes ohne Modellfluggelände
Unterscheidung zwischen Weg für Radfahrer verboten und Weg für Radfahrer
unbenutzbar
Fussgängerrouting über Buslinien
"highway=service" als Fährzufahrt verhindert Routing
nichtnummerische Werte für maxspeed
keine einheitlichen Tags für Seekarten (OpenSeaMap, Freie Tonne, ...)
Welche wichtigen Fragen konnten innerhalb des letzten Jahres im
Konsens geklärt werden?
> 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.
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.
Gruß, Stephan
Mehr Informationen über die Mailingliste Talk-de