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

Zur Unterscheidung zwischen Grenzrelation und place gab es hier schon Diskussionen. Zum folgenden Aspekt habe ich aber nichts gefunden:
Auf dem Land gibt es zunehmend verwaltungstechnisch zusammengelegte Orte, die die Bezeichnung “Stadt” tragen.
Zum Teil finden sich nun place=town Nodes ungefähr an den geographischen Mittelpunkten dieser Verwaltungseinheiten. Ich halte das nicht unbedingt für sinnvoll, zumal place=town auch von Routern ausgelesen wird.

Möglicherweise sinnvoll (Salzgitter): Node an einer zentralen Autobahnabfahrt https://www.openstreetmap.org/node/129992313
Fragwürdig (Oebisfelde-Weferlingen): Node fernab der beiden Stadtzentren auf einem Acker https://www.openstreetmap.org/node/9364077283,

a) Wäre es sinnvoll, die (deutsche) Wikiseite dahingehend zu ergänzen, dass ein Node place=town ausdrücklich nur für urbane Stadtzentren, wo sich die entsprechende Infrastruktur findet, verwendet wird?
b) Um dem Bedürfnis nachzukommen, dass ein "Stadt"name wie Oebisfelde-Weferlingen in der Standardansicht gerendert wird: kann dieser dann als place=municipality Node eingetragen werden?

Wäre es nicht konsequent wenn gar kein place= node da wäre? Also wenn die Argumentation ist das Router das auswerten sollte keiner da sein.

Dann sollte es lediglich einen node geben der als Label für die Grenzrelation dient oder?

Flo

Sowa sgibt es bei mir in der gegend nicht aber mitten auf einem Acker finde ich sollte ein Node place=town nicht sein.

Vieleicht wäre es sinnvoll bei zusammengelegten Gemeinden die nun als Stadt gelten den Node in die Gemeinde ans Rathaus zu setzen wo sich die für alle dazugehörenden Ortsteile zuständige verwalltung befindet.

Salzgitter:
admin_center-Node (Vewaltungssitz) an der Autobahnabfahrt?-)
würde den zum Rathaus verschieben und sein Tagging mal entschlacken insb. hinsichtlich Dopplungen zur Grenzrelation.

Oebisfelde-Weferlingen:
das ist nicht kreisfrei, insofern eine ganz normale Gemeinde, die halt den Titel “Stadt” führt, gibt es in meiner Region auch.
Ein label-Node ist schon ok, aber statt place=town dort place=municipality (wird von carto nicht gerendert).

a) ist hier meiner Einschätzung nach Konsens.

Das ist auch kaputt. Hier in der Gegend gibt es zig so Zusammengesetzte Gemeinden die alle ja mehr oder minder Eigenständig und Stolz drauf sind. Wenn du da den Place auf das Rathaus schiebst ist es kaputt.

Das Problem ist eigentlich eher das wir nirgends defininiert haben was der place= node eigentlich heisst. Gehört der Node auf das Rathaus? In die Innenstadt? In die Bebauung? Das Wiki sagt das Schwamming “In the center of …” und das kann man ja auf die Geographische Ausdehnung des Stadtgebietes beziehen.

Nur so als Beispiel

“Herzebrock-Clarholz” - Komplett disjunkte Städte Herzebrock, Clarholz und Möhler. Hier liegt der node für Herzebrock-Clarholz halt in der Mitte. Also in der Mitte der Geographischen Ausdehnung des Stadtgebietes - aber eben nicht in der Bebauung.

“Rheda-Wiedenbrück” - Gebildet aus “Rheda”, “Wiedenbrück”, “Lintel”,“St. Vit”

Hier ist es nicht ganz so hart weil die Stadtteile Rheda und Wiedenbrück ineinander übergehen (Getrennt durch die A2) so das es nicht so auffällt das der Node mehr oder weniger willkürlich in der Mitte liegt.

Ich halte das mappen als place=town schon für richtig. Eine Navigation die das als “Zielpunkt” ungesehen anbietet ist halt kaputt. In “Hamburg” kommst du bei “Nach Hamburg routen” auch an keinen wirklich spezifischen ort.

Flo

https://www.openstreetmap.org/node/25271757
als label-Node mit place=municipality völlig ok
aber auch hier gilt: bitte entschlacken und keine sinnfreien Dopplungen (der wikimedia-Tags) zur Grenzrelation.

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.