Mangelhafte Suchfunktion von OpenStreetmap

Versuch mal https://photon.komoot.io/

Die in osm.org eingebaute Suche basiert AFAIK auf Nominatim, das sucht vorwiegend nach Namen und Adressen (also z.B. Orts- oder Straßennamen).
Doof finde ich das auch. Weil es ein schlechtes Bild davon abgibt, was OSM kann.

Kann es sein, dass die OSM Suche das shop=copyshop ignoriert und stattdessen nur Ergebnisse bringt, die "copyshop" im Namen tragen?

Da wäre dann etwas zu verbessern, hier https://github.com/osm-search/Nominatim unter issues können Vorschläge eingereicht werden.

Ganz so einfach wird es aber nicht, zB findet "Leipzig Kopierladen" gar nichts.

desputin wrote:

Ist ja leider nur eines von vielen Beispielen, wo die Suche von OSM Schrott ist... Wißt Ihr, weshalb es so schwer fällt, hier mehr Ergebnisse zu finden?

Augen aufmachen könnte helfen!
Unter den ersten beiden Suchtreffern (die "Copyshop" auch im Namen haben) ist ein großer blauer Button "mehr Treffer". Wenn ich den anklicke, erhalte ich den von Dir gesuchten Copyshop als dritten Suchtreffer!

Mammi71 wrote:

ein großer blauer Button "mehr Treffer"

<ironie>alles ab Seite 2 der Ergebnisliste existiert nicht. 😄 </ironie>

Hallo Ihr,
vielen Dank für die Antworten.

Den "mehr Treffer" Button hatte ich tatsächlich noch nie gesehen, obwohl ich openstreetmap.org mehrmals wöchentlich nutze!
Daß aber für eine Großstadt wie Leipzig mit vermutlich 10 Copyshops nur zwei standardmäßig angezeigt werden, finde ich schwach.

Leider ist es in Diensten, die OSM als Basis nutzen auch nicht besser. In OSMand+ für Android z.B. habe ich auch keine vernünftige Suche für sagen wir Copyshops. Oder aber auch bei https://www.qwant.com/maps nicht. Wenn ich da Copyshop und Leipzig eingebe, werden mir auch nur 2 Ergebnisse angezeigt...

In Osmand klappt die Suche bei mir ganz gut.
Ich gehe auf das Lupensymbol, klicke auf Categories (hab die Standardsprache von Android auf englisch umgestellt) und tippe Copy Shop ein. Als erstes Ergebnis wird mir direkt die Übergeordnete Kategorie "Copy Shop" angezeigt.
Auf der Karte werden dann alle Copyshops hervorgehoben.

desputin wrote:

Hallo Ihr,
vielen Dank für die Antworten.

Den "mehr Treffer" Button hatte ich tatsächlich noch nie gesehen, obwohl ich openstreetmap.org mehrmals wöchentlich nutze!
Daß aber für eine Großstadt wie Leipzig mit vermutlich 10 Copyshops nur zwei standardmäßig angezeigt werden, finde ich schwach.

Leider ist es in Diensten, die OSM als Basis nutzen auch nicht besser. In OSMand+ für Android z.B. habe ich auch keine vernünftige Suche für sagen wir Copyshops. Oder aber auch bei https://www.qwant.com/maps nicht. Wenn ich da Copyshop und Leipzig eingebe, werden mir auch nur 2 Ergebnisse angezeigt...

