Fiche import tableurs - [merged] #161

Closed linogaliana closed 3 years ago

In GitLab by @linogaliana on Jun 11, 2020, 07:58

_Merges fiche_importtableurs -> master

Proposition pour la fiche "Import de données issues de tableurs"

@CTassart : j'ouvre la MR pour pouvoir utiliser les fonctionnalités de commentaire et de suggestion si besoin. Elle sera mergée quand tu estimeras que la fiche est prête et qu'elle aura reçue les validations nécessaires

In GitLab by @linogaliana on Jun 11, 2020, 08:10

Commented on 03_Fiches_thematiques/Fiche_import_tableurs.Rmd line 19

Je te propose de garder les éléments que tu mentionnes pour une introduction dans la fiche et ne garder, dans la box recommandation, que la synthèse (sorte de reader digest)

::: {.recommandation data-latex=""}

*Fichiers xlsx*: Du fait de sa vitesse, il est recommandé d'utiliser la fonction `read_xlsx` du package `openxlsx` qui est 4 à 5 fois plus rapide que la fonction dédiée du package `readxl`

*Fichiers xls*: Il est recommandé d'utiliser la fonction `read_excel` du package `readxl` pour ce type de fichiers

*Fichiers odt*: Il est recommandé d'utiliser la fonction `read_ods` du package `readODS` 

Nous ne préconisons pas, ici, l'utilisation du package `xlsx`
:::

Il s'agit seulement d'une synthèse de ce que tu mentionnes, je te fais pleine confiance sur les préconisations

In GitLab by @CTassart on Jun 11, 2020, 09:00

Commented on 03_Fiches_thematiques/Fiche_import_tableurs.Rmd line 19

Je suis OK avec ta proposition. Toutefois, je remplacerai Il n'est pas recommandé d'utiliser le package xls par Nous ne préconisons pas, ici, l'utilisation du package xlsx

In GitLab by @CTassart on Jun 11, 2020, 09:02

Commented on 03_Fiches_thematiques/Fiche_import_tableurs.Rmd line 19

Je ne veux pas dire que xlsx n'est pas bien mais plutôt que, dans notre cas, on ne l'utilise pas

In GitLab by @linogaliana on Jun 11, 2020, 09:09

Commented on 03_Fiches_thematiques/Fiche_import_tableurs.Rmd line 19

Ok, j'ai édité le bloc pour tenir compte de ta remarque

In GitLab by @CTassart on Jun 11, 2020, 09:12

resolved all threads

In GitLab by @CTassart on Jun 11, 2020, 09:12

added 1 commit

45ef5327 - Apply 1 suggestion(s) to 1 file(s)

Compare with previous version

In GitLab by @oliviermeslin on Jun 19, 2020, 15:19

Commented on 03_Fiches_thematiques/Fiche_import_tableurs.Rmd line 19

changed this line in version 3 of the diff

In GitLab by @oliviermeslin on Jun 19, 2020, 15:19

added 3 commits

7b37d755 - Reformulation des recommandations
28d79594 - Ajouter la fiche Excel dans le bookdown
a2614456 - Mettre eval = FALSE dans tous les chunks, le temps qu'on construise des exemples reproductibles

Compare with previous version

In GitLab by @oliviermeslin on Jun 19, 2020, 15:28

added 1 commit

c2e64efe - [skip ci] Mise en forme des titres

Compare with previous version

In GitLab by @oliviermeslin on Jun 19, 2020, 15:35

added 1 commit

4d19b66a - [skip ci] Mise en italique de packages

Compare with previous version

In GitLab by @oliviermeslin on Jun 19, 2020, 15:43

added 1 commit

fb511308 - [skip ci] Mise en forme

Compare with previous version

In GitLab by @oliviermeslin on Jun 19, 2020, 16:14

@CTassart: J'ai fait une première relecture rapide, c'est déjà très bien et très complet! C'est super que tu aies fait attention à mettre les liens vers des tables d'exemple. J'ai repéré un certain nombre de pistes d'améliorations. Je peux soit faire des modifs moi-même, soit te laisser les faire, comme tu préfères.

