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”.
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.
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
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.
