place=suburb

Im Wiki steht in der Tabelle unter place zu suburb folgendes drin:

Stadtteil. Ein Teil einer städtischen/urbanen Siedlung mit eigenem Namen und Identität. Zum Beispiel:
- eingemeindete Städte und Gemeinden, welche vorher eigenstädig waren.
- eigenständige (oder verwaltungsmäßig untergeordnete) Stadtbezirke innerhalb oder in der Nähe einer Großstadt oder größeren Stadt.
- historische Gebiete von Ansiedlungen.
- Industriegebiete oder Nahererholungsgebiete mit speziellen Namen innerhalb einer Stadt.

Punkt 1 steht im Widerspruch zur Tabellenüberschrift "urbane Siedlungsgebiete" und zum englischen Wiki-Eintrag an gleicher Stelle:

A part of a town or city with a well-known name and often a distinct identity.

Bei uns waren vor 1969 auch fast alle Dörfer eigenständige Gemeinden, da sind auch noch einige als place=suburb getaggt.

Wertet Nominatim place=village aus? https://www.openstreetmap.org/search?qu … 194/8.9148 verortet die Harkemisser Straße jedenfalls in einem mehrere 100m außerhalb gelegenen isolated_dwelling, obwohl der place-Node für Harkemissen direkt daneben liegt...

bus-mt wrote:

Im Wiki steht in der Tabelle unter place zu suburb folgendes drin:

… was leider im Widerspruch zur deutschen Wikiseite des Values steht. Dort heißt es ausdrücklich, und das unterstütze ich:

* Umgekehrt sollten klar abgegrenzte Ortschaften, die Teil einer größeren Gemeinde oder Stadt sind, nicht als place=suburb sondern je nach Größe und Struktur als place=village, place=hamlet oder gegebenenfalls auch place=town getaggt werden. Als Beispiel sei hier Tübingen-Hirschau genannt. Es gehört zwar zur Stadt Tübingen wird sinnvollerweise aber als Dorf getaggt.

bus-mt wrote:

Wertet Nominatim place=village aus?

Ja.

bus-mt wrote:

verortet die Harkemisser Straße jedenfalls in einem mehrere 100m außerhalb gelegenen isolated_dwelling, obwohl der place-Node für Harkemissen direkt daneben liegt...

Das ist ein bekannter Bug in Nominatim, der dann auftritt, wenn ein isolated_dwelling nicht von einer Verwaltungsgrenze umgeben ist, und sollte nicht durch falsches Tagging geworkaroundet werden.

place=suburb sind Stadtviertel im Kontext eines zusammenhängenden Stadtgebiets, keine eingemeindeten Dörfer.

--ks

kreuzschnabel wrote:

… was leider im Widerspruch zur deutschen Wikiseite des Values steht. Dort heißt es ausdrücklich, und das unterstütze ich:

* Umgekehrt sollten klar abgegrenzte Ortschaften, die Teil einer größeren Gemeinde oder Stadt sind, nicht als place=suburb sondern je nach Größe und Struktur als place=village, place=hamlet oder gegebenenfalls auch place=town getaggt werden. Als Beispiel sei hier Tübingen-Hirschau genannt. Es gehört zwar zur Stadt Tübingen wird sinnvollerweise aber als Dorf getaggt.

+1. Das fand und finde ich immer noch überzeugend. Ein (klar abgegrenztes) Dorf ist ein Dorf, ein Weiler ist ein Weiler, egal ob sie selbstständig sind oder zu welcher Gemeinde auch immer sie gehören mögen. Für die Zugehörigkeit zu Gemeinden haben wir ja die Grenzen, die place-Werte dagegen beschreiben die Siedlung sozusagen phänomenologisch. Sieht aus „wie Dorf“? → place=village. Sieht aus „wie Stadtteil“, weil komplett mit anderen Teilen zusammengewachsen? → place=suburb.

