Froschs Blog

Computer und was das Leben sonst noch so zu bieten hat

Zur Website | Impressum

Spaß mit GPS

16. Februar 2019 um 21:39 Uhr von Atari-Frosch

Am 16. Januar kam mein „neuer“ (gebrauchter) GPS-Empfänger für die Canon EOS 750D an. Freude! Das Teil, das auf den Blitzschuh gesteckt wird, sollte mir nicht nur zukünftig alle Fotos geotaggen, sofern ich im Freien bin, sondern auch gleich noch die Uhr der Kamera nachstellen. Vor allem das automatische Geotagging wird mir in Zukunft eine Menge Arbeit ersparen und zugleich vermutlich genauere Daten liefern, als wenn ich das im Nachhinein mühsam über das OpenStreetMap-Plugin von Piwigo versuche. Das Gerät mit der Bezeichnung Canon GP-E2 ist gar nicht so einfach zu bekommen, was mich etwas wundert. Sind die Leute denn nicht daran interessiert, im Nachhinein zu wissen, wo genau eine bestimmte Aufnahme gemacht wurde? Lieber Rätselraten? Ich weiß ja nicht.

Routen aufzeichnen kann das Gerät zwar auch noch, aber abgerufen werden können diese Daten dann nur mit einer Windows-Software. Ich probiere gar nicht erst aus, ob die unter wine laufen würde. Denn wenn ich Routen haben will, kann ich dafür einfacher das Smartphone nehmen. Mir kommt es aber ausschließlich auf die Koordinaten in den EXIF-Daten an.

