die Rione waren auch schonmal admin level 10 in OpenStreetMap, allerdings gibt es sie verwaltungsmäßig nicht mehr, das ist alles Municipio I. Ursprünglich war Monti der name und der sperrige Name war official_name. Die Änderung wo der admin level und einfache Name entfernt wurden ist von einem bekannten Remotebesserwissermapper, leider damals ein bisschen spät entdeckt.
Placenodes braucht man dagegen eher nicht, wenn man schon ein Polygon hat, die Nodeposition wäre arbiträr.
Die ganze Seite 3 von dem Thema ist irgendwie recht Off-Topic. Eventuell in ein neues Thema auslagern, sodass hier weiterhin um das Kernthema der Suchfunktion diskutiert werden kann bzw. es auch nachträglich lesbar bleibt, wenn man sich zu diesem Sachverhalt informieren will?
Klar, saubere Daten, verbessern auch die Ergebnisse einer Suche, da aber dann können wir gleich 50% aller Themen hier einfügen 
@dieterdreist
In der Wikipedia haben die Rione mehrsprachige Artikel - wenn sie in OSM(-Daten) nicht gefunden und/oder angezeigt werden sollen,
dann sollte alles ganz genauso bleiben wie es jetzt ist:
place-Flächen mit kryptischen Namen statt boundaries + place-Nodes;-)
@the-asca
Was die POI-Suche anbelangt hatte ich in #52 (auf Seite 3) eine mögliche Lösung skizziert:
Das Wortfeld wird standardisiert in der zugehörigen Tag-Dokumentation erfasst, am besten in der zentralen Vorlage der jeweiligen Sprachversion.
Wirklich Eingegangen ist darauf bisher niemand, umgesetzt wird es wohl nicht, stattdessen wird weitergewurstelt und weitergemosert;-)
bei den Namen gebe ich dir vollkommen Recht, das mögen ja offizielle Namen sein die man auch beim Lesen gut zuordnen kann, aber mit der üblichen Suche findet man sie so nicht, und der allgemein übliche Name ist auch einfacher, ein oder mehrere alt_name machen daher Sinn.
Dass aber place Objekte nicht gefunden werden wenn sie nicht auf einem Node sind, stimmt nicht, Nominatim findet place polygone und sie sind da auch vorteilhaft (weil die Ausdehnung nicht geraten werden muss). Der OpenStreetMap-carto Stil erwartet zwar glaube ich nodes für place, aber der verliert auch immer mehr an Bedeutung, seit sich die Vektortiles so sehr verbreiten. Bei Mapbox sind die Flächen places drin, bei tilemaker in der Standardkonfiguration bisher noch nicht, aber das wird vermutlich noch kommen.
Kurz ein wenig weitermosern:
Ich suchte die [Pfarrer-Theile-Str 1B, 13591 Berlin](https://www.openstreetmap.org/search?query=Pfarrer-Theile-Str 1B%2C 13591 Berlin) und ich erhalte… nichts.
Warum? Es ist sogar mit dieser Hausnummer erfasst: https://www.openstreetmap.org/node/5612339039
Umschließend ist die PostalCode-Relation: https://www.openstreetmap.org/relation/1405891
und die Relation für Berlin: https://www.openstreetmap.org/relation/62422
Es ist auch egal ob “Str” oder Straße" oder “1b” oder “1B” oder mit/ohne Komma. allerdings lasse ich die PLZ und Berlin weg, dann finde ich es direkt:
https://www.openstreetmap.org/search?query=Pfarrer-Theile-Straße 1B
mit Beschreibungstext “Haus 1B, Pfarrer-Theile-Straße, Staaken, Spandau, Berlin, 13591, Deutschland”
Irgendwie scheint es sich an dem “Berlin” in der Suchanfrage zu stören. Klar, jetzt kann man sicherlich irgendwas an den Daten schubsen, dass es passt (addr-Tags ergänzen oder so), aber eigentlich ist alles doch gegeben?
In OSM bin ich es echt gewohnt zigfach Suchanfragen zu formulieren, aber das kann halt ja nicht sein.
Davon ganz ab, hat man mir die Addresse geschickt als “Pfarrer-Theile-Str 1.B 13591 Berlin”, Immerhin positiv überrascht, dass (sofern ich “Berlin” halt wegnehme) Nominatim der Punkt nicht sosehr stört, als dass es die ganze Straße nicht mehr findet - nur halt das Haus selbst nicht.
Aber wenn halt solch legitime Suchanfragen schon Nominatim aus’m Tritt bringen können, dann stell ich mal gar nicht den Wunsch, dass es auch das Haus finden würde bei Eingaben wie:
“Pfarer-Theile-Str 1B 13591 Berlin”, “Pfarrer-Teile-Str 1B 13591 Berlin” oder “Pfarrer-Thaile-Str 1B 13591 Berlin”
Sowas schreibt jemand schnell mal (sei’s weil man die Adresse z.B. gesagt bekommt). Ja, wäre schön, wenn dann eben nicht nur “kein Ergebnis gefunden” käme, sondern auch phonetisch gesucht werden würde.
Gruß,
asca
PS: @Jo Cassel: #52 les ich mir in ruhiger Minute nochmal durch, hab ich glaub ich übersehen, wegen dem ganzen OT hier. Will das neue Beispiel nur kurz hier aufschreiben.
Dass place Objekte nicht gefunden werden wenn sie nicht auf einem Node sind, habe ich nie behauptet.
Aber wird denn ein flächiger place-Name von einem Renderer auch angezeigt, angesichts der Namens-Dopplungsgefahr zu den (global weit überwiegenden) nodes?
Das ist imho kein Problem von carto oder von vector-Karten, sondern von OSM-grundsätzlich.
In Rom gibt es wohl großflächig place-Flächen (statt boundaries + place-nodes) und damit auch keine Stadtteil-Beschriftungen - das muss man mögen.
Mein Fall wäre das nicht, dies indirekt so vorzugeben.
(sorry @the-asca, aber das wollte ich noch klarstellen)
wie gesagt, die werden angezeigt, auch dedupliziert, aber halt nicht von Carto.
Ehrlicherweise sollte man es wohl so sagen:
“wer die Namen aus place-Flächen nutzten will, ist **gezwungen **die OSM-Daten zu dedublizieren”,
sonst kommt sowas raus:
https://overpass-turbo.eu/s/1cE3
In der Abfrage kann man auch sehen, wo automatisch gesetzte Namen von Siedlungsplätzen (“place-nodes, Pah, brauchen wir doch nicht!”) landen können,
nämlich gern auch mal dort, wo kein einziges Haus steht.
Moin,
das ist aber in meinen Augen ein Problem dessen, wie place-Flächen gesetzt werden - und was man damit nun bezeichnen will.
Man muss m. E. zwischen der Verwaltungseinheit (Stadtteil) und dem Siedlungsplatz (Stadtteil) unterscheiden.
Das Eine ist eine admin-boundary, das Andere kann eine place-Fläche (oder eben ein node) sein
Letztere sollte dann aber m. E. auch nur die besiedelte Teilfläche - inkl. umfassene Grünflächen, aber ohne externe Grünflächen - umfassen.
Grüße
Georg
je nachdem auf welchem Standpunkt man steht könnte man auch sagen die nodes widersprechen der one Element Regel wenn es schon ein Polygon gibt.
… Na, wenn das dein Standpunkt ist, dann solltest Du ihn auch mutig vertreten, und die “OSM-Karten-Entschriftung” konsequent fortzusetzen,
für den place-node “Rom” gibt es nämlich auch schon ein Polygon.
Es gibt hier https://github.com/gravitystorm/openstreetmap-carto/pull/2816 einen halben Roman zum Thema den ihr gerade neu auflegt.
Das Problem ist, dass ein Place-Node und Place-Fläche nicht die gleiche Information beinhalten, und das eine aus dem anderen nicht erzeugt werden kann. M.a.W. eine vernünftige De-duplizierung ist nur für den konkreten Anwendungsfall möglich.
Hallo zusammen,
in den Niederland scheint man sich nach einer Diskussion im Forum, auf fogendes tagging geeinigt zu haben.
https://wiki.openstreetmap.org/wiki/Tag%3Aboundary%3Dplace
Das ist da wohl jetzt der Standard.
Das tagging führt zumindest dazu das man bei der Suche nur ein Ergebnis bekommt, bei welchem der Stadtteil mit seiner Grenze angezeigt wird und der place node anzeigt wo das Zentrum ist. Für den normalen einfachen Kartennutzer die optimale Lösung würde ich sagen.
https://www.openstreetmap.org/relation/11960504#map=16/52.3736/4.8983
Da boundary=adminastrative + admin_level z.B 10, anscheinend die gleiche Bedeutung hat wie boundary=place + place=suburb
und letzteres intuitiver zu taggen ist, meint man wohl auf die admin_level verzichten zu können. So verstehe ich zumindest das wiki zu boundary=place .
Ich verstehe zugebener massen nicht was SimonPoole oben meint, und habe auch nicht vor mir deshalb den halben Roman einzuverleiben, aber vielleicht ist es ja möglich den place node (Stadtteil) mit Fläche als boundary=place einzutragen und die boundary=adminastrative, wenn das nicht das selbe ist wie SimonPoole meint bzw. unterschiedlich Daten enthalten soll weiterhin auch als solche einträgt.
Hallo nochmal
mir fiehl eben noch folgendes ein.
Falls SimonPoole hier auf die Verwaltungseinheit abzielt, was der begriff adminastrive ja nahelegt, sind die zumindest in Mönchengladbach in Nord, West , Ost u. Süd eingeteilt.
https://www.moenchengladbach.de/de/stadtbezirke
https://ris-moenchengladbach.itk-rheinland.de/sessionnetmglbi/si0046.asp
Die dann in MG wohl mit admin_level 9 einzutragen wären. Einzelne Stadtteile die keine eigene Verwaltung haben mit boundary=adminstrative zu taggen wären dann unlogisch. Hier wäre boundary=place die bessere Lösung.
Denn Stadtbezirken müsste man dann wohl die einzelnen Stadtteile als Relationen mit role=inner zuordnen.
Für Stadtteile ohne Verwaltung ist die Einordnung unter AL=10 gebräuchlich.
Hierarchisch darunter gibt es auch noch oft level 11 und sogar 12 (suburb, quarter, neighbourhood) mit der Interpretation “Grenzen *für *Verwaltung” und nicht “Grenzen von Verwaltung”.
boundary=place wäre u.U. treffender, wird aber viel seltener verwendet (5000 vs. 400000).
Wie ich oben schon oben geschrieben habe, geht es mir darum das administrative Grenzen (und die entsprechende admin_level) nur für echte administrative Einheiten verwendet werden. Graubereich geschenkt.
Um ein (sehr) konkretes Beispiel zu geben, die (politische) Gemeinde, admin_level=8, in der ich lebe besteht aus 6 verschiedenen Siedlungen die als Hof, Weiler oder Dorf als Punkt gemappt sind. Es gäbe aber einen klaren Mehrwert wenn der Verbund Siedlungsfläche und Zentrum gemappt werden könnte für diese Dorfteile ohne fake administrative Grenzen zu verwenden. Und nein es gibt -keine- offiziellen Grenzen zwischen den Dorfteilen, auch die swisstopo zum Beispiel braucht grob das Siedlungsgebiet.
Nochmal zur Sache wieder ein reales Beispiel: Überfelder Str., 42855 Remscheid
Typischer Weise wieder Ort weggelassen, PLZ weggelassen, mit “in” versucht, … aber diesmal blieb’s unauffindbar. Remscheid ist ein wenig groß um’s mit der Hand abzusuchen, als… Google 
Und siehe da, es ist nicht “Über…” sondern wirklich “Ueber…”: https://www.openstreetmap.org/way/34391228
Klar, technisch ist “Ü” was ganz anderes als “Ue”, aber wie viele werden sich ärgern etwas nicht zu finden, weil man’s einfach nicht wissen kann?
Edit: Diskussionen zu Ue/Überfeld bitte hier rein: https://forum.openstreetmap.org/viewtopic.php?id=74207
+1
place kann sich überschneiden oder deckungsgleich sein, muss aber nicht. Bei Verwaltungsgrenzen hat man normalerweise keine Überschneidungen oder Lücken, das gesamte Territorium ist aufgeteilt, und die Teile sind wieder unterteilt, die Hierarchien sind klar. Bei place ist das nicht unbedingt so, die können sich auch überschneiden, ein quarter kann auch in 2 unterschiedlichen suburbs sein, z.B., etc.
In Deuschland.
Damit lässt sich natürlich alles rechtfertigen, auch ein level 14 admin boundary um jedes Grundstück.
stimmt, aber ist das nicht bei allen admin_leveln ohne eigene Administration so?