[Administré] Etude comparative des principaux estimateurs sur une trace à problème

[Ce fil est une discussion qui s'était développée sur le fil "Connectez VisuGPX à d'autres services". Il a été extrait pour en faire un sujet à part entière, permettant à de nouveaux lecteurs de le retrouver plus facilement. Le ménage était devenu nécessaire... ;-)]
Bonjour à tous,
Vraiment désolé pour ddlm mais en ce mois de deuxième confinement les températures extérieures étant encore bien trop clémentes pour que l’Ours hiberne, il s’est livré à une très brève étude comparative des principaux estimateurs sur une trace à problème par les 5 applications suivantes : UUNTO, VisuGPX, STRAVA, VisoRando et Quantified-Self.ioS, dont il se permet de soumettre le résultat à votre sagacité, accompagné de ces quelques précisions :
- le lien sur la trace ,
- enregistrement des données avec montre Suunto Ambit3 PEAK en mode Trekking,
- paramétrage de VisuGPX : Seuillage = 10 m, Lissage = 5 points,
- pas de paramétrage accessible pour STRAVA pour garantir la fiabilité des comparaisons entre compétiteurs,
- pour VisoRando : avec et sans recalage des altitudes,
- pas trouvé de paramétrage possible pour Quantified-Self.io,
- son estimation manuelle à l’ancienne qui sert de référence faute de mieux étant une mesure la plus honnête possible qu’il a réalisée à partir de la Top 25 de l’IGN, est forcément toute relative, disons avec une précision d’environ 5%.

Sous cette hypothèse : 19,5 < D km < 21,5 et 1150 < D+ <1270
Alors les 3 seules applications satisfaisantes sont donc VisuGPX, STRAVA et VisoRando (sans recalage des altitudes), comme la majorité d’entre nous en est convaincue depuis longtemps.
Reste le petit bémol du paramétrage pour VisuGPX que chacun peut accommoder à son gré, qui confère à cette application une indéniable souplesse, mais qui est extrêmement artificielle s'agissant du seuil que je trouvais particulièrement pertinent pour une adaptation à l’activité (vélo de route, randonnée pédestre par exemple) tant que j’ai cru qu’il s'agissait du seuil d’élimination des mesures aberrantes avant lissage, mais c’était bien avant qu’Admin ne me révèle qu’il n’en était rien ainsi que le principe de son algorithme !
Nous sommes donc bien obligés de nous en contenter en attendant qu’il ne rende tout cela plus scientifiquement correct par une fonction unique auto adaptative susceptible de le placer encore plus haut sur le podium !
Qu'en pensez-vous ?
Bien cordialement.
l’Ours

PS : pour information, j’ai essayé de tester AltitudeRando mais apparemment ils en sont encore à la préhistoire puisqu’ils n'acceptent pas les fichiers au format GPX, qu’ils n’analysent pas ceux au format KML et demande de renseigner à la main toutes les informations, c’est bien évidemment tout l’art de ne vraiment pas se compliquer la vie !...

[Edité par Angstrom le 01/12/2020 15:02]

[Edité par Angstrom le 01/12/2020 15:14]

Ça bosse !
Pfiou, Visu ne s'en sort pas si mal, c'est 😎
Tu pourrais aussi tester ce que donne EditGPX en estimation 😜

Admin a dit :si tu réfléchis
Ah la bonne blague ! les Amis si nous nous calmions et redevenions sérieux 5 mn !
Suite à mes pb du transfert de mes traces de Suunto > VisuGPX Admin ma convaincu, à très juste titre, de reprogrammer nos montres pour une mesure toutes les s, au lieu de toutes les 10 s avec le souci économiser la batterie !
Alors ne suffirait-il pas de poursuivre cette logique jusqu'au bout et rendre EditGPX d'une robustesse imbattable en procédant de la manière suivante :
dès l'instant où le quidam demande l'horodatage de sa trace en fixant date, heure de début et vitesse moyenne :
si nécessaire il faut et suffit de la suréchantillonner à la s, en interpolant latitude, longitude et en recalant l'altitude et basta !
Sur ma trace crash-test, j'ai généreusement choisi 5 km/h de moyenne ce qui est déjà largement surévalué pour de la randonnée pédestre de gens normaux !
10 h = 3600 x 10 = 36000 pt et là je vous garantis que vous soyez en base I ou II, sans seuillage et avec un lissage sur 20 pt un résultat nickel-chrome
Certes ça à un cout, mais jusqu'à preuve du contraire on n'a rien sans rien ! le

Admin a dit :il faut même en mettre moins, mais mieux les placer 😉 !!!!

faut m'expliquer comment ! je me suis appliqué à tirer ceux qui me paraissaient les plus stratégiques sur les courbes de niveau en faisant en sorte qu'ils soient suffisamment nombreux pour qu'ils supportent un petit lissage, etc...
je ne comprends pas comment peut-on les répartir plus harmonieusement et de toute manière il me semble impossible de pouvoir positionner manuellement un nombre de points suffisamment bien répartis pour satisfaire aux exigences d'un lissage statistiquement correct (CQFD). 😋

On est bien d'accord que le lissage fait le job, et nécessite un certain nombre de points. Mais sans lissage, moins tu mets de points moins tu fais d'erreurs 😉

Rajouter des points, pas sûr que ce soit pertinent. Forcément ça va tirer tout droit entre deux points, et couper les lignes de niveau, ce qui risque de poser plus de pb que de solutions. Non, je pense qu'il faut plutôt adapter le lissage à la densité plutôt, et on en revient à qu question de repenser ça, pour obtenir un lissage automatique. Faut que je m'y penche 😨

Il me semble que lorsqu'on crée une trace manuellement point à point lorsque le routage ne marche pas, les gens sérieux font suffisamment attention pour avoir des résultats fiables, ils font en sorte que l'interpolation linéaire entre leurs clic soit probante. Il me parait dommage de se priver de la puissance du suréchantillonnage numérique pour générer un nombre d'échantillons suffisant pour garantir un bon résultat avec un lissage minimal de 10 à 15 statistiquement il est recommandé de ne pas descendre au-dessous de 20, mais c'est bien connu les scientifiques transgressent allègrement les recommandations des matheux, mais faut pas exagérer pour autant !
Pour moi il est illusoire de continuer à bidouiller en essayant de toujours adapter le lissage au nombre de points, la robustesse du procès ne peut venir que de l'inverse adapter le nombres de points à la taille du lissage choisi !
nous divergeons donc sur cette analyse !
ceci dit, je viens d'observer mes dernier enregistrements avec ma monter régler sur 1 s : pour 36 mn = 943 pts, pour 4 h = 7025 pts conclusion un peu moins que toutes les 2 s
et il est bien sur évident que toutes les 5 à 10 s serait largement suffisant, au moins pour du pédestre !!! 😉

avant d'être confiné, je m'étais "amusé" à comparer Oruxmaps sur smartphone (le GPS étant paramétré sur: échantillonnage toutes les 8 s, arrêt dès que la précision atteint 20 m, enregistrer le point s'il est distant de plus de 20 m du précédent) et ma montre qui échantillonne toutes les secondes. Y a pas photo, on a des fichiers 10x volumineux (en faveur d'Orux, bien sûr). Même que j'ai envisagé de passer en .fit pour lutter contre l'orgie de Mo que cela provoque...
la trace qui en résulte est nettement plus précise avec la montre (du moins lorsque la précision du GPS le permet, mais c'est un autre débat), les arrondis lors des descentes à skis plus harmonieux. De différence sur le dénivelé, rien de significatif.
Edit GPX, lorsqu'on réduit le nombre de points, raisonne-t-il comme Orux pour s'adapter à la densité de points ? Autant ne garder que ceux qui sont pertinents.
Cela pourrait aider à "standardiser" la problématique seuil-lissage ???

Editgpx réduit le nombre de points sans tenir compte de la densité, car il y a aussi le paramètre temps qui peut être présent, et je préfère garder un échantillonnage correct sur le temps que sur l'itinéraire.

Oulala!!

On teste les capacité d'analyse des participants du forum!!
Analyse mathématique mais aussi analyse de textes!!

Pour répondre à la question:
ddlm a dit : utilise le routage IGN ?



Il faut relire le post plus haut qui donne le contexte:
la Marmotte & l'Ours a dit :car j’en ai bien évidemment profité pour tester le type de profil qui me préoccupe le plus, mais qui n’est probablement pas très représentatif de la majorité des utilisateurs de VisuGPX et EditGPX, bien qu’il y ait, paraît-il, de plus en plus de gens qui courent n'importe où en montagne, pour notre part nous n’en croisons vraiment pas beaucoup

En clair: l'Ours n'aime pas les sentiers, c'est bien connu. 😉

Comme pourrait le confirmer un randonneur nantais. A lire ici . 😨

Salut Angstrom Merci de venir à mon secours avec beaucoup d'humour, félicitations ! 😄

Admin a dit :Editgpx réduit le nombre de points sans tenir compte de la densité, car il y a aussi le paramètre temps qui peut être présent, et je préfère garder un échantillonnage correct sur le temps que sur l'itinéraire.

OUI et chapeau bas pour les performances de ton algorithme, moi qui n'est pas assisté à la genèse d'EditGPX, j'en reste baba d'admiration, je ne sais pas quel est son secret, mais la performance n'a pas fini de m'étonner !
En effet en cherchant partout s'il était possible de suréchantillonner ma trace bidon (construite essentiellement pour prouver le côté délétère d'un seuillage fixe, un seuillage auto adaptatif étant envisageable, voire indispensable, uniquement pour écrêter les valeurs aberrantes !) j'ai tout bonnement découvert la possibilité de réduire le nombre de mesures, je savais que c'était possible mais pas commet !
Alors comme tous les Ours sont par nature très curieux, j'ai testé avec la dernière trace enregistrée avec ma montre pensant que ça devait très vite se casser la gueule, c'est dire qu'elle n'a pas été ma surprise en constatant au contraire une robustesse étonnante la preuve . 😭

ton échantillonnage initial est 1 pt/3 secondes. il y a peu de variation sur les données jusqu'au sous-échantillonnage 1/4, soit 1 pt / 11 secondes. Ou 1 pt / 10 mètres (sachant que le GPS donnera en moyenne une précision de +/- 10m).
vu la vitesse habituelle en rando, cet échantillonnage suffit (sur un smartphone précédent, j'avais paramétré Orux pour faire un fix toutes les 15 secondes, ça convient très bien. En descente de ski de rando, par contre......).
Je partage ta conclusion: sur-échantillonner sur le terrain n'augmente pas la précision des données (dénivelé, longueur, vitesse...), ça fait uniquement grossir les fichiers.
Du moins, tant qu'on reste à des vitesses "humaines" (un ours, d'ordinaire, ça peut aller plus vite qu'à 4 km/h 😂 )

Intéressant. Merci de ces études et partages.

Je dois dire que je suis surpris depuis un moment de constater la paresse des fabricants d'appareils GPS. En effet, avec tous les capteurs embarqués et l'information contextuelle dont on dispose, il serait possible de faire un échantillonnage beaucoup plus sophistiqué (intelligent, devrais-je dire pour être dans l'air du temps).
Peut-être que cela consommerait plus de ressources (et donc réduirait la batterie) que cela en ferait économiser et donc qu'il n'y a pas de vrai bénéfice à le faire dans l'appareil.
C'est une piste pour VisuGPX de continuer dans cette voie du rééchantillonnage "intelligent", combinant le contexte de l'activité, des vitesses dans ces activités, voire des infos cartographiques comme les tracés des routes et chemins.
A condition qu'il y ait un vrai bénéfice à la clé, bien évidemment. Ce qui n'est pas établi.

Angstrom a dit :A condition qu'il y ait un vrai bénéfice à la clé, bien évidemment. Ce qui n'est pas établi.

Peut-être bien pour la majorité des utilisateurs, mais pas pour un Ours !!!!

Je reste intimement convaincu que beaucoup bidouillent avec le paramétrage du seuil et du lissage de Visu et EditGPX juste pour obtenir les résultats d’une analyse qui s’approchera au plus près de celle que nos chers jouets connectés nous ont restituée en fin d’exercice et ainsi se foutent le doigt dans l’œil jusqu’au coude ! ce qui au passage rende illusoire toute comparaison objective entre les différents exercices, raison pour laquelle, si j’ai bien compris, STRAVA n’analyse pas les traces avec les altitudes mesurées, mais bien avec celles de sa base de données, idem pour VisoRando qui par défaut recale les altitudes !
sauf qu'il n'ont pas les fonctions d'Admin qui au préalable éliminent tout ce qui n'est pas lié à un déplacement !

Alors si Admin veut que Visu et EditGPX restituent les analyses les plus pertinentes au monde, inutile qu’il continue à se torturer les neurones pour trouver la fonction impossible du genre mouton à 5 pattes; au lieu de rester tout ce qui a de plus zen puisqu’il a déjà fait le boulot avec sa fonction magique d’analyse et de sous-échantillonnage.
En effet il lui suffit de :
1 - sur-échantillonner fortement par une bête interpolation linéaire pour avoir un point par m, voire même par 0,5 m, en fonction de la vitesse, procéder au recalage de l’altitude avec la Base (II) pour être sûr qu’il n’y aura pas de trou,
2 - sous-échantillonner en divisant le nb total de pts / 20 comme il sait si bien le faire et le tour est joué, plus de seuil ni de lissage puisqu’il est apparemment très bien fait par son algo ! et ainsi les résultats seront comparables tant qu’il utilisera la même Base; la preuve ci-dessous :

ddlm
“Ou 1 pt / 10 mètres (sachant que le GPS donnera en moyenne une précision de +/- 10m).”
le cœur du problème est bien là ! Cette précision n’est atteinte qu’en moyenne !
Donc nous sommes bien d’accord, pour y arriver l'idéal serait d’avoir n mesures pour un même point et d’attribuer à ce point l'altitude moyenne ! Ce qui est impossible à faire à partir d’une trace bien évidemment, d’où le passage obligé par un lissage, nous en sommes tous convaincus et il serait bon d’oublier à tout jamais le seuillage, tout au moins tel qu'il est pratiqué actuellement, OK.

Alors, compte tenu de tes observations, j’ai poursuivi mes investigations et réflexions en reprenant ma trace à problème de la Montagne de Sumiou pour laquelle :
1 - je n’ai conservé que 1000pts / 7407 mesures, sans seuil et avec un lissage sur 3 pts, j’ai obtenu :
distance = 19,3 km D+ = 1237 D- = 1239
2 - j’ai recalé les altitudes en Base (I) des 5407 mesures avant de ne conserver que 1000pts, sans seuil et avec un lissage sur 3 pts, j’ai obtenu :
distance = 19,32 km D+ = 1198 D- = 1199
3 - j’ai recalé les altitudes en Base (II) des 5407 mesures avant de ne conserver que 1000pts, sans seuil et avec un lissage sur 3 pts, j’ai obtenu :
distance = 19,31 km D+ = 1258 D- = 1260

Pas si mal que ça si on admet que ma mesure manuelle tient la route et donne une référence relative de 1210 m !

Fort de ce résultat, j’ai amélioré ma trace synthétique Crash-Test en doublant le nombre de points et en les répartissant un peu plus harmonieusement et suis ainsi parvenu, après cette harassante manip, à 2308 pts, sur lesquels j’ai repris le même traitement :
1 - j’ai recalé les altitudes en Base (I) avant de ne conserver que 1000pts et obtenu :
a - sans seuil et sans un lissage :
distance = 57,09 km D = 3116
b - sans seuil et avec un lissage sur 3 pts :
distance = 57,09 km D = 2911
c - sans seuil et avec un lissage sur 5 pts :
distance = 57,09 km D = 2782

2 - j’ai recalé les altitudes en Base (II) avant de ne conserver que 1000pts et obtenu :
a - sans seuil et sans un lissage :
distance = 57,17 km D = 3235
b - sans seuil et avec un lissage sur 3 pts :
distance = 57,17 km D = 3190
c - sans seuil et avec un lissage sur 5 pts :
distance = 57,17 km D = 3068
d - sans seuil et avec un lissage sur 7 pts :
distance = 57,17 km D = 2936
e - sans seuil et avec un lissage sur 9 pts :
distance = 57,17 km D = 2810

Là encore, pas si mal que ça si on admet que ma mesure manuelle tient la route et donne une référence relative de 2982 m !

À partir de ces différents constats, que peut-on conclure quand on ne sait pas comment Admin procède lorsqu’il réduit le nombre de points ?
Cependant il me semble que la seule manière d’à la fois compenser l'impossibilité de moyenner les altitudes et les imprécisions des Bases (I) et (II) (cette dernière étant incontournable dès qu’une trace se promène hors routage sur des crêtes et sommets !) est de multiplier le nb de points, 1 tous les 5 m en pédestre (tous les m, voire plus pour les descentes à ski ou à vélo !) au minimum, renseigner les altitudes à partir de la bonne Base, sous- échantillonner et éventuellement appliquer encore un petit lissage, pas forcément nécessaire vu les performances constatées de l'algorithme Admin !
Qu'en pensez-vous ?

Intéressante analyse ! bravo.
A mon avis, le cœur du problème réside dans l'origine de l'information:
Lors d'une sortie
avec ta montre, tu enregistres l'altitude avec le baromètre. Donc une "variabilité" assez faible, ce qui explique que le seuil ne soit pas utile. La situation devrait être différent si on capture les altitudes avec le GPS, la variabilité devient très forte ( sans bouger, on arrive à faire un marathon, voire gravir l'Everest... nos montres et smartphones ne sont pas équipées pour gérer l'Egnos, donc peu d'espoir d'amélioration); je n'ai pas fait l'essai (c'est une idée pour s'occuper après le confinement), mais l'utilisation du seuil pour éliminer les données erratiques du GPS risque d'être indispensable. La qualité du signal initial est clé.
Pour peu que les conditions atmosphériques soient "non standard" ( isotherme 0°C à haute altitude, inversion de température), l'altitude indiquée par le baromètre devient erronée (l'erreur peut facilement atteindre 5%, qui vient se cumuler avec les autres erreurs). Même en échantillonnant à 1 pt/seconde, l'erreur sera bien là et se cumulera. On peut traiter le signal tant qu'on veut, le dénivelé sera faux ( comme toutes les données accumulées sont cohérentes dans leur erreur, comment filtrer ???).
traitement post sortie, ou préparation d'une sortie
si on traite a posteriori la trace obtenue via EditGPS en recalculant les altitudes avec Base I ou II, on élimine ce dernier facteur (ce que fait Strava). L'altitude indiquées par la montre devient une donnée uniquement pour gérer la course sur le terrain, pas pour "analyser la performance". On peut alors réduire l'échantillonnage, on améliore la longévité de la batterie tout en restant dans une précision acceptable.
Le problème demeure pour la préparation d'une trace, et ton analyse de "crash-test" est passionnante: tu rajoutes des points, qui sont interpolés linéairement en fonction de l’échantillonnage de la base; donc ça amplifie les erreurs de la MNT: la précision s'améliore en lissant. C'est ce qui se passe en prenant le routage IGN, qui génère énormément de points, que l'on doit ensuite lisser pour avoir un résultat correct. Ce qui revient à dire que le lissage devrait être relié à la densité spatiale de points, pour s'adapter à l'activité ???
... Il y a des moments où je me demande si je suis très clair dans mes explications.... 😨

ddlm a dit :Il y a des moments où je me demande si je suis très clair dans mes explications.... 😨

Salut ddlm tu es clair mais je te trouve un peu trop pessimiste, certes mon expérience en terme d’enregistrement de traces sur le terrain ne date que de janvier 2019, mais quand même sur :
92 traces, une distance de 1119 km et +93760 m dénivelé cumulé en 2019
92 traces, une distance de 1083 km et +88810 m dénivelé cumulé en 2020
c’est seulement sur 3 d’entre elles que j’ai constaté des résultats vraiment délirants dont ceux du Tour de la Montagne de Sumiou pris en exemple au début de cette conversation.
J’ai également observé 3 absences de signal GPS malgré des conditions idéales, que j’avais attribué à un problème lié à ma montre jusqu’au troisième où la Marmotte nous suivait avec un écart énorme en distance et dénivelé, dès lors que le défaut a été simultané sur nos deux montres ça dédouane de facto la fonction d’enregistrement de Suunto et confirme un pb sur le signal GPS, c’est certes troublant, mais factuel.
Nous n’utilisons pas la mesure de l’altitude par la seule fonction barométrique qui nécessite un recalage régulier de la référence, mais la fonction automatique de Suunto qui est sensée effectuer un savant équilibre entre les mesures barométriques et GPS, dont bien évidemment j’ignore l’algorithmie ! et je dois reconnaître qu’elle ne marche pas si mal que ça puisque les passages aux points cotés par l’IGN sont généralement très bons, assez souvent même au m près, donc à mon avis plutôt issus de la puce GPS que de l’altimètre. Apparemment leur fonction merde quand il faudrait qu’elle ne prenne en compte que les mesures altimétriques lorsque le signal GPS n’est pas suffisamment correct, comme par exemple lorsqu’on longe le pied d’une falaise, ou qu’on la gravit par une mini-via ferrata, cas de l’exemple choisi.
Reste que la découverte du jour est qu’avec les paramètres des réglages de ma montre identiques pour 2 exercices similaires en mode Trekking pour le premier j’ai en moyenne un point de mesure toutes les 2,7 s et pour l’autre 2,26 s, écart suffisamment significatif pour que je m’interroge ? Aurais-tu une explication rationnelle autre qu’une possible adaptation en fonction de la vitesse ? à voir sur ce tableau .
D’où il ressort :
1 - qu’à l’exception du calcul assez anecdotique de la dépense énergétique pour laquelle VisuGPX se distingue sur l’exercice le plus intense à la vitesse la plus lente tous les autres résultats sont cohérents,
2 - que STRAVA est optimisé pour la seule comparaison des performances, raison pour laquelle seule les 2 options, course à pied et vélo sont licites, les autres ne sont sûrement là que pour des raisons de marketing.

ddlm a dit :( sans bouger, on arrive à faire un marathon, voire gravir l'Everest...

Alors là ! permets-moi de m'inscrire en faux et de penser que ce qui suit devrait t’intéresser car si je l’ai cru pendant longtemps, désormais je suis factuellement certain que ceci ne se produit que lorsque le capteur GPS ne voit pas le ciel !
En voici la preuve : la Marmotte porte toujours sa montre au poignet même au cours de ses très longues siestes, moi j’ai la mienne accrochée sur le haut d’une des bretelles de mon sac à dos pour avoir les bonnes températures. Sa montre n’a strictement jamais eu de bouffée délirante, la mienne à plusieurs reprises, jusqu’au jour de ce printemps où nous pique-niquions devant une cabane de berger, elle à découvert sur une chaise et moi dos à la cabane, abrité du soleil par une tôle métallique avec mon sac comme dossier, résultat un délire complet du seul enregistrement de ma montre pendant toute la durée du pique-nique et de me souvenir que les autres observations émanaient soit de la pause-ravitaillement où j’avais la négligente manie de laisser le rabat fort encombré de mon sac recouvrir ma montre, soit de passages sous une baume ou dans une grotte !
explication :

“on arrive à faire un marathon”
parce qu'en pareil cas les coordonnées mesurées étant délirantes, les distances le sont forcément.

“voire gravir l'Everest…”
parce que contrairement à ce que tu penses, ton altimètre étant en mode automatique, dès l’instant où il n’y a plus la détection d’un mouvement, il passe en mode baromètre et les altitudes sont calculées par la puce GPS avec des mesures “bidon” donc complètement folkloriques ! CQFD

“( comme toutes les données accumulées sont cohérentes dans leur erreur, comment filtrer ???).”
Petite précision : il me semble que lorsqu’un altimètre se décale si ça biaise effectivement les mesures suivantes, s'agissant d’une constante ce n’est pas cumulatif et je ne pense pas que ça perturbe beaucoup le lissage.

ddlm a dit :Le problème demeure pour la préparation d'une trace, et ton analyse de "crash-test" est passionnante: tu rajoutes des points, qui sont interpolés linéairement en fonction de l’échantillonnage de la base; donc ça amplifie les erreurs de la MNT: la précision s'améliore en lissant. C'est ce qui se passe en prenant le routage IGN, qui génère énormément de points, que l'on doit ensuite lisser pour avoir un résultat correct. Ce qui revient à dire que le lissage devrait être relié à la densité spatiale de points, pour s'adapter à l'activité

Désolé mais je ne vois pas les choses comme ça ! mais à vrai dire il me manque l’information essentielle à mes yeux qui est de connaître le maillage des bases de données qu'utilise EditGPX, car il me semble qu’il serait débile d’appliquer un sur- échantillonnage plus fin que ce maillage, moyenner ou lisser des valeurs identiques n’est pas particulièrement intelligent !
Pour préparer mes projets, en l’absence de routage, avec EditGPX j’utilise principalement les photos satellites, bien souvent au max de leur définition pour les passages les plus stratégiques, ce qui devient vite particulièrement lourdingue en zone plus calme et sans problème, d’où ma requête (une de plus auprès d’ Admin ) pour savoir s’il lui était possible de rendre cette étape automatique qui serait en fonction de la géométrie de la trace, de l’interpoler linéairement de manière à avoir 1 pt tous les x m, x étant le maillage le plus fin de ses bases, recaler les altitudes et réduire le nb de points à 1000 par exemple pour obtenir un profil nickel et un dénivelé cumulé le plus proche possible de la réalité ?!
En procédant ainsi, il me semble qu’on pourrait définitivement s’affranchir à la fois de l'hypothétique adaptativité de la taille du lissage en fonction de l’activité et de la recherche de la précision maximale puisque, quelle qu'elle soit, il serait impossible de faire mieux !
Pour obtenir une précision supérieure en retour d’expérience, l’idéal serait d’effectuer une dizaine de fois le même itinéraire et de moyenner les profils obtenus; faute de quoi nous sommes bien obligés de nous contenter de ce que l’on peut faire de mieux à partir d’un seul enregistrement. En l’absence d’une mise en œuvre des lourdes fonctions de trajectographie du style aide à l’atterrissage ou autre guidage de missile ou voiture autonome, la seule solution qui reste est de toujours se placer à la fréquence d’enregistrement la plus rapide de la puce GPS pour ensuite pouvoir filtrer au mieux grâce à une fonction statistique du pauvre avec un algo du genre de celui déjà proposé à Admin ou faute de mieux se contenter du simple lissage glissant actuel sur au minimum 10 à 30 pts.

Quand au choix de ma trace "crash-test" si je suis allé la placer en versant Sud du Mont Ventoux c’est bien parce que comme me le recommande Admin je réfléchis (beaucoup trop d’ailleurs puisqu'il m’arrive de ne pas en dormir ! probables séquelles de longues études plus ou moins scientifiques et de toute une carrière professionnelle entièrement consacrée à justement la recherche de fonctions robustes face à des données d’entrées très bruitées ! ) persuadé que si j’avais choisi une ascension sur une longue crête torturée de nos chères Alpes où se déroulaient bon nombre de mes traces à problème, la majorité aurait considéré que ce test n’avait aucune validité. Raison pour laquelle j’ai choisi des pentes assez douces et très ouvertes à des altitudes inférieures à 2500 m pour être sûr de pouvoir tester l’utilisation indifférenciée des 2 Bases, etc.
Qu’en penses-tu ?

😨 Je comprends rien à ce que vous dites, mais j'y lis quand même ! 😎 😜