GoPro & Linux

J'ai essayé d'être clair mais je n'ai semble-t-il pas réussi. J'essaye autrement :

Mon fichier Jonzac02.gpx daté du 20 avril 2023 à 17:39:39 est encore présent sur mon smartphone
Il s'agit de la date/heure à laquelle j'ai fini de télécharger le fichier un peu après ma sortie
En effet c'est le site Geovelo qui le fournit et non un enregistrement direct local de l'application
Je sais, c'est stupide mais c'est comme ça. Il y a d'autres stupidités dans Geovelo ...

Ce fichier contient l'entête : 2023-04-20T15:36:39.824000+0200 et comme premier et dernier points :

Code:

      <trkpt lat="45.440869" lon="-0.427337">
        <time>2023-04-20T15:36:39.824000+0200</time>
      </trkpt>
...
      <trkpt lat="45.44091" lon="-0.427018">
        <time>2023-04-20T17:07:08.851000+0200</time>
      </trkpt>

Vu l'heure de fin de téléchargement( du fichier et son contenu, il est clair que l'hypothèse 1) plus haut est la bonne, à savoir :
Mon trajet a été effectué de 15:36 à 17:07 heure locale qui se trouvait être décalée de +2 heures par rapport à l'UTC puisqu'en heure d'été.
Le +0200 qualifie la zone mais doit être ignoré, sauf si l'on a besoin de retrouver l'heure UTC auquel cas il faut le soustraire.
Or nous ne voulons pas de l'heure UTC, nous voulons afficher l'heure locale au moment du trajet.
Il faut donc ignorer la zone (le +0200) et si des calculs sont faits sur les heures, il ne faut surtout pas que le décalage actuel du PC modifie celles-ci
C'est ce qui peut arriver quand on utilise les librairies habituelles avec par exemple strftime, strptime et surtout mktime.

Je crois que le problème depuis le début (avant même que tu tiennes compte de la zone) était que tu considérais le temps du point GPX comme UTC
Or ce n'est pas le cas d'après ce que je constate. Le GPX contient des points en heure locale quand ils sont de cette forme.
Attention, il y a d'autres cas possibles décrits dans le lien que je t'ai fourni plus haut.

Qu'en penses-tu ?
Pulsar33

Quand tu lis dans le fichier :

2023-04-20T15:36:39.824000+0200

Ça veut dire que tu as commencé ta sortie à 15h36 heure locale.

Si je veux l'heure UTC je dois retrancher 2h...donc 13h36 (attention à la problématique DST)

Dans tous les cas, je lis et convertis tout en UTC. C'est obligatoire et beaucoup plus simple pour faire les calculs.

Lors de l'affichage, donc du rendu, je convertis en heure locale en utilisant les paramètres du PC.

Je ferai plusieurs tests et corrections si nécessaire. Mais c'est pour mois une affaire réglée.

Alors ça correspond en effet à ce que je constate mais non, ce n'est pas réglé
Que tu passes par de l'UTC en interne c'est ton choix (technique) et je peux le comprendre
Mais l'utilisateur lui veut afficher son trajet en heure locale du jour du trajet
Or si tu ré-encodes en hiver une trace prise en été, ce ne sera pas bon
Ce sera mon cas dans quelques jours puisqu'on va passer en heure d'hiver

L'heure actuelle et le DST actuel sur le PC qui bosse n'ont strictement rien à voir avec l'encodage
(ie ne doivent surtout pas impacter le rendu)

Cordialement
Pulsar33

Pour le décalage DST, ça ne doit pas prendre en compte la date de génération, mais la date à laquelle le gpx a été créé.

C'est pour cela que quand tu convertis une heure utc en une heure locale, tu dois fournir le fuseau horaire ET la date.

Bonjour,

Ce que tu dis là n'est pas incompatible de ce que je dis juste au dessus.

Quelles que soient les méthodes (fonctions) que tu utilises et quel que soit le moment de l'année où je génère le rendu, si le GPX contient 2023-04-20T15:36:39.824000+0200 je dois voir 15:36:39 sur le rendu

Bonne journée
Pulsar33

Bonjour,

J'ai un problème avec Fix date time parsing :

Code:

CMake Error at CMakeLists.txt:161 (add_library):
  Cannot find source file:
    src/test.cpp
  Tried extensions .c .C .c++ .cc .cpp .cxx .cu .mpp .m .M .mm .ixx .cppm .h
  .hh .h++ .hm .hpp .hxx .in .txx .f .F .for .f77 .f90 .f95 .f03 .hip .ispc
