Oh, OK, wusste ich nicht. Macht ja aber auch Sinn, da redundante POIs auch unerwünscht sind. http://wiki.openstreetmap.org/wiki/DE:Points_of_interest#POIs_in_OpenStreetMap
klar, wenn es nicht eingebaut ist, kann’s auch nicht gehen - hab ich glatt vergessen für die nächste Version geplant 
Gruss
walter
p.s. hat jemand ein gutes “Schnipsel” dafür? Muß ja nicht jedesmal das Rad neu erfinden. alles in jquery drin.
so, Fensterangaben im url werden nun auch unterstützt. (permalink).
offen: Lupe rechts oben zickt noch ein wenig rum.
Gruss
walter
Braucht man die Dinger nicht um eventuell die Texte richtig zu platzieren? Vor Allem wenn die Formen der Flächen seltsam sind.
Leider werden die immer wieder dazu missbraucht. Place=town/city/village ist redundant, wenn die Grenzrelationen vernünftig gepflegt wird. Man könnte sie sogar als “Altlast” bezeichnen, da sie vor der intensiven Nutzung von Grenzrelationen eingeführt wurden aber immer noch verwendet werden.
Der einzige Vorteil dieser Nodes ist, dass man in der Tat als Mapper damit die Position des Namens beeinflussen kann.
Das Platzieren des Namens bei “unglücklichen” Grenzpolygonen kann durch zwei Maßnahmen beim Rendern verbessert werden:
- Man berechnen die Position nicht mehr mit st_Centroid(geom) sondern mit st_PointOnSurface(geom). Dadurch liegt der Name garantiert innerhalb der Fläche.
- man benutzt beim Rendern die Koordinaten des Labels (ein Node mit der Rolle “label” innerhalb der Grenzrelation)
Beide Möglichkeiten werden bisher zumindest von den Machern vom Mapnik-Style ignoriert.
Nominatim kommt mWn auch ohne Place-Node ganz gut zurecht, wenn das Grenzpolygon die Daten enthält. Ich habe auf jeden Fall “meinen” Place in Wambach gelöscht und werde das mal beobachten.
Gruss
walter
p.s. Lösung1 besteht wirklich nur darin, in der Render-Rule ein einziges Wort auszutauschen 
Gegenbeispiel: der Aachener Bezirk Kornelimünster/Walheim enthält etliche “places” von hamlet über village bis suburb: neben Kornelimünster und Walheim u.a. Lichtenbusch, Oberforstbach, Schleckheim, Nütheim, Schmithof, Sief, Friesenrath, Hahn. Keiner der genannten Orte entspricht einer weiteren administrativen Gliederungsebene (sodaß auch eine “vernünftige Pflege” derselben nicht helfen würde), auch die Identifikation mit landuse-Flächen ist bei einigen problematisch. Als weitere - nicht in OSM enthaltene - bürokratische Ebene existieren nur “statistische Bezirke” - aber auch die haben nichts mit den genannten “places” zu tun.
Dann formuliere ich das mal etwas anders: Dort, wo administrative Grenzen vorhanden und entsprechend gepflegt sind, ist ein place-Node unnötig.
Zudem hab ich mich direkt auf place=city, place=town und place=village bezogen.
Allerdings gibt es auch Gegenden, wo das Admin-Level bis auf 11 runtergebrochen wurde. Es liegt wohl nicht an der “Gegend” sondern am dortigen Mapper.
Wenn es im ländlichen Bereich mehrere räumlich getrennte ehemalig autarke Dörfer gab, die irgendwann administrativ zusammengelegt wurden, sind die - für mich - immer noch Teile des Ganzen. Sie haben ihre Lage, räumliche Trennung und eigenen Namen.
Warum sollten die nicht mit Adminlevel 10 ff erfasst werden, auch wenn es keine selbständige Administration dafür gibt? Irgendwie ist das päpstlicher als der Papst.
Wie eingangs schon geschrieben: Ich habe kein Problem mit Place-Nodes; nur doppelt gemoppelt sollte nicht sein - ist doch wohl das OSM-Prinzip “Ein Feature für eine Aufgabe” (oder so ähnlich).
Gruss
walter
Warum willst du jetzt einen Node mit einem neuen Tag haben? Wenn der Place node innerhalb liegt dann wird der Node statt der Relation dargestellt. Und zwar ohne das man da jetzt “ich bin das Label” dran schreibt. Vond er Auswertung sollte das der gleiche Aufwand sein.
Auf welche Fläche willst Du Deinen ersten Vorschlag (st_PointOnSurface(geom) )beziehen? Die meisten Städte bestehen aus einer vielzahl von landuse=… und der Mittelpunkt der aministrativen Grenze ist nicht immer dort, wo man das Label haben will bzw erwarten würde, also im Extremfall fast ausserhalb der Stadt. Dann gibts da noch Länder, die keine eigene administrative Grenze für Städte haben sondern die kleinste Stufe etwa einem Landkreis entspricht
Bei Level 10 hast Du eventuell Recht. Ansonsten sollte man schon irgendwie angeben, wo sich das Zentrum befindet, und dafür ist der place-node gedacht.
Da kommt der Name derzeit sowieso hin. Allerdings haben es die Kollegen in den letzten Monaten doch hingekriegt, dass die Beschriftung wirklich innerhalb der entsprechenden Fläche liegt. Damit können wir “PointOnSurface” als erledigt schliessen 
Dass der so berechnete Punkt für gerenderte Karten nicht optimal ist, ist unbestritten.
Allerdings wird mMn Place=city/town/village “missbraucht”, um einen Namen an der gewünschten Stelle hinzukriegen. Zudem kommen dann Beschwerden, wieso der Name mehrfach auf der Karte erscheint. Dieses Platzieren - und nur dies - könnte die Rolle “label” übernehmen, wird aber wohl als “Taggen für die Renderer” von den Programmierern abgelehnt.
Ja, ist doch ok so. Wo keine Grenzen bekannt/erfasst sind, erfüllt ein Place-Node prima seinen Zweck. Haben wir doch auch so gemacht. Ich finde aber “es kann nur einen geben”.
Gruß
Walter
Ok, das ist ein guter Ansatz. Die Auswertung sollte doch etwas schwieriger sein aber in vertretbarem Maße bleiben. Den Label-Node hab ich nur als Idee übernommen, da er schon öfters aufgetaucht ist und auch im wiki erwähnt wird: http://wiki.openstreetmap.org/wiki/Relation:boundary (*)
Gruss
walter
*) bitte jetzt keine Diskussion boundary versus multipolygon oder deutsches wiki/englisches wiki - und wenn ja, ohne mich.
Ich habe das auch eben mal bei ein paar Dörfern in meiner Gegend probiert: Es wird auf osm.org nicht dargestellt (Beispiel). Ich habe im Bugtracker mehrere Einträge dazu gefunden, die aber grösstenteils als “gelöst” markiert sind. Habe ich irgendwas falsch gemacht oder ist das ein Fehler des Renderers? Also: Kann man das so lassen oder sollte ich meine entsprechenden Änderungen revertieren?
Das stört mich auch. Liegt aber vermutlich weniger am Place Node sondern daran, dass die Rules nicht so abgestimmt sind, dass bei bestimmten Zoom-Leveln nicht mehrere administrative Namen zugleich erscheinen.
Dann hast beim Rendern ne “entweder Admin-Boundary oder place-Node” Regel. Da musste dann bei jedem place= Node prüfen, ob es eine passende (wie geht der Link zwischen place=abc und admin_level=xyz in jedem Land der Welt?) Boundary Relation drumrum gibt. Und die Point in Polygon Prüfung ist extrem aufwendig.
Du hast das place-tag an das Residential gehängt. Ich habe aber die ganze Zeit von Grenzrelationen gesprochen. Nun gibt es aber für Berwangen und Kirchardt als Ortsteil und Bockschaft keine Trennung in Form einer Grenze, die man dafür verwenden könnte.
Ich halte nichts davon, den place-Tag an das Residential zu hängen, da sich das Problem der doppelten Namen dadurch nur verschieben würde.
Ich möchte ganz im Gegenteil erreichen, dass der place-Tag dort, wo es möglich ist, gänzlich verschwindet. Alle dort vorhandene Informationen beziehen sich auf die gesamte Fläche und könnten daher bei der Grenzrelation stehen - bloss der verd… Name ist nicht zu kontrollieren.
Zudem ist mir beim Testen deines Problemes aufgefallen, dass Mapnik auch die Grenzrelation nicht sauber darstellt, wenn dort place=* drinsteht. Der Name wird nicht ausgegeben. Aber place=* hat mMn eh nichts im Grenzpolygon zu suchen. WAS es ist (Stadt, Ortsteil, Stadtteil, Bezirk, …) wird ja durch das Adminlevel ausgedrückt.
Gruss
walter
p.s. ich ahne schon das Ergebnis: Keiner ist Happy aber alles bleibt so wie es war.
Stimmt - obwohl viw meinte, dass es einfach wäre.
Daher ja auch mein Vorschlag:
- Place-Daten in die Grenzrelation (ohne Place-Tag!)
- Umwandlung des alten Place-Nodes in einen ungetaggten Node
und diesen als Member “label” mit in die Grenzrelation rein. (*)
Damit ist nichts redundant und der Renderer braucht keinerlei spatialen Berechnungen zu machen “ob da noch ein Place drin ist”.
Gruss
walter
*) warum wird eigentlich in vielen Grenzrelationen von größeren Einheiten das admin_center toleriert und auch gepflegt? Das ist doch das Selbe in Grün, oder?
Hier ein Beispiel, dass es nicht unbedingt erforderlich ist, den Node für den Renderer irgendwohin zu schieben (und dann in der Großstadt nicht mehr zu finden
http://opentopomap.org/map.html#49.46210|11.10855|11
Es wird dabei eine Stelle gesucht, wo die Datendichte gering und die Zentralität groß ist (je nach Zoomstufe).
Klasse gelöst! geht doch!
Gruß
walter
Das ist zumindest unser Ziel. Bis jetzt ist’s sehr profan gelöst: Für jede Zoomstufe verschieben wir das Label um einen festen Wert nach rechts oben. Bei einer Großstadt mehr als bei einem Dorf. (siehe Github)
Das kann natürlich jederzeit auch in die Hose gehen, aber es liefert trotzdem bereits bessere Ergebnisse als ohne Verschiebung.
Die automatische Platzierung mit Verdrängung und Analysierung des Hintergrunds wird derzeit als Bachelorarbeit behandelt.
Positionslinks gingen ja schon seit einigen Tagen aber gerade hab ich noch einen Cookie-Bug beseitigt. War ein Session-Cookie (*) obwohl er natürlich länger “leben” sollte. 7 Tage sind wohl genug.
*) wird beim Verlassen des Browsers gelöscht.