[Fiches thématiques] Fiche sur la cartographie #2

Closed linogaliana closed 3 years ago

In GitLab by @linogaliana on Mar 9, 2020, 08:41

Bonjour Gilles, Arlindo et Lino (respectivement @mpf0ao , @s3qcea et @w3crk9 ),

J'ouvre cette issue pour vous mettre en relation, car vous travaillez tous les trois avec les outils cartographiques de R, et il me semblait que c'était une bonne idée que vous rédigiez ensemble la fiche cartographie de la documentation R. Il n'y a évidemment aucune obligation de contribuer.

J'ai préparé un petit canevas pour la fiche dans le fichier 04-fiche_thematiques.Rmd (que vous pouvez modifier). Je vous conseille de créer une branche pour rédiger la fiche, puis de faire une merge request vers la branche master.

Voici les quelques idées que j'ai eues (que vous pouvez tout à fait écarter):

rédiger vos recommandations, en termes d'approche et de packages (pas plus de 6/7 lignes);
présenter rapidement les formats de données SP/SF (ou autre);
dire où on peut trouver les shapefiles Insee (pour ma part, je pense qu'il faut privilégier les accès via un SGBD si ça existe);
montrer comment faire 2/3 cartes simples et standards;
montrer comment exporter dans un format commode;
donner quelques conseils/bonnes pratiques;
renvoyer à des ressources pertinentes (@w3crk9 , je crois que le MTES a fait un module de formation carto, non?).

Merci!

In GitLab by @linogaliana on Mar 16, 2020, 09:59

@mpf0ao je ne parviens pas à compiler le bookdown car je rencontre au moins 2 erreurs:

L'origine de la base europe_LAEA: il s'agit d'une base de données issue d'un package ? Si oui, lequel ?

```{r, eval=TRUE}
espagne_italie <- europe_LAEA[europe_LAEA$iso_a3 %in% c("ITA", "ESP"), ]
plot(st_geometry(espagne_italie), graticule=T, axes=T)

La base de données World:

```{r, eval=TRUE}
data("World")
europe <- World[World$continent == "Europe", ]
st_crs(europe)

plot(st_geometry(europe),
         main=st_crs(europe)[[2]],
         cex.main = 0.8,
         axes=TRUE,
         graticule=TRUE)

europe_LAEA <- st_transform(europe, 3035)

plot(st_geometry(europe_LAEA),
         main=st_crs(europe_LAEA)[[2]],
         cex.main = 0.8,
         axes=TRUE,
         graticule=TRUE)

Mon R ne trouve pas: data("World") appartient à quel package ? :world_map:

By Lino Galiana on 2020-03-16T09:59:28 (imported from GitLab project)

In GitLab by @linogaliana on Mar 16, 2020, 09:52

Merci beaucoup @mpf0ao pour ta première contribution, j'ai appris des choses ! :thumbsup:

Je propose en c9e4e1cf un découpage de la fiche en deux, pour alléger le contenu :

Maniement de données spatiales
Représentation cartographiques

C'est, pour le moment, uniquement de la restructuration. Qu'en pensez-vous ?

By Lino Galiana on 2020-03-16T09:57:40 (imported from GitLab project)

In GitLab by @linogaliana on Mar 16, 2020, 09:29

mentioned in commit c9e4e1cf7c48e739cfbe339c04a5c25ad7c43d0c

By Lino Galiana on 2020-03-16T09:29:01 (imported from GitLab project)

In GitLab by @linogaliana on Mar 16, 2020, 08:12

mentioned in merge request !5

By Lino Galiana on 2020-03-16T08:12:21 (imported from GitLab project)

In GitLab by @linogaliana on Mar 16, 2020, 07:18

@w3crk9 @s3qcea , je viens de pousser une première version de la fiche carto. Je pense qu'il reste encore pas mal de taf. 2 questions :

avez vous une idée du package recommandé pour les cartes d'étude ? cartography ? tmap ? les deux ? un autre ?
comment dissocier (ou pas) le thème analyse stat spatiale, qui a des liens avec la carto ?

By Gilles Fidani on 2020-03-16T07:18:58 (imported from GitLab project)

In GitLab by @linogaliana on Mar 12, 2020, 08:56

@mpf0ao , j'ai réorganisé le dépôt. Tu peux faire pull avec Rstudio (ou faire un git pull origin master en raison de ton amour de la ligne de commande!). Le modèle de fiche s'appelle Modele_de_fiche.Rmd et se trouve dans le dossier 03_Fiches_thematiques. Ce modèle est évidemment indicatif.

Tu peux aussi regarder la fiche Import de fichiers plats dans la formation déployée en html pour voir comment ça rend.

By Olivier Meslin on 2020-03-12T08:56:54 (imported from GitLab project)

In GitLab by @linogaliana on Mar 12, 2020, 07:56

@mpf0ao , tu as raison, j'ai pas encore fait le modèle. Je te dis quand c'est fait.

By Olivier Meslin on 2020-03-12T07:56:14 (imported from GitLab project)

In GitLab by @linogaliana on Mar 12, 2020, 07:24

pas de problème, j'attends le ménage. J'en profite pour m'entrainer à commiter/pusher sur mon dépôt
j'ai effectivement cherché le doc template 4-fiche_thematique.Rmd auquel tu fais référence dans la 1ère partie de cette issue. Je ne l'ai pas trouvé, et ne saurais dire si c'est parce que je débute, ou si le fichier n'existe pas sur le dépot.

PS : n'hésitez pas à me corriger si je mélange les concepts git et/ou si j'emploie des termes indûment

By Gilles Fidani on 2020-03-12T07:24:35 (imported from GitLab project)

In GitLab by @linogaliana on Mar 12, 2020, 06:18

Pour la bonne info de tout le monde, @mpf0ao a déjà des éléments sur la cartographie en R, il va les pousser cette semaine sur le dépôt. @mpf0ao , deux questions:

Peux-tu attendre que j'ai fait un peu de ménage dans le dépôt?
Veux-tu que je te fournisse un template de fiche, dans lequel tu pourrais ajouter tes éléments?

By Olivier Meslin on 2020-03-12T06:18:29 (imported from GitLab project)

In GitLab by @linogaliana on Mar 9, 2020, 08:42

assigned to @w3crk9 and unassigned @s3qcea

By Olivier Meslin on 2020-03-09T08:42:07 (imported from GitLab project)

In GitLab by @linogaliana on Mar 9, 2020, 08:41

assigned to @s3qcea and unassigned @w3crk9

By Olivier Meslin on 2020-03-09T08:41:55 (imported from GitLab project)

In GitLab by @CLG1978 on Mar 16, 2020, 17:05

Bonjour à tous,

Je me permets de m'incruster dans les échanges, j'ai pas mal utilisé le package leaflet, qui permet de travailler avec les fonds de carte d'Openstreetmap. Il est possible de réaliser des cartes chlorophlètes, ou des cartes avec des ronds proportionnels. La principale contrainte de ce package est d'avoir un accès internet pour afficher , les fonds de cartes, ou de stocker sur un espace dédié les images des fonds de cartes. Le principale avantage réside dans le fait de pouvoir des cartes interactives.

https://rstudio.github.io/leaflet/

Je peux faire une traduction de la documentation.

Christophe

In GitLab by @linogaliana on Mar 16, 2020, 17:10

C'est une très bonne suggestion. J'aime beaucoup leaflet c'est très bien fait. On peut faire une fiche dessus, puisque tu le proposes :smile:

In GitLab by @linogaliana on Mar 16, 2020, 17:31

Ou une section de la documentation cartographique spécifique à la carto html

In GitLab by @linogaliana on Mar 17, 2020, 08:48

mentioned in merge request !5

In GitLab by @linogaliana on Mar 17, 2020, 09:00

changed title from Fiche sur la cartographie to {+[Fiches thématiques] +}Fiche sur la cartographie

In GitLab by @gillesfidani on Mar 17, 2020, 17:34

mentioned in merge request !2

In GitLab by @oliviermeslin on Mar 18, 2020, 07:39

@gillesfidani , je rencontre les mêmes problèmes que @linogaliana, sur world et sur europe_LAEA. Je crois comprendre que World est la table world (en minuscules) du package poliscidata. Est-ce cela? Si oui, il faut aller le package avec library(poliscidata).

In GitLab by @linogaliana on Mar 18, 2020, 09:03

J'ai trouvé ! :nerd:

C'est dans le package tmap, cf. ici

In GitLab by @gillesfidani on Mar 18, 2020, 09:16

bien vue @linogaliana !

concernant l'erreur sur europe_LAEA, je pensais vraiment que mon commit de ce matin règlerai le problème. Mais si la base World est dans tmap, un `library("tmap") avant l'appel à l'objet World devrait traiter l'erreur. Je modifie

In GitLab by @gillesfidani on Mar 18, 2020, 09:22

ah ben non, grillé par la fraîcheur (f618cce2)

In GitLab by @linogaliana on Mar 18, 2020, 09:22

Il est très important de ne faire appel à library(.) qu'en cas de force majeure pour réduire le nombre de dépendances (et donc de conflits potentiels) utilisé par le bookdown

In GitLab by @linogaliana on Mar 18, 2020, 09:24

PS: le job échoue car il utilise une version non à jour du pipeline d'intégration continue qui avait un problème

In GitLab by @linogaliana on Mar 18, 2020, 09:27

C'est réglé par d49b0c4d759388cd02dc6e4378f2773e33b455bf. Le pipeline arrive à terme

In GitLab by @gillesfidani on Mar 18, 2020, 09:31

obligé de faire un git checkout -- Fiche_carto.Rmd pour annuler mes modif et me resynchro avec la branche du dépot distant

In GitLab by @ggenin on Mar 20, 2020, 19:17

Bonsoir, je n'ai pas bien suivi la fin de la discussion. Pas grave.

Ma réflexion : il y a des usages différents :

faire une carte simple rapidement (par ex une choroplèthe par région, dept, ze) cumuler choroplèthe et ronds, ronds avec couleurs... ajouter des fonds (régions, mers...)
idem avec une infobulle contenant des infos locales
une carte publiable avec légende, palette Insee... (pourquoi pas faisable avec une carte simplissime)
d'autres cartes plus compliquées (je n'en fais pas pour l'instant)

In GitLab by @linogaliana on Mar 21, 2020, 09:57

5f63c9e33c3ee24343e0edfe07189bbe5a82fe3e propose une série de modification sur la partie traitement de données spatiales.

@gillesfidani je n'ai pas modifié la partie sur les jointures. Tu proposes base::match. Habituellement, sur les données sf j'utilise les fonctions de dplyr (left_join, etc.). J'ai aucun problème à utiliser la fonction match. Pourquoi tu préfères cette grammaire dans l'analyse spatiale ?

In GitLab by @linogaliana on Mar 21, 2020, 10:02

@ggenin Les deux premiers sont tout à fait montrables dans la documentation.

Pour les troisièmes et quatrième points, le problème est que, sauf erreur de ma part, on n'a pas de template Insee pour les cartes construites via R. De la même manière qu'on n'a pas de template ggplot pour les graphiques... Ce sont deux outils qui seraient extrêmement utiles... mais qui dépassent le cadre de cette doc collaborative. La Drees a développé des templates en interne pour faire de la cartographie plus ou moins complexe. L'Insee n'a pour le moment pas suivi cette voie.

In GitLab by @gillesfidani on Mar 21, 2020, 10:17

@linogaliana , en règle générale, et si possible, je préfère me passer de packages tiers (hors base R).

Notamment pour dplyr, j'ai le douloureux souvenir d'un agent qui m'a signalé, un mois après la formation "prise en main rapide de données sour R", que les fonctions présentées étaient désormais deprecated ... :cry:

Depuis, c'est devenu une habitude (tinyverse addict).

Je ne suis pas farouchement opposé à ce que la documentation R propose la version dplyr pour joindre les données attrib et géo. Mais si vous faites ce choix, je quitte le groupe :laughing:

In GitLab by @gillesfidani on Mar 21, 2020, 10:29

sauf erreur de ma part, on n'a pas de template Insee pour les cartes construites via R. De la même manière qu'on n'a pas de template ggplot pour les graphiques... Ce sont deux outils qui seraient extrêmement utiles... mais qui dépassent le cadre de cette doc collaborative.

@linogaliana , qu'entends-tu par template pour les cartes ? 2 jours avant le confinement, j'ai soumis une idée peut-être similaire à un collègue de la dr13, qui semblait enthousiaste. Je lui ai dit que l'idéal serait de monter un projet collabo sur la PF inno. L'objectif serait de mettre en place des outils pour actualiser périodiquement et simplement des publications régionales très orientées carto (atlas régional par ex.)

Du coup, le projet est mis en stand-by

In GitLab by @linogaliana on Mar 21, 2020, 10:43

Je ne suis pas farouchement opposé à ce que la documentation R propose la version dplyr pour joindre les données attrib et géo. Mais si vous faites ce choix, je quitte le groupe :laughing:

Tu sais comment négocier !

@linogaliana , en règle générale, et si possible, je préfère me passer de packages tiers (hors base R).

J'ai la même philosophie.

Je pose cette question car sf est vraiment intégré à dplyr, c'est une surcouche au tibble. Donc je ne suis pas choqué de voir des dplyr::*_join plutôt que merge sur de tels objets. De toute manière, pour modifier un objet sf, on applique déjà plein de fonctions de dplyr. Vivement qu'il existe un équivalent à sf basé sur data.table :nerd:

Je te propose dans cette section là d'adopter la syntaxe merge, je suis vraiment indifférent. Il faut en fait la découper en deux sections:

merge à partir des attributs
merge à partir de la géométrie (st_join, etc.)

Cette fiche sera alors à peu près complète. Il faudrait pointer vers du contenu externe plus complet aussi. Donc elle est pas complète :crying_cat_face:

In GitLab by @oliviermeslin on Mar 21, 2020, 13:12

@gillesfidani , @linogaliana, je connais très mal la cartographie en R, mais je me permets deux remarques:

proposer la syntaxe dplyr pour la carto est plus cohérent avec ce qui est recommandé pour la manipulation de données, et ça permet de minimiser le nombre de fonctions à utiliser pour les utilisateurs débutants (ce qui n'empêche pas les utilisateurs avancés de faire différemment);
ce n'est pas forcément à nous trois de trancher ce point, mais peut-être l'objet d'une discussion collective (avec le COPS? en réunion avec Benoît?) pour aboutir à une recommandation qui fasse consensus pour l'institut. On pourrait d'ailleurs faire la liste des points qui resteront à trancher.

Qu'en pensez-vous?

In GitLab by @gillesfidani on Mar 21, 2020, 15:49

@linogaliana : j'utilise base::match et non base::merge pour éviter de "polluer" mon objet spatial avec des variables que je ne souhaite pas intégrer.

un petit exemple :

os : objet spatial
df : data frame avec variable à représenter (ici pop)

os$ma_pop <- df[match(os$var_jointure, df$var_jointure), "pop"]

je ne suis pas sûr que ce soit la bonne méthode, et il est peut-être possible de sélectionner les variables à intégrer dans os avec merge, mais je ne sais pas faire.

@oliviermeslin : proposer systématiquement dplyr pour des raisons de simplicité, je n'y suis pas favorable. Je reconnais toutefois que c'est mon côté "intégriste", et c'est certainement contre-productif pour sensibiliser des débutants et les attirer vers ~~le côté obscur~~ R. Donc no souci, si vous pensez que c'est le mieux, partons dans cette direction.

In GitLab by @linogaliana on Mar 22, 2020, 09:20

@linogaliana , qu'entends-tu par template pour les cartes ? 2 jours avant le confinement, j'ai soumis une idée peut-être similaire à un collègue de la dr13, qui semblait enthousiaste. Je lui ai dit que l'idéal serait de monter un projet collabo sur la PF inno. L'objectif serait de mettre en place des outils pour actualiser périodiquement et simplement des publications régionales très orientées carto (atlas régional par ex.)

C'est une excellente initiative ! Sinon, passer par gitlab public en attendant !

En fait, je vois deux voies possibles :bulb:

Package avec des fonctions graphiques
Thèmes Insee, à la manière des thèmes ggplot (ex: theme_bw)

Je détaille un peu

:bulb: 1: Package avec des fonctions graphiques :bulb:

Il s'agit de la méthode la plus simple pour débutants. C'est la voie prise par la Drees. Ce n'est pas encore dans leur canal de publication officiel.

Le package dispose de données d'exemple qui sont des shapefiles. Disons que je désire faire une carte au niveau communal et que je dispose d'un dataframe avec des codes géographiques (codes communes). Le package propose une fonction qui fait l'appariemment avec le shapefile, utilise cartography (par exemple) pour faire la carte en tenant compte de certains paramètres donnés en argument de la fonction (titre, légende, etc.)

Bref, ça donne quelque chose comme ça

do_map <- function(df, niveau = "communal", code_geo_var = "code_insee", ...){
 if (level == "communal") shp <- data(shapefile_communes)
  df <- shp %>% dplyr::right_join(df, by = code_geo_var)

# Fait une carte avec plein d'option

return(map)
}

La Drees a fait ça pour faciliter le travail de customisation de certaines cartes, notamment quand on veut afficher les DROM à côté de la France métropolitaine

Voilà une première :bulb: jetée en l'air mais il y a probablement moyen de faire des trucs sympas

:bulb: 2: Un thème :bulb:

C'est pour les utilisateurs plus avancés. Ce n'est pas antithétique à la première méthode: un package peut comporter des fonctions de formattage pour les utilisateurs avancés et des fonctions plus clés en main pour d'autres. L'idée est qu'on laisse faire la construction de la carte aux utilisateurs et qu'on applique uniquement une feuille de style (taille légende, couleurs, etc.) avec un thème.

Je ne sais pas comment cela peut être fait en cartography. Mais pour les packages qui fonctionnent comme ggplot on a cette philosophie : ggplot() + geom_*() + theme_*.

In GitLab by @linogaliana on Mar 22, 2020, 09:29

proposer la syntaxe dplyr pour la carto est plus cohérent avec ce qui est recommandé pour la manipulation de données, et ça permet de minimiser le nombre de fonctions à utiliser pour les utilisateurs débutants (ce qui n'empêche pas les utilisateurs avancés de faire différemment);

En temps normal, je suis plutôt pour minimiser le nombre de packages utilisés et donc j'adopte la même philosophie que @gillesfidani . Mais là, on peut quasiment considérer qu'un objet ̀sf est un tibble donc qu'il s'intègre naturellement dans le cadre dplyr. C'est pour ça que je suis pas opposé sur le principe aux fonctions dplyr::_*join. Mais, comme dis plus haut, je m'en fiche un peu donc je vais pas me battre pour les imposer

ce n'est pas forcément à nous trois de trancher ce point, mais peut-être l'objet d'une discussion collective (avec le COPS? en réunion avec Benoît?) pour aboutir à une recommandation qui fasse consensus pour l'institut. On pourrait d'ailleurs faire la liste des points qui resteront à trancher.

Pas convaincu. On est sur un point mineur de chez mineur. On risque d'en rencontrer plusieurs par fiches. Si on veut être pragmatique pour avancer (conseil de @RLesur ici auquel j'adhère), on va difficilement pouvoir attendre les décisions du COPS, dont on ignore les prochaines dates de réunion et OJ. Le COPS sera à mobiliser sur des points plus structurants, à mon avis

In GitLab by @oliviermeslin on Mar 22, 2020, 10:02

@linogaliana , @gillesfidani , je trouve que ce que vous proposez est une excellente idée. Quelques remarques rapides:

un package de cartographie plus ou moins automatisé me semble une très bonne idée, hyper utile/productif pour l'Institut; ceci dit, il me semble compliqué sur le plan institutionnel de lancer les travaux sans la participation du DAR. Je pense qu'il suffirait que 1/ les chefs du DAR soient au courant, et 2/ qu'il y ait un contributeur du DAR;
sur le theme: pourquoi ne pas commencer par un thème ggplot pour l'Insee? Peut-être qu'Antoine Dreyer a déjà commencé, je ne suis pas au clair;
@linogaliana : j'aperçois un shp %>% dplyr::right_join(df, by = code_geo_var): tiens tiens, on utilise la syntaxe dplyr maintenant? :stuck_out_tongue_winking_eye:

In GitLab by @oliviermeslin on Mar 22, 2020, 10:06

Bon, je me propose de battre en retraite. Ma position de repli: on finit une première version de la fiche avec ce qui vous semble pertinent, et on en discutera plus tard en réunion, ou on en discutera pas du tout :grimacing:

In GitLab by @linogaliana on Mar 22, 2020, 10:18

un package de cartographie plus ou moins automatisé me semble une très bonne idée, hyper utile/productif pour l'Institut; ceci dit, il me semble compliqué sur le plan institutionnel de lancer les travaux sans la participation du DAR. Je pense qu'il suffirait que 1/ les chefs du DAR soient au courant, et 2/ qu'il y ait un contributeur du DAR;

En fait, il faudrait aussi associer le DOE si on veut rentrer dans les clous institutionnels. Et oui, ça me semble utile que des gens du DDAR participent

sur le theme: pourquoi ne pas commencer par un thème ggplot pour l'Insee? Peut-être qu'Antoine Dreyer a déjà commencé, je ne suis pas au clair;

Oui ce serait un bon début. C'est un peu l'idée que j'avais en tête.

shp %>% dplyr::right_join(df, by = code_geo_var

Je pars du principe que c'est un objet sf c'est pour ça. Je suis pleinement cohérent !

In GitLab by @oliviermeslin on Mar 22, 2020, 10:31

Je pars du principe que c'est un objet sf c'est pour ça. Je suis pleinement cohérent !

@linogaliana , désolé j'ai confondu ton opinion avec celle de @gillesfidani :sweat_smile:

In GitLab by @gillesfidani on Mar 22, 2020, 11:22

Je me suis surement mal exprimé, donc je retente :

comme @linogaliana , je suis, de façon générale, plutôt favorable à utiliser le moins de package possible. L'approche dplyr ne m'est pas insupportable, ce qui me gêne franchement dans la tidyverse, c'est le nombre hallucinant de dépendances (12 rien que pour dplyr, chacune d'elle ayant ses propres dépendances : ça monte vite !). Je mets cela en parallèle avec data.table, qui ne dépend que de methods. Je reconnais toutefois que la syntaxe de ce dernier est pour le moins déroutante ...

Autre problématique : l'apprentissage de R. L'approche dplyr / Rstudio semble être la solution retenue à l'Insee (du moins préconisée par USSR). Je ne partage pas ce point de vue. Je me range plutôt à l'avis de Norman Matloff (auteur de l'excellent "The art of R programming"), très bien expliqué et documenté ici : https://github.com/matloff/TidyverseSkeptic

Dans ce contexte, je refuse désormais de dispenser la formation "Prise en main rapide de données sous R", car :

je ne suis pas suffisamment compétent en la matière (je n'utilise jamais dplyr)
je n'adhère pas à l'approche "pipe+english verb+purrr"

TL;DR : je ne suis pas fan de dplyr, mais continuerais néanmoins à contribuer, dans la limite de mes moyens.

PS : pas sur d'avoir posté ce message dans la bonne issue :thinking:

PS2 : je ne veux pas donner l'impression que je rejette massivement et inconditionnellement la tidyverse / RStudio et toutes ses contributions. Ils ont fait de grandes choses pour démocratiser l'utilisation de R, et d'excellents packages. Par contre, je m'interroge sur les conséquences de leur politique commerciale/marketing sur l'avenir de R ...

In GitLab by @RLesur on Mar 22, 2020, 19:28

:100: d'accord avec l'idée du package de cartographie mais... n'était-ce pas l'objectif d'oceanis (https://github.com/insee-psar-at/oceanis-package) ? Vu de l'extérieur, c'est comme ça que j'avais interprété la publication d'oceanis sur le CRAN. Mais j'ai certainement du me tromper :thinking:

In GitLab by @RLesur on Mar 22, 2020, 20:16

Faites attention, ce serait vraiment dommage de recréer au sein de l'Insee la fracture qu'il y a dans la communauté R entre tidyverse et tinyverse. Je ne comprends pas ce besoin que ressentent les adeptes/partisans de chaque côté de vouloir imposer leurs vues aux autres...

Perso, je fais les deux, du tidyverse et du R-base, j'alterne suivant les projets. Et il y a des trucs que j'aime/je n'aime pas de chaque côté. J'aime le côté tidy de rlang et la facilité que ça amène pour faire du NSE mais je suis agacé de voir qu'un certain nombre de fonctions sont juste des wrappers de R-base. Je n'ai jamais compris l'intérêt d'utiliser un pipe dans un package (17 appels de fonctions imbriqués pour un pipe !!!) mais j'aime vraiment bien l'enseigner en formation. Et il y a tellement de chausse-trappes dans R-base dans lesquelles je tombe régulièrement que je comprends pourquoi le tidyverse a été créé.

Là encore, je suis schizoprène : quand je me comporte en utilisateur final, je vais apprécier le tidyverse. Quand je développe un package, j'ai tendance à l'éviter. Mais je suis prêt à l'utiliser dans un package si c'est pour bosser avec quelqu'un que j'apprécie.

Et si vous regardez bien, même au sein de RStudio, tout le monde n'a pas la même culture : allez proposer à Yihui d'intégrer dplyr comme dépendance à un des packages de RStudio qu'il maintient et vous verrez la réponse... j'imagine que vous avez déjà tous lu ce post https://yihui.org/en/2018/11/dependency-winner/.

Pour avoir fait des formations à la fois sur R-base/data.table et sur le tidyverse, j'ai été frappé de voir que R-base/data.table est vraiment beaucoup plus difficile à appréhender que le tidyverse pour des personnes non matheuses/non stateuses (en gros, des utilisateurs d'Excel). Et même chez les statisticiens qui n'ont fait que la PROC FREQ pendant des années, le tidyverse est souvent plus simple. A moins que je ne sois un piètre formateur en R-base/data.table, c'est vrai que je ne m'appelle pas Norman Matloff.

C'est effectivement la seule chose dont je suis à peu près convaincu : les débutants ont tendance à apprécier le tidyverse. A mon boulot, il y avait eu un gros cycle de formations à R-base en 2014-2015. Bilan : énorme flop, les gens ont détesté et ont été découragés. Avec les mêmes personnes, on a essayé le tidyverse en 2017/2018. Les retours ont été : on n'avait rien compris avant et là, ça paraît plus simple. Et les gens se sont mis à R grâce au tidyverse. Donc, oui je suis convaincu que c'est plus facile pour débuter. Même si moi j'ai débuté avec R-base et que ça ne me dérange pas de ne faire que ça.

Et pour tout vous dire, j'ai imposé l'utilisation de dplyr à mon boulot et ce, pour une seule raison : dbplyr. Ce que je veux dire par là, c'est que si on m'imposait de choisir entre R-base/data.table et dplyr, je choisirais... SQL.

In GitLab by @oliviermeslin on Mar 23, 2020, 07:48

@gillesfidani : merci pour ton message détaillé, et surtout pour le post de N. Matloff. Je suis d'accord avec les critiques formulées sur le tidyverse: foultitude de dépendances, visée hégémonique, performances pas incroyables, data.table est mieux, n'utiliser que le tidyverse aboutit à une compréhension superficielle de R...

Il me semble clair que le tidyverse ne peut pas être la seule approche de la manipulation de données en R. Ceci dit, la question centrale est la suivante: quelle approche nous semble pertinente pour faire passer à R le maximum d'agents de l'Insee de la façon la plus facile? Comme j’ai découvert R assez récemment (en septembre 2018), je me suis dit que résumer ma trajectoire pourrait vous intéresser:

Mon expérience préalable de codeur: logiciels stats (Stata, SAS), un peu de programmation (Python, Octave) et LaTeX. Et un niveau avancé en Excel (honte à moi :blush:);
J’ai immédiatement trouvé R base franchement rebutant, et trop technique à mon goût. Je suis donc entré dans R par le tidyverse et le pipe (par les e-formations de Datacamp). Ca m’a permis plusieurs choses :
- être très vite opérationnel sur des tâches simples ;
- bien m’approprier Rstudio (et l’interface git) ;
- découvrir les autres packages proches du tidyverse (stringr, ggplot2) dans un cadre rassurant;
- Et surtout, le tidyverse m’a convaincu que ça valait le coup d’investir vraiment en R.
Très vite (grâce à l’aide de Lino), j’ai vu des limites au tidyverse, notamment sur les grosses données, et je suis passé naturellement à data.table. Je me suis aussi progressivement familiarisé avec Base R, et maintenant je n’utilise plus du tout le tidyverse stricto sensu.
data.table m’est apparu comme vraiment déroutant et difficile à apprendre, et je le dis alors que je suis ravi de m’en servir maintenant.

En un mot, mon expérience est que je ne serais jamais monté en compétence aussi vite sans le tidyverse comme marchepied. Ma position rejoint donc celle de @RLesur : les débutants ont tendance à apprécier le tidyverse, et je suis convaincu que c'est plus facile pour débuter, mais ça ne peut en aucun cas suffire en régime de croisière.

In GitLab by @linogaliana on Mar 27, 2020, 15:08

mentioned in commit 76fada713208bc0689920ff2fa6eea62bf8cd09c

In GitLab by @oliviermeslin on Mar 27, 2020, 15:16

assigned to @gillesfidani

In GitLab by @oliviermeslin on Mar 27, 2020, 15:17

@all, j'ai fusionné la fiche données spatiales dans master. J'ai créé une nouvelle branche fiche_cartographie avec le brouillon de fiche cartographique. N'hésitez pas à contribuer!

In GitLab by @linogaliana on Apr 14, 2020, 09:58

Je ferme cette issue qui n'est plus d'actualité puisque la fiche données spatiales a été mergée. On rouvrira une issue spécifique à la carto

In GitLab by @linogaliana on Apr 14, 2020, 09:58

closed

InseeFrLab / utilitR

[Fiches thématiques] Fiche sur la cartographie #2

:bulb: 1: Package avec des fonctions graphiques :bulb:

:bulb: 2: Un thème :bulb: