... the user friendly GPS tool


Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Metadaten fehlen oder sind veraltet
#11
(03.04.2020, 17:58)tkansgar Wrote: Auf den Namen im Metadatenblock könnte ich verzichten. Der steht ja im <trk>-Block, wo er hingehört und woher Locus Map ihn auch nimmt.

Warum holt Locus dann nicht auch die Zeit daher? Was macht Locus, wenn in einer GPX-Datei mehr als ein Track drin ist?
Grüße
Hans

Reply
#12
Ich habe mal ein bisschen gegoogelt:
https://stackoverflow.com/questions/3086...mt-in-java
Interessant wird es dort ab der Antwort "tl;dr". Demnach ist die Ermittlung des aktuellen Zeitpunkts und dessen Formatierung als ISO-UTC-Zeitstempel in Java ein Einzeiler:
Code:
Instant.now().toString()
Ich bin allerdings kein Java- sondern C++-Entwickler. Daher kenne ich mich mit Java nicht so gut aus.
Reply
#13
(03.04.2020, 18:41)nordlicht Wrote:
(03.04.2020, 17:58)tkansgar Wrote: Auf den Namen im Metadatenblock könnte ich verzichten. Der steht ja im <trk>-Block, wo er hingehört und woher Locus Map ihn auch nimmt.

Warum holt Locus dann nicht auch die Zeit daher? Was macht Locus, wenn in einer GPX-Datei mehr als ein Track drin ist?
Wo bitteschön sollte Locus Map die Zeit denn hernehmen (ein minimaler Track, gerade von RouteConverter erzeugt):
Code:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<gpx xmlns:gpxtpx1="http://www.garmin.com/xmlschemas/TrackPointExtension/v1" xmlns="http://www.topografix.com/GPX/1/1" xmlns:trp="http://www.garmin.com/xmlschemas/TripExtensions/v1" xmlns:gpxx="http://www.garmin.com/xmlschemas/GpxExtensions/v3" xmlns:gpxtpx="http://www.garmin.com/xmlschemas/TrackPointExtension/v2" version="1.1" creator="RouteConverter 2.28-SNAPSHOT-98">
    <trk>
        <name>Test-Track</name>
        <desc>Created at 2020-04-03T17:48:31Z</desc>
        <trkseg>
            <trkpt lat="52.3730446" lon="9.4312477">
                <ele>50.0</ele>
                <name>1</name>
            </trkpt>
            <trkpt lat="52.3729136" lon="9.4287372">
                <ele>50.0</ele>
                <name>2</name>
            </trkpt>
        </trkseg>
    </trk>
</gpx>
Wie gesagt, der desc-Eintrag zählt nicht, weil das eigentlich nur ein Text und kein Zeitpunkt ist. Aber immerhin beweist der, dass RouteConverter den gesuchten Zeitpunkt schon im richtigen Format ermitteln kann. Ob ein time-Eintrag an gleicher Stelle dem GPX-Format genügt, weiß ich nicht. Aber gute Idee, ich werde mal testen, was Locus Map damit machen würde.
Reply
#14
Bingo!
Ich habe aus "desc" vorne und hinten "time" gemacht und "Created at " rausgenommen:

Code:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<gpx xmlns:gpxtpx1="http://www.garmin.com/xmlschemas/TrackPointExtension/v1" xmlns="http://www.topografix.com/GPX/1/1" xmlns:trp="http://www.garmin.com/xmlschemas/TripExtensions/v1" xmlns:gpxx="http://www.garmin.com/xmlschemas/GpxExtensions/v3" xmlns:gpxtpx="http://www.garmin.com/xmlschemas/TrackPointExtension/v2" version="1.1" creator="RouteConverter 2.28-SNAPSHOT-98">
    <trk>
        <name>Test-Track-02</name>
        <time>2020-04-03T17:48:31Z</time>
        <trkseg>
            <trkpt lat="52.3730446" lon="9.4312477">
                <ele>50.0</ele>
                <name>1</name>
            </trkpt>
            <trkpt lat="52.3729136" lon="9.4287372">
                <ele>50.0</ele>
                <name>2</name>
            </trkpt>
        </trkseg>
    </trk>
</gpx>