J'enlèverais la partie sur la comparaison des packages car les autres fiches ne justifient pas les recommandations; en revanche, ces éléments seront extrêmement utiles pour le COPS (comité de certification des packages R) quand il étudiera la question de l'import des données Excel/ODS. Il faudrait d'ailleurs qu'on parle avec Benoît de comment tu pourrais contribuer au COPS.
Je mettrais la présentation de l'interface graphique Rstudio en premier (juste après les recommandations), car c'est le plus simple pour les grands débutants.
On peut enlever les parties sur l'installation des packages, car c'est un sujet qui touche toutes les fiches, dont il va y avoir une fiche spécifique sur l'installation de packages.
Je mettrais beaucoup moins d'exemples (un ou deux par fonction), dans la mesure où les tableaux que tu as faits présentent les options de façon très claire. C'est comme ça que la fiche sur les fichiers csv et txt est rédigée, tu peux y jeter un coup d'oeil pour voir ce que ça donne.
Je me demande si on pourrait pas trouver des jeux d'exemples tirés du site Insee (il y a des fichiers xls sur Insee.fr, je ne sais pas si on peut y trouver des ods et des xlsx).
il faudrait qu'on trouve une façon de stocker en ligne les fichiers d'exemples. J'ai eu l'idée suivante:
- on stocke les fichiers sur un site internet (à déterminer);
- on introduit une fonction url_fichier_xls() dans doremifasol qui imprime l'URL du fichier xls, et idem pour xlsx et ods.
- Les agents exécutent url_fichier_xls(), copient-collent le lien, et téléchargent le jeu d'exemple. Qu'en penses-tu @pierre-lamarche?

In GitLab by @oliviermeslin on Jun 19, 2020, 16:17

added 3 commits

03247fbe - Reformulation encadré Excel
6348f50e - Complément
b9032204 - Petites modifs de forme

Compare with previous version

In GitLab by @oliviermeslin on Jun 22, 2020, 06:34

added 14 commits

b9032204...c9a6050e - 13 commits from branch master
735da1a6 - solve conflict

Compare with previous version

In GitLab by @CTassart on Jun 22, 2020, 07:28

J'enlèverais la partie sur la comparaison des packages car les autres fiches ne justifient pas les recommandations;

Fait

In GitLab by @CTassart on Jun 22, 2020, 07:29

Je mettrais la présentation de l'interface graphique Rstudio en premier (juste après les recommandations), car c'est le plus simple pour les grands débutants.

Fait

In GitLab by @CTassart on Jun 22, 2020, 07:39

On peut enlever les parties sur l'installation des packages, car c'est un sujet qui touche toutes les fiches, dont il va y avoir une fiche spécifique sur l'installation de packages.

Fait

In GitLab by @CTassart on Jun 22, 2020, 07:44

Mettre eval = FALSE dans tous les chunks, le temps qu'on construise des exemples reproductibles

Suppression de eval=FALSE dans tous les chunks
Ajout de l'option suivante en début de pgm :

knitr::opts_chunk$set(echo = TRUE, eval=FALSE, include=TRUE, message=FALSE, warning=FALSE, fig.height = 6, fig.width = 8)

In GitLab by @CTassart on Jun 22, 2020, 09:07

Je me demande si on pourrait pas trouver des jeux d'exemples tirés du site Insee (il y a des fichiers xls sur Insee.fr, je ne sais pas si on peut y trouver des ods et des xlsx).

La difficulté est de trouver des jeux de données permettant de réaliser les différents tests :

pour chaque extension : xlsx, xls et ods,
avec plusieurs onglets,
et différents types de variables (character, numeric, date...)

Après 1 première recherche rapide ici, je n'ai pas trouvé.

In GitLab by @CTassart on Jun 22, 2020, 09:09

Je mettrais beaucoup moins d'exemples (un ou deux par fonction), dans la mesure où les tableaux que tu as faits présentent les options de façon très claire.

Mon idée était justement d'être exhaustif.

In GitLab by @CTassart on Jun 22, 2020, 09:11

il faudrait qu'on trouve une façon de stocker en ligne les fichiers d'exemples. J'ai eu l'idée suivante:

on stocke les fichiers sur un site internet (à déterminer);

