place=town für zusammengelegte Städte??

Das finde ich schon konsequent. (Dass das mir eigentlich sehr sympathische municipality immer nur eine Kompromisslösung sein könnte, hat HeRo ja überzeugend dargelegt.)

Würdest du es dann als reines Problem des Renderers ansehen, dass die Namen bestimmter Verbundgemeinden nicht angemessen prominent als Label auftauchen (finde ich ein absolut berechtigtes Anliegen, das leider die anstößigen place=town nodes provoziert)? Und wenn ja, in welche Richtung könnte hier ein Lösungsweg gehen? In https://github.com/gravitystorm/openstreetmap-carto/issues/4004 wurde ja der Ansatz über die boundaries erfolglos versucht, wenn ich es richtig verstanden habe.

Meiner Meinung nach beeinflusst in diesem Bereich OpenStreetMap Carto das Mapping ungünstig, indem es place und admin Flächen ignoriert, und keine Labels dafür rendert. Die Namen von Verbundgemeinden sollten durchaus gerendert werden, allerdings ohne dass man nichtexistente town nodes setzen muss.
Die Sache ist nicht ganz einfach, denn wenn man labels aus admin Flächen rendert resultieren jede Menge doppelte Labels (für place und für admin), das zu verhindern ist ein bisschen aufwendig.

Wuppertal ist admin_level=6 - andere Liga, ich rede hier nur von kreisangehörigen admin_level=8 Gemeinden, weil die in schöner Regelmäßigkeit hier im Forum als Problem aufploppen.

sehe place=municipality als den Gemeinde-Regelfall und “Baunatal” als seltene Ausnahme.

… was an der “Geisterstadt im Irgendwo”-Problematik aber 0 ändert.

Aktuelles Beispiel die Gemeinde Staufenberg (kein “Stadt”-Titel, das spielt meist gar keine Rolle)
https://www.openstreetmap.org/node/416362121/history

interessant ist die Versionsgeschichte

  • erstellt vor 12 Jahren mit place=village - damals gab es noch keine Gemeinde-Grenzrelationen
  • vor 3 Jahren von einem Kollegen entschlackt und korrekt als place=municipality + role=label getaggt
  • vor 2 Wochen zum place=town befördert CS-Kommentar “Gemeindenamen hinzugefügt” gemeint ist wohl “… auf der Standardkarte dick sichtbar gemacht”

Habe es jetzt mal mit note-Tag versucht …

Hier noch ein Beispiel, wo durch Zusammenlegung eine Stadt verschwunden ist:
https://www.openstreetmap.org/node/240061254

Dessau gibt es nicht mehr in OpenStreetMap, nicht mal mehr als old_name nur noch als admin_level=9 Objekt, Roßlau aber schon

… hat mit den kreisangehörigen admin_level=8 Gemeinden (um die es mir primär geht) nix zu tun, aber in meinen Augen ist das rein OSM-handwerklich in mehrer Hinsicht definitiv nicht sauber gelöst.

Das mag ja korrekt sein, aber solange weder municipality noch label auf einer Karte dargestellt werden, wird man immer wieder einen “Ausweg” suchen, z.B. place=town/village. Wie will man denn einem OSM Interessierten klar machen, dass z.B. Herzebrock-Clarholz auf keiner OSM basierten Karte auftaucht? Der Deutschlandviewer https://onmaps.de/ kann das einfach. Wieso eigentlich?

Verzeiht bitte, wenn dies jetzt schlaumeierisch und Grünschnabel-mäßig rüberkommt. Aber es zeigt sich ja deutlich, dass sich immer weitere solche Beispiele finden lassen. Insofern wäre es toll, wenn diese Sache mal pragmatisch gelöst wird, auch wenn es am Ende keine 100% saubere, begriffslogisch durchgehend befriedigende Lösung ist. Es ist natürlich schwierig einen Kompromiss aus den (im Folgenden krass verkürzt wiedergegebenen) Lösungsansätzen “municipality deprecaten und nur auf Grenzrelationen setzen” und “municipality ausdrücklich im Rahmen von Grenzrelationen empfehlen” zu finden und diesen evtl. zu einem proposal zu entwickeln.

Trotzdem mal als Gedankenspiel - ich habe ja als Neuling in dieser Debatte nichts zu verlieren, drescht ruhig auf mich ein :wink: : Könnte ein solcher Kompromiss municipality als eine Art generischen place-Tag beinhalten, bei dem man nicht so genau hinschaut, ob es nun eher administrativ oder humangeographisch/OTG ist, der also die von Map_HeRo beschriebenen Unschärfen reflektiert, und bei dem man sich dann dafür einsetzt, dass er analog zu place=town gerendert wird?