Der Zeitpunkt wird von Locus Map als solcher anerkannt und der Track entsprechend einsortiert. Und wenn der desc-Eintrag zusätzlich drinbleibt, wird der Text sogar auch noch angezeigt (wobei ich den nicht bräuchte).
Allerdings, dabei fällt mir auf: Ich modifiziere gewöhnlich bei mir vorhandene Tracks und mache daraus neue. Bei denen erzeugt RouteConverter keinen desc-Eintrag (deshalb hatte ich bisher in Locus Map auch noch keinen gesehen). Den time-Eintrag mit dem aktuellen Zeitpunkt an gleicher Stelle bräuchte ich aber trotzdem. Und der Metadatenblock könnte dann meinetwegen auch weiterhin fehlen.
Reply
#15
(03.04.2020, 20:02)tkansgar Wrote: Den time-Eintrag mit dem aktuellen Zeitpunkt an gleicher Stelle bräuchte ich aber trotzdem.

Der ist an der Stelle nur nicht zulässig, validiere dein Muster mal gegen die gpx.xsd, die bekommst du hier. Auch nachzulesen in der Schema Documentation.

Wenn du bei künstlich erzeugten Tracks unbedingt Zeitstempel brauchst, kannst du in RC in der Positionsliste das leere Zeit-Feld des ersten und letzten Punktes händisch ausfüllen und die Punkte dazwischen automatisch füllen lassen.
Grüße
Hans

Reply
#16
(03.04.2020, 20:35)nordlicht Wrote:
(03.04.2020, 20:02)tkansgar Wrote: Den time-Eintrag mit dem aktuellen Zeitpunkt an gleicher Stelle bräuchte ich aber trotzdem.

Der ist an der Stelle nur nicht zulässig, validiere dein Muster mal gegen die gpx.xsd, die bekommst du hier. Auch nachzulesen in der Schema Documentation.

Wenn du bei künstlich erzeugten Tracks unbedingt Zeitstempel brauchst, kannst du in RC in der Positionsliste das leere Zeit-Feld des ersten und letzten Punktes händisch ausfüllen und die Punkte dazwischen automatisch füllen lassen.

Das ist aber schade! Bleibt aber immer noch der Platz in den Metadaten. Und laut der xsd gehört der Zeitpunkt, den Locus Map vermisst, auch genau dort hin:
Code:
<xsd:element name="time" type="xsd:dateTime" minOccurs="0">
  <xsd:annotation>
    <xsd:documentation> The creation date of the file. </xsd:documentation>
  </xsd:annotation>
</xsd:element>
"The creation date of the file." deckt sich mit dem, was ich in #9 vorgeschlagen hatte:
Quote:M.E. sollte RouteConverter den Speicherungszeitpunkt wie auch von Nordlicht vorgeschlagen in die Metadaten eintragen. Welche Zeitpunkte in die Trackpoints eingetragen werden und ob überhaupt, wäre dann aus meiner Sicht egal (könnte also so bleiben, wie es ist).

Den Zeitstempel per RouteConverter in den ersten Trackpoint einzutragen wäre natürlich möglich, hat aber zumindest in meinem Fall keine Vorteile, erstens weil ich extra daran denken und ihn auch noch selbst ermitteln müsste, und zweitens weil ich den alten in den Metadaten meist schon vorhandenen Eintrag trotzdem nachträglich manuell löschen müsste. Da ist es einfacher stattdessen diesen wie bisher manuell anzupassen. Aber wie gesagt, am besten wäre es, wenn RouteConverter mir diese Arbeit abnehmen könnte.
Reply
#17
(03.04.2020, 17:29)tkansgar Wrote: RouteConverter trägt jedoch leider nirgendwo einen <time> Eintrag ein bzw. behält vorhandene Einträge trotz vorgenommener Änderungen bei.

Nirgendwo reizt zum Widerspruch, denn für Trackpunkte in Tracks werden natürlich <time> geschrieben. RouteConverter trägt nichts in <metadata> ein – was sollte da auch sinnvollerweise hinein außer dem Speicherungszeitpukt. Das meintest Du mit nirgendwo, oder?

