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:
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)
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)
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 … (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?
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:
village im village … … 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).
Höchstens, wenn man sich municipality zusätzlich für den Notfall als bewusst schwammigen generic place-tag offenhalten möchte, der auch mal keine direkte Entsprechung in einer Grenzrelation haben könnte. Da habe ich jetzt zwar keinen konkreten Fall im Hinterkopf, könnte mir das angesichts der bisherigen Erörterungen aber vorstellen.
Diese vielfältigen konstruktiven Erörterungen lese ich übrigens gerade angeregt und mit großem Interesse, scheine mich nun aber zunächst etwas weiterbilden zu müssen, bevor ich wieder dazu beitragen kann…
Wetter ist bescheiden und wirkliche Proteste gegen municipality nicht zu vernehmen,
daher habe ich mir mal Zeit genommen, um (m)ein Konzept als aufbohren von https://wiki.openstreetmap.org/wiki/DE:Tag:place%3Dmunicipality
in meinem Benutzernamnsraum auszuformulieren:
Mapper können so was wie Stricharten, Farben, Strichstärken, Kartensymbole, Zeichenreihenfolge und Position von Beschriftungen nicht “vorsehen”, das kann gar nicht gehen weil sie ja nicht wissen, was man darstellt und mit welchem Ausschnitt, und was man sonst noch darstellen will, und wie etc.
Das ganze “label”-tagging ist sinnfrei, und wird daher zurecht ignoriert von carto. Was durchaus Sinn macht (m.E.) ist, einen zentralen Punkt anzugeben, der Name “label” ist dafür aber fehlgeleitet.
da hatte ich mich wohl missverständlich ausgedrückt, klar gibt es einen Verwaltungsakt und ist es verwaltungstechnisch bzw. administrativ völlig unstrittig, dass das Gebiet jetzt gemeinsam unter dem Namen “Dessau-Roßlau” verwaltet wird. Und dass die deutsche Wikipedia nichts anderes anerkennen will wundert mich auch nicht im geringsten, bei OSM haben wir aber andere Kriterien. Für uns ist es durchaus relevant, was die Leute vor Ort sagen, und ob sie denken, Dessau wäre ein Stadtteil oder eine Stadt.
“Dessau-Roßlau” wäre nach dieser Lesart nicht Dessau übergeordnet, sondern eine Beschreibung in einem anderen System/hinsichtlich anderer Kategorien. Dessau-Roßlau ist eine kreisfreie Stadt, eine Verwaltungseinheit, das durch boundary=administrative abgegrenzte Gebiet, Dessau dagegen eine Stadt unter siedlungsgeographischen Kriterien, unabhängig vom verwaltungsrechtlichen Status.
Ich hab mir das mal unter https://osm-boundaries.com/ angeschaut (Permalink klappt anscheinend noch nicht…)
Ich verstehe nicht, warum Dessau AL=9 hat, Roßlau AL=9 hat, dann z.B. Großkühnau ein AL=9 hat, obwohl Großkühnau als AL=9 eine Teilfläche von Dessau auch AL=9 ist…
Ja, den gibt es schon (in der Dokumentation aus gutem Grund als stub gekennzeichnet) - will ja nicht sinnfrei neue Räder erfinden.
Dass es auf einem deutschen admin_level=8 Gemeindegebiet place=town + place=village + place=hamlet (place=city wohl eher selten) gibt ist logisch - daran ändert sich genau 0.
Egal ob der Gemeinde label-Node als municipality oder (nur zwecks Darstellung) als town/village daherkommt - völlig wurst für place-Einordnung der Gemeinde-Ortsteile.
*place * ist ein Chamäleon und wird für die verschiedensten Objekte genutzt (continent, square etc. etc.), u.a. von municipality aufwärts auch verwaltungstechnisch.
Unser Problem hier ist, dass *place * von *farm *etc. bis hinauf zu *city *siedlungsgeografisch orientiert ist, viele Verwaltungseinheiten aber auch gefunden bzw. beschriftet werden sollen, und das nicht nur in winziger Schrift an der Grenzlinie. Vor allem in niedrigen Zoomleveln sollten die Gebietsnamen z.B. der Bundesländer schon prominent erscheinen. Dafür wird *place *auch benutzt.
Dummerweise gibt es aber auch die Verwaltungsverbünde (in DE auf AL7), bei denen es im Gegensatz zu den Verbundgemeinden auf AL8 idR nicht erwünscht ist, dass sie groß auf der Karte auftauchen.
Die Rolle label in Relationen sehe ich vor allem als Hilfe für den Renderer, wo er die Beschriftung hinsetzen soll.
dafür braucht man aber kein neues tagging, dafür ist bereits alles in der db, nämlich der Name in Verbindung mit einem admin_level und boundary=administrative. Wie groß und wo das dargestellt wird, (wenn überhaupt), das entscheiden die Style-Menschen, und mit denen müsste man reden wenn einem noch wichtige labels fehlen. Ein zusätzlicher place-tag ist dafür nicht erforderlich. Früher wurden übrigens solche Verwaltungsflächennamen schon mal gerendert von “mapnik”, d.h. es war wohl eine bewusste Entscheidung, das nicht mehr zu tun.
Nominatim findet die Orte sowieso, egal ob place oder boundary=administrative
und zusätzlich wird auf die Wichtigkeit eines “well-placed” place tag hingewiesen, insofern erfüllt der place-tag also durchaus seinen Zweck (auch wenn man über die Notwendigkeit unterschiedlicher Meinung sein kann).
Aktuell sind für alle möglichen Örtlichkeiten vom Aussiedlerhof bis zur Metropole place-tags vorhanden, die gerendert werden, mit Ausnahme der hier detailliert diskutierten Gebietsreform-Gemeinden … dann ist für mich klar, dass da ein entsprechendes Tag fehlt. Ansonsten könnte man alle anderen auch abschaffen und auf die Darstellung der Ortsnamen ganz verzichten.
Nachdem du vorgelegt hast, muss ich nun doch trotz nicht abgeschlossener Weiterbildung mit meinen Ideen rausrücken, damit wir nicht parallel aneinander vorbeiarbeiten.
zu 1) da war ich ja vor allem in Ehrfurcht erstarrt - du kannst ja Overpass, und dann auch noch mit CSS…
zu 2) Frage -die wollte ich mir eigtl. selbst beantworten, jetzt aber nicht mehr geschafft: heißt dass, wenn man place in die Relation einbindet, wird es auch dann nicht ausgewertet, wenn es das ohne Einbindung würde, oder was meinst du genau?
zu 3) das habe ich nämlich (zwar Overpass-unterstützt, aber mehr oder weniger händisch= gemacht (“Suche municipality in Germany” und dann durchgekramt) und auch im Namespace, wie du mir rietest, ein Zwischenresümee -mit dem Ziel, das Ganze als Renderingsache anzugehen und international zu betrachten- auf Englisch formuliert. Ist aber reichlich verquast geworden. https://wiki.openstreetmap.org/wiki/User:Alfons234/Municipality Könnt ja mal sehen, interessant ist dabei, wenn überhaupt, dann der untere Abschnitt…
(nur zur Auflockerung, ist nicht ernst gemeint!).
… 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 …
… geht mir nicht anders - habe mich die letzten 2 Tage mit kaum was anderem beschäftigt, weil ich das Thema mege interessant finde.