2.0 Merkwürdigkeiten

[Wallaroo]

Guten Tag, alle miteinander,

anscheinend kommt immer mal ein Tag, an dem Zaungäste vom Zaun heruntersteigen um sich ins Geschehen zu mischen. Heute bin ich es, der das tut.

Ich habe seit Version 1.23 viel Freude am RouteConverter gehabt, der ohne viele Schnörkel meinen Bedürfnissen nachgekommen ist; mit jeder Inkarnation etas mehr.

Vielen Dank, Christian, für die Mühe, die Du ganz offensichtlich in diese Entwicklung gesteckt hast!

Seit Version 1.33 war ich leider nicht mehr gang so glücklich, der Quantensprung zu Version 2.0 und den Pre-Releases verwirrt mich vollends. Da sonst niemand damit ernsthafte Probleme zu haben scheint, wird es wohl an meiner speziellen Konfiguration liegen (?).

Hier laufen u. a.
- Windows XP 5.1.2600.5973 x86
- Java 1.6.0_22
- Internet Explorer 8.0.6001.18702 (nicht der Standardbrowser)
- Mozilla Firefox 3.6.12 (Standardbrowser)

Bei meinen Fahrten/Reisen zeichne ich die zurückgelegten Wege mit einem Royaltek RGM-3800 auf, der mir danach NMEA-Dateien liefert, die ich anschließend in RouteConverter nach meinem Belieben bearbeite. Das hat immer wunderschön funktioniert.

Aktuell habe ich neue Dateien, Routeconverter 1.32 hat mir die neue Version 2.0 avisiert, ich habe die geladen und gestartet.

Zuerst fiel mir auf, dass RC mir an der dafür vorgesehenen Stelle weder Länge nach Dauer des Tracks anzeigte, das tat "er" erst, nachdem ich den Typ um- und wieder zurückgestellt hatte. Außerdem zeigte er falsche Datums- und Zeitangaben an.

Dann fiel mir auf, dass RC Datum und Uhrzeit eines Trackpunktes löschte, wenn ich den verschoben = korrigiert habe. Danach habe ich V2.0 beendet und bin zu 1.32 zurückgekehrt.

Prerelease 2.1-Snapshot-1 vom 29.10.2010 hat mich beim Start mit einer doppelten Browser-called-back-Nachricht beglückt, die wegzuklicken war, und zeigte jetzt die korrekte Länge und Dauer trotz fehlerhafter Datums-/Zeitangabe an, nicht ohne gleichzeitig wieder eine wegzuklickende Nachricht anzuzeigen (das geschieht bei jeder Aktion, damit kann ich nicht flüssig arbeiten!). Die Zeitangabe eines Trackpunktes wird auch hier gelöscht.

Prerelease 2.1-Snapshot-1 vom 31.10.2010 bringt beim Start nur noch eine "Nachricht", verhält sich aber ansonsten, wie sein Vorgänger.

Fazit: V2.0 ff sind so für mich nicht brauchbar, zurück also zu V1.32 und alles läuft wieder, wie gewohnt und auch richtig.

Liegt das wohl alles nur an meinem Aufbau, oder woran sonst? Logs und Screenshots habe ich vorsichtshalber gesichert/gefertigt, falls sie vonnöten sein sollten.

Gruß
Bernd

[routeconverter]

Zuerst fiel mir auf, dass RC mir an der dafür vorgesehenen Stelle weder Länge nach Dauer des Tracks anzeigte, das tat "er" erst, nachdem ich den Typ um- und wieder zurückgestellt hatte. Außerdem zeigte er falsche Datums- und Zeitangaben an.

Das ist ein Bug in der 2.0 Version.

Dann fiel mir auf, dass RC Datum und Uhrzeit eines Trackpunktes löschte, wenn ich den verschoben = korrigiert habe. Danach habe ich V2.0 beendet und bin zu 1.32 zurückgekehrt.

Da haben mich Nutzer überzeugt, daß das Verschieben eines Trackpunktes bedeutet, daß Datum und Uhrzeit nicht mehr stimmen können, da sie nicht so aufgezeichnet wurden - und deshalb gelöscht werden sollen.

Prerelease 2.1-Snapshot-1 vom 29.10.2010 hat mich beim Start mit einer doppelten Browser-called-back-Nachricht beglückt, die wegzuklicken war,

Ich jage da Bugs unter Linux und Mac OS X und stellte deshalb derzeit Vorabversionen, die nur dafür geeignet sind, ins Netz. Vielleicht dauert das noch diese Woche, dann ist der Spuk vorbei ;-)

und zeigte jetzt die korrekte Länge und Dauer trotz fehlerhafter Datums-/Zeitangabe an,

Prima.

Liegt das wohl alles nur an meinem Aufbau, oder woran sonst?

Nein, ich hoffe, das erklärt zu haben?

[Wallaroo]

Da haben mich Nutzer überzeugt, daß das Verschieben eines Trackpunktes bedeutet, daß Datum und Uhrzeit nicht mehr stimmen können, da sie nicht so aufgezeichnet wurden - und deshalb gelöscht werden sollen.