Am 9. Februar war es dann soweit, und ich konnte das Gerät zum ersten Mal einsetzen. Anlaß war eine Demonstration eines breiten Bündnisses unter dem Motto Keine rechten Schläger in Düsseldorf-Eller und überall gegen eine „Bürgerwehr“ der sogenannten „Deutschen Bruderschaft“, einer rechten Hooligan-Gruppe, die bereits im November 2018 sehr unangenehm in Düsseldorf aufgefallen war. Nachdem ich mit rund 120 Aufnahmen, einem Muskelkater und mal wieder einer Blase am Fuß zurückgekommen war und die Dateien auf den PC gezogen hatte, schaute ich natürlich gleich mal neugierig in die EXIF-Daten der Bilddateien, und siehe da, das sieht doch schonmal sehr schön aus:

 GPS Tag Version     |2.3.0.0
 North or South Latit|N
 Latitude            |51, 12.0512,  0
 East or West Longitu|E
 Longitude           | 6, 50.2843,  0
 Altitude Reference  |Sea level
 Altitude            |45.4
 GPS Time (Atomic Clo|13:56:11.00
 GPS Satellites      |12
 GPS Receiver Status |A
 GPS Measurement Mode|3
 Measurement Precisio|2.3
 Geodetic Survey Data|WGS-84
 GPS Date            |2019:02:09

Das heißt: Fast. Nach der Umbenennung der Dateien auf den Zeitstempel aus den EXIF-Daten (mit meinem Python-Script renamefolder.py aus dem Projekt The Big Renaming) stimmte nämlich die Uhrzeit nicht mehr: Der Empfänger hatte die Uhrzeit in der Kamera bei der ersten Aktivierung verändert. Der Zeitstempel des Bildes, aus dem die eben gezeigten GPS-Daten stammen, sieht nämlich so aus:

 Date and Time       |2019:02:09 15:56:40

Der kleine Haken: Auf allen anderen Uhren in Deutschland war es zu dieser Zeit 14:56 Uhr.

Die Zeitzonen-Einstellung in der Kamera war vorher „Paris“ gewesen (Berlin kennt sie nicht, warum auch immer), was UTC+1 entspricht. Durch die Umstellung des GPS-Empfängers wurde daraus UTC+2, und alle Bilddateien lagen eine Stunde in ihrer relativen Zukunft. Logisch erscheint das nicht, denn in den GPS-Daten steht die Zeit in UTC+0; die Kombination „GPS meldet UTC+0“ und „Kamera will UTC+1“ hätte doch eigentlich die gewünschte Uhrzeit liefern müssen. Auf die Idee, die Zeitzone in der Kameraeinstellung ggf. mit umzustellen, kam man bei Canon anscheinend nicht. Im Nachhinein habe ich die Kamera auf Londoner Zeit umgestellt, damit zeigt sie jetzt die korrekte Uhrzeit an; die Uhrzeit hat die Kamera trotz Entfernung des GPS-Empfängers behalten, das heißt, ich sollte auch dann die korrekte Zeit haben, wenn ich Bilder ohne den GPS-Empfänger mache (zum Beispiel in geschlossenen Räumen).

Spätestens wenn da noch mindestens eine weitere Kamera innerhalb einer Fotoserie dazukommt, die ich nicht einfach auf UTC+0 stellen kann, nämlich hier die meines Smartphones, ist dieses Verhalten … ungünstig. Daß ich gerade bei größeren Serien auch Smartphone-Fotos zwischendurch dabei habe, ist nicht so ungewöhnlich. Problem ist dann: Die Sortierung über Dateinamen funktioniert nicht mehr. So nebenbei sieht es auch seltsam aus, wenn der Zeitstempel für ein Bild eine bestimmte Uhrzeit ausweist und auf dem Foto zufällig eine öffentliche Uhr zu sehen ist, die eine Stunde früher zeigt. Die Zeitzone steht nämlich nicht in den EXIF-Daten. Jedenfalls nicht bei mir.

So, das war erstmal der Teil, der das Gerät direkt betrifft. Und dann kam Piwigo bzw. dessen OpenStreetMap-Plugin.

Nach dem Bearbeiten der Bilder – bei solchen Demos sollte man schon drauf achten, daß Gesichter von Teilnehmern nicht erkennbar sind – und dem Upload schaute ich also in den Tab für OpenStreetMap. Und war extrem enttäuscht: Die Koordinaten zeigten bei allen Bildern auf 0,0, wurden also offensichtlich nicht aus den Bilddateien ausgelesen. Ich überprüfte extra, ob GIMP nicht doch (teilweise) die EXIF-Daten gelöscht hatte, obwohl ich ihm das verboten hatte und obwohl Piwigo den Zeitstempel der Bilddateien aus den EXIF-Daten übernommen hatte, aber nein, sie waren auch in den bearbeiteten Dateien unverändert vorhanden. Piwigo bzw. das OSM-Plugin las sie einfach nicht ein. 🙁

Was tut man da? Als erstes schaute ich in die offenen Issues zum OSM-Plugin. Dort fand ich aber keinen Hinweis darauf, daß das irgendwo ein Problem wäre. Also doch eine lokale Geschichte bzw. mal wieder einer dieser Fehler, die nur bei mir auftreten?

Auf Twitter bekam ich vom Account @piwigo erstmal und auch am Tag danach keine Antwort.

Aber Alex, dem ich mein Leid im IRC geklagt hatte, kam auf eine andere Spur: Er vermutete einen PHP-Fehler im OSM-Plugin. Darauf kam er über die Beschreibung zu einem anderen Plugin für Piwigo, das sich ebenfalls mit EXIF-Daten befaßt, nämlich Exiftool GPS. Dort heißt es:

Uses command line exiftool to read exif GPS data. This is a workaround for the read_exif_data/exif_read_data bug in PHP which fails to read exif data if there are makernote data in the file.

Was sind nun Makernotes? Die englische Wikipedia klärt auf (MakerNote data, abgerufen 2019-02-10 21:20):

The "MakerNote" tag contains image information normally in a proprietary binary format. Some of these manufacturer-specific formats have been decoded:

[…]

Unfortunately, the proprietary formats used by many manufacturers break if the MakerNote tag is moved, i.e. by inserting or editing a tag that precedes it. The reason to edit to the Exif data could be as simple as to add copyright information, an Exif comment, etc. In some cases, camera vendors also store important information only in proprietary makernote fields, instead of using available Exif standard tags. An example for this is Nikon's ISO speed settings tag.

Den zweiten Absatz interpretiere ich so, daß das Einschieben der GPS-Daten durch den zusätzlichen Empfänger etwas an der Position des Tags „Maker Notes“ verändert und sie dann nicht mehr gelesen werden können. Den Tag habe ich in den EXIF-Daten tatsächlich gefunden, er sieht mit exif von der Kommandozeile aus so aus:

 Maker Note          |8634 bytes undefined data

Die Größe variiert bei den Bilddateien, bewegt sich aber immer so im Bereich um 8 kB. Auch hier muß ich die Logik wieder nicht verstehen: Die GPS-Daten wurden zumindest der Anzeige nach an die sonst von der Kamera erzeugten EXIF-Daten angehängt, veränderten also gerade nicht die Position des „Maker Notes“-Tags. Aber vielleicht sieht das auch nur in der Anzeige so aus …

Ich war am 9. Februar abends dann zu müde, um damit noch weiter herumzuspielen. Am 10. Februar wollte ich dann das zusätzliche Plugin installieren. Aber die Plugin-Sektion von Piwigo erzählte mir in dickem Rot: „Es konnte keine Verbindung zum Server hergestellt werden.“ Huch?

Als erstes überprüfte ich, ob die IP des Piwigo-Hosts aus irgendwelchen Gründen – direkt oder via fail2ban – in meiner iptables gelandet war. Nö, war sie nicht.

Dann fragte ich das Webserver-Log:

2019/02/10 21:27:39 [error] 12310#12310: *740541 FastCGI sent in stderr: "PHP message: PHP Warning: Invalid argument supplied for foreach() in /srv/atarifrosch-media/admin/plugins_installed.php on line 91" while reading response header from upstream, client: [meine IP], server: media.atari-frosch.de, request: "GET /admin.php?page=plugins_installed&incompatible_plugins=true HTTP/1.1", upstream: "fastcgi://unix:/run/php5-fpm.sock:", host: "media.atari-frosch.de", referrer: "https://media.atari-frosch.de/admin.php?page=plugins"

Nanü? – Spannend auch, daß ich diese Fehlermeldung nur bei drei von vier Versuchen (zu unterschiedlichen Uhrzeiten) im error.log stehen habe.

Dabei fiel mir auf, daß mir beim Upgrade auf PHP7 letztens anscheinend was durchgegangen ist: php5-fpm? Das sieht nicht so aus, als würde das PHP, das der Webserver schickt, in PHP7 ausgeführt werden. Also erstmal php5-fpm gestoppt, php7.0-fpm gestartet, in allen Sites, die PHP benutzen, den Pfad zum Socket angepaßt und nginx die Konfiguration neu laden gelassen. Ja, und damit war der Fehler weg, und Piwigo konnte mir wieder Plugins anbieten. Muß man auch erstmal drauf kommen …

(Außerdem kann ich jetzt auch wieder WordPress-Plugins aktualisieren und installieren, das ging nämlich seit ein paar Wochen auch nicht mehr – ich hatte fälschlicherweise vermutet, daß es damit zusammenhängen könnte, daß ich nicht auf die 5er-Version gegangen bin, sondern weiterhin #ausgründen mit 4.9.9 arbeite.) Was immer noch nicht funktionierte: Das automatische Einlesen der GPS-Daten aus den Bilddateien im Piwigo.

Aber jetzt konnte ich ja wieder Plugins installieren. Ich zog also Exiftools GPS und sah mir noch einmal die am Vortag hochgeladenen Fotos im Sammelkorb an. Keine Änderung: Die Koordinaten wurden immer noch nicht angezeigt.

Als nächstes versuchte ich es mit der Metadaten-Synchronisation, sicherheitshalber erst einmal, da das angeboten wird, im Probelauf, also ohne daß die Datenbank tatsächlich angefaßt wird. Es wird explizit angegeben, daß auch GPS-Daten synchronisiert werden sollten. Ergebnis: 0 Bilder würden synchronisiert. So geht's also auch nicht.

Dann lud ich eines der Bilder von der Demonstration nochmal hoch; wenn das entsprechende Plugin installiert ist, kann man Bilder aktualisieren, sprich, einfach nochmal hochladen, ohne daß die bisherigen Datenbank-Einträge verändert werden. Nunja, auch die GPS-Daten wurden in der Datenbank offenbar nicht verändert – weiterhin stehen die Koordinaten auf 0,0.

Das error.log verkündete unbeeindruckt:

2019/02/10 23:44:20 [error] 13263#13263: *742532 FastCGI sent in stderr: "PHP message: PHP Warning: Invalid argument supplied for foreach() in /srv/atarifrosch-media/plugins/exiftool_gps/main.inc.php on line 23" while reading response header from upstream, client: [meine IP], server: media.atari-frosch.de, request: "POST /admin.php?page=plugin-photo_update-15237 HTTP/1.1", upstream: "fastcgi://unix:/run/php/php7.0-fpm.sock:", host: "media.atari-frosch.de", referrer: "https://media.atari-frosch.de/admin.php?page=plugin-photo_update-15237"

Aha. Es funktionierte jetzt offenbar mehr, aber noch nicht alles. Vor allem nicht das, worauf es mir eigentlich gerade ankam.

Ein neuer Tag, ein neuer Versuch; wir sind jetzt beim 11. Februar. Auf meinen Tweet an @piwigo bekam ich endlich eine Rückmeldung – wie üblich von @Flop_Ysh und nicht vom Piwigo-Account selbst. Ich solle doch mal /tools/metadata.php ausprobieren. Dazu mußte ich erstmal herausfinden, wie man das benutzt, das erschließt sich nämlich nicht gerade intuitiv: Metadata (unter „Expanding Piwigo's Metadata Capabilities“).

Ergebnis, auch im direkten Vergleich mit dem Aufruf von exif an der Konsole: Es steht alles in der Datenbank – außer den GPS-Daten.

Auffällig ist noch, daß das Exiftool-Plugin nicht in der Liste der Plugins auf der linken Seite des Plugin-Menüs im Dashboard erscheint, im Gegensatz zu allen anderen Plugins. Aber nur, was da drinsteht, kann man auch konfigurieren. Das Plugin läßt sich ansonsten nur „zurücksetzen“ – was wenig sinnvoll ist, weil es ja immer noch im Ausgangszustand ist, den ich wiederum nicht nachsehen kann, weil ich die Konfiguration ja nicht zu sehen bekomme.

Nächste Runde. Flop hatte mir geraten, das Thema im englischsprachigen Forum von Piwigo einzubringen. Ich hasse Foren. Aber was will man machen. Mein erstes Posting setzte ich unter einen schon etwas älteren Thread, der das gleiche Thema zu haben schien, aber der war halt von Ende 2015. Flop bat mich, einen neuen Thread aufzumachen. Na gut, dann eben nochmal, dafür dann auch gleich noch ein wenig ausführlicher: Get gps data from file to OSM plugin.

16. Februar. Der Forumseintrag blieb bislang unbeantwortet. Danke für's Gespräch 😒

Nächster Versuch: Das Plugin ImageMagick GPS. Das zeigte mir nach der Installation aber auch gleich 'ne Nase: Es wollte bitte zur Aktivierung php-imagick auf dem Server laufen haben. Nach der Installation erzählte es mir immer noch dasselbe, obwohl das Plugin PHP 7 zu sein schien; ich hatte zunächst einen Versionskonflikt vermutet, denn PHP 5 ist ja auch noch installiert.

root@seelilie ~ # service php7.0-fpm restart

[ ok ] Restarting PHP 7.0 FastCGI Process Manager: php-fpm7.0.

Ha! Danach ließ sich das Plugin aktivieren.

Und noch mehr HA! – Nach dem testweisen Aktualisieren von zwei Fotos aus der Serie hatten die Bilder dann tatsächlich ihre GPS-Daten im OSM-Plugin.

Da es zu umständlich gewesen wäre, alle Fotos von der 750D einzeln zu aktualisieren, löschte ich sämtliche Bilder (und Videos) vom 9. Februar und wollte sie nochmal komplett neu hochladen. Dabei passierte aber zweimal hintereinander dasselbe wie am 11. bei dem Versuch, ein einzelnes Bild nochmal hochzuladen: Irgendwann lief sich der Upload tot.

Das error.log hatte nicht wirklich was Neues zu berichten:

2019/02/16 20:27:38 [error] 20859#20859: *825948 FastCGI sent in stderr: "PHP message: PHP Warning: Invalid argument supplied for foreach() in /srv/atarifrosch-media/plugins/exiftool_gps/main.inc.php on line 23" while reading response header from upstream, client: [meine IP], server: media.atari-frosch.de, request: "POST /ws.php?method=pwg.images.upload&format=json HTTP/1.1", upstream: "fastcgi://unix:/run/php/php7.0-fpm.sock:", host: "media.atari-frosch.de", referrer: "https://media.atari-frosch.de/admin.php?page=photos_add"

Moment mal. Wieso jetzt Exiftools GPS? Das brauchte ich doch gar nicht mehr. Also Plugin deaktiviert und neuer Upload-Versuch: So funktionierte das. Spannend wurde jetzt die Frage: Sind die GPS-Daten in die Datenbank gewandert, kann das OSM-Plugin die Positionen darstellen?

YES! Es konnte. Boah, was eine schwere Geburt. 😉

So, jetzt passe ich noch die Erstellungszeit in den Zeitstempeln an, dann sollte alles stimmen.

Ein Kommentar zu “Spaß mit GPS”

  1. SackOhneSenf quakte:

    @Atari-Frosch: Da du in deinem Artikel bezüglich der Zeitangaben zwischen Äpfel und Birnen hin und her springst, möchte ich dich auf einen oft übersehenen Punkt aufmerksam machen:

    GPS Atomic Clock ist nicht gleichbedeutend mit UTC, kann also nicht einfach mit +/- N Stunden in die gewünschte Lokalzeit umgerechnet werden! Ein Grund, weshalb man von automatischem Verstellen/Übernehmen von Zeitzonen absehen sollte.

    Siehe hierzu als Beispiel:
    http://leapsecond.com/java/gpsclock.htm

    (oder andere Artikel zum Thema „GPS Atomic Time“)


Kommentieren

Bitte beachte die Kommentarregeln!

XHTML: Du kannst diese Tags verwenden: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>