GoPro & Linux

Bonjour,

J'ai fait pas mal de remarques et de suggestions qui s'étalent sur plusieurs pages de ce fil, mais en effet, le point majeur concerne l'impact croisé du rééchantillonnage et du filtrage des coordonnées. Si l'on veut aboutir, il faut mettre les choses dans l'ordre et ne rien oublier. Je ne suis pas d'accord avec ta remarque, même si j'ai bien noté que tu n'as pas encore implémenté le traitement "sub-secondique". Ma vision est plutôt celle-ci.

Tout d'abord, je crois me souvenir que tu souhaitais pouvoir traiter les données avec une période plus courte que la seconde pour "certaines utilisations qui t'ont été signalées". Si la plupart des vieux GPS fournissaient des coordonnées à la seconde, il semble que désormais cette limitation est abolie. Comme par ailleurs, les vidéos sont encodées à des fréquences pouvant être comprises entre 25 et 60 Hz voire plus, avec même des valeurs exotiques genre 29.97, il faut bien se résoudre à rééchantillonner le plus proprement possible. A cet effet il y a au moins deux méthodes basiques connues : le plus proche voisin (ce que fait de manière détournée ton patch "skip if same time") et l'interpolation linéaire (le traitement vectoriel ne semble pas utile à ce niveau de précision souhaité).

A l'issue du parsing des données entrantes, pour lesquelles je ne parlerai que de lat/lon/alt/time (ce qui est nécessaire et suffisant pour faire le job) le plus judicieux est donc de rééchantillonner celles-ci en fonction du timestamp demandé pour la vidéo de sortie, idéalement par interpolation entre les deux timestamp les plus proches. Je n'ai pas expérimenté d'autres données, n'en disposant pas, mais le même mécanisme s'applique sans doute aisément.

Une fois cette liste ordonnée de points 4D obtenue et calée sur la vidéo de sortie (il est simplificateur de faire ce traitement d'un seul bloc), il convient de constater que les données de position 3D sont bruitées. Comme indiqué plus haut et démontré par la vidéo, le bruit sur les lat/lon relativement à l'affichage nécessaire pour la map et la trajectoire n'est absolument pas significatif et un filtrage de ces coordonnées à cet effet est même plutôt défavorable car il aplatit les trajectoires.

En revanche, il n'en est pas du tout de même pour la pente et la vitesse qui dérivent des coordonnées 3D surtout que l'altitude est moins précise par construction ou en fonction de sa source qui n'est pas forcément le GPS (ex : utilisation du modèle numérique de terrain de visugpx quand l'altitude est absente). Comme indiqué également plus haut et démontré aussi par la vidéo, un filtre du deuxième ordre avec un coefficient d'amortissement de 0.7 sur 6 cycles donne de bons résultats. Ce filtre nécessite de mémoriser les deux points 3D précédents pour calculer le point courant et le résultat doit être décalé de 6 cycles pour absorber le retard dû au filtre (ie : on utilise lat7/lon7/alt7 pour calculer les valeurs à incruster dans l'image 1 pour laquelle la carte et la trajectoire sont positionnées au même instant en fonction de lat1/lon1).

En attendant que tu aies intégré le traitement "sub-secondique", je peux tout à fait modifier mon outil gpxFilter pour ramener les données à la seconde mais ça ne changera rien au problème : la position 2D ne doit pas être filtrée alors que la pente et la vitesse doivent l'être. Même si je te fournissais une altitude filtrée avec des lat/lon non filtrées pour l'affichage, la vitesse que tu afficherais serait toujours aussi instable.

J'espère que c'est exprimé clairement
Pulsar33

PS : pour ceux qui en auraient besoin, le site visugpx permet sans inscription d'importer un gpx et de re-télécharger immédiatement la même trajectoire avec l'altitude renseignée
Il est inutile de compléter tous les champs ni de sauver la trajectoire, elle disparaîtra d'elle-même

Hello,

Alors je pense que tu ne l'attendais plus... mais voilà une première mise à jour.

