Notes de travail - données synthétiques GPS¶

Page de maintenance

Cette page conserve des décisions de développement. Les données test utilisables sont décrites dans la section Utiliser le package.

Cette page conserve les décisions de travail sur la génération de jeux de données GPS synthétiques pendant le développement de xyt_gps.

Les fichiers générés ne doivent pas être placés dans examples/. Ils doivent être écrits sous Data/Output/ ou dans un autre dossier local ignoré par git.

État actuel¶

Un premier générateur synthétique a été ajouté au package :

module : src/xyt_gps/synthetic.py ;
fonction principale : xyt.generate_synthetic_declic_gps() ;
fonction d’écriture : xyt.write_synthetic_gps_dataset() ;
script : examples/generate_synthetic_declic_testset.py ;
doc : docs/getting-started/synthetic-data.md.

Le générateur actuel ne repose pas sur un GAN, VAE ou CTGAN. Il utilise un bootstrap contrôlé à partir du sample autorisé, puis :

ré-échantillonne des journées GPS observées ;
décale ces journées vers les dates des expérimentations Déclic ;
crée des utilisateurs synthétiques ;
perturbe les géométries ;
injecte des anomalies paramétrées : jours manquants, profils de tracking incomplets, timestamps de confirmation absents, divergences detected_mode / mode, longueurs extrêmes.

Ce choix a été retenu parce que le sample disponible ne contient qu’un seul utilisateur. Ce n’est pas suffisant pour entraîner un modèle comportemental profond défendable.

Dataset synthétique généré¶

Chemin local recommandé :

Data/Output/synthetic-declic-testset/

Contenu généré lors de la dernière passe :

Table	Format	Volume
`storyline`	CSV + Parquet	229 579 lignes
`trips`	CSV + Parquet	125 324 lignes
`journeys`	CSV + Parquet	13 282 lignes
`user_statistics`	CSV	250 lignes
`user_presence`	CSV	250 lignes
`generation_manifest`	CSV	5 lignes

Expérimentations simulées :

Expérimentation	Utilisateurs	Lignes storyline
`declic-mobility-prefig`	50	40 884
`declic-mobility-vague1`	50	37 081
`declic-mobility-vague2`	50	35 703
`declic-mobility-vague3`	50	33 790
`declic-mobility-ziplo`	50	82 121

ZIPLO est plus volumineux parce que la phase 2 simulée est plus longue.

Important : la première génération a écrit aussi des CSV lourds. storyline.csv pèse près de 1 Go. Le comportement par défaut a ensuite été corrigé pour écrire les tables lourdes en Parquet uniquement, sauf demande explicite.

Commande recommandée pour régénérer :

python examples/generate_synthetic_declic_testset.py \
  --output ../Data/Output/synthetic-declic-testset \
  --users-per-experiment 50

Commande si l’on veut aussi les CSV lourds :

python examples/generate_synthetic_declic_testset.py \
  --output ../Data/Output/synthetic-declic-testset \
  --users-per-experiment 50 \
  --formats csv parquet

Aperçu cartographique¶

Un aperçu léger a été généré ici :

Data/Output/synthetic-declic-preview/

Fichiers utiles :

synthetic_gps_traces_map.html : carte interactive Folium ;
synthetic_gps_traces_static.svg : aperçu statique autonome ;
rows_by_experiment.csv : volumes par expérimentation ;
tracking_profiles.csv : répartition des profils de tracking ;
phase_rows.csv : lignes par expérimentation, phase et type ;
mode_rows.csv : lignes Track par mode ;
tracking_quality_summary.csv : jours actifs par profil de tracking.

La carte affiche un extrait volontairement limité :

10 utilisateurs synthétiques ;
350 legs ;
200 staypoints ;
couleur par expérimentation.

Elle ne cherche pas à afficher toute la base, qui serait illisible et trop lourde.

Validation effectuée¶

Le dataset synthétique a été relu et validé avec :

xyt.validate_gps_raw(raw)

Résultat :

storyline : valide ;
trips : valide ;
journeys : valide ;
user_statistics : valide.

Une transformation complète a aussi été testée :

xyt.prepare_mobility_dataset(
    raw,
    xyt.ProjectConfig(),
    resample_missing_days=False,
    clean_leg_geometries=False,
    add_signal_quality_flags=False,
)

Résultat :

storyline conservée après suppression contrôlée des géométries manquantes : 229 120 lignes ;
legs : 125 077 lignes ;
staypoints : 104 043 lignes ;
trips : 125 324 lignes ;
journeys : 13 282 lignes ;
user_stats : 250 lignes.