Halte es ebenfalls für sinnvoll den place-Wert nach der Siedlungsstruktur und nicht nach der "Stadt"-Formalie zu setzen.
Mal ein Praxis-Landkreis-Beispiel aus einem Nachbarfaden,
verbunden mit der Werbung dafür, place-nodes mit den zugehörigen Gemeinde/Stadt-Grenzrelationen zu verknüpfen!

Stadt Vellmar aus 4 zusammengewachsenen place=suburb (aka "Siedlungsbrei")
http://overpass-turbo.eu/s/ESr

Ansonsten sind die Städte (im Landkreis Kassel) häufig Kleinstädte mit der Kernstadt (place=town) und externen dörflichen "Stadtteilen" (place=village).
Siehe das Beispiel Stadt Immenhausen in
https://wiki.openstreetmap.org/wiki/DE: … nselemente

Jo Cassel wrote:

verbunden mit der Werbung dafür, place-nodes mit den zugehörigen Gemeinde/Stadt-Grenzrelationen zu verknüpfen!

Dann aber die nodes so platzieren, dass sie in der admin-Relation die Rolle admin_centre oder label übernehmen können.

Ich sehe auch place (sichtbare Struktur) und admin-Relationen als unterschiedliche Hierarchien, die nur manchmal zusammenfallen (Einzelgemeinden). In BW sind die Konstrukte aus Kernstadt und eingemeindeten Dörfern rundum fast der Regelfall.

Hallo und frohes Neues,

habt ihr ein paar Beispiele? Ich wohne im Braunschweiger Umland und konnte bislang keinen Unterschied in der Darstellung von suburb und village auf carto feststellen. Z. B. bei den separierten Ortsteilen von Wolfenbüttel und anderen Dörfern. Wenn es allerdings gewünscht ist, würde ich diese entsprechend von suburb nach village ändern wollen.

Gruß
Mecki

Mecki wrote:

und konnte bislang keinen Unterschied in der Darstellung von suburb und village auf carto feststellen

Die Schriftgröße von suburb ist geringfügig größer (ist mir bei Rolfsbüttel und Hillerse aufgefallen, in ZL 12 sieht man’s noch). Gelabelt werden beide ab ZL 12, aber das hängt auch von der lokalen Detaildichte ab: Sind Namen eng beisammen, wird suburb bevorzugt, was dazu führt, dass ein Minidorf wie Fürstenau (das ich jetzt mal zum hamlet degradiert habe) eher als z.B. Wendeburg als Label in der Karte erscheint.

--ks

Ah, ich hab deine Änderung an Wendezelle gefunden. Ich weiß nur nicht ob Wendeburg nun prominenter auftauchen wird, da es nun gleichrangig mit seinen Gemeindeteilen Zweidorf und Wendezelle als village getaggt ist. Vermutlich lässt der Renderer dann auch weiterhin Wendeburg in der Darstellung ab einem bestimmten Zoomlevel aus Platzgründen weg.

Edit: Stimmt auf TL12 kann man tatsächlich einen kleinen Unterschied sehen. Dann ändere ich mal flux die separierten Ortsteile um. Das mit der größeren Darstellung von suburb finde ich auch eher nachteilig. In Wolfenbüttel z. B. sind die Neighbourhoods in der Bevölkerung allen bekannt, die offiziellen Stadtteilnamen jedoch eher weniger.

Eigentlich müsste Wendeburg als Zusammenschluss jetzt ein place=municipality sein, aber das wird im Standardstil AFAIK überhaupt nicht gelabelt. Ein bisschen Taggen für den Renderer ist also noch drin, ich geb’s zu 🙂

Man kann sich auch überlegen, ob Wendeburg mit seinen über 10k Einwohnern nicht schon place=town ist. Das hängt ja in OSM auch nicht zwingend am verwaltungsrechtlichen Status.

--ks

Habe auch gleich mal die Stadtgebiete von Braunschweig, welche keine offiziellen Stadtteile sind entsprechend ihrer Größe in quarter oder neighbourhood geändert.