A présent, tu peux utiliser un fichier CSV au lieu du GPX (toujours avec l'option "-g"). Les colonnes du CSV doivent avoir le même nom que celles de l'export.
Par contre l'ordre des colonnes peut être modifié et les colonnes sont optionnelles (à part le timestamp, lat, lon).

Il manque encore beaucoup de contrôle sur la validité sur format des points, mais cela arrive.

Néanmoins, cette fois les calculs devraient être exacts (et plus approximatifs lorsque les timestamp sont à la ms)

Un nouvel outil est ajouté "gpxtools" qui permettra à terme plusieurs manipulation sur les fichiers GPX / CSV.

En cours :
- pouvoir utiliser plusieurs fichiers de télémétrie et pouvoir les sélectionner pour chaque jauge.
- concaténer des GPX / CSV
- ajout de d'autres formats TCX, FIT
- pouvoir modifier le taux de rafraîchissement des données de télémétrie (pour l'instant, un point par seconde)

Enfin, je vais maintenant travailler sur le filtrage.

Pour information, pour l'instant l'algo lit les points au fur et à mesure. Dans un second temps, il prédit un point chaque seconde.
Sur un GPX où les points sont à la milliseconde, il va prédire chaque point (en fait calculer un point à la seconde).

Ce n'est qu'une première étape !

Bonjour,

Alors je ne peux que te remercier pour cette évolution que j'ai longuement réclamée mais effectivement je ne l'attendais plus, c'est pourquoi je t'avais indiqué plus haut que j'avais codé de mon coté.

Pulsar33 a écrit:

Finalement, j'ai codé le petit outil de filtrage du gpx et le résultat me semble tout à fait satisfaisant
J'ai mis un filtre d'ordre deux sur chaque coordonnée avec un coefficient d'amortissement de 0.7 sur 6 cycles
Il me semble inutile de filtrer en vectoriel ni avec des prédictions pour le résultat attendu et compte tenue de la trajectoire intégralement connue.
Les 6 cycles de décalage du filtre sont éliminés dans le fichier de sortie au prix de la perte des 6 derniers points du fichier ce qui n'est pas un problème.
[...]
On voit clairement que le filtre réduit l'amplitude des coordonnées. Il en résulte un aplatissement de la trajectoire dans les ronds-points assez visible
Il faudrait donc conserver les positions non filtrées car à l'échelle de l'affichage, leurs variations non désirées ne sont pas visibles
[...]
Sur un faux-plat assez long, on voit nettement que la pente non filtrée dit n'importe quoi
La pente non filtrée varie de -7% à +12%, avant et après les ponts, et même à -12% fugitivement
A l'inverse, la pente filtrée reste sagement autour de 1% ce qui correspond très bien à la réalité
Il faudrait donc utiliser les positions filtrées pour calculer la pente, la vitesse et ce qui en découle
[...]
Hélas, de l'extérieur du programme, je ne fournis que les positions, donc filtrées ou non filtrées.
Seul gpx2video pourrait en interne utiliser les non filtrées pour les positions et la trajectoire, et les filtrées pour les valeurs dérivées

D'après ce que tu dis (les colonnes sont optionnelles, à part le timestamp, lat, lon) et le alt je suppose, tu recalcules donc les dérivées après avoir ré-échantillonné le fichier d'entrée. Du coup, je ne ferai pas mieux avec le CSV qu'en modifiant le GPX que je te fournis en entrée.
Je reste sur les conclusions que j'ai faites : les latitudes et longitudes utilisées pour l'affichage de la carte et la trajectoire ne doivent pas être filtrées mais elles doivent l'être ainsi que l'altitude pour calculer les dérivées (pente et vitesse) et afficher l'altitude.

Autre point sur lequel je rebondis car je l'avais déjà signalé : tu parles de "prédire" et je ne comprends pas pourquoi. Cette fonction est utile lorsqu'on essaye de localiser avec précision un objet mobile rapide dont on ne connaît pas la trajectoire future (centrale inertielle par exemple, mais cela nécessite de l'hybridation sinon elle dérive forcément). En revanche, ici, la trajectoire étant intégralement connue dès le départ, cette fonction de prédiction ne peut qu'apporter du bruit et générer du traitement inutile par rapport à un simple filtrage.

Bonne journée
Pulsar33

PS : je vais bien sûr essayer ta nouvelle version dès que possible et je te tiendrai au courant

Attention, je le suis peut être mal exprimé.

1/ lorsque tu importes les données de télémétrie depuis un CSV, si les colonnes sont présentes, je les utilise et n'effectue pas les calculs correspondants. Je calcule uniquement les données non renseignées.

Cela te permet de garder les anciennes valeur lat et lon et de remplacer toutes les autres colonnes par tes valeurs calculées.

2/ Kalman n'est pas utilisé pour filtrer, mais pour calculer (prédire) un point après une série de points connus (pas besoin de connaître le suivant).

Sur tes GPX tu as un point toutes les secondes. Or sur un garmin, tu peux avoir un point toutes les 10 secondes. Et surtout l'intervalle entre chaque point est variable. Or pour appliquer un filtre les points doivent respecter un intervalle de temps fixe.

Donc avant d'appliquer un filtre comme ce que tu proposes (chose que je vais à présent implémenter) il faut que tous les points soient à intervalle de temps régulier.

Donc les étapes sont :
- lire n points
- ré-échantiolloner à la seconde (ça sera paramétrable)
- filtrer sur k points
- effectuer les calculs (comme tu proposes)
- afficher le résultat

Prochainement on pourra plus facilement les résultats on affichant les jauges en double en précisant pour l'une un gpx et pour l'autre un csv.

Bonsoir,

En effet je comprends mieux ce que je peux tirer de l'option CSV. Je vais tester ça.

Pour le rééchantillonnage à la seconde, je comprends aussi ce que tu veux faire mais j'ai du mal à me convaincre que Kalman soit nécessaire.
Même si tu n'as qu'un point tous les 10 secondes, vu la précision souhaitée, l'intervalle de temps et la vitesse, de simples interpolations linéaires me semblent suffisantes.
Elles sont surtout susceptibles de ne pas générer de bruit, d'autant plus que comme je le disais, le point suivant est connu de même que toute la trajectoire.

Bon courage pour la suite
Pulsar33

Kalman c'était surtout pour voir comment ça marche

Mais je te l'accorde une interpolation linéaire (mode par défaut d'ailleurs) est largement suffisant.

Bonjour

PC fixe planté ce matin. SSD ou carte mère ?
Désolé pour le délai

Bon dimanche
Pulsar33

PS : a priori ni l'un ni l'autre, ouf.
Un disque de DATA a des faiblesses. Journée maintenance en perspective

Bonsoir,

Désolé pour ce délai dû au crash disque

Alors, premiers constats :
1) gpx2video n'est plus dans build mais dans build/tools (bon, faut juste ne pas réutiliser l'historique des commandes )
2) --telemetry N a changé en --telemetry-method=N (d'ailleurs, tous les champs ne nécessitent pas de = c'est perturbant)
3) La doc n'est pas à jour pour la commande compute dans le .MD : ./gpx2video -g ACTIVITY.gpx -o data.csv --telemetry=0 compute
4) --telemetry-method=N n'est pas optionnel pour la commande compute (si absent, ça boucle en mangeant la mémoire et le swap)
5) Si une heure du GPX est sans fraction décimale de seconde (tombe juste) le CSV redémarre le temps à 0 (champ time trop stricte)
6) Un GPX de 1h28'42" génère un CSV de 4377 lignes alors que le temps termine bien à 5321 ... Pourquoi ?

