Author Topic: [GERMAN] Geocodierung - Höhenangaben nicht punktgenau am Ort der GPS - Daten  (Read 2209 times)

wolboe

  • Full Member
  • **
  • Posts: 127
Hallo,
mir fällt heute auf, dass die Höhenangaben für zwei Orte, die Luftlinie max. 200m voneinander entfernt sind, aber einen Höhenunterschied von ca 80m haben, beim Geocodieren den gleichen Höhenwert erhalten, da scheinbar die Höhe nicht exakt vom Punkt der Geokoordinate sondern von einem Referenzort (?) verwendet wird. GeoSetter liefert  Werte mit  Höhenunterschied im erwarteten Bereich.
Was mache ich falsch?

Gruß
Wolfgang

Mario

  • IMatch Developer
  • Administrator
  • *****
  • Posts: 29760
Du geo-codierst welche Koordinaten mit welchem Dienst und welcher Funktion in IMatch?
Beim Geo-codieren verwendet IMatch die vom Dienst gelieferten Höhenangaben wenn noch kein Altitude-Wert in den Metadaten existiert oder 'überschreiben' gewählt ist. Ich greife da nicht ein.
Ich wüsste auch gar nicht, wo ich andere Altitude-Angaben herbekommen sollte.

Häng mal Beispielkoordinaten an und welche Höhe Du davon von welchem Dienst bekommst.
« Last Edit: January 29, 2018, 01:33:07 PM by Mario »

wolboe

  • Full Member
  • **
  • Posts: 127

Suchdienstanbieter: Google
Geokodierungsanbieter:GeoNames.org
in Geosetter: http://api.geonames.org

In den angehängten Screenshots der GPS-Daten von zwei Bildern ist ersichtlich, dass ein Bild keinen Höhenwert enthält (keine Ahnung warum, zugehörige Bilder sind direkt aus der Kamera  - in beiden Fällen Smartphone Samsung S7).

Dadurch erklärt sich mir aber evtl. die Ursache für eingetragenen Höhenwerte - wenn man beim umgekehrten Geokodieren die Option "Nur leere Felder füllen" markiert, bleibt der von der Kamera gelieferte Höhenwert erhalten, im anderen Fall wird er von dem Wert, der sich aus "Gefundene Orte" ergibt, überschrieben - und dieser Wert paßt dann zwar zu "Gefundene Orte", aber eben nicht immer exakt zur Koordinate. GeoSetter verwendet hier offensichtlich den Höhenwert, der lt. Google zur Koordinate gehört.

Mario

  • IMatch Developer
  • Administrator
  • *****
  • Posts: 29760
Quote
GeoSetter verwendet hier offensichtlich den Höhenwert, der lt. Google zur Koordinate gehört.

Wie das, wenn GS geonames.org verwendet?
IMatch trägt den Höhenwert ein, der von GeoNames geliefert wird, wenn Du GeoNames als Anbieter nutzt. IMatch sucht nicht nochmal extra nach einem anderen Höhenwert oder so. Wenn Du "Domplatz in Köln" als Adresse auswählst, sollte auch der damit assoziierte Höhenwert eingetragen werden. Und nicht der Höhenwert 100 Meter weiter?!...

wolboe

  • Full Member
  • **
  • Posts: 127
Genau das verstehe ich eben nicht - hänge mal ein kleingerechnetes Bild an. Der Höhenwert darin  ist 293m und gefühlt richtig. Wende ich in IM umgekehrte Geokodierung an, werden mir bei "Laden" diverse "Gefunden Orte" angeboten. Läßt man nun  "Nur leere Felder füllen" offen, dann wird dort der Höhenwert eingetragen, der zum ausgewählten "Gefundenen Ort" gehört.
In dem Bild ist das eben nicht der Höhenwert, der zur Koordinate gehört, denn der Ort wird in der Karte richtig gezeigt - aber die Höhe paßt nicht dazu. Sobald man einen anderen "Gefundenen Ort" auswählt, erhält man auch eine andere Höhe.

Mario

  • IMatch Developer
  • Administrator
  • *****
  • Posts: 29760