(03.04.2020, 17:29)tkansgar Wrote: M.E. sollte RouteConverter den Speicherungszeitpunkt wie auch von Nordlicht vorgeschlagen in die Metadaten eintragen.

Und wenn bereits etwas in <metadata><time> drin steht? Überschreiben?
--
Christian
Reply
#18
(04.04.2020, 17:23)routeconverter Wrote:
(03.04.2020, 17:29)tkansgar Wrote: RouteConverter trägt jedoch leider nirgendwo einen <time> Eintrag ein bzw. behält vorhandene Einträge trotz vorgenommener Änderungen bei.

Nirgendwo reizt zum Widerspruch, denn für Trackpunkte in Tracks werden natürlich <time> geschrieben. RouteConverter trägt nichts in <metadata> ein – was sollte da auch sinnvollerweise hinein außer dem Speicherungszeitpukt. Das meintest Du mit nirgendwo, oder?

(03.04.2020, 17:29)tkansgar Wrote: M.E. sollte RouteConverter den Speicherungszeitpunkt wie auch von Nordlicht vorgeschlagen in die Metadaten eintragen.

Und wenn bereits etwas in <metadata><time> drin steht? Überschreiben?

Hi Christian,

da muss ich wiederum widersprechen: Die <time> Einträge für Trackpoints trägt RouteConverter nur ein, wenn man selbst Zeitpunkte setzt oder explizit erzeugen lässt. Ansonsten fehlen sie (s. Minibeispiel in #13). Das ist aber für mein Dafürhalten in Ordnung. Und vorhandene (wie meine von GPSies erzeugte) bleiben erhalten, was natürlich auch ok ist.

Aber du hast Recht, in <metadata> muss meinetwegen außer dem Speicherungszeitpunkt nichts weiter rein. Und ja, wenn schon einer drinsteht, sollte er überschrieben werden, weil es ja eine neue Speicherung mit veränderten Daten ist. Letzteres stellt ja mein aktuelles Problem dar, weil ich immer alte Tracks als Vorlage für neue nehme.

Dazu habe ich noch einen Vorschlag: Wenn du nicht möchtest, dass andere Anwender vom neuen Metadatenblock mit dem Speicherungszeitpunkt "überrascht" werden, könntest du doch eine Option einführen, die defaultmäßig den Metadatenblock weglässt und die ich dann anschalten müsste.

Wie gesagt, ich erzeuge mit RouteConverter immer nur gpx-Dateien. Ob andere von RouteConverter unterstützte Formate auch einen Speicherungszeitpunkt kennen, weiß ich natürlich nicht. Ggf. könntest du dir dann ja noch überlegen ihn auch bei denen wegzuschreiben.

Habe ich eine Chance, dass du mein Anliegen irgendwann realisierst? Ich wäre dir sehr dankbar.

Viele Grüße
tkansgar
Reply
#19
(04.04.2020, 18:15)tkansgar Wrote: Dazu habe ich noch einen Vorschlag: Wenn du nicht möchtest, dass andere Anwender vom neuen Metadatenblock mit dem Speicherungszeitpunkt "überrascht" werden, könntest du doch eine Option einführen, die defaultmäßig den Metadatenblock weglässt und die ich dann anschalten müsste.

Das würde die Angelegenheit nur verkomplizieren. Wenn ein GPX-Track importiert wird, enthält er manchmal auch Metadaten, die dann beim Speichern auch bitte erhalten bleiben sollen, also nix mit default-mäßig weglassen. Daß beim Speichern <metadata><time> hinzugefügt oder überschrieben/aktualisiert wird, wäre für mich in Ordnung.
Grüße
Hans

Reply
#20
(31.03.2020, 18:44)tkansgar Wrote: Hi Hans und Christian,
dafür wäre ich wirklich sehr dankbar. Die manuelle Nachbearbeitung ist echt nervig, zumal ich das gelegentlich zunächst vergesse, feststellen muss, dass Locus Map den neuen Track falsch einsortiert und den Import mit korrigiertem bzw. ergänztem <time> Eintrag wiederholen muss.
Grüße
tkansgar


Hmm als C++ Programmierer kanns Du doch ein Kommandozeilentool schreiben, welches quasi wie touch den timestamp in metadata setzt.

Grüße,
Ilmari
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)