Bon, avec tout ça, je n'ai pas encore pu essayer de mixer des colonnes non filtrées avec des colonnes filtrées
Ce sera pour demain j'espère ...

Bonne soirée
Pulsar33

Bonjour,

Bon, une fois les problèmes de format de CSV compris et contournés, j'arrive à mixer les données souhaitées mais ça plante.
C'est pénible le format des CSV : il faut les ouvrir en "langue française séparée par des virgules" ce qui fait que les flottants ne sont pas exploitables.
Il serait plus efficace d'utiliser le format anglais avec séparateur point-virgule

Je m'interroge sur l'utilité de la méthode de télémétrie dans ce cas d'utilisation mais si on ne la spécifie pas, on explose la mémoire et le swap.
Pour autant, le résultat est pratiquement le même pour les méthodes 0 et 3 :

Code:

pulsar33@Minerve:/media/DATA/Technique/Velos/Pacman/Trajets$ /media/DATA/Workbench/gpx2video/build/tools/gpx2video -q --video-preset=ultrafast --video-crf=25 --telemetry-method=3 -m Jonzac02O.mp4 -g Jonzac02-Mix.csv -l layout576p-best.xml -o Jonzac02-VGO.mp4
gpx2video v0.0.0
Parsing 'layout576p-best.xml' layout file
  Download tile 2418 / 2418 [##################################################] DONE      
[FRAME    49] 00:00:01.960 / 01:12:08.520 |   0% - Remaining time: 16:33:20Abandon (core dumped)

Code:

pulsar33@Minerve:/media/DATA/Technique/Velos/Pacman/Trajets$ /media/DATA/Workbench/gpx2video/build/tools/gpx2video -q --video-preset=ultrafast --video-crf=25 --telemetry-method=0 -m Jonzac02O.mp4 -g Jonzac02-Mix.csv -l layout576p-best.xml -o Jonzac02-VGO.mp4
gpx2video v0.0.0
Parsing 'layout576p-best.xml' layout file
  Download tile 2418 / 2418 [##################################################] DONE      
[FRAME   599] 00:00:23.960 / 01:12:08.520 |   0% - Remaining time: 02:05:45Abandon (core dumped)

Voici le début du fichier CSV. Les Lat/Lon sont non filtrées et les Ele/Speed sont filtrées :

Code:

Timestamp, Time, Lat, Lon, Ele, Speed
1682005105,2023-04-20 17:38:25, 45.44086, -0.42718, 37.2,0
1682005106,2023-04-20 17:38:26, 45.44087, -0.42718, 37.2,0
1682005107,2023-04-20 17:38:27, 45.44088, -0.42717, 37.2,0
1682005108,2023-04-20 17:38:28, 45.44089, -0.42717, 37.2,0
1682005109,2023-04-20 17:38:29, 45.4409, -0.42717, 37.2, 3.8471675
1682005110,2023-04-20 17:38:30, 45.44092, -0.42717, 37.2,0
1682005111,2023-04-20 17:38:31, 45.44093, -0.42717, 37.2, 4.0702484
1682005113,2023-04-20 17:38:33, 45.44096, -0.42717, 37.2,0
1682005114,2023-04-20 17:38:34, 45.441, -0.42717, 37.2, 2.8120929
1682005115,2023-04-20 17:38:35, 45.44102, -0.42716, 37.2, 4.0130935
1682005116,2023-04-20 17:38:36, 45.44104, -0.42713, 37.2, 8.0261869
1682005118,2023-04-20 17:38:38, 45.44106, -0.42707, 37.2, 2.8481028
1682005119,2023-04-20 17:38:39, 45.44106, -0.42702, 37.2, 6.7328137
1682005120,2023-04-20 17:38:40, 45.44107, -0.42697, 37.3, 8.3333447
1682005121,2023-04-20 17:38:41, 45.44107, -0.42694, 37.4, 7.0722214
1682005123,2023-04-20 17:38:43, 45.44107, -0.42691, 37.4, 4.8735446
1682005124,2023-04-20 17:38:44, 45.44107, -0.42689, 37.5, 6.8141597
1682005126,2023-04-20 17:38:46, 45.44107, -0.42686, 37.6, 4.7314136
1682005128,2023-04-20 17:38:48, 45.44108, -0.42683, 37.7, 8.4698829
1682005129,2023-04-20 17:38:49, 45.4411, -0.42681, 37.8, 5.7077345
1682005130,2023-04-20 17:38:50, 45.44112, -0.4268, 37.9, 6.9442752
1682005132,2023-04-20 17:38:52, 45.44115, -0.42679,38, 4.6816557
1682005133,2023-04-20 17:38:53, 45.44115, -0.42678, 38.1, 10.624165

Si tu as besoin d'autre choses, je suis là
Pulsar33

Quelques bonus si l'on peut dire :

J'ai essayé aussi avec les méthodes 1 et 2, ça plante pareil. Le plantage intervient plus ou moins tôt selon la méthode.
Avec la méthode 2 j'ai réussi à obtenir 1'20" de vidéo et je constate que la vitesse et la pente font un peu n'importe quoi.

Dans les modes utilisant le CSV en entrée, les marqueurs de départ et d'arrivée ne s'affichent pas.

J'ai essayé la méthode 2 avec un CSV complet non modifié généré par "compute". Là ça ne plante pas (du moins j'ai testé jusqu'à plus de 6 minutes)
L'altitude et la pente font un peu n'importe quoi. Par exemple la pente affiche -2  0  +2  0 à chaque seconde alors qu'elle était stable avec la version d'avant.
Je vérifie du coup en utilisant le GPX d'origine et j'ai les mêmes défauts. C'est donc un problème global de ré-échantillonnage et non un problème liée au CSV.

En l'état actuel, la nouvelle version régresse par rapport à "skip if same time"

@+ Pulsar33

Hello,

J'ai principalement testé avec un GPX en entrée et non un CSV. (pour être sûr de ne pas avoir trop de régression).

Je vais tester davantage avec un CSV (fr & en)

J'ai poussé quelques fix pour des problèmes que tu as soulevés :
- détecte le caractère de séparation des CSV ("," ou ";")
- parse les nombres "fr" ou "en" (37,3 vs 37.3)

Si tu m'envoies tes fichiers (surtout les GPX/CSV) avec les commandes gpx2video que tu as utilisées ; je pourrai reproduire le problème.

Et effectivement l'exécutable est dans le dossier "tools" avec son binôme "gpxtools".

Merci, je regarde ça demain et je prépare une archive.
Tu parles du parsing "variable" du CSV. Tant mieux si tu as pu le faire.
J'avais plutôt dans l'idée que tu "compute" au format [en] avec séparateur [;]
C'est le plus générique et le plus facile.

Bonne soirée
Pulsar33

Bonjour,

Question préalable :
Le lien vers assets doit-il désormais être dans tools ou rester dans build ?
La doc .MD est-elle à jour ?
$ git clone https://github.com/progweb/gpx2video.git
$ mkdir gpx2video/build
$ cd gpx2video/build
$ cmake ..
$ make
$ ln -s ../assets assets
$ ./gpx2video -h
Please execute gpx2video tool from the build path so as it finds assets data.

Pour info, je n'exécute jamais gpx2video depuis build mais au contraire depuis le dossier contenant les données afin de simplifier les chemins, comme ci-dessous :
/media/DATA/Workbench/gpx2video/build/tools/gpx2video -q --video-preset=ultrafast --video-crf=25 -m Jonzac02O.mp4 -g Jonzac02-VGO_F.gpx -l layout576p-best.xml -o Jonzac02-VGO.mp4

@+ Pulsar33

Le dossier assets doit être dans le dossier depuis lequel tu exécutes gpx2video.

Donc si tu exécutes l'application depuis le dossier qui contient tes vidéos, il suffit de faire un lien assets dans ce dossier.

Je vais m'occuper de ce point (puisque à terme ça sera dans /usr/share....)

Exact !
Depuis le temps j'avais oublié que j'avais mis le lien dans ce dossier aussi
@+ Pulsar33

Alors,

Dans un premier temps, je reviens sur la commande "compute" (en particulier le point 5 cité plus haut) qui pose problème avant de relire un CSV en entrée
Ce que j'indique est valable pour "improve CSV parsing" comme pour "Re-factor telemetry data management"
J'ai identifié ce qui coince et c'est plus judicieux de te montrer directement le problème plutôt que t'envoyer les fichiers pour l'instant.
Il se trouve que mes GPX contiennent des heures au format hh: mm:ss.xxxxxx+0200
Mais il y a quelques cas quand ça tombe juste au format hh: mm:ss+0200
La commande "compute" fonctionne lorsque le DST affiche +0200

Mais comme je te l'avais signalé il y a longtemps, le décalage n'est pas géré. Pire, le décalage en cours sur la machine semble s'ajouter.
Ce qui fait qu'une trace enregistrée à 15:36:39.824000+0200 (c'est à dire en réalité à 13:36:39.824000 GMT) est affichée à 17:36:39 actuellement.
Pour essayer de contrer ce phénomène, j'avais modifié +0200 en -0200 mais ça n'a eu aucun effet, ce champ est ignoré visiblement
Il faudra qu'on reparle de ce problème mais il se trouve que ça fait planter le parsing si le DST est négatif et si l'heure n'a pas de décimales.
Coup de chance de l'avoir vu !

Voici ce que ça donne :


@+ Pulsar33

Bon, une fois le problème particulier ci-dessus traité, franchement, reviens au ré-échantillonnage. Les CSV attendront.
Comme je le disais plus haut :

Pulsar33 a écrit:

L'altitude et la pente font un peu n'importe quoi. Par exemple la pente affiche -2  0  +2  0 à chaque seconde alors qu'elle était stable avec la version d'avant.
Je vérifie du coup en utilisant le GPX d'origine et j'ai les mêmes défauts. C'est donc un problème global de ré-échantillonnage et non un problème liée au CSV.

Voici un lien pour télécharger quelques minutes de vidéo générées sur un trajet bien connu de 2023 à Jonzac.
La partie haute de la vidéo est générée avec ta version actuelle "Improve CSV parsing" mais je pense que le mal vient déjà de "Re-factor telemetry data management"
La partie basse est générée avec "GPX skip point if same time" qui est pour l'instant la meilleure version que j'ai vue.
Dans les deux cas, je fournis en entrée les mêmes données GPX filtrées par mon outil gpxFilter dont j'ai parlé plus haut.
Regarde bien les variations d'altitude et de pente, en particulier dans la côte.
Je ne sais pas ce que tu as cassé dans le ré-échantillonnage mais c'est beaucoup plus instable dans la nouvelle version que dans l'ancienne.

@+ Pulsar33

Dans la nouvelle version, il n'y a plus le filtrage "sommaire" que j'avais implémenté (un simple moyenneur)

Je vais corriger les problèmes puis implémenter un filtre comme celui que tu as fait. Tout en conservant les coordonnées pour la carto.

OK, cool
Bon courage
Pulsar33

J'ai retravaillé sur la partie parsing des GPX / CSV et leurs exports (notamment avec l'outil gpxtools)

