mettre en fonctions la datapreparation

créer une fonction pour chacun des 6 scripts de datapreparation, qui soient lancés dans un seul script dataprep.R

created branch 47-mettre-en-fonctions-la-datapreparation to address this issue

added En cours label

added Prêt label and removed En cours label

@JulietteEngelaere @christelle.belkacem @denis.douillard

Procédure jusque à ce jour: les fichiers source sont chargés sur le serveur rstudio cgdd et recopiés sur le poste de l'utilisateur, qui lance les 5 scripts de datapreparation. Ces scripts crééent le fichier rda qui sert au package.

Action effectuée ce jour: ajout d'un 7e script qui part du résultat du script 7, effectue des filtres pour ne garder que ce qui servira dans le sgbd et met la table au bon format, et enregistre la table sur le serveur ecosql. De plus, ces indicateurs ont été mis à jour dans le googlesheet de sgbd_datamart. On va donc pouvoir à présent récupérer ces données pour indicateur territoriaux.

La prochaine étape consistera à transformer ces 7 scripts en fonctions du package.

Denis, pourrais-tu de ton poste dans R, mettre à jour ta branche main, charger le fichier indic_ecln.rda dans ton environnement, et puis lancer le script 7. ça permettra de voir si ça marche bien chez toi, et ça chargera les données du 4e trimestre qui sont sur ton poste sur le serveur eco_sql. Lors des prochains trimestres, il faudra lancer les 7 scripts au lieu des 6 actuellement( dans l'attente que je fasse les modifs).

@Daniel.Kalioudjoglou tu vas un peu trop vite là, je t'avais demandé hier de ne pas toucher à ce dépôt et de mettre le script de chargement dans sgbd_datamart en utilisant system.file pour accéder aux script de datapréparation et aux données de propre.ecln

@JulietteEngelaere @christelle.belkacem Juliette, Pour faire le parallèle avec propre.eptb:

• premier script de datapreparation: dans propre.eptb, lancement de 3 fichier RMD (DATASET 1, 2, et 3) qui créent le fichier tab_result.parquet qui est stocké sur le serveur CGDD. dans propre.ecln, lancement de 5 scripts R qui créent directement le fichier ecln.RDA stocké dans le package. A noter que cette data-préparation dans propre.eptb n'est pas une fonction du package.
• deuxième script de datapréparation: dans propre.eptb, fonction dataprep.R qui est une fonction du package et dont la seule utilité est de filtrer la région et de créé le rda. Dans propre.ecln, L'équivalent de cette fonction est la fonction facultative 6 (filtre région), que Denis n'utilise pas. On peut donc dire qu'on n'en a pas besoin pour ECLN.
• ensuite on a le script de chargement sur ecosql: pour eptb, script de chargement intégré à sgbd datamart. Pour Ecln, script 7, qui est intégré à Eptb, qui change le format du fichier (disposition des colonnes entre autre, pour le mettre au format du sgbd) et charge la table sur ecosql.

Nous avons donc exactement la même structure et la même procédure entre les 2 applis. Les différences sont:

• 1. Existence d'un fichier intermédiaire parquet (avant création du rda) pour eptb, faute d'emplacement dédié sur le serveur pour ecln.
• 2. le dernier script est lancé depuis sgbd datamart pour eptb, et depuis PROPRE.ecln pour ecln.

Le gros avantage que je vois au fait de lancer tout depuis ECLN est que Denis le faisant dès que les données sont disponibles, les données sur le serveur ecosql seront toujours à jour, ce qui ne sera pas le cas si c'est intégré à sgbd datamart.

Ensuite, dans les 2 cas, on a cogification et/ou indicateurs, dans sgbd datamart.

Je te propose d'en reparler pour que je puisse finaliser.

Il y a bcp de choses à revoir dans ce dépôt, c'est pour cela que je t'avais demandé de ne pas y toucher.

Filtrer sur la région observée ne doit pas se faire dans un script de data-raw mais dans une fonction de data-preparation exécutée par le rédacteur dans son book en fonction d'un parametre code région, le script 6 est à supprimer surtout si Denis ne l'utilise pas.

Dupliquer la fonction poster_document_it dans ce dépôt est une très mauvaise idée pour le long terme et est donc à proscrire.

La datapréparation effectuée par l'utilisateur dans sa publication idéalement repart d'un jeu de données déjà conçu par le mainteneur du package, pour éviter à tous de refaire les mêmes calculs et de supporter les temps de calculs. Cela nécessite par exemple d'écrire dans un dossier partagé du serveur comme dans propre.eptb ou d'avoir le go pour utiliser tous les mêmes données issues de ta secrétisation pour pouvoir les intégrer au package. Cette décision n'a pas la même temporalité que celle de la mise à jour de l'app IT. En attendant, on ne peut pas savoir avec certitude quelles modifications sont à apporter durablement, d'où ma demande de travailler dans sgbd_datamart uniquement.

Ma première idée était d'exécuter les scripts 1 à 5 de propre.eptb dans sgbd_datamart, avec une fonction source(nom_du_script.R) pour toucher le moins possible au dépôt et aussi parce que je vous pensais dans le contexte du serveur SDES avec une impossibilité de partager facilement des résultats entre utilisateurs.

Aujourd'hui que j'ai conscience qu'on est toujours dans le contexte bureautique de la DREAL, pourquoi ne pas simplement enregistrer indic_ecln dans un RData sur X:/SCTE/CSD/DONNEES_CONFIDENTIELLES/_niveau_2/Conjoncture/ECLN/ dans plus de usethis::use_data(indic_ecln). Tu repars de ce .RData pour le script de chargement de SGBD datamart et c'est réglé.

Franchement pourquoi me parles-tu d'ecoSQL alors que tu peux travailler de ton PC ?

Filtrer sur la région observée ne doit pas se faire dans un script de data-raw mais dans une fonction de data-preparation exécutée par le rédacteur dans son book en fonction d'un parametre code région, le script 6 est à supprimer surtout si Denis ne l'utilise pas.

C'est effectivement ce que je viens de te suggérer dans le paragraphe précédent (supprimer le script 6). Le rda du package est léger avec France entière, donc pas besoin de le filtrer.Le filtre région se fait via un parametre du rmd de création de la publication. @JulietteEngelaere

La datapréparation effectuée par l'utilisateur dans sa publication idéalement repart d'un jeu de données déjà conçu par le mainteneur du package

C'est exactement le cas actuellement. C'est ce que j'ai essayé de t'expliquer. Denis est le mainteneur du package. Il créé ce jeu de donnée avec les scripts 1 à 6, que je n'aurai peut-être pas dû appeler data préparation, alors. Tout comme dans Eptb et RPLS, cette manip est effectuée hors sgbd datamart. Cette manip est assez longue et est bien effectuée avant l'utilisation du package par les utilisateurs.

ou d'avoir le go pour utiliser tous les mêmes données issues de ta secrétisation pour pouvoir les intégrer au package

C'est donc ce que j'ai fait (intégrer au package). Le package n'étant pour l'instant utilisé que chez nous, et le rda n'étant pas déposé sur gitlab, pas de problème de "go".

pourquoi ne pas simplement enregistrer indic_ecln dans un RData sur X

Bonne idée, ça me convient parfaitement

Franchement pourquoi me parles-tu d'ecoSQL alors que tu peux travailler de ton PC ?

L'idée était de se préparer à l'évolution à venir qui serait de basculer ces 6 scripts sur le serveur rstudio, mais aussi de pouvoir partager la table préparée, secrétisée et cogifiée aux utilisateurs des autres régions. Elle était postée depuis mon PC. Mais si ce n'est pas nécessaire, alors oui, on oublie.