Création d'un package avec des jeux de données en français #29

Closed linogaliana closed 3 years ago

In GitLab by @oliviermeslin on Mar 31, 2020, 13:17

@ggenin a proposé que nous créions un package avec des jeux de données en français, que nous utiliserions dans tous les exemples de la documentation. Cette idée me paraît bonne, mais je n'ai pas d'expérience de développement de package. Je vois deux questions:

Est-il possible d'inclure des fichiers de format autres que R dans un package (je pense aux .csv, .shp, .sas7bdat...). Ca me semble indispensable pour illustrer les fonctions d'importation. Et est-il possible d'écrire une fonction qui remet ces fichiers non R dans un répertoire indiqué par l'utilisateur (exemple: "D:/Utilisateurs/OMESLIN/Codes/InitiationR"), pour qu'ils puissent être manipulés facilement?
Quels jeu de données souhaitons-nous inclure? J'ai pensé à:
- un csv, une table SAS, un shp, un csv avec des coordonnées géographiques;
- un jeu de données qui contient des chaînes de caractères (pour stringr);
- un jeu de données avec des données quanti et quali (pour faire des stats par groupe et des graphiques, l'équivalent de iris ou de diamonds).

Qu'en pensez-vous?

In GitLab by @ggenin on Mar 31, 2020, 14:11

Je vous proposais cela (dans un autre fil, je remets ici) : une table issue d'insee.fr mais allégée et améliorée (dept et région en plus), elle contient les communes en gée 2019 avec des populations communales, naissances et décès, nb de logts lors des divers RP et entre les RP. on peut rajouter d'autres choses, mais bof pour une typologie. Vous me dites ce que vous en pensez ?

tab_pop_geo2019.rds

En tant que format, je ne crois pas qu'il faille en refaire un fichier plat, mais l'intégrer en dataframe comme les mtcars et cie. Si elle est trop grosse, on peut enlever les naissance décès et nb_logts, qui ne me servent pas souvent.

In GitLab by @ggenin on Mar 31, 2020, 14:15

Je sais que certains sont friands des noms de communes, mais en tant que statisticien, ça ne nous sert à rien. Pour tester les fonctions character, on peut le faire sur une simple chaîne de caractères genre "R version 3.6 est bien mieux qui SAS !" par ex.

In GitLab by @oliviermeslin on Mar 31, 2020, 14:28

A vrai dire, je ne pensais pas à des noms de communes, mais plutôt à des adresses ou des noms d'entreprise. Un extrait de Sirene open data ferait l'affaire par exemple. J'ai des idées d'exemples (tirés d'un projet que je fais avec @mathias.andre).

On peut aussi utiliser ces données sur les noms de famille.

In GitLab by @oliviermeslin on Mar 31, 2020, 14:39

Cette table me semble très bien. Je ne sais pas si RDS est le format habituel des jeux de données inclus dans les packages (@linogaliana : une idée?).

Je suis d'accord qu'il ne faut pas la remettre en csv. Le mieux est de prendre un .csv ou un .txt vraiment disponible sur le site de l'Insee (comme ici), et idem pour le SAS et les shapefiles. Comme ça on colle aux situations rencontrées par les agents.

In GitLab by @pierre-lamarche on Mar 31, 2020, 14:47

Une idée en l'air, mais j'aurais bien imaginé un package ne comportant pas nécessairement les données de manière native, mais permettant à l'utilisateur de télécharger à la volée ce qui l'intéresse (données sur le site de l'Insee, shapefiles sur celui de l'IGN, etc.) à l'aide de fonctions ad hoc (du type telecharger(donnees = "RP", annee = "2016", table = "logement"). Il me semble que l'espace des possibles est assez grand ainsi.

In GitLab by @oliviermeslin on Mar 31, 2020, 14:58

Bonne idée, mais ce serait un peu un autre produit, non? Je veux dire:

le package proposé dans cette issue c'est purement pédagogique pour que les agents puissent reproduire facilement les exemples sur des données en français. Et ce package ne demanderait quasiment aucun travail de programmation;
le package dont tu parles serait très utile dans le travail quotidien, mais demanderait pas mal de programmation, et un recensement des sources. Ca pourrait venir dans un second temps, non?

In GitLab by @mathias.andre on Mar 31, 2020, 15:01

J'avais en tête la même idée que Pierre : ne pas mettre forcément toutes les bases en natif mais d'aller aussi les chercher sur le site insee.fr . Mais je n'ai fait de packages donc je ne sais pas si c'est difficile.

Sinon, une des bases intéressantes qu'on utilisait dans les formations avec Martin, c'est la bpe ou le rp. Exemples ici : https://teaching.slmc.fr/r/

In GitLab by @pierre-lamarche on Mar 31, 2020, 15:27

Nul besoin d'atteindre l'exhaustivité dès le départ, je vois plutôt une construction brique par brique du package. Pas sûr de voir bien le contour du package tel que tu le décris du coup @oliviermeslin : si on fait un package, c'est précisément pour rendre implicite du code, sinon autant faire un notebook avec des exemples d'utilisation. Par ailleurs, pour moi le package a pour vocation à être diffusé (en interne ou en externe, mais pour le coup j'aurais une préférence pour la seconde solution). Du coup, pourquoi un package si c'est pour présenter des cas d'usage à partir d'un table créée de manière ad hoc ?

In GitLab by @ggenin on Mar 31, 2020, 15:41

Une liste des plus grosses entreprises, peut-être. Je veux dire, un truc qui peut réellement servir pour les chargés d'études et qui aurait une réalité utilisable. Ensuite, comme chargé d'études, on ne fait pas souvent de traitements siouxes sur les libellés, et jamais sur des adresses. Ne risque-t-on pas de tomber dans des traitements de liasses Sirene plus que dans les statistiques ?

J'aurais pu sortir cela depuis Clap 2015, mais on n'a que très rarement la raison sociale ou un nom commercial, en plus d'être déjà un peu obsolète.

In GitLab by @pierre-lamarche on Mar 31, 2020, 15:47

Si l'idée est de faire un package similaire à carData, so be it mais du coup pas sûr de voir la plus value pour être franc par rapport à l'existant. Pour l'inclusion des données dans un package, cf. les guidelines de Wickham.

In GitLab by @ggenin on Mar 31, 2020, 15:53

En plus, je n'ai encore jamais trouvé de données sur insee.fr qui soit directement exploitable. C'est d'ailleurs ces données qui m'ont arraché le plus de cheveux, alors que les autres données sur data.gouv.fr étaient beaucoup plus faciles à exploiter (tables des élus par exemple : on a des dates, des noms-prénoms, des communes, des fonctions.... Mais faire des stats sur les prénoms des maires est un peu idiot).

In GitLab by @oliviermeslin on Mar 31, 2020, 16:01

@pierre-lamarche : oui, l'idée ce serait d'avoir un package avec uniquement quelques tables en français pour proposer des exemples faciles à assimiler; le package ne contiendrait pas de code ou presque, et servirait seulement d'emballage. Les data-economists qui ont traduit le bouquin de Wickham en espagnol ont fait pareil: ils ont créé un package avec les données en espagnol (ici).

Précision: je ne fais que reprendre l'idée de @ggenin (si je l'ai bien comprise), pour ma part je pense que c'est pas mal de boulot pour une valeur ajoutée pas forcément énorme. La vérité est que les agents qui passent à R doivent avoir une maîtrise minimale de l'anglais car on ne peut pas tout traduire.

In GitLab by @ggenin on Mar 31, 2020, 16:13

Nan, mais chais pas, on est l'institut de la stat, on devrait être capable de sortir des tables de données nous-mêmes, non ? En stock, j'ai des nomenclatures pour faire des merges ou des factors, des populations communales qui me servent souvent et tout cela non soumis au secret. J'ai aussi 2 tables Estel (niveau dept/reg ou ze) presque utilisables (il reste des redondances) et tout aussi libres de diffusion. Ce ne sont pas de grosses tables, mais suffisantes pour que ce soit pourri sous Calc.

tab_estel_a38_reg.rds

In GitLab by @RLesur on Mar 31, 2020, 20:08

Désolé de ramener ma :strawberry: une fois de plus :pray_tone1:.

J'aime bien l'idée de @pierre-lamarche : commencer par quelques tables issues d'insee.fr. Dans un premier temps, uniquement pour créer des jeux de données d'exercice. Mais en pensant "générique" pour 1 jeu de données, on peut se retrouver avec 100 dans la poche (le coût de développement marginal est parfois très faible).

Autre argument, qui est un avis personnel : je ne suis pas un grand fan (euphémisme) de la duplication de données (i.e. mêmes données sur le web et dans un package).
Dans mon idéal, c'est un peu comme pour le web sémantique : 1 jeu de données = 1 uri

Enfin, petit retour d'expérience de mon passé de chef de SED : je trouve que les producteurs/diffuseurs ne consomment pas assez les données qu'ils mettent à disposition des utilisateurs externes. Comme le dit @ggenin, c'est souvent indigeste. Mon rêve serait que l'Insee applique le dogfooding pour les données diffusées.

Je concède qu'il existe une limite à la proposition de @pierre-lamarche : comme les données diffusées subissent parfois des breaking changes (qui cassent bien les pieds des utilisateurs extérieurs soit dit en passant), cela imposerait de surveiller que les exercices reposant sur des données téléchargées sur insee.fr fonctionnent toujours (en paramétrant le CI pour faire tourner les exercices tous les mois ?).

In GitLab by @pierre-lamarche on Apr 1, 2020, 07:51

Oui je suis très sensible à cette idée qu'on doit exploiter les données qu'on produit et met à disposition ; c'est un cercle vertueux car on devient naturellement sensible aux défauts de diffusion (que ce soit sur les données elles-mêmes ou sur le mode de diffusion) et plus enclins à les corriger. In fine c'est la qualité de ce qu'on produit qui en bénéficie. J'appelle ça être un produser mais peu importe la terminologie. Je veux bien essayer d'initier quelque chose, sur les revenus par exemple - par exemple en reprenant et modifiant substantiellement un ancien projet, ambitieux et surtout extrêmement perfectible sur la visualisation des données de revenu.

In GitLab by @gillesfidani on Apr 1, 2020, 15:48

@pierre-lamarche , @mathias.andre : je suppose que nous avons tous pensé à cette solution un jour ou l'autre : un package pour récupérer rapidement des données à jour, les représenter graphiquement, etc. Il y a qque temps, j'avais commencé à lister les sources + url des données que j'utilise régulièrement. Mais l'arrivée d'Rmés, Mélodi et le dvpt du web semantique risque de changer la donne.

+1 @RLesur : un jeu de données == 1 uri !

In GitLab by @ggenin on Apr 4, 2020, 14:08

Voici ma table Estel refaite, avec tous les détails et surtout sans agrégations, issue du fichier XL (arghh beuhh) téléchargée d'insee.fr. En DR on n'a que insee.fr pour obtenir Estel.

tab_estel_dept_a38_sexe_salaries.rds

In GitLab by @ggenin on Apr 6, 2020, 08:59

Je crois avoir enfin compris ce que vous disiez à propos de données à télécharger depuis insee.fr

télécharger à la volée ce qui l'intéresse (données sur le site de l'Insee, shapefiles sur celui de l'IGN, etc.) à l'aide de fonctions ad hoc (du type telecharger(donnees = "RP", annee = "2016", table = "logement")

Le souci, c'est que l'Insee ne nous propose rien d'exploitable. Alors soit on attend, et on peut attendre longtemps, soit on fabrique nous-mêmes les données dont nous avons besoin. Ce que je vous ai proposé, ce sont deux tables que j'ai fabriquées, mais contenant des données réelles et concrètes, que j'aurais bien aimé trouver facilement directement dans un package, sans passer 15 jours à les triturer dans R depuis des Calc trouvés sur insee.fr. J'en ai d'autres à disposition : tables de nomenclatures, de zonages.

Sinon j'y pense il y a l'API Sirene, mais je ne sais pas comment on s'en sert, ni si cela peut nous être utile.

In GitLab by @pierre-lamarche on Apr 6, 2020, 09:34

Désolé, mais on peut télécharger plein de données très exploitables sur le site de l'Insee. Et mon idée, c'était de récupérer ces URL et de bâtir brique par brique.

In GitLab by @pierre-lamarche on Apr 6, 2020, 09:36

Et d'agissant des nomenclatures, quid de l'API Insee : https://api.insee.fr/metadonnees/nomenclatures/v1 ?

In GitLab by @gillesfidani on Apr 6, 2020, 09:37

je rajouterais ceci : https://www.insee.fr/fr/information/2862759

il y a des trucs exploitables à l'Insee, mais pas toujours très connus

In GitLab by @ggenin on Apr 6, 2020, 10:03

OK, des fichiers dbase zippés. Je tente d'en télécharger un, ça rame. Il fait 77 Mo zippé. Il faut alors dézipper...

In GitLab by @ggenin on Apr 6, 2020, 10:05

Arrivé. Fichier de 600 Mo. Autre chose : insee.fr n'est pas accessible depuis AUS.

In GitLab by @ggenin on Apr 6, 2020, 10:06

600 Mo, je ne tente même pas de l'ouvrir depuis R sur mon pc. Par contre, le transférer par copier-coller vers AUS........ ça va prendre du temps !

In GitLab by @gillesfidani on Apr 24, 2020, 09:16

marked this issue as related to #48

In GitLab by @acazaubiel on Apr 27, 2020, 15:12

Ensuite, comme chargé d'études, on ne fait pas souvent de traitements siouxes sur les libellés, et jamais sur des adresses. Ne risque-t-on pas de tomber dans des traitements de liasses Sirene plus que dans les statistiques ?

A vrai dire, moi je fais en permanence de la recherche textuelle dans Sirène (enfin plutôt Sirus), pour mes enquêtes... Mais c'est parce que j'ai besoin de faire de la siretisation (recherche d'un numéro SIRET) à partir d'informations partiellement bruitées (typiquement des réponses à une enquête). Donc pour faire simple, je recherche le vrai numéro SIRET d'un établissement qui me donne un numéro SIRET (ou pas), son nom, et son adresse... Mais ce qui est certain, c'est que c'est assez compliqué (text-mining + stat. spatiales) et assez spécifique comme requête. Ceci étant dit, si un jour quelqu'un fait un package qui fait ceci, tous les chercheurs du CASD qui exploite des données "externes" au SSP Lab, nous remercierons...

In GitLab by @linogaliana on May 20, 2020, 05:12

Je ferme l'issue puisqu'elle n'est plus à jour grâce à doremifasol

In GitLab by @linogaliana on May 20, 2020, 05:12

closed

InseeFrLab / utilitR

Création d'un package avec des jeux de données en français #29