Fehlerhafte Anzeige des Namen eines Wohngebieten korrigieren?

semantik? Was spricht dagegen das landuse=residential wegzulassen?

Bei der Stadt Bietigheim-Bissingen, Stadtentwicklungsamt, gibt es einen „Übersichtsplan Stadtviertel, Kleinräumige Gliederung“. Auf dieser Karte gibt es zwar einen Bereich „Ellental/Kreuzäcker“, aber keine “Lehmgrube” und auch keine “Mühläcker”. Diese gehören zum Stadtviertel „Altstadt“. Eine feinere Übersicht mit klarer Abgrenzung gibt es vermutlich nicht. Ich hatte schon mal vor, die Stadtviertel in OSM aufzunehmen, habe aber resigniert. Ich würde dies auch gerne jüngeren Kollegen überlassen.
@ jengelh:
Der Link „Offizielle Karte“ zeigt die Stadt Bietigheim im Landesteil Baden, hat aber außer dem Namesteil nichts mit Bietigheim-Bissingen gemeinsam.

Eine Fläche mit landuse=residential ist nicht mit einem Wohngebiet, Stadtteil usw. gleichzusetzen; sie beschreibt einfach nur die vorherrschende Nutzung dieses Gebiets. Es gibt zunehmend die Tendenz, solche landuse=* immer kleinteiliger zu verwenden und z.B. landuse=residential schon an (größeren) Straßen zu unterbrechen (denn dort gilt landuse=road); mancherorts werden nur noch die Blöcke mit landuse=residential umrissen, usw. Das muss man nicht gut finden – wir werden sehen, wie sich das weiterentwickelt –, aber es bedeutet auf jeden Fall schon heute, dass ein landuse=residential nicht ausreicht, um ein „Wohngebiet“, ein Dorf usw. zu kennzeichnen; genau dafür ist „de[r] ganze place=-Quark“ gedacht und nötig.

Hallo zusammen, vielleicht kann ich ja weiterhelfen. In “meiner” Region hatte ich mal gesehen, dass jemand bei den Häusern zusätzlich zu addr:city= auch addr:suburb= eingetragen hatte. Vielleicht lässt sich das Problem ja beheben, wenn bei den Gebäuden zusätzlich auch mit addr:neighbourhood= gearbeitet wird. MfG

ich bin sehr dafür, Straßen (auch kleine) aus den landuses rauszunehmen. Die residentialitis muss ein Ende haben, sie erschwert das Weiterbearbeiten, und bremst den Fortschritt.
Place ist genau richtig für solche „Siedlungsteile mit Namen“, insofern +1

Ich sehe Wohnstraßen, Fußgängerzonen, Spielstraßen auch als Teil des Wohngebietes. Insofern bin beim momentan üblichen Detaillierungsgrad gegen eine übermäßige Zersplitterung der residentials an kleinen Straßen. Vierspurige Stadtautobahnen, Flüsse, Bahnlinien und dgl. sind aber mMn ok.

Dazu sollte aber auch ein halbwegs akzeptierter Konsens wenigstens in DE über eine Hierarchie unterhalb city/town/village bestehen, da kann man suburb, neighbourhood und *village *(eingemeindet) finden, es gäbe aber auch borough, quarter, city_block und plot, siehe https://wiki.openstreetmap.org/wiki/DE:Key:place.
Den Wert locality sollte man nur nehmen, wenn über die Ausdehnung gar nichts bekannt ist.

@seichter
“The place=locality tag is used to name an unpopulated location …”
daher nehme ich den für soetwas, völlig unabhängig von der konkreten Ausdehnung:
https://www.openstreetmap.org/node/1330646826
und nebenbei ist eine Detailierung keine Zersplitterung.

Ansonsten Zustimmung zu Chrysopras #17, der name-Tag hat aus guten Gründen an landuse=residential nix verloren.

