ubuntuusers.de

Kannst du bitte mal zeigen, mit welchen Argumenten du das Skript aufgerufen hast?

Danke, dass du dich gleich meldest!

Aus meinem Script zum Testen:

MYGEOINFO="/usr/local/bin/geoinfo.py"
FIRST_MINIMUM_TIMEDELTA_SEC=216000
GPSINFO_DE=`$MYGEOINFO -a "$GOOGLEAPI" -u "$GEONAMESUSER" --timedelta "$FIRST_MINIMUM_TIMEDELTA_SEC" -lde "$GPXFILE" "$FIRSTFILE"`

Ich würde aber mittlerweile nicht ausschliessen, dass es ein zusätzliches Rechte-Problem bei mir gibt. Ich muss mit einer anderen Datei testen und melde mich wieder, vielleicht habe ich mir nur ein Beispiel zum Testen gesucht, wo die GPX-Datei ein AUsnahmefall ist, obwohl es damit keine Probleme unter 18.04 gibt.

Das sieht nicht nach einem Rechteproblem aus, der Fehler kommt daher, dass die localize() Methode von pytz einen Fehler wirft, wenn das datetime-Objekt bereits eine Zeitzone hat - bitte probier mal die angehängte Fassung des Skripts.

Dürfte was ganz spezielles sein, habe jetzt ein Beispiel gefunden wo es funktioniert. Ich teste, das kann aber dauern bis ich mich melde. Ich kann mir ja vorstellen, dass es bei meinem Script Probleme gibt, weil nun ein User Rechte bekommt (das führt hier zu weit), aber für die Konsole mit nur dem 1 Befehl sollte es egal sein. Ich vermute, dass es keine verwertbaren GPX-Koordinaten bei der Abfrage gibt, das Testfoto ist in einer Schlucht, anderersets sind 216000 Sekunden eine ganze Menge.

Wieder mal typisch, ist suche mir was zum Testen und erwische gleich einen Sonderfall.

Die Fehlermeldung besagt eindeutig, dass die Timestamps der Wegpunkte schon eine Zeitzoneninformation haben (die könnte z.B. direkt aus der gpx-Datei stammen, bei deinen Beispieldaten von damals hat die teilweise gefehlt) und pytz die deswegen (oder weil sich in der Zwischenzeit etwas an der localize() Methode von pytz geändert hat) nicht überschreiben will.

bitte probier mal die angehängte Fassung des Skripts.

Ich sehe da keinen Anhang. Sorry, das hatte ich vorher am Handy überlesen, vielleicht habe sich unser Postings auch überschnitten.

Ups, da hatte ich wohl heute Morgen vergessen den Anhang auch hochzuladen...

/usr/local/bin/geoinfo.py -a xxxx -u yyyy --timedelta 216000 -lde /fotos/test/test.gpx test.jpg 
trying to open /fotos/test/test.cache...
initializing tzwhere...
created tzwhere object
creating cache file...
successfully created cache file /fotos/test/test.cache
Traceback (most recent call last):
  File "/usr/local/bin/geoinfo.py", line 875, in yield_point_with_tz_corrected_timestamp
    orig_tz_ts = self.orig_tz.localize(point.time)
  File "/usr/lib/python3/dist-packages/pytz/__init__.py", line 238, in localize
    raise ValueError('Not naive datetime (tzinfo is already set)')
ValueError: Not naive datetime (tzinfo is already set)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/bin/geoinfo.py", line 928, in <module>
    main()
  File "/usr/local/bin/geoinfo.py", line 921, in main
    tz_corrected_data = geoinfo.tz_corrected_trackpoints(calculated_data)
  File "/usr/local/bin/geoinfo.py", line 644, in tz_corrected_trackpoints
    points))
  File "/usr/local/bin/geoinfo.py", line 878, in yield_point_with_tz_corrected_timestamp
    eprint("got point {point} with tzinfo:", {point.time.tzinfo})
TypeError: unhashable type: 'SimpleTZ'

Ich habe das Beispiel in einen neuen Ordner gegeben und das cache-File neu rechnen lassen, aber wie schon geschrieben, ich glaube mit diesem Foto ist kein Abgleich möglich.

Hier ein anderes Beispiel, da sollten die Koordinaten abgleichbar sein. Wenn ich mich da nicht irre, dann lief das mit der alten Version durch, aber ich bin vorsichtig geworden, da ich permanent Anpassungen in meinem Script mache und im schlimmsten Fall ignoriert mein Script das Problem, daher Test in der Konsole.

