View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0001943 | GeoSetter | User Interface | public | 2018-05-08 22:30 | 2022-12-22 02:04 |
Reporter | GeoUser | Assigned To | Friedemann | ||
Priority | high | Severity | block | Reproducibility | sometimes |
Status | assigned | Resolution | open | ||
Product Version | |||||
Target Version | Fixed in Version | ||||
Summary | 0001943: Adress-Suche liefert falsche Werte | ||||
Description | Version 3.4.82 beta Bei einer Vielzahl von Fotos liefert die Adress-Suche falsche Werte / Orte. - Nordrhein-Westfalen;Dortmund;Ickern existiert nicht. Ickern ist ein Ortsteil von Castrop-Rauxel Nordrhein-Westfalen;Castrop-Rauxel;Recklinghausen existiert nicht. Recklinghausen ist Stadt und Kreis (in dem sich Castrop-Rauxel) befindet. Solcherlei Fehler werden ständig geliefert. Abgefragt wird GeoNames mit eigenem Benutzernamen. | ||||
Steps To Reproduce | Foto-Verzeichnis laden, Track laden, Fotos edit, Online abfragen | ||||
Additional Information | Die Software RouteConverterWindows beispielsweise kann für alle Positionen in der Trackliste Vervollständigen -> Postanschrift. Hier wird nicht GeoNames, sondern Nominatim abgefragt und korrekte Straße, Hausnummer, Plz, Ort geliefert. Nominatim kennt auch den Ortsteil. Die Daten von GeoNames sind extrem unzuverlässig und sehr oft falsch. | ||||
Tags | No tags attached. | ||||
|
Hallo! Ich versuche das Problem zu verstehen und zu lernen. Und heraus zu finden ob ich was falsch mache. Und ein Ergebnis der Recherche ist, dass GeoNames eigentlich kaum eine Chance hat korrekte Orte zu liefern. Also überwiegend. Man muss jederzeit zu jedem von hunderten Fotos (auch auf Reisen in unbekanntem Gebiet) genauestens wissen wo man war, wo das Foto aufgenommen wurde, wie die Orte, Ortsteile, Bezirke und Verwaltungsgrenzen heißen. Sonst glaskugelt GeoNames irgendetwas zusammen, von dem man später am Rechner ohne eigene genaue Kenntnis gar nicht weiß, was zusammen passt. In einem Forum fand ich die Information, dass GeoNames wohl ausschließlich "zentrumsbasiert" funktioniert. Habe ich also eine Koordinate im Foto 51.58729, 7.39241 Korrekt: Emscherallee, Groppenbruch, Dortmund, Regierungsbezirk Arnsberg, Nordrhein-Westfalen, 44359, Deutschland kann GeoNames aus folgenden Bestandteilen umliegender Orte alle möglichen Kombinationen würfeln: Mengeder Straße Emscherallee Groppenbruch Brockenscheidt Brambauer Ickern Süd Dortmund Waltrop Lünen Castrop-Rauxel Kreis Recklinghausen Kreis Unna Regierungsbezirk Arnsberg Regierungsbezirk Münster Nordrhein-Westfalen 44359 45731 44536 44581 Deutschland Und warum das? Weil GeoNames nur nach Entfernungen zu benamten Punkten arbeitet und (anders als OpenStreetMap) nicht mal Boundaries kennt... Zitat: "The service is based on centroid point coordinates as we don't have boundary data" Uff. Keine Boundaries. Das muss man erst mal verdauen. Da wird blitzartig klar, wieso aus - Robert-Bosch-Straße, Hagener Straße, Westhofen, Schwerte, Kreis Unna, Regierungsbezirk Arnsberg, Nordrhein-Westfalen, 58239, Deutschland Hagen-Westhofen wird und aus - 147, Syburger Dorfstraße, Buchholz, Syburg, Dortmund, Regierungsbezirk Arnsberg, Nordrhein-Westfalen, 44265, Deutschland Hagen-Buchholz und so weiter... Ok, das GeoNames Problem dürfte dann vermutlich nicht innerhalb GeoSetter lösbar sein, nehme ich als Laie an. Vielleicht gibt es ja doch eine Chance einen Nominatim-Provider zu finden, dessen API ähnlich nutzbar ist wie GeoNames und das in GeoSetter einzubauen... Lieber Friedemann, dein Programm ist wirklich klasse und ich finde es bewundernswert wenn jemand über so viele Jahre das Gefühl vermittelt mit Herzblut dabei zu sein. Dass dann die Suchergebnisse von Dritter Seite eine so wichtige Funktion nahezu unbrauchbar machen, ist angesichts der vielen Zeit und Liebe zum Detail die Du in die Software gesteckt hat echt schmerzlich. |
|
Ja, ich weiß, dass die GeoNames-Ergebnisse leider nicht für jeden passen. Für mich tun sie das eigentlich seit Jahren. Allerdings brauche ich für meine Fotos auch keine adressgenauen Daten, den eigentlichen Ort ergänze ich meist selbst. Wahrscheinlich ist Google eine Alternative, oder? Das habe ich bisher noch nicht eingebaut, weil die Adressenabfragen mein Kontingent zu sehr belasten würden. Nun hat Google allerdings sowieso gerade sein Geschäftsmodell geändert, ich musste z.B. für meinen API-Key nun eine Abrechnungsmöglichkeit hinterlegen. Ich hoffe, dass ich alles richtig eingestellt habe, so dass mir keine Kosten entstehen werden. Es kann durchaus sein, dass ich auch den Zugriff auf die Karte nicht so lassen kann wie er ist, d.h. die Benutzer müssten sich dann selbst einen API-Key registrieren, leider. Wenn das der Fall wäre, könnte ich natürlich auch Google hinzunehmen. Allerdings, ich möchte keine große Hoffnung machen, eins nach dem anderen. Eine Änderung der Ortsdatenabfrage wird sicherlich dieses Jahr nix mehr werden :-/ Wie auf meiner Webseite angekündigt, versuche ich ja ein etwas größeres Update fertig zu bekommen. Erst danach stünde dann eine Änderung der Ortsdatenabfrage, vielleicht ein Hinzufügen kostenpflichtiger Optionen, zur Disposition. Um Missverständnissen entgegen zu wirken: "Kostenpflichtig" natürlich nicht in Bezug auf mich, sondern die Möglichkeit irgendwelche Services einzubinden, bei denen sich der Benutzer dann ggf. selbst registrieren kann/muss. |
|
Ach, ich sehe gerade erst, Du hast "Nominatim" erwähnt. Das kannte ich bisher nicht. Ist das kostenfrei? Sieht ja fast so aus... Ach so, man braucht einen Provider, der die Datenabfragen kostenfrei zur Verfügung stellt? Also, ich bin ja für alle Aleternativen offen, auch wenn ich das nicht nächste Woche gleich einbauen werde. Änderungen an der Ortsdatenabfrage werde ich definitiv nicht in dieser Version machen. Erst ab der kommenden Version 4, wenn ich sie denn mal fertig habe... |
|
Hier sind ja 3 Provider aufgeführt, wobei mir LocationIQ (https://locationiq.org/) mit 10.000 möglichen täglichen freien Abfragen durchaus akzeptabel erscheint: https://wiki.openstreetmap.org/wiki/Nominatim#Alternatives_.2F_Third-party_providers Man würde dann natürlich auch zwingend einen eigenen Account benötigen... |
|
Hallo und ganz lieben Dank schon mal alleine für deine schnelle Antwort, da Du das in der Freizeit machst hätte ich gar nicht so schnell damit gerechnet, top! Das mit Nominatim ist sicher so eine Sache, was die Abfrage-Kontingente angeht. Abfragen auf den OpenStreetMap-Servern geht, soll aber nur für Testzwecke und einzelne Anfragen genutzt werden und Massenabfragen werden sicher gedrosselt. Aber sich für einen Account irgendwo zu registrieren ist sicher das Letzte woran es scheiten sollte (erst recht nicht, wenn man sich irgendwo im Bereich der kostenfreien aber registrierungspflichtigen Kontingente bewegt), wenn man diese Funktion benötigt oder sehr gerne benutzen möchte. Auch bei GeoNames war ja zumindest ein Account nötig / sinnvoll. Rein von der Datenqualität sollte das für die größten Teile der Welt ein Quantensprung sein, da es sich um OpenStreetMap Daten handelt, wo gerade bei dem hier scheinbar so wichtigen Punkt der Boundaries extrem viel Wert drauf gelegt wird. Und die Daten sind ja nun auch sehr detailliert, auch wenn man/jeder vielleicht nicht (für jedes) Foto(s) immer Genauigkeit bis auf die Hausnummern- oder Objektebene benötigt. Aber da dort Daten immer innerhalb von Boundaries liegen, kann aus Dortmund-Syburg eben nicht Hagen-Syburg werden, und aus einer Bauernschaft in X kein Stadtteil von Y. Nun ist ja auch die Fotografie so wunderbar vielfältig, dass es ja auch nicht schaden kann, so detaillierte Daten zu haben. Schon alleine wenn man wo ist, wo man sich nicht auskennt und die Abfrage der Koordinaten wirft dir sogar aus, dass es z.B. das BvB Fussballstadion ist (https://nominatim.openstreetmap.org/search.php?q=51.49241%2C+7.450921&viewbox=). Nur mal so als blödes Beispiel, gerade nichts besseres im Kopf wo man wirklich sagen könnte wenn man da war, muss man nicht erkannt haben wo ;-) Gerade da wird ja erst interessant, meine sich permanent wiederholenden Locations beschrifte ich auch blind bzw. habe Kürzel für die Textersetzung. Mir ist das Problem beim Radfahren aufgefallen, wo man sich eben durch verschiedene Bauernschaften und über Stadtgrenzen hin und her bewegt, dass da die Daten hinten und vorne nicht stimmen können und ich in der Nachbereitung zu einer Kapelle recherchieren wollte, die GeoNames in Dortmund-Leveringhausen verortet hat. Das ist natürlich vollkommener Blödsinn, das wunderschöne kleine Ding steht in der Nachbar-Stadt Waltrop, immerhin stimmte die Bauernschaft ;-)))) Wäre das jetzt nun nicht in meinem Heimatrevier, hätte ich den Fehler wie bei den anderen Fotos zuvor im Archiv nicht bemerkt. Für die meisten von uns gerade für den privaten Gebrauch nicht realisierbar, daher nur am Rande erwähnt: Bei Nominatim kann man sich theoretisch seine eigene Instanz installieren, planet.osm herunterladen und seinen eigenen Server betreiben. Da gibt es wohl auch noch ein paar andere Engines für eigene Server. Aber wirklich nur ganz am Rande, das werden die wenigsten stemmen können (ich auch nicht ;-) ) Zur Qualität der Daten ein kurzer Schnelltest, vielleicht kann ich damit einen klitzekleinen Beitrag leisten. GPS-Log von einer Radtour im Grenzbereich der vier Städte Dortmund, Schwerte, Hagen und Herdecke. Geladen in die Software von http://www.routeconverter.de. Die hat eine Funktion "Vervollständigen->Postanschrift" und hat die folgenden Geokodierungsdienste implementiert, deren Ergebnisse: GeoNames "51.4188680,7.5052050,Syburg" Photon by komoot.de 51.4188680,7.5052050,44265 Dortmund; North Rhine-Westphalia; Germany 51.4188680,7.5052050,Syburger Dorfstraße 135; 44265 Dortmund; Deutschland Nominatim "51.4188680,7.5052050,Syburger Dorfstraße 135; 44265 Nordrhein-Westfalen; Deutschland" Nur Google und OpenStreetmap erkennen die Straße und sogar Hausnummer, Google unterschlägt das Bundesland welches bei Nominatim aber neben noch deutlich mehr Details die man verarbeiten _könnte_ natürlich da ist. (135, Syburger Dorfstraße, Buchholz, Syburg, Dortmund, Regierungsbezirk Arnsberg, Nordrhein-Westfalen, 44265, Deutschland (Camp Site) direkte Abfrage https://nominatim.openstreetmap.org/search.php?q=51.4188780%2C7.5053350&viewbox=). Mir mögen da gar nicht alle Möglichkeiten einfallen, aber man stelle sich vor man mache im Urlaub wo man sich rein gar nicht auskennt ein Foto einer wunderschönen Wegkappelle und OpenStreetMap kann Daten bis hinter zum Namen der Kapelle liefern. Meiner bescheidenen Meinung nach wäre also OSM als zukünftige Datenquelle geradezu prädestiniert, wenn schon Programmierarbeit da hinein gesteckt wird für eine neue Version. Wobei mich gerade im OpenStreetMap-Umfeld nicht mal wundern würde, wenn da schon jemand einen Referenzcode als OpenSource programmiert hat, den man in seine Anwendung implementieren kann... In diesem Sinne, meinen Respekt, meinen Dank und Wünsche für Gesundheit und Glück an Dich und deine Familie! |
|
Ich bin mal die aktuelle Liste von https://wiki.openstreetmap.org/wiki/Nominatim#Alternatives_.2F_Third-party_providers durchgegangen: - OpenCage: 2500 Anfragen pro Tag reicht zwar nicht ganz, um den ganzen alten Fotobestand in einem Rutsch durchzuarbeiten, aber ansonsten wäre es schon brauchbar. Ein Fragezeichen ist allerdings die mögliche Beschränkung auf eine Abfrage pro Sekunde, die man bei der Massenabfrage für einen kompletten Fotoordner mit Geosetter schon kurzzeitig reißen könnte. Von der Datenqualität wirkt das mit ein paar Stichproben potentiell brauchbar, wenn auch nicht ganz perfekt. Es gibt *kein* vordefiniertes Mapping auf irgendwelche fixen Verwaltungsebenen, das müsste man sich also selbst irgendwie sinnvoll zusammenbasteln, aber das gilt wohl für die meisten dieser Dienste. - LocationIQ: Mit 5000 Abfragen pro Tag, ebenfalls 60 pro Minute und kurzzeitig *2* Abfragen pro Sekunde etwas großzügigere Limits als OpenCage. An Stellen mit "anspruchsvollerer" OSM-Datenlage (sprich Stadtteile/Ortsbezeichnungen nur als Punkte statt als Flächen vorhanden) scheinen die Ergebnisse nach ein paar Stichproben aber etwas schlechter als bei OpenCage zu sein, aber für einen richtigen Vergleich müsste ich das mal im größeren Maßstab ausprobieren. - NetToolKit: Mit 1000 Abfragen pro Tag definitiv nichts fürs Massen-Nachtagging und liefert bei einer kurzen Stichprobe Stadtteilnamen entweder gar nicht, oder anstelle des Stadtnamens, was auch nicht viel brauchbarer ist. - Geoapify: Mit 100.000 Abfragen im Monat und einem kurzzeitigen Limit von 0000010:0000005 Abfragen pro Sekunde in der Hinsicht problemlos. Deswegen hatte ich die auch als erste mal im etwas größeren Maßstab ausprobiert – tendenziell ist die Qualität schon besser als per GeoNames, aber es hat so doch ein paar Seltsamkeiten. Bei der reversen Abfrage fehlen bei einzelnen Koordinaten häufig mal bestimmte Bestandteile (insbesondere der Stadtteil ist, selbst wenn in OSM vernünftig eingetragen, häufig davon betroffen, aber manchmal war es auch das Bundesland/der Landkreis oder in einem Fall sogar die ganze Stadt, die er nicht richtig erkennen wollte), während manchmal nur wenige Meter weiter wieder alles in Ordnung ist. Als Abhilfe bin ich dazu übergegangen, die zu den Koordinaten ausgespuckte Adresse noch einmal vorwärts abzufragen (auch wenn das eine weitere API-Abfrage kostet), da Stadtteilnamen damit zuverlässiger funktionieren. Und wie oben angedeutet, kommen bei lediglich als Punkten eingetragenen Ortsnamen teilweise auch mal seltsame Ergebnisse heraus (z.B. ein Dorf und im nächsten Tal liegt noch ein dazugehöriger kleiner Weiler – daraufhin wird partout bei allen Abfragen im Hauptdorf der abseits gelegene Weiler als "Stadtteil" ausgespuckt, was ich automatisch natürlich überhaupt nicht abfangen kann). OpenCage ist da zwar auch nicht perfekt und eine wirkliche Lösung des Problems geht auch nur über bessere OSM-Daten (Tagging der Stadtteile als Flächen und nicht bloß als Punkte), aber tendenziell doch etwas besser als Geoapify. In einer Stadt wird schließlich für Teile des Stadtzentrums partout irgendein seltsamer Name ausgespuckt, der in den OSM-Daten gar nicht (mehr) auftaucht. - Geocoding API: 5000 Abfragen pro Tag und 3 pro Sekunde sind ebenfalls mit den anderen vergleichbar, aber die API lässt sich ohne Anmeldung überhaupt nicht ausprobieren, sodass ich nichts zur Qualität sagen kann. Benötigt außerdem möglicherweise selbst für das kostenlose Level schon Zahlungsinformationen (Kreditkarte). - Mapquest: Mit 15.000 Abfragen im Monat das geringste Angebot, aber sofern keine zusätzlichen ähnlich eingeschränkten Tages-/Stunden-/etc. -limits gelten vermutlich selbst für ein einmaliges Massen-Nachtagging brauchbar. Laut Lizenzbedingungen bräuchte der Anwendungsfall des Fototaggings aber offiziell möglicherweise eine teure Extralizenz (wobei nicht klar ist, ob das auch für die alternative rein auf OSM-Daten basierende "Open" API ebenfalls gilt), und die API scheint sowieso keine Ortsbezeichnungen auf Stadtteilebene auszuspucken, wäre also ohnehin nicht brauchbar. Um das ganze mal praktisch auszuprobieren, habe ich mir mal einen PHP-basierten Proxyserver gebastelt (zum Glück lässt sich die API-URL in Geosetter ja frei konfigurieren, wenn auch auf HTTP ohne S eingeschränkt), der die Höhendaten- und Zeitzonenanfragen von GeoSetter unverändert an GeoNames durchreicht, sich die Ortsnamen hingegen von anderswo holt und dann im GeoNames-Format an GeoSetter zurückgibt. Für die erste Version hatte ich dazu Geoapify genutzt, aber da das bezüglich Datenqualität mit den häufig fehlenden Daten (siehe oben) mir doch zu lästig geworden war, bin ich beim Aufräumen des Codes auf OpenCage umgezogen. Grundsätzlich funktioniert das Ganze auch gut. Ein Knackpunkt dürfte aber das Mapping von den OSM-Daten auf die vier fixen IPTC-Ebenen sein – ich habe noch nicht mal meine ganze Fotosammlung mal durchprobiert, aber schon bei den Stichproben sind mir einige Fälle aufgefallen, die sich nicht unbedingt mit einer einfachen Prioritätenreihenfolge (z.B. für den Staat/Provinz: Wenn Staat vorhanden nimm das, ansonsten den Landkreis, ansonsten den Stadtnamen, usw.) abhandeln lassen. Mit meiner leicht improvisierten Proxy-Lösung kann ich mir das natürlich wunderbar nach meinen Bedürfnissen einrichten, aber bei einer fix in GeoSetter eingebauten Lösung müsste man das entweder da auch irgendwie konfigurierbar machen, oder vermutlich ein gutes Stückchen Arbeit reinstecken, um zumindest die wichtigsten Problemfälle von Haus aus zu berücksichtigen. Bei den Sprachen kann man sich prinzipiell ähnlich verkünsteln: Alles in Landessprache, oder nur bestimmte Länder, oder nur mit lateinischem Alphabet, oder alles auf Deutsch (oder Englisch)… Falls Interesse besteht, habe ich meinen Code mal hier angehängt. Benötigt werden ein HTTP-Server (idealerweise Apache, falls kein eigener Webspace vorhanden ist, tut es auch ein lokal installierter Webserver) und PHP 7. Die Zip-Datei in das Wurzelverzeichnis des Webservers entpacken (wichtig: Das Ziel muss unter HTTP – nicht HTTPS! – erreichbar sein, da GeoSetter die GeoNames-API nur über HTTP ansprechen kann) und in der proxy.php seinen persönlichen API-Key für OpenCage eintragen. In GeoSetter muss man dann die Adresse der GeoNames-API entsprechend verstellen (soetwas in der Richtung von http://[Adresse des eigenen Webservers]/geoapiproxy) und außerdem vorher einmal %AppData%\GeoSetter\location_cache.dat löschen, damit für bereits verarbeitete Koordinaten nicht veraltete Ergebnisse ausgespuckt werden. geoapiproxy.zip (6,825 bytes) |
|
Die aktuelle Version des Skriptes ist jetzt unter https://github.com/buttercookie42/GeoApiProxy verfügbar. |
Date Modified | Username | Field | Change |
---|---|---|---|
2018-05-08 22:30 | GeoUser | New Issue | |
2018-05-16 11:09 | GeoUser | Note Added: 0003496 | |
2018-05-16 17:43 | Friedemann | Note Added: 0003497 | |
2018-05-16 17:51 | Friedemann | Note Added: 0003498 | |
2018-05-16 18:09 | Friedemann | Note Added: 0003499 | |
2018-05-16 23:08 | GeoUser | Note Added: 0003500 | |
2020-12-29 21:34 | buttercookie42 | File Added: geoapiproxy.zip | |
2020-12-29 21:34 | buttercookie42 | Note Added: 0003843 | |
2021-01-08 00:11 | buttercookie42 | Note Added: 0003845 | |
2022-12-22 02:04 | Friedemann | Status | new => assigned |
2022-12-22 02:04 | Friedemann | Assigned To | => Friedemann |