CMake Error at CMakeLists.txt:161 (add_library):
  No SOURCES given to target: gpxcore
CMake Generate step failed.  Build files cannot be regenerated correctly.

Bon dimanche
Pulsar33

C'est corrigé

Une question, est-ce que ta caméra ajoute le champ creation_time aux metadata de la vidéo ?

Et si oui, c'est date est dans quérir format.

Ici j’ai remarqué que les caméras testées ajoutent toutes ce champ au format UTC.

Excepté la gopro qui indique utc alors que c'est la date locale !

Alors, si je me souviens bien, tu m'avais indiqué au début comment ajouter ce temps à la vidéo parce que c'était alors nécessaire.
Depuis, tu as fait en sorte qu'on puisse s'en passer et ça me va très bien car ma caméra est basique et ne fournit pas ce champ.
Pour info, la vidéo que j'utilise le plus souvent pour tester donne avec ffprobe :

Code:

pulsar33@Minerve:/media/DATA/Technique/Velos/Trajets/Pacman$ ffprobe Jonzac02O.mp4
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'Jonzac02O.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2mp41
    encoder         : Lavf58.76.100
  Duration: 01:12:08.52, start: 0.000000, bitrate: 4189 kb/s
  Stream #0:0(und): Video: mpeg4 (Simple Profile) (mp4v / 0x7634706D), yuv420p, 720x576 [SAR 64:45 DAR 16:9], 4056 kb/s, 25 fps, 25 tbr, 12800 tbn, 25 tbc (default)
    Metadata:
      handler_name    : VideoHandler
      vendor_id       : [0][0][0][0]
  Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 128 kb/s (default)
    Metadata:
      handler_name    : SoundHandler
      vendor_id       : [0][0][0][0]

Pour l'instant, j'ai uniquement testé un "compute" sur le GPX associé et tout s'est bien passé. J'ai bien la bonne heure dans le CSV.
A noter que j'ai ôté quelques points du GPX pour le caler sur la vidéo sans rectifier l'entête. J'ai fait tellement de manips que je m'y perds parfois.
Le GPX commence ainsi :

Code:

 <metadata>
    <name>20 avr. 15h36 - 17h07</name>
    <link href="https://geovelo.app">
      <text>Geovelo - GPS et Stats vélo</text>
    </link>
    <time>2023-04-20T15:36:39.824000+0200</time>
  </metadata>
  <trk>
    <trkseg>
      <trkpt lat="45.44086" lon="-0.42718">
        <ele>37.2</ele>
        <time>2023-04-20T15:38:25.879000+0200</time>
      </trkpt>

Le CSV généré ignore le champ "time" de l'entête et prend la date/heure du premier point, ce qui me va très bien comme ça

Code:

1681997905879 2023-04-20 15:38:25 0 0 0 M 45,44086 -0,42718 37,2

Je modifie et réinjecte le CSV dès que j'ai un moment

Bonne soirée
Pulsar33

Bon, j'ai parlé un peu vite. Finalement comme je le craignais, ça ne fonctionne pas.
Je viens de remplacer tous les +0200 dans le GPX par des -0200
Le "compute" ne plante pas mais génère une heure décalée de 4 heures :

Code:

1682012305879   2023-04-20 19:38:25   0   0   0    M   45,44086   -0,42718   37,2

Donc, si je remets +0200, ça ne fonctionne que parce que mon PC se situe actuellement à un DST de +2h
Et dans quelques jour, après le changement d'heure, ça fournira 14:38:25 au lieu de 15:38:25

Désolé
Pulsar33

Pulsar33 a écrit:

Bon, j'ai parlé un peu vite. Finalement comme je le craignais, ça ne fonctionne pas.
Je viens de remplacer tous les +0200 dans le GPX par des -0200
Le "compute" ne plante pas mais génère une heure décalée de 4 heures :

Code:

1682012305879 2023-04-20 19:38:25 0 0 0 M 45,44086 -0,42718 37,2

Donc, si je remets +0200, ça ne fonctionne que parce que mon PC se situe actuellement à un DST de +2h
Et dans quelques jour, après le changement d'heure, ça fournira 14:38:25 au lieu de 15:38:25

Désolé
Pulsar33

Non, parce que lorsque l'on sera en heure d'hiver, tu auras :

2020-12-13T07:55:48+0100

et non pas "+0200"

Essaie la commande (non documentée) :

Code:

./tools/gpxtools test

