Version 0.65 von TrackGuru

[Nop]

Die Version 0.65 von TrackGuru ist da:

Wer ihn schon hat sollte ein Update angeboten bekommen.
Wer ihn noch nicht hat: http://trackguru.waldpfa.de/ - Dort findet sich auch eine Anleitung.

Wesentliche Änderungen:
- TrackGuru spricht jetzt Deutsch und Englisch
- Fix: Unterstützung für GPX 1.0 format funktioniert jetzt wirklich
- Fix: Nach Löschen von Punkten wird das Diagramm richtig angezeigt

[Harald Hartmann]

Track Guru v0.65 gestartet > Klick auf den Eintrag "Gültiges Trackverzeichnis auswählen" >

Code: Alles auswählen

Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
	at nop.gpx.track.Track.loadGPX11(Track.java:84)
	at nop.gpx.track.Track.<init>(Track.java:47)
	at nop.gpx.Controller.setSelectedTrack(Controller.java:205)
	at nop.gpx.gui.TrackLister.selectTrack(TrackLister.java:82)
	at nop.gpx.gui.TrackLister.lambda$new$2(TrackLister.java:71)

[Harald Hartmann]

Macht es eventuell Sinn, die beiden Schaltflächen "Neu laden" und "Ändern" durch die sonst übliche Symbolik "Reload-Pfeile" und "waagerechte drei Punkte" direkt hinter die Trackverzeichnis-JComboBox zu ersetzen? Dann spart sich dort auch die Übersetzung ... außer man möchte dies weiterhin als ToolTip anzeigen

[Harald Hartmann]

Nach was für einem Kriterium wird eigentlich die Trackliste aus einem Verzeichnis sortiert? Also einerseits wohl nach dem letzten Änderungs- bzw. Erstelldatum. Durch einen Kopiervorgang stehen bei mir jetzt aber 50 Dateien auf den 15.10.2017, die Dateinamen haben aber, dank OSMTracker, am Anfang des Namens das Format yyyy-MM-dd_HH-mm-SS stehen. Wäre vielleicht schön, wenn noch ein zweiter Sort auf den Dateinamen gemacht werden könnte.

[sei-h]

die Dateinamen haben aber, dank OSMTracker, am Anfang des Namens das Format yyyy-MM-dd_HH-mm-SS stehen. Wäre vielleicht schön, wenn noch ein zweiter Sort auf den Dateinamen gemacht werden könnte.

Halte ich auch für sinnvoll.
Als dritte Möglichkeit böte sich die Sortierung nach Erfassungszeit des Tracks, ohne dass man die Datei laden und mit der entsprechenden Option "Dateidatum aus Track übernehmen" wieder speichern muss. Längst nicht alle gpx-Dateien sind mit dem o.g. Format gespeichert.
In der Verzeichnisliste steht nach dem Dateinamen das Änderungsdatum, da hätte auch noch das Trackdatum Platz. Übersichtlicher wäre es, die in zwei bzw. drei Spalten auszugeben, aber ich sehe ein, dass nicht jeder einen großen Bildschirm hat.

Wenn ich schon beim Wünschen bin: Eine grobe Angabe (Grad+Minuten) des Track(beginns) in der Liste fände ich hilfreich. Bisher muss ich die Datei anklicken, um die Gegend zu identifizieren und das Laden des Bildes benötigt ja trotz Cache oft Serverzugriff. Das Datum allein hilft mir nicht immer, da ich auch die Tracks meiner Tochter auf deren Reisen auswerte und alle heruntergeladenen Tracks zunächst im selben Verzeichnis landen.

[sei-h]

Ein kleiner Bug:
Im Vollbild oder bei Fenster ganz rechts unten anstoßend überdeckt das Pop-Up-Fenster nach MouseOver auf dem Button "Bearbeiten" die Schaltfläche komplett, so dass sie nicht mehr angeklickt werden kann.

[sei-h]

Macht es eventuell Sinn, die beiden Schaltflächen "Neu laden" und "Ändern" durch die sonst übliche Symbolik "Reload-Pfeile" und "waagerechte drei Punkte" direkt hinter die Trackverzeichnis-JComboBox zu ersetzen?
Dann spart sich dort auch die Übersetzung ... außer man möchte dies weiterhin als ToolTip anzeigen

Tooltip bei MausOver müsste auch bei Element "..." in Combobox-Liste gehen.

[Nop]

Track Guru v0.65 gestartet > Klick auf den Eintrag "Gültiges Trackverzeichnis auswählen" >

Danke für den Hinweis - gefixt.

[Nop]

Im Vollbild oder bei Fenster ganz rechts unten anstoßend überdeckt das Pop-Up-Fenster nach MouseOver auf dem Button "Bearbeiten" die Schaltfläche komplett, so dass sie nicht mehr angeklickt werden kann.

Soweit ich weiß läßt sich die Positionierung von Tooltips nicht beeinflussen - das ist Java Swing am Werk.

[Nop]

Wenn ich schon beim Wünschen bin: Eine grobe Angabe (Grad+Minuten) des Track(beginns) in der Liste fände ich hilfreich...

Das Starke Interesse an der Übersichtsliste bringt mich auf eine Idee...