Vielleicht auch die "Suche" der Suchmaschine "Qwant" unter Produkten rechts oben nutzen:
( https://www.qwant.com/?q=copyshop+leipzig&t=web ) - Für Qwant_Maps habe ich eine Email geschrieben, diese "gesamten" Suchergebnisse zur Maps-Anzeige zu nutzen.

flosm ( https://www.flosm.de/html/index.html ) hat auch eine POI-Karte ( https://www.flosm.de/html/POI-Karte.htm … 0&st=1&sw= ). Da shop=copyshop dort noch fehlt, habe ich eine Email geschrieben und hoffe ist beim nächsten Update mit online.

Manchmal findet man etwas beim "Nachbarn": OpenPoiMap ( http://mijndev.openstreetmap.nl/~marczo … FFFFFFFFFF )

Wenn man erst die Suchmaschine suchen muss, welche einem die gewünschten Ergebnisse (wie man's erwarten würde) anzeigt, dann läuft wohl etwas schief 🙄

Ich ärger mich auf öfters mit der osm.org-Suche. Scheinbar wird zunächst wirklich nur ausgegeben, was 1:1 im Namen und Adresse deckungsgleich gefunden wird.
"copyshop leipzig" findet halt (als Direkttreffer) die beiden genannten, "copy shop leipzig" findet hingegen nur https://www.openstreetmap.org/node/2168715847 welches auch wirklich "copy shop" im Namen mit drin hat.
Und erst das weitere Treffer scheint dann weitere Tags zu berücksichtigen. Was natürlich hier tragisch ist, wenn der Tag-Value gar 1:1 dem Suchtext entspricht. Mitlerweile suche ich auch meist selbst mit Overpass-Turbo und bastel mir Abfragen zusammen, weil's in meinen Augen zuverlässiger ist, aber ganz sicher kein bisschen laiennutzbar.

Aus Nutzersicht sind viele Treffer bezüglich des Copyshop in Leipzip absolut gleichwertig, aber nur 1 oder 2 werden vor dem Klick auf "Weitere Treffer" angezeigt - das ist kaum erwartbar und verständlich. Otto Normal wird denken "schade, gibt in OSM wohl nur 2 welche erfasst sind" und geht weiter (zu Google).
Da sollte schon was passieren, denn:

FraukeLeo wrote:

Weil es ein schlechtes Bild davon abgibt, was OSM kann.

Es fehlen also aus meiner Sicht verschiedene Dinge bzw. sind verbesserungswürdig:

• die "weiteren" Suchergebnisse sollten wohl direkt mit ausgegeben werden (ggf. mit einer Linie getrennt, aber nicht erst durch einen zusätzlich Klick)
• ebenfalls Oberfläche betreffend ist, dass es laienunfreundlich ist, dass es nach einem Klick auf ein Suchergebnis kein Weg zurück zur Ergebnisliste gibt. Gerade hier stört es, dass die "weiteren Treffer" bei einem "zurück" (je nach Browser, ob dieser halt ggf. cacht) wieder weg sind. Ein sauberes Paging wäre hier wünschenswert und flüssiges hin- und zurück.
• ebenfalls Oberfläche betreffend wäre gut, wenn man alle/mehrere Ergebnisse gleichzeitig auf der Karte anschauen kann. Was bringt es einem, wenn man im Urlaub ist und Pizzeria in xyz sucht und dann sich durch 10 Treffer klicken muss, wo genau diese sind. In Kombi mit 2. ist das einfach nur - ätzend.
Ja, hier kann man natürlich in neuem Tab das Ergebnis öffnen (ist 1. wieder nicht typisch für Laien und 2. nervend zig Tabs mit unterschiedlicher bbox zu vergleichen)
• Die Gewichtung von Einträgen wohl überarbeitet werden. Bei nur "copy shop leipzig" ist arg unklar, wieso https://www.openstreetmap.org/node/6265922610 erst nach 2x Klick auf "weitere Treffer" auftaucht, obwohl sowohl copy als auch shop im Namen und shop-Value-Tag auftauchen (und andere Treffe davor nur shop=copyshop haben).
• Anteilig vorhandene Begrifflichkeiten werden aktuell Null berücksichtigt. Sucht man z.B. nach https://www.openstreetmap.org/search?qu … %20leipzig kommt nichts, sucht man https://www.openstreetmap.org/search?qu … %20leipzig findet man ein Treffer der "kopier-," im Namen enthält
• Ideal wäre, wenn automatisch verschiedene Sprachversionen/Übersetzungen probiert werden. Sodass, sucht man "copy" kommen halt auch Einträge wie "Kopierladen". Was natürlich schwierig ist, da ersten die Daten für solche Begriffsbeziehungen fehlen (naja, könnte man durchaus aus OSM-Daten erschaffen, welche Begrifflichkeiten halt zusammenhängen - shop=copyshop wird wohl öfters im Namen "copy", "kopier", "laden", "druck", ... enthalten) und zweitens es komplex wird, dies performant auszuwerten.
Aber dass halt aktuell OSM bei https://www.openstreetmap.org/search?qu … %20leipzig nichts ausspuckt ist halt blöd

Ich weiß ich weiß, muss sich halt jemand finden das umzusetzen. Aber bevor man jemanden sucht/findet der etwas umsetzt, sollte man/wir erstmal feststellen, was wir eigentlich wollen. Daher erstmal hier wild aufgelistet.

FraukeLeo wrote:

Versuch mal https://photon.komoot.io/

Exakt das selbe ;-)

Gruß,
asca

dabei funktioniert es ja auf deutsch
noch ziemlich gut, „Domhof Köln“ findet die Straße Am Domhof in Köln.
„Milano Piazza Duomo“ hatte bis vorgestern nur Treffer in Piacenza, erst nachdem der Piazza del Duomo noch einen short name bekommen hat wird der Domplatz in Mailand gefunden

Nach jahrelangem Zaudern sind wir mittlerweile soweit, dass wir allen Straßen (wenn sie gefunden werden sollen) noch short names hinzufügen wo die Artikel und Vornamen weggelassen werden.
Alle Alternativen zu Straßentypenarten als alt_names einzutragen ist derzeit noch nicht üblich (und wäre auch falsch), manches kann man nur sinnvoll über den Suchalgorithmus lösen (z.b. dass Via und Viale und Vicolo alles Straßen sind, bei einer Suche nach Via würde man gerne auch z.B. eine entsprechende Viale finden, vor allem wenn es keine Via gibt, ähnlich auch Piazza, Piazzale, Piazzetta).

Ich gebe meinen Vorrednern Recht, die Suche ist superzentral für das Bild, dass wir nach außen abgeben.

kleine Ergänzung zur Copyshop-Suche. Versuch's mal mit http://overpass-turbo.eu/ Copy&Paste.

/*
Try␣Overpass␣query␣by␣pressing␣the␣Run␣button␣above!
*/
node
[shop=copyshop]
({{bbox}});
out;

Ja, ich weiss, dass ist eher ein Insider-Tipp, aber manchmal hilfreich.

googlenaut wrote:

Ja, ich weiss, dass ist eher ein Insider-Tipp, aber manchmal hilfreich.

1. Genau, Insider. Aber eigentlich erwarte ich genau das von einer Suche, wenn ich nach "Copyshop" "Kopieren" usw. in Nominatim suche.....
   

Gerade auch wieder was komisches mit der Suche von OSM.org

Suche nach "Schulstraße 56a 13591 Berlin", also:
https://www.openstreetmap.org/search?qu … 7/13.12977
und ich erhalte "Keine Ergebnisse gefunden".
Dachte mir erst, ok, dann ist das Haus wohl noch nicht drin, Objekt gibt es aber: https://www.openstreetmap.org/node/2872480113

Drum wollte ich jetzt hier den Beitrag schreiben und öffne neue Browser-Instanz (sprich ein anderen Browser sozusagen) und beim Test ob die Links im Beitrag richtig von mir sind raufgeklickt und.... oh wunder, jetzt kommt exakt das eine Ergebnis.
Bin dann nochmal in den vorherigen Browser rein, es kommt immernoch kein Ergebnis. Mit STRG+F5 (also Reload ohne Cache) erhalte ich auch im ursprünglichen Browser dann das Ergebnis.

Hä? Kommt mir so vor als würde "kein Ergebnis" zurückgeworfen, bevor die Suche schon richtig abgeschlossen bzw. die erste Suche dafür sorgen, dass Daten in Nominatim in einem Cache landen und dann erst bei einer neuen Suchanfrage auch ausgeliefert werden.

Ganz ehrlich, würde sagen, dass ist mir schon öfters vorgekommen. Kann mich öfters daran erinnern, etwas gesucht zu haben und "Kein Ergebnis" als Antwort zu bekommen, obwohl es etwas ziemlich sicher in OSM vorhandenes war. Normalerweise stoße ich dann nur nicht eine neue Suche mit einem anderen Browser an, sondern suche "händisch" bzw. via Overpass ^^

Ist natürlich auch arg kontraproduktiv, wenn eine falsche Antwort zurückkommt.

SafetyIng wrote:

googlenaut wrote:

Ja, ich weiss, dass ist eher ein Insider-Tipp, aber manchmal hilfreich.

1. Genau, Insider. Aber eigentlich erwarte ich genau das von einer Suche, wenn ich nach "Copyshop" "Kopieren" usw. in Nominatim suche.....
   

ja, Nominatim will ja explizit keine POIs indexieren (als strukturierte Informationen über das Ding, abgesehen von der Adresse und Lagebeschreibung), bzw. nur wenige als Demo (Briefkästen und Postämter und so). Vielleicht würden die Entwickler diese Einstellung nochmal überdenken, wenn sich jemand oder eine Gruppe finden würde, die die erforderlichen Informationen (tags, ggf. eine strukturierte Beschreibung wie die Dinge zusammenhängen, Übersetzungen, etc.) pflegen würde. Oder man könnte die Overpass-API dafür nutzen, so wie es jetzt auch schon Nominatim und Geonames gibt als Suchergebnisse und man es nutzt um Objekte neben dem Zeiger zu suchen? Sofern man sich nicht nur an Mapper richten will, bräuchte man da auch Listen von Dingen die zu tags gemappt werden für die Abfrage.

"Die Suche ist Schrott und kann sich icht mit Google messen" finde ich immer harten Tobak.

Ist doch klar, Google betreibt umfangreiches Datensammeln, merkt sich "halbgefragt" die Plätze und Restaurants in denen ich schonmal war oder nach denen ich mal gesucht hab usw...

Das hat dann natürlich Vorteile, denn Google kann wissen, das ich mit "Big Wong" vermutlich das Restaurang meine, wo ich schonmal war und weis eh meistens wo ich mich befinde - und nicht irgendwas anderes.

Die Google Dienste werden ja immer besser, je mehr man sie benutzt. Aber das hat seine Schattenseiten.

Gut die OSM Dienste machen das ohne - und das ist gut so. Ich muss mir aber klarmachen, dass ein Verzicht auf Datenweitergabe nicht ohne Verzicht auf Komfort durch Datenauswertung gehen kann...

Skinfaxi wrote:

Das hat dann natürlich Vorteile, denn Google kann wissen, das ich mit "Big Wong" vermutlich das Restaurang meine, wo ich schonmal war und weis eh meistens wo ich mich befinde - und nicht irgendwas anderes.

geschenkt, aber dass mir wenn ich auf Rom gezoomt bin und nach „Pizzeria“ suche als erster Treffer eine Felswand in der Schweiz mit diesem Namen präsentiert wird, das könnte man auch ohne Suchhistorie fixen. Nominatim bewertet lokale Suchen immer noch nicht wichtig genug im Vergleich zu 500km entfernten, gerade bei so allgemeinen und unspezifischen Suchworten.

Oder wenn ich nach „Milano Piazza Duomo“ suche (Domplatz in Mailand), dass dann der Domplatz in Piacenza gefunden wird weil der als „Piazza Duomo“ eingetragen war, während der Mailänder als „Piazza del Duomo“ nicht gefunden (wurde), das müsste die Engine auch ohne weitere Unterstützung hinbekommen. Mittlerweile geht es weil ich „Piazza Duomo“ als alt_name eingetragen habe, aber das führt in der Konsequenz dazu dass man alle möglichen Varianten und Schreibweisen eintragen muss, einmal mit Vornamen und einmal ohne, und dass jegliche Artikel und Präpositionen nicht weggelassen werden können, und jeder einzelne falsche Buchstabe dazu führt, dass das richtige nicht mehr gefunden wird, das liegt nicht nur daran dass wir keine Suchhistorie wie Google haben.

Anderes Beispiel: https://www.openstreetmap.org/search?qu … 9/13.41175

da finde ich die Stadt/Land Berlin zwar nicht, aber einzelne Häuser und POIs, erster Treffer in Mitte und nicht in Brandenburg. Ich würde da irgendwo einen Treffer für den BER erwarten.

Hierzu passend aus dem Vortrag "10 Jahre OpenStreetMap - Wir leben noch und zwar sehr gut.":

https://media.ccc.de/v/31c3_-_6255_-_de … eih#t=1808

Funktioniert heute übrigens nicht mehr. 😉

dieterdreist wrote:

Skinfaxi wrote:

Das hat dann natürlich Vorteile, denn Google kann wissen, das ich mit "Big Wong" vermutlich das Restaurang meine, wo ich schonmal war und weis eh meistens wo ich mich befinde - und nicht irgendwas anderes.

geschenkt, aber dass mir wenn ich auf Rom gezoomt bin und nach „Pizzeria“ suche als erster Treffer eine Felswand in der Schweiz mit diesem Namen präsentiert wird, das könnte man auch ohne Suchhistorie fixen.
...

Wieso hast du es dann nicht schon längst gemacht?

SimonPoole wrote:

Wieso hast du es dann nicht schon längst gemacht?

ich kann es nicht. Das heißt aber nicht, dass es unlösbar ist. Man müsste lokal höher gewichten. Und außerdem ist es wohl derzeit auch nicht gewünscht dass die Suche versucht, möglichst viele POI-Typen zu finden, das ist also auch eine politische Frage, wenn es eine klare Anleitung gäbe was man in welcher Form liefern muss, damit eine bestimmte Suchanfrage gelöst werden kann, und ggf. wie man Übersetzungen liefern kann, dann kann ich mir gut vorstellen dass es viele Beiträge geben würde. Wenn man erstmal Nominatim komplett verstehen muss um mitzuhelfen wird der Kreis der potentiellen Helfer sehr klein.

dieterdreist wrote:

SimonPoole wrote:

Wieso hast du es dann nicht schon längst gemacht?

ich kann es nicht. Das heißt aber nicht, dass es unlösbar ist. Man müsste lokal höher gewichten. ...

Nur willst du dann genau das Gegenteil wenn du zufälligerweise die Felswand "Pizzeria" suchst, und wirst dann argumentieren, dass wenn die Namen genau übereinstimmen, dass natürlich höher gewichtet sein sollte.

SimonPoole wrote:

Nur willst du dann genau das Gegenteil wenn du zufälligerweise die Felswand "Pizzeria" suchst, und wirst dann argumentieren, dass wenn die Namen genau übereinstimmen, dass natürlich höher gewichtet sein sollte.

Wenn ich wirklich die Felswand Pizzeria suchen würde oder den Berg Shell, dann ginge das wahrscheinlich nur mit Nominatim, die Suchmaschinen würden nur Pizzerien „Felswand“ liefern, bzw. Tankstellen und corporate infos. 😉

Aber davon abgesehen, ein Ergebnis weit weg will man schonmal grundsätzlich selten, fast alle Suchanfragen gehen über lokale Themen.

https://www.openstreetmap.org/search?query=pizza

da bekomme ich ein village in Nigeria, eine Residential auf den Philippinen und als drittes einen fast food in Hillingdon greater London und als viertes ein Restaurant in Paris. Auch wenn ich die Siedlungen und Straßen vor den Pois finden will, die Pois will ich lokal, nicht zufällig.

Wenn man dem aktuellen Kartenausschnitt (und in höheren Zoomstufen mit puffer drumrum) noch viel mehr Gewicht geben würde wäre das auf jeden Fall sinnvoll. Dass ich in Rom Pizza suche und nur was in London und Paris finde, daran sollte man doch was ändern, oder?

Wenn man noch einen Ort dazuschreibt sieht es natürlich anders aus, aber ohne Ort ist doch klar dass die Pois lokal sein müssen.

@DieterDreist:

Nominatim hat diese Fähigkeit (Lokailtät des derzeitigen Kartenausschnitts zu beachten), sie wird aber auf der Webseite openstreetmap.org nicht eingesetzt.

Das ist also ein Frontendproblem. Da bräuchte es ein Häckchen in der Art von "nur im Kartenausschnitt suchen" und dann ginge das besser.

Beispiel (Karte auf Hamburg gezoomt und Pizzeria gesucht) mit dem Frontend von Nominatim, wo man es anwenden kann:

https://nominatim.openstreetmap.org/ui/ … &bounded=1

Dort sieht man, dass die Häckchen bei viewbox und bounded von mir gesetzt sind. Dies könnte man auch im Frontend von www.openstreetmap.org umsetzen. Dafür müsste man ein Issue bei https://github.com/openstreetmap/openst … ite/issues eröffnen (bzw. am besten ein Issue gleich mit PR 😉.

dieterdreist wrote:

...
Wenn man noch einen Ort dazuschreibt sieht es natürlich anders aus, aber ohne Ort ist doch klar dass die Pois lokal sein müssen.

Aber du suchst gar nicht nach einem POI sondern nach einem Objekt mit Namen "Pizza".

und einen POI search gibt es in rudimentärer Form bei Nominatim auch:

Drei Beispiele:

https://www.openstreetmap.org/search?qu … 0in%20rome

https://www.openstreetmap.org/search?qu … 20fountain

https://www.openstreetmap.org/search?qu … 0manhattan

ansonsten ist dafür natürlich die overpass-api besser.

Und das sollte übrigens auch mit Copyshop funktionieren, Beispiel:

https://www.openstreetmap.org/search?qu … %20dresden

Wichtig: POI search funktioniert mit z.B. "Begriff" "in" "Ort", nicht mit "Ort" "Begriff" (siehe auch: https://wiki.openstreetmap.org/wiki/Nom … Phrases/DE )

Allerdings scheint es da bei Leipzig ein Problem zu haben mit "Copyshop in Leipzig", da kommt bei mir nur ein Ergebnis, während ich über overpass einige finde: https://overpass-turbo.eu/s/1cmr

Edit: bei "Copyshop in Leipzig" muss ein komisches Problem vorliegen, hier mit einer Nominatim Installation z.B. bei osmap.de funktioniert es (auch wenn da das Frontend die Ergebnisse auf 5 begrenzt).

Und da man bei Nominatim auch so suchen kann:

https://www.openstreetmap.org/search?qu … 3%2C7.6956, wäre für web-frontends oder apps es auch ziemlich einfach möglich, eine umkreissuche zu machen.

Also: so mangelhaft wie behauptet, ist in meinen Augen die Suche über Nominatim nicht. Oftmals sind es eher ungenügende Frontends, die die Fähigkeiten von Nominatim nicht ausschöpfen.

Spiekerooger wrote:

Und das sollte übrigens auch mit Copyshop funktionieren, Beispiel:

https://www.openstreetmap.org/search?qu … %20dresden

führt bei mir aktuell zu

Ergebnisse von OpenStreetMap Nominatim

Error contacting nominatim.openstreetmap.org: 502

-/

Spiekerooger wrote:

Also: so mangelhaft wie behauptet ist in meinen Augen die Suche über Nominatim nicht. Oftmals sind es eher ungenügende Frontends, die die Fähigkeiten von Nominatim nicht ausschöpfen.

Les' dir allein mal den Betreff dieses Themas durch. Er lautet nicht "Mangelhaftes Suchen mit Nominatim", sondern "Mangelhafte Suchfunktion von OpenStreetmap(.org/de)". Aber ist schonmal schön zu wissen, dass Nominatim mehr kann, als die aktuellen Frontends anbieten.

Nichtdestoweniger gibt's wohl aber auch weiterhin noch Probleme direkt mit Nominatim, wenn wie oben geschildert Errors zurückkommen; bei Erstsuche kein Ergebnis kommt; "komische Probleme" vorliegen; etc. Das trübt halt zusätzlich, sodass OSM-Neunutzer (die nicht einfach Reload machen) halt schnell zu dem Ergebnis kommen "OSM taugt nichts", was natürlich falsch bezüglich dem Datenbestand ist.
Und du kannst halt nicht von Otto Normal erwarten, dass er sich an eine Suchsyntax für Basissuchen halt hält. Für die meisten ist es nicht verständlich, wenn "Copyshop Leipzig" andere Ergebnisse als "Copyshop in Leipzig" liefert. Otto Normal beschäftigt sich auch nicht damit ob etwas ein "POI" oder nur "ein Objekt" ist und er entsprechend anders suchen müsste. Wenn also das die eine gewählte Suchanfrage von vielen möglichen (und für Otto Normal gleichen) Suchanfragen halt kein Ergebnis liefert - dann heißt es für ihn, dass die gesuchten Dinge nicht in OSM existieren. Findet er sie dann auf anderem Wege, findet er OSM halt kacke.
Das geht mir hier nicht darum irgendwas schlecht zu reden, sondern einfach nur die Sichtweise von einfachen Nutzern darzulegen. Und wie man dem ganzen Verlauf hier entnehmen kann, haben auch regelmäßige OSM-Nutzer mit der/n Suchfunktion(en) ihre Probleme.

Denn wie ich zu Beginn schon schrieb:

the-asca wrote:

Wenn man erst die Suchmaschine suchen muss, welche einem die gewünschten Ergebnisse (wie man's erwarten würde) anzeigt, dann läuft wohl etwas schief

Also sollte die Frage lauten: Welche Dinge können wir jetzt konkret tun, damit es aus Nutzersicht besser wird:

• Checkbox auf der Webseite für lokale Suche
Hierzu ein Issue am besten erstellen und wenn jemand Webentwicklung kann, am besten gleich Codeänderung dabei vorschlagen
(heißt lokale Suche, dass nur in der BBox gesucht wird? Frage ist halt, ob nicht eher eine einstellbare Umkreissuche vom aktuellen Mittelpunkt sinniger/intuitiver wäre. Denn vl. bin ich gerade sehr nah rangezoomt und erhalte dann ein "hier gibt es nichts", obwohls nur 400m weiter existiert)
• bessere Liste der Suchergebnisse, darunter fällt:

• bei Klick wird nicht alles neu geladen, sondern nur die Karte dorthin verschoben, sodass man wieder zurückgehen kann zur Ergebnisliste
(sprich ein Zurück zur Ergebnisliste erzeugt nicht quasi erneut die gleiche Suche, wie es aktuell ist)
• sauberes Paging und kein unnachvollziehbarer "mehr"-Button
• Option, dass man alle Ergebnisse (ggf. nur der aktuellen Ergebnislisten-Seite) zusammen auf der Karte als Marker sieht

Das sind auch Punkte, die man ebenso als Issue einstellen kann und ideal ein Webentwickler Code-Vorschläge macht
• Stabilität von Nominatim verbessern. Sprich keine 502, keine "gibt keine Ergebnisse" obwohl gleiche Suche kurz später welche liefert (oder ist das ein Frontend-Fehler?), etc.
• Nominatim beibringen Sucheingaben besser zu verstehen. Darunter fällt das Einbeziehen von Übersetzungen, Synonymen und leicht geänderte Schreibweisen von Suchbegriffen.
Idealer weise sollte "Kopieren <Stadt>", "Kopie <Stadt>", "Kopierladen <Stadt>", "Kopierladen in <Stadt>", "Copyshop <Stadt>", "Copyshop in <Stadt>", ... allesamt eben mind. sämtliche Copyshops in <Stadt> halt auflisten (Dass natürlich bei "Kopie <Stadt>" auch noch deutlich mehr Beifang entsteht ist klar und erwartbar, aber eben nicht, dass viele Copyshops wegfallen wie's aktuell ist).

1. und 2. könnte ich mich sehen, dass ich mich da reinarbeite. Aktuell privat und beruflich leider kaum Zeit... naja, Weihnachtsurlaub st ja nicht mehr weit ;-)
Bei 3. und 4. kann ich außer Theorie und Gedanken nicht mehr zu Beisteuern.

Gruß,
asca

PS: Nachdem jetzt einige Zeit beim Schreiben vergangen ist, kommt nun der 502-Error aktuell nicht mehr... hmm...

Die 502er sehe ich heute auch oft, da scheint Nominatim überlastet zu sein. Das ist ein grundsätzliches Philosophieproblem der fehlenden Zugriffsbeschränkung, die immer wieder zu viele Scraper etc. auf den Plan ruft.

Ansonsten ist die Liste von Dir, the-asca, eine sehr gute Ideenliste der Verbesserungsvorschläge für das Frontend und andere Verbesserungen.

Und zu 4.:

Da kann jeder etwas beitragen, indem die SpecialPhrases Listen erweitert werden. Dafür braucht es keinerlei Programmierkenntnisse, nur osm tag Kenntnisse. Siehe: https://wiki.openstreetmap.org/wiki/Nom … al_Phrases

Die Tabellen im Wiki zu den einzelnen Sprachen bei der SpecialPhrases sind sonst ziemlich selbst erklärend.

(Dabei bitte beachten: <Suchbegriff> <Ort> ist leider manchmal unpraktisch, besser ist <Suchbegriff> <in|in der Nähe von| im|etc.> <Ort>). Ok bei z.B. Zahnarzt/Apotheke/Spielplatz, etc., schwierig bei z.B. Restaurant oder Hotel etc. Wenn man da <Suchbegriff> <Ort> verwendet, dann bitte mit Operator '-' (any).
Warum? Weil z.B. mit Restaurant Roma direkt ein Restaurant namens Restaurant Roma in X gemeint sein kann und nicht alle Restaurants in Rom.

the-asca wrote:

• Checkbox auf der Webseite für lokale Suche

Man könnte eine DB auf Tilebasis aufsetzen, in dem restlos alle Begriffe des jeweiligen Tiles unter dessen Tilenummer gespeichert sind. Je nach Zoomstufe sind ja immer nur eine begrenzte Anzahl Tiles zu sehen. Eine Suchfunktion braucht nun also nur noch die Nummern der sichtbaren Tiles aufrufen und deren Einträge mit dem Suchbegriff abgleichen.
"Bayern" würde also nur gefunden, wenn man auf Europaebene rauszoomt. Hat man auf München gezoomt, wird z.B. der Laden eines bekannten Fußballvereins gefunden und dessen Sportgelände.

Spiekerooger wrote:

(Dabei bitte beachten: <Suchbegriff> <Ort> ist leider manchmal unpraktisch, besser ist <Suchbegriff> <in|in der Nähe von| im|etc.> <Ort>). Ok bei z.B. Zahnarzt/Apotheke/Spielplatz, etc., schwierig bei z.B. Restaurant oder Hotel etc. Wenn man da <Suchbegriff> <Ort> verwendet, dann bitte mit Operator '-' (any).
Warum? Weil z.B. mit Restaurant Roma direkt ein Restaurant namens Restaurant Roma in X gemeint sein kann und nicht alle Restaurants in Rom.

Eventuell könnte man überlegen halt dem Nutzer alternative Suchvorschläge zu machen, wenn sich dafür ein Algorithmus findet, wie man aus einer gegebenen Suchanfrage halt Alternativen erzeugt.
Sprich dass halt bei "Restaurant Roma" irgendwo steht (direkt als Link um entsprechende Suche anzutriggern): Meinten sie vl. "Restaurant in Roma" oder "Restaurant bei Roma"?
Da kann man sicherlich was aus den SpecialPhrases-Listen was schaffen. Oder halt gleich im Frontend, dass dieses halt dann diese Suchen gleich mit anstößt, was natürlich für mehr Nominatim-Last erzeugen würde. Aber aus Nutzersicht halt besser gleich Alternativ-Ergebnisse zu sehen.

KPG wrote:

the-asca wrote:

• Checkbox auf der Webseite für lokale Suche

Man könnte eine DB auf Tilebasis aufsetzen, in dem restlos alle Begriffe des jeweiligen Tiles unter dessen Tilenummer gespeichert sind. Je nach Zoomstufe sind ja immer nur eine begrenzte Anzahl Tiles zu sehen. Eine Suchfunktion braucht nun also nur noch die Nummern der sichtbaren Tiles aufrufen und deren Einträge mit dem Suchbegriff abgleichen.
"Bayern" würde also nur gefunden, wenn man auf Europaebene rauszoomt. Hat man auf München gezoomt, wird z.B. der Laden eines bekannten Fußballvereins gefunden und dessen Sportgelände.

Warum etwas neues erfinden, wenn's wohl Nominatim schon kann?

Facilmap kann Copyshops anzeigen: https://facilmap.org/#15/51.3440/12.390 … o_copyshop

Spiekerooger wrote:

und einen POI search gibt es in rudimentärer Form bei Nominatim auch:

Drei Beispiele:

https://www.openstreetmap.org/search?qu … 0in%20rome

https://www.openstreetmap.org/search?qu … 20fountain

https://www.openstreetmap.org/search?qu … 0manhattan

ansonsten ist dafür natürlich die overpass-api besser.

dass es für ein paar wenige Typologien geht und für andere nicht, ist Teil des Problems. Die Nutzer denken, man kann nach POIs suchen (über den typ), weil es manchmal funktioniert.

Der Link von Spiekerooger ist interessant.

https://www.openstreetmap.org/search?qu … %20münchen
findet beides bei mir allerdings auf Anhieb nur 2 Treffer, beides Biergärten in Spanien, nach click auf "mehr" dann auch in Pullach (Landkreis München) und als viertes einen in München.

Sehe jetzt, so geht es: https://www.openstreetmap.org/search?qu … n%20munich

Was bestens funktioniert hat ist "Bordell in Karlsruhe", sofort auch ohne "mehr" 10 Treffer: https://www.openstreetmap.org/search?qu … 0karlsruhe

Spiekerooger wrote:

Da kann jeder etwas beitragen, indem die SpecialPhrases Listen erweitert werden. Dafür braucht es keinerlei Programmierkenntnisse, nur osm tag Kenntnisse. Siehe: https://wiki.openstreetmap.org/wiki/Nom … al_Phrases

Die Tabellen im Wiki zu den einzelnen Sprachen bei der SpecialPhrases sind sonst ziemlich selbst erklärend.

Kleine Anmerkung .. das letzte Mal, als ich da was eingetragen habe( 2017), hat's 'ne ganze Weile gedauert, bis jemand die Änderungen mit in die aktuelle Suchsystematik übernommen hatte (soweit ich mich erinnere ein manueller, sporadisch angestossener Prozess).

Gruß
tux67

Ja, das ist ein manueller Prozess, der nicht regelmäßig stattfindet. Umsomehr lohnt es sich wohl, die gewünschten Eintragungen drin zu haben, bevor dieser Prozess das nächste Mal durchläuft.

Spätestens wenn Nominatim auf 4.0 springt, dürfte es ein neuladen der Datenbank geben und diesen Moment will man doch nicht verpasst haben.

Gutes Beispiel für die Suche, auf https://openstreetmap.de/karte.html 82544 Deining eingeben und suchen lassen. Es wird der richtige Ort gefunden. Jetzt noch die Moosstr. 8, getrennt durch ein Komma dran hängen und Suchen. Jetzt landet man in (92364 Deining) der Oberpfalz, obwohl es die Moosstr. 8 in 82544 Deining gibt und sogar die Hausnummer getaggt ist. Google Maps hab ich nicht probiert, aber Bing Maps findet es korrekt, zuerst den Ort, dann zusätzlich noch die Hausnummer in der Straße.

Gibt es eine Stelle an die man sich wenden kann? Ist die Programmierung hier so kompliziert um das 'richtige' Ergebnis anzuzeigen?

Ich empfehle OpenStreetMap Freunden und Bekannten, wenn ich dann allerdings solche Beispiele genannt bekomme, kann ich immer nur den Kopf schütteln über so eine grottenschlechte Programmierung. Sorry, anders kann ich es nicht nennen.

WST1961 wrote:

landet man in (92364 Deining) der Oberpfalz, obwohl es die Moosstr. 8 in 82544 Deining

Immer langsam mit den Pferden. Du selbst hast die Adresse eingetragen. Zwischen Deining und Egling ist halt schon ein Unterschied, meinst du nicht?

edit:doppelt

dooley wrote:

WST1961 wrote:

landet man in (92364 Deining) der Oberpfalz, obwohl es die Moosstr. 8 in 82544 Deining

Immer langsam mit den Pferden. Du selbst hast die Adresse eingetragen. Zwischen Deining und Egling ist halt schon ein Unterschied, meinst du nicht?

Deining ist ein Ortsteil von Egling, siehe Wikipedia: https://de.wikipedia.org/wiki/Egling Die Moosstr. gibt es nur in Deining, nicht in Egling. Aber trotzdem wird z.B. im Ausweis Egling, OT Deining eingetragen. Was taggt man dann richtigerweise? Beide Orte? Oder Egling OT Deining?

Dass ich den Ort selbst eingetragen habe, ist richtig. Es wurde mir kein Deining im Dropdown angeboten, deshalb hatte ich Egling genommen. Hab es jetzt auf Deining abgeändert.

Such doch mal nach 82544 Egling und nach 82544 Deining. Bei Egling wird nicht direkt Egling gefunden, sondern 'weit' weg vom eigentlichen Egling: https://www.openstreetmap.org/edit#map= … 4/11.51040 In Egling hab ich jetzt den postalcode 82544 nachgetragen.

BTW: Eine Suche auf Bing Maps nach Moosstr.8, 82544 Egling bringt das richtige Ergebnis, die Moosstr. 8 in Deining.

Aus den OSM-Daten ist nicht ersichtlich, dass Deining ein Ortsteil von Egling ist. Eine irgendwie geartete Zuordnung könnte man mit viel gutem Willen durch spatiale Abfragen erreichen, wenn es genau dieses Deining überhaupt als Place- oder administrative Entität in OSM gäbe. Gibt es aber nicht, weil ein Mapper vor einem Monat den place-key gelöscht hat.

https://www.openstreetmap.org/node/9585 … 13/11.5008

WST1961 wrote:

Aber trotzdem wird z.B. im Ausweis Egling, OT Deining eingetragen. Was taggt man dann richtigerweise? Beide Orte? Oder Egling OT Deining?

Ohne jetzt Dein spezielles Problem besonders analysiert zu haben, im Wiki gibt's da Beschreibungen dazu, das muss man nicht im Forum erfragen. Hint: addr:city und addr:suburb könnte Abhilfe schaffen oder bei dooley mal den Link in der Signatur klicken und auf Deinen Bereich zoomen. (Oder beides)

Grundsätzlich, auch wenn man mit iD unterwegs ist, sollte man das Wiki beachten. Da gibt es eine nette Seite, die das mit den Adressen IMHO recht gut erklärt: https://wiki.openstreetmap.org/wiki/DE:Key:addr

WST1961 wrote:

Aber trotzdem wird z.B. im Ausweis Egling, OT Deining eingetragen. Was taggt man dann richtigerweise? Beide Orte? Oder Egling OT Deining?

In dem Fall wäre addr:city = Egling und addr:suburb = Deining wohl nicht verkehrt.

Edit: Upps, da war MKnight schneller ;-)

Moin,

WST1961 wrote:

Deining ist ein Ortsteil von Egling, siehe Wikipedia: https://de.wikipedia.org/wiki/Egling Die Moosstr. gibt es nur in Deining, nicht in Egling. Aber trotzdem wird z.B. im Ausweis Egling, OT Deining eingetragen. Was taggt man dann richtigerweise? Beide Orte? Oder Egling OT Deining?

Letzteres:
addr:city = Egling
addr:suburb = Deining
Überlasse ich Dir zum Ändern.

Allerdings fehlte im OT Deining auch der place-node - habe ich mal nachgetragen.

Grüße
Georg

GeorgFausB wrote:

Allerdings fehlte im OT Deining auch der place-node - habe ich mal nachgetragen.

Warum hast du nicht den genommen und angepasst? https://www.openstreetmap.org/node/9585 … 13/11.5008 Dar war nämlich schon mal ein place=village, siehe Beitrag #38

dooley wrote:

GeorgFausB wrote:

Allerdings fehlte im OT Deining auch der place-node - habe ich mal nachgetragen.

Warum hast du nicht den genommen und angepasst? https://www.openstreetmap.org/node/9585 … 13/11.5008 Dar war nämlich schon mal ein place=village, siehe Beitrag #38

Sorry, die Beiträge haben sich überschnitten - hatte die Antwort vorher begonnen, wurde durch den fehlenden place abgelenkt, hab's bearbeitet ohne erst nach dem Namen zu suchen und hab sie später ohne vorheriges Update abgeschickt ...

Ok, dieses "OT Deining"-Beispiel ist kein Beispiel dafür, dass es was in Nominatim oder der Oberfläche zu verbessern gäbe, sondern tatsächlich in den Quelldaten.

Denn Nominatim findet halt "82544 Deining" weil es als einzelner Node erfasst ist. Damit ist aber natürlich Nominatim nicht klar, dass die Häuser rings um (wie weit denn auch?) zu "82544 Deining" gehören. Die Häuser selbst haben halt nur erfasst:

addr:city=Egling
addr:postcode=82544
addr:street=...
addr:housenumber=...

ohne

addr:suburb=Deining

Ist ja dann unklar, dass es der Ortsteil Deining von Egling ist. Teils sind die Häuser auch erfasst mit:

addr:city=Egling

wie die #6 und #4 und dann werden sie auch gefunden.

Also entweder müsste man überall sie so erfassen:

addr:city=Egling
addr:postcode=82544
addr:suburb=Deining
addr:street=...
addr:housenumber=...

Oder aber man gibt die Daten an diesem Way an, welcher alles umschließt?
https://www.openstreetmap.org/way/77813399
Da bin ich mir aber nicht sicher, ob das jetzt so "richtig" wäre oder doch besser eine Relation, welche diesen Way als auch die Node halt umfasst?

Des weiteren hattest du einen Typo-Fehler, du hast adr:suburb geschrieben statt addr:suburb. Habe ich eben fix gefixt: https://www.openstreetmap.org/changeset/113023793

Aber ja, letztlich ist auch dies ein Punkt, weshalb die Suche teils unverständliche Ergebnisse liefert. Liegt nicht an der Software, sondern am Datenbestand. Aber das müssen wir ja jetzt nicht diskutieren, denn da ist ja sowieso klar, dass wir da alle gemeinsam unser bestes tun, dies nach und nach zu verbessern. Ggf. könnte man überlegen, wie man solche "Fehler" im Datenbestand eventuell entdecken kann.

Moin,

the-asca wrote:

Denn Nominatim findet halt "82544 Deining" weil es als einzelner Node erfasst ist. Damit ist aber natürlich Nominatim nicht klar, dass die Häuser rings um (wie weit denn auch?) zu "82544 Deining" gehören.

zwar nicht "klar" - aber Nominatim wertet da schon ggf. den Abstand aus.
Was aber ja bei klein-/großräumigen Siedlungsflecken nebeneinander auch zu Mißinterpretationen führt - eben wegen des "wie weit".

Grüße
Georg

Spiekerooger wrote:

[...]
Da kann jeder etwas beitragen, indem die SpecialPhrases Listen erweitert werden. Dafür braucht es keinerlei Programmierkenntnisse, nur osm tag Kenntnisse. Siehe: https://wiki.openstreetmap.org/wiki/Nom … al_Phrases

Die Tabellen im Wiki zu den einzelnen Sprachen bei der SpecialPhrases sind sonst ziemlich selbst erklärend.
[...]

Interessanter Hinweis...

In der DE-Liste findet sich auch "Naturschutzgebiet" und zwar mit diesen 2 Tagging-Varianten
landuse=conservation (in D glücklicherweise ungebräuchlich)
leisure=nature_reserve (problematisch, sollte/kann langfristig ganz entfallen)

Der korrekte Erkennungs-Tag wäre eigentlich:
protection_title=Naturschutzgebiet

Das gilt natürlich nur, wenn der Nutzer dezidiert NSGs nach deutschem Recht sucht,
wer dies meint: "NSGs und grob vergleichbare Schutzgebiete - weltweit":
protect_class=4

wenn dies meint "irgendwelche Schutzgebiete des Natur- und Landschaftsschutzes - weltweit":
boundary=protected_area

Dieses semantische Problem ist schwer lösbar...

Beim "Berg" ist das einfacher, und ich bin die etwas sperrige Sache mal probehalber angegangen:
https://wiki.openstreetmap.org/w/index. … id=2212285
wer nach "Gipfel" oder "Berggipfel" sucht hat wohl Pech;-)

"Naturschutzgebiet in [...]"
liefert Treffer, in der Form
"Naturschutzgebiet Dönche, Heinrich-Schütz-Allee, Dönche, Kassel, Niestetal, Hessen, 34134, Deutschland"

Suche nach "Dönche" dagegen
"Schutzgebiet Dönche, Kassel, Niestetal, Hessen, Deutschland"

was mich zu der Frage bringt, gibt es für den output, bzw. dessen Benennung auch derartige Listen?

Bezüglich https://wiki.openstreetmap.org/wiki/Nom … Phrases/DE frage ich mich allerdings wie sinnvoll dies ist bzw. müsste um gut zu wirken deutlich aufgeblasen werden.
Beispielsweise gibt's ja noch in https://wiki.openstreetmap.org/wiki/Nom … ases/DE_AT "Wirtshaus" für amenity=restaurant, welches in DE als Restaurant, Gaststätte und Gasthaus eingetragen ist und mir fallen da fix noch Wirtschaft, Gasthof fix zusätzlich ein

Und so ist es bei vielen Eintragungen dort, dass man noch zig Synonyme eintragen könnte:
Flughafen: Flugplatz, Airport, Lufthafen
Tierpension: Tierunterkunft, Tiersitter und dann noch je Tierart (Pferdepension/-unterkunft, Katzen-..., Hunde-...)
Kulturzentrum: für amenity=arts_centre laut DE-Wiki "Kunstzentrum"
Geldautomat: Bankomat
Bar: Kneipe, Lokal, Schänke, Cocktailbar, Pub
...
Gemeinschaftszentrum: für amenity=community_centre steht ebenfalls im Wiki zig Dinge: "Gemeinschaftszentrum (Kulturhaus, Bürgerhaus, Dorfgemeinschaftshaus, Jugendzentrum, ...)"

Müssen wir die Liste jetzt als stark aufblähen, sodass eben die Suche verbessert wird? Frage ist ja auch bei sowas wie Bar (amenity=bar), Pub/Kneipe (amenity=pub) ... der Nutzer der Kneipe sucht, sucht ganz sicher nicht vl. doch auch eine Bar?

Frage mich, was passiert, wenn ein Nutzer eine Bank sucht in einer Gegend wo viele Sitzbänke erfasst sind, denn beides ist in der Liste als "Bank" eingetragen:
Bank: amenity=bank
Bank: amenity=bench

Jetzt kann man natürlich hergehen und es zu "Sitzbank: amenity=bench" ändern und dann kommt der Nutzer der sich ausruhen will und einfach "Bank" sucht ^^

Also kurz zusammengefasst:
Gut, dass wir via Wiki-Eintragungen dort etwas verbessern könnten, aber so richtig weiß ich jetzt nicht wie und was sinnvoll wäre?
Wenn ich jetzt für alle zig Synonym-Eintragungen mache, werde ich dann von irgendjemand anderem wiederum dafür erschlagen (weil die Wikiseite aufgrund der Länge gar nicht mehr läd ^^)?

Oder habe ich den Zweck dieser Liste grob missverstanden?

Jo Cassel wrote:

wenn dies meint "irgendwelche Schutzgebiete des Natur- und Landschaftsschutzes - weltweit":
boundary=protected_area

wobei das noch weiter geht und auch andere Schutzgebiete miteinschließt, zumindest laut Definition

the-asca wrote:

Müssen wir die Liste jetzt als stark aufblähen, sodass eben die Suche verbessert wird? Frage ist ja auch bei sowas wie Bar (amenity=bar), Pub/Kneipe (amenity=pub) ... der Nutzer der Kneipe sucht, sucht ganz sicher nicht vl. doch auch eine Bar?

insbesondere dass es Sinn machen soll, in, um, im, nahe bei, in der Nähe von, usw. für jeden einzelnen Suchbegriff erneut komplett zu wiederholen kann ich mir nicht vorstellen. Das müsste man mit einer einmaligen Übersetzung ausreichend beschrieben haben.

Für die Angabe von Synonymen und Pluralformen wäre es vielleicht auch sinnvoller, das übersichtlicher zu sammeln.

Dass man nur einen tag angeben kann und keine Kombinationen ist eine Beschränkung die Nominatim hat, oder nicht grundsätzlich?

MKnight wrote:

WST1961 wrote:

Aber trotzdem wird z.B. im Ausweis Egling, OT Deining eingetragen. Was taggt man dann richtigerweise? Beide Orte? Oder Egling OT Deining?

Ohne jetzt Dein spezielles Problem besonders analysiert zu haben, im Wiki gibt's da Beschreibungen dazu, das muss man nicht im Forum erfragen. Hint: addr:city und addr:suburb könnte Abhilfe schaffen oder bei dooley mal den Link in der Signatur klicken und auf Deinen Bereich zoomen. (Oder beides)

Danke für den Hinweis auf addr:suburb. Ich wußte nicht, dass es so getaggt wird, deshalb hier auch die Nachfrage. Jetzt hab ich es in der Beschreibung nachgelesen. Und ja, ich habe schon viel im Wiki nachgeschlagen und nachgelesen.

Nachgesehen habe ich schon auf der Website von dooley, aber mir hat sich noch nicht erschlossen, wie mir das helfen soll. Vielleicht mag mich jemand erhellen, Danke.

the-asca wrote:

Ok, dieses "OT Deining"-Beispiel ist kein Beispiel dafür, dass es was in Nominatim oder der Oberfläche zu verbessern gäbe, sondern tatsächlich in den Quelldaten.

Denn Nominatim findet halt "82544 Deining" weil es als einzelner Node erfasst ist. Damit ist aber natürlich Nominatim nicht klar, dass die Häuser rings um (wie weit denn auch?) zu "82544 Deining" gehören. Die Häuser selbst haben halt nur erfasst:

addr:city=Egling
addr:postcode=82544
addr:street=...
addr:housenumber=...

ohne

addr:suburb=Deining

Ist ja dann unklar, dass es der Ortsteil Deining von Egling ist. Teils sind die Häuser auch erfasst mit:

addr:city=Egling

wie die #6 und #4 und dann werden sie auch gefunden.

Also entweder müsste man überall sie so erfassen:

addr:city=Egling
addr:postcode=82544
addr:suburb=Deining
addr:street=...
addr:housenumber=...

Oder aber man gibt die Daten an diesem Way an, welcher alles umschließt?
https://www.openstreetmap.org/way/77813399
Da bin ich mir aber nicht sicher, ob das jetzt so "richtig" wäre oder doch besser eine Relation, welche diesen Way als auch die Node halt umfasst?

Ich weiß es nicht was die bessere Variante ist, die paar Adressen in der Moosstraße hab ich jetzt man mit addr:suburb getaggt.

the-asca wrote:

Des weiteren hattest du einen Typo-Fehler, du hast adr:suburb geschrieben statt addr:suburb. Habe ich eben fix gefixt: https://www.openstreetmap.org/changeset/113023793

Danke, und wieder was gelernt. 😉

dieterdreist wrote:

[...]
insbesondere dass es Sinn machen soll, in, um, im, nahe bei, in der Nähe von, usw. für jeden einzelnen Suchbegriff erneut komplett zu wiederholen kann ich mir nicht vorstellen. Das müsste man mit einer einmaligen Übersetzung ausreichend beschrieben haben.

Für die Angabe von Synonymen und Pluralformen wäre es vielleicht auch sinnvoller, das übersichtlicher zu sammeln.
[...]

... genau das waren auch meine Gedanken, nach meinem Berg-Test, warum müssen die Einschub-Phrasen abgearbeitet werden, warum braucht es für ein Synonym einen kompletten neuen "Datensatz", wo doch zusätzlich 1x Singular + 1x Plural völlig ausreichen sollten.
(Und mit nur immer genau einem Tag wird sich schwerlich alles korrekt auflösen lassen.)

Den Ansatz die Community da mitwerkeln zu lassen finde ich super, aber als "Übergabeschnittstelle" für einfache Fälle würde ich mir eine einfache Lösung wünschen:
Tag:natural=peak
DE:Singular/Plural: Berg/Berge; Gipfel/Gipfel; Berggipfel/Berggipfel; Berg-Gipfel/Berg-Gipfel;
(Das könnte auch einfach in/mit der jeweiligen Tag-Dokumentation passieren, statt auf abgelegenen Wiki-Seiten)

WST1961 wrote:

Nachgesehen habe ich schon auf der Website von dooley, aber mir hat sich noch nicht erschlossen, wie mir das helfen soll. Vielleicht mag mich jemand erhellen, Danke.

Ich hatte nicht geschaut, bin davon ausgegangen, dass https://osm-suspects.gbconsite.de/#18/4 … tive-dupes mehr Fehler wirft.
Gerade doch mal geschaut, und das Problem ist: Da aktuell nur recht wenig Adressen dort eingetragen sind, gibt es auch recht wenig Fehler 😉

Jo Cassel wrote:

Den Ansatz die Community da mitwerkeln zu lassen finde ich super, aber als "Übergabeschnittstelle" für einfache Fälle würde ich mir eine einfache Lösung wünschen:
Tag:natural=peak
DE:Singular/Plural: Berg/Berge; Gipfel/Gipfel; Berggipfel/Berggipfel; Berg-Gipfel/Berg-Gipfel;
(Das könnte auch einfach in/mit der jeweiligen Tag-Dokumentation passieren, statt auf abgelegenen Wiki-Seiten)

Is mir auch aufgefallen, für "in", "in der Nähe von" "bei" usw usf. brauchts imho nicht jeweils 'ne eigene Definition. Eigentlich brauchts gar keine, Suchbegriff XY sollte stumpf alles relevante ausgeben und solche "Füllworte" wegwerfen.

Hi,

ich weiß nicht ob's hier hinpasst, aber in Mönchengladbach habe ich nach einpflegen der Stadtteilgrenzen durch einen Mapper mal bewusst nach Ortsteilen gesucht. Zur Zeit ist hier eine lustige Gemengelage von place Nodes, landuse=residential mit Ortsnamen und admin boundaries.
Wenn man zum Beispiel nach "Rheindahlen" sucht, findet man nur eine Admin Boundary ( Rheindahlen-Land, West, Mönchengladbach, North Rhine-Westphalia, Germany) , aber nicht den Place node der nur den Namen Rheindahlen trägt oder die Admin Boundary Rheindahlen-Mitte.

Gibt's da irgendeine Hierarchie oder Logik bei der Suche? Die Place nodes finde ich dabei unerlässlich als Bestandteil des Ergebnisses, da Otto Normaluser eher nach dem simplen OT Namen sucht, als den Stadtbezirksnamen (der auch mehrere OT's beinhalten kann).

Gruß
tux67

tux67 wrote:

[...]m Beispiel nach "Rheindahlen" sucht, findet man nur eine Admin Boundary ( Rheindahlen-Land, West, Mönchengladbach, North Rhine-Westphalia, Germany) , aber nicht den Place node der nur den Namen Rheindahlen trägt oder die Admin Boundary Rheindahlen-Mitte.[...]

Beim Tagging der Grenzrelationen und der zugehörigen place-nodes läuft in OSM öfters was suboptimal...

Es gibt die Grenzrelation "Rheindahlen-Mitte"
https://www.openstreetmap.org/relation/13155289
und den place-node "Rheindahlen"
https://www.openstreetmap.org/node/59970201
beide mit identischen Wikidata-Tag

So ein node lässt sich der Grenzrelation als label oder admin_centre fest zuordnen, vgl.
https://wiki.openstreetmap.org/wiki/DE: … nselemente
was auch unbedingt empfehlenswert ist, und sei es nur um Tag-Dopplung zu vermeiden.
Außerdem würde ich hier der Grenzrelation ein alt_name=Rheindahlen spendieren (oder "Rheindahlen-Mitte" zum alt_name umtaggen) - dann dürfte das auch mit der Suche klappen.

MKnight wrote:

WST1961 wrote:

Nachgesehen habe ich schon auf der Website von dooley, aber mir hat sich noch nicht erschlossen, wie mir das helfen soll. Vielleicht mag mich jemand erhellen, Danke.

Ich hatte nicht geschaut, bin davon ausgegangen, dass https://osm-suspects.gbconsite.de/#18/4 … tive-dupes mehr Fehler wirft.
Gerade doch mal geschaut, und das Problem ist: Da aktuell nur recht wenig Adressen dort eingetragen sind, gibt es auch recht wenig Fehler 😉

Danke, zwei Fehler korrigiert. 😉

wie seht ihr das bei place-Flächen für die es keine admin boundary gibt?
Ein Beispiel: https://www.openstreetmap.org/relation/5454344

Soll oder kann man da zusätzlich entsprechende place nodes machen, oder wenn kann man sie auch weglassen?

dieterdreist wrote:

Soll oder kann man da zusätzlich entsprechende place nodes machen, oder wenn kann man sie auch weglassen

Persönlich sage ich, dass man ihn weglassen kann, place=* wird über 1 Mio. mal an Ways und 1/4 Mio. mal an Relationen verwendet. Da sollte man dann davon ausgehen, dass sowas ausgewertet wird.... Wenn nicht, sollte der Datenauswerter sich anpassen.

dieterdreist wrote:

wie seht ihr das bei place-Flächen für die es keine admin boundary gibt?
Ein Beispiel: https://www.openstreetmap.org/relation/5454344

Soll oder kann man da zusätzlich entsprechende place nodes machen, oder wenn kann man sie auch weglassen?

Mmh ... als Fläche...Da habe ich ehrlich gesagt keine Erfahrung, sehe das aber eher kritisch.
Die Kombination Grenzrelation + place-node (in so einem Fall als label eingebunden) halte ich für besser und auswertungsfreundlicher.

Aber zu italien/Rom kann ich da nichts sagen ... sowas z.B.
https://www.openstreetmap.org/relation/1458218
admin_level=10
population=195867
kommt mir seltsam vor.

Jo Cassel wrote:

Beim Tagging der Grenzrelationen und der zugehörigen place-nodes läuft in OSM öfters was suboptimal...

...

Danke .. ich hab' mal einen Optimierungs-Feldversuch gestartet ...

Jo Cassel wrote:

Aber zu italien/Rom kann ich da nichts sagen ... sowas z.B.
https://www.openstreetmap.org/relation/1458218
admin_level=10
population=195867
kommt mir seltsam vor.

was ist daran komisch?

Ist so ähnlich wie hier
https://www.openstreetmap.org/relation/16347

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

Jo Cassel wrote:

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

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
)

Jo Cassel wrote:

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

Jo Cassel wrote:

... 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;-)

Jo Cassel wrote:

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;-)

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 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?qu … ile-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.

dieterdreist wrote:

[...]
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, [...]

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)

Jo Cassel wrote:

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.

dieterdreist wrote:

Jo Cassel wrote:

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.
[...]

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,

Jo Cassel wrote:

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.

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

Jo Cassel wrote:

Ehrlicherweise sollte man es wohl so sagen:
"wer die Namen aus place-Flächen nutzten will, ist gezwungen die OSM-Daten zu dedublizieren",

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/openstr … /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 … ry%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/ … 736/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-rheinl … 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.

Kelso-Mg wrote:

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.

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

Kelso-Mg wrote:

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-rheinl … 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.

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

seichter wrote:

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

+1

seichter wrote:

(suburb, quarter, neighbourhood) mit der Interpretation "Grenzen für Verwaltung" und nicht "Grenzen von Verwaltung".

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.

seichter wrote:

Kelso-Mg wrote:

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.

Für Stadtteile ohne Verwaltung ist die Einordnung unter AL=10 gebräuchlich.

In Deuschland.

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

Damit lässt sich natürlich alles rechtfertigen, auch ein level 14 admin boundary um jedes Grundstück.

SimonPoole wrote:

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?