Décidément je ne dois pas m'exprimer correctement
Lorsqu'on sera à l'heure d'hiver, le contenu de mon GPX n'aura pas changé et si je traite le fichier, j'aurai donc une heure de moins dans le CSV ou sur le rendu qu'aujourd'hui à l'heure d'été.

L'heure actuelle ou future du PC ne doit avoir aucun impact sur la génération qui ne dépend QUE du contenu du fichier
Il me semblait pourtant l'avoir clairement expliqué

Bonne soirée
Pulsar33

Et s'il faut encore argumenter, je viens de faire un enregistrement de trajectoire avec Geovelo

Code:

Enregistrement démarré à 19:00:35
    <time>2024-10-20T19:00:35+02:00</time>
Premier point
    <time>2024-10-20T19:00:35+02:00</time>
Dernier point
    <time>2024-10-20T19:42:20+02:00</time>

Ceci confirme bien que l'heure indiquée dans le GPX est l'heure locale et que le +02:00 caractérise la zone et l'heure d'été auxquelles a été fait l’enregistrement
On peut en déduire l'UTC en soustrayant la zone mais cela ne devrait pas être fait ou alors devrait être compensé plus tard

Le fichier est daté de 19:50:04 heure de fin de téléchargement sur le smartphone par l'application Geovelo

Si je traite ce fichier aujourd'hui, j'aurai bien 19:00:35
Si je traite ce fichier dans 15 jours, j'aurai 18:00:35 qui ne correspondra pas à l'heure de mon trajet

Cordialement
Pulsar33

Non, ça ne sera pas le cas, ça fonctionnera correctement.

Quand ton GPX donne :

2024-10-20T19:00:35+02:00

Je convertis en utc, qui donne 17h... et ça quelque soit le jour où je ferai le calcul.

Au moment du rendu, je fais la conversion en locale, et ça redonnera 19h, car pour savoir l’offset à appliquer par rapport à l’heure utc, il utilise la date (ici 20/10/2024) et non la date du jour de génération.

C'est une bonne nouvelle si tu n'utilises pas l'heure actuelle du PC mais alors explique-moi pourquoi la commande compute génère actuellement des valeurs différentes si la zone est modifiée :

Code:

<time>2023-04-20T15:38:25.879000+0200</time> génère
1681997905879 2023-04-20 15:38:25 0 0 0 M 45,44086 -0,42718 37,2

<time>2023-04-20T15:38:25.879000-0200</time> génère
1682012305879 2023-04-20 19:38:25 0 0 0 M 45,44086 -0,42718 37,2

@+ Puls

Pulsar33 a écrit:

C'est une bonne nouvelle si tu n'utilises pas l'heure actuelle du PC mais alors explique-moi pourquoi la commande compute génère actuellement des valeurs différentes si la zone est modifiée :

Code:

<time>2023-04-20T15:38:25.879000+0200</time> génère
1681997905879 2023-04-20 15:38:25 0 0 0 M 45,44086 -0,42718 37,2

Donc ici 15h38 avec un offset de +2h, on est le 20/04. Donc heure française (été)

Comme il utilise ton pc uniquement pour connaître ton fuseau horaire, il retrouve bien 15h38.

Pulsar33 a écrit:

Code:

<time>2023-04-20T15:38:25.879000-0200</time> génère
1682012305879 2023-04-20 19:38:25 0 0 0 M 45,44086 -0,42718 37,2

@+ Puls

Ici 15h38 avec un offset de -2h, on est le 20/04. Donc heure dans le fuseau horaire UTC-2 donc +4 pour passer en France.

En fait gpx2video ne permet pas de générer une vidéo avec un fuseau horaire différent de ton PC.

Ce qui est un problème, ex : tu fais une sortie vélo pendant tes vacances au Brésil (utc-3)
Lors du rendu que tu feras sur ton pc à ton retour à la maison, il affichera l’heure française lors du rendu et non l'heure locale lors de l’exercice.