kreuzschnabel wrote:

Eigentlich müsste Wendeburg als Zusammenschluss jetzt ein place=municipality sein, aber das wird im Standardstil AFAIK überhaupt nicht gelabelt. Ein bisschen Taggen für den Renderer ist also noch drin, ich geb’s zu 🙂

Man kann sich auch überlegen, ob Wendeburg mit seinen über 10k Einwohnern nicht schon place=town ist. Das hängt ja in OSM auch nicht zwingend am verwaltungsrechtlichen Status.

--ks

Also, es gibt die Gemeinde Wendeburg
https://de.wikipedia.org/wiki/de:Wendeburg
und dann den (namensgebenden) Ortsteil mit Verwaltungssitz
https://de.wikipedia.org/wiki/de:Wendeburg_(Ortsteil)

https://www.openstreetmap.org/node/78557373
sollte statt als "label" als "admin_centre" in die Gemeindegrenzrelation eingebunden sein.

Ein echtes (zuzeit nicht vorhandenes) label wäre ein (carto-unsichtbares) place=municipality, name=Wendeburg
was den Vorteil hätte, dass die OSM-Suche bei der Eingabe von "Wendeburg" auch tatsächlich die "Gemeinde Wendeburg" findet ...

Jo Cassel wrote:

Also, es gibt die Gemeinde Wendeburg

Ja, da hast du recht. 😉

Hier Wendeburg mit alles seinen erfassten Ortsteilen:

Was mir hier so auffällt (und was ich demnächst bereinigen werde):

- der Node https://www.openstreetmap.org/node/78557373 wird in der Admin-Rel als Label verwendet. prima
dieser Node enthält "unerwünschte" Tags (is_in, openGeoDB)
dieser Node enthält Tags, die für die ganze Fläche gelten, also dort hin gehören.

- der Node https://www.openstreetmap.org/node/310517785 ist das Label für Neubrück(10)
er enthält neben den obigen Tags auch noch die PLZ

- das gleiche gilt für den place-Node von Ersehof(11)

- der Perimeter der Admin-Grenze von Ersehof(11) ist als Residential erfasst: https://www.openstreetmap.org/relation/ … 74/10.3909

Dazu liegt das Grenzpolygon von Ersehof(11) "einfach nur so rum", d.h. es überlappt bestehende Grenzstücke und ist nicht in die bestehenden Grenzen "eingewoben".

Insgesamt ein Haufen Schrott Probleme.

Gruss
walter

wambacher wrote:

[...]
Was mir hier so auffällt (und was ich demnächst bereinigen werde):

- der Node https://www.openstreetmap.org/node/78557373 wird in der Admin-Rel als Label verwendet. prima

Nein, nicht prima, korrekt wäre role:admin_centre

wambacher wrote:

dieser Node enthält Tags, die für die ganze Fläche gelten, also dort hin gehören.

Vorsicht, diese Tags beziehen sich nicht auf die Gemeinde, sondern auf den Ortsteil (zur Orientierung bieten sich die Wikipedia/Wikidata-Links an) - dieser hat aber derzeit noch keine Grenzrelation, insofern ist die dortige Zwischenlagerung ok.

wambacher wrote:

- der Node https://www.openstreetmap.org/node/310517785 ist das Label für Neubrück(10)
er enthält neben den obigen Tags auch noch die PLZ
[...]

Auch hier: role:admin_centre

Jo Cassel wrote:

Nein, nicht prima, korrekt wäre role:admin_centre

ok, kann auch richtig sein. Nur kann ich als "Externer" nicht beurteilen, was von beiden gewünscht war. Mir reicht es eigentlich, dass der Node als label/admin_centre genommen wird.

wambacher wrote:

dieser Node enthält Tags, die für die ganze Fläche gelten, also dort hin gehören.