Das ist doch korrekt so.

IMatch hat keine Funtion die zu einer Koordinate irgendwo einen Höhenwert beschafft. Es schickt die Koordinaten an den Dienst, und zeigt Dir das Ergebnis an. Jedes Ergebnis ist mit einem Höhenwert verknüpft. Und denn nimmt IMatch auch. Woher sollte es einen anderen Höhenwert bekommen?

wolboe

  • Full Member
  • **
  • Posts: 127
....Woher sollte es einen anderen Höhenwert bekommen?
Das weiß ich nicht - ich vergleiche mit Geosetter: -  dort werden Ort und Höhe separat abgefragt, deshalb ändert sich bei Auswahl eines anderen angebotenen Ortes die Höhe nicht, da dieser Höhenwert zur exakten Geokoordinate gehört (siehe Anlagen).
Im Vergleich der beiliegenden Screenshots der analogen Arbeitsschritte von IM und GeoSetter sieht man weiterhin, dass jeweils der gleiche Ort aus den angebotenen Orten ausgewählt wurde und diese Daten wohl auch aus der gleichen Datenquelle stammen.

Gruß
Wofgang

Mario

  • IMatch Developer
  • Administrator
  • *****
  • Posts: 29760
Das würde bdeuten, dass IMatch für jeden Reverse-geocoding Vorhang zweimal GeoSetter abfragen muss. Das ist ein freier Dienst, der von Freiwilligen betrieben und finanziert wird. Die von IMatch generierte Last auf den GeoNames.org Server einfach mal so zi verdoppeln scheint mir unnnötig und uinfair.

Du bist der erste User, der mit der Festlegung der Höhe auf der Basis der ausgewählten Adresse jemals ein Problem gemeldet hat. Warum nimmst du nicht einfach Geo-Setter für diese Spezialfälle?

wolboe

  • Full Member
  • **
  • Posts: 127
... Warum nimmst du nicht einfach Geo-Setter für diese Spezialfälle?

GeoSetter nutze ich schon seit vielen Jahren,  wollte aber (möglichst) alle Bearbeitungsschritte mit/in IM vollziehen - "trenne" mich deshalb auch von FixFoto, außer es geht um Bildbearbeitung.

 

Mario

  • IMatch Developer
  • Administrator
  • *****
  • Posts: 29760
Du kannst gerne einen Feature Request schreiben. Vielleicht haben andere User auch das Problem mit der Höhe.
Ich sehe aber wie gesagt keinen echten Grund für eine Änderung. Schon gar nicht die Anzahl der Abfragen auf die freien GeoSetter-Server zu verdoppeln, nur um eine "genauere" Altitude zu ermitteln.

wolboe

  • Full Member
  • **
  • Posts: 127
Du kannst gerne einen Feature Request schreiben....
Für mich allein? - kaum.
Die "Fehler" kommen ja auch nur zum Tragen, wenn die "Gefundenen Orte" zum Koordinatenpunkt  deutliche Höhenunterschiede haben - eben in bergigen Regionen.
Mir ist es auch nur aufgefallen, weil ich wußte, dass die zwei Orte, deren Höhenlage ich vergleichen wollte, nicht die gleiche Höhe haben können - da habe ich nach möglichen Ursachen/Zusammenhängen gesucht,

Gruß und Dank
Wolfgang

wanderer2022

  • Full Member
  • **
  • Posts: 155
Ich mache es auch extern, entweder in Geosetter, oder mit einem Plugin innerhalb von Lightroom. Damit bekomme ich die Strasse dazu, was mir wichtig ist. Geht gut und für 2 Hanseln lohnt es sich nicht was zu ändern.
Schöne Grüße
Hans
Danke für jeden der sich die Mühe gibt zu versuchen was gehen kann und was nicht.
Hans

Mario

  • IMatch Developer
  • Administrator
  • *****
  • Posts: 29760
Quote
Damit bekomme ich die Strasse dazu,

Die Strasse sollte auch in IMatch verfügbar sein. Welchen Dienst verwendest Du in IMatch? Beispiel-Koordinaten?

