UtagawaVTT

je ne comprends pas le texte du Dénivelé seuil supérieur, c'est quoi?
je sais que je roule pas vite mais qd même
A part ça j'ai balancé direct mes AL-Mnt en les exportant de CE3D



Moi le truc qui m'interesserait , c'est de savoir si je suis monté à 450M/H, 500 ou 600m/h, il faudrait donc diviser le D+ par le temps de montée, c'est ça?

c'est bizarre, issues du même soft, l'affichage des dates n'est pas homogène!

Titof6.9 a écrit :@Gégé38
Bon ben pour CompeGPS, je vais voir ce que je peux faire. Envoie moi une trace généré par ce soft.

J'ai trouvé, comment rajouter un nom au parcours dans CompeGPS (dans les propriétés de la trace) cela ne résout pas le problème car le nom se perd à la conversion dans GPSBabel.
Par contre CompeGPS peut enregistrer au format GPX et là ça marche !

Si tu veux quand même un fichier CompeGPS, donne moi une adresse mail où je peux te l'envoyer car je ne sait pas comment le mettre dans le post.

Gégé

Titof6.9 a écrit :Je ne C pas ce qu'en pense mon beta testeur mais je trouve tes idées intéressantes.

salut,
Ne vous inquiétez pas, le beta testeur ne s'est pas endormi sur le dernier GPXtoXL "beta"...
Chez moi tout marche bien, et même "nickel", mais il faut dire que mes fichiers .gpx sont également sans défaut.

Mes avis d'utilisateur sur les idées émises aujourd'hui :

- Afficher la vitesse maxi : bonne idée mais il y a risque d'afficher une "valeur aberrante" très importante due à une mesure ponctuelle erronée du GPS si elle se produit. Dans ce cas peut-être faudrait-il proposer un nouveau filtre de "vitesse maxi" (60 km/h par exemple) ou bien "nettoyer" le fichier avant passage à la moulinette GPXtoXL.

- Le temps de pause : ben c'est la différence "durée" moins "durée de déplacement", pas compliqué, pourquoi pas.

- Le pourcentage de temps pédalé : c'est le rapport "durée de déplacement" sur "durée", pas compliqué non plus.

Après comme dit Titof, ça fait des colonnes en plus et un commentaire très à droite (sans faire de politique) même si vous avez un écran Xtra-large comme le mien on perdra en lisibilité. Heureusement le volet permet le défilement des colonnes.
S'il y a trop de colonnes, on pourrait aussi choisir celles à afficher à partir de cases à cocher, mais le problème c'est la bande grisée qui serait cachée également...
Ou alors on dispose cette bande grisée non pas en haut sur tout la largeur mais sur les deux colonnes de gauche et sur 10 lignes... Ou alors, encore plus de chamboulement pour Titof, mettre toutes ces infos grisées dans une fenêtre indépendante ("UserForm") affichable par simple clic sur un bouton qui serait situé dans un coin en haut à gauche de la feuille. Ca ferait gagner de la place et permettrait le choix des colonnes à afficher. On peut même choisir les colonnes à afficher à partir de boutons situés dans une fenêtre indépendante qui s'affiche à la demande. C'est une solution pour gagner de la place. Mais les "développeurs incollables" ont peut-être d'autres solutions ?
Tout ça est bien joli mais ça ferait reprendre pas mal de chose à Titof à mon avis et ça demande du temps. A voir en fonction de l'utilité, du besoin qu'on en a.

Comment récuperez-vous vos fichiers traces pour les rentrer dans ce tableau?

J'utilise CE3 aussi (ou PhotoExplorer, c'est pareil) et je fais une exportation en .gpx des traces récupérées de mon GPS. En passant par CE3 j'en profite pour "caler les altitudes", ça me supprime les éventuelles altitudes "aberrantes". Après j'utilise GPXtoXL sur le .gpx.
D'accord, c'est fastidieux quand on a plein de gpx à exporter.
L'autre solution pourrait être la suivante : exporter sous CE3 (ou autre ?) un ensemble de traces en un seul fichier .gpx (c'est plus rapide !) et...c'est là que notre développeur-expert intervient : dissocier par GPXtoXL toutes les traces incluses dans le fichier .gpx à partir des "indicateurs" </trk> et <trk> pour "fin de trace" et "début de trace". Encore du boulot... Après faut voir si on en a besoin.

morbli a écrit :Est-ce qu'il y a une limitation dans le nombre de points par trace?

A mon avis un peu moins de 65536 lignes je crois, qui doit correspondre à la limite par feuille dans XL en l'absence de graphes (avec les graphes ça devrait être la moitié, soit plus de 32000).

Quand j'importe un de ces GPX, l'appli semble boucler. Je suis obligé de fermer Excel avec le gestionnaire de tâches.