Vorsicht, diese Tags beziehen sich nicht auf die Gemeinde, sondern auf den Ortsteil (zur Orientierung bieten sich die Wikipedia/Wikidata-Links an) - dieser hat aber derzeit noch keine Grenzrelation, insofern ist die dortige Zwischenlagerung ok.

stimmt.

wambacher wrote:

- der Node https://www.openstreetmap.org/node/310517785 ist das Label für Neubrück(10)
er enthält neben den obigen Tags auch noch die PLZ
[...]

Auch hier: role:admin_centre

siehe oben.

Gruss
walter

ps: eigentlich müsste die AL von Ersehof gelöscht werden, da es sich ja "nur" um eine benanntes Residential handelt, das sicher nicht die gesamte Fläche von Ersehof abdeckt.

Nicht nur bei Braunschweig, sondern auch in Hessen gibt es noch paar verstreute/verirrte place=suburb im ländlichen Raum. Falls mal jemand in dieser Region drüber schauen möchte:

https://overpass-turbo.eu/s/EWj

Verstehe ich das richtig, dass man Ortsteile nicht kennzeichnen soll, ausser über ihre Relationszugehörigkeit?
Edit: Also eben nicht das, was on the ground auf dem Ortsschild steht?

MKnight wrote:

Verstehe ich das richtig, dass man Ortsteile nicht kennzeichnen soll, ausser über ihre Relationszugehörigkeit?
Edit: Also eben nicht das, was on the ground auf dem Ortsschild steht?

Du sollst lediglich das, was on the ground auf dem Ortsschild steht, nicht fälschlich als place=suburb mappen, wenn es real kein solches (nämlich ein Stadtteil innerhalb eines zusammenhängenden Stadtgefüges) ist, das ist alles.

Dass die Zugehörigkeit zu einer Verwaltungseinheit über eine Relation abgebildet wird und nicht übers place-Tagging (außer es macht dir Spaß, ein is_in-Tag dranzuhängen), ist keine Forderung von mir, sondern war schon vor meiner Zeit in OSM so 🙂

--ks

Moin.

Hallo Mecki. Grüße vom Braunschweiger Umland an das Braunschweiger Umland.

Und wambacher hat recht, die Grenzziehung von Ersehof mit den Überlappungen war eines meiner frühen Werke und wegen eben jener Überlappung falsch. Mein Fehler.

Um nun mal all jene in die Problematik vom Herbst 2017 einzuführen, deren einziger Lebenssinn nicht in der Bearbeitung von OSM liegt, sei geschrieben, daß die place-Knoten radial einen Einfluß ausüben und dieser Einfluß in seiner Reichweite offenbar unabhängig vom angegebenen Ortstyp ist.
Dies hatte zur Folge, daß z. Bsp. auf Nominatim, und über Nominatim auch auf openstreetmap.org, Straßen völlig falschen Ortschaften zugeteilt wurden, eben weil der Einfluß des place-Knoten des Nachbarortes größer war als der Einfluß des place-Knoten des Ortes.
Da aber der Einfluß eines place-Schlüssels durch eine Grenze boundary=administrative gestoppt werden kann, habe ich unterhalb des admin_lvl 8 weitere Level (ehemals real existierende Orts-/Verwaltungsgrenzen) in die Karte eingezogen, um das Chaos zu bändigen.

admin_level 8 -> Gemeinde
admin_level 9 -> Orte von Gemeinden mit eigenen Ortschaftsrat

admin_level 10 -> Orte von Gemeinden ohne eigenen Ortschaftsrat
admin_level 11 -> Orte, die Ortschaften zugeordnet sind, die wiederum zu Gemeinden gehören

So ein Beispiel ist Ersehof. Ersehof ist ein Ortteil von Neubrück (AL11), Neubrück ist Ortschaft in der Gemeinde Wendeburg (AL10).

