R-atique

Les transformées d’ondelettes, ou comprendre les mystérieux signaux [félins] grâce aux maths

lvaudor — Mon, 01 Dec 2025 14:15:47 +0000

A quoi peuvent vous servir les transformées d’ondelettes?

A part briller en société si vous avez la chance de comprendre de quoi il retourne, je veux dire?

Eh bien, les transformées d’ondelettes peuvent servir à décrire et comprendre des signaux à des échelles variées: elles sont donc particulièrement utiles si l’on s’intéresse à un signal de type série temporelle pouvant être soumis à des variations périodiques.

Cela peut être par exemple:

des variations de température mesurées toutes les 3h sur une année
le niveau de la mer mesuré toutes les heures sur quelques mois,
le flux de trafic routier mesuré toutes les 10 minutes sur quelques jours
un niveau d’hormones mesuré toutes les 10 minutes sur 48h.

Ce genre de signaux résultant de processus qui s’expriment à différentes échelles, il peut être pertinent de le décrire à travers le temps mais aussi à travers les échelles (ou périodes) pour mieux les comprendre.

Considérons par exemple la série temporelle suivante: j’ai enregistré l’humeur de mon chat toutes les 10 minutes pendant 10 jours grâce à une sonde ultra-perfectionnée (et ultra-imaginaire).

NB: Exceptionnellement, je montre ici des résultats de codes R sans montrer les codes eux-mêmes car les figures suivantes résultent d’un gros travail de mise en application shiny-. Pour l’instant, l’appli waveleT est disponible dans sa version 2016 -!- ici: https://isig-apps.ens-lyon.fr/apps/lvaudor/waveleT/). Le repo github (avec le méga-commit correspondant à sa mise en package et son organisation en modules golem) est ici: https://github.com/lvaudor/waveleT. Je reviendrai ici faire sa promotion et déverser les états d’âme qui m’ont traversée au cours de sa réalisation quand sa nouvelle version -golémisée et packagisée- sera déployée…

Décrire par les ondelettes continues

Voici donc une représentation des humeurs de mon chat au cours de quelques jours du mois de juin 2024:

On y devine des variations journalières, atténuées certains jours, avec a priori des pics de bonne humeur entre 17h et 23h environ. (L’appli peut s’avérer utile pour bénéficier d’un « hover » qui vous permet de situer les variations dans le temps en plaçant la souris dessus ;-)).

Si j’applique une transformée d’ondelettes continues sur ce signal j’obtiens quelque chose comme ça:

C’est flamboyant, c’est fascinant, c’est aussi légèrement effrayant peut-être (surtout si par le passé vous avez traîné dans des sessions poster de conférences où rôdent des physiciens pour qui ce genre de représentation est limpide: ça peut laisser un trauma).

En tout cas voilà comment on peut interpréter ce graphique:

en x, on retrouve le temps: on couvre les quelques jours sur lesquels j’ai effectué des mesures sur mon chat
en y, on trouve des périodes (ici exprimées en minutes). Donc un rythme journalier s’exprimera aux alentours de 24*60=1440 minutes. Là encore, l’échelle log2 sur l’axe des y rend le « hover » fourni par l’appli bien utile.
en échelle colorée, on trouve la « puissance » (power) des coefficients d’ondelette. Elles correspondent grosso modo à une mesure de la variance.

