place=suburb

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.

stimmt.

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?

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 :slight_smile:

–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.

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

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.

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…

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

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.

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:Gemeindegrenze#Zusätzliche_Relationselemente
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?

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.

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:Tag:place%3Dsuburb bzw. https://wiki.openstreetmap.org/wiki/Tag:place%3Dsuburb einerseits und https://wiki.openstreetmap.org/wiki/Template:De:Map_Features: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.php?title=Template:DE:Map_Features:place&oldid=1081233 mit Verweis auf http://forum.openstreetmap.org/viewtopic.php?pid=448855#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?