wanderer2022

  • Full Member
  • **
  • Posts: 155
die Koordinate 51.883333 und 8.500000  und als Dienst verwende ich Geonames mit eigenem Benutzernamen bei Imatch. Sehr oft sind allerdings auch Autobahnen und Waldwege unter den Koordinaten, dann ziehe ich die Daten via Lightroom Plugin von Jeffrey Friedel's Geoencoding Support und da benutze ich dann die OSM Daten da auch Wanderwege die einen Namen tragen bringen.
Danke für jeden der sich die Mühe gibt zu versuchen was gehen kann und was nicht.
Hans

Mario

  • IMatch Developer
  • Administrator
  • *****
  • Posts: 29760
IMatch bietet GeoNames.org und Goolge Maps an. Das ist schon viel für ein DAM.

Das Problem bei OSM (bzw. Nominatim) sind die Nutzungsbedingungen bzw. die Limits:

https://operations.osmfoundation.org/policies/nominatim/

So wie ich das interpretiere, wäre eine Nutzung von IMatch aus illegal, z.B.:

No heavy uses (an absolute maximum of 1 request per second).

Maximal eine Abfrage pro Sekunde - und das gilt für alle IMatch-Benutzer zusammen!

Es gibt auch eine "No Bulk"-Regel, und das ist ja genau, was IMatch User machen wenn sie neue Bilder aufnehmen oder mehr als ein paar Bilder reverse geo-codieren....

Ich kenne das von Dir erwähnte Plug-in nicht und weiß daher nicht, wie die das machen.
Vielleicht haben die ihre eigene Infrastruktur mit einem Server der die Abfragen cached. Oder sie lassen eine Kopie von Nominatim auf einem ihrer Server laufen.

Das wäre mir zu aufwändig, GPS ist ja nur 0.05% vom IMatch Funktionsumgang, wenn überhaupt.

Allerdings biete GeoNames.org nun auch Endpunkte mit OSM im Namen an, zum Beispiel

http://api.geonames.org/findNearbyStreetsOSMJSON?lat=51.883333&lng=8.500000&username=demo

oder auch

http://api.geonames.org/findNearbyPOIsOSMJSON?lat=51.883333&lng=8.500000&username=demo

Schau Dir mal die Ausgaben von diesem Link an (eventuell musst Du demo durch Deinen Benutzernamen ersetzen).
« Last Edit: January 30, 2018, 09:13:57 AM by Mario »

Mario

  • IMatch Developer
  • Administrator
  • *****
  • Posts: 29760
PS.:

Ich habe mir mal den Code angeschaut. Nachdem IMatch mittels findNearbyPlaceNameJSON die passenden Ortsangaben für die Bildkoordinaten abgefragt hat, holt es für jede Adresse ohne Höhe via astergdemJSON noch die Altitude bei GeoNames ab. Das habe ich 2015 extra so programmiert.

Um euer "Problem" zu beheben müsste IMatch statt dessen einmalig die Altitude zu den Bildkoordinaten (nicht Adresse) abholen. Aber dann passt die Höhe noch mehr zur Adresse. Ob sowas von der Mehrzahl der User gewünscht ist?

wanderer2022

  • Full Member
  • **
  • Posts: 155
"Allerdings biete GeoNames.org nun auch Endpunkte mit OSM im Namen an, zum Beispiel

http://api.geonames.org/findNearbyStreetsOSMJSON?lat=51.883333&lng=8.500000&username=demo

oder auch

http://api.geonames.org/findNearbyPOIsOSMJSON?lat=51.883333&lng=8.500000&username=demo"
Ok der erste liefert die Strassen, sortiert im Abstand zur Koordinate, der Zweite das Geschäft was dort vorhanden ist. Geht mit meinem Namen ohne jedes Problem.

Ich habe es natürlich auch mit Google aus Imatch raus versucht, aber ohne meine Api geht garnichts, mit bleibt das Kartenbild schwarz, das kann aber auch an dem merkwürdigen Weg bei Google liegen um überhaupt eine API zu bekommen, so recht schlau bin ich nicht draus geworden was die wollen aber da ich eh LR parallel betreibe (kein Abo, die 6er) war mir das auch egal.