/usr/local/bin/geoinfo.py -a xxxx -u yyyy --timedelta 216000 -lde uk.gpx uk.jpg 
trying to open uk.cache...
sucessfully loaded cache file
Traceback (most recent call last):
  File "/usr/local/bin/geoinfo.py", line 875, in yield_point_with_tz_corrected_timestamp
    orig_tz_ts = self.orig_tz.localize(point.time)
  File "/usr/lib/python3/dist-packages/pytz/__init__.py", line 238, in localize
    raise ValueError('Not naive datetime (tzinfo is already set)')
ValueError: Not naive datetime (tzinfo is already set)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/bin/geoinfo.py", line 928, in <module>
    main()
  File "/usr/local/bin/geoinfo.py", line 921, in main
    tz_corrected_data = geoinfo.tz_corrected_trackpoints(calculated_data)
  File "/usr/local/bin/geoinfo.py", line 644, in tz_corrected_trackpoints
    points))
  File "/usr/local/bin/geoinfo.py", line 878, in yield_point_with_tz_corrected_timestamp
    eprint("got point {point} with tzinfo:", {point.time.tzinfo})
TypeError: unhashable type: 'SimpleTZ'

Ups, da ist was bei der Debug-Ausgabe durcheinander gekommen, eine aktualisierte Version habe ich Angehängt.

Danke dir 9107350-geoinfo.py passt fast, dh Ergebnis sieht gut aus, aber es werden tausende Koordinaten ausgegeben.

got point Geopoint(name='TP15174', latitude=47.79026327, longitude=13.000530439, elevation=423.468051, time=datetime.datetime(2018, 1, 6, 17, 12, 40, tzinfo=SimpleTZ("Z")), timezone_name='Europe/Vienna') with tzinfo: SimpleTZ("Z")
got point Geopoint(name='TP15175', latitude=47.7903635, longitude=13.000146343, elevation=422.809548, time=datetime.datetime(2018, 1, 6, 17, 12, 50, tzinfo=SimpleTZ("Z")), timezone_name='Europe/Vienna') with tzinfo: SimpleTZ("Z")
got point Geopoint(name='TP15176', latitude=47.790366497, longitude=13.000120337, elevation=422.507281, time=datetime.datetime(2018, 1, 6, 17, 13, tzinfo=SimpleTZ("Z")), timezone_name='Europe/Vienna') with tzinfo: SimpleTZ("Z")
got point Geopoint(name='TP15177', latitude=47.790350519, longitude=13.000140339, elevation=424.118799, time=datetime.datetime(2018, 1, 6, 17, 13, 10, tzinfo=SimpleTZ("Z")), timezone_name='Europe/Vienna') with tzinfo: SimpleTZ("Z")
### track elevation stats ###
elevation_maximum=9930
elevation_minimum=-33
elevation_mean=186
elevation_median=52
elevation_stdev=994
elevation_variance=988349
### end track elevation stats ###
image timestamp=2018-01-03 13:16:27
gps timestamp=2018-01-03 13:16:27
minimum timedelta=0:00:00
coordinates=56.340034414, -2.80180257
no alpha2 country code
### POINT START ###
name=TP5479
latitude=56.340034414
longitude=-2.80180257
elevation=29
elevation_source=gpx data
time=2018-01-03 13:16:27
timezone_name=Europe/London
licence=Data © OpenStreetMap contributors, ODbL 1.0. https://osm.org/copyright
location=Hope Park and Martyrs Church, A915, Northbank Farm Steadings, St Andrews, Fife, Schottland, KY16 9XD, Vereinigtes Königreich
country_code=gb
country_code3=
country=Vereinigtes Königreich
state=Schottland
state_district=
county=Fife
postcode=KY16 9XD
city=
town=St Andrews
postal_town=
village=
suburb=Northbank Farm Steadings
city_district=
neighbourhood=
road=A915
route=
pedestrian=
address29=
path=
house_number=
townhall=
ruins=
attraction=
place_of_worship=Hope Park and Martyrs Church
hotel=
bus_stop=
country_part=Schottland
loc_name=St Andrews
street_name=A915
### POINT END ###
unused attributes: 

Ich habe gerade noch mal ein bisschen im Bugtracker von gpxpy gewühlt, wie es aussieht, weist es jedem Datetime-Objekt eine Zeitzoneninformation zu, unabhängig davon ob die Zeitangabe im Punkt aus der GPX-Datei als UTC ausgewiesen ist oder nicht (tkrajina/gpxpy/issues/182).

Bei der Version im Anhang habe ich die Debug-Ausgabe zu den Punkten mit Zeitzonen-Information entfernt und das optionale Ersetzen der Zeitzonen-Information durch die vom Benutzer vorgegebene Zeitzone wiederhergestellt.

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

