barrier=line auf Sportplätzen - Tagging für den Renderer?

Wer soll hier Grenzen setzten? Je nach dem was ein mapper für wichtig hält wird er eintragen. Das Kartieren “vor der Haustür” ist schließlich irgendwann erschöpft und so mancher Süchtige verfällt dann auf’s Kartieren von Bodenfliesen.

Leider,

mir ist schon aufgefallen, dass mit zunehmender Bildqualität der Horizont mancher Mapper enger wird. Man mappt lieber die Bürgersteige, Kanaldeckel oder Vorgärten “seiner” Stadt, als in der Ferne wichtige Lücken zu schliessen.
Mußte mich schon mächtig zusammenreissen als ich endlich einen eigenen Mapserver mit AeroWest-Bildern meiner Ecke hatte.

Gruß
Walter

Gute Karten sollten ein gewisses Abstraktionsmaß besitzen. Um aber gute Karten erzeugen zu können, muss erstmal eine möglichst exakte Datenbasis da sein, von der man abstrahieren kann. Und genau die versuchen wir doch zu schaffen.

Wenn dazu irgendwelche exotische Tags verwendet werden ist das ja auch OK - es bleibt ohnehin dem Kartenersteller überlassen was er in seine Werke an Tags aufnimmt.
Jedoch, wenn zB path als Tag für Feldlinien verwendet wird wird’s schwierig das auszusortieren.

Grüsse
Christian

Oder auch highway=steps+tracktype=grade5 für eine Sommerrodelbahn

Aua, wie unbequem.

Übrigens finde ich die Straßenlistenauswertung 'ne dufte Sache. Endlich kann man ganz simpel namenlose Straßen finden um kommt dabei weit rum!

Nicht nur hier zeigen auch ändern (habs gemacht!). Es gibt aber kein highway-Tag für eine Sommerrodelbahn, Das Wiki sagt nur attraction=summer_toboggan als POI (Fläche oder Node), aber nicht als way. Ich habe daher mal zusätzlich highway=summer_toboggan verwendet obwohl es das laut Wiki nicht gibt.

Und wech isser in Mapnik. Na ja immerhin der Name wird noch gerendet.

+1
Genau, wegwerfen kann man immer noch!

Und damit man aus den Daten auch von Karten für alle Anwendungszwecke erstellen kann, brauch man ein vernüftiges Datenmodell, um die Daten, erstens detailiert erfassen und zweitens, dann auch zielgerichtet für die Karten/Anwendungen selektieren zu können! Das Problem ist nur das das “vernüftige” Datenmodell sicher etwas komplexer wird, so das es das nicht mehr gut massentauglich ist, was es aber sein muß, weil wir brauchen ja jeden Mapper. Somit muß da nach möglichst jeder DAU mitmachen können, also braucht man Tools und Wizards, die das Modell für den Benutzer verstecken, aber gelcihzeitig zum einen die wirklichen Daten für Interessierte weder verstecken, noch die Erweiterung durch eigene Zusätze der erfahrenen Mapper verhindern.

Das ist meies Erachtens der einzige mir bekannte, sinnvolle Weg, wie man auf Dauer verhindern kann, daß man weder nur noch beschränkten Datenmüll hat, noch das Ganze so komplex geworden ist, das niemand mehr mitmappen kann.

Ja, marking=line wäre da evtl. sinnvoller.

Wo denn im Wiki? http://wiki.openstreetmap.org/wiki/Proposed_features/Key:attraction schlägt das nur als (nicht geschlossenen) way vor.
Bei how to map a… steht da so ein Satz in deinem Sinne dabei:

Herrlich, unser Wiki.
Ich hab attraction=summer_toboggan ergänzt.

Ich hole das Ursprungsthema “barrier=line” auf Sportplätzen wieder hoch, weil sich das Malen der Linien auf Sportanlagen offensichtlich weit verbreitet, seitdem wir die aktuellen höher auflösenden Bilder von Bing haben.
Siehe z.B. hier: http://www.openstreetmap.org/?lat=48.271961&lon=7.809187&zoom=18&layers=M
Mapnik zeichnet das schon :confused:
In der Wiki finde ich nix :roll_eyes:
Wie gehen wir damit um? Fügen wir uns dem Druck der Mapper? Dann gehört das in die Wiki.

Ja, weil Mapnik jedes barrier=* malt. :wink:

Bleibt uns was anderes übrig?

Aber vielleicht nicht als Barrier, oder? Kann man nicht was neues machen, wie pitch = line oder so.

Grundsätzlich finde ich das Eintragen solche Linien nicht verkehrt. Hübsch isses ja :wink: und wenn jemand Spaß daran hat, die Sportplätze in seiner Umgebung derart zu verzieren, brauchen wir ihm den nicht zu verderben. Einige Schrullen machen OSM doch erst richtig sympathisch.

