VisuGPX au TOP de la précision scientifique, ridiculise STRAVA

la Marmotte & l'Ours a dit :Mon chemin de pensée emmènerait sur une route visant à supprimer les points inutiles sur une base temporelle

et pourquoi pas le plus simplement du monde comme paramètre de la fiche de VisuGPX du même genre que le choix du seuillage et du lissage, pour moi ça place la plus logique est là ?
du moment que ça mise en œuvre et sa modification change les statistiques je ne vois aucune raison de le différentier !
Qu'en pensez-vous ?

la Marmotte & l'Ours a dit :et pourquoi pas le plus simplement du monde comme paramètre de la fiche de VisuGPX du même genre que le choix du seuillage et du lissage, pour moi ça place la plus logique est là ?
du moment que ça mise en œuvre et sa modification change les statistiques je ne vois aucune raison de le différentier !
Qu'en pensez-vous ?
Oui, bien sûr c'est le plus simple. On ne touche pas au fichier.

Bonjour Admin,
Je ne sais pas si tu as beaucoup bossé ou si tu étais porté par la grâce divine les jours où tu as écrit et validé l’algorithme de VisuGPX, mais chapeau bas l’artiste car, pour moi, il n’est pas si éloigné que ça de la perfection et est d’une robustesse quasiment inégalée.
Il y a quelque temps déjà tu m’avais écrit que tu ne pouvais pas réduire ce fameux seuil car ça le faisait dérailler !?
Au moins pour ce qui est des activités pédestres, les seules que j’ai testées avec le tableau comparatif qui est ici .
devrait définitivement de rassurer, ça en est au point que je me demande si c’est bien la peine de te compliquer la vie en rendant ce seuil paramétrable par les usagers alors que, me semble-t-il, remplacer les 0.5 actuels par 0.1 devrait satisfaire les plus exigeants. Même s’il s'en trouvera toujours pour protester que VisuGPX les contrarie en permanence en abaissant à ce point leurs supposées performances !?
Quoi qu'il en soit je te remercie infiniment pour la confiance que tu m’as accordée en m’autorisant aussi simplement à pouvoir mener ce test, étant bien entendu que tu resteras toujours le seul juge sur la suite à y donner.
Bien cordialement.
l’Ours
PS : si tu décides de laisser l'usager libre du choix de ce paramètre entre par exemple [2 et 0,1] je me permets de te suggérer le garde fou suivant, moyennant ce test ultra simple et l’affichage d’une alerte de ce type :
- si la vitesse moyenne est égale ou supérieure à la vitesse maximale :
- ATTENTION "seuil_vitesse_arret" trop grand.
Qu'en penses-tu ?

la Marmotte & l'Ours a dit :je me permets de te suggérer le garde-fou suivant, moyennant ce test ultra simple et l’affichage d’une alerte de ce type :

Autre suggestion du jour : ATTENTION "seuil_vitesse_arret" trop grand. lorsque la durée de pause est supérieur au 1/3 de la durée totale !?.

d'autre part en ayant eu la curiosité de tester quelques autres résultats, n'y a t'il pas un petit souci avec le calcul des dénivelés horaires ?
Sur ta trace VisuGPX affiche une distance de 13,59 km et +987m / -1028 pour par exemple :
- pour une durée d'ascension de 1h37m32s un dénivelé horaire de 590m alors que j'en trouve 607,2 soit 607m/h
- pour une durée de descente de 1h03m32s un dénivelé horaire de -926m alors que j'en trouve 970,8 soit -971m/h
aurais-tu une idée de mon erreur ou de la tienne !?
Bien cordialement
l'Ours

Salut, le temps de pause inclue aussi les arrêts de quelques secondes, peut-être que c'est ce qui te perturbe ?

Pour le calcul de la vitesse d'ascension, elle se limite à des pentes >3% sur au moins 200m, en dessus j'ai pensé que ce n'était pas significatif.

Admin a dit :peut-être que c'est ce qui te perturbe ?

Bonsoir Admin,

