Posts: 2
Threads: 1
Joined: Sep 2008
14.09.2008, 22:20
(This post was last modified: 14.09.2008, 22:21 by rcvf.)
Hallo,
beim konvertieren von gpx nach nmea werden die originalen UTC-Zeiten als UTC+2 angezeigt (das ist o.k.) aber auch als UTC+2 gespeichert (das ist falsch).
Verwende Version 1.21
rcvf
Posts: 7,419
Threads: 223
Joined: Aug 2007
Hallo rcf,
ich habe das hier mit einem Track ausprobiert und da wurde aus
<wpt lon="13.4115129" lat="52.5202079">
<time>2007-11-22T09:45:10.000+01:00</time>
<name>Position 1</name>
</wpt>
in der NMEA Datei
$GPGGA,094510.000,5231.2125,N,01324.6908,E,1,,,0.0,M,,M,,*67
$GPWPL,5231.2125,N,01324.6908,E,Position 1*61
$GPRMC,094510.000,A,5231.2125,N,01324.6908,E,,,221107,,A*4E
$GPZDA,094510.000,22,11,07,,*58
Ich fürchte, NMEA-Dateien sind immer in UTC gespeichert, oder?
--
Christian
Posts: 2
Threads: 1
Joined: Sep 2008
15.09.2008, 20:21
(This post was last modified: 15.09.2008, 20:28 by rcvf.)
Nach meinem "angelesenen" Wissen sollten die Zeiten immer UTC sein. Sämtliche Umrechnungen (Zeitzonen bzw. Sommerzeit) werden durch die Software durchgeführt, die die Daten verarbeitet.
Mein Beispiel als Ergänzung:
GPX:
<?xml version="1.0"?>
<gpx
version="1.0"
creator="Holux Utility"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.topografix.com/GPX/1/0"
xsi:schemaLocation="http://www.topografix.com/GPX/1/0 http://www.topografix.com/GPX/1/0/gpx.xsd">
<wpt lat="53.480267" lon="12.429535">
<time>2008-09-05T15:32:42Z</time>
<ele>110.02</ele>
<name><![CDATA[Point 0]]></name>
</wpt>
NMEA:
$GPGGA,173242.000,5328.8161,N,01225.7722,E,1,,,110.02,M,,M,,*59
$GPWPL,5328.8161,N,01225.7722,E,Point 0*11
$GPRMC,173242.000,A,5328.8161,N,01225.7722,E,,,050908,,A*41
$GPZDA,173242.000,05,09,08,,*53
rcvf
Posts: 7,419
Threads: 223
Joined: Aug 2007
rcvf Wrote:Nach meinem "angelesenen" Wissen sollten die Zeiten immer UTC sein. Sämtliche Umrechnungen (Zeitzonen bzw. Sommerzeit) werden durch die Software durchgeführt, die die Daten verarbeitet.
[..]
Es gibt da eine Emaildiskussion, die ich gerne hier weiterführen möchte:
(Ich hoffe, Englisch ist kein Problem für Dich?)
I've just thought about it for a while and came to a problem:
Currently I do not interpret times in any way, i.e. the same
date+time from files is visible in the user interface and
written into the converted file.
If I have to convert date+time for GPX and NMEA from UTC:
- Would you expect UTC times in the user interface?
- Or local times?
- Or an attached timezone? (Makes the UI more complicated and leads to width problems).
What do you think?
--
Christian
Posts: 1
Threads: 0
Joined: Nov 2008
Eigentlich ist es mir fast egal, was ich im Benutzerinterface sehe, viel wichtiger ist, dass es korrekt konvertiert wird. Und das ist hier leider nicht der Fall, womit das Programm ziemlich nutzlos wird, wenn man die exakte Zeit etwa für's Geotagging braucht. Schade eigentlich.
Und eigentlich ist es ganz einfach. In NMEA wird keine Zeitzone angegeben, weil da einfach die Universalzeit gespeichert wird (also UTC), die auf der ganzen Welt gleich ist. So gesehen machen die es sich einfach.
Andere GPS-Formate nutzen das ISO-Zeitformat mit Angabe der Zeitzone. Das ist aber auch nicht weiter tragisch, denn die wird ja angegeben. Jetzt muss man nur noch richtig rechnen. Angegeben wird der Versatz zur Universalzeit. Wenn man also auf Universalzeit umrechnen will, muss man den Versatz abziehen:
10:00:00+02:00 entspricht also 8:00:00 in Universalzeit.
Auch das ISO-Zeitformat kann Universalzeit angeben, und zwar entweder so
10:00:00+00:00
oder so
10:00:00Z
Da muss man natürlich nicht umrechnen.
Im wpt-Beispiel sollte also 1 abgezogen werden, im gpx-Beispiel sollte gar nichts verändert werden. Warum da 2 hinzugezählt wird, kann ich mir nur so erklären, dass die lokale Zeitzone des Computers berücksichtigt wurde, die ja nun gar nichts damit zu tun hat.
Im Benutzerinterface sollte meiner Ansicht nach, wenn eine Zeitzone gespeichert ist, die Zeit auch in dieser Zeitzone angezeigt werden. Schließlich will ich wissen, wann ich diesen Aussichtspunkt in lokaler Zeit erreicht hatte. Ist keine Zeitzone gespeichert, sollte davon ausgegangen werden, dass das Universalzeit sein soll. Und das sollte im Userinterface gekennzeichnet sein. Unsinn wäre, es jetzt in die Zeitzone des Computers umzurechnen, zumindest wenn man seinen Urlaub in einer anderen Zeitzone verbracht hat.
Ansonsten gefällt mir das Programm richtig gut. Besonders das Userinterface.
Posts: 7,419
Threads: 223
Joined: Aug 2007
axel.scheithauer Wrote:Und eigentlich ist es ganz einfach.
Leider ist es das nicht. Ich finde keinen Weg, um die per JAXB-geparsten Datumsangaben als GTM-Calendar zu bekommen, das wird irgendwo immer ein lokaler Calendar. Prökel da schon 2 Stunden dran rum...
axel.scheithauer Wrote:Ansonsten gefällt mir das Programm richtig gut. Besonders das Userinterface.
Danke.
--
Christian
Posts: 7,419
Threads: 223
Joined: Aug 2007
Für Leute, die dasselbe Problem haben: XmlNavigationFormat#parseTime() und XmlNavigationFormat#formatTime() sorgen nun für "keine Zeitzone" was implizit GMT+0 ist.
Für Leute, die Probleme mit RouteConverter und vermurksten Zeiten haben: Bitte probiert die aktuelle Prerelease 1.22.7 aus. Funktioniert das für Euch?
--
Christian
|