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

Hallo, genau dieses Thema wurde vor gar nicht so langer Zeit in diesem Thread diskutiert:
https://forum.openstreetmap.org/viewtopic.php?id=73638

Ja, da schau her. Den habe ich beim Überfliegen der Überschriften als Erfstadt-spezifisch eingeordnet und nicht gelesen.
Dort zeichnet sich ja auch schon ab, dass mit der Variante place=municipality für solche Fälle trotz gewisser auch damit einhergehender Probleme bzw. weiteren Handlungsbedarfs hinsichtlich Rendering die meisten Diskussionsteilnehmer leben könnten. Dann würde ich demnächst mal eine Ergänzung im deutschen Wiki unternehmen.

Ich war bis jetzt der Meinung, dass es Konsens ist, den place-Node so zu setzen, dass jemand, der keine genaue Adresse hat oder sich im Ort auskennt oder ab da telefonisch geführt wird oder aus anderen Gründen nur Routing “zum Ort” braucht, an eine zentrale Kreuzung geführt wird, von der aus es weitergehen kann. Und eben nicht auf den Acker, der in der geometrischen Mitte liegt. Dann tut ein Navi, dass das als Zielpunkt anbietet, doch genau das Richtige. Woran soll es erkennen, dass der Node in diesem Fall kein Verkehrszentrum bezeichnet?

Natürlich nicht, aber in Hamburg landet man hoffentlich schon, und zwar so, dass man von da aus weiterkommt.

Nach längerer Beschäftigung mit dem Thema, und etlicher Diskussionen hier im Forum wäre ich ausdrücklich dafür,
für kreisangehörige admin_level=8 Gemeinden in Deutschland einen
place=municipality-Node - eingebunden in die Grenzrelation mit role=label - nahezulegen.

Vor Jahren schon hatte ich diese Beispielliste erabeitet
https://wiki.openstreetmap.org/wiki/DE:Gemeindegrenze#Zus.C3.A4tzliche_Relationselemente
insbesondere “Söhrewald” ist ein sehr häufiger Fall in D und analog zu “Oebisfelde-Weferlingen” zu sehen.
die Grenzrelation:
https://www.openstreetmap.org/relation/1115035
der zugeordnete place-Node (reduziert auf das Notwendigste):
https://www.openstreetmap.org/node/240116344

Habe jetzt https://wiki.openstreetmap.org/wiki/DE:Tag:place%3Dtown einfach mal Fakten geschaffen, die deinen noch viel durchdachteren Ausführungen zumindest nicht widersprechen. Auch wenn das jetzt vielleicht etwas Holterdipolter ging - hier im Forum geht es ja sonst wieder unter. Vielleicht kann man es dort ja noch verfeinern.

Sehe ich ähnlich, z.T. sitzt dort dann ja auch schon der Name der “eigentlichen” town.

Naja, das Wiki gibt ja Rathaus, Kirche etc. als Beispiele an. Das ist zwar ein bisschen schwammig, aber nicht so schwammig, dass der town-Node genau zwischen zwei Städten, die 20km auseinanderliegen, auf einem Acker sein sollte.
(Dass meine Argumentation nicht ganz konsequent ist, wenn man place=city in die Betrachtung einbezieht, ist mir bewusst, aber ich denke, dass es gute Gründe gibt, die Betrachtung von town und city auseinanderzuhalten.)
Das stört im dicht besiedelten Westfalen vielleicht nicht so sehr, aber in dünner besiedelten Regionen schon.
Insofern ist mir noch nicht ganz klar, was dich am municipality-Tag stört, der mir als eine Art Kompromiss zwischen humangeographischer und administrativer Benennung sinnvoll erscheint.

Das ist wohl wahr :wink:

mit
https://wiki.openstreetmap.org/w/index.php?title=DE%3ATag%3Aplace%3Dtown&type=revision&diff=2240723&oldid=2098585
habe ich inhaltlich keine Probleme, aber mehrere stukturelle

Bitte beachten, dass es hier um ganz zentrale Fragen/Tags geht,
und dass die DE-Seiten Mehrfachfunktionen haben:

  • Übersetzung des international gültigen EN-originals +
  • ggf. Details für D-A-CH
    Und bei Festlegungen bzw. Hinweisen für Deutschland sollte das ganz eindeutig per Zwischenüberschrift oder (gern auch penetrantes) “In Deutschland […]” klar gestellt werden

“Neben der Verwendung von boundary=administrative mit admin_level=8 […]” in D sind die Gemeindegrenzen derart vollständig in OSM erfasst, das ist in diesem Zusammenhang nicht uninteresseant.

Meine Erfahrung ist, dass gemeindebezogene place-Nodes in D nicht nur fälschlich als place=town deherkommen sondern auch mal “bescheiden” als place=village - was die Sache nicht besser macht.
Daher würde ich nicht auf “Städte” fokusieren, sondern erstmal bei
https://wiki.openstreetmap.org/wiki/DE:Key:place
ansetzen - dort ist place=municipality noch nicht einmal übersetzt …

Wenn ich so ein großes Ding angehe, dann erstmal in meinem Benutzernamensraum, die Zwischenergebnisse zur Diskussion stellen und erst wenn alle zufrieden sind in den OSM-Namensraum übernehmen - aber da bin ich wohl der Einzige :wink:

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