Bekomme auch keine Verbindung. Da sollte ein Server wohl Schluckauf haben.
Naja, morgen wird ja wohl wer im Office sein.
Gruss
walter
Okay, danke für’s Checken!
Hallo zusammen.
In meiner Stadt werden seit ein paar Monaten mehr und mehr Stelen aufgebaut, welche eine Kombination von Karte und Wegweiser sind und als Leitsystem für die Touristen dienen sollen:
Bisher hatte ich diese Stelen als “information=guidepost” gemappt, nun ist mir aber aufgefallen, dass da ja nun eigentlich die Info, dass da auch eine Karte abgebildet ist - “information=map” - verlorengeht. Im Wiki finde ich leider nichts passenderes. Hat jemand von euch eine Idee, wie ich diese Info elegant mit einbauen kann? Danke!
name=Rathaus + map=yes würde ich das taggen. (guidepost hat mich zuerst etwas verwirrt, es sieht wie ein information=board aus, aber da sind ja tatsächlich Richtungen angegeben.)
–ks
information=guidepost;map . Oder eins der anderen Möglichkeiten auf http://wiki.openstreetmap.org/wiki/Multiple_values .
Meine Präferenz ganz klar das Semikolon.
Vielleicht eher genau umgekehrt, d.h. information=map plus guidepost=yes. Wobei letzteres auch als überflüssig interpretiert werden könnte, zumindest in diesem speziellen Fall, wo die map an sich die Lagepositionen ja auch enthält.
Andererseits, die dritte Variante mit Semikolon hätte dagegen wieder den Vorteil, dass man damit effektiv gleich beides als Icon aus fast allen Fertigkarten-Darstellungen löschen kann. Weil diese dämlichen Kartenapps, die Maps nur als Bilder anzeigen können, ja zu doof sind um Mehrfachwerte einzeln auseinander zu klamüsern und als Icon darzustellen. Die können grundsätzlich nur vorher genau definierte Einzelwerte abfragen, nicht auch noch sämtliche möglichen Mehrfachkombinationen (incl. auch noch sämtlicher möglichen Leerzeichen-Positionen neben den Semikolons) in genau vordefinierten if-Bedingungen. Sowas muss man nicht auch noch unterstützen, schließlich verplempern wir als Mapper nicht soviel unserer Freizeit für so sinnloses Zeug wie irgendwelche druckreifen 2D-Karten zu erzeugen, sondern um die Datenbank so detailreich wie möglich zu kriegen.
Finde ich nicht. Der Witz an einem Guidepost ist ja, dass man sich die Richtung nicht erst aus einer Karte raussuchen muss, sondern gleich ein Brett vor dem Kopf hat, das in die richtige Richtung zeigt. Das gedankliche Einnorden einer nicht drehbaren Karte fällt vielen Leuten entsetzlich schwer, und ob „rechts“ auf der Karte nun real rechts, vorwärts, links, zurück oder schräg aufwärts ist, ist dann nicht so einfach zu entscheiden. Dafür sind guideposts da.
–ks
Das würde ich so nicht sagen. Also, dass die Kartenapps zu dämlich dazu sind. Beim Kacheln macht es zeitlich einen großen Unterschied, ob ich jeden Hundekottütenspender darauf prüfen muß, ob in einem Tag ein oder mehrere Werte drin stehen und wie die auseinander zu klabüstern sind.
Wenn die Änderungen ja nicht sofort auf “der Karte” sichtbar sind, kommen hier wieder im Minutentakt Fragen, warum denn die schöne neue Baumreihe nicht angezeigt wird…
In der Hoffnung, dass dies eine „kleine Frage“ ist, sprich, dass wir da einen Konsens haben: ein und dieselbe Gemeinde ist zweimal als place=village, name=Pleidelsheim gemappt:
- mit einem place-Node, der zudem die weiteren Tags wie population=* beherbergt: https://www.openstreetmap.org/node/76797862
- als Umriss, der zudem auch als landuse=residential-Fläche dient: https://www.openstreetmap.org/relation/6712478
(Aus dem Umriss (2) habe ich bereits ein Multipolygon gemacht, weil ich, da es ja ein landuse=residential ist, landuse=allotments, landuse=cemetery etc. als inner eintragen wollte; in der Annahme, dass wir, um sauber zu arbeiten, überlappende landuse-Flächen vermeiden wollen.)
Zweimal place=village, name=Pleidelsheim scheint mir ein bisschen viel des Guten zu sein. Sollte ich nicht entweder diese Tags von (2) entfernen (sodass dies nur noch als landuse=residential-Fläche dient), oder (1) löschen und die Tags von dort auf (2) übertragen? Oder soll ich das so lassen? Oder sollte ich was ganz anderes machen? 
(Ich weiß, wir hatten schon Diskussionen zu diesem Thema, aber ich finde sie gerade trotz intensiver Suche irgendwie nicht wieder. Sorry!)
place-nodes sollten, wie der Name schon sagt, Nodes sein. Sie werden nämlich von Mapnik überhaupt nicht gerendert, wenn man Flächen (oder, wie hier, Relationen) damit taggt. Es gibt jemanden, der hier in der Gegend die place-Nodes fleißig in die residental-Areas übertragen hat, mit dem “Erfolg”, dass diese Dörfer nicht mehr auf der Karte erscheinen.
Stimmt so nicht: Laut Wiki ist place ein Schlüssel für nodes und areas. Dass OSM-Carto die place-areas nicht anzeigt, ist ein bekanntes “issue”. Das führt zum bekannten Problem, ob der Renderer über das Tagging entscheiden soll.
Ginge man strikt nach dem Kriterium “kein Tagging für den Renderer”, müsste man deutschlandweit alle place-nodes aller Gemeinden löschen, da die Gemeinden bereits über die Grenzrelationen abgebildet sind. Aber wir machen das genau deswegen nicht, weil eine Karte ohne irgendwelche Ortsnamen nicht wirklich hilfreich ist.
Welche meinst du (sortiert von aktuell bis alt):
oder vielleicht
Edit: Das finde ich zumindest wenn ich bei Google nach “site:forum.openstreetmap.org place node” suchen lasse und für relevant gehalten habe.
Wäre echt mal schön wenn sich der Standard-OSM-Kartenstil mal dazu entscheiden könnte auch areas entsprechend zu behandeln.
Bald ist ja Weihnachten. Ob man es sich wünschen kann?
Nö, löschen muss man nicht - es gibt noch viele andere redundante Daten in OSM, die man aus verschiedensten Gründen drin lässt. Ich habe nur darauf hingewiesen, dass place an area erlaubt ist.
Man könnte argumentieren, dass Ortsnamen nicht an residentials gehören und daraufhin deine erste Lösung anwenden 
Ich habe auch lange mit place-Nodes vs. place-Polygonen gehadert und bin bei place-Nodes geblieben (die ich z.B. bei einzelnen Gehöften, Weilern etc. begeistert setze), und zwar aus folgendem Grund:
Das place-Polygon bildet nichts Physisches ab, sondern umreißt nur, was „alles dazugehört“. Das ist nun eine für Menschen sehr gut verständliche, für Maschinen aber umso umständlichere Art der Dazugehörigkeitsveranschaulichung: die Maschine muss erst anhand der Koordinaten ermitteln, ob ein Punkt innerhalb des Polygons liegt. Daher würde ich Zugehörigkeit eher per is_in=* abbilden. Ich weiß, dass viele das nicht mögen, aber dann muß nur ein String ausgewertet werden, um die Zugehörigkeit beispielsweise eines Aussiedlerhofes zu einem Dorf maschinenlesbar zu machen. Einfacher geht’s nicht.
Dem Argument, ein place-Polygon bilde nichts Physisches ab, könnte man entgegenhalten, das tue ein place-Node auch nicht. Stimmt zunächst mal, wenn man „physisch“ im Wortsinn begreift, aber er bildet dennoch etwas sehr Sinnvolles ab, nämlich das „gefühlte Zentrum“ des entsprechenden Wohnplatzes. Das ist nicht nur deshalb sinnvoll, weil der Renderer dann dort den Namen hinsetzen kann (obwohl auch das einen guten Sinn erfüllt: man stelle sich ein Dorf vor, das an einer Ecke seiner länglichen Gemarkung liegt – ein Name, der nur nach Admin-Grenzen da reingesetzt wird, säße mitten in der Wiese und weit weg vom Dorf!), sondern erleichtert auch andere Anwendungen. Wenn ich mir zum Beispiel eine Anwendung bastle, die die Luftlinienentfernungen von Orten ermittelt und dazu die Koordinaten der place-Nodes auswertet, dann weiß ich, dass ich ungefähr die Stadtmitten habe. Ohne Place-Einträge ginge so etwas einklich gar nicht, und die geometrischen Mittelpunkte von place-Polygonen können auch danebenliegen, sobald das Polygon zu weit von der Rotationssymmetrie abweicht.
Also setze ich weiterhin munter place-Nodes und fühle mich gut dabei. Auch wenn sie nichts richtig Körperliches abbilden, etwas sehr sinnvolles Abstraktes bilden sie auf jeden Fall besser ab als place-Polygone, und deutlich besser als Admin-Polygone.
–ks
Bei admin-Relationen kann man das auch ohne place-nodes erreichen und zwar mit label-nodes (role=label). Das ist dort sinnvoll, wo der Name an unerwünschter Stelle erschiene (z.B. U-shape). Die tun genau das, was ihr Name sagt, nämlich dem Renderer sagen, wo er den Namen hinpflanzen soll. Oft mag ein admin_center das auch bereits erledigen.
Man muss das nicht so machen, aber place-nodes haben auch Nachteile z.B. gelegentlich bei Nominatim.
Ortsnamen an Residentials sind Blödsinn. Höchstens Siedlungsnamen würde ich tolerieren.
Gruss
walter
Ah, kannte ich noch gar nicht. Aber spätestens im Subadminbereich muss man auf place-Nodes gehen (Aussiedlerhöfe, Weiler, einzelne Wohngrundstücke, Forsthäuser). Und dann scheint es mir konsistenter, eine Methode durchgehend anzuwenden, statt ab einer Verwaltungsebene zu wechseln.
–ks