Aller à la page : 1 2 3 4 5 Suivante
J'ouvre cette discussion suite aux remarques de thierry77, concernant les dénivelés enregistrés sur le terrain par vos GPS.
Les satellites étant haut dans le ciel, les GPS voient les satellites sous un angle relativement fermé. Il en résulte que la précision donnée concernant l'altitude est à peu près 3 fois moins bonne que la précision horizontale (lat/lon).
Plus que la précision, qui n'est pas importante pour calculer un dénivelé, c'est la répétabilité de la mesure qui pose problème, et surtout sur terrain plat.
Exemple : vous vous déplacez sur du plat (admettons 230m), et votre GPS enregistre votre altitude régulièrement : 230 229 228 230 231 230 232. Au final il vous annonce un dénivelé positif de 5 mètres alors que vous n'avez pas pris 1 mètre. Vous voyez donc le problème.
Sur un déplacement avec du dénivelé, les écarts de votre GPS sont moins influents sur le résultat, car ils ne sont pas suffisant pour prendre le dessus par rapport à votre prise d'altitude. Ex sur un profil où vous prenez 2 mètres à chaque point : 230 233 234 235 238. Finalement le GPS vous annonce le bon dénivelé.
Connaissant ce soucis, comment faire pour obtenir un dénivelé réaliste ? Plusieurs pistes :
- Augmenter la période de mesure du GPS : moins il prendra de points, moins il y aura d'erreur !
- Utiliser un GPS avec altimètre barométrique incorporé, qui se basse sur une variation de la pression pour mesurer l'altitude : beaucoup plus fiable.
- Utiliser une moulinette "intelligente", qui filtre les variations d'altitudes (n'en tient pas compte en dessous d'un certain seuil). Par exemple VisuGPX qui laisse même la possibilité de fixer la valeur de seuil, pour l'adapter à son GPS.
- Redéfinir les altitudes de votre fichier, en utilisant une source externe. C'est aussi ce que propose VisuGPX en utilisant les données du SRTM.
Voilà quelques pistes, à vous de jouer maintenant !
Oui. Ceci est particulièrement vrai pour un parcours plutôt à plat 🙄 .
Mais j'ai remarqué que sur un parcours typé montagne (le plat, bin y en a pas beaucoup 🤣), même lorsque le fichier est construit sur la base d'une carte (avec EditGPX 😉 ) les données du SRTM étant pas extrêmement précises, il peut y avoir des occilations dans les altitudes, alors que la montée (ou descente peu importe) est régulière 🤢 .
Ne serait-il pas possible d'aider le système en lui indiquant les points de changement de sens vertical (pointer sur la courbe verticale, quand on cesse de monter pour redescendre, et vice-versa) ? En gros on pointerait sur le profil, le départ, un col, un point bas, le sommet, un autre point bas, un autre col et l'arrivée et le système corrigerait les altitudes grace à ce pointage 🙄 😎 😉 .
OK en mettant un lissage à 30 ou 50 m sur un profil avec 1 montée et 1 descente, ça marche très bien 😎 , mais sur un profil avec 1 ou 2 courtes descentes (ou remontée) ça peut faire passer à la trappe ces variations d'altitude réelle 😉 .
J'ai participé de manière très active à ces longues discussions qui ont trait au calage des altitudes pendant 2 ans ( 2007 et 2008) sur Utagawa.
Je soulignerai 2 points:
- le 1er qui m'est très cher, et qui s'appelle la théorie de la fourmi qui monte et descend tous les cailloux rencontrés sur son chemin, donc qui, sur un sentier plat, franchit un dénivellé énorme! ce qui revient à dire que plus on a points sur une trace , plus on multiplie l'imprécision de la mesure,Il faut noter que ces imprécisions sont amplifiées par les valeurs indiquées par les logiciels de cartographie ( les éditeurs n'achètent pas à IGN les mêmes BDalti - maillage différent entre CE et MM par exemple)
- Le 2ème, et qui explique pour partie le fait que j'ai décidé de publier mes traces ici, c'est que depuis la mise en place de l'outil de Jéroen (visu et edit gpx), je trouve une cohérence de valeurs entre celles qui me sont données par cet outil et mes traces "nettoyées" et recalées dans CE3D.
je terminerai en disant que pour les traces GPS , l'essentiel est que le référentiel soit identique pour tous les fichiers GPS, donc par exemple, qe tous soient "obligatoirement" passés par la moulinette de Skitour.
Ici, et j'observai quasiment TOUS les topos publiés depuis le début de VTTour, les contributeurs montagnards attitrés indiquaient majoritairement les valeurs données par leurs Suntoo et autres alti, donc des relevés baro. Maintenant que bcp s'équipent de GPS et donc publient des fichiers "enregistrés" sur le terrain se pose la question de la cohérence entre les différentes indications fournies sur un topo. (je fais le distingo entre "relevé sur place " et tracé à la souris sur un logiciel, puisque là encore, suivant l'outil utilisé les indications diffèrent énormément, promenez votre souris sur une courbe de niveau et lisez la valeur d D+, faites le test c'est édifiant)
Voilà mon éclairage, je suis tout ça attentivement!
Edit: Je me suis interrogé sur le fichier de Squal mis sur le topo de Greg depuis Epierre: tracé à la souris, ou enregistré?
Oui j'ai été très surpris aussi avec une erreur énorme de 500m de D+ sur une sortie qui en fait 1300 max.
C'est une trace faite via Edit gpx. Alors je ne sais pas où est le bug ??? Je ne l'ai pas virée, je me suis dit que je la referai sur mon PC fixe car là faite sur un portable et donc souris moins précise ???? Mais bon c'est une montée sèche régulière et le tracé ne montre pas d'erreurs monumentales....
Donc si Jeroen ou quelqu'un d'autre a l'explication.
Ce qui est surprenant, c'est que généralement quand je fais mes traces sous edit gpx, le résultat est cohérent.
Le problème en suivant la route (qui prend peu de dénivelé), c'est qu'un petit point à coté et hop, tu perds plus de 10 mètres, qui sont comptabilisés dans le dénivelé final. On retrouve la même problème chaque fois qu'on suit des routes avec lacets. C'est exactement ce que voulait dire larsen quand il disait
larsen a dit :promenez votre souris sur une courbe de niveau et lisez la valeur d D+, faites le test c'est édifiant
Et plus la pente est importante, plus c'est édifiant.
Le filtre de 10 mètre n'est même pas suffisant. Pour ce type de profil, il faudrait presque ne pas suivre la route, mais tracer droit dans la pente.
Jeroen a dit :Le filtre de 10 mètre n'est même pas suffisant. Pour ce type de profil, il faudrait presque ne pas suivre la route, mais tracer droit dans la pente.
Que penses-tu de ma proposition pour "aider" le système à calculer le vrai D+ ?
En gros tu dis au système de ne comptabiliser les différences d'altitudes qu'entre tel et tel point (basta) et d'ignorer tous les autres. Une sorte de filtre manuel
Dans mon soft de carto, Carte sur Table, une autre méthode de filtrage est utilisé, par bspline (approximation polynomiale) à n points (n variable de 3 à 9 points)
Pers j'ai toujours retrouvé l'altitude d'un alti barométrique en utilisant ce lissage des altitudes à 9 points.
Peut-être une meilleure méthode qu'un filtre différentiel ????
Phil'Ô a dit :Que penses-tu de ma proposition
Que c'est une usine à gaz ? 😜
Florent a dit :Dans mon soft de carto, Carte sur Table, une autre méthode de filtrage est utilisé, par bspline (approximation polynomiale) à n points (n variable de 3 à 9 points)
Pers j'ai toujours retrouvé le déniv d'un alti barométrique en utilisant ce lissage des altitudes à 9 points.
Peut-être une meilleure méthode qu'un filtre différentiel ????
Up;)
Florent a dit :Dans mon soft de carto, Carte sur Table, une autre méthode de filtrage est utilisé, par bspline à n points (n variable de 3 à 9 points)
C'est une très bonne idée ça, mais bonjour le calcul...
Peut être sans utiliser les B-Splines, à ton avis une moyenne (pondérée ?) sur 2n+1 points (n + 1 + n) pourrait t'il donner de bons résultats ?
je vais demander le calcul à mon pôte qui à écrit le soft en question 😉
Je ne crois pas qu'il y ait de solutions miracles 🙁
Pour ma part, je pense qu'il faut prendre en compte les points à partir du moment qu'il y a une variation supérieur à 5 (10 me parait de trop surtout sur des parcours comme les miens, tu écrêtes beaucoup trop) et faire ensuite une moyenne entre chaque point retenu ce qui permet de faire un second lissage.
J'ai fait une simulation sous Excel, ça me donne un résultat assez proche de celui du logiciel.
Comme le dit Jeroen, il faut limiter le plus possible les points et règler son GPS en conséquence.
Le mien était réglé au taquet, ça ne sert pas à grand chose, à part augmenter la taille du fichier final...
A+ 😉
Concernant la trace d'Epierre, c'est effectivement la manière de faire le tracé qui influe le résultat: j'ai regardé sur mémorymap à midi: la largeur même du trait blanc représentant la piste sur la carte ( pour qu'elle soit lisible ) couvre à certains endroits + de 2 courbes de niveaux, pour la représentation graphique du lacet (tjs la lisibilité de la carte) l'épingle est élargie et Squal a souvent mis 3 points par épingle, ensuite pour peu que les points de trace soient 1 coup à droite, 1 coup à gauche du trait blanc, on multiplie les erreurs de représentation du profil, celui-ci en l'occurence est une succession de dents de scie alors que l'on sait tous que ça monte tt le long! . Pour info le recalage de cette trace de 322pts sur CE3D lui donne 1 D+ de 1650m (avec les points mal positionnés)
@+