ubuntuusers.de

das hat aber den Nachteil, dass die Lokalzeit nicht stetig verläuft und es Doppelungen geben kann,

Das habe ich mir mittlerweile auch überlegt und daher denke ich, dass man es primär simpel halten soll. Ich habe mir überlegt, man könnte die GPX-Datei analysieren und die Zeit für die Überschreitung eines Landes bestimmen, man müsste also sagen können, war von bis in D, von bis in F, von bis in P, etc. Aber letztlich ist das nicht so wichtig, ich wollte nur die Probleme aufzeigen, die ich bisher hatte und offensichtlich ist das auch nicht so einfach zu lösen.

glaskugel schrieb:

das hat aber den Nachteil, dass die Lokalzeit nicht stetig verläuft und es Doppelungen geben kann,

Das habe ich mir mittlerweile auch überlegt und daher denke ich, dass man es primär simpel halten soll. Ich habe mir überlegt, man könnte die GPX-Datei analysieren und die Zeit für die Überschreitung eines Landes bestimmen, man müsste also sagen können, war von bis in D, von bis in F, von bis in P, etc.

Aber man kann es aus den Metadaten der Bilder nicht sicher rekonstruieren, wo ein Bild aufgenommen wurde, wenn es keine Informationen zur Zeitzone für die Bilder gibt und man nur anhand der jeweiligen Lokalzeit einen Abgleich mit den GPS-Trackpoints macht. Das löst dann die Folgeprobleme aus, die du schon beschrieben hast.

und offensichtlich ist das auch nicht so einfach zu lösen.

Es ist sehr einfach zu lösen, wenn die Kamera immer in UTC lauft und man aus den GPX-Daten UTC-Timestamps bekommt (alles andere ist eh blödsinnig, weil GPS ohne eine koordinierte weltweit gültige Zeitinformation, aus der der Emfpfänger die UTC errechnen kann, nicht funktionieren würde). Sonst muss man sich um Zeitzonen, Sommer-/Winterzeit usw. kümmern - und das kann man allein mit den Exif-Informationen nicht zuverlässig automatisieren. Irgendwoher muss zumindest die Zeitzone bekannt sein, auf die die Kamera zu dem Zeitpunkt eingestellt war (Koordinaten bzw. Land genügen eigentlich auch nicht, da ist die absolute Zeit beim Wechsel von Sommer- auf Winterzeit zwischen 2 und 3 Uhr nicht eindeutig, ohne z.B. zu wissen, ob es noch MESZ oder schon MEZ war), sonst kann man die Daten nicht in allen Fällen sauber zuordnen.

Du hast logisch gesehen bzgl. UTC völlig recht. Für mich dürfte es trotzdem aus "anderen Überlegungen" so wie bisher die einfachere Variante sein, einfach bei Zeitwechsel unterschiedliche Ordner mit lokaler Zeit zu verwenden. Ein Umsteig auf UTC hätte Auswirkungen, die ich nicht abschätzen kann.

Ok, dann machen wir es mit Umrechnung der GPS-Timestamps in Lokalzeit. Ich habe mal in den Code von gpxpy geschaut, da wird die Information, dass es UTC-Timestamps in der .gpx Datei sind, einfach ignoriert und alles ohne Zeitzoneninformationen ausgelesen 👿
Ich würde die GPS-Timestamps standardmäßig als UTC interpretieren und in Lokalzeitumrechnen - wenn man von etwas anderem als UTC ausgehen will, kann man das dem Skript als Startargument (--tzname) über einen Zeitzonen-Namen wie z.B. "Europe/Berlin" mitgeben.

Da das ermitteln der Zeitzonen aus den Koordinaten relativ rechenintensiv ist, würde ich mit einer Cache-Datei arbeiten, die neu erstellt wird, wenn die md5-Summe der gpx-Datei nicht zum Wert aus dem Cache passt oder die Cache-Datei noch nicht existiert. Dadurch dauert nur der erste Aufruf pro gpx-Datei länger.

Wenn du eigene Ordner pro Lokalzeit hast, dürfte das Matchen dann recht einfach sein.

Die Argumente, die man dem Skript aktuell mitgeben kann, sehen so aus:

$ ./geoinfo.py -h
usage: geoinfo.py [-h] [--tzname TZ] [--timedelta DELTA]
                  GPXFILE IMAGE [IMAGE ...]

match EXIF DateTimeOriginal field with trackpints from a gpx file and return
geoinformation with OSM data for the picture

positional arguments:
  GPXFILE               gpx file with trackpoints
  IMAGE                 image file(s) with DateTimeOriginal exif data

optional arguments:
  -h, --help            show this help message and exit
  --tzname TZ, -t TZ    timezone for gps timestamps (default='UTC')
  --timedelta DELTA, -d DELTA
                        maximum allowed timedelta between timestamps in
                        seconds to match (default: 3600 s)

Ein Aufruf liefert dann z.B.:

$ ./geoinfo.py -d 3600 test.gpx 20081017-0002.jpg 
trying to open test.cache
loaded cache file
minimum timedelta: 0:00:49
### POINT START ###
name=TP3176
latitude=48.131771
longitude=11.588551
elevation=504.0
time=2008-10-17 19:04:49
timezone_name=Europe/Berlin
location=Müllersches Volksbad, 1, Rosenheimer Straße, Bezirksteil Maximilianeum, Stadtbezirk 05 Au-Haidhausen, München, OB, Bayern, 81667, Deutschland
licence=Data © OpenStreetMap contributors, ODbL 1.0. http://www.openstreetmap.org/copyright
country_code=de
country=Deutschland
state=Bayern
state_district=OB
county=
postcode=81667
city=München
suburb=Bezirksteil Maximilianeum
city_district=Stadtbezirk 05 Au-Haidhausen
neighbourhood=
road=
pedestrian=
address29=
path=Rosenheimer Straße
house_number=1
townhall=
ruins=
attraction=Müllersches Volksbad
unused attributes: 
### POINT END ###

Falls du noch spezielle Wünsche für die Formatierung der Ausgabe hast, wäre jetzt der richtige Zeitpunkt dafür. Ansonsten würde ich den Code noch aufräumen und auf einer frischen Ubuntu 14.04 Installation ausprobieren, was man da so alles an Paketen und zusätzlichen Python-Modulen benötigt, bevor ich das Skript poste.

Ich würde die GPS-Timestamps standardmäßig als UTC interpretieren und in Lokalzeitumrechnen

Vorsichtshalber die Frage, die (automatische) Lokalzeit ergibt sich woraus? Ich verstehe die Logik noch nicht ganz. Also PC ist in D und es geht um zB portugiesische Fotos, wobei die Annahme getroffen ist, dass alle Fotos im Ordner die gleiche lokale Zeit betreffen. Vielleicht magst du auch mal schauen wie das bei http://www.carto.net/projects/photoTools/gpsPhoto/#softwareDownload gelöst wurde.

Da das ermitteln der Zeitzonen aus den Koordinaten relativ rechenintensiv ist, würde ich mit einer Cache-Datei arbeiten

Ok, sehe da kein Problem.

Falls du noch spezielle Wünsche für die Formatierung der Ausgabe hast, wäre jetzt der richtige Zeitpunkt dafür

Hmmh, sieht ganz ok aus. Ich frage mich gerade, ob man das Ende durch einen Delimiter kennzeichnen soll. Ich bin mir nicht sicher, ob ein 2. = zu Problemen führen könnte.

Ich nehme mal an, dass ich die Ausgabe aus dem Python-Skript in einer Variable "out" habe.

Dann könnte man folgendes machen:

staat=`echo "$out" | grep "state="`

So würde ich mir dann alle Variablen holen, die ich brauche.

und auf einer frischen Ubuntu 14.04 Installation ausprobieren, was man da so alles an Paketen und zusätzlichen Python-Modulen benötigt, bevor ich das Skript poste

Das ist aber mühsam, Respekt, dass du dir das antust. Ich habe gestaunt, was ich noch für "python3-pip" dazu instllieren musste, denn meine Pakete sind über Jahre notiert und da muss ich sonst kaum was nachinstallieren.

Ich freu mich schon zu testen! Danke!

glaskugel schrieb:

Ich würde die GPS-Timestamps standardmäßig als UTC interpretieren und in Lokalzeitumrechnen