Da nach Auskunft unserer Samtgemeinde die Gemarkungen (Zusammenfassung mehrere Flure, die wiederum eine Zusammenfassung mehrerer Flurstücke sind) den Ortschaften entsprechen und die kleinste verwaltungstechnische Einheit nun einmal die Gemeinde ist (AL 8), ist es völlig wurscht, ob die Pappel auf der Koppel nun von Ersehof beansprucht wird oder nicht, es ist Gemeindeland.
Aus diesem Grund sind auf admin_lvl 11 auch nur die landuse=residential-Gebiete als Relation zusammengefaßt - auch wenn sich diese Residential-Bereiche noch auf mehrere unabhängige Gebiete aufteilen.

Nachtrag: Neubrück hat einen eigenen Ortsrat und ist damit AL9 und nicht AL10.

OkerJoker wrote:

Um nun mal all jene in die Problematik vom Herbst 2017 einzuführen, deren einziger Lebenssinn nicht in der Bearbeitung von OSM liegt, sei geschrieben, daß die place-Knoten radial einen Einfluß ausüben und dieser Einfluß in seiner Reichweite offenbar unabhängig vom angegebenen Ortstyp ist.
Dies hatte zur Folge, daß z. Bsp. auf Nominatim, und über Nominatim auch auf openstreetmap.org, Straßen völlig falschen Ortschaften zugeteilt wurden, eben weil der Einfluß des place-Knoten des Nachbarortes größer war als der Einfluß des place-Knoten des Ortes.
Da aber der Einfluß eines place-Schlüssels durch eine Grenze boundary=administrative gestoppt werden kann, habe ich unterhalb des admin_lvl 8 weitere Level (ehemals real existierende Orts-/Verwaltungsgrenzen) in die Karte eingezogen, um das Chaos zu bändigen.

Diese Problematik hab ich bereits mehrmals im Forum beschrieben, da eine "Place-Diskussion" hier alle paar Monate erneut stattfindet. Aber so treffend und verständlich wie bei diesem Post hab ich das nicht hingekriegt.

Danke dafür
Walter

Ps: Bold in Zitat von mir

Hallo OkerJoker, danke für die Info. Würde ich wahrscheinlich genau so machen.
Gruß Mecki

Jo Cassel wrote:

Auch hier: role:admin_centre

Also mit role:admin_centre habe ich ein Problem.

Wenn ich auf openstreetmap.org nach Neubrück suche, dann finde ich "Dorf Neubrück, Landkreis Peine, Niedersachsen, 38530, Deutschland", den Knoten (da fehlt auch die Gemeinde Wendeburg in der Struktur) und "Nachbarschaftsgrenze Neubrück, Wendeburg, Landkreis Peine, Niedersachsen, Deutschland", die administrative Grenze.

Setze ich dagegen role:label, erhalte ich "Dorf Harvesse, Wendeburg, Landkreis Peine, Niedersachsen, Deutschland" mit der administrativen Grenze UND dem Knoten im Zentrum des Dorfes. Also nur eine Eintragung.

Vielleicht wäre folgende Lösung der beste Weg:

WENN der Name einer Gemeinde gleich dem Namen einer Ortschaft in der Gemeinde ist UND sowohl für die Gemeinde als auch für die Ortschaft eine Grenzrelation vorhanden ist, DANN setze den place-Knoten für die Ortschafts-Relation auf role:label und den place-Knoten für die Gemeinde-Relation auf role:admin_centre.

Um noch einmal die Problematik der Schriftgröße von Zweidorf / Wendezelle in Wendeburg aufzugreifen:
Auf der Geofabrik-Karte sehe ich ab einem bestimmten Zoom nur die Namen der beiden Ortsteile, der Ortsname Wendeburg wird völlig verschluckt.
Da aber der Key place=village (für Dörfer) auch place=neighbourhood erlaubt, ist dies in diesem Fall der gangbare Weg.

