Détection d’un probable problème entre VisuGPX et VisuGPX ?!

C'est pas la fréquence cardiaque, c'est la cadence (nombre de pas par minute). Récupérée sur les mouvements des bras (accéleromètre de la montre) ??

Effectivement elle n'apparait que de façon erratique, et l'altitude n'est récupérée par mon parseur que lorsque la cadence est aussi définie.

Bref, je suis dessus.

Admin a dit :C'est pas la fréquence cardiaque, c'est la cadence (nombre de pas par minute).
Désolé, j'ai utilisé à tort le terme de fréquence. Il s'agit bien de cadence. La montre Spartan (et d'autres probablement) dispose effectivement d'un podomètre.
C'est étrange ces données de cadence erratiques...

Tu utilises GPSBabel pour la conversion?

C'est la référence dans ce domaine pour gérer la profusion de formats GPS. GPSVisualizer entre autres utilise ce programme et n'a pas eu de pb avec le fichier Suunto.

Il en existe une version Linux et le code est Open Source donc tu devrais pouvoir intégrer cela "facilement" à VisuGPX.

Non j'utilise une lib phpFitFileAnalysis, mais visiblement buggée 😡

Oh là, oh là ! la bonne blague ! moi pas être au courant de tout ça ! alors pour avoir la correction barométrique en fonction de la température la plus précise possible, je fixe ma montre sur le haut de mon sac, il est donc parfaitement normal que ma cadence soit totalement erratique ! si ça peut t'aider à debugger je peux t'envoyer un fichier FIT de la Marmotte qui elle garde sa montre au poignet et va très très lentement !!!...

Angstrom a dit :Pour aller plus loin, il faudrait savoir comment l'import dans VisuGPX se fait:
1) est-ce la fonction "combler" qui est utilisée? Si oui, cela veut dire que les points dont les valeurs d'alti sont manquants vont être renseignés à partir du MNT, alors que ceux présents resteront. Si le baro n'est pas parfaitement calé, il y aura des différences de calcul de D+/D-, fatalement.
Si je peux encore apporter mon petit grain de sel à cette conversation : je pense que cette solution est une des plus mauvaise qui soit et a toutes les chances de compromettre l'avenir, pour les raisons suivantes:
1 - très bien vues par Angstrom les mesures d'altitudes obtenues avec un altimètre barométrique ou par mesure GPS ou un savant mélange des deux ont toutes les chances de ne pas être statistiquement homogènes avec celles issues d'une base de données quelle qu’elle soit, alors il me semble que ce comblement introduit forcément un biais plus ou moins conséquent qui
2 - risque de compromettre les performances de la fonction d'élimination des mesures aberrantes et leur lissage du genre de celles que j'avais proposé de tester au cours de notre premier confinement si je me souviens bien et que peut-être un jour Admin (*) adoptera afin de s'extraire à jamais de cette fonction de seuillage sans aucun fondement scientifique, le simple fait qu'elle soit mise en œuvre par la quasi-totalité des opérateurs ne saurait lui conférer pour autant une quelconque légitimité; cette incongruité hérisse fortement les poils de l’Ours et, à force, va lui coller un eczéma avant qu’il ne trépasse ! pour moi et bien d'autres, seule la fonction de lissage est scientifiquement pertinente !
Alors comment procéder ? il me semble que le plus rigoureux est de combler les trous par une des nombreuses fonctions d'interpolation des données manquantes dans un tableau, dont la plus basique est évidemment l'interpolation linéaire; professionnellement j'utilisais la géniale fonction INTERPLT qu'un Japonais avait publiée dans la revue IEEE dans les années 70, que malheureusement je n'arrive pas à retrouver sur Internet.
Reste que cette manière de faire en corrélant les mesures faussera d'autant plus la statistique suivante que les trous seront nombreux ! en conclusion avoir des données mitées n'est jamais bien bon pour obtenir des résultats probants aussi géniales que soient les fonctions utilisées !...

(*) suggestion pour Admin : vu que tu n’as pas le temps d’étudier une autre solution, si ça te paraît possible, pourquoi ne pas profiter de la profusion d’universitaires ou autres élèves ingénieurs sur Grenoble pour proposer à quelques-uns, une saine émulation étant toujours profitable, un sujet de stage du genre :
recherche bibliographique parmi les fonctions existantes les plus pertinentes susceptibles de répondre au problème, les tester en les adaptant et surtout ne pas se priver d’en inventer de nouvelles. Le défi à relever étant d’aboutir à une fonction auto-adaptative qui, d’où que proviennent les mesures d’altitudes dès lors qu'elles sont en nombre suffisant en terme statistique, calcule les dénivelés cumulés avec une précision inférieure ou égale à 1%. A ce titre, les traces des cyclotouristes de la base de données de VisuGPX devraient être une véritable mine d’or propre à faire baver beaucoup de chercheurs. Si je ne devais prendre qu’un seul exemple ce serait le dernier publié en tant que récit sur VisuGPX les 5 Gorges de l’Aude qui avec ses 263 km et 23825 points de mesure me paraît être excellent, le défi étant de trouver la fonction qui à partir de plusieurs familles de mesures GPS mais également issues de plusieurs routeurs conduise à toujours obtenir au final D+ = D- = 3800 m avec une précision d’au moins 1% , soit 3762 m < |D| < 3838 m. D'autant qu’il ne m'étonnerait guère que dès qu’il le pourra Admin n’aille pas voir s’il peut passer sous la barre des 10h sur ce beau circuit !? 😜 😎

la Marmotte & l'Ours a dit :avec une précision inférieure ou égale à 1%.
Il est bien évident qu'il faut lire supérieure ou égale à 1%. Décidément je n'arriverai jamais à écrire un message sans coquille du premier coup et je n'ai toujours pas compris comment il faut procéder pour en tester le rendu avant de cliquer sur Oui, c'est ça !
MERCI à une âme charitable de bien vouloir éclairer ma lanterne !