Hallo zusammen,
ich habe letztens einen Spielplatz taggen wollen. Problem ist jetzt aber, dass ich mir nicht sicher bin, ob ich die Relationen usw. richtig gesetzt habe…
Auf dem größeren von beiden werden auch die Sandkästen nicht gerendert.
Ich habe mich am Wiki orientiert… und dort stand, dass man die Spielgeräte in Relation zum Spielplatz setzen solle.
Wäre cool, wenn sich das mal jemand anschauen könnte, ob das so richtig ist oder wie man es “besser” machen könnte.
Gruß BlubFish
hallo blubfish,
ich kenne mich damit auch nicht aus,
hab’s dir aber mal zusätzlich / testweise mit area=yes getaggt,
schau doch mal, ob’s jetzt funzt…
grüße,
georg
Sieht alles richtig aus. Allerdings ist der Mapnik-Stil nicht für Spielplätze optimiert und stellt daher bis jetzt noch keine Sandkästen dar.
Es gibt ja schon http://opengastromap.org für Gastronomie, http://wheelmap.org für Kinderwägen und Rollstühle. Dort wird das jeweils wichtige auch dargestellt, wenn auch nur über der Mapnik-Grundkarte. Es fehlt eine Spielplatz-, Kindergarten- und Schulkarte: http://openchildrensmap.org oder so. 
Die könnte das alles dann darstellen. Bis sich keiner darum kümmert, kann man nicht erwarten, dass in einer Straßen- oder Wanderkarte (ungefähr das ist http://openstreetmap.org momentan) auch jedes einzelne Spielgerät eines Spielplatzes zu sehen ist.
Ich zeichne Spielplätze auch schon lange mit Details ein, auch wenn keine mir bekannte Karte das bisher schön darstellt. Es geht ja auch nicht um die Darstellung, es geht darum, dass es kartiert ist!
Hallo BlubFish,
erstmal Willkommen bei OSM.
Nicht alles was im Wiki steht wird bei der Onlinekarte gerendert. Objekte wie Sandkästen gehören derzeit sehr wahrscheinlich dazu, da sie noch in den proposed Features sind und auch sonst längst nicht alle möglichen Objekte dargestellt werden. Dein Tagging sieht laut Wiki jedenfalls korrekt aus. “Verwaltungstechnisch” betrachtet ist der Relation-Typ “site” richtig angegeben. Für die Darstellung allerdings wird (zusätzlich) der Typ “multipolygon” erwartet, was aber Löcher im Spielplatz anstelle der Sandkästen ergeben könnte, wenn diese nicht in den Renderregeln implementiert sind.
Viele Grüße
Mario
… so, habe den area-tag wieder entfernt, es hat nichts gebracht
(sorry übrigens dafür, war etwas gedankenlos…)
ich habe dann parallel zu meiner bearbeitung etwas mit einem playground “gespielt”:
auch verschachtelte multipoygonstrukturen bringen hier kein ergebnis (mapnik)
wie mario postet, kann man zwar ein “loch” erzeugen u. in dieses wiederum den
sandkasten setzen, doch in der darstellung ergibt dies auch nur eine einzige
fläche mit einer feinen linie, welche das innere element abgrenzt.
denn “playground=sandpit” wird von mapnik genauso dargestellt wie der playground selbst.
ich habe es dann auch mal mit “natural=sand” angetestet, das brachte aber auch kein
visuell eindeutiges ergebnis…
schade u. grüße,
georg
Einfach einen Wunsch an Mapnik senden. Oder eine eigene Kinder-Karte machen.
Ich habe mir jetzt die Sache nicht im Detail angeguckt, aber der Vorschlag mit dem Multipolygon klingt ziemlich falsch: Ein Multipolygon ist nicht dazu da, um irgendwelche Renderregeln festzulegen, sondern es soll innerhalb von Flaechen ausnahmegebiete raus schneiden. Wenn man also einen Spielplatz als Multipolygon-Outer anlegt und die Sandkiste dann als Inner-Polygon markiert, dann wuerde das bedeuten, dass die Sandkiste nicht zum Spielplatz gehoert, sondern dass der Spielplatz nur aussen um die Sandkiste drumherum ist. Wenn das mit dem Multipolygon so gemeint war, dann ist das also ziemlicher Bloedsinn.
Gruss
Torsten
In der Tat. Das area-Tag ist nur da zu benutzen, wo Strassen nicht als Linie eingetragen sind sondern als Plaetze (also als Flaechen). Und genaugenommen ist es eigentlich auch nur fuer Fussgaengerzonen gedacht.
Fuer alle Elemente, die per Definition sowieso Flaechenobjekte beschreiben, ist das Tag absolut uberfluessig.
Taggen wir hier solange lustig mit irgendwelchen Werten, bis uns die Anzeige in Mapnik am Besten gefaellt? Was probierts du als naechstes? natural=beach?
OSM ist doch kein Malprogramm.
Gruss
Torsten
Also ich finde deinen letzten Beitrag sehr daneben!
Erstens bei OSM gibt es keine Regeln. Jeder darf taggen wie er möchte. Und wenn er dafür das Tag Sandkasten erfindet.
Zweitens finde ich es durchaus legitim das nach Wegen gesucht wird, das die geleistete Arbeit auch honoriert wird. In diesem Falle angezeigt. Schließlich ist nicht jeder hier ein Freak dem es nur darum geht Datenbanken zu füllen.
Man mappt nicht für den renderer/router whatever und das ist eine der wenigen Regeln die OSM besitzt.
Man sollte sich nur etwas überlegen wenn eine Anwendung etwas nicht logisch lösen kann
Solange rumbasteln bis die anzeige in renderer x irgendwie passt ist Müll. Man sollte eher die Renderer verbessern und ohne entsprechende Bug reports wird es nie einen Fortschritt geben.
Eine physikalische Flächenbeschreibung (natural=sand, natural=water, landuse=forest) sollte immer über einer Gebietsbeschreibung (Spielplatz, Wohngebiet) gerendert werden.
Ich finde es auch gut, wenn man ein neues Tag erfindet fuer Sachen, fuer die es noch kein Tag gibt. Das stoert im Moment niemanden und kann in Zukunft das Projekt weiter voran bringen, wenn das Tag sich mal etabliert hat.
Es ist aber eine ganz andere Sache, ein eigentlich unpassendes Tag zu benutzen, nur damit ein neues Objekt bei einem bestimmten Renderer angezeigt wird.
Auch ich sehe die Datenbank nicht als Selbstzweck. Auf der anderen Seite geht es bei OSM aber auch nicht darum, dass man bei genau einem bestimmten Renderer eine moeglichst schoene Anzeige hinbekommt. Man darf dabei nie vergessen, dass OSM ja x verschiedene Auswertungen hat. Es kann ja nicht sein, dass man sich ausschliesslich auf seinen Lieblingsrenderer konzentriert, dafuer aber die anderen Auswertungen stoert. Gerade weil es bei OSM keine festen Regeln gibt, muss man da etwas ruecksichtsvoller agieren.
Wenn einem die Anzeige der Elemente im Renderer nicht passt, dann sucht man sich einen anderen Renderer oder sieht zu, dass man den Renderer entsprechend weiter entwickelt bekommt. Man passt aber nicht die Datenbank auf den Renderer hin ab, das ist der falsche Weg.
Gruss
Torsten
Genau das meinte ich mit „Einfach einen Wunsch an Mapnik senden" = den Renderer durch Bugreports verbessern/weiter entwickeln. Und mit „Oder eine eigene Kinder-Karte machen" = einen passenden Renderer suchen bzw. selbst erschaffen.
Ich sehe auch gerne auf irgendeiner Karte, was ich erschaffen habe. Deshalb suche ich mir die passenden Karten, für meine aufgezeichneten Objekte, zum Beispiel die Plumpenkarte für die Berliner Wasserpumpen.
Eine Spielplatzkarte fehlt mir allerdings auch noch.
Ich habe zur Multipolygon-Relation nochmal im Wiki gelesen und genauer überlegt - kein Hinweis darauf, dass ein inner Element automatisch vom outer Element auszuschließen ist. Niemand käme auf die Idee, ein Sandkasten auf einem Spielplatzgelände gehöre nicht zum Spielplatz, oder andere Beispiele: eine Lichtung gehöre nicht zum Wald, eine Spielfläche (oft von leisure=track umschlossen) nicht zum Stadion usw. Es scheint eine reine Interpretationsfrage zu sein. Ich für meinen Teil bin der Meinung, Multipolygon-Relationen sollen lediglich das Handling mit Flächen bei komplexeren Strukturen (umschließende Straßen/Wege, verschachtelte Flächen etc.) erleichtern. Ein inner Element in einer solchen Relation wird nicht vom outer Element ausgeschlossen, sondern schafft überdeckungsfreien Platz. Insofern denke ich, dass die Multipolygon-Relation (auch) im Sinne der Renderer eingeführt wurde. Sinnvoll ist ein Loch in einer Fläche ja gerade, wenn z.B. Gebüsch auf einem See dargestellt werden soll und an anderer Stelle ein See im Gebüsch - ohne Multipolygon-Relation, aber mit festgelegter Darstellungsreihenfolge, wäre in einem von beiden Fällen das kleinere Element immer überdeckt.
Viele Grüße
Mario
Kein Hinweis? Es steht an zig Stellen, dass “inner”-Member die Löcher in der Fläche sind.
Eben, deshalb ist der Rat, hier eine Multipolygon-Relation einzusetzen, auch komplett fehl am Platz.
Ganz einfache Überlegung: Wenn ich im Sandkasten stehe, bin ich dann auf dem Spielplatz?
Wenn nein => Loch im Spielplatz, inner-Member
Wenn ja => kein Loch im Spielplatz, kein inner-Member - und das will ich doch mal annehmen.
Es ist keine Interpretationsfrage. Die “grenzwertigen” Fälle enstehen nicht dadurch, dass unklar wäre, was “multipolygon” bedeutet, sondern dadurch, dass die anderen Tags schwammig definiert sind.
Beispiel: Meint landuse=forest das konkret baumbestandene Gebiet oder den “Wald” als begriffliche Abstraktion? Im ersten Fall muss die Lichtung ausgeschlossen werden, im zweiten nicht. Ist natural=water die Wasserfläche oder der “See”? Und so weiter.
Eine multipolygon Relation sorgt dafür das die bezeichnete Fläche nur zwischen outer und inner Kreis gilt.
Beispiele:
Ein Wald mit Lichtung: In der Lichtung gilt die Waldfläche nicht mehr.
Eine Grenze mit enclave,Brandenburg als outer und Berlin als inner : Inner gehört nicht mehr zum outer
Das ganze hat somit nur bedingt etwas mit dem Renderer zu run obwohl der Renderer damit auch überdeckungsprobleme lösen kann.
Genaugenommen loest eine Multipolygon-Relation ein Ueberdeckungsproblem, in dem es dafuer sorgt, dass es ueberhaupt keine Ueberdeckung gibt: Im Inner-Bereich gelten ausschliesslich die Tags vom Inner-Polygon und nicht die Tags der Multipolygon-Relation (bzw. die Tags des Outer-Poylgons, sofern die Relation nicht selber mit Tags markiert worden ist - nur der Vollstaendigkeit halber erwaehnt).
Wenn aber zwei oder mehr Eigenschaften gleichzeitig fuer eine Flaeche gelten, dann hat da erstens ein Multipolygon nichts zu suchen und zweitens ist es dann alleine Sache des Renderers, wie er die ueberlagernden Eigenschaften darstellt. Verschiedene Renderer werden da auch zwanglaeufig zu verschiedenen Anzeigen kommen. Es kommt halt ganz darauf an, was fuer den jeweiligen Zweck wichtiger ist. Als Mapper hat man sich da also gar nicht weiter einzumischen.
Nebenbei bemerkt:
Das haut so pauschal uebrigens auch nicht hin. Man braucht als Beispiel ja nur mal einen Waldspielplatz nehmen. Den will man in einer Karte ja nicht unbedingt vom Wald verdeckt haben.
Fuer die Darstellung ist es eine ganz brauchbare Heuristik, wenn man asagt, dass eine kleinere Flaeche innerhalb einer groesseren Flaeche immer ueber dieser angezeigt werden sollte. So sind erstens immer beide Elemente in der Karte mindestens teilweise zu sehen (d.h. kein Element ist vollstaendig verdeckt) und zweitens wird dem Mapper mit einiger Wahrscheinlichkeit die kleinere Flaeche an der Stelle wichtiger als der “Hintergurnd” gewesen sein, denn sonst haette er sie ja nicht extra eingezeichnet.
Das Problem bei diesem Ansatz ist allerdings, dass die Darstellunsgreihenfolge dann nicht mehr alleine von den Tags der Elemente abhaengt, sondern auch noch die raeumliche Lage der Elemente mit ausgewertet werden muss. Und das ist um ein Vielfaches aufwendiger.
Ein anderer Ansatz ist, dass man die Flaechenelemente nicht deckend einzeichnet sondern nur (halb-)transparent. Dann ist die Darstellungsreihenfolge nicht mehr so wichtig, da die anderen Elemente ja immer noch durch das oberste Element durchscheinen. Auf der anderen Seite leidet natuerlich die Optik der Karte, wenn man nur noch mit transparenten Flaechenanzeigen arbeitet.
Letztendlich muss also jeder Renderer entscheiden, wie er seine Schwerpunkte setzen will. Aber noch mal: Das ist Sache des Renderers und nicht Sache des Mappers!
Gruss
Torsten
Wenn die Renderer manche Sachen nicht logisch lösen können dann fehlt IMO eine Information.
Da frage ich mich warum man nicht ein z-level Tag für solche Flächen benutzt.
Weil der Mapper gar nicht entscheiden kann, in welcher Reihenfolge die Elemente von jedem einzelnen Renderer dargestellt werden. Fuer den einen Anwendungszweck ist die eine Eigenschaft wichtiger, fuer den anderen Anwendugszweck ist die andere Eigenschaft wichtiger. Der Mapper traegt beide ohne eine Wertung ein, und der Renderer entscheidet dann entsprechend seiner Zielsetzung, wie das darzustellen ist. So kann jeder Renderer die Anzeige auf seinen Zweck hin optimieren.
Theoretisch koennte man dem Renderer die Arbeit ein wenig leichter machen, in dem man ueberlagernde Flaechen in einer Relation zusammen fasst. Dann wuesste der Renderer ohne lange Suche, welche vershciedenen Eigenschaften er irgendwie miteinanderkombinieren muss.
Gegen eine solche Relation werden aber viele (zu Recht) einwenden, dass man diese Information auch automatisch aus der Lageinformation der Objekte generieren kann. Das ist dann halt nur mit einigem Aufwand verbunden.
Gruss
Torsten