Freilich gefiele es mir besser, wenn man Mapnik beibringen könnte, abhängig vom sport-Tag sowie der Größe und Ausrichtung des Spielfeldes die passenden Linien selbst zu malen. Da würden sicher schlagartige etliche sport-Tags nachgetragen.

Wenn man die Linien selbst einzeichnen will, ist barrier m.E. kein guter Schlüssel. Das soeben vorgeschlagene pitch=line beispielsweise macht schon mehr Sinn.

Dein Vorschlag Mapnik bei leisure=pitch und sport=* gleich selber die passenden Linien (nur in Z17/Z18) einzuzeichnen, finde ich ausgesprochen gut. Es wäre dann aber auch notwendig, dass JOSM und Potlatch-2 diese Funktion ebenso haben. Das würde uns in Zukunft eine Menge von Detail-Müll in den Daten ersparen.

Leider hat das Umbiegen auf ein anderes Tagging wie pitch=line wenig Aussicht auf Erfolg. Erstens wird pitch=line/net nicht in Mapnik gezeichnet das falsche Tagging barrier=line jedoch bereits heute. Weiter ist es gleichgültig mit welchem Tagging die DB zugemüllt wird.

Dagegen hilft wirklich nur noch das automatischen Einzeichnen der Spielfeldbegrenzungen wie von dir vorgeschlagen. Tagging wäre zusätzlich zu leisure und sport ein decoration:=. Im verlinkten Beispiel also decoration:tennis=4 und decoration:soccer=1 und decoration=none.

Edbert (EvanE)

@EvanE:

Generell ist deine Idee mit decoration:tennis=4 udgl gut - leider aber nicht umsetzbar, da man dann eine Prüfung bräuchte: 3+1 oder 2+2 oder 4+0 (also die Anordnung der Plätze betreffend) - somit würde sich eigentlich nur anbieten jeden Platz als einen Platz zu handeln. Dann könnte man es wieder über die Sportart machen und bräuchte kein decoration:xxyy

tunnelbauer: +1

Die Abmessungen von Sportfeldern sind ziemlich genau geregelt. Von daher ist es kein Hexenwerk die Anordnung der einzelnen Plätze festzustellen, wenn man eine Außengrenze hat. Bei den 3D-Leuten wird der Dachfirst ja auch nach längere/kürzere Seite ausgerichtet. Lediglich wenn man sehr viele Spielfelder hat, kann es mehr als eine Lösung geben. Aber niemand hindert uns, ein passendes Subtagg für die Anordnung zu entwickeln.

Ich zeichne speziell bei Tennisplätzen nur das als leisure=pitch ein, was durchgehend den selben Belag und einen durchgehenden Außenzaun hat. Das sind oft 2, 3 oder 4 Spielfelder. Wenn ein (Erschliessungs)Weg dazwischen verläuft, sind das auch getrennte leisure=pitch.

Aber jeder wie er/sie mag. Wenn man jedes Tennisfeld einzeln einträgt (was ich nicht befürworte oder mache), dann kann man in der Tat auf decoration:= verzichten. Nichtsdestotrotz wäre es sinnvoll, zu prüfen, ob die Größe auf ein Spielfeld passt oder eventuell mehr als ein Spielfeld in der Fläche passen würde.

Ich würde jedoch vorschlagen auch im Fall von Einzelfeldern ein decoration::= zu setzen und nur wenn dieses Tagg gesetzt ist, die Spielfeld-Begrenzungen überhaupt einzutragen. Wer das nicht haben will, lässt decoration:=* einfach weg.

Über Tagg-Namen usw. kann man natürlich reden. Da ist noch nichts festgelegt.

Edbert (EvanE)

Es gibt genügend Beispiele, wo dem genau nicht so ist. Spielfelder orientieren sich eher an den Gegebenheiten als andersherum. Wenn der Sportplatz eben 5m zu kurz wird, wird er trotzdem gebaut. Da wird dann zwar keine Olympiade drauf stattfinden, dennoch ist es ein Fußballfeld. Die exakten Maße findest du nur bei ausgesprochenen Sport-Arealen. Bei allem anderen werden dann eben auf eine große Rasenfläche mehrere Spielfelder so gebaut, dass es eben irgendwie passt. Also ist es durchaus sinnvoll, die einzelnen Spielfelder zu taggen, als da irgendeinen Algorithmus ranzulassen, der versucht Standardmaße in die Fläche zu packen.

Ich habe hier auch schon mal geschaut und irgendwo im “Osten” folgende Tags entdeckt.
Das ganze wurde auch auf “irgendwelchen” Karten dargestellt.

marking=sport
colour=white

Klingt zwar nach malen, ist aber ein recht flexibler Ansatz…

ludwich