$ /usr/local/bin/9107439-geoinfo.py -a xxxx -u yyyy --timedelta 216000 -lde test.gpx test.jpg 
trying to open test.cache...
sucessfully loaded cache file
### track elevation stats ###
elevation_maximum=1143
elevation_minimum=388
elevation_mean=1035
elevation_median=1079
elevation_stdev=114
elevation_variance=13038
### end track elevation stats ###
image timestamp=2017-10-03 10:11:57
gps timestamp=2017-10-03 12:20:26
minimum timedelta=2:08:29
coordinates=47.13313146, 13.680164234
no alpha2 country code
### POINT START ###
name=TP0180
latitude=47.13313146
longitude=13.680164234
elevation=1124
elevation_source=gpx data
time=2017-10-03 12:20:26
timezone_name=Europe/Vienna
licence=Data © OpenStreetMap contributors, ODbL 1.0. https://osm.org/copyright
location=Bäckerei Binggl, Schmiedgasse, Mauterndorf, Tamsweg - Lungau, Salzburg, 5570, Österreich
country_code=at
country_code3=
country=Österreich
state=Salzburg
state_district=
county=Tamsweg - Lungau
postcode=5570
city=
town=Mauterndorf
postal_town=
village=
suburb=
city_district=
neighbourhood=
road=Schmiedgasse
route=
pedestrian=
address29=
path=
house_number=
townhall=
ruins=
attraction=
place_of_worship=
hotel=
bus_stop=
country_part=Salzburg
loc_name=Mauterndorf
street_name=Schmiedgasse
### POINT END ###
unused attributes: bakery
bakery=Bäckerei Binggl

$ /usr/local/bin/9107439-geoinfo.py -a xxxx -u yyyy --timedelta 1000 -lde test.gpx test.jpg 
trying to open test.cache...
sucessfully loaded cache file
### track elevation stats ###
elevation_maximum=1143
elevation_minimum=388
elevation_mean=1035
elevation_median=1079
elevation_stdev=114
elevation_variance=13038
### end track elevation stats ###
image timestamp=2017-10-03 10:11:57
gps timestamp=2017-10-03 12:20:26
minimum timedelta=2:08:29
no entry found

Bei "no entry" greifen dann meine Fallback-Koordinaten bzw. eine Erhöhung der Zeittoleranz.

Ich frage mich, ob da einfach die GPX-Datei zu viele Trackpoints (fast 50000) enthält und die cache-Erstellung mit der Gratis-Variante nicht durchläuft, aber "successfully created cache file"

could not calculate timezone id for TP48659 at 54.857501074, 17.946871777
asking geonames timezone api
geonames tz api: Europe/Warsaw
creating cache file...
successfully created cache file 2019-08_asientest.cache
Traceback (most recent call last):
  File "/usr/local/bin/geoinfo.py", line 875, in yield_point_with_tz_corrected_timestamp
    orig_tz_ts = self.orig_tz.localize(point.time)
  File "/usr/lib/python3/dist-packages/pytz/__init__.py", line 238, in localize
    raise ValueError('Not naive datetime (tzinfo is already set)')
ValueError: Not naive datetime (tzinfo is already set)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/bin/geoinfo.py", line 928, in <module>
    main()
  File "/usr/local/bin/geoinfo.py", line 921, in main
    tz_corrected_data = geoinfo.tz_corrected_trackpoints(calculated_data)
  File "/usr/local/bin/geoinfo.py", line 644, in tz_corrected_trackpoints
    points))
  File "/usr/local/bin/geoinfo.py", line 878, in yield_point_with_tz_corrected_timestamp
    eprint("got point {point} with tzinfo:", {point.time.tzinfo})
TypeError: unhashable type: 'SimpleTZ'
trying to open 2019-08_asientest.cache...
sucessfully loaded cache file
Traceback (most recent call last):
  File "/usr/local/bin/geoinfo.py", line 875, in yield_point_with_tz_corrected_timestamp
    orig_tz_ts = self.orig_tz.localize(point.time)
  File "/usr/lib/python3/dist-packages/pytz/__init__.py", line 238, in localize
    raise ValueError('Not naive datetime (tzinfo is already set)')
ValueError: Not naive datetime (tzinfo is already set)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/bin/geoinfo.py", line 928, in <module>
    main()
  File "/usr/local/bin/geoinfo.py", line 921, in main
    tz_corrected_data = geoinfo.tz_corrected_trackpoints(calculated_data)
  File "/usr/local/bin/geoinfo.py", line 644, in tz_corrected_trackpoints
    points))
  File "/usr/local/bin/geoinfo.py", line 878, in yield_point_with_tz_corrected_timestamp
    eprint("got point {point} with tzinfo:", {point.time.tzinfo})
TypeError: unhashable type: 'SimpleTZ'

