ubuntuusers.de

Es geht darum die Exif-Daten eins Fotos mit einer gpx-Datei abzugleichen, aber NICHT darum die Koordinaten in das Foto zu schreiben. Ich brauche Variablen für ein Bash-Script.

Bis jetzt ging das damit ganz gut:

gpsPhoto.pl --dry-run --maxtimediff 3600  --timeoffset=guess --tz-guess=zone.tab --geoinfo=wikipedia --city=guess --state=guess --country=guess -i test.jpg --gpsfile test.gpx

Ich hänge nun bei "Problem getting geoinfo for point" Die Koordinaten werden aber richtig zugeordnet, nur bei den Geodaten hängt es dann, vermutlich ist der Server down oder es gibt eine Änderung am Server, sodass das alte gpsPhoto.pl aus 2012 nicht damit klarkommt.

City(geotag)=guess
City(nogeotag)=guess
Province-State(geotag)=guess
Province-State(nogeotag)=guess
Country-PrimaryLocationName(geotag)=guess
Country-PrimaryLocationName(nogeotag)=guess

Vor ein paar Tagen hatte ich bereits ähnliche Probleme und nun suche ich nach einer Alternative. Insbesondere brauche ich "Altitude", das zur Zeit gar nicht ausgegeben wird.

gpsPhoto.pl --geoinfo=list
zip wikipedia geourl none osm geonames

Bei geonames muss man sich mittlerweile registrieren und ich denke gpsPhoto.pl hat dafür keine Option

gpsPhoto.pl -V
gpsPhoto.pl (release 1.160 2012/10/10 19:51)