on introduit une fonction url_fichier_xls() dans doremifasol qui imprime l'URL du fichier xls, et idem pour xlsx et ods.

Les agents exécutent url_fichier_xls(), copient-collent le lien, et téléchargent le jeu d'exemple. Qu'en penses-tu @pierre-lamarche?

Est-ce que minio de la PFI pourrait faire l'affaire ?

In GitLab by @CTassart on Jun 22, 2020, 09:14

@oliviermeslin je veux bien de ta contribution pour la gestion des jeux de données.

In GitLab by @oliviermeslin on Jun 22, 2020, 09:21

Je pense qu'on peut enlever pas mal d'exemples car les tableaux d'options que tu as proposés sont super, il suffit de donner un ou deux exemples d'utilisation des options.

Cette question renvoie au débat qu'on a eu au début du projet sur l'ambition d'UtilitR. On s'est dit collectivement qu'on préférait être concis plutôt qu'exhaustifs, car l'idée de cette doc n'est pas de traiter tous les cas d'usages (c'est impossible) mais d'apprendre aux agents à chercher la bonne solution par eux-mêmes. Ceci dit, on peut toujours ajuster en fonction de ce que les contributeurs considèrent comme des éléments importants qui doivent figurer dans les fiches.

In GitLab by @oliviermeslin on Jun 22, 2020, 09:22

C'est noté

In GitLab by @oliviermeslin on Jun 22, 2020, 09:22

assigned to @CTassart

In GitLab by @oliviermeslin on Jun 22, 2020, 09:22

assigned to @oliviermeslin

In GitLab by @oliviermeslin on Jun 22, 2020, 09:23

On peut faire ça, le problème c'est qu'on est binaires sur tous les chunks en même temps, alors qu'avec eval = FALSE dans chaque chunk ça permettait de les mettre en fonctionnement un par un. Mais je reconnais que ce n'était pas propre.

In GitLab by @CTassart on Jun 22, 2020, 09:41

OK ! Je n'avais pas cette info car je n'étais pas là au début du projet : je propose de recueillir l'avis de différents contributeurs sur ce qui est judicieux de garder et je supprimerai le superflu.

In GitLab by @oliviermeslin on Jun 22, 2020, 09:42

OK, tu peux lancer un appel aux bonnes volontés dans le salon docR.

In GitLab by @CTassart on Jun 22, 2020, 11:11

added 2 commits

6bd51434 - supp comparaison packages, qq modif de forme
fe768748 - modifs mineures

Compare with previous version

In GitLab by @CTassart on Jun 22, 2020, 17:28

added 1 commit

c44c240e - ajout jeu de données xlsx et ods

Compare with previous version

In GitLab by @clairelegroux on Jun 22, 2020, 18:18

Bonjour

tout d'abord pourquoi j'accorde une grosse importance à cette fiche

les interactions entre outils, formats de fichiers, sont des questions récurrentes que j'ai à gérer en terme d'assistance au quotidien. Je suis donc assez sensibilisée au sujet.
je compte sur cette fiche pour orienter les utilisateurs vers un plus gros usage de R, en lieu et place du tableur, une fois que la saisie est faite, ou les données récupérées, on doit pouvoir se passer d'un outil bureautique (dont le tableur). J'ai donc "besoin" qu'une fiche "rassurante" soit proposée sur cette étape indispensable pour passer d'un outil à l'autre.