J'ai fait plusieurs corrections sur le parsing de la date ; je pense que ça devrait fonctionner correctement à présent avec tes GPX.

Attention, à présent :
- l'indication de fuseau horaire est prise en compte.
- le timestamp exporté dans le CSV est en milisecondes
- on ne perd plus le dernier point du GPX
- gpxtools exporte au format CVS ou GPX 1.1 avec les extensions si les données sont présentes
- l'export au format CSV comprend la température

Si tout est OK, je vais attaquer le filtrage des données.

Bonsoir,

Merci. J'essaye de voir ça ce weekend et je te dis ...

Cordialement
Pulsar33

Bonjour,

Le plantage d'importation GPX avec -0200 est bien corrigé et le DST est pris en compte mais je ne suis pas certain que ce soit le bon traitement
Je viens d'installer sur mon smartphone Fitotrack qui intègre directement l'altitude dans le GPX au lieu de geovelo qui nécessite de recourir à visugpx après coup.
Les formats sont radicalement différents. Je réfléchis à tout ça ...

Franchement, comme déjà dit, attaque-toi sérieusement au ré-échantillonnage et au filtrage, le reste c'est du détail

A plus tard
Pulsar33

Bonjour,

FitoTrack ne m'apporte finalement pas grand chose. S'il y a bien l'élévation dans le GPX, elle semble entachée d'un ratio que je ne comprends pas.
Par ailleurs, je n'arrive pas à obtenir plus de 3 ou 4 points par minutes, ce qui est beaucoup trop faible et rédhibitoire