En fait rien ne me perturbe vraiment, les Ours étant des plus basiques que ce soit, pour eux le dénivelé horaire à afficher dans les stats me paraît être égal au dénivelé total divisé par le temps en s affiché du déplacement multiplier par 3600 et basta !?
d'où mon étonnement qu'il n'en soit pas ainsi, vu que je pensais que le temps à plat défini par "des pentes >3% sur au moins 200m" était égal au temps total du déplacement moins la somme du temps de monté et de descente,
soit pour l'exemple ci-dessus 3h06m50 - (1h37m32 + 1h03m32) = 25m46 !?
donc moi pas comprendre ou je me plante ?
Bien cordialement
l'Ours

Pas compris.
Je ne compte pas de temps à plat. Je capte des temps en montée uniquement, et je considère que c'est une montée dès que la pente est supérieure à 3% sur au moins 200m.

Admin a dit :Pas compris.
Je ne compte pas de temps à plat. Je capte des temps en montée uniquement, et je considère que c'est une montée dès que la pente est supérieure à 3% sur au moins 20

Dois-je en déduire que pour afficher le temps de descente, tu inverses le sens de la trace et tu la repasses à la moulinette de ton algo ? OK !
Mais peu importe ça ne change rigoureusement rien à mon raisonnement ultra basique pour lequel il me paraît bien difficile de faire plus simple,
en effet pour moi dès l'instant ou on affiche un temps de monté et un temps de descente comme qu'ils aient été déterminés qu'il soit rigoureux ou complètement faux la n'est pas le pb.
il me semble que la solution la plus cohérente pour estimer les dénivelés horaires est de les calculer en fonction du D+, du D- déterminé par ton algo et de leur temps respectifs cumulés ! non ?
Du coup moi non plus, je ne comprends pas ce que tu ne comprends pas !?
Bien cordialement
l'Ours

la Marmotte & l'Ours a dit :Dois-je en déduire que pour afficher le temps de descente, tu inverses le sens de la trace et tu la repasses à la moulinette de ton algo ? OK !
Non, pour calculer le temps en descente je fais pareil mais sur des pentes inférieures à -3%

Je comprend que tu voudrais faire simplement dénivelé horaire = denivelé / temps. Ok dans l'absolu, mais calculer un dénivelé horaire sur une rando dont la pente est de 2% maximum n'a pas de sens. Donc je ne calcule le dénivelé horaire que lorsque ça monte (ou descend) un minimum ! Le reste est considéré comme du plat.

Eh bien une fois de plus j'aurais mieux fait de réfléchir avec un peu plus de perspicacité et de délicatesse, ça m'aurait éviter d'exposer au grand jour ma honteuse balourdise, pour laquelle je te présente mes plus plates excuses !
De plus ton algo en est d'autant plus performant, félicitations !
Toutefois si tu me le permets encore une petite question :

Admin a dit :Donc je ne calcule le dénivelé horaire que lorsque ça monte (ou descend) un minimum !

- OK et c'est tout à ton honneur, mais alors pour éviter ma magistrale bévue, est-ce qu'il ne serait pas plus logique et plus précis d'afficher dans le tableau des statistiques seulement ces temps là,
pour qu'il ne puisse plus y avoir aucune ambiguïté pour ceux qui comme moi ne réfléchissent pas assez !
En effet, il me semble que quand on lit : 590m/h et au dessous 1h37m32s, il ne tombe pas immédiatement sous le sens qu'il s'agit du cumul du temps de monté et du temps à plat en fonction de ton critère pour les distinguer !?
Dit plus simplement mes neurones n'ont plus la vélocité nécessaire pour comprendre que tu puisses intégrer dans le temps de monté et de descente le temps pendant lequel tu estimes précisément et à juste titre qu'on ne monte où ne descend pas ??? 😨
D'autre part, comme en plaçant le temps affiché en dénominateur, j'obtiens déjà un résultat supérieur au tient en le diminuant du temps à plat, ce sera encore discordant !
qu'en penses tu ?
Par ailleurs quelle suite envisages-tu pour ce fameux "seuil_vitesse_arret" ?
Car pour nous l'essentiel est bien là, le reste étant parfaitement anecdotique !
Bien cordialement
l'Ours

Bonjour Admin,
je poursuis l'opportunité que tu m'as offerte :
Admin a dit :J'ai ajouté un paramètre pour que tu puisses faire des tests, tu me donnera tes conclusions !

