seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11180
Wohnort: München
|
glaskugel schrieb: Du hattest übrigens recht, der Track versteckt sich bei der Sevilla Rückfahrt bei Algier, man muss entsprechend tief zoomen. Problematisch finde ich, dass die Tracks im Ort Ayamonte bei Algier sind.
Ich denke, die Grenzungenauigkeiten von ca. 1km bei einer Route kann man vernachlässigen, aber dass Ayamonte total daneben ist, dafür muss man sich einen Workaround überlegen. "alg" im Dateinamen steht für Algier, sollte aber eigetlich klar sein.
Da musst du dir überlegen, was du haben willst, wenn tzwhere raten muss - entweder man gibt dann für den Abgleich mit den Bildern eine Zeitzone vor statt die Lokalzeit mit den Angaben von tzwhere zu errechnen, man fragt Geonames oder Google Maps, ignoriert den Punkt usw.
|
glaskugel
(Themenstarter)
Anmeldungsdatum: 8. Juli 2010
Beiträge: 3453
|
Ich lade dir meine Algier-gpx-Datei zum Testen hoch, könnte größer sein als deine. Vielleicht siehst du eine Möglichkeit zum Elimieren der Punkte über die Geschwindigkeit.
- test_Africa_Algiers.gpx.tar.gz (11.9 KiB)
- Download test_Africa_Algiers.gpx.tar.gz
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11180
Wohnort: München
|
Wäre es eventuell ausreichend nach der Höhe zu filtern? Die störenden Wegpunkte über dem Meer sind da ja alle mindestens 1 km hoch in der Luft.
|
glaskugel
(Themenstarter)
Anmeldungsdatum: 8. Juli 2010
Beiträge: 3453
|
Hmmh, daran habe ich auch schon gedacht. In Portugal würde das schon passen, aber in anderen Regionen, zB Alpen, da ist man schnell über 1km und im Flugzeug natürlich auch. Ich bin jetzt für einige Stunden weg und schaue vermutlich am späteren Abend wieder vorbei.
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11180
Wohnort: München
|
gpsbabel kann ja Dateien nach verschiedenen Kriterien wie z.B. Zeit, Mindest- und Maximalhöhe, Umkreis usw. aufsplitten und auch wieder zusammensetzen - ich denke um eine gewisse Vorarbeit kommt man nicht herum und gut aufbereitete Daten sind immer die Voraussetzung für automatisierte Prozesse, die nicht beliebig komplex sein können. Dann fehlt jetzt eigentlich nur noch die Möglichkeit dem Programm zu sagen, dass es optional alle Punkte in einer GPX-Datei beim Vergleich mit Bildern mit einem bestimmten UTC-Offset bzw. einer Zeitzonen-ID in eine einheitliche Lokalzeit umrechnen soll, oder?
|
glaskugel
(Themenstarter)
Anmeldungsdatum: 8. Juli 2010
Beiträge: 3453
|
gpsbabel kann ja Dateien nach verschiedenen Kriterien wie z.B. Zeit, Mindest- und Maximalhöhe, Umkreis usw. aufsplitten und auch wieder zusammensetzen
Kennst du da eine Seite mit Beispielen dazu? Ich habe mir da bereits was zusammengesucht, die Anwendung dann war eher intuitiv. Nach Zeit splitten klappt meistens, aber auch nicht immer. Zur Höhenfilterung ist mir noch was eingefallen. Kannst du einen Minimalwert, Maximalwert und Mittelwert der Höhe ausgeben (oder vielleicht auch die Varianz). Dann hat man einen Anhaltspunkt ab welcher Höhe man filtern kann und kann dann logische Irrläufer rauswerfen. Ob ein Album einen Flug enthält, weiß man ja und bei Fotos auf Meereshöhe kann man dann leicht entscheiden zB alles über 1000m rauszuwerfen, wenn man den Maximalwert hat, dann sieht man da auch gleich, dass da was nicht passt.
ich denke um eine gewisse Vorarbeit kommt man nicht herum und gut aufbereitete Daten sind immer die Voraussetzung für automatisierte Prozesse, die nicht beliebig komplex sein können.
Sicherlich. Dieses Zeitzonengrenzen-Beispiel ist eher die Ausnahme, muss man aber trotzdem irgendwie lösen. Bei meinen Fotos bin ich auf noch keine Probleme gestoßen, aber auch mir kann es passieren, dass die GPS-Daten problematisch sind. Ich schaue von Zeit zu Zeit auf den Empfang, andere haben das GPS einfach in der Fototasche und kümmern sich nicht weiter darum.
Dann fehlt jetzt eigentlich nur noch die Möglichkeit dem Programm zu sagen, dass es optional alle Punkte in einer GPX-Datei beim Vergleich mit Bildern mit einem bestimmten UTC-Offset bzw. einer Zeitzonen-ID in eine einheitliche Lokalzeit umrechnen soll, oder?
Das habe ich immer noch nicht ganz verstanden und lasse mich überraschen wie das mit Ayamonte dann gemacht werden soll. Ich probiere jetzt mal die Fotos von Spanien und Portugal zu trennen. Die Ausgabe der Splits in eine Datei wie beschrieben wäre schon hilfreich, dann hat man sie auch für den nächsten Tag noch. Ergänzung: GPX-Dateien mit gleicher Zeit kann man natürlich manuell zusammensetzen, aber bei einem Flug über viele Länder ist das aufwendig. Ist das schwierig zu automatisieren? Du schriebst ja schon mal, dass da problematische Fälle sein können. Bei einem Flug von D nach Griechenland kommt da einiges zusammen, wobei dann auch die Schwierigkeit besteht, die Länder in der richtigen Reihenfolge aneinander zu hängen.
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11180
Wohnort: München
|
glaskugel schrieb: Kennst du da eine Seite mit Beispielen dazu? Ich habe mir da bereits was zusammengesucht, die Anwendung dann war eher intuitiv. Nach Zeit splitten klappt meistens, aber auch nicht immer.
Das ist in der Dokumentation eigentlich recht gut und inklusive Beispielen erklärt: https://www.gpsbabel.org/htmldoc-1.5.3/Data_Filters.html - ggf. muss man mehrere Tracks in einer Datei erst zusammenführen, bevor man sie nach einem neuen Kriterium splitten kann. Zur Höhenfilterung ist mir noch was eingefallen. Kannst du einen Minimalwert, Maximalwert und Mittelwert der Höhe ausgeben (oder vielleicht auch die Varianz). Dann hat man einen Anhaltspunkt ab welcher Höhe man filtern kann und kann dann logische Irrläufer rauswerfen. Ob ein Album einen Flug enthält, weiß man ja und bei Fotos auf Meereshöhe kann man dann leicht entscheiden zB alles über 1000m rauszuwerfen, wenn man den Maximalwert hat, dann sieht man da auch gleich, dass da was nicht passt.
Also z.B. so?
$ ./geoinfo.py -s gpx/zeitzonenwechsel43-4x.gpx
[...]
elevation_maximum=167
elevation_minimum=-12
elevation_mean=42
elevation_median=29
elevation_stdev=37
elevation_variance=1440
[...]
Dann fehlt jetzt eigentlich nur noch die Möglichkeit dem Programm zu sagen, dass es optional alle Punkte in einer GPX-Datei beim Vergleich mit Bildern mit einem bestimmten UTC-Offset bzw. einer Zeitzonen-ID in eine einheitliche Lokalzeit umrechnen soll, oder?
Das habe ich immer noch nicht ganz verstanden und lasse mich überraschen wie das mit Ayamonte dann gemacht werden soll. Ich probiere jetzt mal die Fotos von Spanien und Portugal zu trennen. Die Ausgabe der Splits in eine Datei wie beschrieben wäre schon hilfreich, dann hat man sie auch für den nächsten Tag noch.
Wenn du den Spezialfall hast, dass tzwhere eine Zeitzonen-ID falsch zuordnet, kannst du die Tracks aus den GPX-Dateien mit gpsbabel mergen und dann dem Skript sagen, dass es alle Punkte in einer Datei mit einer bestimmten Zeitzonen-ID behandeln soll.
Ergänzung: GPX-Dateien mit gleicher Zeit kann man natürlich manuell zusammensetzen, aber bei einem Flug über viele Länder ist das aufwendig. Ist das schwierig zu automatisieren? Du schriebst ja schon mal, dass da problematische Fälle sein können. Bei einem Flug von D nach Griechenland kommt da einiges zusammen, wobei dann auch die Schwierigkeit besteht, die Länder in der richtigen Reihenfolge aneinander zu hängen.
Das Problem ist nicht der Länderwechsel (solange er die Zeitzonen-ID richtig erkennt), sondern der Zeitpunkt, an dem du die Zeit in der Kamera umgestellt hast. Generell kann man die Menge an Punkten dadurch reduzieren, dass man sinnvolle Filterkriterien mit GPSBabel darauf anwendet - wenn du z.B. weißt, dass du erst zu einer bestimmten Zeit Bilder an einem Ort gemacht hast, kannst du frühere und spätere Punkte rausfiltern. Wenn du weißt, dass du auf in einem bestimmten Bereich über Landesgrenzen hinweg unterwegs warst und dabei die Zeit in der Kamera nicht angepasst hattest, kannst du einen Polygon- oder Umkreisfilter nutzen und danach die passende Zeitzone bzw. den gewünschten UTC-Offset für den Vergleich erzwingen (das lade ich später noch hoch).
|
glaskugel
(Themenstarter)
Anmeldungsdatum: 8. Juli 2010
Beiträge: 3453
|
Das ist in der Dokumentation eigentlich recht gut und inklusive Beispielen erklärt
Danke, ich muss mir das mal ganz langsam durchlesen und mir die Anwendungen überlegen. Kann man da auch Punkte ab einer Geschwindigkeit rauswerfen? Ich habe mir überlegt, dass das eine 99%-Lösung für meine falschen Koordinaten ist.
Also z.B. so?
Ja genau. Diese Statistik hilft im Zweifel viel.
Wenn du den Spezialfall hast, dass tzwhere eine Zeitzonen-ID falsch zuordnet, kannst du die Tracks aus den GPX-Dateien mit gpsbabel mergen und dann dem Skript sagen, dass es alle Punkte in einer Datei mit einer bestimmten Zeitzonen-ID behandeln soll.
Jetzt wird es verständlicher.
wenn du z.B. weißt, dass du erst zu einer bestimmten Zeit Bilder an einem Ort gemacht hast, kannst du frühere und spätere Punkte rausfiltern.
Ich denke das Beschränken der GPX-Daten auf die entsprechende Zeit ist was ganz was wesentliches
und dabei die Zeit in der Kamera nicht angepasst hattest,
Ich gehe im Normalfall davon aus, dass vor dem Laufen des Scripts die Lokalzeit stimmt, außer man trickst in Spezialfällen. Ich habe noch eine Verständnisfrage zum Abgleich bei dieser Portugal - Spanien Problematik. Bei dieser Fahrt über den Grenzfluss von Portugal nach Spanien wird in Spanien die Zeit um 1h später, dh da sollte es keine Probleme bzgl. doppelt möglicher Zeiten geben, das gibt es nur bei der Rückfahrt. So wie es im konkreten Fall aussieht, wurden die letzten Fotos auf dem Boot auf der spanischen Seite gemacht. Nach 110725-1342 Lokalzeit könnte man also die Tracks rauswerfen. Ist jetzt das Problem beim Abgleich, dass der größte Teil als Algier-Zeitzone erkannt wird und damit die Zuordnung nicht passt? Es geht da um ca. 100 Fotos. Wird da eine andere Cache-Datei erstellt, wenn man mit OSM bzw. Google abfrägt? Sollte das mit Google nicht machbar sein, wenn man vorher die gpx-Datei möglichst reduziert? Du schriebst ja, dass das mit Google viel besser stimmt. python3 /usr/local/bin/geoinfo.py
usage: geoinfo.py [-h] [--cachedir CACHEDIR] [--google-maps-apikey APIKEY]
[--geonames-username USERNAME] [--geocoder GEOCODER]
[--compare-elevation] [--tzsplit] [--tzname TZ]
[--timedelta DELTA] [--language LANGUAGE]
GPXFILE|COORDINATES [IMAGE [IMAGE ...]] Kann man bei deinem Script zu den Optionen mehr in der Shell erfahren, zB welche Geocoder möglich sind und wie die genau zu benennen sind. Ich habe mir das aus dem Thread zusammengesucht. In welcher Einheit ist timedelta anzugeben? --compare-elevation habe ich nicht mitbekommen, worum ging es da?
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11180
Wohnort: München
|
glaskugel schrieb: Kann man da auch Punkte ab einer Geschwindigkeit rauswerfen? Ich habe mir überlegt, dass das eine 99%-Lösung für meine falschen Koordinaten ist.
Bei GPSBabel habe ich in der Dokumentation dazu nichts gefunden (man kann aber nach räumlichen und zeitlichen Distanzen zwischen Punkten splitten, also könntest du wenn dein GPS-Tracker alle 60 Sekunden einen Punkt loggt z.B. sagen, dass er splitten soll, wenn der nächste Punkt mehr als 3600 m entfernt ist, weil die Geschwindigkeit dann über 216 km/h wäre ). Mit gpxpy kann ich die Geschwindigkeit zwischen zwei Punkten in Metern pro Sekunde ermitteln. Ich könnte beim Erstellen der Cache-Datei danach filtern, da ich dabei die Segmente der einzelnen Tracks Punkt für Punkt durchlaufe. Für den ersten Punkt eines Tracks gibt es generell keine Geschwindigkeitsinformationen, weil die Geschwindigkeit aus der räumlichen und zeitlichen Distanz von zwei Punkten errechnet wird. Ein weiteres Problem ist, dass man bei einem Ausreißer nicht nur den Punkt eliminiert, der unerwartet weit weg ist, sondern auch den eigentlich korrekten Punkt nach dem Zurückspringen. Wenn zwei Ausreißer nahe bei einander liegen, hilft ein Geschwindigkeitsvergleich auch nicht - da ist eine Begrenzung auf einen Umkreis oder ein Polygon für den Bereich, in dem man sich aufgehalten hat, viel zuverlässiger.
Ich gehe im Normalfall davon aus, dass vor dem Laufen des Scripts die Lokalzeit stimmt, außer man trickst in Spezialfällen. Ich habe noch eine Verständnisfrage zum Abgleich bei dieser Portugal - Spanien Problematik. Bei dieser Fahrt über den Grenzfluss von Portugal nach Spanien wird in Spanien die Zeit um 1h später, dh da sollte es keine Probleme bzgl. doppelt möglicher Zeiten geben, das gibt es nur bei der Rückfahrt. So wie es im konkreten Fall aussieht, wurden die letzten Fotos auf dem Boot auf der spanischen Seite gemacht. Nach 110725-1342 Lokalzeit könnte man also die Tracks rauswerfen. Ist jetzt das Problem beim Abgleich, dass der größte Teil als Algier-Zeitzone erkannt wird und damit die Zuordnung nicht passt?
Ja, wobei in dem Fall aber wenn ich das richtig verstanden habe sowohl Fotos aus Portugal als auch aus Spanien falsch zugeordnet wurden und die Kamera dabei auf die spanische Lokalzeit eingestellt war - d.h. man muss die errechnete Lokalzeit sowieso ignorieren und eine Zeitzone bzw. einen UTC-Offset vorgeben, um die Zeitstempel der Bilder zuverlässig vergleichen zu können. Es geht da um ca. 100 Fotos. Wird da eine andere Cache-Datei erstellt, wenn man mit OSM bzw. Google abfrägt? Sollte das mit Google nicht machbar sein, wenn man vorher die gpx-Datei möglichst reduziert? Du schriebst ja, dass das mit Google viel besser stimmt.
Im Prinzip könnte man sich die Zeitzonen-Information von Google oder OSM holen (das müsste ich noch einbauen). Alternativ könnte man auch angeben, dass man die Zeitzone bzw. den UTC-Offset kennt und ohne Online-Abfrage auskommen (das habe ich gerade als --tzid und --utcoffset ins Skript eingebaut). Kann man bei deinem Script zu den Optionen mehr in der Shell erfahren, zB welche Geocoder möglich sind und wie die genau zu benennen sind. Ich habe mir das aus dem Thread zusammengesucht.
Klar, einfach das Skript fragen - hier sieht das gerade so aus:
$ ./geoinfo.py --help
usage: geoinfo.py [-h] [--cachedir CACHEDIR] [--google-maps-apikey APIKEY]
[--geonames-username USERNAME] [--geocoder GEOCODER]
[--compare-elevation] [--tzsplit] [--tzname TZ]
[--utcoffset UTC-OFFSET] [--tzid TZ-ID] [--timedelta DELTA]
[--language LANGUAGE]
GPXFILE|COORDINATES [IMAGE [IMAGE ...]]
match EXIF DateTimeOriginal field with trackpints from a gpx file and return
geoinformation with OSM data for the picture
positional arguments:
GPXFILE|COORDINATES gpx file with trackpoints or a set of decimal
coordinates, e.g. "48.1374300, 11.5754900" for
Munich's City Center
IMAGE image file(s) with DateTimeOriginal exif data
optional arguments:
-h, --help show this help message and exit
--cachedir CACHEDIR, -c CACHEDIR
cachedir to use for gpx file. If ommitted the current
directory is used
--google-maps-apikey APIKEY, -a APIKEY
Google Maps API key
--geonames-username USERNAME, -u USERNAME
username for geonames API
--geocoder GEOCODER, -g GEOCODER
choose geocoder: osm or googlemaps (default: osm)
--compare-elevation, -e
compare elevation values for google maps and geonames
for a given set of coordinates. Needs both Google Maps
API key and genonames username
--tzsplit, -s create timezone separated gpx files
--tzname TZ, -t TZ timezone for gps timestamps (default='UTC')
--utcoffset UTC-OFFSET, -z UTC-OFFSET
convert alle gpx timestamps to a local time using the
given offset in seconds instead of the calculated
timezone
--tzid TZ-ID, -i TZ-ID
convert all gpx timestamps to localtime for a given
timezone-id (e.g. "Europe/Berlin") instead of using
the calculated timezone
--timedelta DELTA, -d DELTA
maximum allowed timedelta between timestamps in
seconds to match (default: 3600 s)
--language LANGUAGE, -l LANGUAGE
preferred language as country code for geographical
names, if unset, return names in local language of the
requested point In welcher Einheit ist timedelta anzugeben?
Sekunden, siehe obige Ausgabe --compare-elevation habe ich nicht mitbekommen, worum ging es da?
Da wolltest du Höhenwerte von geonames und Google Maps für gegebene Koordinaten vergleichen können.
|
glaskugel
(Themenstarter)
Anmeldungsdatum: 8. Juli 2010
Beiträge: 3453
|
Bei GPSBabel habe ich in der Dokumentation dazu nichts gefunden (man kann aber nach räumlichen und zeitlichen Distanzen zwischen Punkten splitten, also könntest du wenn dein GPS-Tracker alle 60 Sekunden einen Punkt loggt z.B. sagen, dass er splitten soll, wenn der nächste Punkt mehr als 3600 m entfernt ist, weil die Geschwindigkeit dann über 216 km/h wäre ).
Dann müsste ich also wissen wie der GPS-Logger konfiguriert war und das ist bei verschiedenen schwierig bzw. bei manchen kann man gar nicht einstellen, wie oft geloggt werden soll und oft ist die Häufigkeit auch noch abhängig von anderen Kritieren, zB Ortsveränderung in m.
Ich könnte beim Erstellen der Cache-Datei danach filtern
Ist doch super, einfach als Option, dann kann man entscheiden, ob es Sinn macht.
Für den ersten Punkt eines Tracks gibt es generell keine Geschwindigkeitsinformationen,
Der ist in der Regel nach dem Einschalten kein Problem und kein Problem wenn er fehlt. Man schaltet nicht den Logger ein und macht in der nächsten Sekunde ein Foto und dann gibt es ja auch nocht "timedelta"
Ein weiteres Problem ist, dass man bei einem Ausreißer nicht nur den Punkt eliminiert, der unerwartet weit weg ist, sondern auch den eigentlich korrekten Punkt nach dem Zurückspringen.
Das sehe ich auch nicht als Problem. Die Situation ist doch, dass da offensichtlich was nicht passt und dann gibt es sowieso Ungenauigkeiten. Oft passiert das nachdem man in einem Gebäude oder sonst wo war, wo es keinen Empfang gibt. Abhängig vom GPS dauert es kürzer oder länger bis die Koordinaten wieder passen, die stimmen nicht von einer Sekunde auf die andere, also ist es auch nicht so tragisch da eine Koordinate mehr oder weniger zu löschen, greift ja wieder timedelta. Bei mir geht es primär um den richtige Ortsnamen und da ist oft sehr großer Spielraum. Wer die genauen Koordinaten im Foto haben will, muss sich entsprechend beim Loggen darauf einstellen.
Wenn zwei Ausreißer nahe bei einander liegen, hilft ein Geschwindigkeitsvergleich auch nicht - da ist eine Begrenzung auf einen Umkreis oder ein Polygon für den Bereich, in dem man sich aufgehalten hat, viel zuverlässiger.
Ja, aber auch dann würde es mir reichen, hohe Geschwindigkeiten einfach rauszuwerfen. Eine statistische Analyse wie bei der Höhe würde da auch helfen den Grenzwert für die Geschwindigkeit zu definieren. Egal was du da noch machen kannst, jede Verbesserung ist eine Hilfe.
wenn ich das richtig verstanden habe sowohl Fotos aus Portugal als auch aus Spanien falsch zugeordnet wurden und die Kamera dabei auf die spanische Lokalzeit eingestellt war
Ja, aber ich warte nur darauf die Fotos in Portugal auf die richtige Zeit zu stellen. Die richtige Zeit wird also mit exiftool korrigiert, das ist keine Aufgabe deines Scripts.
d.h. man muss die errechnete Lokalzeit sowieso ignorieren
Nein, weil das ja korrigiert wird und es kommt zu Chaos, wenn manche Fotos die korrekte Lokalzeit haben und andere nicht. Es ist nur im Urlaub so, dass man nicht immer daran denkt die Zeit zu ändern, daher denke ich, dass es fehlerfreier ist, wenn man einfach MEZ lässt und dann zu Hause die jeweiligen Fotos korrigiert.
Im Prinzip könnte man sich die Zeitzonen-Information von Google oder OSM holen (das müsste ich noch einbauen).
Es ist immer die Frage wieviel Google-Credits etwas kostet. Gehe davon aus, dass so ca. 200 Fotos pro Tag bei Google möglich sein sollen, wobei in Spezialfällen je Fotos auch mehr als 1x abgefragt werden kann
Alternativ könnte man auch angeben, dass man die Zeitzone bzw. den UTC-Offset kennt
Ja, das hatte ich schon mal gemeint, bin aber wahrscheinlich nicht richtig verstanden worden.
und ohne Online-Abfrage auskommen
Das verstehe ich dann nicht, ich brauche zu den Koordinaten ja dann das Land, den Ort, etc.
Da wolltest du Höhenwerte von geonames und Google Maps für gegebene Koordinaten vergleichen können.
Ach ja, das war das. Das Problem ist zurückgestellt bis das Ayamente-Problem gelöst ist. Ich habe in meinem Script jetzt eingebaut, dass es Bedingugen für timedelta und geocoder gibt.
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11180
Wohnort: München
|
glaskugel schrieb: Egal was du da noch machen kannst, jede Verbesserung ist eine Hilfe.
Ok, ich schau mal, dass ich einen Filter für die maximale Geschwindigkeit und Höhe einbaue - darf ich die Höhe filtern, bevor er sie über die Google Maps Elevation API bzw. geonames abfragen würde? Alternativ könnte man auch angeben, dass man die Zeitzone bzw. den UTC-Offset kennt
Ja, das hatte ich schon mal gemeint, bin aber wahrscheinlich nicht richtig verstanden worden.
Aber was ist dann der Sinn der Funktion, wenn du die Lokalzeit der Bilder sowieso vorab korrigierst? und ohne Online-Abfrage auskommen
Das verstehe ich dann nicht, ich brauche zu den Koordinaten ja dann das Land, den Ort, etc.
Ja, aber nur für den einen GPX-Trackpoint, der zeitlich passt - aber nicht für alle, bei denen tzwhere raten müsste. Bei Geonames hat man glaube ich 3000 Credits, bei Google Maps 2500 pro Tag. Ich habe gerade durch Probieren herausgefunden, dass das Ergebnis bei der Abfrage mit pytzwhere besser ist, wenn ich die Länge/Breite auf eine Nachkommastelle runde, als wenn er mit der vollen Präzision raten muss 🙄
$ ./geoinfo.py -s gpx/zeitzone_pt-es_ayamonte.gpx
trying to open gpx/zeitzone_pt-es_ayamonte.cache
creating cache file...
successfully created cache file gpx/zeitzone_pt-es_ayamonte.cache
2011-07-25 09:47:30: changed to timezone Europe/Lisbon at point TP4740 (37.1969016, -7.4146133)
2011-07-25 10:03:01: changed to timezone Europe/Madrid at point TP4821 (37.1983499, -7.4124866)
2011-07-25 12:40:42: changed to timezone Europe/Lisbon at point TP5629 (37.1976033, -7.4122916)
guessed 0 points
### track elevation stats ###
elevation_maximum=151
elevation_minimum=-10
elevation_mean=23
elevation_median=18
elevation_stdev=23
elevation_variance=551
processing trackpoints for tzname 'Europe/Madrid'
creating gpx/zeitzone_pt-es_ayamonte_Europe_Madrid.gpx for timezone Europe/Madrid
processing trackpoints for tzname 'Europe/Lisbon'
creating gpx/zeitzone_pt-es_ayamonte_Europe_Lisbon.gpx for timezone Europe/Lisbon
Falls du mit deinen Daten keine weiteren Problematischen Punkte findest, würde ich also erst mal darauf verzichten da extra API-Abfragen zu machen.
- geoinfo.tar.xz (6.6 KiB)
- Download geoinfo.tar.xz
|
glaskugel
(Themenstarter)
Anmeldungsdatum: 8. Juli 2010
Beiträge: 3453
|
Ok, ich schau mal, dass ich einen Filter für die maximale Geschwindigkeit und Höhe einbaue - darf ich die Höhe filtern, bevor er sie über die Google Maps Elevation API bzw. geonames abfragen würde?
Keine Ahnung über die Auswirkung, also mache was du richtig findest. Wenn, dann hat ja die gpx-Datei Fehler, also sehe ich zuerst kein Problem.
Aber was ist dann der Sinn der Funktion, wenn du die Lokalzeit der Bilder sowieso vorab korrigierst?
Wenn die Zeiterkennung aus irgendeinem Grund nicht passt,kann ich dann das erzwingen, das ich möchte. Ist das nicht bei Ayamonte so? OSM will Algier und ich möchte Madrid.
Ja, aber nur für den einen GPX-Trackpoint, der zeitlich passt - aber nicht für alle
Ok.
Bei Geonames hat man glaube ich 3000 Credits,
Bin mir auch nicht sicher, ich glaube pro Stunde. Pro Tag sind es mehr.
Ich habe gerade durch Probieren herausgefunden, dass das Ergebnis bei der Abfrage mit pytzwhere besser ist, wenn ich die Länge/Breite auf eine Nachkommastelle runde, als wenn er mit der vollen Präzision raten muss
Ich habe bei dieser Testerei auch schon viel dazu gelernt und heute, dass das Handy eigentlich sehr genau loggt, nur dort wo ich fotografiert habe, war es total daneben, keine Ahnung warum. Ich muss schauen, dass ich einen brauchbaren guten Logger finde, aber zur Zeit finde ich da nichts, irgendeine deutliches Problem haben alle. Sowas wie BT dauernd an, das ich gar nicht verwende, finde ich inakzeptabel und gpsbabel sollte man auch klar kommen. Künstliche Intelligenz beim Loggen sollte man abstellen können.
Falls du mit deinen Daten keine weiteren Problematischen Punkte findest, würde ich also erst mal darauf verzichten da extra API-Abfragen zu machen.
Du meinst Google? Ich muss das konkret probieren. Kannst du aber zurückstellen. Für den Rhodos-Flug bin ich mittlerweile auf eine brauchbare Lösung gekommen. Der Track wird auf Griechenland eingeschränkt und dort wo es keinen Fix gab, schreibe ich einfach südliche Ägäis hin und setze irgendwo im Meer einen Punkt, wonei ich dann noch immer eine Location bekomme, die einer Insel zugeordnet wird, aber irgendwann kann man nicht mehr machen.
|
glaskugel
(Themenstarter)
Anmeldungsdatum: 8. Juli 2010
Beiträge: 3453
|
Geonames ist bis dahin frei: http://www.geonames.org/export/
30'000 credits daily limit per application (identified by the parameter 'username'), the hourly limit is 2000 credits. postalCodeSearch 1 credit per request
findNearbyPostalCodes 2 credits per request, 3 credits for more than 500 records
search 1 credit per request
timezone 1 credit per request
findNearbyWikipedia 2 credits per request
wikipediaSearch 1 credit per request
findNearestAddress 1 credit per request
gtopo30 0.1 credit per request
srtm3 0.2 credit per request *
astergdem 0.3 credit per request *
findNearByWeatherJSON 2 credits per request
findNearbyPlaceName 3 credits per request
rssToGeoRSS 4 per item in feed (for geocoding)
0 if lat/lng are already included in feed
cities 4 credits per request
findNearby 4 credits per request
extendedFindNearby 4 credits per request
geonamesData.js 0.2 credit per request
|
glaskugel
(Themenstarter)
Anmeldungsdatum: 8. Juli 2010
Beiträge: 3453
|
Kann das sein? elevation_source=google maps elevation api
licence=Data © OpenStreetMap contributors, ODbL 1.0. http://www.openstreetmap.org/copyright Der API-Key von Google ist angegeben, aber mit "-g osm".
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11180
Wohnort: München
|
glaskugel schrieb: Kann das sein?
elevation_source=google maps elevation api
licence=Data © OpenStreetMap contributors, ODbL 1.0. http://www.openstreetmap.org/copyright
Der API-Key von Google ist angegeben, aber mit "-g osm".
So wie es aktuell gelöst ist ja, aber vielleicht sollte ich noch extra Schalter dafür einbauen, wenn man die Höheninformation über Google Maps bzw. Geonames abfragen möchte.
|