Moin,
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
Warum hast du nicht den genommen und angepasst? https://www.openstreetmap.org/node/95855586/history#map=15/47.9513/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,
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
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.php?title=Nominatim%2FSpecial_Phrases%2FDE&type=revision&diff=2212583&oldid=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/Nominatim/Special_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/Nominatim/Special_Phrases/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?
wobei das noch weiter geht und auch andere Schutzgebiete miteinschließt, zumindest laut Definition
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?
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.
Ich weiß es nicht was die bessere Variante ist, die paar Adressen in der Moosstraße hab ich jetzt man mit addr:suburb getaggt.
Danke, und wieder was gelernt. 
… 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)
Ich hatte nicht geschaut, bin davon ausgegangen, dass https://osm-suspects.gbconsite.de/#18/47.94802/11.49452/osm-wrongcity-minimalmissing-wrongstreet-wronghousenumber-outsideplz-falsepositive-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
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
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:Gemeindegrenze#Zus.C3.A4tzliche_Relationselemente
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.
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?
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.
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.