Wenn ich Ausreißer dahin verschiebe, wo sie hingehören, dann stimmen die Zeitangaben durchaus, nur die Position stimmt eben nicht. Das passiert mir durchaus häufig, wenn ich bspw. in einem Gebäude bin oder in der Nähe einer Häuserwand oder ... Heißt das denn, ich müsste jetzt die Angaben händisch wieder hinzufügen? Hm ...

Ich jage da Bugs unter Linux und Mac OS X und stellte deshalb derzeit Vorabversionen, die nur dafür geeignet sind, ins Netz. Vielleicht dauert das noch diese Woche, dann ist der Spuk vorbei ;-)

Ach so, ja dann ... :-)

und zeigte jetzt die korrekte Länge und Dauer trotz fehlerhafter Datums-/Zeitangabe an,

Prima.

Nein, leider nicht prima. Die "falsche" Zeitangabe, wie ich eben meine festgestellt zu haben, scheint abhängig von der Betriebssystem-Zeitzone zu sein. Irgendwie interpretiert RC 2 wohl etwas, was es m. E. nicht sollte und was RC 1.xx nicht tat/tut.

Beispiel:
Ein Trackpunkt wurde 08.10.10 23:16:34 aufgezeichnet (UTC).
RC zeigte gestern an: 09.10.10 01:16:34 (UTC+2 = MESZ)

Hoppla:
Das zeigt er heute auch an, da müsste ja an sich 09.10.10 00:16:34 (UTC+1 = MEZ) zu sehen sein. Stützt meine Vermutung also nicht.

Was verschiebt die Zeitangabe wohl dann?

Liegt das wohl alles nur an meinem Aufbau, oder woran sonst?

Nein, ich hoffe, das erklärt zu haben?

Danke vielmals für die bisherige Aufklärung :-)

[routeconverter]

Wenn ich Ausreißer dahin verschiebe, wo sie hingehören, dann stimmen die Zeitangaben durchaus, nur die Position stimmt eben nicht. Das passiert mir durchaus häufig, wenn ich bspw. in einem Gebäude bin oder in der Nähe einer Häuserwand oder ... Heißt das denn, ich müsste jetzt die Angaben händisch wieder hinzufügen? Hm ...

Tja, da gibt es wohl zwei unvereinbare Positionen: die einen möchten jede Verfälschung sichtbar machen, die anderen sehen das pragmatisch. Was tun? Eine weitere versteckte Option?

Nein, leider nicht prima. Die "falsche" Zeitangabe, wie ich eben meine festgestellt zu haben, scheint abhängig von der Betriebssystem-Zeitzone zu sein. Irgendwie interpretiert RC 2 wohl etwas, was es m. E. nicht sollte und was RC 1.xx nicht tat/tut.

Beispiel:
Ein Trackpunkt wurde 08.10.10 23:16:34 aufgezeichnet (UTC).
RC zeigte gestern an: 09.10.10 01:16:34 (UTC+2 = MESZ)

Hast Du ein Beispiel dafür?

Was verschiebt die Zeitangabe wohl dann?

RouteConverter verwendet bei der Ausgabe in die Tabellenspalte die lokale Zeitzone. Das ist wohl keine gute Idee, oder?

[Wallaroo]

Wenn ich Ausreißer dahin verschiebe, wo sie hingehören, dann stimmen die Zeitangaben durchaus, nur die Position stimmt eben nicht. ...

Tja, da gibt es wohl zwei unvereinbare Positionen: die einen möchten jede Verfälschung sichtbar machen, die anderen sehen das pragmatisch. Was tun? Eine weitere versteckte Option?

Fundis gegen Realos? :-)
Als Verfälschung sehe ich eher die Ausreißer, die ich korrigieren möchte. Aber klar, das ist Ansichtssache. Eine Option könnte dies Problem natürlich lösen und beiden Ansichten gerecht werden, ob sie unbedingt versteckt sein muss, weiß ich nicht. Wir haben ja bspw. auch Zentrieroptionen u. ä.

Nein, leider nicht prima. ...

Beispiel:
Ein Trackpunkt wurde 08.10.10 23:16:34 aufgezeichnet (UTC).
RC zeigte gestern an: 09.10.10 01:16:34 (UTC+2 = MESZ)

Hast Du ein Beispiel dafür?

Aber sicher doch. Was hättest Du gern? Meine NMEA-0183-Datei, Screenshots, beides, anderes?

Was verschiebt die Zeitangabe wohl dann?

RouteConverter verwendet bei der Ausgabe in die Tabellenspalte die lokale Zeitzone. Das ist wohl keine gute Idee, oder?

Ich finde es keine gute Idee. Wenn ich mich außerhalb der lokalen Zeitzone bewege, was ich meistens tue, wenn ich Strecken aufzeichnen lasse, bringt mir die Information, welche Zeit es daheim gewesen wäre, keinen wirklichen Mehrwert. Ist dies "Feature" denn eine Neuerung in 2.0? Denn 1.32 und 1.33 taten/tun es (hier) nicht, aber ich wiederhole mich da.