Es kann da durchaus sein, dass da irgendein Punkt im Meer zwischen indonesischen Inseln abgefragt wurde.

PS: Es könnte auch mit den Imagemagick-Problemen unter Eoan zu tun haben. Das hier war nur die Logik, wenn mein Script mit einem Album mit anderen Fotos durchläuft, dann kommt keine Fehlermeldung. Ich muss das mal außerhalb meines Scripts testen um dort Probleme auszuschliessen. Während der Feiertage habe ich aber nicht viel Zeit.

Es liegt wahrscheinlich daran, dass unter Eoan meine find-Syntax im Script nicht mehr funktioniert und daher bei der Angabe der Bilddatei eine leere Variable angegeben wird. Frage mich aber, warum mein Script bei anderen Verzeichnissen durchläuft. Aber gut, das ist dann nicht hier das Problem deines Scripts. Vgl. https://forum.ubuntuusers.de/topic/eoan-find-mit-regex/

Hmmh, neben allen anderen Problemen, die ich sonst noch habe, ergibt sich nun im Terminal, also außerhalb meines Scripts und ohne Variablen mit vollen Pfadangaben das schon zitierte Problem:

MYGEOINFO /usr/local/bin/geoinfo.py
FIRST_MINIMUM_TIMEDELTA_SEC 216000

Die Werte der Variablen sollten also passen.

GPSINFO_DE=`$MYGEOINFO -a "$GOOGLEAPI" -u "$GEONAMESUSER" --timedelta "$FIRST_MINIMUM_TIMEDELTA_SEC" -lde "$GPXFILE" "$FIRSTFILE"`

sucessfully loaded cache file
Traceback (most recent call last):
  File "/usr/local/bin/geoinfo.py", line 875, in yield_point_with_tz_corrected_timestamp
    orig_tz_ts = self.orig_tz.localize(point.time)
  File "/usr/lib/python3/dist-packages/pytz/__init__.py", line 238, in localize
    raise ValueError('Not naive datetime (tzinfo is already set)')
ValueError: Not naive datetime (tzinfo is already set)

Die Koordinaten sollten sein, wenn ich manuell über Suchen in der Textdatei abgleiche:

Lokale Zeit auf Bali:

[EXIF]          0x9003 Date/Time Original              : 2019:08:21 13:04:00
[EXIF]          0x9004 Create Date                     : 2019:08:21 13:04:00

UTC -8h:

      <trkpt lat="-8.534122036" lon="115.509751101">
        <ele>-1.856111</ele>
        <time>2019-08-21T05:03:53Z</time>
        <speed>0.000000</speed>
        <name>TP19943</name>
      </trkpt>
      <trkpt lat="-8.534131088" lon="115.509791715">
        <ele>-1.789164</ele>
        <time>2019-08-21T05:04:03Z</time>
        <speed>0.555556</speed>
        <name>TP19944</name>
      </trkpt>
      <trkpt lat="-8.534129520" lon="115.509877229">
        <ele>-0.633641</ele>
        <time>2019-08-21T05:04:13Z</time>
        <speed>0.833333</speed>
        <name>TP19945</name>
      </trkpt>

Das ist also bei Padang Bai Port auf Bali:

<trkpt lat="-8.534131088" lon="115.509791715">

Damit es nicht langweilig ist.

Verwende ich Fotos aus Bayern mit der dazugehörigen GPX-Datei, dann gibt es keine Probleme.

Die verwendete Cache-Datei ist eine auf genau diesen Tag reduzierte Datei, aber vielleicht ist die Cache-Datei irgendwie kaputt.

Habe noch ein Foto aus Singapur probiert mit ähnlicher Fehlermeldung. Die Cache-Datei wurde fehlerfrei erstellt.

[EXIF]          0x9003 Date/Time Original              : 2019:09:02 16:39:17
[EXIF]          0x9004 Create Date                     : 2019:09:02 16:39:17
[EXIF]          0x9003 Date/Time Original              : 2019:09:02 16:39:17

Unterschied gegenüber UTC -8h:

      </trkpt>
      <trkpt lat="1.350784372" lon="103.990399117">
        <ele>23.510286</ele>
        <time>2019-09-02T03:29:02Z</time>
        <speed>0.000000</speed>
        <name>TP47600</name>
      </trkpt>
      <trkpt lat="1.288688007" lon="103.856075419">
        <ele>1.319266</ele>
        <time>2019-09-02T08:43:35Z</time>
        <speed>0.000000</speed>
        <name>TP47601</name>
      </trkpt>

Das sollte also dazu passen:

<trkpt lat="1.350784372" lon="103.990399117">

Maps zeigt ein ähnliches Foto.