Données d'entrée¶

Les fichiers de test sont situés dans :

Data/GPS/declic/waypoints-sample/

Chaque fichier correspond à une journée de waypoints. Les fichiers sont séparés par point-virgule.

Schéma brut observé¶

Colonne	Rôle	Traitement local
`user_id`	identifiant utilisateur	conservé comme `source_user_id`
`tracked_at`	timestamp brut	converti en `timestamp` UTC
`latitude`	latitude WGS84	convertie en `lat`
`longitude`	longitude WGS84	convertie en `lon`
`accuracy`	précision GPS en mètres	utilisée comme filtre qualité
`speed`	vitesse brute	convertie en `speed_kmh`
`altitude`	altitude	non utilisée par le modèle
`course`	cap	non utilisé par le modèle

Lors de la lecture, le pipeline ajoute un waypoint_id stable de la forme nom_du_fichier:numéro_de_ligne. Cette stabilité suppose que le fichier source ne soit pas réordonné.

Legs nettoyés¶

La source principale des legs est :

Data/GPS/declic/cleaned-base/parquet/legs.parquet

Cette table doit couvrir les mêmes utilisateurs et la même période que les waypoints. Seules les lignes dont type == "Track" sont utilisées. Elles sont normalisées avec les colonnes suivantes :

Colonne	Rôle
`user_id`	clé commune avec les waypoints
`started_at`	début du leg, interprété en UTC
`finished_at`	fin du leg, interprétée en UTC
`leg_id`	identifiant principal du leg
`storyline_id`	identifiant de storyline conservé pour traçabilité
`trip_id`	déplacement contenant le leg
`mode`	mode confirmé, prioritaire
`detected_mode`	mode détecté, utilisé si `mode` est absent
`mode_niv1`, `mode_niv2`, `mode_mrmt`	nomenclatures harmonisées conservées en sortie

La correspondance utilise un intervalle demi-ouvert :

même user_id
et started_at <= timestamp < finished_at

Cette convention évite d'attribuer deux fois un point situé exactement à la frontière entre deux legs contigus. Si plusieurs legs recouvrent simultanément un point, le leg dont le début est le plus récent est renseigné pour diagnostic, mais le statut overlapping_tracks empêche l'utilisation du point par le modèle.

Les statuts possibles sont :

Statut	Interprétation
`matched`	correspondance unique avec un leg
`outside_track`	utilisateur présent, mais aucun leg ne couvre le timestamp
`user_without_tracks`	aucun leg disponible pour cet utilisateur
`overlapping_tracks`	plusieurs legs couvrent le timestamp

Format attendu par ReLUT¶

Le modèle ReLUT attend des trajectoires contenant au minimum :

Colonne	Rôle
`lon`	longitude en degrés décimaux
`lat`	latitude en degrés décimaux
`timestamp`	date-heure lisible par pandas
`speed_kmh`	vitesse non négative en km/h

Les colonnes supplémentaires sont conservées dans les exports locaux pour la traçabilité, mais ne sont pas utilisées par le modèle.

Conversion locale¶

Le pipeline applique les conversions suivantes :

Source	Sortie	Hypothèse
`longitude`	`lon`	coordonnées WGS84
`latitude`	`lat`	coordonnées WGS84
`tracked_at`	`timestamp`	timestamp parsable avec fuseau horaire
`speed`	`speed_kmh`	vitesse brute en m/s, convertie par `* 3.6`

L'unité de vitesse est configurable par raw_waypoints.speed_unit.

Point à vérifier

Le pipeline suppose actuellement que speed est exprimée en m/s. Si la source fournit déjà des km/h, il faut modifier speed_unit: kmh.

Vitesses manquantes ou inconnues¶

Les valeurs -1 sont traitées comme vitesses inconnues. Lorsque la vitesse brute est absente ou inconnue, le pipeline calcule une vitesse approximative entre deux points successifs d'un même utilisateur :

distance haversine entre points successifs / delta temps

Cette imputation est utile pour faire fonctionner le modèle, mais elle reste une approximation. Elle peut amplifier les erreurs si les timestamps sont irréguliers ou si la position saute brutalement.