J'ai quelques remarques générales et des coquilles/remarques par ligne (je mets ça un autre post..) Vu le 2e besoin que j'ai décrit, je verrais bien une première partie simplifiée (via l'interface, comme le propose @oliviermeslin avec peut être en plus un ou deux exemples sur les options les plus fréquemment utilisées (choix des colonnes/variables, feuilles...). Je n'ai pas assez regardé les autres fiches, mais ça vous choquerait, quelque chose du type "code à trou" pour franchir la 1ère marche ? Le reste étant vraiment important mais coté progression, j'essaierais d'abord d'importer un fichier, tout court (avec la feuille x et y p.ex) puis ensuite, je m'attache aux options plus détaillées (qui me semblent précieuses, et qu'il ne faut pas passer sous silence !)

Est-ce que l'encodage n'est qu'une problématique pour les fichiers plats (csv, txt) ? je suis prise d'un doute...

sinon l'ods vient tard...

In GitLab by @clairelegroux on Jun 22, 2020, 19:14

Ligne 16 => remplacer odt par ods (sauf si tu veux mettre odf, mais dans le cas de cette fiche, ça ne s'y prête pas)
Ligne 27 => travailler sur le Z, je ne recommanderais pas. Si l'on part du cadre d'usage d'AUS, je parlerais du U: (Espert) d'ailleurs @oliviermeslin @linogaliana lino a-t-on définit quel était le cadre d'usage de base à utiliser dans chaque fiche ? Cela devrait être générique dans toute la doc (poste => où ?, distant, AUS, où ?). S'il faut créer une issue, pas de souci, je vous la proposerais.
Ligne 47 => coquille lo =>le
Ligne 60 => doublon xlsx ??
Ligne 66 => ne serait-ce pas Empty et non Emprty ?
Ligne 68/69.... : soit fichier xls/xlsx, soit fichier tout court. Associer le format au logiciel potentiellement utilisé pour le créer reste piégeux et restrictif.
Ligne 99 => récupération par l'index intéressant. Dans Calc, intrinsèquement, le programme ne gère que l'index des feuilles (bref note pour plus tard... et le package d'Antoine
Ligne 153 => coquille variable
Ligne 58/224/372 => à la fois la description des options est nécessaire, à la fois ça alourdit. Est-ce une reformulation ou une reprise d'une doc existante mot pour mot vers laquelle on pourrait faire un lien ? Ou bien, les mettres en fin de fiches, commedes annexes (et j'imagine qu'une ancre vers la fin est possible)
Ligne 181 => réserves sur check.names / sep.names . Si tout cela est résolu en 4.1.5, c'est logique d'aborder le sujet au moment de la rédaction, mais je ne laisserais pas cette "digression" qui noit le lecteur. Au début de la fiche, tu écris que le cadre de la fiche, c'est la version 4.1.5 du package. Je me limiterais à une nouvelle alerte du style=> attention, pour une utilisation correcte des options [..], il est rappelé, que les versions antérieures à 4.1.5 ne doivent pas être utilisées.
Ligne 195 => là ça fait appel à une fonctionnalité tableur, si elle a été utilisée.. Pour faciliter la compréhension, j'aurais tendance à reprendre la terminologie existante. coté LibreOffice on parle de "plage nommée", coté Excel (de mémoire, je vérifierais) on parle de nom ou zone de nom. mais l'import d'une zone de nom => c'est extra ! je suis bluffée.
Ligne 202 => je ne décrirais pas la méthode qui est propre à chaque logiciel. Et dans Calc, personnellement, je me simplifie la vie, j'utilise la "zone de nom" (celle qui donne la référence ou d'une plage sélectionnée). En plus le chemin change tous les 4 matins (enfin à chaque version de libo). Et dans Excel ce ne serait pas fait par le même chemin. => je dirais plus tôt "nommer une plage" avec votre tableur => si les personnes ne savent pas utiliser leur tableur, c'est pas directement votre sujet. Mais ça chez Calc c'est documenté Insee. Je pourrais vous filer la fiche correspondante (que j'ai rédigée d'ailleurs...)
ligne 219 => il vaudrait mieux rappeler les recommandations, puisque pour un package tu le recommande pour xls, pour l'autre pour l'xlsx. S'il y en a un qui fait les 2, on ne sait plus trop pourquoi on préco 2 packages... (je me doute bien qu'il y a une raison)
ligne 249 => est-ce une coquille tibble ?

je passe plus vite... en réalité j'ai une autre remarque générale

ligne 349 pourquoi fichier "tabulé" ??? un ods, c'est pas plus, pas moins un fichier tableur que xls, xlsx... J'enlèverais l'adjectif, et me limiterais à l'extension, pour nous mettre tous d'accord.
ligne 358 : il faut vraiment changer ça et fournir un fichier spécifique, généré à partir d'un csv tout propre.
ligne 442 spécifier
ligne 460 estpace
ligne 492 parler
ligne 492/498 : c'est pas clair : tu veux dire que si ma zone (via un ctrl+* dans tableur) va de A1 à D7, la ligne 1 est considérée comme les nom de variables (en tête) et les données commence en ligne 2 ? C'est étrange de désigner une zone à partir de la ligne 2... pas d'utilisation de zone de nom avec readODS ? c'est du boulot pour @AntoineDreyer

=> je mettrais la partie ods en 1er (pas juste parce que c'est ods, mais aussi car elle est plus courte

In GitLab by @clairelegroux on Jun 22, 2020, 19:25

Ma dernière remarque générale se loge bien ici. Il y a effectivement besoin de plus de synthèse. Une fois lu la description du 1er package tu as moins envie de lire les autres. Mais l'idée reste de "piocher".. Je crois qu'on peut identifier des principes commun entre les 3 packages et des options communes (les plus intéressantes), juste leur syntaxe sera sensiblement différente, voire juste les mots clés.

Peut-être pourrais-tu partir d'un exemple générique, que tu déclines pour chaque extension sur ce qui change. Mais une seule explication pour tous les principes identiques. Dans tous les cas par exemple

il faut récupérer les en tête (sur ods, la ligne de référence est différente... mais me parait plus logique)
tu peux avoir besoin de désigner les feuilles
tu peux utiliser des zones de nom (mais ça pour moi c'est un extra, je doute que ce soit le truc le plus utilisé,je passerais plus par un renvoi)
il faut définir le format des colonnes/ variables (ce qui me parait autrement plus important que les zones de nom). Pour les formats de variables, même chose, je me limiterais aux formats le splus courant, et ferait un renvoi pour le reste.

Et enlever, comme le précisait @oliviermeslin tout ce qui sera précisé dans les autres fiches, y compris l'environnement de travail (mais ça il faudra peut être qu'on se mette d'accord, si ce n'est déjà fait !)

Déjà écrit, mais je partirais d'ods pour décliner l'ensemble des principes. Comme le paquet est peut-être moins complet, c'est plus simple...

In GitLab by @pierre-lamarche on Jun 23, 2020, 08:19

Je vais réagir sur deux points :

le premier, c'est ta proposition pour doremifasol, @CTassart Je trouve l'idée de décomposer la fonction telechargerDonnees très séduisante, et je pense effectivement qu'un peu de modularité ne ferait pas de mal. En revanche, l'idée de doremifasol c'est de recenser les données mises à disposition sur le site de l'Insee ainsi que leur URL, mais pas de dupliquer l'information de manière à créer une sorte de simili-API (si je comprends bien ton idée évidemment). J'entends bien le besoin de créer un exemple à partir d'un document ods, mais je ne vois pas trop l'intérêt de l'intégrer dans le package vu que ce n'est pas un format de diffusion externe pour l'Insee. En gros, si je devais tracer une ligne rouge pour moi, ce serait qu'il ne faut jamais dupliquer la donnée déjà diffusée. Mais ce n'est que mon avis.
le second, ce sont tes propositions de correction @clairelegroux Il est important que tous, collectivement, on joue le jeu de respecter les règles de contribution, parce que nécessairement l'absence d'effort pour un contributeur engendre un surcoût d'effort pour le reste de la communauté. Ainsi, si on veut intégrer tes remarques, il faut que quelqu'un reprenne extensivement tes différents points et les intègre dans un commit sur la branche créée par @CTassart ce qui tu l'auras bien compris est pénible. Il serait mieux que tu envoies tes suggestions directement via Git (mais cela implique d'utiliser Git, condition sine qua non de contribution au projet). Nous sommes tous à ta disposition pour t'accompagner si tu as des questions, mais il est vraiment important de collectivement respecter les règles de contribution.

In GitLab by @CTassart on Jun 23, 2020, 09:38

le premier, c'est ta proposition pour doremifasol, @CTassart Je trouve l'idée de décomposer la fonction telechargerDonnees très séduisante, et je pense effectivement qu'un peu de modularité ne ferait pas de mal. En revanche, l'idée de doremifasol c'est de recenser les données mises à disposition sur le site de l'Insee ainsi que leur URL, mais pas de dupliquer l'information de manière à créer une sorte de simili-API (si je comprends bien ton idée évidemment). J'entends bien le besoin de créer un exemple à partir d'un document ods, mais je ne vois pas trop l'intérêt de l'intégrer dans le package vu que ce n'est pas un format de diffusion externe pour l'Insee. En gros, si je devais tracer une ligne rouge pour moi, ce serait qu'il ne faut jamais dupliquer la donnée déjà diffusée. Mais ce n'est que mon avis.

En fait, je ne connais pas doremifasol : c'est @oliviermeslin qui m'en a parlé et à fait cette suggestion : voilà, j'ai rendu à César ce qui lui appartient !. Néanmoins, on se pose la question du "stockage" des données dans le cadre de ces fiches concernant l'import de données xlsx, ods mais aussi sas...

In GitLab by @CTassart on Jun 23, 2020, 09:42

le second, ce sont tes propositions de correction @clairelegroux Il est important que tous, collectivement, on joue le jeu de respecter les règles de contribution, parce que nécessairement l'absence d'effort pour un contributeur engendre un surcoût d'effort pour le reste de la communauté. Ainsi, si on veut intégrer tes remarques, il faut que quelqu'un reprenne extensivement tes différents points et les intègre dans un commit sur la branche créée par @CTassart ce qui tu l'auras bien compris est pénible. Il serait mieux que tu envoies tes suggestions directement via Git (mais cela implique d'utiliser Git, condition sine qua non de contribution au projet). Nous sommes tous à ta disposition pour t'accompagner si tu as des questions, mais il est vraiment important de collectivement respecter les règles de contribution.

Merci @pierre-lamarche de rappeler les règles de bonnes pratiques car je ne les connaissais pas forcément non plus :wink: Toutefois, j'ai modifié le document en prenant les remarques de Claire qui, à mon sens, ne devrait pas faire débat (orthographe...). Pour les autres, il faut que je les commit, c'est ça ?

In GitLab by @CTassart on Jun 23, 2020, 09:48

Merci pour ton travail @clairelegroux

Je ne ferai pas de commentaires particuliers sur la plupart de tes remarques (de forme souvent) que j'ai souvent pris en compte.

Je reprends ci-dessous celles qui, à mon sens, peuvent faire débat afin de recueillir l'avis des collègues.

In GitLab by @CTassart on Jun 23, 2020, 09:50

Ligne 58/224/372 => à la fois la description des options est nécessaire, à la fois ça alourdit. Est-ce une reformulation ou une reprise d'une doc existante mot pour mot vers laquelle on pourrait faire un lien ? Ou bien, les mettres en fin de fiches, commedes annexes (et j'imagine qu'une ancre vers la fin est possible)

Je suis pour laisser inchangé

Il ne me semble pas gênant de conserver un tableau de paramètres spécifiques au package décrit. Les paramètres ne sont pas forcément les mêmes. De plus, je pense qu'un utilisateur pourrait s'attarder sur la partie qui l'intéresse (ods, par exemple) sans s'intéresser aux autres.

In GitLab by @CTassart on Jun 23, 2020, 11:35

Ligne 181 => réserves sur check.names / sep.names . Si tout cela est résolu en 4.1.5, c'est logique d'aborder le sujet au moment de la rédaction, mais je ne laisserais pas cette "digression" qui noit le lecteur. Au début de la fiche, tu écris que le cadre de la fiche, c'est la version 4.1.5 du package. Je me limiterais à une nouvelle alerte du style=> *attention, pour une utilisation correcte des options [..], il est rappelé, que les versions antérieures à 4.1.5 ne doivent pas être utilisées. *

Je suis d'accord

J'ai supprimé l'avertissement pour être plus explicite sur l'utilisation de ce paramètre.

In GitLab by @CTassart on Jun 23, 2020, 11:37

Ligne 202 => je ne décrirais pas la méthode qui est propre à chaque logiciel. Et dans Calc, personnellement, je me simplifie la vie, j'utilise la "zone de nom" (celle qui donne la référence ou d'une plage sélectionnée). En plus le chemin change tous les 4 matins (enfin à chaque version de libo). Et dans Excel ce ne serait pas fait par le même chemin. => je dirais plus tôt "nommer une plage" avec votre tableur => si les personnes ne savent pas utiliser leur tableur, c'est pas directement votre sujet. Mais ça chez Calc c'est documenté Insee. Je pourrais vous filer la fiche correspondante (que j'ai rédigée d'ailleurs...)