Genau auf diese Weise habe ich auch mal Klein Schwülper als Ortsteil von Rothemühle eingetragen. Genauso wie im Falle von Zweidorf und Wendezelle war Klein Schwülper mal ein eigenständiger Ort, der an der Okerstraße mit dem größeren Rothemühle zusammengewachsen ist und nun einen Ortsteil darstellt.
Ich orientierte mich dabei an dem örtlichen Online-Telefonbuch, in dem seinerzeit der Ortsteil bei der Suche noch gefunden werden konnte, ohne allerdings Teil einer Adresse innerhalb des Ortes zu sein.
Ebenso ist es bei Wendezelle und Zweidorf, beide Ortsteile sind als eben solche aufgeführt, die Namen werden aber nicht in Adressen geführt.

OkerJoker wrote:

Vielleicht wäre folgende Lösung der beste Weg:

WENN der Name einer Gemeinde gleich dem Namen einer Ortschaft in der Gemeinde ist UND sowohl für die Gemeinde als auch für die Ortschaft eine Grenzrelation vorhanden ist, DANN setze den place-Knoten für die Ortschafts-Relation auf role:label und den place-Knoten für die Gemeinde-Relation auf role:admin_centre.

Zunächst mal zu der Gemeinde-Ebene (auf das sich auch mein obiges aus dem Zusammenhang gerissenes Zitat bezog)
admin_centre ist der Ort des Verwaltungssitzes der Gemeinde (al=8) - völlig unabhängig davon ob al=9, al=10-Grenzen erfasst sind! In der Regel ist das der namensgebende Hauptort, aber ein Naturgesetz ist das keineswegs. Und wenn Du dir auf der Gemeinde-Ebene bei derartigen Gemeinde-Fällen (gleichnamiger Hauptort) wie Breuna
https://www.openstreetmap.org/relation/162612
keine Gedanken um label machst, dann passiert bereits auf der Gemeide-Ebene das, was dir auf der Ortsteil-Ebene negativ auffällt, die Gemeinde wird nicht als Gemeinde, sondern als Dorf erkannt.

Zu den Ortsteilen, da wäre zunächt mal zu formulieren, was denn überhaupt das Ziel der Übung ist, oder ist das schon "linke Großkommune"?
Schonmal darüber nachgedacht einen Ortsteil-place-node als admin_centre UND label der Relation zuzuweisen statt über ODER zu sinieren - oder passt das nicht in dein Weltbild?

Nun nun - solange Euer Beider Weltbild darauf beruht, einem Fehler in Nominatim mit Tagging für Nominatim beikommen zu wollen, seid Ihr doch gar nicht soweit auseinander.

Übrigens:
Aus diesem "Wenn der Name eines place-node gleich der admin-relation ist" ist der aktuelle fehlerhafte Nominatim-Würgaround ja erst entstanden - den ihr jetzt durch einen erneuten Tagging-Würgaround ausgleichen wollt. => Doppelt gewürgt hält besser!

@GeorgFausB
Naja, ein Auswerter soll allein aus dem admin_level=* der Grenzrelation ermitteln, mit welcher Gebietskörperschaft er es genau zu tun hat?

Bei den Schutzgebieten (boundary=protected_area) gibt es neben protect_class=* sinnvollerweise auch noch protection_title=* - was Benennungen ohne zuhilfenahme fragwürdiger Drittquellen ermöglicht (ob Nominatdings das umsetzt ist wieder etwas anderes).

Moin.

Die Relation Breuna ist ja schon nicht schlecht, allerdings irritieren zwei Knoten doch etwas. Wenn man den Knoten des admin_centre farblich anders gestalten könnte, wäre es wohl hilfreicher.
Vielleicht könnte man den place=village- und den place=municipality-Knoten (Ist der Name beim municipality-Knoten generell unsichtbar ?) nebeneinander legen und sie mittels label in die jeweilige Relation einbinden. Dann könnte man z. Bsp. die Bevölkerungsinformationen wieder an die Knoten schreiben, wo man sie ja als Mapper prinzipiell auch vermuten würde.

