[Talk-at] Irreführendes Nominatim-Ergebnis

[Andreas]

Am 18.06.20 um 21:49 schrieb Johann Haag:

> Wenn etwas wie Nominatim derart nachhaltig nicht funktioniert, so kannst
> Du mit Gewissheit davon ausgehen, dass ein solches Verhalten bewusst
> herbeigeführt ist, unser OpenSource Projekt simpel nicht als
> Produktivsystem geeignet sein soll.

Musste die Verschwörungstheorie-Keule jetzt wirklich ausgepackt werden?

Auch kommerzielle Anbieter haben oft Probleme mit ihren Suchalgorithmen,
daher finde es sehr interessant hier gleich auf eine bewusste
Verfälschung des Suchergebnisses zu setzen.

Und wenn wirklich die Ursache für das Problem nicht gefunden werden
kann, kann man einen Issue auf der Projektseite auf github
(https://github.com/osm-search/Nominatim/issues) erstellen.

Wir sind eine Community und es gibt hier keine Elite. Es gibt vielleicht
erfahrenere Mapper und OSM Entwickler, aber das ist ja das schöne an dem
Projekt. Es können Menschen mit den unterschiedlichsten Wissensständen
sich miteinander austauschen und so OSM verbessern.

> Sowas nennt man Politik.
> Siehe auch: https://www.openstreetmap.org/user/addresshistory*hxg*at

Ich habe jetzt wirklich deine Profilseite besucht und musste beim Lesen
deines Begrüßungstextes nur den Kopfschütteln.

Du wolltest eine "brauchbare" Karte von Adressen in Österreich
erstellen, auf Grundlage von unbrauchbaren, falschen und lückenhaften Daten?

Deine Adress-Importe wurden revidiert, weil sie mehr Adressen zerstört
haben, als neue korrekte Adressdaten hinzugefügt haben. Die Daten haben
eine heute üblichen Qualitätsgrad nicht standgehalten.

Wie schon mehrfach erwähnt, gibt es für Importe gewisse Regeln die
einzuhalten sind und die meisten davon sagt mir zumindest mein Hausverstand:
	- Sind die Daten die ich importieren will richtig
	- Verstoßen diese Daten nicht den Lizenzbedingungen
	- Wie werden Konflikte mit bestehenden Daten bereinigt

OSM gibt es jetzt schon eine lange Zeit und durch die Integration von
unterschiedlichen Informationen und Objekten ist die Editierung nicht
mehr so leicht wie am Anfang.

Ich persönlich hatte bereits bei einfachen Änderungen wie neue Straßen
oder Kreisverkehre erstellen das Problem, dass ich mich dabei mit
Relationen befassen musste, weil im Bearbeitungsgebiet sehr viele
Buslinien als Relationen auf den Kanten gemappt waren.

Ich finde es sehr traurig, dass du mit deinen Aussagen immer wieder die
Konfrontation mit der ML und dem Forum suchst. Vielleicht hast du auch
Spaß daran, ich glaube es aber nicht, weil dann würdest du ja auch in
deinem OSM Profil angeben, dass du auch der OSM User in Österreich bist
mit den meisten ML und Forensperren.

OSM ist ein Gemeinschaftsprojekt, dass schon viele Jahre besteht und ich
bin stolz ein Teil zu sein. Sicherlich bin ich mit bestimmten
Entwicklungen nicht einverstanden, aber ich spreche mit anderen darüber.
Ich informiere mich bei div. Community Events zB FOSSGIS und versuche so
Wissenslücken zu schließen, kann mit anderen über meine Vorstellungen
diskutieren oder bekomme Einblicke in Neuerungen in OSM.

Ich würde es begrüßen, wenn wir endlich wieder eine konstruktives
Diskussionsklima hier schaffen könnten, ohne ständige persönliche
Anfeindungen und faktenlosen Aussagen.

In dem Sinne wünsche ich dir und allen Lesern der ML hiermit einen
schönen Abend und noch viele schöne Stunden mit OSM.

mfg
geologist

> Am Do., 18. Juni 2020 um 12:31 Uhr schrieb Florian Ledermann
> <florian.ledermann at tuwien.ac.at <mailto:florian.ledermann at tuwien.ac.at>>:
> 
>     Liebe Community,
> 
>     hat einer für euch eine Erklärung, warum eine Suche bei Nominatim nach
>     "Schelleingasse 8" als erstes Ergebnis die Node "Alois-Drasche-Park 8"
>     liefert?
> 
>     https://nominatim.openstreetmap.org/search.php?q=schelleingasse+8
> 
>     Die Address-Node, die hier als erstes geliefert wird, ist in OSM
>     korrekt
>     als "Alois-Drasche-Park 8" getagged, von Schelleingasse ist dort keine
>     Rede. Dennoch wird im Nominatim-Ergebnis die Straße der Ergebnis-Node
>     als "Schelleingasse" angezeigt. Das 2. Nominatim Ergebnis ist dann das
>     korrekte Haus, leider ist es schwer das automatisiert zu erkennen da
>     das
>     erste Ergebnis bereits als Node "Schelleingasse 8" zurückgeliefert wird.
> 
>     Ich konnte ein solches Ergebnis mit keiner anderen Adressen im 4.
>     Bezirk
>     reproduzieren, auch die anderen Adressen in der Schelleingasse liefern
>     das erwartete (korrekte) Ergebnis. Auffällig ist allerdings noch, dass
>     Adress-Nodes im Alois-Drasche-Park von Nominatim anscheinend generell
>     nicht gefunden werden (z.B.
>     https://nominatim.openstreetmap.org/search.php?q=Alois-Drasche-Park+8 )
>     - keine Ahnung ob das etwas damit zu tun hat...
> 
>     Ich würde gerne das Tagging verbessern, so dass das 1. Ergebnis in
>     Nominatim die korrekte Adresse liefert, habe aber keine Idee wie ich
>     das
>     machen sollte, da das Tagging der Adresse mir korrekt erscheint.
> 
>     Wäre also über einen Hinweis oder Erklärung dankbar!
> 
>     LG Florian
> 
> 
>     -- 
>     Dipl.-Ing. Florian Ledermann
>     Cartography Research Group
>     Department of Geodesy and Geoinformation
>     TU Wien, Vienna, Austria
> 
>     http://cartography.tuwien.ac.at/florian-ledermann/
>     https://twitter.com/floledermann
> 
>     _______________________________________________
>     Talk-at mailing list
>     Talk-at at openstreetmap.org <mailto:Talk-at at openstreetmap.org>
>     https://lists.openstreetmap.org/listinfo/talk-at
> 
> 
> 
> -- 
> Elektronikermeister Johann Haag
> Innsbruckerstraße 42
> 6380 St. Johann in Tirol
> ÖSTERREICH
> Tel: +43 664/174 7414
> Mailto:johannhaag at hxg.at <mailto:johannhaag at hxg.at>
> 
> _______________________________________________
> Talk-at mailing list
> Talk-at at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstreetmap.org/pipermail/talk-at/attachments/20200618/d8842d93/attachment.sig>