Wie sieht es aus, wenn es “später” nicht besser wird? Ich habe hier eine Ecke (mit immerhin rund 3.500 Einwohnern), wo sich die Ortsteile eventuell grob, aber nicht genau teilen lassen. Zitat (https://rp-online.de/nrw/staedte/neuss/laternen-zeigen-die-ortsgrenze-an_aid-19754135):

Derzeit sind es nur Nodes, was hier und in anderen vergleichbaren Stellen bei Nominatim für Einheimische kaum erträgliche :wink: Ergebnisse auswirft…
**Grob **als Fläche erfassen oder so lassen?

Willkommen im Forum.

Entschuldige, wenn das jetzt hart klingt:
Der Vorschlag ist sachlich nicht hilfreich, da es sich nicht um einen Adressbestandteil handelt und zudem in der Folge an Stelle eines einzigen Ways oder eines einzigen Nodes viele Daten ergänzt/gepflegt werden müssten. Zudem ist es ja auch genau das Problem zu wissen, >wo< die “Grenze” verläuft, die es oft im echten Leben so auch gar nicht gibt. Landläufige Stadtteilnamen sind nicht immer in Verordnungen gegossen - und dessen Abgrenzungen sind manchmal auch nur den Köpfen von Verwaltungsbeamten entsprungen.

Beides ist in Ordnung. OSM lebt von Ortskenntnis - und derzeit scheinst Du die beste Quelle zu sein :wink:

Steht so ebenfalls im deutschen Wiki, wird nur weniger beachtet, wie man auch an einigen Beiträgen weiter oben sehen kann.
Lässt sich abgesehen davon auch nicht lupenrein realisieren: Was macht man mit einem Gewann, in dem mehrere hundert Meter voneinander entfernt zwei, drei Bauernhöfe stehen? Das ist kein hamlet, isolated_dwelling oder farm.
Aber in der Tendenz stimme ich zu: location sollte nur in Ausnahmefällen verwendet werden.

Guten Abend, um vorzubeugen dass wir aneinander vorbeireden möchte ich klarstellen dass mir durchaus bewusst ist dass solche Zusätze niemals auf Briefköpfen zu finden sein werden, aber auch dass gerade historisch gewachsene Siedlungsnamen sowohl im städtischen als auch im ländlichen Bereich nur schwer topographisch zu umfassen sind.
Mir geht es lediglich darum, ob es möglich ist, die Suchmaschine auf diese Weise technisch auszutricksen. Um es zu konkretisieren: bei meinem Beispiel mit addr:suburb= wurde nicht wie im Wiki beschrieben die Verwaltungsebene als Nummer eingetragen, sondern der Ortsname selbst. Ist das überhaupt so richtig und von Programmen verwertbar?
Wenn ja wäre das doch eine brauchbare Lösung. Der Threadersteller könnte für die Häuser an dem Straßenzug, von dem er hundertprozentig die Zugehörigkeit weiß (Bietigheim) die Eintragung als Neighbourhood machen, damit die südlich der Bahnstrecke gelegene Bezeichnung dort “rausfliegt”. Wie gesagt ich kenne die technischen Zusammenhänge nicht, es bleibt eine Überlegung. Aber es wäre immerhin besser, als Siedlungsbezeichnungen als Fläche zu taggen, deren Umrisse kaum jemand genau kennt.
Das Aufwandsargument möchte ich nicht gelten lassen für eine Datenbank, in der theoretisch Millionen Gebäude für Etagen- und 3d-Mapping präpariert werden können. Von dem noch ausstehenden Umtaggen auf die tatsächliche Nutzungsart, die noch vielerorts fehlt, ganz zu schweigen. MfG

Ich auch, bis auf die Fußgängerzonen, die sind eher für Innenstädte typisch. Wohngebiete sind dagegen eher in funktionsgetrennten Bereichen (also „moderne“ und “postmoderne”) üblich.

landuse=residential ist kein Wohngebiet sondern ein Stück Land dass dem Wohnen dient.

borough kenne ich z.B. von NYC, ich dachte eigentlich das wäre eine administrative Einteilung.
Quarter steht zwischen neighbourhood und suburb, kommt also prinzipiell in Frage, je nach Situation.
city_block ist ein Häuserblock der von Straßen begrenzt ist (also kleiner als ein typisches Wohngebiet)
und plot ist ein einzelnes Grundstück.

locality hingegen ist ein Ortsname der sich explizit nicht auf eine Siedlung oder einen Siedlungsteil bezieht. Kommt für Wohngebiete also nicht in Frage.

Für Siedlungsteile ist die Hierarchie neighbourhood, quarter, suburb

wenn der Name sich auf das Gewann bezieht ist es locality, wenn er sich auf einen oder mehrere der Höfe bezieht dann nicht.

Wir sollten in der Datenbank grundsätzlich nicht “tricksen”.
Technisch gesehen könnte man auch unzählige nodes an alle Stellen setzen, von denen man weiß, dass dort der Ortsteil ist und von Nominatim erhoffen, dass er nur einen kleinen Umgriff um diese Punkte als passende Gebietsfläche interpretiert. Wir sind uns sicher einig, dass das Unfug wäre.

Theoretisch ist das verwertbar. Nachdem das vorgeschlagene Tagging aber so nicht vorgesehen ist, würde es momentan logischerweise von praktisch niemandem unterstützt (=ausgewertet) werden.

Es besteht hierbei kein Unterschied dazu, als wenn man um die “bekannten Punkte” bzw. “Häuser” eine entsprechende Fläche ziehen würde.
Außerdem würden ja auch alle anderen Elemente, die keine Adresse tragen (Spielplätze, Straßen, Hundehütten…) in diesem Ortsteil liegen.

Das Argument zielt nicht auf die Größe der Datenbank ab, sondern auf deren Pflege. Angenommen, jemand erfasst einen Neubau zwischen den wie vorgeschlagen erfassten Gebäuden und kennt “die Trickserei” nicht bzw. erfasst das nicht - dann liegt das Objekt für den Auswerter wo?
Definitiv ein Argument für eine Fläche!
Aus dem gleichen Grund erfasse ich normalerweise keine PLZ, da das kaum vor Ort verifizierbar ist, aber relativ leicht aus den PLZ-Gebieten abgeleitet werden kann.

Die fehlt nur, wenn man sich dafür interessiert :wink: Mir reicht ein vernünftiges landuse. Einen kleinen Einblick in das Thema: zum Beispiel hier https://forum.openstreetmap.org/viewtopic.php?id=69728

wir haben in Italien noch keine Postleitzahlengebiete und auch noch relativ wenige Adressen, aber wo ich eine Adresse erfasse setze ich soweit ich es weiß auch die PLZ dazu, das geht ziemlich oft, z.B. anhand von Adressangaben auf Kassenzetteln und Internetseiten von Geschäften.

OT:

“Normalerweise” bezog ich auf D. Ich habe auch schon nicht wenige Adressen in I erfasst. Bei den Wohngebäuden war es aber - wenig erstaunlich - schwer, PLZs zu finden. Wenn dann irgendwann jemand dort ein PLZ-Gebiet erfassen würde, fände ich das aber effektiver, als wenn immer wieder vereinzelt jemand an eine Adresse die PLZ ergänzt :stuck_out_tongue: Letzteres ist aber natürlich besser, als gar nichts :sunglasses:

Hallo,

hier würde ich persönlich den Schwerpunkt eher beim zweiten Satzteil legen. Es kann ja nicht Ziel sein, die ganze Karte flächendeckend mit place=neighbourhood-Nodes zuzupflastern und ansonsten immer den nächstgelegenen derartigen Node heranzuziehen, selbst wenn der kilometerweit weg liegt. Gibt es denn keine Maximaldistanz, ab der Nominatim die Zuordnung nicht mehr vornimmt?

Das gleiche Problem zeigt sich auch in der Mainzer Oberstadt. Hier werden auch weite Teile als “Schlesisches Viertel” ausgewiesen, weil das halt der einzige Neighbourhood-Node weit und breit ist (https://www.openstreetmap.org/node/4671549890).

Muss denn diese Ebene zwischen Straße und Ort im Ergebnis der Suche denn unbedingt ausgewiesen werden? Einen Mehrwert kann ich spontan nicht erkennen.

Gruß

Ein place + Name, wo dies bekannt und zutreffend ist, sehe ich als sinnvolle Ergänzung der Daten.
Nicht ok wären place-nodes, die künstlich angelegt wurden, um die Ausgabe von Nominatim zu beeinflussen.
Das wäre analog zum (Falsch-)“Mappen für den Renderer”.

Was Nominatim wann und warum macht, sollte nicht Richtschnur fürs Mappen sein. Das ist (im Prinzip) Sache der Entwickler von Nominatim.