Trace daté de 1970...

[Seb26]

Quand je passe mes traces gpx à la moulinette, elles ressortent daté de 1970.

Ceci n'est pas très gênant en soit mais empêche de faire des comparaison en mode Time où l'on voit les différentes traces se construire petit à petit.

J'ai vérifié le gpx, la date des différents points est bonne.

Je pensais faire une modification dans le fichier google, mais le kmz mais c'est du compréssé

Du coup, la solution de contournement que j'ai trouvé consiste à sauvegarder le kmz en kml, faire un replace all de tous les time stamp "<when>1970-01-01" par "<when>2009-05-07"      

Est-ce qu'il y a d'autres personnes qui aurait rencontré ce problème et qui pourraient mieux comprendre à identifier la cause de ce mauvais datage?

Sinon, une idée Man's?

[marc]

donne ta trace d'origine, on pourra jeter un oeil déjà.

Pour info, le kmz, c'est un zip. Donc tu prends ton zip préféré (winzip & cie), tu ouvres, et dedans t'as un kml. Tu édites ce kml, tu rezipes, et t'as un kmz.

[Seb26]

Vu comme ça, c'est sûr que c'est déjà moins lourd que d'ouvrir google earth pour faire de la compression/décompression.

Sinon, j'ai réussi à transformer ma trace gpx en igc via gps babel, et là plus de soucis. Le problème vient peut être du décryptage des gpx...

[Man's]

Le problème vient peut être du décryptage des gpx...

Oui, ca me revient vaguement maintenant : je crois que je etais aperçu de ce bug quand j'avais développé GPS2GE, mais comme j'arrivais pas à le corriger (et à vrai dire, je n'imaginais pas que ça puisse vraiment gêner quelqu'un !), j'avais laissé tomber...
Promis, dès que j'ai un peu de temps (c'est à dire dans longtemps ), je vais regarder ça et aussi donner un coup de jeune au module de stats de parawing !

[Seb26]

Le problème vient peut être du décryptage des gpx...

Oui, ca me revient vaguement maintenant : je crois que je etais aperçu de ce bug quand j'avais développé GPS2GE, mais comme j'arrivais pas à le corriger (et à vrai dire, je n'imaginais pas que ça puisse vraiment gêner quelqu'un !), j'avais laissé tomber...
Promis, dès que j'ai un peu de temps (c'est à dire dans longtemps ), je vais regarder ça et aussi donner un coup de jeune au module de stats de parawing !

En fait, je viens de voir qu'il était possible d'enregistrer des igc depuis gpsdump (ne pas faire save log as... mais save log as igc )

Et là ça marche très bien, donc ça ne doit pas gêner grand monde   

Sinon, je me suis apperçut d'autre chose en dépouillant ma trace, mais là je ne sait pas si le pb vient de GPS2GE ou de ma compréhension de la CFD:
Dans le calcul d'une distance libre 1 ou 2 points, la dernière balise est positionnée à l'attero et non sur le point le plus éloigné. Est-ce une règle de la CFD ou une approximation de l'outil pour simplifier les calculs?

[Man's]

Sinon, je me suis apperçut d'autre chose en dépouillant ma trace, mais là je ne sait pas si le pb vient de GPS2GE ou de ma compréhension de la CFD:
Dans le calcul d'une distance libre 1 ou 2 points, la dernière balise est positionnée à l'attero et non sur le point le plus éloigné. Est-ce une règle de la CFD ou une approximation de l'outil pour simplifier les calculs?

Normalement, GPS2GE va chercher les meilleurs balises, qui ne sont pas forcément le déco ou l'attérro. Cela dit, on n'est jamais à l'abri d'un bug (je sais qu'il y a des erreurs sur les parcours en QU notamment, les plus compliqués). Si tu as une trace ou ca le fait sur une DL1 ou DL2, ca m'intéresse !

[Seb26]

Revoilà ma trace d'hier (mais cette fois depuis un igc):
http://carnet.parawing.net/get_kml?trace=fiches/trace/9984-14-59.kmz

Dans ce cas, le point le plus loin n'est que 300m plus éloigné que l'attero, c'est paut être pour ça aussi qu'il n'est pas retenu. Mais dans mon cas, c'est les 300m qui me permettent d'atteindre la barre des 70km en DL1 ).

Sinon, toujours avec cette trace, j'ai vu qu'il y avait un décalage d'une heure sur la trace affichée: les min/max sont bons, mais les time stamp sont décalés d'une heure (je n'ai quand même pas été à st Marcel pour décoller à 12h32)

[Man's]

Dans ce cas, le point le plus loin n'est que 300m plus éloigné que l'attero, c'est paut être pour ça aussi qu'il n'est pas retenu.

C'est possible en effet. Pour ne pas mettre des heures à générer une trace, GPS2GE les simplifie pour les calculs CFD en ne prenant que les points les plus significatifs, et il peut donc y avoir des approximations.

Sinon, toujours avec cette trace, j'ai vu qu'il y avait un décalage d'une heure sur la trace affichée: les min/max sont bons, mais les time stamp sont décalés d'une heure (je n'ai quand même pas été à st Marcel pour décoller à 12h32)

Oui, et c'est vrai que c'est plus gênant que la date en 1970 ! . La aussi, j'avais des bugs zarbis qu j'arrivais pas à résoudre (des fois, c'est la bonne heure, d'autres fois, non...), et j'ai abandonné, vu que au pire, si tu tiens à avoir l'heure exacte, tu peux toujours regenerer ta trace en jouant avec le paramètre de décalage horaire du formulaire de saisie...

[Seb26]

En fait il semble que le recalage marche pour les min/max et les noms des points, mais pas forcément pour la trace...

En effet, dans le kml on trouve ceci:

Code:

<name>[b]12:29[/b] : 891 m 2 km/h 0.1 m/s</name>
					<LookAt>
						...
					</LookAt>
					<TimeStamp><when>[b]2009-05-07T10:29:35Z[/b]</when>
</TimeStamp>

Il semblerait donc que pour les min/max, nom des points l'heure corresponde à:
UTC + 1 + décalage moulinette

Et que pour les points de la trace, il corresponde à UTC + 1

Conclusion, c'est tip top bon en hiver, mais au printemps et en été il y a un petit décalage.

Pour info, les traces issu du site de la cfd possèdent le bon timing...

[Bradepitre]

donne ta trace d'origine, on pourra jeter un oeil déjà.

Pour info, le kmz, c'est un zip. Donc tu prends ton zip préféré (winzip & cie), tu ouvres, et dedans t'as un kml. Tu édites ce kml, tu rezipes, et t'as un kmz.

C'est bizarre, il me semble que le kmz est plus "lourd" que le kml. Je croyais que dans le kml, il manquait certaines données.
(Mais, j'ai le même problème avec le 1970)