Das Plugin was ich in LR nutze ist dieses: http://regex.info/blog/lightroom-goodies/gps, so nebenbei macht der Typ auch noch tolle Bilder in Japan. Das der jede Sekunde nur ein Bild abfragt kann sein, das dauert aber bei GeoNames manchmal auch so eine Sekunde.
Was ich verstehe, für 0.05% User würde ich da auch nichts tun und wie gesagt, ich habe eine Lösung dafür, pass schon.

Danke für jeden der sich die Mühe gibt zu versuchen was gehen kann und was nicht.
Hans

Mario

  • IMatch Developer
  • Administrator
  • *****
  • Posts: 29760
Quote
Das der jede Sekunde nur ein Bild abfragt kann sein, das dauert aber bei GeoNames manchmal auch so eine Sekunde.

Dieses Limti gilt pro Anwendung. Wenn also mehrere Leute sein Plug-in gleichzeitig nutzen, müsste er einen eigenen Server vorschalten, der die Zugriffe of OSM synchronisiert und sicher stellt, dass nur ein Zugriff pro Sekunde erfolgt. Ob es so einen Aufwand treibt oder ob er die Nutzungsbestimmungen von OSM einfach ignoriert? Das wäre nicht fair, OSM ist ja ein Projekt von Freilwilligen, die auch für alles zahlen.

Wenn er über seinen zentralen Server routed, müsste das Plug in ja auch eigene Privacy-Einstellungen und eine entsprechende Belehrung des Users anzeigen (US / Europäisches Recht), weil die GPS-Abfragen der User nicht nur an OSM gehen, sondern auch "durch" den Server des Plug-in Autors laufen. Er kann also alles mitlesen, einschließlich IP-Adresse, gesetzter Cookies und alle Informationen, die ein Lr Plug-in auf dem Rechner des Users sammeln kann...mhm.

Das wäre mir alles zu aufwändigm, echt.

Quote
das dauert aber bei GeoNames manchmal auch so eine Sekunde.
IMatch wartet immer mindestens eine Sekunde nach einer Abfrage, um die Bestimmungen von GeoNames einzuhalten und ihre Server nicht mit hunderten von Requests pro Sekunde zuzuballern. Das ist nur fair.
Die Performance der freien GeoNames-Server schwankt auch sehr, abhängig davon, wie viele User gerade drin sind.