Vorsichtshalber die Frage, die (automatische) Lokalzeit ergibt sich woraus? Ich verstehe die Logik noch nicht ganz. Also PC ist in D und es geht um zB portugiesische Fotos, wobei die Annahme getroffen ist, dass alle Fotos im Ordner die gleiche lokale Zeit betreffen. Vielleicht magst du auch mal schauen wie das bei http://www.carto.net/projects/photoTools/gpsPhoto/#softwareDownload gelöst wurde.

Lange Perl-Skripte (das originale Skript hat über 4000 Zeilen) sehe ich eigentlich als write-only an... - aber es sieht so aus, als hätten die eine ähnliche Idee gehabt.

Um das nochmal auszuführen - ich gehe davon aus, dass die Zeitzone der Timestamps in den GPS-Trackpoints bekannt ist (normalerweise UTC, falls die abweicht kann man das als Argument angeben). Dann erstelle ich für jeden Punkt in den Tracks ein Zeit-Objekt mit dieser Zeitzonen-Information. Aus den Koordinaten hole ich mir mit dem früher verlinkten tzwhere den Namen der Zeitzone, in der der Punkt liegt und wandle den Timestamp in diese Zeitzone um. Damit sollte ich einen Timestamp in Lokalzeit haben, den ich mit den Timestamps aus den Bildern vergleichen kann, die ja auch jeweils in Lokalzeit vorliegen sollten.

Ich frage mich gerade, ob man das Ende durch einen Delimiter kennzeichnen soll. Ich bin mir nicht sicher, ob ein 2. = zu Problemen führen könnte.

Das verstehe ich nicht ganz - was genau braucht einen Delimiter? Die einzelne Zeile hat ein Zeilenende und die Ausgabe für einen Treffer aktuell ein "### POINT END ###" (wobei man das natürlich beliebig anpassen kann)

Ich nehme mal an, dass ich die Ausgabe aus dem Python-Skript in einer Variable "out" habe.

Dann könnte man folgendes machen:

staat=`echo "$out" | grep "state="`

Wäre da so etwas nicht praktischer, um den String zu extrahieren und der Variable zuzuweisen (nachdem ich jetzt gerade durch viele Zeilen Perl mit vielen Regulären Ausdrücken gescrollt habe, drängt sich das ja geradezu auf da ein Lookbehind zu nutzen 😉)?

1

staat=$(grep -Po "(?<=^state=).*$" <<< $out)

und auf einer frischen Ubuntu 14.04 Installation ausprobieren, was man da so alles an Paketen und zusätzlichen Python-Modulen benötigt, bevor ich das Skript poste

Das ist aber mühsam, Respekt, dass du dir das antust. Ich habe gestaunt, was ich noch für "python3-pip" dazu instllieren musste, denn meine Pakete sind über Jahre notiert und da muss ich sonst kaum was nachinstallieren.

Bei Ubuntu 16.04 ist Python3 schon standardmäßig dabei, dadurch fällt die Liste deutlich kürzer aus. Jetzt noch Software für Python2 zu schreiben bringt absehbare Probleme in ein paar Jahren, wenn das nicht mehr gepflegt wird: https://pythonclock.org/

Das verstehe ich nicht ganz - was genau braucht einen Delimiter?

Bin mir ja auch unsicher, ob es Sinn macht. Manchmal gibt es Fehler in der Datenbank, da könnte dann am Ende zB "Deutschland " stehen, also am Ende ein Leerzeichen sein. Wird kaum bei Deutschland sein, aber bei irgendwas Exotischem nach meiner Erfahrung möglich. Ich habe das dann mit einem Sed-Konstrukt abgesichert. Wenn da irgendein sichtbares Zeichen am Ende ist, würde man das sofort erkennen. Mein Bash-Script ist über 10 Jahre gewachsen, aber es funktioniert, obwohl es programmtechnisch grausam ist, weil da immer wieder Workarounds zu Dingen kamen, die ursprünglich nicht geplant waren. So ein Leerzeichen am Ende bzw. Anfang eines Feldes hatte schon zu Chaos in meinem Script geführt.

Auf jeden Fall brauche ich was um den Feldnamen vom Inhalt zu trennen und das ist offensichtlich im Beispiel =