(Edit: naja - sehe gerade: entspricht fast genau diesem Beitrag: https://forum.openstreetmap.org/viewtopic.php?pid=838988#p838988)

Flächen werden in OSM carto absichtlich nicht gerendert, wie im Wiki unter Key:place ausführlich beschrieben ist.

Der hier zugrunde gelegt “lack of verifiability” gilt m.E. ganz genau so für rein administrative Gebilde, die vermutlich aus eben diesem Grunde auch mit Absicht nicht gerendert werden, auch wenn sie einen place=municipality node enthalten.

Fehlerhaften Begriff ausgetauscht

Macht es denn wirklich einen Unterschied, ob so ein administrativer Konstrukt auf Ebene einer kreisfreien Stadt oder auf Gemeindeebene erzeugt wird? Der Konstrukt beim Zusammenlegen zweier Orte ist doch derselbe und die daraus resultierenden Einordnungsprobleme auch.

Ist das jetzt eine (auswertungs)technische oder soziokulturelle Frage?
vgl.
https://forum.openstreetmap.org/viewtopic.php?pid=838853#p838853
und den dortigen simplen overpass-Auswertungs-Link (nebenbei ganz ohne municipality oder label, das sind nur Auswertungs-Zusatzmöglichkeiten)

@38446: Ja … PPete2 hat die OSM-Wirrniss seinerzeit gut auf den Punkt gebracht :wink:

Naja in der OSM-Dokumentation schon.
(aber die Dessau-Roßlau Probleme fangen doch schon damit an, dass die 2 Stadtteile Dessau + Roßlau nicht gleichwertig in OSM abgebildet sind.)

ich glaube admin Flächen werden nicht gerendert weil man sonst deduplizieren müsste, seit 18 Jahren sind die Mapper es gewohnt dass sie für Ortsnamen nodes setzen müssen, daher gibt es für die meisten davon nodes, und place Flächen sind eher rar (vor allem reine place Flächen wo nicht nur der tag an ein admin polygon gehängt wurde), weil die Hauptkarte sie nicht rendert.

der lack of verifiability ist m.E. hier nur vorgeschoben, und für admin ist es erst recht kein Grund, die Grenzen werden da ja gerendert nur die Namen nicht.

Ich will dem nicht widersprechen, dazu weiß ich zuwenig über die Historie, aber die Festlegung im Wiki dazu hört sich für mich schon ziemlich verbindlich an … ohne node kein place. Ende der Diskussion :slight_smile: . Und von den admin areas werden eben auch nur die Grenzlinien gerendert, ohne place und name.

Für mich stellt sich das so dar, dass man bei den “municipality areas” auf Basis dieser grundsätzlichen Regelung ohne einen node nicht weiterkommen wird, auch wenn das programmtechnisch sicher machbar wäre.

es stimmt nicht ganz was ich oben geschrieben habe, admin Namen werden gerendert, allerdings entlang der Grenzen mit kleinem offset und nicht als Punktlabel in der Mitte.

ja, da gibt es auch einen weiteren virtuellen place, sogar city, und ein Beispiel warum carto place Flächen nicht rendern will
https://www.openstreetmap.org/relation/62526

Wäre es dann nicht wirklich das Pragmatischste sich darum zu bemühen, wie municipality gerendert werden kann (nach Betrachtung der weiteren Implikationen, Stichwort Dopplungen mit town)? Dann müsste ja an den Vereinbarungen zum Tagging nichts geändert werden und man könnte auf die falsche Verwendung von town verzichten.
Und die Diskussion dazu müsste dann wahrscheinlich international (direkt auf GitHub?) erfolgen?

@dieterdreist: mit “Pragmatischste” will ich sagen - ja, es ist nicht ganz konsequent, aber der “saubere” Weg ist aufgrund der langen Zeit zu aufwendig und nicht (mehr) realistisch umzusetzen, oder?

ja, place-Tags an einer Grenzrelation, die bereits einen dezidiert gesetzten place-Node (per label eingebunden) besitzt sind logischerweise Dopplungs-Mist.

Das nächste Problem erkennt man, wenn man sich die Versionsgeschichte dieses place-Nodes anschaut:
https://www.openstreetmap.org/node/240061254/history
Der startete mal als “Dessau”, und wurde irgendwann zu “Dessau-Roßlau”, aber ohne das einer neuer “Dessau” gesetzt wurde. Dessau ist aber nicht untergegangen, sondern besteht als Stadtteil - analog zu Roßlau - munter weiter.
Als place=suburb Node für “Dessau” bietet sich übrigens ein Recycling dieses alten Datenmülls an:
https://www.openstreetmap.org/node/240098523

Und die place-Nodes der Stadtbezirke gehören dann zum place=quarter abgestuft.

Ja, die carto-Render-Entscheidungen fallen nicht hier und haben internationale Implikationen…
Du musst aber bedenken, dass es, was die deutschen Gemeinden angelangt, mehrere Auswertungsmöglichkeiten gibt:

  1. Nur auf Datenbasis der al=8-Grenzrelationen - die Lage der Beschriftung erfolgt automatisiert (und nicht immer optimal)
    Das ist das, was ich hier gemacht habe https://forum.openstreetmap.org/viewtopic.php?pid=838853#p838853
    (geht natürlich, je nach Auswerterwunsch, auch ohne name:prefix)

  2. Auf Datenbasis der al=8-Grenzrelationen - die Lage der Beschriftung aus der dort (sofern vorhanden) eingebundenen label-Node-Position (carto wertet label gegenwärtig gar nicht aus)

  3. Nur auf Datenbasis der municipality-Nodes
    Problem bei 3 sind Sonderfälle wie “Baunatal” und dass Daten wie name:prefix=* wiederum nur über die Grenzrelation verfügbar sind oder am Node gedoppelt werden müssten.

Mein Gedanke/Ansatz ist da insofern ganz bescheiden: möglichst keine “Geisterstädte” in den OSM-Daten und dass eine fundierte Auswertung nach 2) möglich sein sollte.

