Sicher, dass du die letzte Version nutzt? Da wird dieser Fehler eigentlich abgefangen...
Kommandozeilen-Tool um Koordinaten + Geoinfo aus gpx-File zuzuordnen
Anmeldungsdatum: Beiträge: 11107 Wohnort: München |
|
(Themenstarter)
Anmeldungsdatum: Beiträge: 3404 |
Danke für den Hinweis, ich verstehe es nicht, wo die alte Version herkommt, denn
aber offensichtlich hatte meine Version eine andere md5sum. Ich entschuldige mich und rätsle wie das passiert ist. Bali-Test: sucessfully loaded cache file ### track elevation stats ### elevation_maximum=228 elevation_minimum=-10 elevation_mean=70 elevation_median=22 elevation_stdev=73 elevation_variance=5362 ### end track elevation stats ### image timestamp=2019-08-21 13:04:00 gps timestamp=2019-08-21 13:04:03 minimum timedelta=0:00:03 coordinates=-8.534131088, 115.509791715 no alpha2 country code ### POINT START ### name=TP19944 latitude=-8.534131088 longitude=115.509791715 elevation=-2 elevation_source=gpx data time=2019-08-21 13:04:03 timezone_name=Asia/Makassar licence=Data © OpenStreetMap contributors, ODbL 1.0. https://osm.org/copyright location=Ferry to Nusa Penida, to Nusa Penida, Padangbai, Bali, Indonesien country_code=id country_code3= country=Indonesien state=Bali state_district= county= postcode= city= town=Padangbai postal_town= village= suburb= city_district= neighbourhood= road=to Nusa Penida route= pedestrian= address29= path= house_number= townhall= ruins= attraction= place_of_worship= hotel= bus_stop= country_part=Bali loc_name=Padangbai street_name=to Nusa Penida ### POINT END ### unused attributes: ferry_terminal ferry_terminal=Ferry to Nusa Penida Singapur-Test: sucessfully loaded cache file ### track elevation stats ### elevation_maximum=7540 elevation_minimum=-14 elevation_mean=856 elevation_median=23 elevation_stdev=1595 elevation_variance=2542439 ### end track elevation stats ### image timestamp=2019-09-02 16:39:17 gps timestamp=2019-09-02 16:43:35 minimum timedelta=0:04:18 coordinates=1.288688007, 103.856075419 no alpha2 country code ### POINT START ### name=TP47601 latitude=1.288688007 longitude=103.856075419 elevation=1 elevation_source=gpx data time=2019-09-02 16:43:35 timezone_name=Asia/Singapore licence=Data © OpenStreetMap contributors, ODbL 1.0. https://osm.org/copyright location=Outdoor Theatre, The Esplanade, Clarke Quay, City Hall, Singapur, Central, 39802, Singapur country_code=sg country_code3= country=Singapur state= state_district= county=Central postcode=39802 city=Singapur town= postal_town= village= suburb=City Hall city_district= neighbourhood=Clarke Quay road= route= pedestrian=The Esplanade address29= path= house_number= townhall= ruins= attraction= place_of_worship= hotel= bus_stop= country_part=Central loc_name=Singapur street_name=The Esplanade ### POINT END ### unused attributes: theatre theatre=Outdoor Theatre |
(Themenstarter)
Anmeldungsdatum: Beiträge: 3404 |
Bevor sich da nochmals eine falsche Version eingeschlichen hat. md5sum /usr/local/bin/geoinfo.py 9a2c0493441a5b0918ab2b1de463b107 /usr/local/bin/geoinfo.py Hat es bei der Google API irgendwelche Änderungen gegeben? Der Schlüssel ist kaum verwendet und nicht meiner, die letzten Tage wurde er sicher nicht verwendet, vielleicht Monate lang nicht. Allerdings verwendete ich meinen Schlüssel zum Testen dieser Datei mit meiner IP-Adresse, dh 2 User, gleiche IP, unterschiedliche Schlüssel. could not calculate timezone id for TP0475 at 55.02497846, 18.13817729 asking geonames timezone api geonames tz api: Europe/Warsaw could not calculate timezone id for TP0476 at 55.044271526, 18.163609645 asking geonames timezone api geonames tz api: None asking google maps timezone api REQUEST_DENIED (<class 'googlemaps.exceptions.ApiError'>, ApiError('REQUEST_DENIED', None), <traceback object at 0x7f1e570aec30>) creating cache file... successfully created cache file /fotos/original_digitalfotos/ec/2019-08_singapur_digicam/2019-08_singapur.cache no elevation data Wenn da nichts komisches passiert ist, denn früher lief die gpx-Datei schon durch, habe allerdings die cache-Datei nicht mehr. Irgendwelche Ideen? Habe jetzt einen Tag von dieser gpx-Datei extrahiert. Es kommt sofort (keine Sekunde) "successfully created cache file". Dateigröße 148kB. So schnell habe ich das nie erlebt. Kann ich überprüfen, ob was sinnvolles in der Cache-Datei steht? initializing tzwhere... created tzwhere object creating cache file... successfully created cache file Hmmh, sieht eher danach aus, dass die "kleine" Datei, dessen cache sofort erstellt war, die Koordinaten richtig abgeglichen hat. Ich habe da gewöhnt viele Zeilen mit "TP" zu sehn, das war nicht der Fall. Bei Google denke ich mir, vielleicht funktioniert gerade der Server nicht richtig. Werde morgen wieder testen. |
Anmeldungsdatum: Beiträge: 11107 Wohnort: München |
|
(Themenstarter)
Anmeldungsdatum: Beiträge: 3404 |
Gute Frage. Beide Schlüssel wurden etwa zur gleichen Zeit angelegt, der 2. gehört zur Familie und wird nicht so oft verwendet, meistens nach einer Reise oder wenn Fotos neu gerechnet werden. Ich bin jetzt vorsichtig, da für eine riesige Datei ein cache berechnet werden soll. Ich werde das morgen, also nach über 24h Nichtnutzung von Abfragenm mit meinem Key probieren und schauen was passiert. Der 2. Key wurde auf jeden Fall vor mindestns 2 Jahren verwendet, da sehe ich die letzten bearbeiteten Fotos, vermutlich gab es aber danach auch noch eine geringe Verwendung. Mit einem lahmen PC (alter Dual-Core) macht Fotobearbeitung wenig Spaß, aber jetzt haben wir 2 schnelle Ryzen 3700 mit GTX 1660. Kann ich irgendwie prüfen, ob der Key noch aktiv ist? |
Anmeldungsdatum: Beiträge: 11107 Wohnort: München |
Schau dir an, was in der Google API Console dazu steht, wenn du dich mit dem Account angemeldet hast, für den der Key erstellt wurde. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 3404 |
Ich habe jetzt mit meinem Key getestet und es lief alles durch. grep "<name>TP" test.gpx | wc -l 49086 Die Ausgabe in die Konsole enthielt grep -i google reiselog.txt | wc -l 2844 grep -i geonames reiselog.txt | wc -l 7306 Somit dürften die Credits bei 24h reichen, wenn ich da nichts falsch interpretiere. Die Cache-Datei hat ca. 3.4MB. Die Dauer der Erstellung war ca. 15-20 Minuten, habe nicht darauf geachtet. Die Ausgabe in die Konsole sieht so aus: asking geonames timezone api geonames tz api: None asking google maps timezone api could not calculate timezone id for TP0480 at 55.121845601, 18.265419075 asking geonames timezone api geonames tz api: None asking google maps timezone api could not calculate timezone id for TP0481 at 55.14129096, 18.290963824 asking geonames timezone api geonames tz api: None Ich frage mich nun wie zwar eine deutlich kleinere Datei ohne jegliche Ausgabe unter 1 Sekunde erstellt werden kann und dann funktioniert. Könnte es sein, dass durch frühere Tests, alles im RAM des PC war? Morgen werde ich mir den 2. Key mit "Google API Console" ansehen, traue mich nicht mit einem anderen Key zu testen. Sind sowieso schon so viele Merkwürdigkeiten bei der Umstellung auf Eoan und will nicht auf die falsche Fährte gelockt werden. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 3404 |
Habe mir mal https://console.cloud.google.com/ angesehen, ziemlich unübersichtlich, aber ich habe folgendes gefunden: Geocoding API API aktiviert Aber kurz danach wurde mir beim Rumsurfen auf einer Seite wieder mit "Geocoding API" eine Aktivierung angeboten, das habe ich gemacht Den 2. Key habe ich auch auf der Googleseite gefunen, aber noch immer: geonames tz api: None asking google maps timezone api REQUEST_DENIED (<class 'googlemaps.exceptions.ApiError'>, ApiError('REQUEST_DENIED', None), <traceback object at 0x7fd959914b40>) Kannst du mir bitte genau sagen, wo ich was kontrollieren soll? |
(Themenstarter)
Anmeldungsdatum: Beiträge: 3404 |
Ich verstehe nicht warum die Timezone-Anfragen alle fehlerhaft sind. Siehe Anhang. Da sieht man auch alle aktiven APIs. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 3404 |
Könnte sein, dass ich das mit Geolocation API verwechselt habe, denn wenn ich bei mir schaue, dann habe ich nur 3 APIs aktiviert. Siehe api_alle.png. Interessant sind auch die Requests bei mir. |
Anmeldungsdatum: Beiträge: 11107 Wohnort: München |
Ich versuche das mal bei Gelegenheit nachzuvollziehen. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 3404 |
Danke dir, bin da auch am Recherchieren, habe aber schon Probleme eine bestimmte Seite wieder zu finden. Mein Gefühl geht in Richtung "freie Abfragen". Schau dir mal den Screenshot von meinem Key an. Da steht 50000 pro 100 Sek., sonst unbegrenzt. Ich muss mal versuchen diese Seite beim 2. Key zu finden. |
Anmeldungsdatum: Beiträge: 11107 Wohnort: München |
Mit welchen Argumenten rufst du das geoinfo.py Skript genau auf? Kannst mir eine betroffene GPX-Datei und ein dazu gehöriges Bild zukommen lassen? |
(Themenstarter)
Anmeldungsdatum: Beiträge: 3404 |
Habe mir manuell für die Konsole was zusammengebastelt. Mein Script ruft aber ein jpg-File auf, das aus arw erstellt wurde, sollte IMHO egal sein. Eben konnte ich beim Suchen nach einem Beispiel feststellen, dass es durchlief. Vielleicht hängt es damit zusammen, wenn OSM alles beantworten kann. $ time /usr/local/bin/geoinfo.py -a KEY -u USER --timedelta 216000 -lde test.gpx test.arw Cache-Datei wurde vorher gelöscht. Ich sah alleredings, wenn ich die Cache-Datei nicht lösche, dass trotzdem versucht wird die Cache-Datei neu anzulegen. $ time /usr/local/bin/geoinfo.py -a KEY -u USER --timedelta 216000 -lde test.gpx test.arw trying to open test.cache... initializing tzwhere... created tzwhere object could not calculate timezone id for TP0466 at 54.851488233, 17.911233439 asking geonames timezone api geonames tz api: Europe/Warsaw could not calculate timezone id for TP0467 at 54.870769103, 17.936385257 asking geonames timezone api geonames tz api: Europe/Warsaw could not calculate timezone id for TP0468 at 54.890042253, 17.961526706 asking geonames timezone api geonames tz api: Europe/Warsaw could not calculate timezone id for TP0469 at 54.909328, 17.986642569 asking geonames timezone api geonames tz api: Europe/Warsaw could not calculate timezone id for TP0470 at 54.928629265, 18.011747669 asking geonames timezone api geonames tz api: Europe/Warsaw could not calculate timezone id for TP0471 at 54.947922133, 18.036930919 asking geonames timezone api geonames tz api: Europe/Warsaw could not calculate timezone id for TP0472 at 54.967188504, 18.06219276 asking geonames timezone api geonames tz api: Europe/Warsaw could not calculate timezone id for TP0473 at 54.986442589, 18.087473961 asking geonames timezone api geonames tz api: Europe/Warsaw could not calculate timezone id for TP0474 at 55.005708995, 18.112798769 asking geonames timezone api geonames tz api: Europe/Warsaw could not calculate timezone id for TP0475 at 55.02497846, 18.13817729 asking geonames timezone api geonames tz api: Europe/Warsaw could not calculate timezone id for TP0476 at 55.044271526, 18.163609645 asking geonames timezone api geonames tz api: None asking google maps timezone api REQUEST_DENIED (<class 'googlemaps.exceptions.ApiError'>, ApiError('REQUEST_DENIED', None), <traceback object at 0x7fdf18c1cc30>) creating cache file... successfully created cache file test.cache ### track elevation stats ### no elevation data Traceback (most recent call last): File "/usr/local/bin/geoinfo.py", line 939, in <module> main() File "/usr/local/bin/geoinfo.py", line 935, in main args.imagefiles) File "/usr/local/bin/geoinfo.py", line 243, in compare_gpx_with_images mtd = min(timedeltas) ValueError: min() arg is an empty sequence real 0m7,433s user 0m3,026s sys 0m0,138s Diese GPX-Datei enthält nur 1 Tag von einer größeren gpx-Datei. Die gesamte Datei lief mit meinem Key durch, wie bereits davor erwähnt. Exif-Abfrage: [MakerNotes] 0x0006 Sony Date Time : 2019:08:13 23:08:29 (sollte UTC +2 sein, mitterleurop. Sommerzeit) [EXIF] 0x9004 Create Date : 2019:08:14 00:08:29 (sollte Helsinki-Zeit sein, also UTC +3) UTZ-Zeit daher 2019:08:13 21:08:29 Somit sollte IMO mit TP1111 abgeglichen werden <trkpt lat="60.312147337" lon="24.954159753"> <ele>50.714849</ele> <time>2019-08-13T21:08:28Z</time> <speed>3.888889</speed> <name>TP1111</name> </trkpt> Die Koordinaten entsprechen dem Flughafen Helsinki Vantaan und das Foto passt dazu. Sorry gibt kein besseres Foto, das ich auf die Schnelle fand und wo die Fehlermeldung auftrat. Foto-Download: https://drive.google.com/file/d/1M_gsTOM7Evp_3D1tDorVVYLmX8N7vnOF/view?usp=sharing Die gpx-Datei hänge ich auch hier an. |
Anmeldungsdatum: Beiträge: 11107 Wohnort: München |
Wie es aussieht, kann man die Timezone-API mittlerweile nur noch nutzen, wenn man Zahlungsinformationen hinterlegt und die Abrechnung für die API aktiviert: https://developers.google.com/maps/documentation/timezone/usage-and-billing Dass er überhaupt auf die Google Timezone API zurückfällt liegt vermutlich daran, dass da viele Wegpunkte aus der .gpx-Datei in der Ostsee liegen. In der angehängten Version fange ich den Fehler ab, wenn man eine Google-ID angibt, aber die Abfrage nicht klappt und nutze die API dann nicht mehr für weiter Abfragen, nachdem es den ersten Fehler gab. |