Ici, on peut lire le graphique de cette manière: il y a des variations particulièrement importantes dans le signal à la période 1440 min = 24h sur l’ensemble de la période sauf les 8 et 9 juin (qui s’avèrent être un samedi-dimanche): cela se voyait déjà sur le signal brut. Il y a aussi des variations à une échelle de 720 minutes (12h), et des variations (plus irrégulières peut-être à une échelle entre 240 et 480 minutes (entre 4 et 8h).

La puissance nous renseigne sur l’ampleur des variations et non sur leur nature. Si l’on représente directement les coefficients d’ondelettes, on peut voir les variations positives et négatives:

Je peux ainsi constater que mon chat a un coup de mou quotidien (les jours de semaine) à peu près entre 9h et 17h, et un coup de mieux entre 19h et 7h du matin. Le week-end, son humeur est globalement meilleure (pas de coup de mou en journée). Peut-être est-il heureux d’avoir du monde à la maison?

Par ailleurs, pour l’interprétation des périodes 12h et 4-8h, je peux vous fournir une information complémentaire: le distributeur automatique de mon chat lui a distribué une ration chaque jour à 6h, 10h, 18h, et 22h. Visiblement, mon chat est de meilleure humeur quand il a le ventre plein. Mais la fréquence à laquelle le distributeur améliore de façon apparente son humeur varie non seulement par son paramétrage -les croquettes tombent à 4h d’intervalle à certains moments, à 8h d’intervalle à d’autres- et selon l’événement que l’on considère et sa durée -i.e., en quelque sorte, sa « forme »- : le fait d’avoir les croquettes qui tombent -durée 30 secondes- et le fait d’avoir le ventre plein -durée a priori plus importante-. Ainsi, même pour une une causalité claire (d’autant plus claire à vrai dire que j’ai simulé le jeu de données pour que l’humeur de mon chat réponde aux horaires du distributeur de croquettes) il peut être délicat de décrire le signal en temps-fréquence (ou temps-période). Certaines périodicités sautent aux yeux, d’autres moins.

Décomposer par les ondelettes discrètes

Voilà qui m’amène à une autre manière d’utiliser les ondelettes pour comprendre/décrire ce qui se passe dans un signal temporel.

La figure suivante montre le signal « débruité » pour tous les niveaux scalaires inférieures à une périodicité de 24h. On y voit parfaitement le rythme quotidien des humeurs de mon chat.

Techniquement, ce signal débruité est reconstitué via une analyse multi-résolution par les ondelettes discrètes Là encore, je vous renvoie à mon appli waveleT qui permet de paramétrer l’ondelette-mère et les niveaux scalaires de votre choix facilement.

Si je veux être capable d’examiner les variations dans mon signal à une échelle intermédiaire (pour démêler, par exemple, ce qui se passe aux échelles temporelles entre 4 et 12h) je peux sélectionner des niveaux scalaires inférieurs:

Il devient ainsi possible de considérer les variations du signal qui relèvent uniquement d’une certaine période, en excluant ici le bruit (variations sur les périodes les plus courtes) et les variations sur la période de 24 heures et plus. Il s’agit d’un résultat qui reste descriptif, mais qui a le mérite de faciliter la description et l’interprétation des variations d’un signal complexe.

P.S.: le chat orange chez qui j’ai vécu pendant 13 ans n’est plus . Que ce post soit un hommage vibrant à ce qu’il a accompli (quoique inconsciemment) pour la science et un témoignage ému de l’importance qu’il accordait à ce qui compte vraiment .

Le blog est mort. Vive le blog!

lvaudor — Thu, 06 Nov 2025 09:01:34 +0000

Quatre ans (!), quatre ans sans publier un seul billet sur ce blog. Quatre ans sans écrire, partager des réflexions, des découvertes, des bouts de code, des petites lubies du moment. Le blog a été laissé à l’abandon, un peu comme un vieux fichier .RData oublié dans un dossier poussiéreux.

À vrai dire, il n’a jamais été complètement mort: j’ai continué à y déposer des supports de cours par exemple, mais sans m’y investir vraiment en mode « blog ». Pourquoi? D’abord pour des raisons personnelles (enfants, temps partiel, priorisation de projets « professionnellement urgents »), et plus récemment, parce que la révolution de l’IA générative m’a fait douter de l’intérêt de publier sur le blog.

Le doute était simple: à quoi bon écrire du contenu quand il devient si facile de générer des supports pédagogiques parfaitement adaptés à chacun avec un simple prompt? Mes statistiques de consultation ont confirmé mon intuition: divisées par trois en deux ans. Certes, c’est sans doute lié à mon manque d’activité (et à mon absence de tweets), mais il y a autre chose: les usages d’Internet changent. Les lecteurs ne lisent plus les blogs; ils lisent des contenus digérés par l’IA.

Pour autant, pas de rancune. J’utilise moi-même ces outils tous les jours pour analyser des données, debugger du code, améliorer ce que je rédige, et plus largement gagner du temps sur des tâches chronophages et/ou répétitives. Je ne vois pas au nom de quoi je m’offusquerais de leur usage par d’autres.

En revanche, dans le vaste schéma des choses, si l’IA devait se contenter de re-digérer des contenus générés par IA (on parle d’auto-phagie), elle finirait par tourner en rond, à produire des contenus plats, stéréotypés, ou biaisés. Alors j’ai décidé: peu importe si les lecteurs me lisent moins directement, je projette de recommencer à écrire pour faire passer ma voix, pour que mon code et mes idées ne se dissolvent pas totalement dans les courants du web (oui, il y a sans doute un fond de mégalomanie dans cet air-là).

Cette envie me vient à l’heure où j’ai décidé de rédiger une HDR (et où, ce faisant, je redécouvre le plaisir d’écrire sans -trop- de contraintes). En prévision de mon futur HDR-blues, il me faut trouver un futur exutoire à mes envies d’expression personnelle.

Donc, le blog quasi-renaît de ses presque-cendres. Certaines choses changent: plus de promotion sur feu Twitter, mais sur LinkedIn (où je vois que « ça bouge »), et je continuerai à l’illustrer à la main (sans IA). Pourquoi? Parce que, certes, cela prend du temps, mais ça me fait plaisir… et parce que pour le moment aucune IA ne fait encore des illustrations qui me conviennent vraiment. Par contre, j’utiliserai l’IA pour améliorer le texte ou m’aider à le structurer (c’est un retour d’ascenseur, en somme). On verra si cela se ressent dans mon style d’écriture!… et si j’arrive toujours, malgré cela, à y exprimer quelque chose de personnel. Spoiler alert: je crois que c’est possible, et que les IA génératives comme ChatGPT peuvent même aider… même si les textes que je lui demande de réécrire « dans le style de Lise Vaudor » sont truffés de blagues vraiment nases -et vous m’en voyez bien marrie!-.

Dans mes idées pour les prochains billets, il y a justement cette question de l’IA générative (oui pour le coup ce n’est pas très original!), et notamment à la question de son coût environnemental qui m’a toujours pas mal interrogée. Aussi, j’aimerais faire renaître de ses cendres un autre de mes projets sur lequel j’ai beaucoup travaillé, mais peu communiqué: celui de l’analyse des signaux par les ondelettes. Espérons que toutes ces annonces en fanfare me poussent à effectivement trouver le temps d’écrire tout cela .

Practice makes purrr-fect

lvaudor — Tue, 07 Sep 2021 12:47:52 +0000

purrr et dplyr sont dans un bateau: aucun ne tombe à l’eau

Voilà déjà 3 ans, je publiais sur ce blog un billet sur le package purrr. Depuis, avec la pratique, j’ai pu identifier quelques points techniques qui me mettaient en difficulté assez fréquemment et pour lesquels j’aimerais vous présenter quelques explications.

Ces difficultés sont en fait nées de l’utilisation simultanée de dplyr et de purrr, qui sont certes conçus pour fonctionner ensemble, mais dont l’usage conjoint pouvait des fois causer quelques noeuds à mon cerveau lors de l’écriture de mes codes.

Un petit rappel rapide d’abord:

Le principe de base de purrr, c’est d’itérer n fois une fonction sur les n éléments d’un vecteur ou d’une liste.

Si la fonction .f() prend en entrée un argument x (et éventuellement des arguments supplémentaires figurés ici par ...) et renvoie en sortie un résultat y

alors on peut grâce à purrr::map() appliquer la fonction .f() à tout un vecteur ou liste .x=(x_1,x_2,x_3,...,x_n) pour obtenir un vecteur ou liste (y_1,y_2,y_3,...,y_n).|

Alors, partant de ce principe, comment les fonctions de purrr peuvent-elles s’articuler avec les idées “tidy” et notamment l’omniprésence de tableaux pour traiter les données?

Fonctions, formules et pipéabilité

Le premier petit souci que j’ai pu avoir dans l’usage conjoint de dplyr et purrr était lié au fait que (faute d’avoir compris toutes les possibilités syntaxiques des fonctions du package) je me retrouvais souvent obligée d’écrire des petites fonctions “rustines” destinées à ne servir qu’une seule fois, et qui faisaient tache dans la beauté ondoyante et serpentine de mon code :-p (beauté ondoyante et serpentine conférée par l’usage de dplyr et des pipes bien sûr).

C’est-à-dire que, au lieu de faire

resultat <- blabla %>%
  dplyr::truc() %>%
  dplyr::bidule() %>%
  dplyr::machin() %>%
  dplyr::mutate(chose=purrr::map(fonction_standard)) %>% 
  dplyr::bidule() %>%
  dplyr::machin()

j’étais régulièrement de faire un truc du genre

resultat <- blabla %>%
  dplyr::truc() %>%
  dplyr::bidule() %>%
  dplyr::machin()

fonction_rustine=function(blabla){
  blabla
}

resultat= resultat %>%
  dplyr::mutate(chose=purrr::map(fonction_rustine)) %>% 
  dplyr::bidule() %>%
  dplyr::machin()

car je ne trouvais pas la fonction standard adéquate.

Ainsi donc, ma méconnaissance de l’usage des formules dans les fonctions de purrr nuisaient à la “pipéabilité” de mon code. Cela vous semble peut-être un détail, mais ça m’ennuyait beaucoup (imaginez l’exemple ci-dessus avec davantage de lignes et plusieurs “petites fonctions rustines” par exemple: la relecture et compréhension de la chaîne de traitement s’en trouve vite complexifiée, même pour des opérations “toutes bêtes”).

Ainsi donc, première prise de conscience de ma part, on peut écrire, au lieu de :

rustine=function(blabla){
  lignes_de_commande_impliquant_blabla
}

purrr::map(.x=truc, .f=rustine)

quelque chose comme:

purrr::map(.x=truc,
           ~lignes_de_commande_impliquant_.x)

L’usage d’une formule peut aussi permettre d’utiliser une fonction standard qu’on souhaite itérer sur un autre argument que son premier argument. Par exemple:

purrr::map(.x=truc,
           ~fonction_standard(a=33,b=.x))

Attention à la position des arguments supplémentaires pour la fonction .f() dans l’appel à map!

Dans le cas où on spécifie une fonction:

purrr::map(.x=truc,
           .f=fonction_machin,
           argument_supplémentaire=33) 
#argument spécifié dans l'appel à map()

Dans le cas où on spécifie une formule:

purrr::map(.x=truc,
           .f=~fonction_machin(blabla,
                               argument_supplémentaire=33)) 
# argument spécifié dans l'appel à fonction_machin()

Je n’ai pas réussi pour le moment à construire un “vrai” exemple permettant d’illustrer ces principes tout en restant simple… Je vais donc me contenter pour le moment de ces ‘fausses’ lignes de code…

Petit à petit, les données font leur nid

Passons maintenant à une autre fonction qui me permet régulièrement d’utiliser purrr pour mes jeux de données.

Il s’agit de la fonction tidyr::nest().

Chargeons le tidyverse:

library(tidyverse)

et examinons la situation suivante:

birds=tibble(id=paste0("ad_",1:6),
             species=c("orange","yellow","blue",
                       "blue","yellow","orange"),
             sex=rep(c("M","F"),3))

La fonction tidyr::nest() permet de regrouper des lignes et colonnes en sous-jeux de données dans une colonne data. La colonne data correspond à une colonne-liste (ou list-column en anglais). Autrement dit, la commande ci-dessous regroupe les données (selon l’argument spécifié pour group_by()) en nids.

nested_couples=birds %>% 
  group_by(species) %>% 
  nest()

nested_couples

## # A tibble: 3 × 2
## # Groups:   species [3]
##   species data            
##                
## 1 orange  
## 2 yellow  
## 3 blue

Chaque couple-nid pond alors des oeufs selon des règles propres à leur espèce. Définissons la fonction lay_eggs() correspondant à ce processus.

lay_eggs=function(species){
  n_egg=case_when(species=="orange"~2,
                  species=="blue"~1,
                  species=="yellow"~3)
  eggs=tibble(egg=paste0("egg_",1:n_egg))
  return(eggs)
}
lay_eggs("orange")

## # A tibble: 2 × 1
##   egg  
##   
## 1 egg_1
## 2 egg_2

Cette fonction prend en argument d’entrée l’espèce considérée, et renvoie en sortie une table comprenant autant de lignes que d’oeufs pondus.

On peut appliquer cette fonction à l’ensemble des couples-nids de la manière suivante:

after_lay_eggs=nested_couples %>% 
  mutate(eggs=purrr::map(species,lay_eggs))

Examinons de plus près ce résultat, par exemple pour l’espèce “yellow”:

after_lay_eggs %>% filter(species=="yellow") %>% pull(eggs)

## [[1]]
## # A tibble: 3 × 1
##   egg  
##   
## 1 egg_1
## 2 egg_2
## 3 egg_3

Il va s’agir maintenant de voir éclore les oeufs. Voici la fonction qui correspond à ce processus. Elle prend deux arguments: eggs, évidemment, mais aussi species, dont dépend le sex-ratio des juvéniles.

hatch_eggs=function(eggs,species){
  sex_ratio=case_when(species=="blue"~0.54,
                      species=="yellow"~0.6,
                      species=="orange"~0.4)
  youngs=eggs %>% 
    mutate(young=str_replace(egg,"egg","young")) %>% 
    select(-egg) %>% 
    mutate(sex=runif(nrow(eggs),0,1)) %>% 
    mutate(sex=sex% 
    mutate(sex=case_when(sex==T~"M",
                         sex!=T~"F"))
}

On itère sur les deux arguments de la fonction donc on utilise purrr::map2() :

set.seed(33)
after_hatch=after_lay_eggs %>% 
  mutate(youngs=purrr::map2(eggs,species,hatch_eggs)) %>% 
  select(-eggs)

Je retire la colonne eggs qui n’a plus lieu d’être après éclosion…

Examinons plus en détail par exemple ce qu’on obtient pour l’espèce “yellow”:

after_hatch %>% filter(species=="yellow") %>% pull(youngs)

## [[1]]
## # A tibble: 3 × 2
##   young   sex  
##      
## 1 young_1 F    
## 2 young_2 F    
## 3 young_3 M

Il est maintenant de laisser s’envoler nos petits oiseaux! Nous allons les faire sortir du nid…

birds_youngs=after_hatch %>% 
  unnest(cols=c("youngs")) %>% 
  ungroup()
birds_youngs

## # A tibble: 6 × 4
##   species data             young   sex  
##                    
## 1 orange   young_1 M    
## 2 orange   young_2 F    
## 3 yellow   young_1 F    
## 4 yellow   young_2 F    
## 5 yellow   young_3 M    
## 6 blue     young_1 M

En faisant appel à unnest() sur la colonne youngs, on sort les juvéniles de leur nid et les attributs des “nids” (ici species) sont répétés autant de fois que nécessaire pour qualifier désormais les individus juvéniles.

Notez qu’on ne pourrait pas faire la même opération de manière concomittante sur data pour une question de dimensions (data comporte des éléments qui ont tous 2 lignes, youngs comporte des éléments dont le nombre de ligne varie entre 1 et 3).

Ce petit exemple très simple (et imagé) vous aidera j’espère à exploiter les possibilités offertes par le trio dplyr-tidyr::nest()-purrr!

ACP

lvaudor — Tue, 11 May 2021 11:13:39 +0000

Très régulièrement, dans le cadre de ma mission de support à la recherche, on me demande de réaliser (ou d’aider à réaliser) des ACP (Analyses en Composantes Principales). En général cette demande ne s’ensuit pas d’un fol enthousiasme de ma part: je me sens un peu comme une cuisinière “bistronomique” à qui on demanderait tout le temps une entrecôte-frites. Je peux comprendre le côté “tradi mais appétent” mais pour moi c’est pas l’éclate.

Quoi qu’il en soit, la demande étant somme toute légitime (et fréquente) voici un billet où je rassemble quelques éléments d’information et outils pour réaliser des ACP sans douleur.

Une ACP, pour quoi faire

Une ACP (ou “PCA” pour Principal Components Analysis en anglais) c’est une analyse qui vise à décrire un jeu de données comprenant de multiples variables quantitatives.

Elle fait partie d’une même “famille” d’analyses, celle des analyses factorielles qui s’appliquent à de larges tableaux de données (pas forcément uniquement composés de variables quantitatives comme dans le cas de l’ACP).

Le principe d’une ACP est de réduire un jeu de données à N>2 variables (i.e. N dimensions) à quelques (généralement 2) variables nouvelles (ce qu’on appelle les composantes principales). Le but de la manoeuvre, c’est d’obtenir quelque chose qui est beaucoup plus facile à décrire et à représenter qu’un jeu de données avec beaucoup de variables (puisque 2 dimensions, c’est ce qu’il faut pour représenter le jeu de données “dans son entièreté” sur un graphique, que ce soit pour un article papier ou sur un écran d’ordinateur…).

Le coeur du “job” de l’ACP, c’est donc justement de calculer ces composantes principales à partir des variables de base.

Tentons une analogie.

Imaginez une banane par exemple. Il s’agit d’un objet 3D. Si je veux le représenter en 2D, selon l’angle que je choisirai pour la représenter, je vais obtenir quelque chose de plus ou moins “reconnaissable”.

A gauche, l’angle choisi est tel qu’on ne reconnaît pas la forme de la banane. A droite, c’est bien mieux, car l’angle choisi permet de reconnaître le côté allongé et courbé caractéristique. Notez que dans les deux cas, la couleur est une information supplémentaire bienvenue pour l’interprétation ;-)..

Eh bien, pour réaliser l’image de droite, un dessinateur fait un peu l’équivalent d’une ACP en trouvant un “angle” (ou plus précisément un “plan” défini par deux axes) qui va apporter le plus d’information possible sur l’objet, de sorte que l’oeil humain puisse interpréter de quoi il s’agit.

Quand on travaille sur un jeu de données à N>>2 dimensions (et généralement N>>3) il est évidemment plus difficile d’avoir une image mentale de la structure/forme de l’objet d’origine que dans le cas d’une banane… La représentation “la plus juste possible” de cet objet en 1D, 2D ou 3D que propose l’ACP va permettre d’appréhender cette structure/forme.

Calcul des composantes principales

Je ne rentrerai pas ici dans le détail du calcul réalisé dans le cadre d’une ACP. Il y a derrière des notions de maths qui ne sont pas forcément très accessibles (c’est selon votre sensibilité, votre cursus, et la fraîcheur de vos études mais par exemple, j’ai pour ma part fait une prépa bio/véto il y a une quinzaine d’années -et donc pas mal de maths- mais le mécanisme exact du calcul me semble toujours un peu difficile à appréhender!).

Néanmoins, si vous êtes frustrés de ne pas comprendre “en profondeur” la méthode et que vous pensez que cela nuit à la qualité des interprétations que vous faites de vos analyses factorielles, je recommande les matériels pédagogiques relatifs au package FactoMineR, et en particulier pour les ACP en particulier cette vidéo de François Husson, un des auteurs du package. C’est très bien amené et expliqué! Si vous tombez au bon moment, vous pouvez même suivre le MOOC (je l’ai suivi moi-même il y a quelques années et cela m’a bien aidé à mettre mes idées au clair).

Réaliser l’ACP

Il existe plusieurs packages pour réaliser les ACP. Les deux principaux, FactoMineR et ade4 ont été développés par des équipes françaises (cocorico!?). Et ce n’est guère surprenant, les analyses factorielles elles-mêmes étant très françaises (comme l’entrecôte-frites?) puisqu’elles ont été mises au point dans les années 70 notamment par un certain Jean-Paul Benzécri et par son équipe.

Le package ade4 a été développé (et est maintenu) par une équipe lyonnaise, qui travaille notamment avec des biologistes de l’évolution et des écologues (cela se ressent sur les exemples d’application d’ACP avec ce package que vous pourrez trouver!). Le package FactoMineR a quant à lui été développé (et est maintenu) par une équipe rennaise, qui travaille dans un univers un peu plus “agronomique”. Pour les méthodes les plus centrales (ACP, AFC), les différences entre ces packages sont à mon avis mineures et une fois que vous avez compris le principe d’une ACP vous pouvez sans inconvénient majeur opter pour l’un ou l’autre. Pour ma part, bien que Lyonnaise, j’ai une petite préférence pour FactoMineR car je trouve que c’est un peu plus facile de s’y retrouver (que ce soit pour les noms des fonctions ou des objets renvoyés, ou pour les supports pédagogiques).

Du coup, pour vous montrer un exemple d’ACP, je vais partir sur un exemple avec FactoMineR. D’ailleurs, je ne me casse vraiment pas la tête ici puisque je reprends le jeu de données et l’exemple proposé sur le site de FactoMineR lui-même

library(FactoMineR)
data(decathlon)
head(decathlon)

##          100m Long.jump Shot.put High.jump  400m 110m.hurdle Discus Pole.vault Javeline 1500m Rank Points Competition
## SEBRLE  11.04      7.58    14.83      2.07 49.81       14.69  43.75       5.02    63.19 291.7    1   8217    Decastar
## CLAY    10.76      7.40    14.26      1.86 49.37       14.05  50.72       4.92    60.15 301.5    2   8122    Decastar
## KARPOV  11.02      7.30    14.77      2.04 48.37       14.09  48.95       4.92    50.31 300.2    3   8099    Decastar
## BERNARD 11.02      7.23    14.25      1.92 48.93       14.99  40.87       5.32    62.77 280.1    4   8067    Decastar
## YURKOV  11.34      7.09    15.19      2.10 50.42       15.31  46.26       4.72    63.44 276.4    5   8036    Decastar
## WARNERS 11.11      7.60    14.31      1.98 48.68       14.23  41.10       4.92    51.77 278.1    6   8030    Decastar

Il s’agit donc d’un jeu de données qui comprend les résultats pour différentes épreuves du Décathlon (en colonnes) de plusieurs athlètes (en lignes).

Les 10 premières colonnes correspondent aux résultats (quantitatifs) aux 10 épreuves du Décathlon. Attention, pour les épreuves de vitesse (100m, 110m.hurdle, 400m, 1500m), les valeurs élevées correspondent à de mauvaises performances!… Les variables supplémentaires “Rank”, et “Points” correspondent respectivement aux rang, et nombre de points total de chaque athlète, La variable supplémentaire “Competition” indique lors de quelle compétition ces résultats ont été obtenus.

Réalisons une ACP sur les 10 premières variables (les variables quantitatives) pour avoir un “aperçu” de la structure des résultats des athlètes aux différentes épreuves. J’utilise pour ce faire une fonction qui s’appelle PCA():

resultat=PCA(decathlon[,1:10], graph=FALSE)

Et voilà! ça tourne en une demi-seconde, et renvoie (en plus de graphiques si on ne précise pas graph=FALSE) le résultat suivant.

resultat

## **Results for the Principal Component Analysis (PCA)**
## The analysis was performed on 41 individuals, described by 10 variables
## *The results are available in the following objects:
## 
##    name               description                          
## 1  "$eig"             "eigenvalues"                        
## 2  "$var"             "results for the variables"          
## 3  "$var$coord"       "coord. for the variables"           
## 4  "$var$cor"         "correlations variables - dimensions"
## 5  "$var$cos2"        "cos2 for the variables"             
## 6  "$var$contrib"     "contributions of the variables"     
## 7  "$ind"             "results for the individuals"        
## 8  "$ind$coord"       "coord. for the individuals"         
## 9  "$ind$cos2"        "cos2 for the individuals"           
## 10 "$ind$contrib"     "contributions of the individuals"   
## 11 "$call"            "summary statistics"                 
## 12 "$call$centre"     "mean of the variables"              
## 13 "$call$ecart.type" "standard error of the variables"    
## 14 "$call$row.w"      "weights for the individuals"        
## 15 "$call$col.w"      "weights for the variables"

Ce résultat comprend 3 éléments principaux:

eig des infos sur les eigenvalues (ou “valeurs propres”), qui vont nous permettre d’évaluer la qualité de l’ACP. J’y reviendrai dans la partie suivante.
ind: des infos sur les individus (lignes du tableau initial)
var: des infos sur les variables (colonnes du tableau initial)

ind et var contiennent tous deux des éléments d’information correspondant à

coord les coordonnées des individus ou variables sur les axes principaux
cos2 qui permet d’évaluer si un individu ou une variable en particulier est bien représenté sur les axes principaux
contrib qui permet d’évaluer le “poids” d’un individu ou d’une variable particuliers dans le calcul des axes.

Les résultats graphiques d’une ACP correspondent usuellement à la représentation des coordonnées des individus et des variables dans l’espace défini par les axes principaux (en pratique, on en retient souvent 2 par défaut). C’est le cas ici, si on laisse FactoMineR nous proposer une représentation graphique de l’ACP (en ne précisant pas graph=FALSE).

resultat=PCA(decathlon[,1:10])

Le premier graphique correspond aux individus, le deuxième aux variables.

Ces deux représentations sont (rappelons-le) imparfaites puisqu’en réduisant le nombre de dimensions du jeu de données de 10 à 2 on a perdu une partie de l’information contenue par le jeu de données.

Qualité de l’ACP

Les eigenvalues apportent une information quant à la qualité de l’ACP en permettant de calculer la proportion de variance (ou inertie) du jeu de donnée initial qui est portée par les composantes principales issues de l’analyse.

resultat$eig

##         eigenvalue percentage of variance cumulative percentage of variance
## comp 1   3.2719055              32.719055                          32.71906
## comp 2   1.7371310              17.371310                          50.09037
## comp 3   1.4049167              14.049167                          64.13953
## comp 4   1.0568504              10.568504                          74.70804
## comp 5   0.6847735               6.847735                          81.55577
## comp 6   0.5992687               5.992687                          87.54846
## comp 7   0.4512353               4.512353                          92.06081
## comp 8   0.3968766               3.968766                          96.02958
## comp 9   0.2148149               2.148149                          98.17773
## comp 10  0.1822275               1.822275                         100.00000

Par construction, l’ACP calcule et ordonne les composantes pour que la première porte plus d’information que la deuxième, qui en porte plus que la troisième, etc.

Les valeurs dans la deuxième colonne (percentage of variance) correspondent en effet aux valeurs d’eigenvalues divisées par le nombre initial de variables (10).

On retrouve dans cette colonne percentage of variance les valeurs de 32.72% et 17.37% qui étaient indiquées dans les étiquettes d’axes des deux graphiques ci-dessus. Ainsi, avec une représentation 2D (correspondant aux deux premiers axes principaux) on arrive à représenter 32.7+17.3=50.0% de l’information contenue dans le jeu de données initial.

* »Et alors, __% d’inertie portée par mes deux premiers axes, c’est bien ou c’est pas bien? »* m’entends-je demander parfois.

Eh bien mon bon monsieur, ma bonne dame, ptêt ben qu’oui, ptêt ben qu’non. Il n’existe à ma connaissance pas de convention sur une valeur qui serait “suffisamment bonne”.

Ici, on a 50% de l’info sur 2 axes, alors qu’on avait 10 variables à la base. Avant de réaliser l’ACP, deux dimensions correspondaient donc à 2 fois un dixième de l’inertie du jeu de données, soit 20%. L’ACP a donc permis de passer de 20% à 50% de l’info représentable par un graphique 2D: ça semble honnête, tant qu’on garde à l’esprit dans les interprétations que la moitié de l’info est perdue dans notre tentative de simplification.

Si on avait eu à la base 4 variables dans le jeu de données, 50% de l’info représentée par les deux premiers axes de l’ACP, ç’aurait été clairement très mauvais, puisque 2 sur 4 des variables initiales auraient déjà pu apporter cette part d’info. Autrement dit, l’ACP n’aurait servi à strictement rien.

La proportion d’info portée par les composantes principales dépend évidemment du nombre de variables en entrée.

Mais pas que.

Ce qui permet à l’ACP de “réduire en dimensionnalité” un jeu de données, c’est l’existence de corrélations entre les variables d’origine.

Si dans un jeu de données on a deux groupes de variables extrêmement inter-corrélées, alors très bien: deux composantes principales seront à même de représenter relativement bien les deux types d’effets. Si en revanche les N>>2 variables sont très peu corrélées les unes aux autres, alors on n’a aucune chance de “résumer” fidèlement le jeu de données dans son ensemble à l’aide de quelques composantes principales…

Interprétation

On peut interpréter les sorties graphiques d’une ACP de trois manières:

en examinant la position des variables dans le nouveau repère (et en comparant la position des variables les unes par rapport aux autres)
en examinant la position des individus dans le nouveau repère (et en comparant la position des individus les uns par rapport aux autres)
en examinant la position des individus par rapport à la position des variables dans le nouveau repère

Position des variables

La représentation des variables dans le plan factoriel, aussi appelé cercle des corrélations, permet d’évaluer la liaison entre les variables.

Plus l’angle entre deux variables est petit, plus la corrélation est proche de 1. Si l’angle est droit, la corrélation est proche de 0. Si l’angle est de 180° (les flèches sont opposées) alors la corrélation est proche de -1. tout ça est s’applique évidemment si les variables sont “bien représentées” par les deux premiers axes de l’ACP

plot.PCA(resultat, choix="var")

Ici par exemple, les performances des sportifs semblent corrélées positivement pour les disciplines de “force” Discus,Shot.put,High.jump. Les disciplines de “vitesse” 400m, 110m.hurdle 100m sont aussi positivement corrélées les unes aux autres. La performance en Long.jump est inversement corrélée aux résultats de vitesse (rappelons que les résultats de vitesse sont des temps, donc une bonne performance sur les épreuves de vitesse est corrélée à une bonne performance en saut en longueur).

La qualité de représentation d’une variable par un axe peut être évaluée à travers le cosinus carré de l’angle entre la variable et l’axe considéré. Le cosinus correspond à la projection orthogonale de la pointe de la flèche sur l’axe. Du coup, (petit rappel du théorème de Pythagore) la qualité de représentation sur les deux axes (i.e. la somme des cosinus carrés) correspond à la longueur de la flèche: plus la pointe de la flèche est proche du cercle, plus la représentation de la variable dans le plan factoriel est “de qualité”.

Rappelons que le premier axe correspond à la plus grande part d’inertie du jeu de données initial. Ici, on voit que le jeu de données est structuré principalement par (à droite) les bonnes performances (i.e. petites valeurs pour les épreuves de vitesse et grosses valeurs pour toutes les autres) vs (à gauche) les mauvaises performances.

Position des individus

plot.PCA(resultat, choix="ind")

Ce graphique montre les “ressemblances” entre individus. Plus ils sont proches (comme par exemple Parkhomenko et Korkizoglou, en haut à gauche, ou Karpov, Sebrle et Clay à droite), et plus leurs “profils” de performance sont vraisemblablement similaires.

Les coordonnées des individus peuvent ainsi classiquement servir de base pour définir des classes d’individus à travers une classification hiérarchique ascendante (par exemple).

Comme dans le cas des variables, les individus les mieux représentés par le plan factoriel sont ceux les plus éloignés du centre (même si ici on ne peut pas lire directement les valeurs de cosinus sur le graphique – elles sont en revanche disponible dans l’objet resultat issu de l’ACP).

La position des individus peut en outre être interprétée en lien avec la position des variables. Par exemple Casarsa, tout en haut à gauche, a vraisemblablement eu des résultats assez mauvais dans toutes les épreuves, tandis que Sebrle (à droite, en haut) a plutôt eu de bons résultats, en particulier dans les épreuves “de force”.

Représentations graphiques

Pour l’instant je me suis contentée d’utiliser les représentations graphiques proposées par le package FactoMineR lui-même. Elles peuvent être suffisantes pour une première exploration des résultats d’ACP mais ne suffisent généralement pas à produire des graphiques suffisemment lisibles et jolis pour (par exemple) faire partie d’articles, rapports ou autres.

Il existe divers packages qui permettent d’améliorer et paramétrer finement les graphiques typiques d’une ACP. Si vous travaillez avec le package FactoMineR, le package factoextra est une possibilité intéressante. Voyez ici très bien fait qui vous montrera quelques exemples d’utilisation de ce package (Vous ne serez de plus pas trop perdus car ce billet utilise aussi des données d’exemple liées au Décathlon -attention tout-de-même il s’agit d’un jeu de données decathlon2 et non decathlon ce qui explique les quelques différences de résultats que vous pouvez remarquer).

Pour ma part je suis totalement conquise par le package explor de Julien Barnier pour explorer mes résultats d’ACP (plus d’infos ici).

Ce package produit une interface Shiny qui vous permet de visualiser vos résultats et paramétrer finement vos sorties graphiques, décaler les étiquettes qui se chevaucheraient, etc. Et vous pouvez suite à ces manipulations soit exporter les figures (au format et dimensions de votre choix), soit copier le code R qui permet de produire les graphiques en question (dans un souci de reproductibilité de vos analyses…).

Pour lancer cette interface, c’est très simple. On réalise l’ACP avec le package de son choix (FactoMineR OU ade4!) et on lance la fonction explor() avec ce résultat d’ACP en objet:

resultat=PCA(decathlon, quanti.sup=11:12,quali.sup=13, graph=FALSE)
explor::explor(resultat)

Ici j’ai précisé que mon jeu de données comprenait des variables supplémentaires (que je désigne par le numéro de colonne) de manière à pouvoir les utiliser dans les sorties graphiques.

Petit “tweak” d’utilisation de ce package: Il m’arrive également, quand je souhaite faire des graphiques qui sortent un peu des sentiers battus avec des résultats issus d’analyses factorielles, de récupérer les résultats mis en forme par la fonction prepare_results() de ce package. Ensuite j’utilise les tableaux en sortie avec le combo magique tidyr-dplyr-ggplot2 et hop, je suis à même d’obtenir exactement le graphique que j’ai en tête…

Géocodage sous R via une API

lvaudor — Mon, 09 Nov 2020 13:06:04 +0000

Géocodage via une API: was ist das?

Géocodage

Le géocodage d’abord: Il s’agit d’une opération qui consiste à associer des coordonnées géographiques à un nom de lieu ou une adresse. C’est donc une opération incontournable si vous disposez par exemple d’un jeu de données comprenant des lieux sous forme de chaînes de caractère, et que vous voudriez l’utiliser pour produire une carte.

API

Qu’est-ce qu’une API, maintenant:

API cela veut dire Application Programming Interface. C’est un service qui permet aux développeurs de récupérer des données via internet pour les utiliser dans leurs applications. Imaginez par exemple que, aiguillonné par la faim, vous vous rendiez sur un site de commande de repas en ligne pour commander un burgher. Pour que seuls s’affichent les restaurants qui peuvent vous livrer et faire en sorte de vous fournir un temps d’attente probable, les développeurs de ce site ont fait en sorte de récupérer votre position à partir de l’adresse postale que vous leur avez fournie. Cette opération se fait automatiquement, à travers une API de géocodage (celle de Google par exemple). Dans ce cas, on comprend bien pourquoi cela s’appelle une API: l’interface du service vous permet de récupérer des données, qui seront utilisées dans une autre application (ici le site de vente de burghers en livraison).

J’en ai vraiment besoin?

“Mais moi je suis pas développeur” me direz-vous peut-être. Effectivement, vous n’avez peut-être pas l’intention de construire un site web ou une application qui sollicitera régulièrement telle ou telle API. Mais sans développer une application à proprement parler vous pouvez tout-de-même avoir besoin de géocoder un certain nombre d’adresses de manière automatique… Dans ce cas vous aurez une utilisation d’API ponctuelle et limitée à un nombre fixe de requêtes (le nombre d’éléments que vous voulez géocoder pour compléter votre jeu de données)… ça tombe bien, souvent l’utilisation gratuite des API est limitée à un certain nombre de requêtes par jour ou seconde (ben oui parce que c’est un service, et un service c’est rarement gratuit, sauf peut-être si c’est un petit service).

Personnellement, les quelques fois où j’ai souhaité faire du géocodage, c’était dans le but d’exploiter les renseignements de localisation d’utilisateurs Twitter: ça signifiait géocoder des noms de lieux renseignés à des niveaux de précision et d’exactitude divers (par exemple “Quartier Beauregard, Trifouillis-les-Oies”, ou juste “France”, ou “Allemagne et USA”, ou encore “Je suis partout où le vent me porte”… cette rubrique des profils Twitter pouvant être renseignée -ou au contraire laissée vide- totalement librement). Je souhaitais récupérer non seulement la localisation (latitude-longitude) mais aussi des informations d’appartenance (à une ville, ou un pays) à l’échelle la plus fine possible selon le degré de précision avec lequel l’utilisateur avait spécifié sa localisation.

Il existe diverses API qui permettent de réaliser le géocodage de noms de lieux et de récupérer non seulement la localisation mais également divers renseignements. Dans ce billet, je parlerai de l’API de géocodage de Google, de l’API Opencage, et de l’API Nominatim d’OSM.

Exemple

Dans la suite de ce billet je testerai ces trois API pour collecter des informations sur les lieux suivants:

mydf <-tibble::tibble(loc=c("Lyon, France",
                            "22 place du Général de Gaulle, Paris",
                            "la Guillotière, Lyon",
                            "Europe",
                            NA,
                            "Tucson, AZ",
                            "Rio Grande do Sul"))

Pour l’exemple j’ai choisi des lieux désignés de façon plus ou moins vague, à des échelles variées et un peu partout dans le monde.

Pour utiliser une API: montrez patte blanche!

Pour accéder à une API, il est la plupart du temps de s’enregistrer auprès de son fournisseur afin de disposer d’une clé d’accès (API key): une espèce de long mot de passe qui permet à l’API de vous identifier vous et d’identifier l’application pour laquelle la requête est passée.

Nominatim (OSM)

Pour accéder à cette API: bonne nouvelle! Nul besoin d’une clé :-). L’utilisation est en principe accordée pour un usage “créatif et inattendu”… Attention néanmoins à utiliser le service de manière “respectueuse” (ie ne pas envoyer 2000 requêtes en 5 minutes par exemple, pour ne pas surcharger les serveurs par des demandes inconsidérées). Plus de détails [ici] (https://operations.osmfoundation.org/policies/nominatim/)

Google

Pour accéder à l’API de géocodage de google, il faut disposer d’un compte Google et aller récupérer une clé pour les “maps-APIs” Google ici. Il va falloir aussi renseigner une carte de crédit, même si vous ne pensez pas dépasser les quotas d’accès gratuit (ça ne fait pas trop plaisir mais sans ces “billing informations” la clé ne fonctionnera pas…).

La clé devrait ressembler à un truc sympa du genre: “BEiz89gzKNzlcpaK90ver80A_230Lli0N173kinvB” (c’est évidemment une fausse clé que j’indique ici ).

Notez que si vous disposer d’une clé pour l’API Google, cela vous permettra aussi de disposer des fonds de carte lorsque vous utilisez ggmap pour faire vos cartes (voir billet de blog ici -billet que j’avais rédigé à une époque où une clé n’était pas encore nécessaire pour cela-)

Opencage

Pour accéder à l’API Opencage, vous pouvez vous enregistrer ici. Pour une utilisation ponctuelle et limitée (2500 requêtes par jour max) vous n’aurez pas besoin de renseigner votre carte de crédit (ouf!).

Votre clé sera un truc du genre “6fjzlc8z2s6f113qx215zlk22ig1vq” (encore une fois, c’est une clé que j’ai inventée pour vous montrer l’allure de la chose ).

Où enregistrer vos clés d’accès aux API?

Si vous travaillez avec R, il y a de fortes chances que vous soyez amené à partager vos scripts avec des collaborateurs ou même avec le monde (via github par exemple). C’est donc une mauvaise idée d’enregistrer vos clés dans vos scripts ou dans tout autre document que vous pourriez partager par inadvertance. Il vaut mieux aller les cacher dans un document aux tréfonds de votre machine, qui vous permette d’accéder à leurs valeurs sans risquer de les partager.

Une solution pour cela consiste à les enregistrer comme variable d’environnement dans R. Pour faire cela vous pouvez faire

usethis::edit_r_environ()

ce qui va vous ouvrir le fichier .Renviron, où qu’il se trouve sur votre machine.

Ensuite, vous taperez les lignes suivantes (avec les bonnes clés bien sûr) dans ce fichier:

GOOGLE_KEY="BEiz89gzKNzlcpaK90ver80A_230Lli0N173kinvB"
OPENCAGE_KEY="6fjzlc8z2s6f113qx215zlk22ig1vq"

Après enregistrement de .Renviron et réouverture de R, vous pourrez accéder aux valeurs de ces variables à l’aide des commandes Sys.getenv("GOOGLE_KEY") et Sys.getenv("OPENCAGE_KEY").

Comment ça fonctionne?

Les requêtes envoyées aux API ressemblent à des URL un peu complexes de ce genre (ici pour rechercher “La Guillotière, Lyon” auprès de l’API de géocodage Google):

"https://maps.googleapis.com/maps/api/geocode/json?address=Grande+Rue+de+la+Guilloti%C3%A8re,+Lyon&key=BEiz89gzKNzlcpaK90ver80A_230Lli0N173kinvB"

{Au passage, notez que “URL” (pour “Uniform Resource Locator”) prend ici tout son sens…

On peut voir que cette URL correspond d’abord à l’“adresse” de l’API (https://maps.googleapis.com/maps/api/geocode/json), ensuite à la requête elle-même suivie du paramètre “key” (address=Grande+Rue+de+la+Guilloti%C3%A8re,+Lyon&key=BEiz89gzKNzlcpaK90ver80A_230Lli0N173kinvB ») dont la nature et les valeurs possibles sont documentées directement par le fournisseur des API :

pour Nominatim (OSM), c’est ici
pour Google, c’est ici
pour Opencage, c’est ici

En principe, donc, on peut très bien construire cette URL nous-même, en étudiant bien la doc de chaque API, et obtenir la réponse à travers la commande httr::GET() qui permet de récupérer l’info correspondante par http.

La réponse obtenue (par exemple avec l’URL ci-dessus) ressemble généralement à quelque chose de ce genre:

{
   "results" : [
      {
         "address_components" : [
            {
               "long_name" : "Grande Rue de la Guillotière",
               "short_name" : "Grande Rue de la Guillotière",
               "types" : [ "route" ]
            },
            {
               "long_name" : "Lyon",
               "short_name" : "Lyon",
               "types" : [ "locality", "political" ]
            },
            {
               "long_name" : "Rhône",
               "short_name" : "Rhône",
               "types" : [ "administrative_area_level_2", "political" ]
            },
            {
               "long_name" : "Auvergne-Rhône-Alpes",
               "short_name" : "Auvergne-Rhône-Alpes",
               "types" : [ "administrative_area_level_1", "political" ]
            },
            {
               "long_name" : "France",
               "short_name" : "FR",
               "types" : [ "country", "political" ]
            }
         ],
         "formatted_address" : "Grande Rue de la Guillotière, Lyon, France",
         "geometry" : {
            "bounds" : {
               "northeast" : {
                  "lat" : 45.7553017,
                  "lng" : 4.8602422
               },
               "southwest" : {
                  "lat" : 45.7461895,
                  "lng" : 4.842601
               }
            },
            "location" : {
               "lat" : 45.7502745,
               "lng" : 4.8504236
            },
            "location_type" : "GEOMETRIC_CENTER",
            "viewport" : {
               "northeast" : {
                  "lat" : 45.7553017,
                  "lng" : 4.8602422
               },
               "southwest" : {
                  "lat" : 45.7461895,
                  "lng" : 4.842601
               }
            }
         },
         "place_id" : "ChIJefk7rWnq9EcRDacYDiq2NLA",
         "types" : [ "route" ]
      }
   ],
   "status" : "OK"
}

C’est un résultat qui correspond à un format json (on pourrait aussi l’avoir au format “list” R).

Il est ainsi possible de récupérer les éléments de réponse qui nous intéressent moyennant une petite “gymnastique” de manipulation de listes sous R.

Dans un cas (construction de l’URL) comme dans l’autre (récupération des données depuis la liste) néanmoins, cela exige un peu de travail.

C’est pour cela qu’il existe des API clients R, c’est-à-dire des packages qui visent à simplifier l’envoi de requêtes et la récupération de données pour les utilisateurs de R. La simplification intervient à deux niveaux:

pour construire l’URL, les paramètres sont passés (de manière classique pour des habitués de R) comme valeurs d’arguments des fonctions. Par ailleurs, il y a souvent eu un “écrémage” des paramètres possibles pour ne garder que les plus importants aux yeux des développeurs de ces packages.
les résultats sont formattés d’une manière allégée et simplifiée pour des utilisateurs de R (par exemple sous forme de tableau plutôt que sous forme de liste).

API clients opencage, mixr, tidygeocode

Je vais ici vous montrer les API clients

tidygeocoder (qui interroge l’API Nominatim (OSM))
opencage (qui interroge l’API Opencage)
mixr (qui interroge les API google et Opencage)

API OSM: package tidygeocoder

Comme son nom l’indique le package tidygeocoder a en entrée et en sortie des données sous forme tidy, il est donc particulièrement agréable à utiliser pour tous les aficionados du tidyverse.

Il peut aussi récupérer les données depuis l’API UScensus (sa source par défaut) mais pour des noms de lieu hors USA ce n’est évidemment pas indiqué… Je précise donc method="osm" dans l’appel à la fonction geocode() de tidygeocoder ci-dessous:

result_tidygeocoder=tidygeocoder::geocode(mydf,
                                          loc,
                                          method="osm")
result_tidygeocoder

## # A tibble: 7 x 3
##   loc                                    lat    long
##                                      
## 1 Lyon, France                          45.8    4.83
## 2 22 place du Général de Gaulle, Paris  NA     NA   
## 3 la Guillotière, Lyon                  45.8    4.84
## 4 Europe                                51     10   
## 5                                   NA     NA   
## 6 Tucson, AZ                            32.2 -111.  
## 7 Rio Grande do Sul                    -29.8  -53.8

On peut également récupérer plus d’infos que simplement celles de latitude-longitude. Pour cela, il faut préciser l’argument full_results=TRUE

result_tidygeocoder_full=tidygeocoder::geocode(mydf,
                                               loc,
                                               method="osm",
                                               full_results=TRUE)
colnames(result_tidygeocoder_full)

##  [1] "loc"          "lat"          "long"         "place_id"     "licence"      "osm_type"     "osm_id"       "boundingbox"  "display_name" "class"        "type"         "importance"   "icon"

Pour en savoir plus sur ce package vous pouvez consulter cette page

API Google/Opencage: package mixr

mixr, c’est un petit package “maison” que je me suis fait pour pouvoir réexploiter plus facilement un certain nombre de fonctions que je m’étais créées pour travailler avec des données Twitter. Il est encore en développement mais il est d’ores et déjà possible de l’installer depuis github ici si vous le souhaitez. En termes de géocodage, il permet de récupérer des données depuis l’API Google et depuis l’API Opencage.

Pour cette deuxième option (API Opencage) il s’appuie très largement sur un autre package R: opencage voir ici. Son avantage principal par rapport à la fonction opencage::opencage_forward() est qu’il permet de géocoder plusieurs noms de lieux à la fois. Il s’agit apparemment d’une chose que les développeurs d’opencage ont préféré ne pas implémenter directement pour diverses raisons, l’une d’entre elles étant que les utilisateurs risquaient d’utiliser le service de manière immodérée: j’ai donc fait en sorte que dans la fonction mixr::tidy_geocode(method="opencage") chaque envoi de requête prenne a minima 1 seconde…

Appel de la fonction tidy_geocode() pour l’API Google:

result_mixr_google=mixr::tidy_geocode(mydf,
                                      location=loc,
                                      method="google",
                                      info=c("lat","lng","country"))
result_mixr_google

## # A tibble: 7 x 4
##   stringlocation                         lat     lng country      
##                                               
## 1 Lyon, France                          45.8    4.84 France       
## 2 22 place du Général de Gaulle, Paris  48.9    2.43 France       
## 3 la Guillotière, Lyon                  45.8    4.84 France       
## 4 Europe                                54.5   15.3           
## 5                                   NA     NA             
## 6 Tucson, AZ                            32.2 -111.   United States
## 7 Rio Grande do Sul                    -30.0  -51.2  Brazil

Appel de la fonction tidy_geocode() pour l’API Opencage:

result_mixr_opencage=mixr::tidy_geocode(mydf,
                                        location=loc,
                                        method="opencage",
                               info=c("lat","lng","components.country_code"))

## Warning: `tbl_df()` is deprecated as of dplyr 1.0.0.
## Please use `tibble::as_tibble()` instead.
## This warning is displayed once every 8 hours.
## Call `lifecycle::last_warnings()` to see where this warning was generated.

result_mixr_opencage

## # A tibble: 37 x 4
##    stringlocation   lat     lng components.country_code
##                                    
##  1 Lyon, France    45.8  4.83   fr                     
##  2 Lyon, France    45.7  4.74   fr                     
##  3 Lyon, France    44.1  0.0135 fr                     
##  4 Lyon, France    46.6 -1.38   fr                     
##  5 Lyon, France    46.5 -1.34   fr                     
##  6 Lyon, France    45.7  4.74   fr                     
##  7 Lyon, France    46.7 -1.25   fr                     
##  8 Lyon, France    48.9  2.32   fr                     
##  9 Lyon, France    45.7  4.83   fr                     
## 10 Lyon, France    50.5  2.50   fr                     
## # … with 27 more rows

Pour l’une comme pour l’autre, vous pouvez consulter l’aide des fonctions pour voir quelles sont les infos que vous pouvez espérer obtenir…

Citation

Merci de citer ce billet de la manière suivante:

Vaudor L (2020). “Géocodage sous R via une API.” R-atique: Analyse de données avec R. http://perso.ens-lyon.fr/lise.vaudor/geocodage-sous-r-via-une-api/>.

(???){vaudor_geocodage, author = {Lise Vaudor}, title = {Géocodage sous R via une API}, month = {nov}, year = {2020}, journal = {R-atique: Analyse de données avec R}, type = {blog}, url = {http://perso.ens-lyon.fr/lise.vaudor/geocodage-sous-r-via-une-api/}, }

Utiliser un package

lvaudor — Wed, 07 Oct 2020 09:13:19 +0000

Qu’est-ce qu’un package ?

Un package est un ensemble de fonctions documentées visant à la réalisation d’une tâche particulière.

En poursuivant cette série de tutoriels vous serez notamment amenés à travailler avec le package dplyr qui vise à réaliser un ensemble d’opérations et de manipulations de base sur les tableaux de données, et le package ggplot2 qui vise à produire des graphiques en s’appuyant sur les principes de la grammaire des graphiques.

Installation vs chargement

INSTALLATION

L’installation d’un package consiste à télécharger les codes du package sur l’ordi.

Cette étape nécessite que vous téléchargiez l’ensemble des fichiers contenant le code du package sur votre ordi. De ce fait, c’est une étape qui nécessite que vous ayiez accès à internet… Par contre, vous n’avez besoin de réaliser cette installation une seule fois (tant que vous ne changez pas d’ordi, ou que vous n’avez pas besoin de mettre à jour le package par exemple).

Installer un package, c’est un peu comme ramener le carton d’outils de cuisine chez soi et les ranger dans le placard, cf illustration ci-dessous…

L’installation d’un package se fait généralement à l’aide de la commande:

install.packages("dplyr")

Vous pouvez également effectuer cette installation à partir de l’outil “Packages” dans RStudio.

CHARGEMENT

Le chargement consiste à préparer R à l’utilisation des fonctions du package (en les appelant par leur nom).

A chaque fois (ou presque) que vous utiliserez un package (i.e. pour chacune de vos sessions de travail avec ce package), vous aurez besoin de le charger. Le chargement d’un package permet en effet à R d’ajouter les noms de ses fonctions à son “répertoire” et donc d’aller chercher le code correspondant où il se doit.

Charger un package, c’est un peu l’équivalent de sortir les outils du placard de sorte qu’ils soient prêts à servir… cf illustration ci-dessous.

Vous pouvez charger un package de la manière suivante:

library(dplyr)

Espace de nommage, désambiguation

Chaque package est associé à un espace de noms (namespace) qui correspond à l’ensemble des noms de fonctions qui le composent.

Un même nom peut correspondre à plusieurs fonctions, issues de packages différents.

Si ces packages sont installés et chargés pour une même session de travail, il est recommandé (voire indispensable) d’écrire explicitement à quel espace de noms on fait référence à l’aide de la notation nomdupackage::nomdelafonction…

library(stats)
library(dplyr)

## 
## Attaching package: 'dplyr'

## The following objects are masked from 'package:stats':
## 
##     filter, lag

## The following objects are masked from 'package:base':
## 
##     intersect, setdiff, setequal, union

starwars %>% filter(starwars,species=="Human")

## Error: Problem with `filter()` input `..1`.
## x Input `..1$name` must be a logical vector, not a character.
## ℹ Input `..1` is `starwars`.

Vie et maintien d’un package

Un package n’est pas définitivement figé au moment de sa création (ou de son dépôt sur le CRAN par exemple).

Il est amené à évoluer, en lien avec, par exemple, les demandes des utilisateurs, les ajouts ou modifications des contributeurs, les modifications rendues nécessaires par les changements de version des autres packages (dont il dépend) ou de R lui-même.

En effet, un package est construit sur la base de codes R préexistants, mais également en se basant sur des packages, basés sur des packages, basés sur des packages… Ces packages constituent ce qu’on appelle les dépendances.

Qualité d’un package

La “qualité” d’un package peut recouvrir de nombreuses notions, parmi lesquelles:

le fait que le code fonctionne, et soit robuste (à de légers changements dans les types de données entrées par exemple).
le fait que le code soit bien documenté, de sorte que l’utilisateur comprenne comment utiliser une fonction et à quoi correspond le résultat en sortie.
le fait que les traitements réalisés soient corrects (par exemple qu’un algorithme soit juste, qu’un test soit correct d’un point de vue statistique etc.) et corresponde bien au résultat escompté par l’utilisateur.

Qualité du code => qualité du matériel, de l’instrumentation
Qualité de la méthode => on obtient bien le produit escompté
Qualité de la doc => les instructions sont claires!

Des fonctions, de la documentation

Pour obtenir de l’aide sur une fonction (installée, peut-être non chargée):

??nomfonction

Pour obtenir de l’aide sur une fonction (installée et chargée):

?nomfonction
help(nomfonction)

Pour obtenir la liste de la doc relative à un package:

help(package="dplyr")

=> liste des fonctions, des vignettes, etc.

Documentation simplifiée: vignettes

Les vignettes sont des documents qui aident à prendre en main un package en identifiant ses fonctions les plus importantes, et en montrant un ou plusieurs cas d’usage.

Tous les packages ne font pas (hélas!) l’objet de vignettes!…

Pour lister les vignettes relatives à un package (par ex. dplyr):

vignette(package="dplyr")

Vignettes in package ‘dplyr’:

colwise                colwise (source, html)
compatibility          dplyr compatibility (source, html)
base                   From base R to dplyr (source, html)
grouping               Grouped data (source, html)
dplyr                  Introduction to dplyr (source, html)
programming            Programming with dplyr (source, html)
rowwise                rowwise (source, html)
two-table              Two-table verbs (source, html)
window-functions       Window functions (source, html)

Pour visualiser une vignette donnée:

vignette("colwise", package="dplyr") # dans RStudio
RShowDoc("colwise", package="dplyr") # dans le navigateur web

Les cheatsheets (ou antisèches) sont des documents visant à résumer de manière graphique la fonction et l’usage d’un package.

Tous les packages ne font pas (hélas, encore!) l’objet d’une cheatsheet. Les plus utiles sont listées ici:

(https://rstudio.com/resources/cheatsheets/)

Des problèmes d’installation?

Ce n’est pas parce que vous avez des messages/ des warnings/ du rouge dans votre console que vous avez eu un problème d’installation…

La preuve:

Le package a bien été installé!

Par contre, là, oui, l’installation n’a pas pu aboutir:

Ici en l’occurrence, j’ai besoin d’installer magick sur ma machine (en dehors de R) avant d’installer le package R magick…

Parmi les problèmes classiques (et faciles à résoudre) qu’on peut rencontrer lors de l’installation, on peut citer:

l’absence de connection internet
l’absence de guillemets autour du nom de package dans l’appel à la fonction install.packages() (eh oui des fois ça coince pour des bêtises…)
une mauvaise orthographe du nom de package

Illustration:

install.packages("dplyr") #j'ai coupé internet

## Installing package into '/home/lvaudor/R/x86_64-pc-linux-gnu-library/3.6'
## (as 'lib' is unspecified)

install.packages(dplyr)

## Error in install.packages(dplyr): objet 'dplyr' introuvable

install.packages("deplyr")

## Installing package into '/home/lvaudor/R/x86_64-pc-linux-gnu-library/3.6'
## (as 'lib' is unspecified)

## Warning: package 'deplyr' is not available (for R version 3.6.3)

Les problèmes d’installation sont relativement souvent liés à un problème dans l’installation des dépendances:

Dans ce cas cela peut être une bonne idée d’installer la dépendance “qui coince” en premier (dans l’exemple ci-dessus xml2), puis retenter l’installation du package…

Janitor: nettoie-moi cette table (et qu’elle brille!)

lvaudor — Thu, 11 Jun 2020 16:33:21 +0000

Chers lecteurs, bonjour!

Aujourd’hui, je vais vous parler du package janitor, un package qui comprend notamment (mais pas seulement) un certain nombre de fonctions pour améliorer vos tableaux de contingence. En Anglais, “janitor” veut dire (plus ou moins) “homme à tout faire”. Et en effet, outre les tâches liées à la mise en forme de ces tableaux, le package janitor vise à prendre en charge pour vous un certain nombre de tâches aussi variées que pénibles…

Jetons un coup d’oeil à l’ensemble des fonctions comprises dans ce package (je fais ça à l’aide de mon package flowrpowr (http://perso.ens-lyon.fr/lise.vaudor/certains-packages-sont-comme-des-fleurs/):

library(janitor)
library(flowrpowr)
flowrpowr::flowr_package("janitor")

Opérations sur les tables de contingences

Les éléments apparaissant ci-dessous sont ceux relatifs aux tables de contingence (fonctions tabyl et consorts, fonctions de type adorn_xxx() –adorn_title(),adorn_ns(),adorn_rounding(),etc.-). Les autres fonctions sont toutes celles qui réalisent des opérations sur les données (en général, mais pas seulement, en lien avec le nettoyage de tableaux).

flowrpowr::flowr_package("janitor", element=c("adorn","tabyl"))

La fonction tabyl() est, en quelque sorte, l’équivalent (amélioré) de la fonction table(), qui compte des effectifs par classe. Mais là où table() travaille sur des vecteurs (ou facteurs), tabyl() prend pour premier argument un tableau de données. C’est peut-être un détail pour vous, mais en fait ça veut dire beaucoup: c’est le signe que le package janitor est “pipe-compatible” (et donc “dplyr-compatible”) (puisque le premier argument des fonctions est un jeu de données, on peut enchaîner les opérations à l’aide des “pipes” %>%).

Voyez plutôt:

tabyl(mtcars,cyl)  # en appel "classique"

##  cyl  n percent
##    4 11 0.34375
##    6  7 0.21875
##    8 14 0.43750

mtcars %>%
  tabyl(cyl) # en appel "pipé"

##  cyl  n percent
##    4 11 0.34375
##    6  7 0.21875
##    8 14 0.43750

Remarquez en outre que, pour une variable, tabyl() vous affiche diligemment les proportions (percent) en plus des effectifs (n).

Comme table(), tabyl() sait aussi compter des effectifs croisés:

mtcars %>% 
  tabyl(cyl,am)

##  cyl  0 1
##    4  3 8
##    6  4 3
##    8 12 2

L’ensemble des fonctions adorn_xxx() vise à mettre en forme les tableaux d’effectifs produits par tabyl().

On peut par exemple rajouter une colonne correspondant aux effectifs totaux:

tab=mtcars %>%
  tabyl(gear, cyl) %>%
  adorn_totals("col")
tab

##  gear 4 6  8 Total
##     3 1 2 12    15
##     4 8 4  0    12
##     5 2 1  2     5

On peut afficher les pourcentages plutôt que les effectifs (ici pourcentages par ligne)

tab=tab %>%
  adorn_percentages("row")
tab

##  gear          4         6   8 Total
##     3 0.06666667 0.1333333 0.8     1
##     4 0.66666667 0.3333333 0.0     1
##     5 0.40000000 0.2000000 0.4     1

On peut limiter le nombre de digits dans l’affichage:

tab=tab %>% 
  adorn_pct_formatting(digits=2)
tab

##  gear      4      6      8   Total
##     3  6.67% 13.33% 80.00% 100.00%
##     4 66.67% 33.33%  0.00% 100.00%
##     5 40.00% 20.00% 40.00% 100.00%

On peut afficher, en plus des pourcentages, les effectifs:

tab=tab %>% 
  adorn_ns()
tab

##  gear          4          6           8        Total
##     3  6.67% (1) 13.33% (2) 80.00% (12) 100.00% (15)
##     4 66.67% (8) 33.33% (4)  0.00%  (0) 100.00% (12)
##     5 40.00% (2) 20.00% (1) 40.00%  (2) 100.00%  (5)

On peut rajouter le nom de la deuxième variable:

tab=tab %>% 
  adorn_title()
tab

##              cyl                                    
##  gear          4          6           8        Total
##     3  6.67% (1) 13.33% (2) 80.00% (12) 100.00% (15)
##     4 66.67% (8) 33.33% (4)  0.00%  (0) 100.00% (12)
##     5 40.00% (2) 20.00% (1) 40.00%  (2) 100.00%  (5)

Pour en savoir plus sur les fonctionnalités des “tabyls”, vous pouvez aller voir la vignette fournie par les auteurs de janitor (vous pouvez l’ouvrir en faisant vignette("tabyls") dans votre console une fois que vous avez installé le package).

Nettoyage de tableaux de données

Je ne vais pas aborder l’ensemble des autres fonctions de janitor, mais, pour aller à l’essentiel, disons que ces fonctions réalisent quelques tâches “de routine” pour nettoyer les tableaux de données. Par exemple:

flowrpowr::flowr_package("janitor",element=c("compare|remove|clean|^round"))

les fonctions remove_xxx() retirent les colonnes qui contiennent une valeur constante (remove_constant()), ou les colonnes ou lignes complètement vides (remove_empty_cols(),remove_empty_rows())
les fonctions compare_df_cols...() comparent les colonnes de deux tableaux (compare_df_cols()) et déterminent si, en l’état ils peuvent être “recollés” en semble par une opération de type bind_rows() ou rbind() (compare_df_cols_same())

-les fonctions round_xxx() constituent des améliorations de la fonction round() consistant à arrondir de manière systématique vers le haut les valeurs (round_half_up()) ou à arrondir à une fraction près (round_to_fraction())

les fonctions ...clean_names() permettent de nettoyer des noms (make_clean_names()) et notamment les noms de colonnes des tableaux (clean_names()). C’est, je pense, cette fonction clean_names() que j’utilise le plus fréquemment dans le package janitor. Si vous aussi vous êtes amenés à travailler avec des tableaux dont les noms de colonnes sont à coucher dehors, vous comprendrez pourquoi… Admirez plutôt:

tib=tibble("TempérDegCelsius"=NA,
       "précipit (mm/24h)"=NA,
       "succès_prob(%)"=NA,
       "Fiabilité.Estim"=NA) 
tib

## # A tibble: 1 x 4
##   TempérDegCelsius `précipit (mm/24h)` `succès_prob(%)` Fiabilité.Estim
##                                                    
## 1 NA               NA                  NA               NA

tib %>% clean_names()

## # A tibble: 1 x 4
##   temper_deg_celsius precipit_mm_24h succes_prob_percent fiabilite_estim
##                                                     
## 1 NA                 NA              NA                  NA

A partir de noms de colonnes très hétérogènes et comprenant un certain nombre de caractères spéciaux, la fonction clean_names() produit des noms homogènes et commodes à utiliser dans R. Par défaut, la casse est de type “serpent” (case="snake"): tous les mots sont écrits en minuscule, séparés par un underscore _. Alternativement, et si telle est votre habitude, vous pouvez demander à ce que vos noms de variables soient en casse “petit chameau”, “grand chameau” ou “serpent criard”, etc., etc. (j’adore ces dénominations :-)…).

tib %>% clean_names(case="small_camel")

## # A tibble: 1 x 4
##   temperDegCelsius precipitMm24H succesProbPercent fiabiliteEstim
##                                              
## 1 NA               NA            NA                NA

tib %>% clean_names(case="big_camel")

## # A tibble: 1 x 4
##   TemperDegCelsius PrecipitMm24H SuccesProbPercent FiabiliteEstim
##                                              
## 1 NA               NA            NA                NA

tib %>% clean_names(case="screaming_snake")

## # A tibble: 1 x 4
##   TEMPER_DEG_CELSIUS PRECIPIT_MM_24H SUCCES_PROB_PERCENT FIABILITE_ESTIM
##                                                     
## 1 NA                 NA              NA                  NA

Citation

Merci de citer ce billet de la manière suivante:

## Vaudor L (2020). "Janitor: nettoie-moi cette table (et qu'elle brille!)." _R-atique: Analyse de données avec R_. .

## @Misc{vaudor_janitor,
##   author = {Lise Vaudor},
##   title = {Janitor: nettoie-moi cette table (et qu'elle brille!)},
##   month = {jun},
##   year = {2020},
##   journal = {R-atique: Analyse de donnÃ©es avec R},
##   type = {blog},
##   url = {http://perso.ens-lyon.fr/lise.vaudor/janitor-nettoie-moi-cette-table-et-que-ca-brille/},
## }

Jamais sans ces packages!

lvaudor — Wed, 11 Mar 2020 08:46:28 +0000

Quand quelqu’un vient me demander des conseils pour débuter, ou effectuer une tâche particulière sous R, une des premières choses que je fais (outre lui conseiller la lecture de mon blog, bien sûr -rire machiavélique-) est de l’aiguiller sur quelques packages que je juge incontournables. En effet, s’il existe des points d’entrée plus généraux dans l’usage de R, avoir quelques points de repère quant aux packages qui simplifient vraiment son usage permet de gagner du temps dans son apprentissage en limitant l’étendue des possibles (dans un premier temps tout du moins!).

A toutes fins utiles, donc, voici la liste de mes incontournables. Il va sans dire que c’est une liste qui est susceptible d’évoluer, non seulement au gré de mes apprentissages, mais aussi au gré des développements de R! D’ailleurs, si vous avez vous-même des packages chouchous que vous n’y voyez pas, n’hésitez pas à me l’indiquer en commentaire!!

Manipulation de données

`dplyr`: manipulation des tableaux de données

Je l’utilise pour tout ce qui est opération sur les tableaux (c’est-à-dire, tout le temps: quel que soit la nature de mon projet, il implique, à un moment ou un autre, de manipuler un tableau). D’ailleurs, j’avais déjà écrit un billet sur ce package ici (sélectionner des colonnes, filtrer des lignes, faire des tris, faire des regroupements) et là (réaliser des jointures).

`tidyr`: restructuration des tableaux de données

J’utilise tidyr de manière moins systématique, mais il réapparaît tout de même assez régulièrement dans mes scripts pour deux raisons en particulier:

les pivots, réalisés à l’aide des fonctions gather() et spread() (désormais remplacées par les plus explicites pivot_longer() et pivot_wider(), respectivement) pour modifier la structure des données. J’avais écrit un paragraphe sur ces fonctions à la fin de ce billet. Vous pouvez aller voir le très bon billet de ThinkR sur le sujet ici.
les fonctions nest() et unnest() pour créer des listes-colonnes de jeux de données (une fonctionnalité que j’utilise souvent en conjonction avec le package purrr et la programmation fonctionnelle)

`readr`: lecture des tableaux de données

Pour lire des tableaux de données depuis des fichiers .csv ou .txt, j’utilise le plus souvent le package readr. Pour vous dire toute la vérité, même: la plupart du temps, si je constate que le fichier que j’essaie d’importer est un peu “spécial”, j’utilise la fonctionnalité “Import Dataset” de RStudio pour explorer les options et me générer la ligne de commande ad hoc (“bouh! la tricheuse!” entends-je certains se récrier dans l’audience), et c’est cette fonctionnalité qui (le plus souvent) me suggère l’usage de readr…

Manipulation de données particulières

`stringr`: Manipulation de chaînes de caractères

Pour tout ce qui est manipulation de chaînes de caractères (qui vont au-delà de paste0()), j’utilise le package stringr. J’avais déjà écrit un billet de blog sur ce package ici ainsi qu’un billet le complétant sur le sujet des expressions régulières ici.

`tidytext` pour le traitement du langage naturel

Pour traiter du langage naturel (des phrases, des paragraphes, des tweets, etc.) dans des traitements de type lexicométrie, j’utilise le package tidytext. J’y ai consacré un petit paragraphe du “Descriptoire” (un livre en ligne traitant de l’analyse de textes avec R) mais si vous n’avez rien contre une ressource anglophone, les vignettes associées au package (et notamment l’introduction) sont très très bien faites…

`lubridate`: opérations sur des dates, temps, heures

Ce package permet de gérer (sans trop transpirer) toutes les opérations sur les données de type date, heure, temps, etc. (Lecture, conversion, arrondis, séquences de dates, opérations de type addition-soustraction, etc.). J’ai écrit un billet sur ce sujet ici.

`forcats`: opérations sur les facteurs (variables catégorielles)

Pour travailler avec les variables catégorielles et notamment pour modifier les noms des différents niveaux (c’est peut-être un détail pour vous, mais pour moi ça veut dire beaucoup), j’utilise forcats. Voici le billet que j’avais écrit à ce sujet.

Graphiques

`ggplot2` : réalisation des graphiques

Pour la réalisation des graphiques, bien sûr, je ne jure plus que par ggplot2. J’avais écrit (cela commence à faire un moment) un billet sur le sujet. En plus récent et plus complet, il y a aussi un de mes supports de cours ici, ici, et là.

`patchwork`: combinaison de graphiques

Pour combiner plusieurs graphiques en… patchworks, plus ou moins complexes, selon une syntaxe très intuitive (voir la vignette ici).

Données géographiques et cartographie

`sf` : données géographiques vectorielles

Pour tout ce qui est manipulation de données géographiques de type données vectorielles, le package sf est non seulement une mine d’or mais il est en plus tidyverse-friendly, c’est-à-dire qu’il fonctionne bien, notamment, avec les packages dplyr et ggplot2… J’ai un (très succinct) support de cours à son sujet ici. En plus détaillé, vous pouvez aller jeter un coup d’oeil à cet article de StatnMap sur le sujet!

`raster` : données raster, grid

C’est (comme son nom l’indique) le package incontournable pour travailler avec des données de type raster (ou grid). Il est un peu plus ancien que sf et de ce fait les opérations croisant données raster et vectorielles qu’il propose sont plutôt compatibles avec le package sp (le prédecesseur de sf).

`tmap`: réalisation de cartes

C’est un package qui permet de réaliser des cartes qui sont, au choix, statiques ou interactives. C’est aussi un package qui s’inscrit dans la logique “tidyverse” (malgré quelques différences de syntaxe par rapport à ggplot2). C’est de ce fait le package de cartographie que j’en suis venue à privilégier (parmi de nombreux choix possibles). Cependant, il m’arrive encore de faire appel à d’autres packages (comme leaflet par exemple) quand tmap ne répond pas à un besoin particulier. Par exemple, l’intégration d’une carte produite par tmap dans une appli shiny requiert l’utilisation de commandes que je ne comprends pas trop (mais que je suis malgré tout en mesure d’utiliser, par la grâce de Stack Overflow et du copier-coller ;-)). Or utiliser des choses sans les comprendre, cela me gêne un peu dans certains contextes (par exemple, quand je donne cours!).

Rapports et applications

J’aime partager le fruit de mon dur labeur dans des documents et applications qui permettent à mes interlocuteurs d’explorer les données/rendus/résultats des modèles de manière documentée, explicitée, et parfois interactive… Voilà les outils que j’utilise:

`rmarkdown` et `knitr`: rapports tricotés

Pour produire des rapports (c’est-à-dire des documents mêlant un plan, du code R, du texte, des résultats issus de R, des graphiques, etc.), j’utilise les packages rmarkdown et knitr… Vous pouvez consulter ce tutoriel de Claire Della Vedova pour vous aider à vous lancer…

`shiny`: applications interactives

Pour construire des applications, bien sûr, shiny est le must… Il y a beaucoup de tutos en ligne (à vous de choisir, selon vos préférences, un tuto anglophone/francophone/autre, un support sous forme de video/document/exercices en ligne…), mais à toutes fins utiles, j’ai moi-même un petit support de cours disponible ici -je m’en sers pour donner cours “en vrai” donc c’est plus un aide-mémoire qu’un guide de démarrage, réellement-…

Pour l’instant en tant que “développeuse shiny occasionnelle” je m’en tiens essentiellement à shiny (avec quelquefois quelques additions par exemple colourpicker qui propose un widget pour choisir une couleur) mais je suis très intéressée par le package golem de ThinkR qui permet de modulariser les applis (car, oui, une appli, ça peut vite devenir gros, compliqué et bordélique) et que j’aimerais bien incorporer à mon “workflow” la prochaine fois que j’aurai l’occasion de développer une appli shiny… En plus, chouette, ils ont plein de doc pour s’y mettre…

Itérations

Je ne sais pas trop dans quelle rubrique classer purrr, mais il figure parmi mes nouveaux incontournables depuis maintenant 2 ou 3 ans. J’avais écrit un billet à ce sujet ici De fait, quand on travaille très régulièrement avec dplyr (et des “tibbles”), l’usage de purrr pour remplacer les traditionnelles boucles for est le bienvenu… L’usage de purrr s’accompagne aussi d’un changement de pratiques pour moi puisque j’en viens de plus en plus à écrire mon code “en fonctions”!…

Graphes

Pour analyser des réseaux et produire des graphes (attention, j’ai bien dit graphes, et non graphiques!) j’utilise deux packages de Thomas Lin Pederson:

`tidygraph` : description et analyse de réseaux

J’en parle succinctement dans ce billet(en promettant un article très prochainement. C’était il y a six mois. Gloups.): tidygraph permet de traiter des données en réseau (qui sont par conséquent structurés d’une manière différente des données “tidy” telles qu’on les connaît, où une ligne=un individu et une colonne=une variable). Ce package s’inscrit très largement dans les principes et la syntaxe du tidyverse.

`ggraph` : représentation de réseaux en graphes

J’en parle dans ce billet. Ce package permet de représenter des réseaux en graphe en reprenant les principes et les éléments de syntaxe de ggplot2.

Analyses factorielles

Entre FactoMineR et ade4, mon coeur balance… Pourtant, j’aimerais bien être en mesure de trancher une fois pour toute, car pour moi, utiliser deux packages qui font “un peu la même chose mais pas exactement”, ça veut dire que je n’arrive jamais à me rappeler les commandes ni de l’un ni de l’autre.

Cependant, je pense que je n’arriverai jamais à trancher, car si je trouve FactoMineR un peu plus clair, je trouve aussi ade4 un peu plus complet. Quelque part, on retrouve la “patte” des disciplines qui les a vus émerger: plus agronomique (culture méthodique et maîtrisée) côté FactoMineR, plus écologique (écosystème foisonnant et en évolution) côté ade4… (Que les auteurs de ces packages me pardonnent ces clichés, c’est juste comme ça que je m’explique mon “feeling” vis-à-vis de l’un ou de l’autre ). D’ailleurs, j’ai fait mes études dans une école d’ingénieur agronome, et mon doctorat dans un laboratoire d’écologie, et vous comprendrez donc pourquoi, même d’un point de vue disciplinaire, j’ai du mal à faire mon choix entre ces deux packages…

Analyse multi-résolution d’une série à travers les ondelettes discrètes

lvaudor — Wed, 27 Nov 2019 15:20:24 +0000

Aïe aïe aïe!! Quelle prise de tête que les transformées d’ondelettes quand on n’est pas très matheux… Comprendre de A à Z comment elles fonctionnent, en déroulant tout le raisonnement de la définition d’une ondelette à l’interprétation finale de la transformée, c’est long, c’est compliqué, c’est même parfois impossible si on ne peut pas se lancer à corps perdu dans le sujet…

Ici, je pars du principe que vous non plus, vous n’êtes pas forcément prêts à faire le grand saut… alors je vais vous présenter une méthode liée aux transformées d’ondelettes discrètes, dite Analyse Multi-Résolution (MRA en anglais) en me concentrant sur le résultat plutôt que sur la méthode. J’ai tout un tas de supports éparpillés sur la méthode en question donc il n’est pas exclu que je me fende un jour d’un bon gros billet avec tout plein d’équations sur le sujet mais je ne voudrais pas vous faire peur d’emblée :-)…

Notez que dans cette même démarche (de démocratisation des ondelettes) j’ai également mis en ligne une appli permettant de tester tout un tas de méthodes d’analyse du signal par les ondelettes (ondelettes discrètes ou continues).

Les ondelettes discrètes, pour quoi faire?

Les transformées d’ondelettes peuvent servir à débruiter, filtrer, compresser, décomposer le signal et/ou sa variance en dissociant ses composantes à diverses échelles.

Pour ma part, je ne m’intéresse pas ces transformées pour la compression du signal mais plutôt à leur usage pour l’analyse de séries. Par ailleurs, je vais ici me concentrer sur l’analyse de séries (temporelles ou spatiales) 1D, excluant de ce fait l’analyse d’images (2D) de mon propos.

J’aimerais commencer en montrant rapidement ce que l’on peut réaliser à travers les transformées d’ondelettes. Considérons le signal suivant, qui correspond à une série de températures relevées à la station météo de Lyon Saint-Exupéry (température moyenne journalière, données disponibles sur ce site et que je vous remets ici. On devine dans ce signal une forte composante saisonnière (échelle temporelle “moyenne”), à laquelle se rajoute du “bruit” (échelle temporelle fine), et, peut-être, une tendance de fond (échelle temporelle longue) à l’augmentation de la température moyenne (on verra si nos analyses le confirment!). De fait, j’ai choisi ces données car elles se prêtent tout naturellement à une analyse multi-résolution!!

library(tidyverse)
data_ex=read.delim(paste0(dat.path,"TG_STAID000037.txt"),
                   sep=",", skip=20, na=-9999)%>% 
  mutate(x=lubridate::ymd(DATE),
         y=TG/10) %>% 
  group_by(x) %>% 
  summarise(y=mean(y)) %>% 
  na.omit()
ggplot(data_ex,aes(x=x,y=y))+
  geom_line(col="dark grey")

La décomposition en ondelettes discrètes permet de réaliser une analyse multi-résolution (MRA) du signal. Je passe pour l’instant sur le code qui permet de réaliser les graphiques suivants… mais j’y reviendrai! C’est à dire que l’on va pouvoir décomposer le signal en différentes composantes, qui correspondent à des échelles plus ou moins fines, et que cette décomposition aura l’intérêt d’être additive.

Si l’on considère la façon dont le signal est décomposé, étape par étape, on peut écrire les équations suivantes:

$$ \begin{aligned} Y &= & & & & & & & &S1 &+ &D1\ &= & & & & & &S2 &+ &D2 &+ &D1\ &= & & & &S3 &+ &D3 &+ &D2 &+ &D1\ &= & & S4 &+ &D4 &+ &D3 &+ &D2 &+ &D1\ etc. \end{aligned} $$

D’abord, Y est décomposé à très petite échelle en un signal de “détail” (D1) et un signal lissé –“smooth”– (S1).
Puis ce signal lissé à très petite échelle peut être lissé à une échelle un peu moins petite en un nouveau “smooth” (S2) et un nouveau “detail” (D2): S1 = S2 + D2.
A nouveau, on peut lisser ce smooth une échelle un peu plus grande pour produire un nouveau smooth (S3) et un nouveau détail (D3): S2 = D3 + S3
etc.

A la fin, on arrive toujours à une somme de sous-signaux égale au signal de départ, chaque sous-signal nous informant sur la variation à une échelle donnée, de manière non redondante par rapport aux autres sous-signaux.

Voyez à quoi la “pyramide” d’équations ci-dessus correspond en terme de représentation des variations du signal (j’ai représenté les séries verticalement pour une meilleure lisibilité):

Il est en fait possible de lisser encore et encore ce signal, jusqu’à arriver à un smooth qui nous montre la tendance de fond. Ci-dessus je me suis arrêtée au niveau 4 car d’un point de vue graphique 4 niveaux de décomposition étaient déjà assez lourds…

Cela étant, rien ne nous empêche de regrouper certains sous-signaux… Par exemple, on peut essayer de distinguer une composante plutôt saisonnière (S4) au sein des variations journalières:

Y = S4 + (D4 + D3 + D2 + D1)

Ainsi, en poussant la décomposition plus loin, et en regroupant un certain nombre de niveaux, on peut essayer d’isoler une tendance de fond:

Y = S10 + (D10 + … + D5) + (D4 + … + D1)

Bingo! L’examen des graphiques ci-dessus révèle par exemple:

qu’il y a bien une tendance à l’augmentation de la température depuis 1975 (on ne nous aurait donc pas menti! :-p).
il y a eu quelques années particulièrement froides dans la deuxième moitié des années 80 (on le voit sur S10) et en particulier un hiver 85 particulièrement rigoureux (on le voit sur D10+….+D5)
on remarque les épisodes de canicule dans leur effet sur la composante saisonnière (D10+…+D4): voyez par exemple la canicule 2003 marquée par un pic plus marqué que les autres…

Comment faire, sous R?

Pour réaliser les transformées d’ondelettes discrètes sous R j’utilise un package qui s’appelle wavelets. Comme à mon habitude, je vais aussi utiliser le tidyverse pour réaliser les quelques traitements supplémentaires dont j’aurai besoin (et patchwork pour organiser mes panneaux de graphiques!)

library(wavelets)
library(tidyverse)
library(patchwork)

Voilà comment je réalise mon analyse multi-résolution, à l’aide de la fonction mra() du package wavelets:

mymra=mra(X=data_ex$y, 
          n.levels=10,
          boundary="reflection")

Le premier argument X correspond au signal lui-même. Pour que la transformée d’ondelettes ait un sens, il faut que la série de données corresponde à des valeurs Y régulièrement espacées (ici dans le temps).
Le deuxième argument n.levels correspond au niveau maximal de décomposition (ce niveau maximal dépendra de la nature de l’ondelette et de la longueur de la série).
Le dernier argument boundary correspond à la méthode utilisée “au bord du signal” pour calculer les transformées d’ondelettes. En effet, pour calculer les coefficients d’ondelettes sur les bords du signal, on est obligés d’allonger artificiellement le signal. Les deux choix possibles sont “periodic” (on recycle le signal, du début à la fin) ou “reflection” (on retourne le signal, en miroir). Dans notre cas de séries de températures, l’existence d’une évolution entre le début et la fin du signal (augmentation graduelle de la température moyenne) rend la transformation “reflection” plus pertinente…

Examinons maintenant ce que nous retourne la fonction mra():

str(mymra)

## Formal class 'mra' [package "wavelets"] with 9 slots
##   ..@ D       :List of 10
##   .. ..$ D1 : num [1:32532, 1] 0.418 -1.058 0.292 0.332 -0.51 ...
##   .. ..$ D2 : num [1:32532, 1] -0.538 -0.396 -0.244 0.316 1.119 ...
##   .. ..$ D3 : num [1:32528, 1] 0.1031 -0.207 -0.5185 -0.3569 -0.0928 ...
##   .. ..$ D4 : num [1:32528, 1] 2.249 2 1.697 1.147 0.477 ...
##   .. ..$ D5 : num [1:32512, 1] 0.868 0.899 0.913 0.835 0.716 ...
##   .. ..$ D6 : num [1:32512, 1] 0.861 1.047 1.215 1.3 1.343 ...
##   .. ..$ D7 : num [1:32512, 1] -3.88 -3.89 -3.89 -3.84 -3.76 ...
##   .. ..$ D8 : num [1:32512, 1] -2.47 -2.6 -2.72 -2.8 -2.87 ...
##   .. ..$ D9 : num [1:32256, 1] -2.88 -2.94 -2.99 -3.02 -3.05 ...
##   .. ..$ D10: num [1:31744, 1] 0.62 0.622 0.624 0.625 0.626 ...
##   ..@ S       :List of 10
##   .. ..$ S1 : num [1:32532, 1] 13.8 14.3 14.7 15.2 15.7 ...
##   .. ..$ S2 : num [1:32532, 1] 14.3 14.7 15 14.9 14.6 ...
##   .. ..$ S3 : num [1:32528, 1] 14.5 14.4 14.2 13.8 13.2 ...
##   .. ..$ S4 : num [1:32528, 1] 12.2 12.4 12.5 12.6 12.7 ...
##   .. ..$ S5 : num [1:32512, 1] 12.9 13 13.1 13.2 13.3 ...
##   .. ..$ S6 : num [1:32512, 1] 12 12 11.9 11.9 11.9 ...
##   .. ..$ S7 : num [1:32512, 1] 15.9 15.8 15.8 15.7 15.7 ...
##   .. ..$ S8 : num [1:32512, 1] 18.4 18.4 18.5 18.5 18.6 ...
##   .. ..$ S9 : num [1:32256, 1] 11.5 11.5 11.5 11.5 11.5 ...
##   .. ..$ S10: num [1:31744, 1] 11.3 11.3 11.3 11.3 11.3 ...
##   ..@ filter  :Formal class 'wt.filter' [package "wavelets"] with 7 slots
##   .. .. ..@ L        : int 8
##   .. .. ..@ level    : int 1
##   .. .. ..@ h        : num [1:8] 0.0322 0.0126 -0.0992 -0.2979 0.8037 ...
##   .. .. ..@ g        : num [1:8] -0.0758 -0.0296 0.4976 0.8037 0.2979 ...
##   .. .. ..@ wt.class : chr "Least Asymmetric"
##   .. .. ..@ wt.name  : chr "la8"
##   .. .. ..@ transform: chr "dwt"
##   ..@ level   : int 10
##   ..@ boundary: chr "reflection"
##   ..@ series  : num [1:32532, 1] 14.2 13.2 15 15.5 15.2 14.4 12.3 11.7 15.2 16.4 ...
##   ..@ class.X : chr "numeric"
##   ..@ attr.X  : list()
##   ..@ method  : chr "dwt"

Cet objet comprend un slot “filter” qui nous renseigne sur la nature de l’ondelette utilisée (car il existe plusieurs ondelettes possibles)! Ici, comme nous n’avons rien précisé dans l’appel à la fonction mra(), c’est par défaut l’ondelette “Least Asymetric” de longueur 8 (“la8”) qui a été utilisée (mais bien sûr nous aurions pu explicitement demander qu’une autre ondelette soit utilisée en utilisant l’argument filter):

mymra@filter

## An object of class "wt.filter"
## Slot "L":
## [1] 8
## 
## Slot "level":
## [1] 1
## 
## Slot "h":
## [1]  0.03222310  0.01260397 -0.09921954 -0.29785780  0.80373875 -0.49761867 -0.02963553  0.07576571
## 
## Slot "g":
## [1] -0.07576571 -0.02963553  0.49761867  0.80373875  0.29785780 -0.09921954 -0.01260397  0.03222310
## 
## Slot "wt.class":
## [1] "Least Asymmetric"
## 
## Slot "wt.name":
## [1] "la8"
## 
## Slot "transform":
## [1] "dwt"

Outre des informations sur la méthode de calcul et la nature de l’ondelette (slot “filter”), l’objet mymra comprend l’ensemble des smooths et des details pour les 10 niveaux de décomposition demandés ici. On peut accéder à chacun de ces sous-signaux de la manière suivante:

mymra@D$D1[1:5]

## [1]  0.4177861 -1.0581337  0.2924646  0.3321684 -0.5095316

Cela étant, quand on travaille dans la logique “tidy”, on a très envie d’obtenir tous ces sous-signaux comme autant de colonnes d’une table. Pour faciliter cette transformation, j’ai écrit une petite fonction add_wav_data():

add_wav_data=function(mydata,mra_obj){
  n=nrow(mydata)
  cut_to_size=function(x,n){
    if(dim(x)[1]>n){
      x=x[1:n]
    }else{
      x=c(x,rep(NA,n-dim(x)[1]))
    }
    return(x)
    }
  if(class(mra_obj)=="mra"){
    S=mra_obj@S %>%
      purrr::map(cut_to_size,n) %>% 
      bind_cols() %>% 
      mutate_all(as.vector)
    D=mra_obj@D %>%
      purrr::map(cut_to_size,n) %>% 
      bind_cols() %>%
      mutate_all(as.vector)
    wav_data=bind_cols(S,D)
  }
  mydata=bind_cols(mydata,
                   wav_data)
  return(mydata)
}

data_ex_wav=add_wav_data(data_ex,mymra) 
str(data_ex_wav)

## Classes 'tbl_df', 'tbl' and 'data.frame':    16266 obs. of  22 variables:
##  $ x  : Date, format: "1975-04-20" "1975-04-21" "1975-04-22" "1975-04-23" ...
##  $ y  : num  14.2 13.2 15 15.5 15.2 14.4 12.3 11.7 15.2 16.4 ...
##  $ S1 : num  13.8 14.3 14.7 15.2 15.7 ...
##  $ S2 : num  14.3 14.7 15 14.9 14.6 ...
##  $ S3 : num  14.5 14.4 14.2 13.8 13.2 ...
##  $ S4 : num  12.2 12.4 12.5 12.6 12.7 ...
##  $ S5 : num  12.9 13 13.1 13.2 13.3 ...
##  $ S6 : num  12 12 11.9 11.9 11.9 ...
##  $ S7 : num  15.9 15.8 15.8 15.7 15.7 ...
##  $ S8 : num  18.4 18.4 18.5 18.5 18.6 ...
##  $ S9 : num  11.5 11.5 11.5 11.5 11.5 ...
##  $ S10: num  11.3 11.3 11.3 11.3 11.3 ...
##  $ D1 : num  0.418 -1.058 0.292 0.332 -0.51 ...
##  $ D2 : num  -0.538 -0.396 -0.244 0.316 1.119 ...
##  $ D3 : num  0.1031 -0.207 -0.5185 -0.3569 -0.0928 ...
##  $ D4 : num  2.249 2 1.697 1.147 0.477 ...
##  $ D5 : num  0.868 0.899 0.913 0.835 0.716 ...
##  $ D6 : num  0.861 1.047 1.215 1.3 1.343 ...
##  $ D7 : num  -3.88 -3.89 -3.89 -3.84 -3.76 ...
##  $ D8 : num  -2.47 -2.6 -2.72 -2.8 -2.87 ...
##  $ D9 : num  -2.88 -2.94 -2.99 -3.02 -3.05 ...
##  $ D10: num  0.62 0.622 0.624 0.625 0.626 ...
##  - attr(*, "na.action")= 'omit' Named int  1 2 3 4 5 6 7 8 9 10 ...
##   ..- attr(*, "names")= chr  "1" "2" "3" "4" ...

On est dès lors en mesure de faire notre petite tambouille (avec ggplot2, avec dplyr, etc.). Tenez, vérifions en deux coups de cuillère à pot que la décomposition du signal est bien additive:

data_ex_wav %>%
  mutate(somme=S10+D10+D9+D8+D7+D6+D5+D4+D3+D2+D1) %>% 
  select(y,somme) %>% 
  head(n=10)

## # A tibble: 10 x 2
##        y somme
##     
##  1  14.2  6.66
##  2  13.2  4.79
##  3  15    5.69
##  4  15.5  5.84
##  5  15.2  5.30
##  6  14.4  4.72
##  7  12.3  2.84
##  8  11.7  1.28
##  9  15.2  3.70
## 10  16.4  2.96

En outre, je peux utiliser ce tableau à ma guise pour réaliser un graphique montrant les composantes de mon choix:

pbase=ggplot(data_ex_wav,aes(x=x,y=y))
pY =pbase+
  geom_line(col="dark grey")+ggtitle("Y")
pDall=pbase +
  geom_line(aes(x=x,y=D4+D3+D2+D1),col="lightgreen")+
  ggtitle("D4+...+D1")
pDseason=pbase+
  geom_line(aes(x=x,y=D10+D9+D8+D7+D6+D5), col="slateblue")+
  ggtitle("D10+...+D5")
pTrend=pbase+
  geom_line(aes(x=x,y=S10),col="gold",size=2)+
  ggtitle("S10")
pY/pTrend/pDseason/pDall

Des graphes bien jolis

lvaudor — Tue, 15 Oct 2019 15:15:24 +0000

Dans ce billet, je vais me focaliser principalement sur ggraph, et j’essaierai de trouver le temps pour parler un peu plus en profondeur de tidygraph un peu plus tard dans un autre billet.

Données

Nous allons travailler sur cette table qui renseigne les noeuds de notre réseau, et cette autre table qui renseigne les liens.

nodes=read_csv("../../lise.vaudor/Rdata/Graphes_et_tidyverse_ggraph/vertices.csv")
edges=read_csv("../../lise.vaudor/Rdata/Graphes_et_tidyverse_ggraph/edges.csv")

Pour aujourd’hui, je vais utiliser une fonction de tidygraph (tbl_graph()) pour former à partir de ces deux tables un objet de type graphe (et même, plus précisément, de classe “tbl_graph”). Je passe rapidement sur cette étape, car j’y reviendrai très bientôt dans un autre billet…

tib_g=tidygraph::tbl_graph(nodes=nodes,edges=edges)

De la même manière qu’avec la fonction ggplot() du package ggplot2, je crée ma première “couche” avec la fonction ggraph() du package ggraph:

g=tib_g %>% 
   ggraph(layout="auto")

Pour l’instant, il n’y a rien à voir… mais je vais ensuite pouvoir exploiter les possibilités de ggraph pour la représentation des noeuds et des liens.

Représentation des noeuds

D’abord, voici les possibilités pour les noeuds:

flowrpowr::flowr_package("ggraph",element="geom_node", layout="sugiyama")

Toutes n’ont pas forcément un intérêt dans notre cas (c’est fonction de la structure de notre graphe) donc je ne les testerai pas toutes, mais en voici quelques-unes adaptées à notre cas:

g1=g + geom_node_point(color="goldenrod",size=3)
g2=g + geom_node_label(aes(label=name),fill="steelblue",alpha=0.2)
g3=g + geom_node_text(aes(label=name), color="olivedrab")
g4=g + geom_node_circle(aes(fill=gender, r=0.3))
library(patchwork)
(g1+g2)/(g3+g4)

Notez que l’on retrouve les traits les plus commodes de ggplot2, comme l’argument “mapping” qui permet de relier certaines caractéristiques des geoms à certaines variables dans notre jeu de données…

Représentation des liens

Maintenant, voyons les possibilités pour la représentation des liens:

flowrpowr::flowr_package("ggraph",element="geom_edge", layout="sugiyama")

Et à nouveau, testons quelques-unes des possibilités:

g11=g1+geom_edge_link(color="steelblue")
g12=g1+geom_edge_arc(color="coral")
g13=g1+geom_edge_link(aes(edge_width=weight),color="olivedrab", alpha=0.2)
g14=g1+geom_edge_link(aes(edge_colour=relationship))
(g11+g13)/(g12+g14)

Facettes, échelles, etc.

Evidemment, pour un “vrai” graphe, on va jouer sur tout en même temps (les noeuds, les liens, la superposition des couches, les esthétiques, etc.). ggraph permet également de créer des facettes d’un même graphe soit en fonction des noeuds, soit en fonction des liens

gf=g +
  geom_edge_link(aes(edge_colour=relationship),
                 alpha=0.3, edge_width=2)+
  geom_node_label(aes(label=name, fill=gender),
                  alpha=0.3, label.size=0)+
  scale_edge_color_manual(values=c("couple"="red",
                                   "friends"="blue",
                                   "colleagues"="dark grey"))+
  scale_fill_manual(values=c("man"="yellow","woman"="orange"))+
  ggplot2::scale_x_continuous(expand=ggplot2::expand_scale(mult=0.1))
gf

(la dernière ligne me permet simplement d’étendre légèrement l’échelle des abscisses afin que les noms ne soient pas coupés sur les bords…)

On peut enfin facetter notre figure pour distinguer différents sous-graphes, en lien soit avec une variable catégorielle décrivant les noeuds (facet_nodes()), soit avec une variable catégorielle décrivant les liens (facet_edges()).

gf_e=gf + facet_edges(~relationship)
gf_n=gf + facet_nodes(~gender)
gf_e/gf_n

R-atique

Les transformées d’ondelettes, ou comprendre les mystérieux signaux [félins] grâce aux maths

A quoi peuvent vous servir les transformées d’ondelettes?

Décrire par les ondelettes continues

Décomposer par les ondelettes discrètes

Le blog est mort. Vive le blog!

Practice makes purrr-fect

purrr et dplyr sont dans un bateau: aucun ne tombe à l’eau

Fonctions, formules et pipéabilité

Petit à petit, les données font leur nid

ACP

Une ACP, pour quoi faire

Calcul des composantes principales

Réaliser l’ACP

Qualité de l’ACP

Interprétation

Position des variables

Position des individus

Représentations graphiques

Géocodage sous R via une API

Géocodage via une API: was ist das?

Géocodage

API

J’en ai vraiment besoin?

Exemple

Pour utiliser une API: montrez patte blanche!

Nominatim (OSM)

Google

Opencage

Où enregistrer vos clés d’accès aux API?

Comment ça fonctionne?

API clients opencage, mixr, tidygeocode

API OSM: package tidygeocoder

API Google/Opencage: package mixr

Appel de la fonction tidy_geocode() pour l’API Google:

Appel de la fonction tidy_geocode() pour l’API Opencage:

Citation

Utiliser un package

Qu’est-ce qu’un package ?

Installation vs chargement

Espace de nommage, désambiguation

Vie et maintien d’un package

Qualité d’un package

Des fonctions, de la documentation

Documentation simplifiée: vignettes

Des problèmes d’installation?

Janitor: nettoie-moi cette table (et qu’elle brille!)

Opérations sur les tables de contingences

Nettoyage de tableaux de données

Citation

Jamais sans ces packages!

Manipulation de données

dplyr: manipulation des tableaux de données

tidyr: restructuration des tableaux de données

readr: lecture des tableaux de données

Manipulation de données particulières

stringr: Manipulation de chaînes de caractères

tidytext pour le traitement du langage naturel

lubridate: opérations sur des dates, temps, heures

forcats: opérations sur les facteurs (variables catégorielles)

Graphiques

ggplot2 : réalisation des graphiques

patchwork: combinaison de graphiques

Données géographiques et cartographie

sf : données géographiques vectorielles

raster : données raster, grid

tmap: réalisation de cartes

Rapports et applications

rmarkdown et knitr: rapports tricotés

shiny: applications interactives

Itérations

Graphes

tidygraph : description et analyse de réseaux

ggraph : représentation de réseaux en graphes

Analyses factorielles

Analyse multi-résolution d’une série à travers les ondelettes discrètes

Les ondelettes discrètes, pour quoi faire?

Comment faire, sous R?

Des graphes bien jolis

Données

`dplyr`: manipulation des tableaux de données

`tidyr`: restructuration des tableaux de données

`readr`: lecture des tableaux de données

`stringr`: Manipulation de chaînes de caractères

`tidytext` pour le traitement du langage naturel

`lubridate`: opérations sur des dates, temps, heures

`forcats`: opérations sur les facteurs (variables catégorielles)

`ggplot2` : réalisation des graphiques

`patchwork`: combinaison de graphiques

`sf` : données géographiques vectorielles

`raster` : données raster, grid

`tmap`: réalisation de cartes

`rmarkdown` et `knitr`: rapports tricotés

`shiny`: applications interactives

`tidygraph` : description et analyse de réseaux

`ggraph` : représentation de réseaux en graphes