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

Ich gebe dir uneingeschränkt recht, dass meine Vorgehensweise, besonders auch was die zeitlichen Abstände angeht, rabiat ist. Sicherlich wird mich da zu Recht auch noch schärfere Kritik treffen.

Andererseits wird dieses Problem schon länger diskutiert, und das, was ich geschrieben habe, verdeutlicht eigentlich nur noch einmal, was bereits im Wiki (als Übersetzung aus dem Englischen) steht, ohne neue Empfehlungen zu machen. Im übrigen stimme ich dir voll zu, dass der municipality-Tag der Schlüssel zur Lösung ist. Werde mich bei Gelegenheit mal der Übersetzung widmen. Das Entscheidende ist aber doch, dass er mal gerendert wird, damit man ihn auch gerne benutzt. Vielleicht ist es gar nicht so ein großes Ding.

das “Zentrum” des place sollte das Zentrum der Siedlung sein, und nicht des Verwaltungsgebiets. Dazu ist man sich einig hätte ich gedacht? Auch dass “Zentrum” kulturell verstanden wird, und nicht das mathematische Flächenzentrum (Schwerpunkt) angeben soll.

Ich habe mal nachgesehen, und in der Tat gibt es mitten in der Pampa nodes mit place=town für solche Fälle, z.B. hier: https://www.openstreetmap.org/node/240054451

den tag place=town würde ich wegmachen, weil es eine solche “town” nicht gibt, population Angaben auf einem solchen Node sind auch sinnlos, die gehören m.E. an das Gebiet (wo sie auch schon sind): https://www.openstreetmap.org/relation/2779017
Hier ist der place=town angebracht: https://www.openstreetmap.org/node/275681751 das ist aber verwaltungstechnisch nur ein Stadtteil von Albstadt.
Interessanterweise heißt der Ort nur “Ebingen” wobei im Sprachgebrauch im weiteren Umland eher von “Albstadt-Ebingen” die Rede ist, so heißen in OSM aber nur die Bahnhöfe.
Weiters ist der Ortsteil Tailfingen eine town. https://www.openstreetmap.org/node/246040682

Die beiden towns die Siedlungen sind finde ich ok, aber eine dritte town, die es nur auf dem Papier gibt, und die sich eigentlich aus diesen und anderen Teilen zusammensetzt, sollte es in “place” nicht geben.

Ich finde es ein wenig unübersichtlich, dass parallel in 2 Topics genau dasselbe Thema diskutiert wird, verfolge es aber trotzdem mit großem Interesse :wink: … mir ist im Laufe der Diskussion folgendes aufgefallen:

Die Unterscheidung von echten (gewachsenen) Ortschaften = city, town, village und unechten (reinen Verwaltungs-) Ortschaften = municipality ist m.E. eher willkürlicher Natur. Jede gewachsene Ortschaft ist ebenso (eine/mehrere/Teil_einer) municipality wie eine durch Verwaltungsakt entstandene Ortschaft. Nahezu jede größere Stadt in Deutschland ist eine municipality und im Laufe der Jahrhunderte aus vielen kleinen Dörfern zusammengewachsen. Man wird nie sauber trennen können, welche Stadt heute schon eine “town” oder gar “city” sein darf und welche ihr Dasein als “municipality” fristen muss.

Erftstadt ist ganz offiziell eine Stadt, hat eine gemeinsame Postleitzahl für alle Ortsteile und Liblar oder Lechenich (ehemals eigenständige Städte) sind heute offiziell Stadtteile von Erftstadt - auf dem Ortsschild steht Liblar bzw. Lechenich / Stadt Erftstadt / Rhein-Erft-Kreis. Auch wenn die Stadtteile von Erftstadt heute weit auseinanderliegen, kann das in wenigen Jahren schon anders sein. Warum Erftstadt also nicht eine place=town node geben …??.. die de:wiki Regel, dass fusionierten Gemeinden kein place-node zusteht, gibt es in der englische wiki nicht … eine deutsche Sonderregelung.

Wenn man argumentiert, dass Erftstadt keine “echte” Stadt (bestehend aus x physisch vorhandenen Stadtteilen) ist, sondern nur ein administrative Gebilde = municipality, dann ist es OTG nicht identifizierbar und kann daher eigentlich auch keinen place node erhalten. Will man es trotzdem machen, müsste man konsequenterweise allen municipalities einen place node verpassen. Dann hätte eine “echte” Stadt einen place=town node und zusätzlich einen place=municipality node.

Das ist sicher nicht erwünscht, also müsste es eine nachvollziehbare Regel geben, die einen place=municipality Tag für Verwaltungseinheiten rechtfertigt. Eine derartige Regel ist aber wegen der Vielzahl an unterschiedlichen Gegebenheiten kaum zu erstellen. Das einzige klare Kriterium wäre vermutlich der Ortsname. Wenn bei einer Zusammenlegungsaktion für das neu entstandene administrative Gebilde ein bis dato nicht existierender Name erfunden wird (Beispiel Erftstadt), dann könnte dieses Gebilde den place=municipality Tag bekommen.

Das würde aber auch auf Wuppertal zutreffen, auch wenn dieser Name für den administrativ erzeugten Ort schon 1930 eingeführt wurde, es sei denn, man würde für die Zeitschiene ein Limit als Zusatzregel formulieren. Oder Baunatal, bei dem JoCassel, der sich bereits intensiv mit dem Thema beschäftigt hat, als Kriterium für das erteilte place=town Tag die mittlerweile ziemlich geschlossene Bebauung angesetzt hat.

Also würde die Bedingung für place=municipality dann lauten: Ein bis dato nicht existierender Name und keine geschlossene Bebauung und nicht älter als x Jahre.

Städte wie Villingen-Schwenningen oder Seeheim-Jugenheim könnten dann immer noch kein place=town Tag bekommen, da jeweils beide Orte existieren und nicht zusammengewachsen sind. Also müsste man die Verwaltungseinheit mit dem Doppelnamen wieder als place=municipality taggen oder eine weitere Ausnahmeregelung fomulieren, z.B. für Orte mit Doppelnamen.

Zum Schluss kommt man zu einem Regelwerk, das kaum noch durchschaubar ist. Da empfinde ich die aktuell weitgehend angewandte Praxis, auch diese administrativen entstandenen Städte und Gemeinden einfach als place=town zu taggen und die Ortsteile als place=suburb, als das kleinere Übel. Oder man formuliert keine Regel und entscheidet einfach nach örtlichen Gegebenheiten und Bauchgefühl …

wie schon anderswo gelegentlich erwähnt, m.E. braucht man keine place Objekte für Verwaltungseinheiten. Dafür haben wir boundary=administrative und admin_level. Ich würde place=municipality, province, borrough, region, state, country etc. alle deprecaten.

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