Concernant le champ TIME et l'ajustement DST, j'ai du mal à comprendre ce qu'il faut réellement faire même en lisant ce paragraphe de Wikipédia
C'est la norme à laquelle se réfère la structure des fichier GPX. Prenons l'exemple de la valeur 023-04-20T15:38:40.910000+0200 présente dans mon GPX. Je peux la comprendre de deux façons :
1) l'enregistrement du point a été fait à 15:38:40.91 heure locale avec un décalage inclus de 2 heures par rapport à l'UTC (permettant de retrouver l'UTC si besoin par soustraction)
ou bien
2) l'enregistrement du point a été fait à 15:38:40.91 UTC qu'il faut décaler de 2 heures pour obtenir l'heure locale (par addition donc)
Or nous voulons incruster évidemment l'heure locale. Dans le premier cas il ne faut pas ajouter l'offset, dans l'autre il faut l'ajouter.
Et dans tous les cas, il ne faut pas tenir compte de l'offset actuellement en cours sur la machine qui fait les calculs.

Tu as visiblement fais le choix numéro 2, ce qui reste à valider, mais de plus, avec ta version actuelle, je constate que :

Code:

<time>2023-04-20T15:38:40.910000-0200</time> donne 1681997920910 2023-04-20 15:38:40
<time>2023-04-20T15:38:40.910000+0200</time> donne 1682012320910 2023-04-20 19:38:40

Ceci confirme bien que tu as fait le choix 2) mais que de plus tes calculs ajoutent (involontairement sans doute) le DST en cours actuellement
Dans quelques jours d'ailleurs, le constat devrait changer puisqu'on passera en heure d'hiver.

La levée de doute entre les choix 1) et 2) peut se faire soit par analyse des normes (mais je n'ai pas réussi) soit par la pratique (mais j'ai un problème actuellement avec geovelo)

A suivre
Pulsar33

Mmh ce que j'ai fait n'ai pas bon

Il faut que je fasse l'opposer.

Quand c'est +0200 ça veut dire qu'il faut que j'enlève 2h pour retrouver l'heure UTC.

Je vais corriger cela. Et continuer le filtrage.