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

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;-)

irgendwo einen node ins „Nichts“ zu legen zwischen den Orten die gemeinsam eine Stadt bilden, das finde ich genauso befremdlich wie irgendwo einen node zu haben mit name=Deutschland place=country. Im Prinzip wäre es also theoretisch denkbar.

Carto könnte problemlos solche Punkte selbstständig „erfinden“ indem sie Polygonnamen für sowas rendern, label nodes braucht niemand und haben mit Geodaten nichts zu tun. Sofern der Node ein Zentrum bezeichnet wie es bei Städten in der Regel der Fall ist, passt das, aber hier geht es ja gerade um den Fall dass es kein Zentrum gibt.

dass Dessau jetzt ein Stadtteil ist und keine Stadt mehr steht so in der deutschen Wikipedia, aber diese Interpretation halte ich nicht für besonders realistisch wenn man nicht nur auf die Verwaltung sieht. Dessau ist nach wie vor eine Stadt und kein Stadtteil, nur verwaltungstechnisch ist es ein Teil von Dessau-Roßlau. In 50 Jahren sieht die Lage vielleicht anders aus, momentan „gibt“ es weiterhin sowohl Dessau als auch Roßlau und zusammen gelten sie als kreisfreie Stadt (daraus folgt nicht dass sie alleine keine Städte im Sinne von place sein können).

Das denken die cartoonisten wohl auch und rendern z.B. “Brandenburg” (automatisiert) östlich Berlins, Richtung polnische Grenze, statt nördlich Berlins, wie von Mapper(n) vorgesehen.

Also in meiner Wikipedia ist der Absatz zur “Stadtgliederung” von Dessau-Roßlau mit einer behördlichen Quellenangabe versehen:
“Das Gebiet der ehem. Stadt Dessau bildet den Stadtteil Dessau mit den Stadtbezirken 01 - 21 und das Gebiet der ehem. Stadt Roßlau (Elbe) den Stadtteil Roßlau (Elbe) mit den Stadtbezirken 22 - 25.”
https://verwaltung.dessau-rosslau.de/stadt-buerger/wahlen-und-statistik/statistik/stadtgebiet.html

Was ist denn eigentlich für OSM gewonnen, wenn ein Dessau-Node als place=town (statt korrekt suburb) gemappt wird?
Soll dann das übergeordnete Dessau-Roßlau “city” werden?

@dieterdreist

Ich schätze Deine knochentrockenen Kommentare, wie z.B. diesen

bin aber in dieser Sache

anderer Meinung. Carto generiert solche Punkte nicht selbständig, mit der Begründung

und “well placed” kann eine willkürlicher gesetzer Node kaum sein. Das sollte am besten jemand machen, der mit den örtlichen Gegebenheiten vertraut ist. Natürlich gibt es einen Unterschied zwischen dem Zentrum einer “echten” Stadt mit Bebauung, Kirche, Rathaus, Marktplatz usw. und dem Zentrum einer administrativ aus mehreren Orten gebildeten Stadt, welches sich je nach lokaler Gegebenheit im Hauptort oder einer gut erreichbaren zentralen Stelle (wie z.B. im Falle Salzgitter) befinden sollte. Das letztere ist dann schon mal ein klarer Hinweis für den User, dass dieser Ort kein gewachsenes Stadtzentrum hat. Aber die Notwendigkeit auch für diesen Node ergibt sich aus dem vorher gesagten.

Und das Beharren darauf, dass eine per Administrationsakt entstandene Stadt wie Erftstadt oder Dessau-Rosslau in Wirklichkeit nicht exisitert, hilft niemand weiter. Es sind nach deutschem Recht existierende Städte, auch wenn die lokale Bevölkerung sich noch jahrzehntelang daran festklammern mag, dass der eigene Ort mit den beigeordneten nicht das geringste zu tun hat. Und wenn man die zuvor eigenständige Städte nicht zu “Suburbs” degradieren will spricht nichts dagegen, sie auch zukünftig als place=town zu taggen. Dazu Zitat Wiki:

Das impliziert, dass ich durchaus eine city in der city haben kann oder eben auch eine town in der town. Wie zum Beispiel hier praktiziert:

https://www.openstreetmap.org/node/240053255#map=15/48.2315/7.7245

village im village … :slight_smile: … mal abgesehen davon, dass die Redundanz in name= + name:de= natürlich Quatsch ist, ist das m.E. eine akzeptable Lösung, auch wenn das übergeordnete Rheinhausen kein “echtes” Dorf ist, sondern eine durch Gebietsreform entstandene Gemeinde, also eigentlich ein place=municipality führen müsste. Aber daran wird ja gerade gearbeitet …

Ich bin da absolut dabei. Wenn man irgendwo in einem durch Grenzrelation umschlossenen Gebiet eine place Node setzt, um dem Kind einen Namen zu geben (denn darum geht es bei diesem node ja primär) gibt es m.E. überhaupt keinen Grund, warum man diesen NICHT als label in die Relation einbinden sollte, oder?

Der place-Node scheint mir sinnvoll im zentralen, bebauten Bereich positioniert - statt im grünen Nirgendwo - sieht für mich aus der Ferne nachvollziehbar aus.
Den alten openGeoDB-Krempel raus, den place-Node mit role=label in die zugehörige Gemeinde-Grenzrelation einbinden und gut ist (erstmal).