Danke … ich hab’ mal einen Optimierungs-Feldversuch gestartet …
… Dort ist hinter der 9 immerhin noch etwas Platz.
Meine Sorge ist, wenn die 10 levels “aufgebraucht” sind, weichen Mapper möglicherweise deswegen auf place-Flächen aus,
obwohl ein durchgängiges admin_level-Schema (+place-node) perspektivisch die bessere Erfassungsmethode wäre, auch und gerade hinsichtlich von Suche und Auswertung.
Zu Berlin, dort ist die admin_level=9-Grenzrelation mit einem place=borough-node verbunden, soweit so gut,
warum diese Relation selbst zusätzlich auch noch als place=borough getaggt worden ist, ist mir allerdings schleierhaft.
Es gibt nun mal viele benannte Orte die keine administrativen Einheiten sind und einfach was zu erfinden was in Realität nicht existiert, ist nicht sonderlich sinnvoll (ja ich weiss Deutschland geht da seinen eigenen Sonderweg). Sinnvoller wäre es sich auf eine vernünftige Unterstützung von place-Flächen (inklusive Flachen + Zentrum Kombinationen) zu einigen.
nach 10 kommt 11. Wir haben uns damals für 10 entschieden, weil immer eins dazwischen ausgelassen wurde, es könnte ja genauso gut sein, dass man zukünftig irgendwann eine Stufe dazwischen braucht. Übliche admin levels sind hier 2, 4, 6, 8 und ggf. 10
… Na, dann würde ich die 11 auch nutzen + verbundenen place-node
http://overpass-turbo.eu/s/1czk
aber bitte ohne Doppelung des place=* an der admin_level-Grenzrelation.
(Generell würde ich empfehlen sowas nicht für nur eine Grenzrelation zu machen, sondern soweit möglich für die komplette übergeordnete Gebietskörperschaft. Dies scheint so ein z.Zt. isoliert rumgeisternder Rione-place-node
https://www.openstreetmap.org/node/5566077492
)
für Monti gibt es glaube ich keine Gebietskörperschaft, aber der node ist sowieso eine Doppelung, das Viertel ist hier: https://www.openstreetmap.org/relation/5451988
… ist mir klar, findet sich ja in der Abfrage in #66.
Dein hinzugefügter alt_name geht in die richtige Richtung,
aber warum nicht alle Rione (einheitlich) zur admin_level-Grenzrelation umtaggen und mit (einheitlichen) place-nodes versorgen/verbinden…
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.