Inkonsistente Zeitstempel

[lundefugl]

Hallo,

Wenn man von Hand Punkte in einen aufgezeichneten Track hinzufügt, so wird automatisch ein passender Zeitstempel hinzugefügt. Verschiebt man diese Punkte (z.B. weil wie bei mir am Anfang der Logger noch nichts aufgezeichnet hat), so bleiben diese Zeitstempel natürlich erhalten, aber sind nicht mehr konsistent.

Bis jetzt ist mir das bei GPX-Tracks mir nie richtig aufegfallen. Es macht allerdings Probleme, wenn man es mit Google Earth anzeigen will. Google Earth kann GPX und auch Kmz-Files problemlos lesen und importieren, aber es zeigt dann einfach keine Linie an. Es gibt dann auch keinen Hinweis.

Aus meiner Sicht wäre es daher schön, wenn man irgendwie solche Fehler leicht im RC erkennen könnte. Für das Wie habe ich im Moment auch keine richtige Idee. Evtl. gibts ja noch andere Fehler, die man über einfache Plausitests erkennen könnte.

Gruß
Thomas

[routeconverter]

Wenn man von Hand Punkte in einen aufgezeichneten Track hinzufügt, so wird automatisch ein passender Zeitstempel hinzugefügt. Verschiebt man diese Punkte (z.B. weil wie bei mir am Anfang der Logger noch nichts aufgezeichnet hat), so bleiben diese Zeitstempel natürlich erhalten, aber sind nicht mehr konsistent.

Du könntest zwei versteckte Optionen nutzen: cleanTimeOnMove löscht die Zeit, complementTimeOnMove versucht eine neue Zeit zu setzen.

Aus meiner Sicht wäre es daher schön, wenn man irgendwie solche Fehler leicht im RC erkennen könnte. Für das Wie habe ich im Moment auch keine richtige Idee. Evtl. gibts ja noch andere Fehler, die man über einfache Plausitests erkennen könnte.

Wie müßte solch ein Test denn aussehen? Oder andersherum: was bringt Google Earth denn durcheinander?

[lundefugl]

Hallo Christian,

Du könntest zwei versteckte Optionen nutzen: cleanTimeOnMove löscht die Zeit, complementTimeOnMove versucht eine neue Zeit zu setzen.

danke für den Tipp, werde ich ausprobieren, wenn ich wieder zu Hause bin. Klingt auf jeden Fall so, als würde es mein Problem lösen.

Wie müßte solch ein Test denn aussehen? Oder andersherum: was bringt Google Earth denn durcheinander?

Ich vermute mal, dass es der Rückwärtssprung der Zeit ist. D.h. die ersten beiden Punkte hatten einen Zeitstempel, der später war, als die Folgenden. Als ich die Zeitstempel von Hand einfach davor gesetzt hatte, hat Google Earth eine Linie gemalt. Witzigerweise scheint es nur die Linie zu betreffen. Aktiviert man die Label-Anzeige bei Google Earth (was bei aufgezeichneten Tracks nicht gerade sinnvoll ist), so erscheinen die Stecknadeln mit den Texten.

Wenn ich mich recht erinnere, ist Google Earth nicht das einzigste Programm, was damit nicht umgehen kann. Ich meine GpsBabel hat das auch nicht gewollt, aber da gab es eine aussagekräftige Fehlermeldung auf der Konsole.
Da ich das Programm inzwischen nicht mehr nutze (der RC kann den File-Merge unter Beibehaltung aller Tracks), hatte ich das bis jetzt nie gemerkt, dass Google Earth damit auch Probleme hat.

Gruß
Thomas

[lundefugl]

Hallo Christian,

Du könntest zwei versteckte Optionen nutzen: cleanTimeOnMove löscht die Zeit, complementTimeOnMove versucht eine neue Zeit zu setzen.

danke für den Tipp, werde ich ausprobieren, wenn ich wieder zu Hause bin. Klingt auf jeden Fall so, als würde es mein Problem lösen.

Ich bin leider erst jetzt zum ausprobieren gekommen.
Die Optionen funktionieren doch nicht ganz so, wie ich mir das vorgestellt habe.