Wäre da so etwas nicht praktischer, um den String zu extrahieren und der Variable zuzuweisen

Mag sein, mein ganzes Script wäre besser in Perl, aber so wie es ist, kann ich mich verlassen, dass es passt und es sind über 10000 Zeilen Code für alles mögliche, vieles davon nicht mehr genutzt. Zeit spielt nicht so die Rolle dabei. Ich versuche da nur wenn es gar nicht anders geht was anderes als Bash-Befehle zu nehmen. Ob dann Perl oder Python ist aber dann egal.

Jetzt noch Software für Python2 zu schreiben bringt absehbare Probleme

Ja klar, es ist auch kein Problem ein paar Pakete zu Python 3 zu installieren. Jetzt verstehe ich warum da so viel nachinstalliert wurde.

Ich denke am besten ich probiere dann.

Ich bin schon gespannt, was diese Koordinaten-Beispiele mit OSM bringen und in welcher Sprache

35.0989709,24.6888069 (Kreta), 27.1764481,33.7230069 (Ägypten), 48.1548109,12.8273597 (Deutschland oder Österreich?)

glaskugel schrieb:

Wäre da so etwas nicht praktischer, um den String zu extrahieren und der Variable zuzuweisen

Mag sein, mein ganzes Script wäre besser in Perl, aber so wie es ist, kann ich mich verlassen, dass es passt und es sind über 10000 Zeilen Code für alles mögliche, vieles davon nicht mehr genutzt. Zeit spielt nicht so die Rolle dabei. Ich versuche da nur wenn es gar nicht anders geht was anderes als Bash-Befehle zu nehmen. Ob dann Perl oder Python ist aber dann egal.

Das ist ja ein ganz braver Bash-Befehl, der PCRE für grep anschaltet 😉

35.0989709,24.6888069 (Kreta), 27.1764481,33.7230069 (Ägypten), 48.1548109,12.8273597 (Deutschland oder Österreich?)

Mal die Kurzfassung aus der Python-Shell, weil das Skript auf einem anderen Rechner ist:

1
2
3
4
5
6
7
8

>>> from geopy.geocoders import Nominatim
>>> g = Nominatim()
>>> g.reverse("35.0989709,24.6888069")
Location(Τυμπάκι - Αγία Γαλήνη, Αγία Γαλήνη, Δήμος Αγίου Βασιλείου, Περιφερειακή Ενότητα Ρεθύμνου, Περιφέρεια Κρήτης, Αποκεντρωμένη Διοίκηση Κρήτης, 74056, Ελλάδα, (35.0992668, 24.6905117, 0.0))
>>> g.reverse("27.1764481,33.7230069")
Location(الغردقة, البحر الأحممر, Egypt مصر, (27.2405016, 33.8267842, 0.0))
>>> g.reverse("48.1548109,12.8273597")
Location(269, Mautnerstraße, Burghausen, Landkreis Altötting, OB, Bayern, 84489, Deutschland, (48.15491535, 12.8274126738414, 0.0))

Edit:

So sieht es mit Details aus:

 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
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96

