Re: [Talk-de] Update von nominatim.osm.org
Harald aug...@hotmail.de writes: Ähmm, der Zusatz Spreewald dürfte ja wohl mehr oder weniger zwingend in den name-Tag gehören, da der offizielle Name meines Wissen eben Lübben (Spreewald). In meinen augen gehört so etwas nach name_official. -- Karl Eichwalder ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update von nominatim.osm.org
Hallo Sarah, Am Dienstag, 11. September 2012, 18:31:15 schrieb Sarah Hoffmann: bin mir immer noch nicht sicher, warum es nicht funktioniert. Beispiel Aystetten: Suche ( http://nominatim.openstreetmap.org/search.php?q=Aystetten ) liefert sowohl Relation als auch Knoten, aber: – die Relation und der Knoten heißen gleich – die Relation ( http://www.openstreetmap.org/browse/relation/44 ) enthält den Knoten mit Rolle label – die Änderungen sind schon vor ein paar Tagen passiert Es gab da noch ein Problem mit den Updates von Place-Boundary-Verbindungen. Im Code ist das bereits repariert, aber der OSM-Server wird erst in ca. 2 Wochen das nächste Software-Update erhalten. Es wird wegen dem Lizenzwechsel auch nochmal einen Neuimport der Datenbank geben in naher Zukunft. Spätestens dann sollten deine Änderungen sichtbar sein. ich nehme an, den Neuimport hat es schon gegeben? Das Beispiel funktioniert leider immer noch nicht. Eckhart ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update von nominatim.osm.org
On Wed, Oct 03, 2012 at 05:19:24PM +0200, Eckhart Wörner wrote: Hallo Sarah, Am Dienstag, 11. September 2012, 18:31:15 schrieb Sarah Hoffmann: bin mir immer noch nicht sicher, warum es nicht funktioniert. Beispiel Aystetten: Suche ( http://nominatim.openstreetmap.org/search.php?q=Aystetten ) liefert sowohl Relation als auch Knoten, aber: – die Relation und der Knoten heißen gleich – die Relation ( http://www.openstreetmap.org/browse/relation/44 ) enthält den Knoten mit Rolle label – die Änderungen sind schon vor ein paar Tagen passiert Es gab da noch ein Problem mit den Updates von Place-Boundary-Verbindungen. Im Code ist das bereits repariert, aber der OSM-Server wird erst in ca. 2 Wochen das nächste Software-Update erhalten. Es wird wegen dem Lizenzwechsel auch nochmal einen Neuimport der Datenbank geben in naher Zukunft. Spätestens dann sollten deine Änderungen sichtbar sein. ich nehme an, den Neuimport hat es schon gegeben? Das Beispiel funktioniert leider immer noch nicht. Der Neuimport steht leider immernoch aus. Wenn nichts dazwischen kommt, wird es wohl übernächstes Wochenende passieren. Gruss Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update von nominatim.osm.org
Hallo Sarah, Am Mittwoch, 3. Oktober 2012, 17:59:26 schrieb Sarah Hoffmann: Der Neuimport steht leider immernoch aus. Wenn nichts dazwischen kommt, wird es wohl übernächstes Wochenende passieren. alles klar, danke. Eckhart ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update von nominatim.osm.org
Am 23. September 2012 19:59 schrieb Georg Feddern o...@bavarianmallet.de: Es mag sein, dass sich das zu 90% aus den Gegebenheiten (place der Ortschaft/Verwaltung) so ergibt, aber: Mir fällt auf Anhieb ein Beispiel ein, wo diese Bedingung gar nicht so einfach zu erfüllen ist: http://www.openstreetmap.org/?lat=54.3245lon=10.3945zoom=14layers=M Die Gemeinde Fargau-Pratjau ist ein Zusammenschluß der beiden namensgebenden Ursprungs-Gemeinden/Ortschaften. Ich wüsste nicht, welchen place-Typ ich da verwenden sollte, da es außer der Gemeinde gar keinen place dieses Namens gibt. (Auch wenn ein label bei dieser Gebietsform nicht notwendig ist.) Du verwechselst hier glaube ich 2 Arten von Objekten: administrative Grenzen und topographische Orte. In Deinem Beispiel würde ich für Fargau und Pratjau jeweils ein place-Objekt erwarten dagegen für Fargau-Pratjau überhaupt kein place-Objekt sondern ein administratives mit boundary=administrative und admin_level=x Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update von nominatim.osm.org
Moin, Am 24.09.2012 11:10, schrieb Martin Koppenhoefer: Du verwechselst hier glaube ich 2 Arten von Objekten: administrative Grenzen und topographische Orte. In Deinem Beispiel würde ich für Fargau und Pratjau jeweils ein place-Objekt erwarten dagegen für Fargau-Pratjau überhaupt kein place-Objekt sondern ein administratives mit boundary=administrative und admin_level=x nö, das ist mir schon klar, ich will ja auch gar keinen place-node für die Gemeinde setzen. Aber Sarah ist (war?) der Auffassung, dass Die Label-Node sollte schon eine normale place-Node sein Nur dem halte ich entgegen, dass das a) gar nicht immer möglich ist b) für das label nur die Koordinaten benötigt werden, also doch gar keine Tags am node nötig wären Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update von nominatim.osm.org
Am 24.09.2012 12:06, schrieb Georg Feddern: Nur dem halte ich entgegen, dass das a) gar nicht immer möglich ist b) für das label nur die Koordinaten benötigt werden, also doch gar keine Tags am node nötig wären Würde ich auch denken. label soll ja nur für den Renderer anzeigen, wo er das Label am besten platzieren sollte, bzw. wo der Ortsmittelpunkt ist. Die anderen Infos stecken in der Admin-Relation drin. Es kann aber sein, dass der label-Node zusätzlich auch noch Tags hat, u.a. auch ein place. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update von nominatim.osm.org
fly wrote: On 09/09/12 01:46, Sarah Hoffmann wrote: On Sat, Sep 08, 2012 at 09:56:37PM +0200, fly wrote: Das war bisher der 1. Treffer: http://www.openstreetmap.org/browse/relation/1629146 Sollte eigentlich alles soweit enthalten. Da hat sich in der Tat ein Bug eingeschlichen. Dass admin_level ohne ein boundary=administrative verwendet wird, war nicht vorgesehen. Oh, dass habe ich wohl übersehen. Verstehe selber nicht warum das da fehlt, aber lasse es erstmal so. Wie sich herausstellte, war die Sache mit den Azoren noch etwas komplizierter. Die Relation enthält eine label-Node, die keine Tags hat. Das hat Nominatim verwirrt. Ich habe das jetzt gefixt, sodass er damit umgehen kann (wobei es allerdings zwei, drei Wochen brauchen wird, bis die Änderung auf dem Hauptserver ankommt). Allerdings ist diese Art von Tagging IMHO doch eher fragwürdig. Die Label-Node sollte schon eine normale place-Node sein und ausserdem innerhalb des Gebietes liegen, die es beschreibt und nicht irgendwo im Meer. Das scheint mir zumindest der Konsens anderswo zu sein. Gruss Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update von nominatim.osm.org
Moin, Am 23.09.2012 17:51, schrieb Sarah Hoffmann: Die Label-Node sollte schon eine normale place-Node sein Es mag sein, dass sich das zu 90% aus den Gegebenheiten (place der Ortschaft/Verwaltung) so ergibt, aber: Mir fällt auf Anhieb ein Beispiel ein, wo diese Bedingung gar nicht so einfach zu erfüllen ist: http://www.openstreetmap.org/?lat=54.3245lon=10.3945zoom=14layers=M Die Gemeinde Fargau-Pratjau ist ein Zusammenschluß der beiden namensgebenden Ursprungs-Gemeinden/Ortschaften. Ich wüsste nicht, welchen place-Typ ich da verwenden sollte, da es außer der Gemeinde gar keinen place dieses Namens gibt. (Auch wenn ein label bei dieser Gebietsform nicht notwendig ist.) Aber auch sonst ist in meinen Augen selbst der Name am label-node nicht notwendig, da der node ja eigentlich nur die Position des Labels angibt, alle notwendigen Informationen sich aber sonst aus der Relation ergeben. Insofern ist ein tag-loser node in meinen Augen eigentlich eher die Regel (-Möglichkeit) denn die Ausnahme. Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update von nominatim.osm.org
Hi, On Sun, Sep 09, 2012 at 05:03:06PM +0200, Stefan wrote: mir ist aufgefallen, dass eine Suche nach Fahltskamp[1] zwei Ergebnisse liefert. Eine in Pinneberg-Mitte und eine in Thesdorf. Dies ist aber nur eine (verbundene) Straße (in Pinneberg-Mitte). Die Unterteilung ist notwendig, da sich die oneway Eigenschaft ändert. Ist hier was an den Daten nicht richtig, oder kann nominatim damit nicht um? Nominatim kann Duplikate schon erkennen, aber natürlich nur, wenn sie im gleichen Stadtteil liegen. In diesem Fall ist das Problem, dass die Stadtteile nur als place-Nodes vorhanden sind und er falsch rät in welchem Stadteil der eine Teil der Strasse ist. Wenn du die Stadtteile als boundary-Relationen einträgst, sollten die Duplikate verschwinden. Gruss Sarah Am 26.08.2012 20:44, schrieb Sarah Hoffmann: Hi, wie einige vielleicht mitbekommen haben, hat Nominatim, die OSM-Suche, in den letzten Wochen ihre Updates ausgesetzt gehabt, um den Redaction-Bot passieren zu lassen. Inzwischen ist eine neue Datenbank eingespielt und die Suche ist wieder minuten-aktuell wie gewohnt. Bei dieser Gelegenheit hat der Server auch ein Software-Update bekommen. Neben kleineren Bugfixes gibt es drei grössere Neuerungen: die Art wie die Adressen ermittelt werden, wurde etwas verbessert, Orten wird jetzt mit Hilfe von Wikipedia-Artikeln eine Wichtigkeit zugeordnet und es gibt jetzt eine Erkennung wo Grenzrelationen und Place-Nodes zusammengehören. Ein paar kurze Worte zu den letzten beiden Punkten. Nominatim ermittelt jetzt mit Hilfe von Wikipedia-Artikeln, wie bekannt ein Ort ist und nutzt das, um die Reihenfolge zu verbessern, mit der die Suchergebnisse ausgegeben werden. Zum Beispiel liefert die Suche nach 'Brooklyn' jetzt tatsächlich als erstes Resultat den bekannten Stadtteil von New York und nicht irgendeinen Weiher im mittleren Westen der USA. Für die richtige Zuordnung der Orte hilft es ungemein, wenn das 'wikipedia'-Tag in einer seiner Varianten gesetzt ist. Sollten irgendwo also noch eine komische Reihenfolge bei der Suche herauskommen, erstmal schauen, ob das wikipedia-Tag noch fehlt. Für das Erkennen von Duplikaten bei Grenzrelationen und Place-Nodes wertet Nominatim jetzt sowohl die Rolle 'label' als auch 'admin_centre' in den Grenzrelatioen aus, wobei Nodes mit 'admin_centre' nur zusammengefasst werden, wenn Name und Admin-Level stimmen. Fehlen beide, rät Nominatim, welcher Place-Node zur Relation passen könnte. Das funktioniert aber nur beschränkt gut, weil es keine weltweit eindeutige Zuordnung zwischen admin-level und place-Wert gibt. Die Node explizit zur Relation zuzufügen ist daher zuverlässiger. Wenn für eine Grenzrelation ein Place-Node gefunden wurde, werden dessen Koordinaten auch als Zentrum der Relation zurückgegeben, was praktisch immer zu besseren Ergebnissen führt, als der Mittelpunkt der Relation, der bisher verwendet wurde. Bugs können wie üblich entweder im trac gemeldet werden oder aber auch gerne auf der geocoding Mailingliste diskutiert werden oder hier auf talk-de. An dieser Stelle noch einen Dank an alle, die bei dem Update mitgeholfen haben, insbesondere aber an Brian Quinion, der den Grossteil der Neuerungen implementiert hat. Gruss Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update von nominatim.osm.org
On Tue, Sep 11, 2012 at 07:31:23AM +0200, Eckhart Wörner wrote: Am Sonntag, 26. August 2012, 20:44:13 schrieb Sarah Hoffmann: Für das Erkennen von Duplikaten bei Grenzrelationen und Place-Nodes wertet Nominatim jetzt sowohl die Rolle 'label' als auch 'admin_centre' in den Grenzrelatioen aus, wobei Nodes mit 'admin_centre' nur zusammengefasst werden, wenn Name und Admin-Level stimmen. Fehlen beide, rät Nominatim, welcher Place-Node zur Relation passen könnte. Das funktioniert aber nur beschränkt gut, weil es keine weltweit eindeutige Zuordnung zwischen admin-level und place-Wert gibt. Die Node explizit zur Relation zuzufügen ist daher zuverlässiger. Wenn für eine Grenzrelation ein Place-Node gefunden wurde, werden dessen Koordinaten auch als Zentrum der Relation zurückgegeben, was praktisch immer zu besseren Ergebnissen führt, als der Mittelpunkt der Relation, der bisher verwendet wurde. bin mir immer noch nicht sicher, warum es nicht funktioniert. Beispiel Aystetten: Suche ( http://nominatim.openstreetmap.org/search.php?q=Aystetten ) liefert sowohl Relation als auch Knoten, aber: – die Relation und der Knoten heißen gleich – die Relation ( http://www.openstreetmap.org/browse/relation/44 ) enthält den Knoten mit Rolle label – die Änderungen sind schon vor ein paar Tagen passiert Es gab da noch ein Problem mit den Updates von Place-Boundary-Verbindungen. Im Code ist das bereits repariert, aber der OSM-Server wird erst in ca. 2 Wochen das nächste Software-Update erhalten. Es wird wegen dem Lizenzwechsel auch nochmal einen Neuimport der Datenbank geben in naher Zukunft. Spätestens dann sollten deine Änderungen sichtbar sein. Gruss Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update von nominatim.osm.org
Danke für die Antwort, leider habe ich keine Informationen wo die Grenze verläuft... Ich werde weiter suchen. Viele Grüße Stefan Am 11.09.2012 18:26, schrieb Sarah Hoffmann: Hi, On Sun, Sep 09, 2012 at 05:03:06PM +0200, Stefan wrote: mir ist aufgefallen, dass eine Suche nach Fahltskamp[1] zwei Ergebnisse liefert. Eine in Pinneberg-Mitte und eine in Thesdorf. Dies ist aber nur eine (verbundene) Straße (in Pinneberg-Mitte). Die Unterteilung ist notwendig, da sich die oneway Eigenschaft ändert. Ist hier was an den Daten nicht richtig, oder kann nominatim damit nicht um? Nominatim kann Duplikate schon erkennen, aber natürlich nur, wenn sie im gleichen Stadtteil liegen. In diesem Fall ist das Problem, dass die Stadtteile nur als place-Nodes vorhanden sind und er falsch rät in welchem Stadteil der eine Teil der Strasse ist. Wenn du die Stadtteile als boundary-Relationen einträgst, sollten die Duplikate verschwinden. Gruss Sarah Am 26.08.2012 20:44, schrieb Sarah Hoffmann: Hi, wie einige vielleicht mitbekommen haben, hat Nominatim, die OSM-Suche, in den letzten Wochen ihre Updates ausgesetzt gehabt, um den Redaction-Bot passieren zu lassen. Inzwischen ist eine neue Datenbank eingespielt und die Suche ist wieder minuten-aktuell wie gewohnt. Bei dieser Gelegenheit hat der Server auch ein Software-Update bekommen. Neben kleineren Bugfixes gibt es drei grössere Neuerungen: die Art wie die Adressen ermittelt werden, wurde etwas verbessert, Orten wird jetzt mit Hilfe von Wikipedia-Artikeln eine Wichtigkeit zugeordnet und es gibt jetzt eine Erkennung wo Grenzrelationen und Place-Nodes zusammengehören. Ein paar kurze Worte zu den letzten beiden Punkten. Nominatim ermittelt jetzt mit Hilfe von Wikipedia-Artikeln, wie bekannt ein Ort ist und nutzt das, um die Reihenfolge zu verbessern, mit der die Suchergebnisse ausgegeben werden. Zum Beispiel liefert die Suche nach 'Brooklyn' jetzt tatsächlich als erstes Resultat den bekannten Stadtteil von New York und nicht irgendeinen Weiher im mittleren Westen der USA. Für die richtige Zuordnung der Orte hilft es ungemein, wenn das 'wikipedia'-Tag in einer seiner Varianten gesetzt ist. Sollten irgendwo also noch eine komische Reihenfolge bei der Suche herauskommen, erstmal schauen, ob das wikipedia-Tag noch fehlt. Für das Erkennen von Duplikaten bei Grenzrelationen und Place-Nodes wertet Nominatim jetzt sowohl die Rolle 'label' als auch 'admin_centre' in den Grenzrelatioen aus, wobei Nodes mit 'admin_centre' nur zusammengefasst werden, wenn Name und Admin-Level stimmen. Fehlen beide, rät Nominatim, welcher Place-Node zur Relation passen könnte. Das funktioniert aber nur beschränkt gut, weil es keine weltweit eindeutige Zuordnung zwischen admin-level und place-Wert gibt. Die Node explizit zur Relation zuzufügen ist daher zuverlässiger. Wenn für eine Grenzrelation ein Place-Node gefunden wurde, werden dessen Koordinaten auch als Zentrum der Relation zurückgegeben, was praktisch immer zu besseren Ergebnissen führt, als der Mittelpunkt der Relation, der bisher verwendet wurde. Bugs können wie üblich entweder im trac gemeldet werden oder aber auch gerne auf der geocoding Mailingliste diskutiert werden oder hier auf talk-de. An dieser Stelle noch einen Dank an alle, die bei dem Update mitgeholfen haben, insbesondere aber an Brian Quinion, der den Grossteil der Neuerungen implementiert hat. Gruss Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update von nominatim.osm.org
Hi, Am Sonntag, 26. August 2012, 20:44:13 schrieb Sarah Hoffmann: Für das Erkennen von Duplikaten bei Grenzrelationen und Place-Nodes wertet Nominatim jetzt sowohl die Rolle 'label' als auch 'admin_centre' in den Grenzrelatioen aus, wobei Nodes mit 'admin_centre' nur zusammengefasst werden, wenn Name und Admin-Level stimmen. Fehlen beide, rät Nominatim, welcher Place-Node zur Relation passen könnte. Das funktioniert aber nur beschränkt gut, weil es keine weltweit eindeutige Zuordnung zwischen admin-level und place-Wert gibt. Die Node explizit zur Relation zuzufügen ist daher zuverlässiger. Wenn für eine Grenzrelation ein Place-Node gefunden wurde, werden dessen Koordinaten auch als Zentrum der Relation zurückgegeben, was praktisch immer zu besseren Ergebnissen führt, als der Mittelpunkt der Relation, der bisher verwendet wurde. bin mir immer noch nicht sicher, warum es nicht funktioniert. Beispiel Aystetten: Suche ( http://nominatim.openstreetmap.org/search.php?q=Aystetten ) liefert sowohl Relation als auch Knoten, aber: – die Relation und der Knoten heißen gleich – die Relation ( http://www.openstreetmap.org/browse/relation/44 ) enthält den Knoten mit Rolle label – die Änderungen sind schon vor ein paar Tagen passiert Eckhart ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update von nominatim.osm.org
On 09/09/12 01:46, Sarah Hoffmann wrote: On Sat, Sep 08, 2012 at 09:56:37PM +0200, fly wrote: Das war bisher der 1. Treffer: http://www.openstreetmap.org/browse/relation/1629146 Sollte eigentlich alles soweit enthalten. Da hat sich in der Tat ein Bug eingeschlichen. Dass admin_level ohne ein boundary=administrative verwendet wird, war nicht vorgesehen. Oh, dass habe ich wohl übersehen. Verstehe selber nicht warum das da fehlt, aber lasse es erstmal so. Ich habe mal ein Ticket angelegt: http://trac.openstreetmap.org/ticket/4558 Der Wikipedia Link wird dann auch nicht mehr benutzt ! Danke fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update von nominatim.osm.org
Hallo, mir ist aufgefallen, dass eine Suche nach Fahltskamp[1] zwei Ergebnisse liefert. Eine in Pinneberg-Mitte und eine in Thesdorf. Dies ist aber nur eine (verbundene) Straße (in Pinneberg-Mitte). Die Unterteilung ist notwendig, da sich die oneway Eigenschaft ändert. Ist hier was an den Daten nicht richtig, oder kann nominatim damit nicht um? Viele Grüße Stefan [1]: http://nominatim.openstreetmap.org/search.php?q=Fahltskamp Am 26.08.2012 20:44, schrieb Sarah Hoffmann: Hi, wie einige vielleicht mitbekommen haben, hat Nominatim, die OSM-Suche, in den letzten Wochen ihre Updates ausgesetzt gehabt, um den Redaction-Bot passieren zu lassen. Inzwischen ist eine neue Datenbank eingespielt und die Suche ist wieder minuten-aktuell wie gewohnt. Bei dieser Gelegenheit hat der Server auch ein Software-Update bekommen. Neben kleineren Bugfixes gibt es drei grössere Neuerungen: die Art wie die Adressen ermittelt werden, wurde etwas verbessert, Orten wird jetzt mit Hilfe von Wikipedia-Artikeln eine Wichtigkeit zugeordnet und es gibt jetzt eine Erkennung wo Grenzrelationen und Place-Nodes zusammengehören. Ein paar kurze Worte zu den letzten beiden Punkten. Nominatim ermittelt jetzt mit Hilfe von Wikipedia-Artikeln, wie bekannt ein Ort ist und nutzt das, um die Reihenfolge zu verbessern, mit der die Suchergebnisse ausgegeben werden. Zum Beispiel liefert die Suche nach 'Brooklyn' jetzt tatsächlich als erstes Resultat den bekannten Stadtteil von New York und nicht irgendeinen Weiher im mittleren Westen der USA. Für die richtige Zuordnung der Orte hilft es ungemein, wenn das 'wikipedia'-Tag in einer seiner Varianten gesetzt ist. Sollten irgendwo also noch eine komische Reihenfolge bei der Suche herauskommen, erstmal schauen, ob das wikipedia-Tag noch fehlt. Für das Erkennen von Duplikaten bei Grenzrelationen und Place-Nodes wertet Nominatim jetzt sowohl die Rolle 'label' als auch 'admin_centre' in den Grenzrelatioen aus, wobei Nodes mit 'admin_centre' nur zusammengefasst werden, wenn Name und Admin-Level stimmen. Fehlen beide, rät Nominatim, welcher Place-Node zur Relation passen könnte. Das funktioniert aber nur beschränkt gut, weil es keine weltweit eindeutige Zuordnung zwischen admin-level und place-Wert gibt. Die Node explizit zur Relation zuzufügen ist daher zuverlässiger. Wenn für eine Grenzrelation ein Place-Node gefunden wurde, werden dessen Koordinaten auch als Zentrum der Relation zurückgegeben, was praktisch immer zu besseren Ergebnissen führt, als der Mittelpunkt der Relation, der bisher verwendet wurde. Bugs können wie üblich entweder im trac gemeldet werden oder aber auch gerne auf der geocoding Mailingliste diskutiert werden oder hier auf talk-de. An dieser Stelle noch einen Dank an alle, die bei dem Update mitgeholfen haben, insbesondere aber an Brian Quinion, der den Grossteil der Neuerungen implementiert hat. Gruss Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update von nominatim.osm.org
Hi, Suche nach Burgstraße, Bergkamen meldet 2 Treffer mit unterschiedlichen PLZ: 44534 (falsch, Lünen) 59192 (Bergkamen, korrekt) Bug in Nominatim oder Daten falsch ? Die PLZ/Admin Relation 158457 sieht mir ok aus. Grüße Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update von nominatim.osm.org
On Sat, Sep 08, 2012 at 10:56:01AM +0200, Chris66 wrote: Hi, Suche nach Burgstraße, Bergkamen meldet 2 Treffer mit unterschiedlichen PLZ: 44534 (falsch, Lünen) 59192 (Bergkamen, korrekt) Bug in Nominatim oder Daten falsch ? Die PLZ/Admin Relation 158457 sieht mir ok aus. Bug in Nominatim. PLZ sind zur Zeit noch sehr schlecht implementiert. Ist aber recht weit oben auf der TODO-Liste. Gruss Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update von nominatim.osm.org
On Sat, Sep 08, 2012 at 09:56:37PM +0200, fly wrote: On 06/09/12 15:48, Sarah Hoffmann wrote: On Thu, Sep 06, 2012 at 03:40:28PM +0200, fly wrote: Habe leider ein Problem entdeckt. Wenn ich azores bzw azoren eingebe bekomme ich leider viele Treffer. Vor dem Update war der erste auch der richtige für das Archipel, jetzt ist er leider gar nicht mehr vorhanden. Mit Glück findet man noch ein paar Treffer auf einer der Inseln, aber auch sämtliche Inseln an sich werden auch nicht mehr angeboten. Hast du gerade einen Link zum OSM-Objekt zur Hand, das er eigentlich finden sollte? Damit liesse sich das leichter debuggen. Das war bisher der 1. Treffer: http://www.openstreetmap.org/browse/relation/1629146 Sollte eigentlich alles soweit enthalten. Da hat sich in der Tat ein Bug eingeschlichen. Dass admin_level ohne ein boundary=administrative verwendet wird, war nicht vorgesehen. Ich habe mal ein Ticket angelegt: http://trac.openstreetmap.org/ticket/4558 Gruss Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update von nominatim.osm.org
Hallo Georg, Am Freitag, 7. September 2012, 07:43:00 schrieb Georg Feddern: - die Grenzrelation hat Admin Level: 6, der Knoten hat Admin Level: 15 (gibt es doch gar nicht?) Sollte der Knoten auch admin_level=6 getaggt werden? als Regierungssitz des Regierungsbezirks Schwaben (1) müsste Augsburg eher admin_level=5 bekommen. Zumindest der node, damit scheint das nur ein Vertipper zu sein. Ein Vertipper ist das wohl weniger, der node hat überhaupt kein admin_level getaggt. Das Problem sehe ich darin, dass ein Node grundsätzlich mehr als ein admin_level haben müsste, um zu den Relationen zu passen, im Beispiel 5 *und* 6. Eckhart ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update von nominatim.osm.org
Moin, Am 07.09.2012 08:20, schrieb Eckhart Wörner: Am Freitag, 7. September 2012, 07:43:00 schrieb Georg Feddern: - die Grenzrelation hat Admin Level: 6, der Knoten hat Admin Level: 15 (gibt es doch gar nicht?) eher admin_level=5 bekommen. Zumindest der node, damit scheint das nur ein Vertipper zu sein. Ein Vertipper ist das wohl weniger, der node hat überhaupt kein admin_level getaggt. Oben steht das noch anders ... Das Problem sehe ich darin, dass ein Node grundsätzlich mehr als ein admin_level haben müsste, um zu den Relationen zu passen, im Beispiel 5 *und* 6. Nicht unbedingt. Sie müssen ja nur zusammenpassen, damit Nominatim den node dann ignorieren kann ;-). Der node kann ja durchaus als Regierungssitz des Regierungsbezirks gefunden werden Als node zur Gemeinde-Relation (hier als kreisfrei Stadt AL 6) muss er ja aber nun nicht unbedingt vorhanden sein. Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update von nominatim.osm.org
Hallo Georg, Am Freitag, 7. September 2012, 09:06:45 schrieb Georg Feddern: Am 07.09.2012 08:20, schrieb Eckhart Wörner: Am Freitag, 7. September 2012, 07:43:00 schrieb Georg Feddern: - die Grenzrelation hat Admin Level: 6, der Knoten hat Admin Level: 15 (gibt es doch gar nicht?) eher admin_level=5 bekommen. Zumindest der node, damit scheint das nur ein Vertipper zu sein. Ein Vertipper ist das wohl weniger, der node hat überhaupt kein admin_level getaggt. Oben steht das noch anders ... Dann habe ich mich unklar ausgedrückt. Der Knoten hat laut http://nominatim.openstreetmap.org/details.php?place_id=17722739 Admin Level 15, aber am Knoten selber ist admin_level nicht getaggt. Das Problem sehe ich darin, dass ein Node grundsätzlich mehr als ein admin_level haben müsste, um zu den Relationen zu passen, im Beispiel 5 *und* 6. Nicht unbedingt. Sie müssen ja nur zusammenpassen, damit Nominatim den node dann ignorieren kann ;-). Der node kann ja durchaus als Regierungssitz des Regierungsbezirks gefunden werden Als node zur Gemeinde-Relation (hier als kreisfrei Stadt AL 6) muss er ja aber nun nicht unbedingt vorhanden sein. Es geht ja nicht nur darum, dass der Knoten aus den Suchergebnissen rausfliegt, sondern auch, dass er zum Zentrum der Grenzrelationen wird. Eckhart ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update von nominatim.osm.org
Hi, On Thu, Sep 06, 2012 at 04:07:15PM +0200, Eckhart Wörner wrote: Am Sonntag, 26. August 2012, 20:44:13 schrieb Sarah Hoffmann: Für das Erkennen von Duplikaten bei Grenzrelationen und Place-Nodes wertet Nominatim jetzt sowohl die Rolle 'label' als auch 'admin_centre' in den Grenzrelatioen aus, wobei Nodes mit 'admin_centre' nur zusammengefasst werden, wenn Name und Admin-Level stimmen. mir ist noch nicht ganz klar, wie das Zusammenfassen genau funktionieren soll. Beispiel Augsburg: Grenzrelation: http://nominatim.openstreetmap.org/details.php?place_id=148614123 Knoten: http://nominatim.openstreetmap.org/details.php?place_id=17722739 - der Knoten ist admin_centre der Grenzrelation - beide heißen Augsburg - die Grenzrelation hat Admin Level: 6, der Knoten hat Admin Level: 15 (gibt es doch gar nicht?) Sollte der Knoten auch admin_level=6 getaggt werden? Ich würde in diesem Fall eher mit 'label' als Rolle taggen als mit 'admin_centre', weil Augsburg ja nicht das Verwaltungszentrum der kreisfreien Stadt ist, sondern es ist ein und dieselbe Stadt. Dann ist es nicht nötig, dass admin levels übereinstimmen. Der Grund, dass Nominatim für admin_centre nach dem admin level sucht, liegt daran, dass es nicht fälschlicherweise z.B. Kreis und Kreisstadt zusammenfassen soll, wenn beide gleich heissen. gruss Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update von nominatim.osm.org
Hallo Sarah, Am Freitag, 7. September 2012, 09:39:08 schrieb Sarah Hoffmann: Ich würde in diesem Fall eher mit 'label' als Rolle taggen als mit 'admin_centre', weil Augsburg ja nicht das Verwaltungszentrum der kreisfreien Stadt ist, sondern es ist ein und dieselbe Stadt. Dann ist es nicht nötig, dass admin levels übereinstimmen. klingt irgendwie überzeugend. :-) Eckhart ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update von nominatim.osm.org
Hi, Am Sonntag, 26. August 2012, 20:44:13 schrieb Sarah Hoffmann: Für das Erkennen von Duplikaten bei Grenzrelationen und Place-Nodes wertet Nominatim jetzt sowohl die Rolle 'label' als auch 'admin_centre' in den Grenzrelatioen aus, wobei Nodes mit 'admin_centre' nur zusammengefasst werden, wenn Name und Admin-Level stimmen. Fehlen beide, rät Nominatim, welcher Place-Node zur Relation passen könnte. Das funktioniert aber nur beschränkt gut, weil es keine weltweit eindeutige Zuordnung zwischen admin-level und place-Wert gibt. Die Node explizit zur Relation zuzufügen ist daher zuverlässiger. Wenn für eine Grenzrelation ein Place-Node gefunden wurde, werden dessen Koordinaten auch als Zentrum der Relation zurückgegeben, was praktisch immer zu besseren Ergebnissen führt, als der Mittelpunkt der Relation, der bisher verwendet wurde. bin mal probeweise durch ein paar Landkreise durch und habe die Zuordnung vorgenommen; von Aach bis Zwönitz steht noch eine ganze Menge Arbeit an. :-) Eckhart ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update von nominatim.osm.org
Hey Sarah Habe leider ein Problem entdeckt. Wenn ich azores bzw azoren eingebe bekomme ich leider viele Treffer. Vor dem Update war der erste auch der richtige für das Archipel, jetzt ist er leider gar nicht mehr vorhanden. Mit Glück findet man noch ein paar Treffer auf einer der Inseln, aber auch sämtliche Inseln an sich werden auch nicht mehr angeboten. Grüße fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update von nominatim.osm.org
Hi, Am Sonntag, 26. August 2012, 20:44:13 schrieb Sarah Hoffmann: Für das Erkennen von Duplikaten bei Grenzrelationen und Place-Nodes wertet Nominatim jetzt sowohl die Rolle 'label' als auch 'admin_centre' in den Grenzrelatioen aus, wobei Nodes mit 'admin_centre' nur zusammengefasst werden, wenn Name und Admin-Level stimmen. mir ist noch nicht ganz klar, wie das Zusammenfassen genau funktionieren soll. Beispiel Augsburg: Grenzrelation: http://nominatim.openstreetmap.org/details.php?place_id=148614123 Knoten: http://nominatim.openstreetmap.org/details.php?place_id=17722739 - der Knoten ist admin_centre der Grenzrelation - beide heißen Augsburg - die Grenzrelation hat Admin Level: 6, der Knoten hat Admin Level: 15 (gibt es doch gar nicht?) Sollte der Knoten auch admin_level=6 getaggt werden? Eckhart ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update von nominatim.osm.org
Moin, Am 06.09.2012 16:07, schrieb Eckhart Wörner: Hi, Am Sonntag, 26. August 2012, 20:44:13 schrieb Sarah Hoffmann: Für das Erkennen von Duplikaten bei Grenzrelationen und Place-Nodes wertet Nominatim jetzt sowohl die Rolle 'label' als auch 'admin_centre' in den Grenzrelatioen aus, wobei Nodes mit 'admin_centre' nur zusammengefasst werden, wenn Name und Admin-Level stimmen. Beispiel Augsburg: Grenzrelation: http://nominatim.openstreetmap.org/details.php?place_id=148614123 Knoten: http://nominatim.openstreetmap.org/details.php?place_id=17722739 - der Knoten ist admin_centre der Grenzrelation - beide heißen Augsburg - die Grenzrelation hat Admin Level: 6, der Knoten hat Admin Level: 15 (gibt es doch gar nicht?) Sollte der Knoten auch admin_level=6 getaggt werden? als Regierungssitz des Regierungsbezirks Schwaben (1) müsste Augsburg eher admin_level=5 bekommen. Zumindest der node, damit scheint das nur ein Vertipper zu sein. Ob allerdings auch die Relation admin_level=5 bekommen sollte, bin ich mit mir selbst nicht einig ... ist ja nur eine kreisfreie Stadt. Gruß Georg (1) http://de.wikipedia.org/wiki/Augsburg http://de.wikipedia.org/wiki/Schwaben_%28Bayern%29 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update von nominatim.osm.org
Am 26.08.2012 22:29, schrieb Sarah Hoffmann: Ich will jetzt keine Diskussion vom Zaun brechen, ob der Zusatz Spreewald nun in den name-Tag gehört oder nicht. mMn nach ja, da das nunmal der offizielle Name ist. Eine Variante, um das Problem zu lösen ist, noch zusätzlich eine alt_name=Lübben oder short_name=Lübben zu ergänzen. Ah, beides wird also von Nominatim ausgewertet? Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update von nominatim.osm.org
On Mon, Aug 27, 2012 at 09:54:29AM +0200, Chris66 wrote: Am 26.08.2012 22:29, schrieb Sarah Hoffmann: Ich will jetzt keine Diskussion vom Zaun brechen, ob der Zusatz Spreewald nun in den name-Tag gehört oder nicht. mMn nach ja, da das nunmal der offizielle Name ist. Es gäbe noch die Möglichkeit, es so zu taggen: name = Lübben official_name = Lübben (Spreewald) Ich würde jetzt nicht sagen, dass eine Variante richtiger ist als die andere. Es kommt ganz auf den lokalen Gebrauch an. Eine Variante, um das Problem zu lösen ist, noch zusätzlich eine alt_name=Lübben oder short_name=Lübben zu ergänzen. Ah, beides wird also von Nominatim ausgewertet? Ja, beides wird für die Suche verwendet. short_name wird zusätzlich auch für die Anzeige in den Suchresultaten benutzt. Zur Info, die anderen Namens-Tags die Nominatim zur Zeit versteht: int_name, reg_name, nat_name, loc_name, old_name, commonname, common_name, place_name, official_name ... und natürlich die ganzen Varianten mit Sprach-Code nach dem Doppelpunkt. Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update von nominatim.osm.org
On 27.08.12 12:08, Sarah Hoffmann wrote: Es gäbe noch die Möglichkeit, es so zu taggen: name = Lübben official_name = Lübben (Spreewald) Berücksichtigt der Nominatim official_name (oder full_name oder alt_name oder loc_name oder was es da noch so gibt)? Servus, Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update von nominatim.osm.org
On Mon, Aug 27, 2012 at 12:36:47PM +0200, Andreas Labres wrote: On 27.08.12 12:08, Sarah Hoffmann wrote: Es gäbe noch die Möglichkeit, es so zu taggen: name = Lübben official_name = Lübben (Spreewald) Berücksichtigt der Nominatim official_name (oder full_name oder alt_name oder loc_name oder was es da noch so gibt)? Siehe Liste im zweiten Teil der Mail, die du da zitiert hast. Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update von nominatim.osm.org
Am 27.08.2012 um 13:00 schrieb Sarah Hoffmann lon...@denofr.de: Siehe Liste im zweiten Teil der Mail, die du da zitiert hast. Ist das für ref (nat_ref, old_ref etc.) auch implementiert? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update von nominatim.osm.org
Sarah Hoffmann lon...@denofr.de wrote: Nominatim ermittelt jetzt mit Hilfe von Wikipedia-Artikeln, wie bekannt ein Ort ist und nutzt das, um die Reihenfolge zu verbessern, mit der die Suchergebnisse ausgegeben werden. Zum Beispiel liefert die Suche nach 'Brooklyn' jetzt tatsächlich als erstes Resultat den bekannten Stadtteil von New York und nicht irgendeinen Weiher im mittleren Westen der USA. Hm, die Suche nach Goethestraße Karlsruhe liefert immer noch nicht das erwartete Ergebnis. Mit anderen Städten klappt es aber teilweise. Gruss Sven -- Das allgemeine Persönlichkeitsrecht (Art. 2 Abs.1 i.V.m. Art.1 Abs. 1GG) umfasst das Grundrecht auf Gewährleistung der Vertraulichkeit und Integrität informationstechnischer Systeme. (BVerfG, 1BvR 370/07) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update von nominatim.osm.org
On Mon, Aug 27, 2012 at 01:46:21PM +0200, Martin Koppenhoefer wrote: Am 27.08.2012 um 13:00 schrieb Sarah Hoffmann lon...@denofr.de: Siehe Liste im zweiten Teil der Mail, die du da zitiert hast. Ist das für ref (nat_ref, old_ref etc.) auch implementiert? Ja, die hatte ich weggelassen. An ref-Tags wertet er noch folgende aus: ref, int_ref, nat_ref, reg_ref, loc_ref, old_ref, ncn_ref, rcn_ref, lcn_ref Dann für die Flughäfen: iata, icao Und dann noch ein paar PLZ-Eigenartigkeiten: pcode:1, pcode:2, pcode:3, un:pcode:1,un:pcode2,un:pcode:3 Jetzt ist die Liste aber vollständig. Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update von nominatim.osm.org
Hallo Sarah, Nominatim ermittelt jetzt mit Hilfe von Wikipedia-Artikeln, wie bekannt ein Ort ist und nutzt das, um die Reihenfolge zu verbessern, mit der die Suchergebnisse ausgegeben werden. Das finde ich genial! Wie genau ermittelst Du diese Bekanntheit? Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update von nominatim.osm.org
Original-Nachricht Betreff: Re: [Talk-de] Update von nominatim.osm.org Datum: Sun Aug 26 2012 22:06:26 GMT+0200 Von: Chris66 chris66...@gmx.de An: talk-de@openstreetmap.org Am 26.08.2012 20:44, schrieb Sarah Hoffmann: Hier noch 'ne Kleinigkeit die mir heuer aufgefallen ist: Die Stadt Lübben wird nur gefunden wenn man Lübben (Spreewald) in die Suchmaske eingibt. Könnte man noch verbessern. Die parallele Suchmaschine (GeoNames) kann es ja auch. Dieses Problem kenne ich auch und zwar mit Alfeld (Leine). Sucht man nur nach Alfeld, findet Nominatim erst einmal nur ein Kaff in Bayern und ein dazugehöriges Autobahnkreuz. Erst nach zweimaligem Mehr Treffer findet sich dann an der 6. Stelle die (Weltkulturerbe-)Stadt Alfeld (Leine). Das kann wirklich nicht sinnvoll sein. Auch finde ich es absurd, dass zuerst Verwaltungsgrenzen als Treffer angezeigt werden und erst später die zugehörige Stadt, Dorf etc. Viele Grüße, Constanze ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update von nominatim.osm.org
Hallo Constanze, dass zuerst Verwaltungsgrenzen als Treffer angezeigt werden und erst später die zugehörige Stadt, Dorf etc. Ja, andersrum wäre deutlich effizienter. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update von nominatim.osm.org
On Mon, Aug 27, 2012 at 12:20:53PM +, Sven Geggus wrote: Sarah Hoffmann lon...@denofr.de wrote: Nominatim ermittelt jetzt mit Hilfe von Wikipedia-Artikeln, wie bekannt ein Ort ist und nutzt das, um die Reihenfolge zu verbessern, mit der die Suchergebnisse ausgegeben werden. Zum Beispiel liefert die Suche nach 'Brooklyn' jetzt tatsächlich als erstes Resultat den bekannten Stadtteil von New York und nicht irgendeinen Weiher im mittleren Westen der USA. Hm, die Suche nach Goethestraße Karlsruhe liefert immer noch nicht das erwartete Ergebnis. Mit anderen Städten klappt es aber teilweise. Das ist leider einer der Bugs, die immernoch auf der Todo-Liste stehen. Das Ordnen hilft neustens bei weniger häufig verwendeten Namen, z.B. Schwindstr, Karlsruhe. Aber sobald es zu viele Kandidaten gibt, kommt der richtige schon nicht aus der DB. Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update von nominatim.osm.org
On Mon, Aug 27, 2012 at 02:35:45PM +0200, Markus wrote: Hallo Sarah, Nominatim ermittelt jetzt mit Hilfe von Wikipedia-Artikeln, wie bekannt ein Ort ist und nutzt das, um die Reihenfolge zu verbessern, mit der die Suchergebnisse ausgegeben werden. Das finde ich genial! Wie genau ermittelst Du diese Bekanntheit? Der Code stammt nicht von mir, insofern weiss ich da auch nur sehr wenig. Aber grob gesagt, ermittelt er die Wichtigkeit einer Wiki-Seite über Link-Zähler und ähnliches und übernimmt dann diese Wichtigkeit für das OSM-Objekt. Wegen genauerer Details musst du Brian fragen. Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update von nominatim.osm.org
On Mon, Aug 27, 2012 at 02:56:06PM +0200, tumsi wrote: Am 26.08.2012 20:44, schrieb Sarah Hoffmann: Hier noch 'ne Kleinigkeit die mir heuer aufgefallen ist: Die Stadt Lübben wird nur gefunden wenn man Lübben (Spreewald) in die Suchmaske eingibt. Könnte man noch verbessern. Die parallele Suchmaschine (GeoNames) kann es ja auch. Dieses Problem kenne ich auch und zwar mit Alfeld (Leine). Sucht man nur nach Alfeld, findet Nominatim erst einmal nur ein Kaff in Bayern und ein dazugehöriges Autobahnkreuz. Erst nach zweimaligem Mehr Treffer findet sich dann an der 6. Stelle die (Weltkulturerbe-)Stadt Alfeld (Leine). Das kann wirklich nicht sinnvoll sein. Wie gesagt, ein zusätzliches alt_name-Tag schafft Abhilfe. Eventuell auch noch ein wikipedia-Tag ergänzen. Es scheint, dass der Namenszusatz auch verhindert, dass Nominatim die richtige Wikipedia-Seite findet, die dem Ort eine höhere Wichtigkeit verleihen könnte. Auch finde ich es absurd, dass zuerst Verwaltungsgrenzen als Treffer angezeigt werden und erst später die zugehörige Stadt, Dorf etc. An sich ist das schon richtig so, weil die Verwaltungsgrenzen eine Fläche darstellen, die genauer besagt, wie gross der Ort eigentlich ist. Das Problem hier ist eher die Benennung. Da diese Grenzen alle mit boundary=administrative getaggt sind, gibt die Website auch einfach nur Verwaltunsgrenze zurück. Das sollte man besser mit Hilfe des admin-levels unterscheiden und dann entsprechend 'Stadt', 'Kreis', 'Land', etc. angeben. Dann machen die Ergebnisse mehr Sinn. Das ist auf jeden Fall auf der Todo-Liste für die nächste Version. Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update von nominatim.osm.org
Am 27.08.2012 12:08, schrieb Sarah Hoffmann: On Mon, Aug 27, 2012 at 09:54:29AM +0200, Chris66 wrote: Am 26.08.2012 22:29, schrieb Sarah Hoffmann: Ich will jetzt keine Diskussion vom Zaun brechen, ob der Zusatz Spreewald nun in den name-Tag gehört oder nicht. mMn nach ja, da das nunmal der offizielle Name ist. Es gäbe noch die Möglichkeit, es so zu taggen: name = Lübben official_name = Lübben (Spreewald) Ich würde jetzt nicht sagen, dass eine Variante richtiger ist als die andere. Es kommt ganz auf den lokalen Gebrauch an. Eine Variante, um das Problem zu lösen ist, noch zusätzlich eine alt_name=Lübben oder short_name=Lübben zu ergänzen. Ah, beides wird also von Nominatim ausgewertet? Ja, beides wird für die Suche verwendet. short_name wird zusätzlich auch für die Anzeige in den Suchresultaten benutzt. Zur Info, die anderen Namens-Tags die Nominatim zur Zeit versteht: int_name, reg_name, nat_name, loc_name, old_name, commonname, common_name, place_name, official_name ... und natürlich die ganzen Varianten mit Sprach-Code nach dem Doppelpunkt. Soll dass jetzt heißen, dass jeder in den name-tag schreiben kann, was er oder sie will? Ich war eigentlich immer der Meinung, da gehört der offizielle Name hin. Für einen abweichenden Gebrauch sehe ich keine stichhaltigen Gründe. Freundliche Grüße Harald ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update von nominatim.osm.org
On Mon, Aug 27, 2012 at 10:27:16PM +0200, Harald wrote: Zur Info, die anderen Namens-Tags die Nominatim zur Zeit versteht: int_name, reg_name, nat_name, loc_name, old_name, commonname, common_name, place_name, official_name ... und natürlich die ganzen Varianten mit Sprach-Code nach dem Doppelpunkt. Soll dass jetzt heißen, dass jeder in den name-tag schreiben kann, was er oder sie will? Ich war eigentlich immer der Meinung, da gehört der offizielle Name hin. Für einen abweichenden Gebrauch sehe ich keine stichhaltigen Gründe. Die verschiedenen Varianten des Name-Tags sind ausreichend im Wiki dokumentiert: http://wiki.openstreetmap.org/wiki/DE:Names Nominatim implementiert nur, was da steht. (Oder um genau zu sein: was da stand, als die Liste angelegt wurde. Offensichtlich werden einige Tags nicht länger verwendet. Könnte man mal korrigieren.) Gruss Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Update von nominatim.osm.org
Hi, wie einige vielleicht mitbekommen haben, hat Nominatim, die OSM-Suche, in den letzten Wochen ihre Updates ausgesetzt gehabt, um den Redaction-Bot passieren zu lassen. Inzwischen ist eine neue Datenbank eingespielt und die Suche ist wieder minuten-aktuell wie gewohnt. Bei dieser Gelegenheit hat der Server auch ein Software-Update bekommen. Neben kleineren Bugfixes gibt es drei grössere Neuerungen: die Art wie die Adressen ermittelt werden, wurde etwas verbessert, Orten wird jetzt mit Hilfe von Wikipedia-Artikeln eine Wichtigkeit zugeordnet und es gibt jetzt eine Erkennung wo Grenzrelationen und Place-Nodes zusammengehören. Ein paar kurze Worte zu den letzten beiden Punkten. Nominatim ermittelt jetzt mit Hilfe von Wikipedia-Artikeln, wie bekannt ein Ort ist und nutzt das, um die Reihenfolge zu verbessern, mit der die Suchergebnisse ausgegeben werden. Zum Beispiel liefert die Suche nach 'Brooklyn' jetzt tatsächlich als erstes Resultat den bekannten Stadtteil von New York und nicht irgendeinen Weiher im mittleren Westen der USA. Für die richtige Zuordnung der Orte hilft es ungemein, wenn das 'wikipedia'-Tag in einer seiner Varianten gesetzt ist. Sollten irgendwo also noch eine komische Reihenfolge bei der Suche herauskommen, erstmal schauen, ob das wikipedia-Tag noch fehlt. Für das Erkennen von Duplikaten bei Grenzrelationen und Place-Nodes wertet Nominatim jetzt sowohl die Rolle 'label' als auch 'admin_centre' in den Grenzrelatioen aus, wobei Nodes mit 'admin_centre' nur zusammengefasst werden, wenn Name und Admin-Level stimmen. Fehlen beide, rät Nominatim, welcher Place-Node zur Relation passen könnte. Das funktioniert aber nur beschränkt gut, weil es keine weltweit eindeutige Zuordnung zwischen admin-level und place-Wert gibt. Die Node explizit zur Relation zuzufügen ist daher zuverlässiger. Wenn für eine Grenzrelation ein Place-Node gefunden wurde, werden dessen Koordinaten auch als Zentrum der Relation zurückgegeben, was praktisch immer zu besseren Ergebnissen führt, als der Mittelpunkt der Relation, der bisher verwendet wurde. Bugs können wie üblich entweder im trac gemeldet werden oder aber auch gerne auf der geocoding Mailingliste diskutiert werden oder hier auf talk-de. An dieser Stelle noch einen Dank an alle, die bei dem Update mitgeholfen haben, insbesondere aber an Brian Quinion, der den Grossteil der Neuerungen implementiert hat. Gruss Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update von nominatim.osm.org
Am 26.08.2012 20:44, schrieb Sarah Hoffmann: Bei dieser Gelegenheit hat der Server auch ein Software-Update bekommen. Vielen Dank dafür. Hier noch 'ne Kleinigkeit die mir heuer aufgefallen ist: Die Stadt Lübben wird nur gefunden wenn man Lübben (Spreewald) in die Suchmaske eingibt. Könnte man noch verbessern. Die parallele Suchmaschine (GeoNames) kann es ja auch. Grüße Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update von nominatim.osm.org
On Sun, Aug 26, 2012 at 10:06:26PM +0200, Chris66 wrote: Am 26.08.2012 20:44, schrieb Sarah Hoffmann: Bei dieser Gelegenheit hat der Server auch ein Software-Update bekommen. Vielen Dank dafür. Hier noch 'ne Kleinigkeit die mir heuer aufgefallen ist: Die Stadt Lübben wird nur gefunden wenn man Lübben (Spreewald) in die Suchmaske eingibt. Könnte man noch verbessern. Die parallele Suchmaschine (GeoNames) kann es ja auch. Sie wird schon gefunden, aber erst im zweiten Versuch, nachdem man auf Mehr Treffer geklickt hat. Der Grund dafür ist, dass Nominatim exakten Ergebnissen den Vorzug gibt, was ja meistens auch das ist, was man eigentlich will. Ich will jetzt keine Diskussion vom Zaun brechen, ob der Zusatz Spreewald nun in den name-Tag gehört oder nicht. Eine Variante, um das Problem zu lösen ist, noch zusätzlich eine alt_name=Lübben oder short_name=Lübben zu ergänzen. Gruss Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update von nominatim.osm.org
Am 26.08.2012 22:29, schrieb Sarah Hoffmann: Sie wird schon gefunden, aber erst im zweiten Versuch, nachdem man auf Mehr Treffer geklickt hat. Der Grund dafür ist, dass Nominatim exakten Ergebnissen den Vorzug gibt, was ja meistens auch das ist, was man eigentlich will. Ich will jetzt keine Diskussion vom Zaun brechen, ob der Zusatz Spreewald nun in den name-Tag gehört oder nicht. Eine Variante, um das Problem zu lösen ist, noch zusätzlich eine alt_name=Lübben oder short_name=Lübben zu ergänzen. Ähmm, der Zusatz Spreewald dürfte ja wohl mehr oder weniger zwingend in den name-Tag gehören, da der offizielle Name meines Wissen eben Lübben (Spreewald). Einen schönen Abend Harald ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