(Feature qu'on m’a demandé, mais pas encore implémentée)

Bon, tu exprimes les choses autrement mais tu confirmes enfin ce que j'explique depuis de nombreux messages. Actuellement, l'heure (et la date) locale du PC qui effectue le traitement influence l'heure qui sera affichée.
Or, ce n'est pas ce que l'on veut.
Quelle que soit la zone dans laquelle a été fait l'enregistrement et quelles que soient l'heure et la zone dans lesquelles sont faits les traitements, l'heure affichée doit être l'heure locale du trajet qui est présente dans le GPX, c'est à dire en ignorant le +/-XXYY
Que tu aies besoin de travailler en UTC peut se comprendre si tu utilises les librairies standard de traitement des heures mais au final, tu dois compenser les choses pour retrouver l'heure locale du fichier.

Bonne nuit
Pulsar33

Le problème est que la plupart des GPX sont en heure UTC.

Les caméras elles n'ont pas non plus la connaissance du fuseau horaire dans lequel elles sont.

Donc ça passera par un paramètre de config pour dire dans quel fuseau horaire tu veux faire le rendu.

Vu que peu font des sorties dans des fuseaux horaires différents, ce n'est pas urgent.

Mais si tu as vraiment besoin,
TZ='America/New_York', /tools/gpx2video....

Et le rendu sera fait aves les heures à New York



D'ailleurs je suis prêt à parier que ton GPX a été généré depuis un site web, et qu'il a utilisé le fuseau horaire de ton PC au moment où tu l'as exporté.
Garmin connect les exporte en utc.

Bonjour,

Je te rejoins au moins sur un point. La specification des waypoints indique :

Code:

Creation/modification timestamp for element. Date and time in are in Univeral Coordinated Time (UTC), not local time! Conforms to ISO 8601 specification for date/time representation. Fractional seconds are allowed for millisecond timing in tracklogs.

Il n'y a pas à parier, comme je te l'avais dit, mes GPX actuels sont générés par l'application Geovelo et modifiés si besoin par le site visuGpx pour obtenir le champ "ele". Je ne sais pas ce qu'enregistre le smartphone en provenance du GPS hardware mais ce qui m'est fourni par le site Geovelo à l'issue du téléchargement est effectivement en heure locale. Cependant, les heures sont conformes à l'ISO 8601 qui comprends les formats suivants pour le champ time :

Code:

Local time (unqualified) : If no UTC relation information is given with a time representation, the time is assumed to be in local time
Coordinated Universal Time (UTC) If the time is in UTC, add a Z directly after the time without a space
Time offsets from UTC : The UTC offset is appended directly to the time instead of "Z" suffix above ... '±[hh]:[mm]' '±[hh][mm]' or '±[hh]'

Le GPX fourni par Geovelo est en heure locale comme indiqué par les '±[hh][mm]'
Le GPX corrigé par visuGpx est aussi en heure locale mais indiqué par '±[hh]:[mm]'
Dans un cas comme dans l'autre, la présence de ces deux formats exprime sans ambiguïté que c'est une heure locale et te fournit le moyen de retrouver l'UTC.
Je ne vois pas pourquoi une option serait nécessaire dans ce cas. Il suffit que l'heure finale calculée soit égale à l'heure locale du GPX.

Si de nombreux GPX qui te sont soumis sont en UTC, ils doivent respecter l'ISO 8601 et le champ time doit contenir un Z, ce qui te permet de lever le doute.
Dans ce cas ou bien si le champ time est "unqualified" tu n'as pas d'autre choix que d'utiliser une option sur la ligne de commande, j'en conviens.

Mais dans tout ce que je viens d'évoquer, je répète que l'heure actuelle du PC au moment du traitement ne doit en aucun cas jouer sur le résultat.

Bonne journée
Pulsar33

Pour être plus complet sur les cas d'utilisation de ton logiciel, avec mes caméras sans GPS je peux aussi utiliser ce GPS Bluetooth connecté à mon Smartphone ou à un PC portable.


Dans ce cas, j'utilise l'enregistrement des trames NMEA 183. On voit bien dans le terminal l'heure locale (11:41:40.310) et l'heure UTC de la trame 094140.000
Il me faut alors convertir les trames GPGGA pour obtenit directement l'heure et la position 3D et exporter cela au format GPX.
Je peux pour cela utiliser un programme perso, ou bien gpsbabel (jamais essayé) ou bien Github/richhowley/NMEAtoGPX par exemple (jamais essayé non plus).

Dans tous les cas, le format de l'heure devra être conforme à l'ISO 8601

Bonne journée
Pulsar33

Bonsoir,

Pour info, j'ai légèrement modifié le script Python de richhowley sur GitHub pour l'adapter à mes besoins (fins de lignes, format des champs retenus, suppression de champs inutiles)
N'ayant que l'heure UTC dans les trames NMEA, le format de mes dates est celui-ci : 2005-03-08T09:18:16Z et lorsque je lance un "compute", j'obtiens 2005-03-08 10:18:16
Il se confirme donc bien que la conversion utilise la date à transcoder pour déterminer le DST (elle considère qu'on était en hiver même si on est encore en été)

Bonne soirée
Pulsar33