Das Problem bei den meisten Vorschlägen ist, daß man sowohl für die Startzeit des Tracks als auch für die Koordinaten den Track zuvor laden muß - für eine Liste von 100 oder mehr Tracks dauert das zu lange um wirklich angenehm zu sein. Ich probier' da mal was aus...

[sei-h]

Das Starke Interesse an der Übersichtsliste bringt mich auf eine Idee...
Das Problem bei den meisten Vorschlägen ist, daß man sowohl für die Startzeit des Tracks als auch für die Koordinaten den Track zuvor laden muß - für eine Liste von 100 oder mehr Tracks dauert das zu lange um wirklich angenehm zu sein. Ich probier' da mal was aus...

Da die relevante Info am Anfang der gpx-Datei steht, sollte es eigentlich nicht zu lange dauern, das zu lesen.
Aber warten wir's ab ...

[Nop]

Da die relevante Info am Anfang der gpx-Datei steht, sollte es eigentlich nicht zu lange dauern, das zu lesen.

Die JPX-Bibliothek liest Tracks immer komplett. Da gibt's keine Abkürzungen.

Abgesehen davon müssen die relevanten Koordinaten nicht am Anfang der Datei stehen. Es können schlielich Einschaltfehler, Anfahrt oder mehrere weit verteilte Abschnitte sein...

[sei-h]

Die JPX-Bibliothek liest Tracks immer komplett. Da gibt's keine Abkürzungen.

Dann eben nicht.
Ich lese meine Trackdateien halt "zu Fuß" und bearbeite sie mit String-Methoden.

Abgesehen davon müssen die relevanten Koordinaten nicht am Anfang der Datei stehen. Es können schlielich Einschaltfehler, Anfahrt oder mehrere weit verteilte Abschnitte sein...

Ich würde keine Perfektion erwarten: Wenn die Tracks im Golf von Guinea oder sonstwo anfangen, sind das gleich die Kandidaten fürs "Köpfen".
Die Anfahrt ist aber eine Argument, denn die Touren gehen tatsächlich häufig vom selben Ort aus. Da sagt ein Bild mehr als tausend Koordinaten .

[Harald Hartmann]

Hmm, und kann es sein, dass der GPXReader von JPX auch ein kleines Problem hat?

Code: Alles auswählen

java.io.IOException: javax.xml.stream.XMLStreamException: Unexpected element <time>.
	at io.jenetics.jpx.GPX$Reader.read(GPX.java:1072)
	at io.jenetics.jpx.GPX.read(GPX.java:1820)
	at nop.gpx.track.Track.loadGPX11(Track.java:74)

Zumindest kommt dieser Fehler bei all meinen mit GPSLogger aufgenommen Tracks, hier ein Beispiel:

Code: Alles auswählen

<?xml version="1.0" encoding="UTF-8" ?>
<gpx version="1.0" creator="GPSLogger 87 - http://gpslogger.mendhak.com/"
	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">
	<time>2017-06-26T16:31:04.000Z</time>
	<trk>
		<trkseg>
			<trkpt lat="50.51747187" lon="10.86970716">
				<ele>511.3999938964844</ele>
				<time>2017-06-26T16:31:04.000Z</time>
				<course>47.9</course>
				<speed>2.0</speed>
				<src>gps</src>
				<sat>8</sat>
			</trkpt>

Laut https://www.topografix.com/gpx_manual.asp#time ist das time vor dem trk aber zulässig, zumindest wenn ich das richtig lese, oder muss ich das so lesen, dass time nur als Attribut des gpx-Elements zulässig ist, und dann in der Tat der Entwickler vom GPSLogger das ebenfalls missverstanden hat?

Nachtrag: also laut http://www.topografix.com/GPX/1/0/gpx.xsd ist das time als Element definitiv unter dem gpx element zulässig...

[Nop]

Die Exception kommt, wenn man versucht ein GPX1.0 als GPX1.1 zu lesen. Sie wird gefangen und danach GPX1.0 laden ausprobiert.

Der Track sollte trotz der Exception geladen werden, richtig?

[Harald Hartmann]

Der Track sollte trotz der Exception geladen werden, richtig?

Jepp, wird er. Aber dann könnte man die Exception auch "verkürzt" darstellen, so sieht es nach einem schwerwiegenden Fehler aus. Hmm, aber du weißt doch vorher schon ob es ein GPX 1.0 oder 1.1 ist, oder etwas nicht? Oder macht das JPX falsch?

[Nop]

Ich hatte diese Exception zwischenzeitlich ganz unterdrückt - dann kam aber natürlich ein Track mit einem echten, anderen Fehler an...

[sei-h]

Ich hatte diese Exception zwischenzeitlich ganz unterdrückt - dann kam aber natürlich ein Track mit einem echten, anderen Fehler an...

GPX 1.0 statt 1.1 ist halt nur eine mögliche Ursache für eine XMLStreamException, aber möglicherweise? so häufig, dass sich dafür eine eigene Behandlung lohnt.

[Nop]

Hat sich erledigt, die Situation gibt es in V0.7 nicht mehr.

[sei-h]

Hat sich erledigt, die Situation gibt es in V0.7 nicht mehr.

Richtig. Hatte die Änderungen in TG 0.7 noch nicht gelesen.
Das nennt man vorauseilenden Gehorsam .