"complementTimeOnMove" setzt die aktuelle Uhrzeit des Systems, was in meinem Fall nicht gewünscht ist. Wenn, dann wäre für mich eher die Zeit von "Vervollständigen --> Zeit" gewünscht. Da ich meist die Reihenfolge nicht verändere, wäre das jedoch nicht ganz so wichtig.
Das Hinzufügen von Punkten ist eigentlich bei mir der Use-Case, der zu den inkonsistenten Zeitstempeln geführt hat.

Auf das Hinzufügen neuer Punkte haben beide Optionen überhaupt keinen Einfluss. Selbst wenn man hier nur die Clear-Option setzt, so wird für die Punkte die aktuelle Uhrzeit gesetzt. Wenn für das Hinzufügen irgendwie die Erzeugung des Zeitstempels unterdrücken könnte, so wäre das für mich schon ausreichend. Man würde dann in der Liste sehen, dass etwas fehlt und könnte die Zeit per "Vervollständigen --> Zeit" setzen. Die Luxuslösung wäre natürlich, wenn dass sogar automatisch aktivierbar wäre.

Gruß
Thomas

[routeconverter]

"complementTimeOnMove" setzt die aktuelle Uhrzeit des Systems, was in meinem Fall nicht gewünscht ist.

Es versucht aus den vorigen beiden Positionen die Zeit zu extrapolieren und verwendet die aktuelle Uhrzeit, wenn das nicht funktioniert.

Wenn, dann wäre für mich eher die Zeit von "Vervollständigen --> Zeit" gewünscht.

Dann würde die Zeit von der Vorgänger- und Nachfolgerposition intrapoliert. Da der Vorgänger keine Zeit hat (s.o.) nützt Dir das auch nichts.

Auf das Hinzufügen neuer Punkte haben beide Optionen überhaupt keinen Einfluss.

Korrekt, um das anzuzeigen, heißen sie auch ...OnMove

Selbst wenn man hier nur die Clear-Option setzt, so wird für die Punkte die aktuelle Uhrzeit gesetzt. Wenn für das Hinzufügen irgendwie die Erzeugung des Zeitstempels unterdrücken könnte, so wäre das für mich schon ausreichend. Man würde dann in der Liste sehen, dass etwas fehlt und könnte die Zeit per "Vervollständigen --> Zeit" setzen. Die Luxuslösung wäre natürlich, wenn dass sogar automatisch aktivierbar wäre.

Schau mal in BaseMapView#insertPosition(). Dort wird complementTime aufgerufen - dieselbe Variante wie beim Verschieben. Daher glaube ich, daß Dein Problem ein anderes ist. Vervollständigen->Zeit würde Dir dann nichts nützen.

[lundefugl]

Hallo Christian,

"complementTimeOnMove" setzt die aktuelle Uhrzeit des Systems, was in meinem Fall nicht gewünscht ist.

Es versucht aus den vorigen beiden Positionen die Zeit zu extrapolieren und verwendet die aktuelle Uhrzeit, wenn das nicht funktioniert.
...

Schau mal in BaseMapView#insertPosition(). Dort wird complementTime aufgerufen - dieselbe Variante wie beim Verschieben. Daher glaube ich, daß Dein Problem ein anderes ist. Vervollständigen->Zeit würde Dir dann nichts nützen.

Das die Zeit auf Basis der 2 vorherigen Punkten errechnet wird, hatte ich nicht gewusst. Ich hatte nur die Zeit des ersten Punktes manuell gesetzt und anschliessend die nachfolgenden Punkte hinzugefügt.

Ich habe bei mir nun das Fallbackverhalten (aktuelle Zeit) bei der Vervollständigung der Zeit über eine versteckte Option abschaltbar gemacht. Wenn man dann die Files mit den fehlenden Zeiten mit Google Earth öffnet, so werden die Tracks dargestellt. Scheinbar hat Google nur mit den Rückwärtssprüngen ein Problem. Fehlt die Info ganz, so stört Google das wohl nicht. Ausserdem sieht man im RC dann leicht, wo noch Zeiten von Hand gesetzt werden müssten.

Ich werde dir auch dafür mal einen Pull-Request stellen.

Gruß
Thomas

[routeconverter]