>>> geoinfo.get_osm_data(geolocator.reverse("35.0989709,24.6888069"))
### POINT START ###
name=
latitude=35.0992668
longitude=24.6905117
elevation=
time=
timezone_name=
location=Hotel Sky Beach, Τυμπάκι - Αγία Γαλήνη, Αγία Γαλήνη, Δήμος Αγίου Βασιλείου, Περιφερειακή Ενότητα Ρεθύμνου, Περιφέρεια Κρήτης, Αποκεντρωμένη Διοίκηση Κρήτης, 74056, Ελλάδα
licence=Data © OpenStreetMap contributors, ODbL 1.0. http://www.openstreetmap.org/copyright
country_code=gr
country=Ελλάδα
state=Αποκεντρωμένη Διοίκηση Κρήτης
state_district=Περιφέρεια Κρήτης
county=Δήμος Αγίου Βασιλείου
postcode=74056
city=
town=Αγία Γαλήνη
suburb=
city_district=
neighbourhood=
road=Τυμπάκι - Αγία Γαλήνη
pedestrian=
address29=
path=
house_number=
townhall=
ruins=
attraction=
hotel=Hotel Sky Beach
unused attributes: 
### POINT END ###
>>> geoinfo.get_osm_data(geolocator.reverse("27.1764481,33.7230069"))
### POINT START ###
name=
latitude=27.2405016
longitude=33.8267842
elevation=
time=
timezone_name=
location=الغردقة, شارع الكهف, الحرية 8, الغردقة, البحر الأحممر, Egypt مصر
licence=Data © OpenStreetMap contributors, ODbL 1.0. http://www.openstreetmap.org/copyright
country_code=eg
country=Egypt مصر
state=البحر الأحممر
state_district=
county=
postcode=
city=الغردقة
town=
suburb=
city_district=
neighbourhood=الحرية 8
road=شارع الكهف
pedestrian=
address29=الغردقة
path=
house_number=
townhall=
ruins=
attraction=
hotel=
unused attributes:
### POINT END ###
>>> geoinfo.get_osm_data(geolocator.reverse("48.1548109,12.8273597"))
### POINT START ###
name=
latitude=48.15491535
longitude=12.8274126738414
elevation=
time=
timezone_name=
location=269, Mautnerstraße, Burghausen, Landkreis Altötting, OB, Bayern, 84489, Deutschland
licence=Data © OpenStreetMap contributors, ODbL 1.0. http://www.openstreetmap.org/copyright
country_code=de
country=Deutschland
state=Bayern
state_district=OB
county=Landkreis Altötting
postcode=84489
city=
town=Burghausen
suburb=
city_district=
neighbourhood=
road=Mautnerstraße
pedestrian=
address29=
path=
house_number=269
townhall=
ruins=
attraction=
hotel=
unused attributes:
### POINT END ###

Danke! Also das mit Burghausen sieht schon mal gut aus. Gibt es eine Möglichkeit nicht lateinische Schrift mit lateinischen Namen auszugeben, also zB Hurghada statt الغردقة

Ich muss mal später schauen, ob man über die API von Geonames oder Google Maps da etwas passendes bekommt - aber ich vermute, dass das hauptsächlich für größere Städte funktioniert und bei Straßennamen beißt es vermutlich sowieso aus...

Ich wollte einfach nur fragen, und wenn es da was gibt, bitte als Option anbieten. Mir geht es dabei vorwiegend um das Land, Bundesland und die Stadt. Bei mir hält sich das in Grenzen und ich habe mir da mit sed was gebaut, das die arabischen Zeichen entsprechend ersetzt. Wie schon geschrieben, mein Script besteht aus Workarounds 😉

Man kann der OSM-Abfrage noch eine bevorzugte Sprache mitgeben - ich habe die Möglichkeit für ein Startargument hinzugefügt, mit der man die bevorzugte Sprache als Länderkürzel angeben kann, für deutsch also z.B. "-l de", falls das nicht gesetzt ist, bekommt man die lokalen Namen:

$ python3 geoinfo.py -lde test.gpx 20081017-3.jpg 
trying to open test.cache
loaded cache file
minimum timedelta: 0:00:38
### POINT START ###
name=TP3178
latitude=27.1764481
longitude=33.7230069
elevation=504.0
time=2008-10-17 19:04:38
timezone_name=Africa/Cairo
location=Hurghada, Rotes Meer, Ägypten
licence=Data © OpenStreetMap contributors, ODbL 1.0. http://www.openstreetmap.org/copyright
country_code=eg
country=Ägypten
state=Rotes Meer
state_district=
county=
postcode=
city=Hurghada
town=
suburb=
city_district=
neighbourhood=
road=
pedestrian=
address29=
path=
house_number=
townhall=
ruins=
attraction=
hotel=
unused attributes: 

### POINT END ###

Die benötigten Abhängigkeiten für Ubuntu kann man so installieren:

1
2
3
4
5

sudo apt-get install python3-pip python3-numpy python3-shapely python3-tz
pip3 install --user geopy
pip3 install --user gpxpy
pip3 install --user exifread
pip3 install --user tzwhere

Das Skript geoinfo.py ist angehängt (als tar gepackt, weil die Forensoftware aus irgendeinem Grund die Endung .py in .java ändert). Ich bin gespannt, wie das mit deinen Datensätzen klappt.