Egal wie man es dreht und wendet, es ist ein Unding, das die Namen von real existierenden Großgemeinden in carto nicht angezeigt werden, auch wenn wir grundsätzlich nicht für den renderer taggen. Und, wie 38446 korrekt festgestellt hat, sollte eine pragmatische Lösung her. Der aktuelle Zustand (jeder macht, was er will) ist auf keinen Fall befriedigend.

Eine Lösung nur auf Basis der Grenzrelation -analog Jo Cassel Punkt 1)- halte ich angesichts der klaren Aussage “Populated places mapped as areas do not render in the openstreetmap-carto stylesheets. This is intentional …” für ausgeschlossen, da die Grenzrelation eben nur eine area beschreibt.

Eine gute, realitätsnahe und praktikable Lösung wäre m.E. die Verwendung einer place=municipality node, egal, ob diese freihändig platziert oder als label in die Gemeinde-Grenzrelation eingebunden ist. Ob bei der zuständigen Stelle erreicht werden kann, place=municipality analog place=town zukünftig zu rendern, entzieht sich meiner Kenntnis. Der Vorschlag, der ebenfalls auf Jo Cassel zurückgeht, hätte aber sicher nicht nur meine Unterstützung.

In Anbetracht der teilweise ewig langen Entscheidungsprozesse halte ich es persönlich aber auch nicht für grundlegend verwerflich, Kunstgebilde wie Erftstadt zumindet temporär als “zukünftig zusammengewachsene Städte analog Baunatal” zu betrachten und diesen administrativ entstandenen Städten einen place=town node zu verpassen, auch wenn andere und auch erfahrenere Kollegen sich dagegen aussprechen. Was heute noch nicht ist (zusammengewachsen), kann ja schon in wenigen Jahren der Fall sein. Und, wie einer meiner Chefs gerne zu sagen pflegt: Erfahrung hemmt den Fortschritt … :smiley: (nur zur Auflockerung, ist nicht ernst gemeint!).

Eine derartige temporäre Lösung würde gegen keine gültige Regel verstoßen (außer einer in die deutsche Wiki hineingemogelten Untersagung), das aktuelle Renderingproblem ad hoc lösen und könnte, sobald eine dauerhafte/umfassende Lösung für das Problem gefunden wurde, sukzessive durch das finale Tagging ersetzt werden. Davon abgesehen wird es ohnehin schon in vielen Fällen praktiziert. Also warum das nicht solange dulden, bis eine endgültige, die reale Situation korrekt abbildende Lösung gefunden ist?

Ein place=municipality Node sollte bitte, bitte(!) immer als label in die Gemeinde-Grenzrelation eingebunden sein. Das Mapper den freihändig (neu) platzieren kann ist ja gerade Sinn des role=label (Mapper kann die geeignete Beschriftungsposition oft besser einschätzen als der geistig beschränkte Renderer)

Wenn irgendwo in D entschieden wird “ist ja eigentlich (fast) wie Baunatal” hab ich damit kein Problem, es muss lokal nur municipality in town oder was auch immer geändert werden.

Mein Baunatal-Gedanke dazu schon vor 3 Jahren: Auswerter die “Baunatal” auf Basis der Grenzrelation als Gemeinde Beschriften wollen können bei Nutzung label-Position sogar den place-Node überdecken und damit Namens-Dopplungen vermeiden.
Daher ist Baunatal-place=town eben auch als label in die Gemeinde-Grenzrelation eingebunden - schlauere Lösungen hat mir seit damals niemand präsentiert;-)