Nein. Nicht mit eigenständiger Administrative. Ob es Verwaltungsgrenzen innerhalb der Gemeinde gibt, ist eher fraglich.
Eigentlich schon. Das Telefonbuch der Telekom zum Beispiel unterscheidet bei den Adressen schon zwischen den Ortsteilen.
Die Post kann auch etwas damit anfangen, wenn Du den Ortsteil bei der Adresse angibst.
In einer großen Stadt orientiert man sich doch auch an den Stadtteilen.
Wenn Du Dir Schwülper als “künstliche” Verwaltungseinheit ansiehst, gibt es da 4 eigenständige Orte. Groß Schwülper, Lagesbüttel, Walle und Rothemühle. Alle zum Beispiel mit eigenen Feuerwehren und Sportvereinen und dem entsprechenden Ortsteilnamen. Schon deswegen macht eine Unterscheidung Sinn.
Der Fehler von OSM liegt wohl darin, daß place-Knoten schlecht definiert sind.
Und nein, ich halte das nicht für einen Fehler von Nominatim. Warum sollte Nominatim die Daten der OSM Datenbank schlechter auswerten als andere Programme?
Wieso sehe ich bei deinem Beispiel Großaspach den Namen des Ortes auf der Karte bis zu einer gewissen Zoomstufe und bei den Orten in Schwülper nicht?
Großaspach existiert in Nominatim auch nur einmal als Polygon und der Name wird angezeigt.
Groß Schwülper wird bei mir in ZL 12 bis 15 angezeigt. Wenn bei dir nicht, dann liegt der Fehler bei dir. Die anderen Nodes sind noch nicht wiederhergestellt, weil ich noch nicht weiß, welche du alle gelöscht hast.
Ich habe jetzt zu den “Ortsteil”-Polygonen wieder die “Ortsteil”-Knoten angelegt. Die Merkmale sind identisch.
Und ich erhalte hier jetzt alle möglichen Effekte.
Sehr gut: In Hülperode werden Fläche und Knoten von Nominatim als eine Einheit betrachtet, wie in Großaspach.
Gut: Für Groß Schwülper und Walle liegen in Nominatim Knoten und Fläche getrennt vor, aber der Knoten enthält keine Elemente.
Nicht gut: Für Lagesbüttel liegen in Nominatim Knoten und Fläche getrennt vor, aber der Knoten enthält einige Elemente.
Geht gar nicht: Für Rothemühle liegen in Nominatim Knoten und Fläche getrennt vor und in der Fläche fehlen alle Straßen.
Die teilweise falschen Ortszuordungen beim Nominationsuchergebnis fallen meiner Meinung nach vielen OSM-Kartenbenutzern negativ auf und wurden schon häufiger in OSM als Fehler gemeldet.
Mein Senf dazu:
Das “Nomination-Anzeigeproblem” wäre keines, wenn Nomination die place=* im Ergebnis einfach weglassen würde, wenn das Suchziel innerhalb einer Gemeinderelation liegt und stattdessen nur den Namen der Relation anzeigen würde. Mir würde beim Suchergebnis genügen, wenn z.B. dransteht “Breisacherstraße 1, München”. Den Stadtteil, das Viertel oder Häuserblock brauche ich nicht, vorallem, wenn er nur teilweise stimmt.
Im Berliner Stadtgebiet gibt es m.W. 9x die Berliner Straße.** Allein im Bezirk Pankow findest Du drei (früher noch mehr) Berliner Straßen. Was macht man in diesen Fällen ohne Ortsteilzuordnung? Ich fürchte, Dein Vorschlag wäre hier ein elementarer Rückschritt.
** Das heutige Berlin entstand 1920 durch eine große Eingemeindung etlicher Städte und Dörfer, weshalb es bis heute viele Straßennamendopplungen in Berlin gibt.
Nach 49 Beiträgen verstehe ich immer noch nicht die Intention der ersten Betrages…
Was will er damit bezwecken?
Ich habt zum Test mal die Straße “Asthoop” gewählt. Die PLZ-Datenbank will immer einen Ort hanben… ok… Bei OSM wir mir “Asthoop, Lagesbüttel, Schwülper, Samtgemeinde Papenteich, Landkreis Gifhorn, Niedersachsen, 38179, Deutschland” angezeigt… Ich habe das auch mit anderen Straßen getestet… Selbes Ergebnis.
Wirklich? Ich glaube es nicht, daß man das nicht abgrenzen kann…
Im Zweifelsfall können unterhalb der Gemeinde Schwülper (AL=8) die entsprechenden Ortsteile mit ihrer Grenze als AL=10 erfasst werden. Als Grenzen können hier z.B. (alte) Gemarkungsgrenzen herhalten. Man muß es aber halt nur machen!!
Meiner Erfahrung nach verändern sich diese Gemarkungsgrenzen i.d. R. nicht, oder nur sehr wenig, so daß sie hinreichend und in der Fragestellung ausreichend sind…
Wenn der Ortsteil durch eine Relation ermittelt wurde, habe ich auch nichts gegen “Breisacherstraße 1, Haidhausen Nord, München”.
Wenn der Ortsteil durch einen gewissen Umkreisradius um einen place=xy-POI “erraten” wurde, das Suchergebnis aber innerhalb einer place=xy-Relation liegt, wäre es mir lieber der Rate-Name würde nicht angezeigt werden und nur der Relations-Name. Liegt das Sucherbnis innerhalb keiner place=xy-Relation ist auch ein “geratener” Name besser als nix und soll auch weiterhin verwendet werden, nur eben nicht wenn es “bessere”, genauere Daten über eine place=xy-Relation gibt.
Das meinte ich damit und hoffe ich habe es nicht zu verwirrent erklärt.
Nein, sind sie nicht, wenn du sie neu angelegt hast. Die History fehlt; es sieht jetzt so aus, als seiest du der erste, der diese place-nodes überhaupt jemals angelegt hat, die Dokumentation der Arbeit deiner Vor-Mapper ist durchs Löschen und Wieder-neu-Anlegen verloren gegangen. Deshalb habe ich dir angeboten, die Nodes wiederherzustellen, wenn du mir sagst, welche das waren.
Deshalb gleicht man eine Löschung nicht durch Wiederanlegen aus, sondern durch Wiederherstellen. Der Editor iD, den du verwendest, kann das nicht, soweit ich weiß, aber JOSM, den ich verwende und die meisten anderen hier auch, kann es. Du müsstest dazu aber etwas Teamgeist zeigen und kommunizieren, statt weiter auf eigene Faust herumzuwurschteln. Ich hab dich zwei Mal gefragt, welche place-Nodes du gelöscht hast, du hast nie geantwortet, und jetzt haben wir sie zwei Mal in der Datenbank (einmal gelöscht, physisch sind die Daten aber noch da, einmal neu).
Ich freue mich für Eure Wertschätzung des Historischen.
Anders formuliert: Ich habe alle Schlüssel mit allen Werten, die an den Knoten vorhanden waren, an den jeweiligen Polygon gehängt, der den besiedelten Ortsteil darstellen soll.
place-Node und place-Polygon zu mappen halte ich für falsch, verstößt gegen das one-feature Prinzip, und führt dazu, dass ein Ort bei der Ortssuche im Navi doppelt erscheint.
Ich finde die Lösung auch nicht toll.
Es ist aber nun mal offensichtlich so, daß man den name-Schlüssel nicht formatieren kann.
D.h. ich habe hier Polygone, die ich um Orte, die verwaltungstechnisch als Ortsteile gezeichnet werden, ziehen muß, damit die Straßen überhaupt dem richtigen Ort (-steil) zugeordnet werden.
Dabei werden 1) ab einer bestimmten Zoomstufe (etwa, wenn man die Straßennamen erkennen kann) die Ortsnamen nicht mehr angezeigt, im Gegensatz zu einem place-Knoten, und 2) umfaßt der eine oder andere Ortspolygon ein geographisch so weit auseinanderliegendes Straßen-/Siedlungsgebiet (Bsp. Rothemühle), daß ein zentrierter Ortsname mitten in der Pampa liegen müßte.
Wenn also der Name auch in etwas tieferen Zoomschichten angezeigt werden könnte und man ihn formatieren könnte (links, mittig, rechts) oder besser, man die Position des Schriftzuges an eine geographische Position binden könnte, wäre ich zufrieden.
Natürlich wäre es irgendwie einfacher, die Straßen mit einem “located_in” Schlüssel zu versehen, um sie eindeutig einem Ort zuzuordnen. Einen postal_code hat man ja bei OSM schnell hinbekommen…
Einfach wie wild ein paar Linien zu zeichnen und damit zu definieren, was wo hingehört?
Diese “Place-Polygone” sind genau so willkürlich wie “meine” geschätzten Admin Boundaries, allerdings sind die “Places” zu 100% geraten, wärend die AL-Grenzen zumindest an der Peripherie sauber sind.
Es wird eine neues Konstrukt eingeführt (zumindest in DE)
Es werden uralte, obsolete Tags verwendet (is_in), die in einer Spatialen Datenbank nichts zu suchen haben.
Es werden PLZ verwendet, obwohl es dafür fertige Relationen gibt
Die Gebiete überschneiden sich teilweise, auch wenn place=* identisch ist.
Es gibt riesige Lücken, die undefiniert sind.
Gesamturteil: Pfusch
Um der Frage vorzubeugen: “Es gibt dort ja keine Grenzen, erst recht keine Administrativen”
Warum haben wir dann diese Grenzen in DEU? davon ca 5500 AL10-12?
select level, count(*)
planet3-# from boundaries
planet3-# where country='DEU'
planet3-# group by level
planet3-# order by wno_number(level);
level | count
-------+-------
2 | 1
4 | 16
5 | 19
6 | 399
7 | 1254
8 | 11162
9 | 4758
10 | 4353
11 | 1056
12 | 164
Ich bin jedenfalls froh, dass es die (in OSM) gibt.
Ist dir eigentlich klar - oder auch nur bekannt - , dass OSM auf einer Spatialen Datenbank basiert? Dass es dabei absolut unnötig ist, irgendwelche Konstrukte (toll, nun auch noch “located_in”) an die Objekte dranzuschreiben, damit man weiss, wo sie sich befinden?
Dann können wir OSM auch gleich auf mySQL oder Excel/Access umstellen, das kennen eh viel mehr Leute.
wambacher
ps: Ansonsten bestätigt sich bei mir der Eindruck, dass du nicht bereit - oder in der Lage? - bist, konstruktive Kritik zu lesen, zu verstehen und zu akzeptieren. Manche Sachen wurden schon von mehreren Kollegen dargestellt aber du scheinst da nicht drauf zu reagieren.
a) Wenn Dich die Darstellung auf der Hauptkarte oder auf irgendwelchen anderen OSM-basierten Karten nicht gefällt > gibts alles als Opensource > selber Hand anlegen und nach deinen Wünschen gestalten. Easy as this. Kannst ja mal bei Mapbox vorbeischauen, da kannst du, soviel ich weiß, so ziemlich alles in einem eigenen Stil anpassen und dann diesen verwenden.
b) Wie @wambacher Dir schon schrub, ist postal_code an highways “etwas” veraltet und Du hättest gerne ein located_in? Mitnichten wäre es einfacher, einen located_in-Key zu verwenden. Teilst du die highways genau an der Grenze auf? Pflegst du die ganzen located_in bei Eingemeindungen/Änderungen? Wieviele der Mapper würden daran denken, das zu tun? Im Gegenteil würde das den Prozess für viele Mapper verkomplizieren, und das brauchen wir sicher nicht.
