Skipisten

Mhhh, leisure=track ist nicht unbedingt falsch, sieht aber trotzdem komisch aus. :wink:

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) :wink:

GrĂŒsse

mdk