avec cette nouvelle suggestion : dans les stats de VisuGPX, comme tu affiches à quelle distance tu as trouvé la vitesse maximale,
si c'est possible il serait me semble-t-il intéressant de connaître le dénivelé horaire maximal sur par exemple 50m de dénivelé,
car dés lors que ce dernier serait inférieur au dénivelé horaire global on saurait que le seuil_vitesse_arret est trop grand !
l'étude menée sur la trace de la Marmotte qui ne tient même plus le 300m/h démontre que pour elle 0,5 c'est déjà bien trop grand,
ce que nous avions depuis longtemps !
Pour conclure : il me semble que les tests effectués montrent que contrairement à tes craintes ton algo ne draille absolument pas jusqu'à 0,1 et qu'au contraire c'est en l'augmentant que les résultats sont de plus en plus faux ce qui me paraît logique ! non ?
Qu'en penses-tu ? sachant que rien ne presse puisque tu nous a déjà généreusement offert le moyen de régler cet épineux pb.
Bien cordialement.
l'Ours

la Marmotte & l'Ours a dit :En effet, il me semble que quand on lit : 590m/h et au dessous 1h37m32s, il ne tombe pas immédiatement sous le sens qu'il s'agit du cumul du temps de monté et du temps à plat en fonction de ton critère pour les distinguer !?
Non, il ne s'agit que du temps de montée. Le temps à plat (dans des pentes <3%) n'est pas affiché, mais il peut se calculer en faisant "temps de déplacement - temps de montée - temps de descente"

Pour diminuer le seuil de 0.5km/h, j'ai peur qu'une valeur trop faible ne soit pas compatible avec la précision de la géolocalisation, qui ferait que les pauses ne soient plus prises en compte. Peut être qu'il faudrait que je ne calcule le temps de pause pour des intervalles de temps de x secondes mini (actuellement à chaque nouveau point, ça peut être toutes les secondes), dans ce cas la seuil des 0.5km/h pourrait être abaissé

Admin a dit :Non, il ne s'agit que du temps de montée. Le temps à plat (dans des pentes <3%) n'est pas affiché, mais il peut se calculer en faisant "temps de déplacement - temps de montée - temps de descente"

OK ! c'est bien ce que je pensais, mais alors comment obtiens-tu 590m/h à partir de 1h37m32s pour un dénivelé cumulé de +987m ? perso je trouve 607m/h ce qui a fait l'objet de mon alerte, voir plus haut !?

Le dénivelé cumulé est le dénivelé total, y compris sur les pentes à moins de 3%.

Admin a dit :Pour diminuer le seuil de 0.5km/h, j'ai peur qu'une valeur trop faible ne soit pas compatible avec la précision de la géolocalisation, qui ferait que les pauses ne soient plus prises en compte.

Même si ce constant souci et tout en ton honneur, franchement Admin entre les situations quasiment extrémistes que représente ta trace test et celle de la Marmotte quels sont les résultats les plus réalistes entre :
- pour un seul = 0,5 --> temps en mouvement = 02:54:54, temps de pause = 00:11:56, qui à l'échelle du temps total = 03:06:50 sont pour moi quasiment indétectable sur l'altigraphe et probablement plus lié à des difficultés de terrain qu'à de réels arrêts !?
- pour un seul = 0,1 --> temps en mouvement = 03:06:50, temps de pause = 00:00:00.
et ceux de la Marmotte :
- pour un seul = 0,5 --> temps en mouvement = 06:08:10, temps de pause = 04:44:52, résultat complètement délirant par rapport au réel, puisqu'il est certain que ce temps est aux environs de 50mn
- pour un seul = 0,1 --> temps en mouvement = 10:06:27, temps de pause = 00:46:35, dont 34mn pour la pause pique-nique.
Perso je pense que ce sont ceux obtenus avec un seuil = 0,1 et ce d'autant plus que je suis convaincu que tous les usagers de VisuGPX ne sont pas des marathoniens des cimes ! non ?
Il serait par ailleurs intéressant que les plus fidèles membres de notre communauté donnent leur opinion à ce sujet, pour m'a part je laisse bien volontiers tous les fans des : STRAVA, SUUNTO, GARMIN et VISORANDO pour ceux que j'ai pu tester
à leurs délirantes estimations et je suis tous les jours un peu plus convaincu d'avoir fait le bon choix, en vous rejoignant. 😍