Es gibt auch eine bezahlte "Premium"-Variante von GeoNames (http://www.geonames.org/commercial-webservices.html) bei der man deutlich mehr Leistung bekommt.
Das billigste Paket kostet 40$ im Monat und dafür bekomment man 100,00 Anfragen mit maximal 2000 Abfragen pro Tag und 250 Abfragen (aka 125 Bilder a 2 Abfragen) pro Stunde.

wanderer2022

  • Full Member
  • **
  • Posts: 155
'OSM ist ja ein Projekt von Freilwilligen, die auch für alles zahlen', stimmt ich gehöre auch dazu, ich investiere Zeit und Geld um die Karten aktuell zu halten, dafür benutze ich genau die Lokation, ich Wandere offizielle Wege ab, schaue ob sie in OSM erfasst sind, trage sie nach oder modifiziere sie und wenn sie dann nicht als Wanderwege drin sind, passe ich sie an und freue mich, wenn es dann auf den Karten zu sehen ist. Vor Jahren gab es da viel zu tun, aber heute ist schon der Großteil erfasst. Das begann lange bevor Google auf die Idee kam Waldwege zu kartographieren. Es macht spass und ab und an denke ich mal warum, dauert nicht lange, dann weil ich es kann.
Danke für jeden der sich die Mühe gibt zu versuchen was gehen kann und was nicht.
Hans

Mario

  • IMatch Developer
  • Administrator
  • *****
  • Posts: 29760
Ich habe mal ein bischen gebastelt und für die von Dir als Beispiel genannten Koordinaten bekomme ich jetzt:



Ist das beser? IMatch ruft nun den GeoNames OSM endpoint für Adressen auf, die einen über den normalen Aufruf mit einem leeren Straßennamen zurückkommen.

wanderer2022

  • Full Member
  • **
  • Posts: 155
Ich kann die Strasse  jetzt nicht sehen, aber wenn er nun Straße mit Kolpingstrasse beantwortet wäre es Cool, wenn er St Anna Strasse antwortet perfekt. Hintergrund ist, es liegt näher an der Kolpingstrasse, wird aber über St, Anna erschlossen. Kann man die Straße dann auch eintragen lassen in den XMP?
Danke für jeden der sich die Mühe gibt zu versuchen was gehen kann und was nicht.
Hans

Mario

  • IMatch Developer
  • Administrator
  • *****
  • Posts: 29760
Mist    
Falscher Screen Shot. Das ware der alte Zustand.

Mit dem neuen Verfahren erhalte ich:



IMatch nimmt die als Erstes von GeoNames/OSM gelieferte Strasse pro Koordinate um die leere Strasse zu füllen. St. Anna kommt als 2., die 1. is Kolpingstraße. Ich kann keine zweo Strassen eintragen.
Es scheibt aber, die Ergebnisse von GeoNamesOSM sind nicht nach Distance sortiert sondern nach sonstwas...? Mhm.

XMP hat keinen Eintrag für Strasse. Es gbt nur Location und die wird entweder von SubLocation oder Straße gefüllt, je nachdem, was verfügbar ist und vom User ausgewählt wird.
« Last Edit: January 30, 2018, 04:25:06 PM by Mario »

wanderer2022

  • Full Member
  • **
  • Posts: 155
Die Kolpingstrasse sieht Geonames richtig, da keine Location Data für die Garagen existieren, damit wird die next genommen. Auf der Zeichnung ist deutlich zu sehen, das nur die Häuser die Hausnummer haben und nur die haben den Ort und die Strasse drin so wie die Hausnummer. Im Prinzip sind das alles Objekte im Objekt im Objekt und aus den Linien werden erst durch die Eigenschaften der Objekte das was man hinterher auf der Karte sieht.
Für mich wäre Location ok und die Strasse würde reichen.
Danke für jeden der sich die Mühe gibt zu versuchen was gehen kann und was nicht.
Hans

Mario

  • IMatch Developer
  • Administrator
  • *****
  • Posts: 29760
IMatch fordert nun 10 Ergebnisse von /findNearbyStreetsOSMJSON an und sortiert sie nach 'distance'.
Damit erhalten wie für den Testfall



Es ist nicht dokumentiert, wonach findNearbyStreetsOSMJSON die Ergebnisse sortiert, aber für unseren Fall ist Distanz auf jeden Fall richtig.

Theoretisch könnte IMatch noch weitere Sätze aus den von OSM gelieferten Daten synthetisieren, also ggf. noch einen Eintrag für die Kolpingstraße einbauen. Aber ich denke, dass geht zu weit.

wanderer2022

  • Full Member
  • **
  • Posts: 155
Distanz ist auf jeden Fall richtig, sieht klasse aus und wäre cool so was zu haben. Danke dir für Deine Mühen.
Danke für jeden der sich die Mühe gibt zu versuchen was gehen kann und was nicht.
Hans

wolboe

  • Full Member
  • **
  • Posts: 127
Hallo,
war ein paar Stunden nicht am Rechner - das Thema ist ja in eine andere, aber damit auch noch  interessantere Richtung "abgedriftet" - die Version mit den Straßennamen könnte mir auch gefallen ...

Gruß
Wolfgang

Mario

  • IMatch Developer
  • Administrator
  • *****
  • Posts: 29760
Das ist jetzt so implementiert.

An der Art, wie IMatch die Höhe bestimmt, hat sich nichts geändert. Die Höhe wird aus der vom Benutzer gewählten Adresse übernommen. Ich denke, das ist für die Mehrzahl der Benutzer das korrekte Verhalten.

wolboe

  • Full Member
  • **
  • Posts: 127
... Ich denke, das ist für die Mehrzahl der Benutzer das korrekte Verhalten.

Das sehe ich auch so!