Vielen Dank und sieht gut aus.

Ich hätte da gerne noch die Option, dass man den Pfad zum Cache angeben kann. Es kann nämlich passieren, dass der Ordner mit der gpx-Datei keine Schreibrechte hat. Hintergrund, Familienmitglieder haben für bestimmte Ordner nur Leserechte um nicht irrtümlich was löschen zu können.

creating cache file...
successfully created cache file
minimum timedelta: 0:00:11
### POINT START ###
name=TP2639
latitude=49.6100383
longitude=6.1404299
elevation=273.0
time=2016-05-27 12:58:06
timezone_name=Europe/Luxembourg
location=Batterie du Rham, Rue de Trèves, Grund, Luxembourg, Canton Luxembourg, 2427, Lëtzebuerg
licence=Data © OpenStreetMap contributors, ODbL 1.0. http://www.openstreetmap.org/copyright
country_code=lu
country=Lëtzebuerg
state=
state_district=
county=Canton Luxembourg
postcode=2427
city=Luxembourg
town=
suburb=Grund
city_district=
neighbourhood=
road=Rue de Trèves
pedestrian=
address29=
path=
house_number=
townhall=
ruins=
attraction=
hotel=
unused attributes: castle

### POINT END ###

Was ist timedelta?

country_code=lu

Kannst du das auch 3stellig ausgeben? (Das ist der 1. Unterschied zu meinen bisherigen Angaben). Vgl. http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/list-en1.html

Nur interessehalber, kommt "name=TP2639" aus meiner gpx-Datei?

Ansonsten muss ich jetzt mein Script anpassen, um Details zu testen und das wird sicher einige Zeit dauern bis ich da über 10000 Zeilen durchsuche und anpasse. Ich suche mal nach gpsPhoto und in der Gegend darum herum. Ich denke, Probleme werden aber kaum mit deinem Script zusammenhängen, sondern eher mit dem was OSM ausgibt.

Ich kenne mich mit Python nicht aus. Kann man das "allgemeiner" machen, also ohne, dass man da User anlegt und einfach eine Datei haben, die dann ausführbar ist? Ist nicht ein großes Problem, für mehrere PCs und mehrere User kommt da einiges zusammen.

Also die Option -lde ist super!

Aber die 1. Probleme mit OSM sind bereits aufgetreten.

successfully created cache file
minimum timedelta: 0:00:04
### POINT START ###
name=None
latitude=48.620984942
longitude=14.308222747
elevation=608.152771
time=2016-08-27 12:45:13
timezone_name=Europe/Prague
location=Poštovní muzeum, Míru, Hohenfurth, Bezirk Böhmisch Krumau, Südböhmische Region, Südwesten, 38273, Tschechien
licence=Data © OpenStreetMap contributors, ODbL 1.0. http://www.openstreetmap.org/copyright
country_code=cz
country=Tschechien
state=Südwesten
state_district=
county=Bezirk Böhmisch Krumau
postcode=38273
city=
town=
suburb=Hohenfurth
city_district=
neighbourhood=
road=Míru
pedestrian=
address29=
path=
house_number=
townhall=
ruins=
attraction=
hotel=
unused attributes: village museum

### POINT END ###

bzw.

### POINT START ###
name=None
latitude=48.620984942
longitude=14.308222747
elevation=608.152771
time=2016-08-27 12:45:13
timezone_name=Europe/Prague
location=Poštovní muzeum, Míru, Vyšší Brod, okres Český Krumlov, Jihočeský kraj, Jihozápad, 38273, Česko
licence=Data © OpenStreetMap contributors, ODbL 1.0. http://www.openstreetmap.org/copyright
country_code=cz
country=Česko
state=Jihozápad
state_district=
county=okres Český Krumlov
postcode=38273
city=
town=
suburb=Vyšší Brod
city_district=
neighbourhood=
road=Míru
pedestrian=
address29=
path=
house_number=
townhall=
ruins=
attraction=
hotel=
unused attributes: village museum

### POINT END ###

Der Ort ergäbe sich aus "suburb=Hohenfurth" bzw. "suburb=Vyšší Brod" Die Unterscheidung in city, town, suburb kann ich nicht nachvollziehen.