Chez moi sur la version beta le traitement de ton fichier finit par une erreur d'exécution déjà vue ("incompatibilité de type"). A mon avis c'est parce que ton format de fichier n'est pas le même que mes .gpx et que le nombre de champs dans ton .gpx (fort complet !) est trop grand. En clair le programme doit lire certainement une chaîne de texte inattendue alors qu'il attend un nombre par exemple. Modifier le programme pour qu'il accepte n'importe quel format .gpx est encore un challenge...D'autre part ça ralentirait sans doute le programme pour les gros fichiers (tests conditionnels). A voir. Essaie déjà le convertisseur GPS Visualizer dont le lien est fourni sur GPXtoXL et voit si ça marche. Si ça ne vient pas de là et que j'ai tout faux c'est que mon PC ne se comporte pas comme le vôtre...

morbli a écrit :C'est donc le format du fichier d'origine qui pose problème

CQFD

J'ai remarque un petit bug qu'il n'y avait pas dans la version précédente : la vitesse moyenne max...

(merci le correcteur automatique ! ). Là c'est le beta testeur qui n'a pas fait son boulot. En effet le calcul de la vitesse max est fait sur la colonne F au lieu de la colonne G...(ça se voit sur la cellule). Une colonne a dû être déplacée entre deux versions. Du coup je vérifie les autres...C'est bon !

Comment transférer les données de la version 1.2.2 a la version1.3.0

Sélectionner les cellules à déplacer de la feuille 1.2.2 et faire copier (Ctrl+C) puis sur la feuille 1.3.0 faire coller (Ctrl+V) sur la cellule en haut à gauche de la zone à coller. Déplacer ensuite des données de la même façon si jamais les colonnes ne sont pas les mêmes entre les deux versions.

Je voudrais rentrer toutes les traces que j'ai (+ de 100) suffit-il de faire une fichier GPX avec toutes les traces et après les importer ?

Bonne question déjà répondue ci-dessus. Ca serait peut-être pas mal mais chez moi ça ne marche pas. La seule limite à mon avis devrait être constituée par la limite des 65536 lignes d'une feuille XL. Après on peut contourner le problème mais c'est plus compliqué (et plus cher ?).
Moi j'ai une autre question : peut-on intégrer un correcteur d'orthographe à GPXtoXL ?

Titof6.9 a écrit :@Gégé38
Bon ben pour CompeGPS, je vais voir ce que je peux faire. Envoie moi une trace généré par ce soft.

Ca y est ! Titof est rentré dans le traitement de fichiers .gpx "sur mesure" ! Le doigt dans l'engrenage, j'vous dis !

Gégé38 a écrit :...Par contre CompeGPS peut enregistrer au format GPX et là ça marche !

Moi le truc qui m'interesserait , c'est de savoir si je suis monté à 450M/H, 500 ou 600m/h

Bonne idée la vitesse ascensionnelle : et hop une colonne de plus ! (voir plus haut)

Il faudrait donc diviser le D+ par le temps de montée, c'est ça?

Oui, je crois !

je ne comprends pas le texte du Dénivelé seuil supérieur, c'est quoi?

C'est pour filtrer des valeurs d'altitudes "aberrantes" entre deux points en cas de mauvais enregistrement GPS, si j'ai bien compris.

C'est bizarre, issues du même soft, l'affichage des dates n'est pas homogène!

Demande d'homogénéisation (pas facile à dire) des formats déjà faite par le beta testeur attitré.

Tenez, un lien vers d'autres petits softs XL pour vous occuper un peu...C'est que ça rédige vite ici !
http://pagespro-orange.fr/patacou/xlcyclo/
Le problème c'est que ça risque de données des idées à certains...

C'est tout pour ma prose de ce soir...

Il est bien mon beta testeur ! Il répond tout ce qu'il faut à ma place
Bon ben j'vois que j'ai du boulot durant les X prochainnes années. Tombe bien l'hiver arrive. Ca va occuper mes longues soirée devant la cheminée. Moi j'vous dis C mon VTT qui va faire la gueule....

Après tout ce qui a été dit : prioriété numéro 1 crorrigé le bug débusqué par Larsen. Après on verra selon mes inspirations.
Il faut quand même privilégier les correction de bugs éventuels avant l'ajout de nouvelles fonction.
D'autant plus qu'il y'a d'autres chose qui doivent être modifier et que vous n'avez (encore) pas vu.....
exemple si on traite un fichier sans donné temps la date de la trace retournée devrait être celle de la création du fichier. Or ce n'est pas le cas.

J'ai effectivement mis le doigt dans un engrenage, mais j'aime bien ça

Bonjour à tous,

J'ai fait une sortie hier après-midi : le tour du Môle par Plan Meulet (Larsen appréciera ).
La trace préparée avec CartoExploreur et rentrée dans GPXtoXL est donnée pour 588 m de D+, ce qui est évidemment totalement invraisemblable.
L'ACTIVE LOG de la sortie donne 1679 m de D+ dans GPXtoXL, avec dans les deux cas le même réglage de seuils (seuil inférieur : 0 - seuil supérieur : 10).
Quant à l'alti de mon GpsMap 60 CSx, il indique 1550 m.
Comment de tels écarts peuvent-ils s'expliquer

