Mhhh, leisure=track ist nicht unbedingt falsch, sieht aber trotzdem komisch aus. 
http://www.openstreetmap.org/?lat=44.80907&lon=6.47563&zoom=15&layers=M
Ja, sieht merkwürdig aus.
Die Taggs aus http://wiki.openstreetmap.org/wiki/Proposed_features/Piste_Maps werden zwar verwendet, aber scheinen dem/den Erstellern nicht zu genügen, da die natürlich nicht auf einer der Standard-Karten gerendert werden.
Edbert (EvanE)
Und das ist ein Problem, mit dem wir uns vermutlich immer häufiger werden auseinandersetzen müssen.
Wieder haben wir es mit einer “Bedeutungserweiterung” oder “Interpretationserweiterung” eines für andere Zwecke etablierten Tags zu tun.
Wieder hat man als Kartenbauer das Problem, nach neuen Strategien zum Ausfiltern solcher Daten suchen zu müssen.
Wie hier http://forum.openstreetmap.org/viewtopic.php?id=14597&p=2 bereits geschrieben:
Bei der Diskussion um die Neuerfindung von Tags wird hin und wieder die Meinung geäußert, man möge doch erst einmal überprüfen, ob nicht die vorhandenen Tags ausreichen. Das ist zwar grundsätzlich richtig. Doch kommt dabei nicht deutlich genug rüber, daß man gleichzeitig auf Differenzierung der vorhandenen Tag-Schemata achten bzw. diese gegebenenfalls erweitern muß.
So muß man sich nicht wundern, wenn vorhandene Tags in ihrer Bedeutung erweitert werden, nach dem Motto “das paßt eigentlich auch noch irgendwie rein”.
Wenn man mal nachzählt, wieviele User sich an Diskussionen um Tags beteiligen und wie diese dann bei Streitthemen verlaufen, dann muß man sich nicht wundern, wenn sich viele die Zeit für solche “unnützen Schreibereien” sparen und “einfach mal machen”.
Das Beispiel Skipiste sollte eigentlich Anlaß sein, sich das Tagschema leisure=track mal genauer unter die Lupe zu nehmen, um zu hinterfragen, welcher Modifikation es bedarf, um sinnvoll auch für diesen Bereich genutzt werden zu können, bzw. ob die in Mapnik gewählte Form der Auswertung (=Renderregeln) sinnvoll ist.
Der Mapper hat sich ja offensichtlich Gedanken gemacht. Die Kombination leisure=track + sport=skiing ist ja eigentlich eindeutig.
Warum nun in Mapnik leisure=track ohne Zusatz von area=yes als Fläche gerendert wird, hat sich mir allerdings noch nie erschlossen. Track heißt doch Bahn oder Spur. Im Zusammenhang mit Sportarenen wurde das dann als “von der Rennbahn eingeschlossene Fläche” gedeutet. Paßt zwar, ist aber nicht wirklich logisch, wenn diese Interpretation ohne den Zusatz area=yes erfolgt.
Da die die Piste umschließende Linie mit Sicherheit nicht die Spur/Bahn ist, auf der man fährt, ist das Tag sachlich falsch genutzt und gehört durch ein sinnvolleres ersetzt.
Falls man in Mapnik die Entwicklung von offensichtlich falschen Tagkombinationen unterdrücken möchte, muß man in diesem Fall die Renderregeln umstellen und alle leisure=track grunsätzlich ohne Fläche darstellen, solange der Zusatz area=yes fehlt. Da auch diese Kombination natürlich leicht zweckentfremdet werden kann, um die Darstellung einer Fläche in Mapnik zu erzwingen, muß man das Tag area=yes überdenken. Zumindest in der Kombination mit leisure=track könnte man überlegen, daß area mit einem auf den Nutzungszweck der Fläche hinweisenden Begriff kombiniert wird. Wenn in Mapnik nur noch leisure=track + area=athletic_sports gerendert wird, kann für Mapnik gezielt ausgewählt werden, was dargestellt/ignoriert wird. Wenn dann jemand tatsächlich schummeln möchte, ist er gezwungen, einen ganz offensichtlich falschen Key zu benutzen. Wer das dann macht, …
Im vorliegenden Fall würde ich aber keinesfalls unterstellen wollen, daß da jemand versucht hat zu manipulieren. Ich meine eher, daß da jemand kreativ vorhandene Möglichkeiten genutzt und die Bedeutung des Tag leisure=track für seine Zwecke erweitert hat.
Wenn dieses Beispiel nun zeigen sollte, daß die Ausweitung des Verständnis von leisure=track möglicherweise zu negativen Folgen für Mapnik führt, dann muß man sich Gedanken über Tag- und Renderschema machen.
Gruß
tippeltappel
Ich denke dass ist historisch gewachsen. Als ich vor einigen Jahren mit OSM anfing, da meckerte keepright, dass leisure=track als Linie falsch sei und gefälligst eine Fläche sein soll. JOSM und Mapnik rendern sie als Flächen. Nur im Wiki stand es anders.
keepright meldet inzwischen keine Fehler mehr, aber JOSM und Mapnik behandeln leisure=track immer noch als Flächen.
Aber hier haben wir ein generelles OSM-Problem: Jeder interpretiert die Tags auf seine Art und Weise. Änderungen sind nur sehr schwer und schmerzhaft zurchzusetzen. Es gibt keine “verbindliche” und maschienenlesbare Definition von Tags mit zulässigen Werten und Eigenschaften, die jedes Tool einlesen könnte.
In JOSM divergieren die Definitionen teilweise sogar innerhalb unterschiedlicher Funktionen wie Presets, Darstellung und Validator. So fehlt public_transport=platform in den Vorlagen, aber es gibt eine eigene Darstellung. Teilweise gibt es Werte in den Vorlagen, die der Validator bemängelt. Sogar das validieren im Validator und vor dem Hochladen liefern unterschiedliche Fehler.
Aber das mit den “verbindlichen” Definition ist eine andere Geschichte (Thread) 
Grüsse
mdk