Je suis d'accord. Proposition :

Dans le cadre de cet exercice, vous pouvez créer une région (nommer une plage : test_namedRegion) avec votre tableur.

(mesDonnees <- openxlsx::read.xlsx(xlsxFile = chemin_xlsx, namedRegion="test_namedRegion"))

In GitLab by @CTassart on Jun 23, 2020, 11:40

ligne 219 => il vaudrait mieux rappeler les recommandations, puisque pour un package tu le recommande pour xls, pour l'autre pour l'xlsx. S'il y en a un qui fait les 2, on ne sait plus trop pourquoi on préco 2 packages... (je me doute bien qu'il y a une raison)

Je suis d'accord. Proposition :

Pour lire un fichier au format xls (ce que ne fait pas le package openxlsx), éventuellement un fichier au format xlsx de quelques Mo seulement, nous préconisons d'utiliser la fonction read_excel() du package readxl.

In GitLab by @CTassart on Jun 23, 2020, 11:40

ligne 249 => est-ce une coquille tibble ?

Ce n'est pas une coquille

In GitLab by @CTassart on Jun 23, 2020, 12:24

ligne 492/498 : c'est pas clair : tu veux dire que si ma zone (via un ctrl+* dans tableur) va de A1 à D7, la ligne 1 est considérée comme les nom de variables (en tête) et les données commence en ligne 2 ? C'est étrange de désigner une zone à partir de la ligne 2... pas d'utilisation de zone de nom avec readODS ?

