Les premiers tests d'utilisation de mon nouveau joujou, un GPS Data Logger (voir mon précédent billet) m'ont confirmé ce que je savais déjà, en fait : la vraie première galère, c'est le temps.

Je m'explique : je me promène avec mon GPS et mon appareil photo. Voilà ce qui se passe :

Le GPS est réglé sur l'heure des satellites, eux même synchronisés avec des horloges atomiques (la mesure précise de la position est dépendante d'une mesure précise de l'heure). Le GPS est donc synchronisé sur une horloge commune, en temps UTC (Temps Universel Coordonné en français), qui permet de s'affranchir des problèmes posés par les heures locales. L'appareil photo, lui, est réglé à la main, à l'heure locale (enfin, plus ou moins).

L'enjeu est de synchroniser le GPS avec l'appareil photo. Pourquoi ? parce que si ce n'est pas le cas, les photos ne seront pas bien placées sur la carte : mauvaise heure = mauvais endroit !

Il faut donc régler plusieurs problèmes :

  • D'une part, obtenir le fuseau horaire local à partir des données de position du GPS : pour cela, j'utilise le service web proposé par GeoNames, qui me donne la réponse très simplement.
  • Ensuite, prendre en compte les éventuels changements d'heures liés au passage à l'heure d'hiver/d'été. Là encore, je suis aidé : la base de données zoneinfo (TZ) permet de répondre à cette question (après un portage en C#, je ne ménage pas ma peine, ma p'tite dame).
  • Enfin, corriger la dérive éventuelle de quelques secondes à quelques minutes, entre l'heure locale "officielle", et l'heure de l'horloge de l'appareil photo. Et c'est là que ça se gâte.

C'est là que réside le vrai grand problème, et, assez étrangement, personne ne semble s'y être intéressé. Je sais que les services de positionnement de photos sur des cartes sont encore très jeunes. Pourtant, des ténors comme Flickr ou Google proposent se genre de services, mais... à vous de vous débrouiller.

Personnellement, je ne suis pas fan des solutions manuelles, du genre :

  • Régler à la main l'heure sur son appareil photo à partir d'une horloge fiable (mais mon appareil ne permet pas de descendre en dessous de la minute, et la dérive de l'horloge oblige à refaire l'opération fréquemment)
  • Photographier une horloge à chaque début de série (plus malin, mais pas très automatique).

Moi, ce dont j'ai envie, c'est d'un biniou qui fasse le boulot tout seul. Non, mais !

Alors, comme je suis assez têtu au niveau des défis, j'ai eu une idée.

Quand on prend une photo, en général, on s'arrête, ou au moins, on ralentit

Il suffirait donc de corréler les baisses de vitesse de marche avec les moments où sont prises les photos, et le tour serait joué ? J'ai tenté le coup, et :

  • Introduit dans mon code une notion d'"estimation d'arrêt" (Stop Estimation). Je calcule la vitesse instantanée (en utilisant la mesure de distance dite du Grand Cercle); je définis l'estimateur d'arrêt comme l'exponentielle de l'opposé de cette vitesse : e^(-v/v0), qui est un nombre entre 0 et 1 (0 = mouvement rapide, 1 = arrêt total).
  • Appliqué cet estimateur à l'ensemble des données d'une trace GPS. J'applique à chaque photo un décalage temporel (compris entre -5 et +5 minutes, je recommence pour chaque seconde de cet intervalle), et j'effectue la somme des estimateurs d'arrêt sur les données GPS correspondant aux dates ainsi calculées.
  • Obtenu le décalage donnant la valeur la plus grande (et donc la vitesse moyenne la plus faible pour l'ensemble des photos).

Bon, c'est un peu compliqué, mais en clair, on obtient ceci :

Là, on remarque qu'avec un décalage de 6 secondes, on obtient le meilleur résultat (plus grand nombre de photos prises en compte, meilleur calage). Pour vérifier, on peut afficher la courbe de l'estimateur d'arrêt et la comparer à la position des prises de vue :

On constate que les prises de vue correspondent à des maximums locaux de l'estimateur d'arrêt.

Et ça, c'est plutôt encourageant... La suite dans le prochain épisode, et en attendant, bonne nuit !