$ gpsPhoto.pl
You have to specify images (--dir, --image-list, --image)!
Usage:
    gpsPhoto.pl [options]

     Options:
      --dir directory    Image directory. Multiple are allowed.
      -I|--image-list file     Image list file. Multiple are allowed.
      -i|--image file    Image file name. Multiple are allowed.
      --gpsdir dir       GPX track directory. Multiple options are allowed.
      --gpsfile-list list      GPX track list file. Mult. options are allowed.
      --gpsfile gpx      GPX track file. Multiple options are allowed.
      --maxtimediff seconds    maximum difference time. Default: 120.
      --maxdistance metres     maximum interpolation distance. Default: 20.
      --timeoffset seconds     Camera time + seconds = GMT. No default.
      --writecaption     image name -> IPTC Caption-Abstract & ObjectName.
      --copydate         Date of EXIF DateTimeOriginal -> IPTC DateCreated.
      --select state     Select images. Default: any ('list' for list).
      --credit "text"    "text" -> IPTC Credit.
      --city "text"      "text" -> IPTC City.
      --sublocation "text"     "text" -> IPTC Sub-location.
      --state "text"     "text" -> IPTC Province-State.
      --country "text"   "text" -> IPTC Country-PrimaryLocationName.
      --copyright "text" "text" -> IPTC CopyrightNotice.
      --source "text"    "text" -> IPTC Source.
      --keywords "text"  "text" -> IPTC Keywords.
      --caption "text"   "text" -> IPTC Caption-Abstract.
      --enable-xmp       Write meta information into an extra XMP file.
      --kml kmlfile      KML output file for Google Earth.
      --kmz kmzfile      KMZ output file for Google Earth.
      --kml-image-type=type    How put an image in KML? ('list' for list).
      --kml-image-dir=dir      KML will reference images in dir.
      --kml-track-enable=method Which tracks come into KML? ('list for list).
      --track-color AABBGGRR   KML track colour: alpha, blue, green, red.
      --track-colour AABBGGRR  KML track colour: alpha, blue, green, red.
      --track-height     Draw track with height. Default off.
      --kml-timeline     Include a track timeline. Default off.
      --kml-placemark-thumbnail-size=size   Max thumbnail size (default 200).
      --kml-placemark-thumbnail-method=method  Thumbnail method (default: none).
      --kml-placemark-thumbnail-dir=dir     Thumbnail dir (default: 'thumbs').
      --dry-run|-n       Do not change the image files.
      --image-file-time=method How to set image time ('list' for list).
      --overwrite-geotagged    Overwrite geotagged images.
      --interpolate=method     Interpolate track points. ('list' for list).
      --tz-guess=method  Guess time zone of track. ('list' for list).
      --report-distance=method Report distance from place ('list' for list).
      --report-direction=method Report direction to place ('list' for list).
      --geoinfo=method   Reverse geo-coding method. ('list' for list).
      --geotag-source=source   Use geotag from source. ('list' for list).
      --geotag=lat,lon,alt     Manual geotag definition.
      --language=type    Definition of the language code (2-letter ISO-3166-1).
      --delete-geotag    Removes all geotags of the given images.
      -V|--version       Print version.
      -h|-?|--help       Print brief help message.
      --man              Print full documentation.

    Either --dir, --image-list, or --image is mandatory.

Was könnte also eine Alternative zu gpsPhoto.pl sein?

Kannst du mal eine Liste der Felder machen, die du aus der Datei extrahieren (bzw. im Fall der Geolocation abfragen) willst und eine gpx-Datei bereitstellen, die für deine Geo-Daten repräsentativ ist?

Für Python gibt es gpxpy und geopy, die das Parsen von gpx-Dateien und das Suchen einer Ortsbenennung für vorgegebene Koordinaten ermöglichen - z.B. um Koordinaten, Höhe und Ortsbeschreibung für Wegpunkte (über Nominatim von OSM) auszugeben:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

#!/usr/bin/env python3
import sys
import gpxpy
from geopy.geocoders import Nominatim
geolocator = Nominatim()


def parse_gpx_file(path):
    with open(gpx_file, 'r') as f:
        return gpxpy.parse(f)


def print_gpx_data(gpx_data):
    for waypoint in gpx_data.waypoints:
        print("latitude=%s" % (waypoint.latitude))
        print("longitude=%s" % (waypoint.longitude))
        print("altitude=%s" % (waypoint.elevation))
        if all((waypoint.latitude, waypoint.longitude)):
            global location
            location = geolocator.reverse(str(waypoint.latitude) + ', ' +
                                          str(waypoint.longitude))
            for key, value in location.raw['address'].items():
                print("%s=%s" % (key, value))

if __name__ == '__main__':
    for gpx_file in sys.argv[1:]:
        g = parse_gpx_file(gpx_file)
        print_gpx_data(g)

Aufruf wäre dann, wenn man das Skript ausführbar gemacht hat z.B.:

1

./geoinfo.py my.gpx [another.gpx] ...

Ich bin mir jetzt nicht sicher, ob ich alle Felder gefunden habe, für die ich Variablen brauche, aber was ergänzen dürfte dann nicht so schwer sein, wenn das funktioniert.

[IPTC]          0x005a City
[IPTC]          0x005f Province-State
[IPTC]          0x0064 Country-Primary Location Code
[IPTC]          0x0065 Country-Primary Location Name
[XMP]                - Country Code
[XMP]                - Location # PLZ
[XMP]                - GPS Altitude
[XMP]                - GPS Altitude Ref
[XMP]                - GPS Latitude
[XMP]                - GPS Longitude

Habe da mal irgendein bedeutungsloses Foto mit folgenden Koordinaten genommen: Problem getting geoinfo for point 49.610038300,6.140429900

Die angehängte gpx-Datei wurde mit gpsbabel verkleinert. Es werden verschiedene GPS-Logger verwendet, ich hoffe die gpx-Dateien sind dann kompatibel. Oft verwende ich Logger mit MTK- oder Wintec-Chipset.

"Country Code" für XMP sowie "Country-Primary Location Code" für IPTC haben vermutlich identische Werte (Länderkürzel), oder?

An die Höheninformationen des Bodens für gegebene Koordinaten (damit man die "GPS Altitude Ref" berechnen kann) komme ich über die Elevation-Komponente der Google Geocoding API - die ist in der kostenlosen Version auf 2500 Anfragen pro Tag mit bis zu 512 Datenpunkten limitiert und man muss sich einen API-Key dafür besorgen. Oder bezieht sich das nur fest auf die Angabe "Above Sea level"?

Brauchst du alle Datenpunkte aus Wegpunkten, Tracks und Routen oder reicht da ein bestimmter Typ?

Country Code" für XMP sowie "Country-Primary Location Code" für IPTC haben vermutlich identische Werte (Länderkürzel), oder?

Ja.

An die Höheninformationen des Bodens für gegebene Koordinaten

Das ist überhaupt nicht genau. Es geht darum, zB Bergfotos in über 2000m Höhe zu finden, oder Fotos am Meer, etc. Auf 100m genau reicht und wenn es nicht genau passt, auch nicht so schlimm. Fehler gibt es bei Geoinfo sowieso immer wieder. Früher hatte ich auf Stadtteilebene bestimmt, das war aber mehr falsch als richtig.

2500 Anfragen pro Tag sollten reichen, Könnte zwar sein, dass das manchmal zu wenig ist, aber dann warte ich eben auf den nächsten Tag. Ich nutze das sporadisch, aber dann intensiv

Brauchst du alle Datenpunkte aus Wegpunkten, Tracks und Routen oder reicht da ein bestimmter Typ?

Die Frage verstehe ich nicht. Ich lese das GPS aus und das hat mir bis jetzt gereicht. Meistens sind es Tracks, selten gibt es auch mnauell "markierte Punkte". Was du mit Route meinst, verstehe ich nicht.

glaskugel schrieb:

An die Höheninformationen des Bodens für gegebene Koordinaten

Das ist überhaupt nicht genau. Es geht darum, zB Bergfotos in über 2000m Höhe zu finden, oder Fotos am Meer, etc. Auf 100m genau reicht und wenn es nicht genau passt, auch nicht so schlimm. Fehler gibt es bei Geoinfo sowieso immer wieder. Früher hatte ich auf Stadtteilebene bestimmt, das war aber mehr falsch als richtig.

Deine Daten enthalten ja schon Höheninformationen im <ele> Tag - wenn ich http://www.opanda.com/en/pe/help/gps.html#GPSAltitudeRef richtig verstehe, braucht es noch einen Bezugspunkt für die Angabe - und da wird anscheinend nur 0 = Meereshöhe genutzt, dann kommt man denke ich auch ohne die Google-API aus, wenn man nicht anhand der Koordinaten die Höhe des Bodens an der Stelle abfragen muss, weil man z.B. mit einem Flugzeug unterwegs ist und sich für die Höhe über dem Boden interessiert.

Brauchst du alle Datenpunkte aus Wegpunkten, Tracks und Routen oder reicht da ein bestimmter Typ?

Die Frage verstehe ich nicht. Ich lese das GPS aus und das hat mir bis jetzt gereicht. Meistens sind es Tracks, selten gibt es auch mnauell "markierte Punkte". Was du mit Route meinst, verstehe ich nicht.

Es gibt verschiedene mögliche Elemente in den GPX-Dateien (hier gibt es z.B. eine Erklärung der Typen: http://www.gpsmap.net/DefiningPoints.html) - in deinem Beispiel habe ich Wegpunkte und Tracks mit Sektionen, die Trackpoints enthalten gesehen - die Frage ist, ob du neben den Punkten aus diesen Kategorien auch noch Routen-Punkte haben willst, falls sie vorhanden sind.

Deine Daten enthalten ja schon Höheninformationen im <ele> Tag - wenn ich http://www.opanda.com/en/pe/help/gps.html#GPSAltitudeRef richtig verstehe, braucht es noch einen Bezugspunkt für die Angabe

Der Bezugspunkt ist die Uhrzeit in den Exifdaten des Fotos, korrigiert um die Differenz zu UTC.

Das hat ja gpsPhoto.pl bis jetzt erledigt und könnte es weiter erledigen.

--maxtimediff 3600  --timeoffset=guess --tz-guess=zone.tab

Die 3600 (1h) Ungenauigkeit sind eigentlich sehr viel, aber manchmal besser als nichts, wenn das GPS sehr ungenau geloggt hat, kommt vor allem vor, wenn man längere Zeit in einem Gebäude war.

--timeoffset=guess --tz-guess=zone.tab

Das sollte sich meistens aufgrund der Koordinaten ergeben.

Frage ist, ob du neben den Punkten aus diesen Kategorien auch noch Routen-Punkte haben willst, falls sie vorhanden sind.

Ich denke Routen wie bei http://www.gpsmap.net/DefiningPoints.html erklärt "A route is a set of waypoints that you "tell" the receiver you want to navigate from one point to the next." gibt es bei mir nicht. Ich zeichne mit einem GPS-Logger auf und synchronisere dann mit Spezialkritierien in die Metadaten einer jpg-Datei. "Waypoints" bin ich mir nicht klar, ob ich die brauche, auch wenn sie vorhanden sind, denn über Trackpoints mit der entsprechenden Zeit sollte eigentlich alles vorhanden sein um einem Foto die Koordinaten zuzuordnen und die Zusatzinfos ergeben sich durch die Koordinaten.

Edit: Die Höhe reicht, wenn sie sich auf Meeresspiegel bezieht.

Ich komme vermutlich erst gegen Ende der Woche dazu, aber nur um den Algorithmus zu klären:

• Das Skript bekommt eine gpx-Datei und den Pfad zu einer Datei oder einem Ordner mit Bildern übergeben (sind das nur JPEG-Dateien oder auch andere Dateiformate?)

• Es holt sich für jedes Bild aus den Metadaten (z.B. Exif-Informationen) den Zeitpunkt der Aufnahme

• Dafür wird in den Tracks (und ggf. in den Waypoints) nach einem Eintrag mit einem Zeitstempel gesucht, der innerhalb einer vorgegebenen Zeitdifferenz liegen muss

• für den besten Treffer werden die Geodaten abgefragt (Land, Landesteil, Stadt) und zusammen mit Koordinaten und Höhe ausgegeben - gibt es da spezielle Wünsche für das Ausgabeformat?

Also erstmal vielen Dank!

Das Skript bekommt eine gpx-Datei und den Pfad zu einer Datei oder einem Ordner mit Bildern übergeben (sind das nur JPEG-Dateien oder auch andere Dateiformate?)

Gute Frage, Praktisch sind es nur jpg-Dateien, theoretisch könnte auch die Endung jpeg, pef, arw und nef vorkommen, dh Raw-Formate verschiedener Kameras. Wenn Raw umständlich ist, dann vergiss es, das sind nur Einzelfälle.

Es holt sich für jedes Bild aus den Metadaten (z.B. Exif-Informationen) den Zeitpunkt der Aufnahme

Aus welchem Feld?

Von einem ARW-File

[File]               - File Modification Date/Time     : 2016:09:05 14:23:09+02:00
[File]               - File Access Date/Time           : 2016:09:05 20:17:02+02:00
[File]               - File Inode Change Date/Time     : 2016:09:05 20:12:05+02:00
[EXIF]          0x0132 Modify Date                     : 2016:05:27 12:57:55
[EXIF]          0x9003 Date/Time Original              : 2016:05:27 12:57:55
[EXIF]          0x9004 Create Date                     : 2016:05:27 12:57:55
[EXIF]          0x0132 Modify Date                     : 2016:05:27 12:55:23
[MakerNotes]    0x0006 Sony Date Time                  : 2016:05:27 12:55:23
[MakerNotes]    0x022c Sony Date Time                  : 2016:05:27 12:55:23

Von einEm PEF-File:

[File]               - File Modification Date/Time     : 2016:09:03 22:39:52+02:00
[File]               - File Access Date/Time           : 2016:09:06 00:01:35+02:00
[File]               - File Inode Change Date/Time     : 2016:09:05 20:12:05+02:00
[EXIF]          0x0132 Modify Date                     : 2016:09:03 14:35:59
[EXIF]          0x9003 Date/Time Original              : 2016:09:03 14:35:59
[EXIF]          0x9004 Create Date                     : 2016:09:03 14:35:59
[MakerNotes]    0x0006 Date                            : 2016:09:03
[MakerNotes]    0x0001 Manufacture Date                : 2014:03:05
[MakerNotes]    0x0007 Time                            : 14:36:21

Die Zeit in MakerNotes war die an der Kamera tatsächlich eingestellte Zeit. Die Exif-Zeit ist eine korrigierte Zeit nach der abgeglichen werden soll. Ich mache das so:

dclock -dateup -date "%A, %d %b %Y" -seconds -smallsize .8 -miltime -geometry 1280x600 -bg black -led_off black -noblink

Die Ausgabe der Uhrzeit wird dann fotografiert und danach die Uhrzeit mit exiftool und den gespeicherten Exif-Daten korrigiert, zB

exiftool -overwrite_original -AllDates-="0:0:0 0:0:1"

-AllDates macht aber in Ausnahmefällen keinen Sinn. Ich denke "0x9003 Date/Time Original" sollte der Bezug für die Koordinaten sein.

Dafür wird in den Tracks (und ggf. in den Waypoints) nach einem Eintrag mit einem Zeitstempel gesucht, der innerhalb einer vorgegebenen Zeitdifferenz liegen muss

Hier kann es kniffelig werden, zB bei Sommerzeit-Umstellung bzw. Zeitzonenwechsel

für den besten Treffer werden die Geodaten abgefragt (Land, Landesteil, Stadt) und zusammen mit Koordinaten und Höhe ausgegeben - gibt es da spezielle Wünsche für das Ausgabeformat?

Wie eingangs schon erwähnt, ich brauche das als Variable für ein Bashscript. Am besten alles extra.

Also Längengrad 1 Variable, Breitengrad 1 Variable, etc.

Ich denke mir gerade, da das auch andere nutzen könnten, könntest du einfach weitere Informationen, die bei der Abfrage automatisch kommen, auch ausgeben. Mit Quickpic am Android-Handy sehe ich zB die Straße mit Hausnummer bei der Abfrage der Details. Man muss das dann ja nicht verwenden, wenn man es braucht. Wichtig ist nur, dass man sich die Daten dann irgendwie als Variable holen kann und es keine Probleme gibt, wenn ein Feld nicht bestimmt ist.

Was für einen Dienst nimmst du für die Geodaten? Könntest du eventuell verschiedene vorsehen, falls einer ausfällt?

gpsPhoto.pl --geoinfo=list
zip wikipedia geourl none osm geonames

Ich hatte mit gpsPhoto lange geonames verwendet und bin dann auf wikipedia umgestiegen, mittlerweile funktioniert beides nicht mehr. Bitte beachte, dass geonames einen User braucht. Kostenlose Registrierung bei http://www.geonames.org/login AFAIR sind die Abfragen pro Stunde beschränkt, ich erinnere mich dumpf, dass es irgendwas pro Stunde war und man bis zu Beginn der Stunde warten musste, wenn man zuviel abgefragt hat. Das erreiche ich Normalfall aber nicht, nur wenn ich mein Script testete und es irgendwo hakte.

Ich habe https://codeload.github.com/tkrajina/gpxpy/zip/master runtergeladen und bin da überhaupt nicht weitergekommen. In README.md sollte erklärt sein, wie man anfängt. Ich kenne mich mit Python nicht aus. Ein "make" brachte eine Reihe von Fehlermeldungen.

glaskugel schrieb:

Hier kann es kniffelig werden, zB bei Sommerzeit-Umstellung bzw. Zeitzonenwechsel

In den GPX-Daten werden Zeitstempel in UTC genutzt, z.B.:

1
2
3
4
5

      <trkpt lat="49.607998200" lon="6.136888300">
        <ele>284.000000</ele>
        <time>2016-05-27T10:00:33Z</time>
        <name>TP2312</name>
      </trkpt>

Damit ist die GPS-Seite eigentlich kein Problem. Wie sieht es bei den Daten aus der Kamera aus? Lässt du die mit Ortszeit laufen (dann könnte man die entsprechende Zeitzone auswählbar machen, mit der die Timestamps interpretiert werden sollen) oder mit UTC oder einfach einmal initial eingestellt mit MEZ oder MESZ?

für den besten Treffer werden die Geodaten abgefragt (Land, Landesteil, Stadt) und zusammen mit Koordinaten und Höhe ausgegeben - gibt es da spezielle Wünsche für das Ausgabeformat?

Wie eingangs schon erwähnt, ich brauche das als Variable für ein Bashscript. Am besten alles extra.

Also Längengrad 1 Variable, Breitengrad 1 Variable, etc.

Also z.B. so für den oben geposteten Trackpoint https://goo.gl/maps/26Sez2C9LZq:

name=TP2312
latitude=49.6079982
longitude=6.1368883
elevation=284.0
location=Écluse du Grund, Place Auguste Engel, Grund, Luxembourg, Canton Luxembourg, 1238, Lëtzebuerg
country_code=lu
city=Luxembourg
postcode=1238
country=Lëtzebuerg
county=Canton Luxembourg
road=Place Auguste Engel
ruins=Écluse du Grund
suburb=Grund

Nicht existierende Felder bei den über geoinfo abgerufenen Daten würde ich dann in der Ausgabe einfach weglassen.

Ich denke mir gerade, da das auch andere nutzen könnten, könntest du einfach weitere Informationen, die bei der Abfrage automatisch kommen, auch ausgeben. Mit Quickpic am Android-Handy sehe ich zB die Straße mit Hausnummer bei der Abfrage der Details. Man muss das dann ja nicht verwenden, wenn man es braucht. Wichtig ist nur, dass man sich die Daten dann irgendwie als Variable holen kann und es keine Probleme gibt, wenn ein Feld nicht bestimmt ist.

Was für einen Dienst nimmst du für die Geodaten? Könntest du eventuell verschiedene vorsehen, falls einer ausfällt?

Ich hätte den Neonatim-Dienst von OSM genommen (das liefert die im Beispiel oben sichtbaren Daten). Für alle anderen Dienste benötigt man eine Anmeldung oder einen API-Key. Außerdem sind die zurückgegebenen Felder nicht einheitlich - von der Google Maps API bekomme ich für den gleichen Punkt z.B. https://goo.gl/maps/qAi6dcLWrEp:

### Trackpoint START ###
name=TP2312
latitude=49.6079982
longitude=6.1368883
elevation=284.0
location=12 Bisserweg, 1238 Lëtzebuerg, Luxembourg
place_id=ChIJQ_L7Bc1IlUcRuvN-uDVlHwI
types=['street_address']
formatted_address=12 Bisserweg, 1238 Lëtzebuerg, Luxembourg
geometry={'viewport': {'northeast': {'lat': 49.6095529802915, 'lng': 6.138509680291502}, 'southwest': {'lat': 49.6068550197085, 'lng': 6.135811719708498}}, 'location': {'lat': 49.608204, 'lng': 6.1371607}, 'location_type': 'ROOFTOP'}
address_components=[{'short_name': '12', 'long_name': '12', 'types': ['street_number']}, {'short_name': 'Bisserweg', 'long_name': 'Bisserweg', 'types': ['route']}, {'short_name': 'Lëtzebuerg', 'long_name': 'Lëtzebuerg', 'types': ['locality', 'political']}, {'short_name': 'Lëtzebuerg', 'long_name': 'Lëtzebuerg', 'types': ['administrative_area_level_2', 'political']}, {'short_name': 'Distrikt Lëtzebuerg', 'long_name': 'Distrikt Lëtzebuerg', 'types': ['administrative_area_level_1', 'political']}, {'short_name': 'LU', 'long_name': 'Luxembourg', 'types': ['country', 'political']}, {'short_name': '1238', 'long_name': '1238', 'types': ['postal_code']}]
### Trackpoint END ###

gpsPhoto.pl --geoinfo=list
zip wikipedia geourl none osm geonames

Ich hatte mit gpsPhoto lange geonames verwendet und bin dann auf wikipedia umgestiegen, mittlerweile funktioniert beides nicht mehr. Bitte beachte, dass geonames einen User braucht. Kostenlose Registrierung bei http://www.geonames.org/login AFAIR sind die Abfragen pro Stunde beschränkt, ich erinnere mich dumpf, dass es irgendwas pro Stunde war und man bis zu Beginn der Stunde warten musste, wenn man zuviel abgefragt hat. Das erreiche ich Normalfall aber nicht, nur wenn ich mein Script testete und es irgendwo hakte.

Mit geopy sind die Informationen, die man von dem in geoinfo eingebauten GeoNames Modul bekommt, vergleichsweise dürftig:

[Location(Clausen, 03, LU, (49.61139, 6.13611, 0.0))]

- das originale xml sieht so aus - das reicht also nicht, wenn man die Straße haben möchte:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<geonames>
<geoname>
<toponymName>Earth</toponymName>
<name>Earth</name>
<lat>0</lat>
<lng>0</lng>
<geonameId>6295630</geonameId>
<countryCode/>
<countryName/>
<fcl>L</fcl>
<fcode>AREA</fcode>
</geoname>
<geoname>
<toponymName>Europe</toponymName>
<name>Europe</name>
<lat>48.69096</lat>
<lng>9.14062</lng>
<geonameId>6255148</geonameId>
<countryCode/>
<countryName/>
<fcl>L</fcl>
<fcode>CONT</fcode>
</geoname>
<geoname>
<toponymName>Grand Duchy of Luxembourg</toponymName>
<name>Luxembourg</name>
<lat>49.75</lat>
<lng>6.16667</lng>
<geonameId>2960313</geonameId>
<countryCode>LU</countryCode>
<countryName>Luxembourg</countryName>
<fcl>A</fcl>
<fcode>PCLI</fcode>
</geoname>
<geoname>
<toponymName>District de Luxembourg</toponymName>
<name>District de Luxembourg</name>
<lat>49.6278</lat>
<lng>6.09</lng>
<geonameId>2960314</geonameId>
<countryCode>LU</countryCode>
<countryName>Luxembourg</countryName>
<fcl>A</fcl>
<fcode>ADM1</fcode>
</geoname>
<geoname>
<toponymName>Luxembourg</toponymName>
<name>Luxembourg</name>
<lat>49.61167</lat>
<lng>6.13</lng>
<geonameId>2960316</geonameId>
<countryCode>LU</countryCode>
<countryName>Luxembourg</countryName>
<fcl>P</fcl>
<fcode>PPLC</fcode>
</geoname>
<geoname>
<toponymName>Clausen</toponymName>
<name>Clausen</name>
<lat>49.61139</lat>
<lng>6.13611</lng>
<geonameId>2960688</geonameId>
<countryCode>LU</countryCode>
<countryName>Luxembourg</countryName>
<fcl>P</fcl>
<fcode>PPLX</fcode>
</geoname>
</geonames>

Ich habe https://codeload.github.com/tkrajina/gpxpy/zip/master runtergeladen und bin da überhaupt nicht weitergekommen. In README.md sollte erklärt sein, wie man anfängt. Ich kenne mich mit Python nicht aus. Ein "make" brachte eine Reihe von Fehlermeldungen.

Eigentlich sollte das einfach über pip3 installierbar sein:

sudo apt-get install python3-pip
pip3 install --user gpxpy
pip3 install --user geopy

In den GPX-Daten werden Zeitstempel in UTC genutzt

Ich möchte es nicht zu kompliziert machen, aber es gibt Handy-Apps, die mit der Uhrzeit des Handys loggen. Insofern wäre ein Korrekturfaktor sinnvoll. So was ist mir schon lange nicht mehr untergekommen, habe aber schon damit gekämpft.

Wie sieht es bei den Daten aus der Kamera aus? Lässt du die mit Ortszeit laufen

Ich stelle normalerweise Ortszeit ein und zwar bei der "Hauptzeit" der Kamera. Einige Kameras haben 2 Zeiten und Sommerzeitkorrektur, aber nicht jede, also stelle ich die Zeit an der Kamera auf Ortszeit um. Entscheidend ist die Zeit, die dann im Exif steht.

Nicht existierende Felder bei den über geoinfo abgerufenen Daten würde ich dann in der Ausgabe einfach weglassen.

Darüber sollte man nachdenken, ob man nicht eine Option macht um leere Felder anzuzeigen. Es gibt "komplizierte" Adressen, zB nur mit Ort und Hausnummer danach und keiner Straße. Das Feld muss jedenfalls eindeutig zu erkennen sein und durch Weglassen darf es zu keinen Verwechslungen kommen.

Ich hätte den Neonatim-Dienst von OSM genommen

Damit habe ich noch keine Erfahrung, ich bin schon froh, wenn wenigstens der Ort stimmt. Im Grenzgebiet an einem sich windenden Fluß stimmt sogar oft das Land nicht,

Mit geopy sind die Informationen, die man von dem in geoinfo eingebauten GeoNames Modul bekommt, vergleichsweise dürftig

Ich wollte nur ein bißchen damit spielen, bin aber schon bei der Installation gescheitert.

Eigentlich sollte das einfach über pip3 installierbar sein

Die Installation lief durch, jetzt muss ich da weiter durchkämpfen 😉

glaskugel schrieb:

In den GPX-Daten werden Zeitstempel in UTC genutzt

Ich möchte es nicht zu kompliziert machen, aber es gibt Handy-Apps, die mit der Uhrzeit des Handys loggen. Insofern wäre ein Korrekturfaktor sinnvoll. So was ist mir schon lange nicht mehr untergekommen, habe aber schon damit gekämpft.

Man könnte anhand der GPS-Position die Zeitzone errechnen und als Lokalzeit interpretieren, falls der Timestamp keine Zeitzoneninformation enthält: https://pypi.python.org/pypi/tzwhere

Wie sieht es bei den Daten aus der Kamera aus? Lässt du die mit Ortszeit laufen

Ich stelle normalerweise Ortszeit ein und zwar bei der "Hauptzeit" der Kamera. Einige Kameras haben 2 Zeiten und Sommerzeitkorrektur, aber nicht jede, also stelle ich die Zeit an der Kamera auf Ortszeit um. Entscheidend ist die Zeit, die dann im Exif steht.

Das ist so ein bisschen ein Henne-Ei Problem - eigentlich kann man die Bilder ja erst dann sicher den Koordinaten zuordnen, wenn man sich auf die gleiche Zeitbasis geeinigt hat (idealerweise halt man intern alles als UTC-Timestamps) - daher wäre es IMHO sinnvoll die Zeitzone für die Bilder vorzugeben, wenn man nicht mit der Lokalzeit des Systems arbeiten will.

Nicht existierende Felder bei den über geoinfo abgerufenen Daten würde ich dann in der Ausgabe einfach weglassen.

Darüber sollte man nachdenken, ob man nicht eine Option macht um leere Felder anzuzeigen. Es gibt "komplizierte" Adressen, zB nur mit Ort und Hausnummer danach und keiner Straße. Das Feld muss jedenfalls eindeutig zu erkennen sein und durch Weglassen darf es zu keinen Verwechslungen kommen.

Ich kann entweder bestimmte Felder gezielt abfragen und wenn die nicht vorhanden sind z.B. einen leeren String für den Wert zurückgeben oder dynamisch alles ausgeben, was mir vom Server als Adresse geliefert wird - keine Ahnung, wie stabil die API in dem Fall ist.

Man könnte anhand der GPS-Position die Zeitzone errechnen und als Lokalzeit interpretieren

So stelle ich mir das vor. Ich habe noch in keinen Metadaten eines Fotos einen Hinweis auf die Zeitzone gefunden, nur in den Kameraeinstellungen. IMO sollte "0x9003 Date/Time Original" die Referenz sein. Meistens kann ich vermeiden Fotos bei Zeitzonenwechsel in 1 Ordner zu geben und dann hatte ich auch keine Probleme.

Das ist so ein bisschen ein Henne-Ei Problem - eigentlich kann man die Bilder ja erst dann sicher den Koordinaten zuordnen, wenn man sich auf die gleiche Zeitbasis geeinigt hat

Ich kenne da speziell Probleme bei Fotos mit Sommerzeit / Winterzeitwechsel. Workaround war Fotos nach dem Zeitwechsel in einen anderen Ordner zu geben. Vielleicht hatte da auch gpsPhoto ein Problem.

Lokalzeit des Systems?

Meinst du die Zeit vom PC? Die sollte IMO total nebensächlich sein. Mir geht es um folgendes Problem. Man fliegt zB nach Portugal, macht in D am Flughafen ein Foto und in Portugal am Flughafen wieder eines. Nehmen wir weiter an, im Flugzeug wurde die Zeit der Kamera über Portugal um 1h korrigiert, dann sollte die richtige Position zugeordnet werden, entweder automatisch oder durch eine manuelle Korrektur.

Ich kann entweder bestimmte Felder gezielt abfragen und wenn die nicht vorhanden sind z.B. einen leeren String für den Wert zurückgeben oder dynamisch alles ausgeben, was mir vom Server als Adresse geliefert wird - keine Ahnung, wie stabil die API in dem Fall ist.

Am besten wir probieren das. Interessant sind dann ja immer exotische Koordinaten in der Wüste oder in den Bergen fernab eines Ortes. Solange da ein Feldname davor steht, wird das kein Problem sein. Problem ist, wenn zB einmal das 3. Feld die Stadt ist und dann das 2. AFAIR hatte ich da bei geonames manchmal Probleme.

glaskugel schrieb:

Man könnte anhand der GPS-Position die Zeitzone errechnen und als Lokalzeit interpretieren

So stelle ich mir das vor. Ich habe noch in keinen Metadaten eines Fotos einen Hinweis auf die Zeitzone gefunden, nur in den Kameraeinstellungen. IMO sollte "0x9003 Date/Time Original" die Referenz sein. Meistens kann ich vermeiden Fotos bei Zeitzonenwechsel in 1 Ordner zu geben und dann hatte ich auch keine Probleme.

Das geht nicht, weil die Efix-Informationen keine Zeitzoneninformationen abbilden, sondern nur mit Lokalzeit arbeiten - wenn man sich das automatische Tagging vereinfachen will, kann man die Uhr der Kamera auf UTC stellen, dann muss das Programm nur wissen, dass es sich um UTC handelt, sonst muss es die Zeitzone kennen - ein Timestamp ohne Zeitzoneninformationen wird immer in Lokalzeit des System interpretiert (ausgenommen Unix-Timestamps, die liegen als Sekunden ab 01.01.1970 0:0 Uhr UTC vor).

Alternativ können natürlich auch der Timestamp des GPS-Trackers und der der Kamera in Lokalzeit der gleichen Zeitzone vorliegen - aber die Beispieldatei, die du gepostet hast, hatte UTC-Timestamps.

Oder man errechnet aus dem UTC-Timestamp der GPX-Daten die Lokalzeit und vergleicht das dann mit den Zeitstempeln aus den Exif-Informationen - das hat aber den Nachteil, dass die Lokalzeit nicht stetig verläuft und es Doppelungen geben kann, die zu fehlerhafte Zuordnungen führen können - wenn du dich z.B. aus der MESZ in ein Land mit WESZ bewegst (z.B. von Spanien nach Portugal oder von Frankreich nach England), dann hast du einen Zeitsprung von einer Stunde, was bei den kurzen Reisezeiten dazu führen kann, dass zwei Bilder bzw. GPS-Trackpooints ähnliche Lokalzeiten haben, obwohl sie absolut gesehen eine Stunde auseinander liegen.