ubuntuusers.de

Sicher, dass du die letzte Version nutzt? Da wird dieser Fehler eigentlich abgefangen...

Danke für den Hinweis, ich verstehe es nicht, wo die alte Version herkommt, denn

Vielen Dank, super! Ich habe die ursprüngliche Datei ohne Fix auch noch getestet.

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

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.

glaskugel schrieb:

Der Schlüssel ist kaum verwendet und nicht meiner

Woher weißt du dann, dass er noch gültig ist?

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?

glaskugel schrieb:

Kann ich irgendwie prüfen, ob der Key noch aktiv ist?

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.

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.

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?

Ich verstehe nicht warum die Timezone-Anfragen alle fehlerhaft sind. Siehe Anhang. Da sieht man auch alle aktiven APIs.

Aber kurz danach wurde mir beim Rumsurfen auf einer Seite wieder mit "Geocoding API" eine Aktivierung angeboten, das habe ich gemacht

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.

Ich versuche das mal bei Gelegenheit nachzuvollziehen.

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.

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?

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.

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.