Quel rapport y a-t-il me direz-vous, entre ce joli Fuligule milouin photographié au jardin botanique de Nantes, ce topic, et un développeur en Excel en la personne de Titof ?
...
Vous avez trouvé ?

C'est tout simple : derrière cette apparente tranquillité dénuée d'expression, se cache une dépense d'énergie considérable à pédaler comme un fou pour avancer...

Merci de me comparer à un canard...
J'ai pas tout de suite compris la métaphore. Au début j'ai crus que Christian avait pété un câble....

Il a certes raison, les travailleurs de l'ombre, n'ont pas chômé : nous en somme lui et moi déjà à la version 1.3.6. Tous les bugs présentés plus haut ayant été corrigé.
La seule difficulté qui nous reste, et non des moindre, est de trancher sur une méthode de calcul du pourcentage de pente moyen. En effet, dans la dernière version (1.3.0), GPXtoXL calcul le pourcentage moyen en calculant le pourcentage de chaque côte et en faisant la moyenne de tous ces %.
ChristanB suite à une mystérieuse intuition, m'a démontré que cette méthode avait tendance à exagérer le résultat.
Il m'a (presque) convaincu que la méthode la plus juste serait de diviser le dénivelé positif par le déplacement en cote.
En ce qui me concerne, j'ai l'impression quil y'ait une formule plus juste que l'autre mais ne m'explique par pourquoi on observe un biais entre les deux résultat de calcul.

Aussi, nous avons une différence de point de vue sur le calcul du pourcentage de pente en général. Après une recherche bibliographique, il en ressort la formule :

• % = D+/distance horizontale parcourue

Comme on travaille dans l'espace, j'en ai conclu que la distance horizontale parcourue était grâce à pythagore :

• distance horizontale = racine(Distance entre 2 points²-D+²)

Mais ChristianB m'a rétorqué que selon lui, les distances calculées sont déjà le fruit d'une projection et que donc ce calcul est superflu.
Sur un terrain plat, il est vrai que la différence sera minime. Parcontre sur un parcours un peu plus cassant je pense que l'on peut avoir des différences supérieures à plusieurs pourcents.

Nous somme curieux d'avoir vos avis sur ces différents point de vues

Je pourrai alors "libérer" la version 1.3.7

Voilà en dehors des petites étourderies de programmation, voilà ce qui anime notre correspondance depuis une semaine. Voilà ce que sous l'eau fait le canard....

En ce qui concerne le calcul du D+, il me semble que nous l'avons validé depuis un moment. Nous n'avons pas trouvé de différence significative entre GPXtoXL et autre logiciel ou API
Christian Montessuit, pour ta trace j'ai envie de dire : envoie le fichier....

Titof6.9 a écrit : Nous somme curieux d'avoir vos avis sur ces différents point de vues

si comme je le suppose, la distance entre deux points est calculée à partir des couples (lat/long) de chaque point, il est évident que cette distance est une distance projetée (donc horizontale). Pas nécessaire de réveiller Pythagore pour ça

Bon courage et vogue petit Saturnin

Ca m'arrive aussi de "péter un câble"; j'ai un humour parfois difficile à suivre je reconnais...

Je pense que tu as déjà résolu le problème de Christian M. dans une version intermédiaire non encore publiée, je t'avais transmis ses fichiers. Je ne me souviens plus de la raison du bug, mais tu l'as réglé je crois, je vérifierai.

Pour moi l'augmentation de distance due aux variations d'altitude (1% en plus pour une bonne pente à 14% par exemple) est prise en compte par CE3 ou par le GPS à partir des données altimétriques. Le calcul de distance entre deux points de LAT et LON connues, vu les fonctions utilisées, sont celles pour un ellipsoïde ou une sphère.

Pour le calcul de % moyen des côtes, entre les deux méthodes de calcul de GPXtoXL (et d'autres softs) et la mienne, on peut avoir une moyenne à 17% (mon calcul) ou une moyenne à 30%...Pas négligeable (exemple d'une montée au château de la Madelaine à Chevreuse, je joins le fichier avec le graphique inclus).
Selon moi les distances entre deux points de mesure en côte sont trop courtes et la précision du GPS est trop faible pour obtenir des valeurs de % suffisamment précises (exemple : sur une distance de 2m, élévation enregistrée de 1m, donc côte à 50%...). Donc le résultat dépend aussi de la façon dont les points sont enregistrés par le GPS (à distance constante, à intervalle de temps constant, ou "optimisé" comme pour mes fichiers).

Que pensez-vous de tout cela ? Des réponses aux questions de Titof ? On n'arrive pas à se décider alors on fait appel aux contributeurs...