Hamburg mitten im Meer

Kommt drauf an. :wink:
Bei Flächen wie Wald, Wüste etc. ist es im Prinzip egal wo der Name steht, da kann man automatisch ausrichten
lassen. Bei Place-Polygonen sollte der Name im Stadtzentrum stehen. Wobei die Lösung mit dem place-Node und diesen
als Admin-Centre dem boundary-Poly zuzuordnen ja auch zufriedenstellend ist.

Chris

Hallo Mapper

Ich möchte die Fragestellung noch mal auf den Kern bringen:

Ist es “richtig” das Hamburg nur einen Admin Level 4 benötigt?
Angesichts den Tatsache das das Bundesland “Hamburg” aus Hamburg und der exclave “Neuwerk” besteht kann diese Aussage in meinen Augen zumindest geografisch nicht mehr stimmen.
Müssen wir Hamburg(Stadtgebiet)mit Admin-Level 6 und Neuwerk mit Admin-Level 10 anlegen?
Die beiden bestehende Hamburg Relationen haben einmal Neuwerk und einmal das Naturschutzgebiet eingeschlossen. Beide sind mit Admin Level 4 getagt. Allein diese Tatsache ist unschlüssig.

ludwich

Nahmd,

Nein, kommt nicht drauf an.

Die Frage bezog sich auf den Ort, wo der Name eines Polygons gerendert wird. Und der sollte in jedem Fall aus den bereits genannten Gründen automatisch bestimmt werden.

Ein Ortszentrum ist ein eigenes Feature. Das sollte selbstverständlich in ein Admin-Flächenfeature aufgenommen werden, das aber, aber weil es logisch dazugehört (das definierte Zentrum des Admin-Bereiches ist), und nicht, weil das die definierte Position des Labels werden soll. Denn gerade das Ortszentrum ist meist voller POIs und kleiner Straßen, die Platz für Straßennamen brauchen - da kann es durchaus besser sein, das Label etwas vom Ortszentrum wegzuschieben, natürlich abhängig von der Auflösung/Zoom. Und das ist wiederum die Aufgabe für einen Placement-Algorithmus.

Gruß Wolf

@ Netzwolf

Erst einmal Danke für Deine kritische Auseinandersetzung.

Ich bin davon ausgegangen, dass Multipolynome in der Regel nicht für kleine Objekte eingesetzt werden. Bei meinem Posting bezog sich das Ganze (und das habe ich leider nicht dazu geschrieben) auf administrative Objekte, bei denen ein “place” auch dann existiert, wenn es die zugehörige Grenze dazu als Multipolygon gibt. Dabei hängen an diesem place sehr viele Infos, die auch für die Grenze gleichermaßen gelten.

Und dabei ergeben sich die genannten Probleme - insbesondere dass der Nane zweimal gerendert wird und dass man beim Heranzoomen an die Beschriftung des Flächenobjektes nichts zum Editieren findet. Wenn man hier den place als Member mit der Rolle “label” in die Multipolygon Grenzrelation aufnimmt, könnte das Zweitrendern der Grenze als Flächenobjekt vermieden werden. Und man fände beim Heranzoomen einen Punkt zum Editieren. In diesem Falle ist das Rendern am Ort des Place nicht meine Erfindung, sondern existiert schon.

Tag,

das Problem mit doppelten Tags liegt nicht erst bei den Renderern, sondern schon beim Einspielen der Datenbank. Die meisten von uns verwenden osm2pgsql. Und das hat die Eigenart, dass es Multipolygone in einzelne Polygone auflöst, die lediglich anhand ihrer Id noch als was zusammengehöriges erkannt werden können. So entstehen dann aus der Relation 2114212 für München zwei Polygone:

=> select osm_id,tags from osm_polygon where osm_id=-2114212;
  osm_id  |                                          tags                                           
----------+-----------------------------------------------------------------------------------------
 -2114212 | "name"=>"München", "place"=>"city", "name:ru"=>"Мюнхен", "way_area"=>"697671029.217790"
 -2114212 | "name"=>"München", "place"=>"city", "name:ru"=>"Мюнхен", "way_area"=>"25271.444000"
(2 rows)

Und die winzige Exklave ist dann die Stelle, wo z.B. die Radkarte den Ortsnamen hinschreibt.

Bisher hab ich mir immer damit geholfen, dass ich place-polygone ignoriere, wenn in ihrem inneren bereits ein place-node liegt, aber das scheitert bei Exklaven, weil die haben ja nicht den node. Ausserdem war das früher kein ernsthaftes Problem, weil die ganzen grossen place-Multipolygone erst im Laufe des April 2012 entstanden.

Der eigentlich richtigere Ansatz wäre, schon beim Abfragen der Datenbank diese umgewandelten MPs zu erkennen und z.B. den größten davon zum Rendern auszuwählen. Aber da fehlt mir auch noch eine Idee…

Grüße, Max

eventuell so: absteigend nach Flächengröße sortieren und immer nur die erste Fläche nehmen.

Gruss
walter