Ja das wäre gut, und die Höhe sollte üer default von Geonames abgefragt werden.
Kommandozeilen-Tool um Koordinaten + Geoinfo aus gpx-File zuzuordnen
(Themenstarter)
Anmeldungsdatum: Beiträge: 3453 |
|
Anmeldungsdatum: Beiträge: 11179 Wohnort: München |
Ok, ich habe den Code mal aufgeräumt (ich hoffe, dass ich dadurch nichts kaputt gemacht habe), es gibt Filter für die Höhe (z.B. -E 2000 um alle Punkte über 2000 m auszuschließen) und die Geschwindigkeit (z.B. -S 100, um Punkte mit mehr als 100 m/s auszuschließen). Wenn Filter für diese Eigenschaften gesetzt sind, wird die Cache-Datei automatisch neu aufgebaut. Eine fehlende Höhen-Angabe wird jetzt bevorzugt über Geonames berechnet, falls das nichts liefert, gibt es einen Fallback auf GoogleMaps (wenn der API-Key gesetzt ist). Beim Zeitzonen-Split legt er zusätzlich eine <gpx-dateiname>_tz_changes.txt Datei mit den Zeitzonenwechseln an. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 3453 |
Vieldn Dank. Kann ich vermutlich heute nicht mehr viel ausprobieren und morgen bin ich unterwegs, also vermutlich Feedback erst am Mittwoch oder morgen spät am Abend. Ich rätsle gerade an was anderem. Ich habe mich mit den Ayamonte-Fotos gespielt und es gab keinen Fehler, nicht mal auf der Rückfahrt nach Portugal, dh Zeitüberlappung. Vielleicht gibt es da ein paar Zufälle, die ich noch nicht erkannt habe. Wie früher gepostet, die Zeit der Fotos wurde von mir falsch interpretiert. Da hat 1h CD suchen bei FNAC in Sevilla etwas zur Verwirrung beigetragen. 😉 Dh 1h Unterchied bringt noch immer ca. FNAC mit dem eindeutig erkennbaren Gebäude. DIe portugiesischen Fotos sind also Lokalzeit und die spanischen Fotos wurden auf Lokalzeit geändert. Die paar Fotos auf der Rückfahrt von Ayamonte, Spanien nach Vila Real de Santo Antonio, Portugal wurden auf spanischer(!) Zeit belassen, da es mir eigentlich egal ist, ob die Fotos am Fluss nun Spanien oder Portugal zugeordnet sind. Nun ist folgendes passiert, ab ca. der Mitte des Flusses wurde Vila Real de Santo Antonio in Portugal angegeben. Das ist perfekt. Nur ist mir nicht klar, ob das Zufall ist. Wenn da schon Portugal erkannt wurde, dann müsste ja auch die Lokalzeit berücksichtigt werden, aber mit der span. Lokalzeit kommen die richtigen Ergebnisse. Es hat mir also nirgends die Algier-Zeit hineingepfuscht. Könnte es sein, dass die Algier-Problematik nur beim Split entsteht?
Hast du eine Statistik eingebaut. Ich kann die neue Version zur Zeit nicht installieren, läuft gerade ein längerer Test. Ansonsten hört sich das alles sehr gut an! Nochmals danke! Ich hoffe, damit ist nun das wichtigste geschafft. |
Anmeldungsdatum: Beiträge: 11179 Wohnort: München |
Ja, aktuell zeigt er es beim tzsplit und beim Matchen von Bildern: $ ./geoinfo.py -s gpx/zeitzone_pt-es_ayamonte.gpx trying to open gpx/zeitzone_pt-es_ayamonte.cache... sucessfully loaded cache file 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 ### end track elevation stats ### 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 $ ./geoinfo.py test.gpx 20081017-0002.jpg trying to open test.cache... sucessfully loaded cache file ### track elevation stats ### elevation_maximum=305 elevation_minimum=227 elevation_mean=277 elevation_median=274 elevation_stdev=11 elevation_variance=141 ### end track elevation stats ### image timestamp=2008-10-17 19:04:00 gps timestamp=2008-10-17 19:17:49 minimum timedelta=0:13:49 coordinates=49.6098249, 6.1327266 ### POINT START ### name=TP3176 latitude=49.6098249 longitude=6.1327266 elevation=304 elevation_source=gpx data time=2008-10-17 19:17:49 timezone_name=Europe/Luxembourg licence=Data © OpenStreetMap contributors, ODbL 1.0. http://www.openstreetmap.org/copyright location=Galerie Clairefontaine, Tunnel René Konen, Ville-Haute, Luxembourg, Canton Luxembourg, 1728, Lëtzebuerg country_code=lu country_code3=LUX country=Lëtzebuerg state= state_district= county=Canton Luxembourg postcode=1728 city=Luxembourg town= postal_town= village= suburb=Ville-Haute city_district= neighbourhood= road=Tunnel René Konen route= pedestrian= address29=Galerie Clairefontaine path= house_number= townhall= ruins= attraction= place_of_worship= hotel= bus_stop= country_part=Canton Luxembourg loc_name=Luxembourg street_name=Tunnel René Konen ### POINT END ### unused attributes: Ich habe gerade noch einen Fehler entdeckt, wenn man keine Geonames/GoogleMaps Anmeldedaten für ein Koordinatenset übergeben hat - eine Version mit Fix ist im Anhang. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 3453 |
Danke, bin schon echt neugierig! Hast du eine Erklärung für die Rückfahrt von Ayamonte? [EXIF] 0x9003 Date/Time Original : 2011:07:25 13:35:42 TP5569, 0:00:00 adj [XMP] - City : Ayamonte [Composite] - GPS Position : 37.2075883 -7.41227659992222 LOL, das ist schon ein paar Meter über die Flussmitte in Portugal 😉 [EXIF] 0x9003 Date/Time Original : 2011:07:25 13:38:30 TP5603, 0:00:02 adj. [XMP] - City : Vila Real de Santo António [Composite] - GPS Position : 37.2018965999897 -7.41246659999444 Ich glaube zwar nicht, dass es was mit der aktuell verwendeten gpx-Datei zu tun hat, aber ich hänge sie vorsichtshalber an. |
Anmeldungsdatum: Beiträge: 11179 Wohnort: München |
Die Polygone der Shape-Dateien, die als Grundlage für die Berechnungen von tzwhere dienen, haben eine gewisse Ungenauigkeit (ich hatte den Bugreport schon mal verlinkt: https://github.com/mattbornski/tzwhere/issues/8) - kann gut sein, dass er da auf dem Fluss daneben liegt, wenn das nur ein paar Meter von der Grenzlinie entfernt ist ("37.2075883, -7.41227659992222" sind so ca. 6 m auf portugiesischer Seite, beim richtig zugeorneten Punkte für "37.2018965999897 -7.41246659999444" gut 115 m auf portugiesischer Seite, wenn man Google Earth glauben darf. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 3453 |
Das letzte Foto war bei "37.1977433000778 -7.412295". Kann schon sein, dass das mit diesem Bug zusammenhängt. Ist sowieso ein Speziellfall und es ist Zufall, dass ich so ein Beispiel fand. Ich denke in Europa gibt es nicht oft solche Fälle. Serbien / Rumänien düfte so ein Fall sein, also keine Kreuzfahrt auf der Donau machen 😉 Wegen ein paar Fotos wie hier trennen ist natürlich blöd, aber ist wohl die einzige Lösung, wenn man auf der sicheren Seite sein will. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 3453 |
Unexpected error while loading gpx data (<class 'IsADirectoryError'>, IsADirectoryError(21, 'Is a directory'), <traceback object at 0x7f9fee50c588>) Kleiner Bug, wenn man nur ein Verzeichnis und kein Directory angibt. --help zeigt, dass du viel mehr gemacht als hier zur neuen Version erwähnt hast, super! Testen dauert etwas, bin gleich weig. |
Anmeldungsdatum: Beiträge: 11179 Wohnort: München |
Unexpected error while loading gpx data (<class 'IsADirectoryError'>, IsADirectoryError(21, 'Is a directory'), <traceback object at 0x7f9fee50c588>) Kannst du mal den Aufruf zeigen? mir ist gerade nicht ganz klar, was du mit "nur ein Verzeichnis und kein Directory" meinst. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 3453 |
Der Fehler ist eingentlich saudumm, aber ist mir eben passiert. Ich habe mit dem Tab die Verzeichnisse automatisch ergänzt und die gpx-Datei wurde nicht erweitert (bash completion), keine Ahnung warum, da nur 1 Datei im Verzeichnis war. Ich meine also sowas:
Also keine gpx-Datei angegeben, aber einen Pfad. Was hast du denn bei zeitzone_pt-es_ayamonte.gpx für Optionen verwendet, damit Algiers nicht verwendet wurde? Ich bin gerade dabei mir problematische gpx-Dateien zum Testen zu suchen. Edit: Alternativ kannst du statt keinem gpx-File auch einen ungültigen Dateinamen angeben. Das mache ich natürlich nicht absichtlich, aber irgendwas passt bei mit der bash-completion gerade nicht. Wo bekomme ich bitte eine Statistik zur Geschwindigkeit? |
(Themenstarter)
Anmeldungsdatum: Beiträge: 3453 |
Zuerst, die vorige Antwort wurde ergänzt. BTW km/h statt m/s wären leichter anzugeben, man kann sich vorstellen wie schnell man mit dem Auto unterwegs war. Bei m/s muss zumindest ich erst zu rechnen beginnen. Das ist jetzt mehr eine Info, als das es wichtig ist. Sowohl in Griechenland als auch Albanien gibt es jetzt andere Ortsnamen. In Albanien sind lauter neue Orte und in Griechenland teilweise. In Albanien kenne ich mich kaum aus, also keine Ahnung ob jetzt besser oder schlechter. In Griechenland scheint ein Eintrag jetzt besser zu sein. Kann dies etwas mit der geänderter Cache-Erstellung zu tun haben? Ansonsten dort wo es mir sofort auffallen würde, habe ich noch nichts falsches entdeckt. Ich habe auch noch ein Verständnisproblem, aber diese Problemfälle werden (mir) schon langsam lästig. Wenn bei Zeitzonenüberschreitung die Zeit später wird (und nur später), dann sollte es doch zu keinen Problemen kommen, die Probleme entstehen ja erst in der Gegenrichtung, wenn die Zeit wieder zurückgestellt wird. Wenn ich nun "--timedelta 300" angebe, dann sollte das bedeuten, dass bei einer größeren Abweichung als 5 Minuten nichts gefunden wird und ich bekam in der Südägäis einen Eintrag von Serbien. Könntest du kurz auf den Code schauen, ob mit timedelta alles passt? Ich hatte die Originale-Gesamt-GPX-Datei wieder verwendet, da ich dachte, dass das passen müsste. Jetzt ist einfach nach Griechenland in der gpx-Datei alles rausgeflogen und es passt wieder. Ich wollte das nur erwähnen, da du ja geschrieben hast, dass du den Code neu strukturiert hast. Edit: Habe zu den geänderten Ortsnamen gerade was entdeckt:
Kukës hatte ich vorher als Ort. Kann das vielleicht mit OSM und Google zusammenhängen, dh es wurde ein anderer Server abgefragt? Ich hatte nach den googlemaps-Tests aber nie mehr googlemaps beim Testen angegeben. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 3453 |
gelöscht, da ich mittlerweile denke, dass das ein externes Problem ist. |
Anmeldungsdatum: Beiträge: 11179 Wohnort: München |
Das hatte ich in 8522488 geschrieben:
Der Ansatz ist der: wenn er mit der vollen Präzision keinen Treffer findet, versucht er es mit auf eine Nachkommastelle gerundeten Koordinaten. Wenn das auch nichts liefert, fragt er die Google-Maps API (falls der API-Key übergeben wurde) und ansonsten lässt er tzwhere raten. glaskugel schrieb:
Was soll das Programm sonst machen, wenn man es mit Schrott füttert als mit einem Fehler auszusteigen? Im besten Fall kann man da noch eine sprechendere Fehlermeldung liefern: $ ./geoinfo.py -s foo.gpx failed to open file foo.gpx for calculating md5sum could not access gpx file foo.gpx: [Errno 2] No such file or directory: 'foo.gpx' $ ./geoinfo.py -s folder failed to open file gpx for calculating md5sum could not access gpx file folder: [Errno 21] Is a directory: 'folder'
Wenn die Maximalgeschwindigkeit genügt, könnte man z.B. gpxinfo (wird mit dem gpxpy Modul mitinstalliert) nehmen - das kann das auch für jeden einzelnen Track aufschlüsseln: $ gpxinfo gpx/zeitzonenwechsel43-4x.gpx File: gpx/zeitzonenwechsel43-4x.gpx Length 2D: 305.266km Length 3D: 305.658km Moving time: 07:23:59 Stopped time: 30:14:41 Max speed: 28.12m/s = 101.22km/h Total uphill: 2892.10m Total downhill: 2856.10m Started: 2011-07-25 09:47:30 Ended: 2011-07-28 19:20:54 Points: 5592 Avg distance between points: 57.35m Track #0, Segment #0 Length 2D: 2.473km Length 3D: 2.482km Moving time: 00:18:59 Stopped time: 00:12:28 Max speed: 3.58m/s = 12.89km/h Total uphill: 36.50m Total downhill: 43.50m Started: 2011-07-25 09:47:30 Ended: 2011-07-25 10:18:57 Points: 247 Avg distance between points: 10.01m Track #1, Segment #0 Length 2D: 1.773km Length 3D: 1.793km Moving time: 00:30:24 Stopped time: 00:31:45 Max speed: 1.42m/s = 5.11km/h Total uphill: 47.20m Total downhill: 27.20m Started: 2011-07-25 10:38:29 Ended: 2011-07-25 11:40:38 Points: 466 Avg distance between points: 3.81m Track #2, Segment #0 Length 2D: 7.024km Length 3D: 7.041km Moving time: 00:24:31 Stopped time: 00:04:54 Max speed: 11.19m/s = 40.30km/h Total uphill: 106.20m Total downhill: 114.20m Started: 2011-07-25 12:22:53 Ended: 2011-07-25 12:52:18 Points: 301 Avg distance between points: 23.34m Track #3, Segment #0 Length 2D: 0.387km Length 3D: 0.387km Moving time: 00:03:32 Stopped time: 00:00:13 Max speed: 2.96m/s = 10.66km/h Total uphill: 0.00m Total downhill: 0.00m Started: 2011-07-25 18:47:40 Ended: 2011-07-25 18:51:25 Points: 46 Avg distance between points: 8.41m Track #4, Segment #0 Length 2D: 5.152km Length 3D: 5.223km Moving time: 00:31:58 Stopped time: 00:16:25 Max speed: 4.83m/s = 17.39km/h Total uphill: 175.90m Total downhill: 140.90m Started: 2011-07-25 18:54:17 Ended: 2011-07-25 19:42:40 Points: 273 Avg distance between points: 18.87m Track #5, Segment #0 Length 2D: 141.102km Length 3D: 141.302km Moving time: 03:45:13 Stopped time: 02:10:04 Max speed: 27.74m/s = 99.86km/h Total uphill: 1149.80m Total downhill: 1180.80m Started: 2011-07-27 07:57:10 Ended: 2011-07-27 13:52:27 Points: 2898 Avg distance between points: 48.69m Track #6, Segment #0 Length 2D: 147.355km Length 3D: 147.429km Moving time: 01:49:22 Stopped time: 26:58:52 Max speed: 28.12m/s = 101.22km/h Total uphill: 1376.50m Total downhill: 1349.50m Started: 2011-07-27 14:32:40 Ended: 2011-07-28 19:20:54 Points: 1361 Avg distance between points: 108.27m Für eine Auswertung aller Geschwindigkeiten im Skript müsste ich die Datenstruktur der Cache-Dateien umbauen, das wäre eine größere Aktion (hatte ich schon erwähnt, dass möglichst vollständige Spezifikationen vorab extrem hilfreich sind?).
Ok, dann halt noch ein zusätzliches Argument -K, das Geschwindigkeiten in km/h akzeptiert und ausfiltert...
Vielleicht hat sich auf OSM-Seite etwas geändert, die Abfrage über die Geocoder ist eigentlich gleich geblieben.
Wenn du Griechenland nach Serbien wechselst, wird es eine Stunde früher. Da müsste ich die gpx-Datei und den Timestamp des genutzten Bildes und die Bewegungsrichtung Griechenland → Serbien bzw. umgekehrt kennen.
Ich würde da eher vermuten, dass jemand die Datenbanken aktualisiert hat. Kukës wäre ja nur die Gemeinde gewesen |
(Themenstarter)
Anmeldungsdatum: Beiträge: 3453 |
Ok, das hatte ich probiert, aber mit einem etwas anderen gpx-File aus dieser Gegend und da kam auch Algier. Ich dachte damals, dass du eine spezielle Option verwendet hast. Jetzt muss ich mir das noch näher anschauen. Mir fiel jedenfalls auf, dass gpsbabel nach Zeit manchmal nicht korrekt trennt. Da kann ein kleiner Bereich außerhalb der gefilterten Zeit im Ergebnis sein, das ich aber noch nie als Problem sah. Mit der Datei aus dem Upload ins Forum kommt das, also wie bei dir: $ python3 /usr/local/bin/geoinfo.py -s zeitzone_pt-es_ayamonte.gpx trying to open zeitzone_pt-es_ayamonte.cache... initializing tzwhere... created tzwhere object creating cache file... successfully created cache file zeitzone_pt-es_ayamonte.cache 2011-07-25 09:47:41: changed to timezone Europe/Lisbon at point TP4741 (37.1968999, -7.4145866) 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=553 ### end track elevation stats ### processing trackpoints for tzname 'Europe/Lisbon' creating zeitzone_pt-es_ayamonte_Europe_Lisbon.gpx for timezone Europe/Lisbon processing trackpoints for tzname 'Europe/Madrid' creating zeitzone_pt-es_ayamonte_Europe_Madrid.gpx for timezone Europe/Madrid
Genau das meinte ich, falls das wer verwendet, der mit PCs nicht so klarkommt.
Ok, so was entwickelt sich leider erst oft mit der Nutzung. Überlegen wir mal, wie das vielleicht einfach umzusetzen ist. Ich denke da zB an eine Autofahrt und weiß, dass da zB nie schneller als 150 gefahren wurde, daher könnte man Geschwindigkeiten über 200 rauswerfen. Wenn ich das nun nicht weiß, dann hilft die Statistik.
Das wäre schon sehr wertvoll und am wichtigsten, denn dann kann man erkennen, wenn da was total daneben liegt oder nicht, also ob man sich den Geschwindigkeitsfilter sparen kann. Ich hänge da ein Beispiel an, wo ich glaube, dass man die Ausreißer nicht in den Griff bekommt. Es ist mir auch klar, dass man irgendwann falsche GPS-Daten nicht mehr logisch korrigieren kann. Wenn diese Tunnel-Geschichte, dh Ausreißer ab dem Tunneleintritt und Zeit bis wieder die Koordinaten stimmen nicht gelöst werden kann, auch kein Problem, aber vielleicht siehst du ja eine Lösung. Zur Klarstellung, das ist eine reine Autobahnfahrt und so was ist in der Praxis nur relevant, wenn aus dem fahrenden Auto fotografiert wurde. Ich glaube, dass die Höchstgeschwindigkeit schon reichen wird.
Daran habe ich auch schon gedacht und ansonsten habe ich mich auch schon selber mit Trugschlüssen reingelegt, wenn der Anfang stimmt und das Ende stimmt, dann muss es in der Mitte nicht zwingend stimmen. Aber ok, da warte ich auf andere Problemfälle, sind mir aber noch keine untergekommen.
Auf deiner Seite kannst du die Sache abhaken. Mein Irrtum war zB, dass man von Rhodos nach Serbien länger als 1h fliegt, das ist aber falsch, dh auch in Rhodos geht sich wegen der Zeitverschiebung theoretisch schon eine Koordinate in Serbien aus und wenn die Tests, dann tw. richtige Ergebnisse bringen und dann wieder falsche, beginnt man zu zweifeln. Man muss in diesem Fall wirklich die Koordinaten in Serbien rauswerfen und es passt.
Ich habe es nur erwähnt, da du ja geschrieben hast, dass beim Umbau irgendwelche Unstimmigkeiten passiert hätten können und ich dachte an Google-Abfragen, die ja was anderes liefern können als OSM. |
Anmeldungsdatum: Beiträge: 11179 Wohnort: München |
Die Höchstgeschwindigkeit war ja nur so um die 130 km/h und wie es aussieht, hat der GPS-Empfänger nach dem ersten Vortunnel das Signal verloren - ich fürchte ohne Kombination mit einem Trägheitsnavigationssystem hat man in Tunneln, Gebäuden und anderen Umgebungen ohne Kontakt zu den Satelliten wenig Chancen den Routenverlauf automatisiert zu ermitteln. Wenn man aber von einer halbwegs gleichmäßigen Geschwindigkeit zwischen den Punkten außerhalb des Tunnels ausgehen kann und den Tunnelverlauf kennt, sollte man die fehlenden Punkte mit recht brauchbarer Genauigkeit ergänzen können. |