Das ist eine gelungene Zusammenfassung der Handlungsoptionen.
Bei der Generalüberholung “meines” Landkreises hatte ich häufig 1) in 2) geändert, das Beispiel “Baunatal” aber nicht, weil tatsächliche geschlossene Siedlungsfläche - und eine bessere Sortierung/Differenzierung ist mir seitdem auch nicht eingefallen.
place=municipality (+ role=label) ist imho eine ungefährliche Angelegenheit, kann Datennutzer nämlich ignorieren ODER auswerten, bei place=town/etc. sieht das schon anders aus, derartigen “Mapper-Vorgaben” kann sich ein Auswerter schwer entziehen. Im Sinne von “freien, offenen” Daten spricht insofern viel für 2) + 3)
Die gemeindebezogenen place-Nodes in D stammen afaik aus einem Uralt-Import (vor den Grenzrelationen), was wohl Teil der ganzen Problematik ist.
Wobei der letztgenannte sich dann eher mit dem Rendern der Bezeichnungen an den Grenzrelationen befasste und mit der Einschätzung geschlossen wurde, dass admin levels 7 und 8 zu kleinteilig seien und außerdem municipality doppelten. Müsste man nochmal ausdrücklich einen eröffnen, municipality zu rendern, oder?
Die administrative boundary für Erftstadt hat - soweit ich sehe- weder einen place node noch ein label. Das macht es tatsächlich schwierig, den Ortsnamen an einer bestimmten Stelle einzutragen.
Ich bin fast versucht einen Tag place=label zu fordern, da die Aufgabe der hier diskutierten Nodes die Platzierung des Namens und sonst nichts zu sein scheint.
Der Node gehört auf jeden Fall mit der Rolle label in die admin-Relation.
Wenn es Konsens wäre, dass die Beschriftung eines admin-Objektes zwingend entweder aus der admin-Fläche oder aus dem Label in der Relation erzeugt wird, wäre der Spuk mit nicht mehr zu findenden Namen bald vorbei.
Das automatische Label für Dessau-Roßlau z.B. käme etwa in die Mitte der beiden (vorherigen) Städte, das für Dessau in etwa dahin, wo jetzt der place-Node für Dessau-Roßlau sitzt, Roßlau ist auf jeden Fall Kandidat für einen expliziten label-Node, da das Stadtzentrum am Südrand des Gebietes liegt.
Nachfrage:
**Erftstadt **ist als place=municipality und als label für die adm. Grenze eingetragen und erscheint in keiner Karte. Zum Vergleich: **Rodgau **in Hessen ist auch als place=municipality und label eingetragen, erscheint aber auf Karten in kleineren Maßstäben (ab 2km).
Warum ist das so?
Eine technische Feinheit in OSM, die ich nicht kenne?
Oder eine Feinheit beim rendern, die ich nicht beeinflussen kann?
Einen Link kann ich nicht bieten, aber:
Start mit: https://openstreetmap.de/karte/
Eingabe Rodgau, Suchen.
Zwei-/dreimal rauszoomen (-) und der Name Rodgau erscheint auf der Karte.
Die gleiche Vorgehensweise funktioniert bei Erftstadt nicht.
Danke für die Links. Freut mich das jemand meine Beobachtung bestätigt. Wobei ich beobachte, das der Maßstab, ab dem der Name Rodgau auftaucht, variiert. Aber Erftstadt funktioniert gar nicht. Ist der Name zu lang- drei Buchstaben zuviel? Rödermark (9 Buchstaben, direkt neben Rodgau) funktioniert doch auch. Ähnlich wie Erftstadt funktioniert die Sache in Blankenfelde-Mahlow (bei Berlin) nicht.
Ich kann auch die Beobachtungen bzgl. Rodgau (sichtbar in Zoom 12 auf osm.de) und Erftstadt (nicht sichrbar) bestätigen. Generell ist zu sagen das solche municipality-Namen auf osm.org nach wie vor nicht gerendert werden, sondern nur (teilweise) auf osm.de. Man müsste die osm.de Entwickler fragen welche Voraussetzungen es geben muss, dass die Namen solcher Gemeinden auf der Karte angezeigt wird.
Meine Vermutung ist, dass dazu ein loser place=municapility nicht reicht, sondern es eher davon abhängt ob es in einer Gemeinde-Relation nodes mit role=label oder admin_centre gibt und an deren Stelle bei bestimmten Zoom-Stufen dann der Name der Relation an deren Stelle gerendert wird.
Beides wäre zwar auch bei Erftstadt vorhanden, vielleicht gibt es da aber irgendeine Verdrängung durch einen andere Beschriftung auf der Karte und wird deshalb nicht dargestellt.
Danke Jo, ich habe alles zu dem Thema, von 2011 bis heute, gelesen, und war verblüfft, das es in 10 Jahren nicht gelungen ist, eine Lösung für das Problem zu finden. Mir dünkt auch (erster Eindruck), dass die Mapper und die Renderer nicht oder zu wenig miteinander kommunizieren. Täuscht dieser Eindruck? Ich fand jedenfalls keinen Input von den Rendern und keinen Ansprechpartner. Ich bleibe aber am Ball und melde mich im neuen Forum, wenn ich mehr weiß.
Kennst Du einen osm.de Entwickler? Was ist das für ein Völkchen - lesen die auch dieses Forum oder sind die in anderen Sphären?
Ich hatte zuerst auch admin_centre im Verdacht, konnte aber keine Belege finden. Ich werde ein wenig herumexperimentieren und ggf. wieder berichten.
Es gibt inzwischen eine Begründung warum Rodgau in Zooms <=12 auf osm.de gerendert wird: Die Kacheln in Zooms <=12 auf osm.de werden nicht aktuell gehalten. Z.b. jene von Rodgau ist von Juli 2020. Und damals war Rodgau noch als place=town in der OSM und wurde daher gerendert.
…