Das die Zeit auf Basis der 2 vorherigen Punkten errechnet wird, hatte ich nicht gewusst. Ich hatte nur die Zeit des ersten Punktes manuell gesetzt und anschliessend die nachfolgenden Punkte hinzugefügt.

Aber mit 2 Punkten geht es?

Ich habe bei mir nun das Fallbackverhalten (aktuelle Zeit) bei der Vervollständigung der Zeit über eine versteckte Option abschaltbar gemacht. Wenn man dann die Files mit den fehlenden Zeiten mit Google Earth öffnet, so werden die Tracks dargestellt. Scheinbar hat Google nur mit den Rückwärtssprüngen ein Problem. Fehlt die Info ganz, so stört Google das wohl nicht.

Wäre es nicht besser, die Rückwärtssprünge auszusortieren? Oder bei KML gar ganz verhindern, wenn man Positionen bewegt oder einfügt?

[lundefugl]

Hallo Christian,

Aber mit 2 Punkten geht es?

ja. Damit gehts.

Wäre es nicht besser, die Rückwärtssprünge auszusortieren? Oder bei KML gar ganz verhindern, wenn man Positionen bewegt oder einfügt?

Das Aussortieren halte ich für keine gute Lösung. Wenn man das machen würde, so wären bei mir alle aufgezeichneten Punkte herausgeflogen und nur die manuell am Anfang hinzugefügten Punkte am Leben geblieben.

Das KML ganz zu verhindern, wenn Punkte hinzugefügt werden, dürfte auch schwierig werden. Wie soll das erkannt werden, wenn man das File als GPX speichert und dann neu läd ?

Den KML-Export grundsätzlich bei Rückwärtssprüngen nicht zuzulassen, wäre sicherlich ein gangbarer Weg. Wie schon mal zuvor im Thread angesprochen, dürfte hier nur das Problem sein, wie man das dem User mitteilt.

Das Format beim Save-As nicht anzubieten dürfte nur neue Supportfälle generieren ("Das KML-Format ist verschwunden"). Ausserdem könnte man ja auch ein KML laden und dann manipulieren - was soll dann beim einfachen Save-Passieren ?
Die meisten Programme würden wahrscheinlich jetzt eine Messagebox produzieren. Aus meiner Erfahrung weiss ich nur leider, dass die kaum gelesen werden und die meisten User einfach auf "OK" oder "Ja" kicken.

Mal eine ganz blöde Frage: Gibt es eigentlich ein Format oder Use-Case, bei dem Rückwärtssprünge in Tracks einen tieferen Sinn haben ? Wenn nicht, so könnte man evtl. ein Status-Icon mit einem Tool-Tip irgendwo eim RC einblenden, wo dann der Hinweis auf den Rückwärtssprung drin ist. Oder der Cell-Renderer macht die Zeit in der Tabelle einfach rot, wo der Rückwärtssprung ist.
Immerhin kann Google Earth auch andere Formate wie GPX importieren und bekommt dann die gleichen Probleme.

Gruß
Thomas

[routeconverter]

Das Format beim Save-As nicht anzubieten dürfte nur neue Supportfälle generieren ("Das KML-Format ist verschwunden"). Ausserdem könnte man ja auch ein KML laden und dann manipulieren - was soll dann beim einfachen Save-Passieren ?
Die meisten Programme würden wahrscheinlich jetzt eine Messagebox produzieren. Aus meiner Erfahrung weiss ich nur leider, dass die kaum gelesen werden und die meisten User einfach auf "OK" oder "Ja" kicken.

Das sehe ich auch so.

Gibt es eigentlich ein Format oder Use-Case, bei dem Rückwärtssprünge in Tracks einen tieferen Sinn haben ? Wenn nicht, so könnte man evtl. ein Status-Icon mit einem Tool-Tip irgendwo eim RC einblenden, wo dann der Hinweis auf den Rückwärtssprung drin ist. Oder der Cell-Renderer macht die Zeit in der Tabelle einfach rot, wo der Rückwärtssprung ist.

Mir fällt so spontan kein tieferer Sinn ein bei Tracks. Es könnte bei Wegpunktlisten und Routen verwirrend sein, eine rote Zeit zu sein - wo Zeit kaum eine Rolle spielt. Aber die Idee gefällt mir.