Update du format de données de l'action d'export csv pour l'open data

[P3rceval]

On repart du format du dernier export réalisé (cf https://www.data.gouv.fr/fr/datasets/trajets-realises-en-covoiturage-registre-de-preuve-de-covoiturage/) On utilise l'action BuildExport

• [x] S'assurer que long et lat ne sont pas inversés et s'affichent avec 2 décimales en fonction de la densité de population comme actuellement
• [x] Ajout des distances en mètres (exposée, sinon calculée)
• [x] Régler le problème d'encodage => Passer en UTF-8
• [ ] Ajout de unit tests sur le formatage
• [x] migration manuelle des données

[jonathanfallon]

:warning: les lon/lat doivent être tronquées en fonction de la densité de population pour avoir un carroyage dynamique et assurer l'anonymisation des données !

[jonathanfallon]

Demande des opérateurs pour pouvoir faire des recoupements :

• Ajout d'une colonne operator_journey_id qui est envoyée par l'opérateur

Voir la doc technique pour le schema

[jonathanfallon]

Mise à jour des colonnes operator_journey_id, operator_driver_id et operator_passenger_id dans trip.list.

La mise à jour est trop longue pour être passée dans une migration. Les requêtes sont exécutées via un one-off container et un script.

#!/bin/bash

# install db client
dbclient-fetcher postgresql 12

# export connection vars for PostgreSQL
export $(DATABASE_URL=$APP_POSTGRES_URL npx pgexplode)

# timestamp the start
date

# update operator_journey_id
psql -c 'update trip.list set operator_journey_id = aa.journey_id from acquisition.acquisitions aa where trip.list.journey_id = aa._id;'

# bench for first query
date

# update operator_driver_id and operator_passenger_id
psql -c "update trip.list tl set operator_driver_id = aa.payload#>>'{driver,identity,operator_user_id}', operator_passenger_id = aa.payload#>>'{passenger,identity,operator_user_id}' from acquisition.acquisitions aa where tl.journey_id = aa._id;"

# timestamp the end
date

Le script doit être lancé dans un container détaché (--detached) pour éviter les problèmes de timeout. Malheureusement, il n'est pas possible d'uploader le script (-f script.sh) vers le container avec le mode détaché. Solution : on upload le script sur un S3 public et on le lance via un wget dans le container.

scalingo -a pdc-prod r --detached "wget -q -O - https://my-s3-bucket/script.sh | bash"

Monitoring

• Dashboard de la DB
• Running queries sur le dashboard PG
• tail des logs (ci-dessous

scalingo -a pdc-prod logs -f | less -p one-off

[nmrgt]

@nicolas-viennot-beta on peut fermer ?

[nicolas-viennot-beta]

@P3rceval : est-ce ok pour toi de clore ce ticket ? (pas possible pour moi de le tester)

[nmrgt]

@P3rceval on peut fermer ?

[github-actions[bot]]

Ce ticket est marqué comme obsolète car cela fait 60 jours qu'il n'y a pas eu d'activité dessus. Retirez ce label ou ajoutez un commentaire sinon ce ticket sera fermé dans 5 jours.

[github-actions[bot]]

Ce ticket a été fermé car cela fait 5 jours qu'il a été marqué comme obsolète sans activité