Ja, Nominatim war 2017 der Anlaß dafür, die Auswüchse der place-Knoten durch Grenzen einzuschränken. Der Sinn war auch der, daß es eben außerhalb der kompakten Residential-Landusemasse der Orte auch Wohnhäuser geben kann, die sich ohne die Grenzen nicht einfach zuordnen lassen.

Nominatim lieferte damals eine Menge Quatsch, also ordnete Straßen den falschen Orten zu. Und dies war eben auch bei Suchanfragen auf der relevantesten Seite von OSM, openstreetmap.org, so.
Heute liefert Nominatim auch noch Quatsch, aber irgendwie beeinflußt es das Suchergebnis nicht. Jede Menge Seiteneffekte....

OkerJoker wrote:

Moin.

Die Relation Breuna ist ja schon nicht schlecht, allerdings irritieren zwei Knoten doch etwas. Wenn man den Knoten des admin_centre farblich anders gestalten könnte, wäre es wohl hilfreicher.
Vielleicht könnte man den place=village- und den place=municipality-Knoten (Ist der Name beim municipality-Knoten generell unsichtbar ?)

All dies sind reine Fragen der Daten-Auswertung. Ich rate jetzt mal, dass Du von der OSM-Homepage + carto sprichst, die halt nicht alle Möglichkeiten nutzen.
Andere Auswertung z.B.
http://overpass-turbo.eu/s/Ezh

OkerJoker wrote:

Dann könnte man z. Bsp. die Bevölkerungsinformationen wieder an die Knoten schreiben, wo man sie ja als Mapper prinzipiell auch vermuten würde.

Also da wo ich herkomme ist die Bevölkerung erfreulicherweise über eine Fläche verteilt und nicht punkförmig gestapelt.

Jo Cassel wrote:

Also da wo ich herkomme ist die Bevölkerung erfreulicherweise über eine Fläche verteilt und nicht punkförmig gestapelt.

Die place-Knoten (in einer Ortschaft) stellen auch nur an einem Punkt Informationen zur Verfügung, im übrigen sollen die population-, wikidata- und wikipedia-Tags nach dem englischen Original (siehe: Additional tags) dort stehen, wo die place-Tags sind.
Sprich, man könnte also schon je einen Knoten place=village bzw. place=municipality mit allen Informationen nebeneinander erstellen und in den verschiedenen Relationen labeln, wobei anhand der Informationen anderen Usern klar sein sollte, daß der "doppelte Knoten" gewollt und kein Fehler war.

OkerJoker wrote:

Die place-Knoten (in einer Ortschaft) stellen auch nur an einem Punkt Informationen zur Verfügung, im übrigen sollen die population-, wikidata- und wikipedia-Tags nach dem englischen Original (siehe: Additional tags) dort stehen, wo die place-Tags sind.
[...]

Wenn es keine diesbezüglichen Grenzrelationen gibt ..., in DE gibt es allerdings flächendeckend Gemeinde-Grenzrelationen, daher einfach an hier erarbeiteten Gemeinde-Beispiele:
https://wiki.openstreetmap.org/wiki/DE: … nselemente
und "Alle Daten die das gesamte Gemeindegebiet betreffen sind der Grenzrelation zugeordnet." halten und nicht bis in die Unendlichkeit diskutieren.

Ab wann ist ein Stadtteil denn Teil eines zusammenhängenden Stadtgefüges?

Beispielsweise hier München-Langwied: https://www.openstreetmap.org/#map=15/48.1789/11.4223
Wäre das jetzt noch Teil des zusammenhängenden Stadtgefüges?

Maturi0n wrote:

Ab wann ist ein Stadtteil denn Teil eines zusammenhängenden Stadtgefüges?

Nach meinem Dafürhalten: Wenn es an mindestens einer Stelle mit dem übrigen Bebauungsgebiet verbunden ist. Andersrum: Wenn man von seinem Ortskern zur Bezugsstadt nicht zwingend über unbebautes Land gehen muss.