Tests package :

pytest tests -q

Résultat au moment de ce mémo : 44 tests passés.

Doc :

python -m mkdocs build --strict

Résultat au moment de ce mémo : build OK, avec les avertissements déjà connus de MkDocs Material et deux pages hors navigation.

Confidentialité et données sensibles¶

Principe retenu :

ne pas lire les données sensibles dans Data/ sans autorisation explicite ;
utiliser le sample autorisé pour les démonstrations ;
si un entraînement sur données réelles est lancé plus tard, il devra se faire localement ;
ne pas afficher les lignes sensibles dans les sorties ;
ne pas exporter les données réelles brutes hors du répertoire projet ;
ne produire que des diagnostics agrégés, des métriques qualité et des données synthétiques.

Point important discuté :

Un modèle ne peut pas être entraîné sans lire les données. En revanche, le code d’entraînement peut être écrit pour que les données restent locales, sans copie externe et sans affichage de contenu sensible.

Piste SDV / GAN / VAE / CTGAN à reprendre¶

La piste SDV semble intéressante, mais elle ne doit pas être utilisée directement sur une colonne geometry EWKB brute.

La base GPS est multi-table, séquentielle et géospatiale. Les géométries sont longues, fortement identifiantes et difficiles à apprendre comme une simple variable tabulaire.

Approche recommandée plus tard :

Construire des tables d’apprentissage dérivées :
user_features ;
daily_tracking_features ;
legs_features ;
trips_features ;
éventuellement journey_features.
Entraîner un modèle SDV sur ces tables dérivées.
Générer des lignes synthétiques tabulaires.
Reconstruire des géométries plausibles séparément :
soit par perturbation contrôlée de traces réelles ;
soit par formes simplifiées entre zones origine-destination ;
soit par ré-échantillonnage de patrons de trace anonymisés.
Réassembler au format attendu par xyt_gps.
Valider avec xyt.validate_gps_raw() puis xyt.prepare_mobility_dataset().

Modèles SDV envisagés :

Modèle	Rôle possible	Remarque
`GaussianCopulaSynthesizer`	baseline rapide	À tester en premier pour avoir une référence simple
`TVAESynthesizer`	modèle VAE tabulaire	Probablement le premier modèle profond à tester
`CTGANSynthesizer`	GAN tabulaire	À tester si TVAE ne suffit pas, plus lent et plus délicat
`HMASynthesizer`	multi-table	Intéressant si le schéma reste simple, environ 5 tables avec relations parent-enfant

La fonction SDV sample(num_rows=...) ne crée des données réalistes qu’après entraînement d’un synthesizer. Elle n’est donc pas une solution complète seule : il faut d’abord préparer les données, déclarer la metadata, entraîner, évaluer, puis échantillonner.

Proposition de reprise¶

Créer plus tard un notebook :

Notebooks/Package-ready/ ou un notebook exploratoire dédié hors `examples/`

Structure proposée :

charger les données réelles localement ;
construire des tables features non directement identifiantes ;
définir la metadata SDV ;
entraîner un baseline GaussianCopulaSynthesizer ;
entraîner un TVAESynthesizer ;
comparer avec un CTGANSynthesizer si nécessaire ;
évaluer les distributions, les corrélations et les risques de proximité avec les données réelles ;
reconstruire un dataset MotionTag-like synthétique ;
valider avec le package ;
exporter vers Data/Output/ ou un autre dossier local ignoré par git.

Critères minimaux de succès :

le dataset synthétique passe xyt.validate_gps_raw() ;
xyt.prepare_mobility_dataset() fonctionne ;
les distributions principales sont plausibles : modes, durées, longueurs, jours actifs, semaines de participation, phases ;
les traces synthétiques ne recopient pas exactement les trajectoires réelles ;
aucune colonne directement identifiante n’est conservée ;
les limites du modèle sont documentées.

Points à ne pas oublier¶

Installer les dépendances SDV dans un fichier séparé, par exemple requirements-synthetic.txt, pour ne pas alourdir le cœur du package.
Ne pas intégrer SDV comme dépendance obligatoire de xyt_gps.
Garder la génération synthétique comme outil de développement, de test, de documentation et de démonstration.
Ne pas présenter les données synthétiques comme représentatives des comportements réels sans validation méthodologique.
Documenter clairement la différence entre :
données testset ;
données synthétiques ;
données anonymisées ;
données réelles sensibles.