effectivement, ce n'est pas explicite et ça induit même en erreur.

Je reprends cette partie.

In GitLab by @CTassart on Jun 23, 2020, 14:13

Ligne 27 => travailler sur le Z, je ne recommanderais pas. Si l'on part du cadre d'usage d'AUS, je parlerais du U: (Espert) d'ailleurs @oliviermeslin @linogaliana lino a-t-on définit quel était le cadre d'usage de base à utiliser dans chaque fiche ? Cela devrait être générique dans toute la doc (poste => où ?, distant, AUS, où ?). S'il faut créer une issue, pas de souci, je vous la proposerais.

Je ne recommanderai pas non plus de travailler sur le Z : c'est temporaire le temps que soit défini le cadre d'usage.

In GitLab by @CTassart on Jun 23, 2020, 14:15

je mettrais la partie ods en 1er (pas juste parce que c'est ods, mais aussi car elle est plus courte

Je suis d'accord

In GitLab by @CTassart on Jun 23, 2020, 14:16

je verrais bien une première partie simplifiée (via l'interface, comme le propose @oliviermeslin avec peut être en plus un ou deux exemples sur les options les plus fréquemment utilisées (choix des colonnes/variables, feuilles...).

Je suis d'accord. Je développe cette partie

In GitLab by @CTassart on Jun 23, 2020, 14:20

added 2 commits

1625769e - prise en compte des remarques de Claire
0ef5db3e - Passage de la partie ODS en 1er

Compare with previous version

In GitLab by @oliviermeslin on Jun 23, 2020, 17:29

La question de l'espace de travail est effectivement importante. Ceci dit, elle n'est pas importante partout. Dans le cas présent, il ne me semble pas fondamental de savoir si on importe un fichier Excel depuis Z: ou depuis ailleurs.

Par ailleurs, je pense qu'il ne faut pas que Z: figure dans les exemples:

soit on travaille en local (donc sur D: le plus souvent);
soit on travaille sur AUS ou sur la PF innovation, et donc dans un coffre, dans U:, mais pas sur Z:.

In GitLab by @oliviermeslin on Jun 23, 2020, 17:31

J'approuve les deux idées de @pierre-lamarche. En particulier, j'insiste aussi sur le nécessaire respect des règles de contribution.

InseeFrLab / utilitR

Fiche import tableurs - [merged] #161