Maturi0n wrote:

Beispielsweise hier München-Langwied: https://www.openstreetmap.org/#map=15/48.1789/11.4223
Wäre das jetzt noch Teil des zusammenhängenden Stadtgefüges?

Nach meiner Kartenbild-Interpretation: nein. Kenne die Gegend aber nicht.

--ks

Sorry diesen Thread nochmal aufzumachen. Aber im Zusammenhang mit der aktuellen place=town-Diskussion bin ich darüber gestolpert, dass der im hier vorliegenden Thread angesprochene Widerspruch zwischen https://wiki.openstreetmap.org/wiki/DE: … e%3Dsuburb bzw. https://wiki.openstreetmap.org/wiki/Tag:place%3Dsuburb einerseits und https://wiki.openstreetmap.org/wiki/Tem … ures:place andererseits nach wie vor besteht. Der dort diskutierte, Verwirrung stiftende und im engl. Original nicht vorhandene Punkt zu "vormals eigenständigen Städten" als suburb wurde 2014 eingefügt (https://wiki.openstreetmap.org/w/index. … id=1081233 mit Verweis auf http://forum.openstreetmap.org/viewtopi … 55#p448855 - dort wird suburb jedoch nicht diskutiert). Auf welchen deutschlandinternen Konsens geht dieser Punkt zurück, der im Widerspruch zu den anderswo beschriebenen Konventionen steht? Oder anders gefragt: Wenn er damals ohne Konsens und irreführend eingetragen wurde, wäre es nicht sinnvoll legitim, ihn mal allmählich zu entfernen? Welche Art der Meinungsbildung bzw. Rückversicherung würdet ihr für einen solchen Schritt für angebracht halten?

@ 38446

Die Definition von place=suburb ist in der englischen (und damit maßgeblichen) Wiki deckt sich mit der deutschen, wobei der Begriff in der letzteren etwas ausführlicher dargestellt wird.

Bereiche eines zusammenhängenden Stadtgebiets sollten nicht als place=town, place=village oder place=hamlet getaggt werden. Diese Werte sollte nur für abgegrenzte Siedlungen verwendet werden.

Umgekehrt sollten klar abgegrenzte Ortschaften, die Teil einer größeren Gemeinde oder Stadt sind, nicht als place=suburb sondern je nach Größe und Struktur als place=village, place=hamlet oder gegebenenfalls auch place=town getaggt werden.

OSM's usage of 'suburb' is different than that used by North American English, where a suburb is "an area, often residential, outside of a central city". Often these suburbs are distinct settlements and will be tagged as place=village, place=town, or place=city, depending on factors such as population.

Lediglich in der deutschen Template zu place=suburb der wikiseite Key:place hat jemand die anderslautende Definition hineingemogelt.

Unterschiede zwischen der englischen und deutschen Version sind generell zulässig, sofern sie nationale Besonderheiten reflektieren - dann sollten Sie aber auch entsprechened gekennzeichnet/dokumentiert sein. Das ist hier aber nicht wirklich der Fall, wie Du bereits festgestellt hast.

Auch wenn eine Verwendung von place=suburb im Falle der parallel laufenden Diskussion zu den administrativ künstlich erzeugten "unechten" Städten den Vorteil hätte, dass man dann dem übergeordneten Kunstgebilde ruhigen Gewissens einen place=town node verpassen könnte (was vielleich sogar der Grund für diese undokumentierte Definition war ..??), steht das ganz klar im Widerspruch zur meinungsführenden englischen wiki-Version und sollte daher korrigiert werden.

Wie das am besten geschieht und dokumentiert wird, werden die versierteren Kollegen sicher wissen. Ich denke, in so einem relativ klaren Fall reicht es, eine korrekte Übersetzung der englischen Version einzufügen und diesen Change entsprechend zu kommentieren, habe aber keine Erfahrung mit der Bearbeitung der Wikis.