Cartographie du réseau Openflight de relations mondiales

La cartographie de relations mondiales souffre de problèmes graphiques spécifiques à ce type de données, à leur échelle géographique d’analyse, leur résolution notamment. Ces problèmes caractérisent, au sens général, un effet spaghetti qui témoignent de problèmes de représentation d’ordre graphique, mais pas seulement.

Cet effet est parfois si prégnant, et difficile à appréhender que l’information est souvent filtrée arbitrairement, avant de pouvoir être représentée, la zone d’étude limitée, réduite, recadrée… Pour explorer quelques possibilités de géo-visualisation de ces données, nous présentons des travaux réalisés à partir d’un même jeu de données (la base de données Openflightdata) appréhendée selon différentes perspectives.

Une première approche essentiellement cartographique est présentée sur le carnet de recherches Neocarto ici ; elle décrit un travail ancien mené au sein du groupefmr par Laurent Beauguitte, Serge Lhomme et moi-même, qui a donné lieu à une communication à l’ECTGQ en 2013. Une seconde approche, orientée cartographie web interactive, s’inscrit dans le registre de la Théorie des graphes, elle est présentée ci-dessous.

Explorer des relations aériennes mondiales

Les données dont il est question sont bien connues du groupefmr, car elles proviennent du site de l’Openflightdata, proposant librement un jeu de données formé de relations aériennes mondiales inter aéroports ou internationales.

L’intérêt porté à ces données est qu’elles font l’objet d’une application mise en ligne dans l’année, dénichée dans le cadre du projet geographic flows visualization (gFlowiz) explorant la représentation de flux et de réseaux dans le geoweb.

IATA Map Airport web application

L’application web IATA Map Airport, réalisée par Matthieu Totet, est accessible sur son site ici. L’objectif est de permettre d’explorer les données relationnelles de IATA (2017), en les géo visualisant de manière interactive; Il est en effet possible de cliquer sur les cercles symbolisant les aéroports représentés pour voir afficher leur réseau aérien.

Continuer la lecture de Cartographie du réseau Openflight de relations mondiales

Françoise Bahoken

Géographe et cartographe, Chargée de recherches à l'IFSTTAR et membre-associée de l'UMR 8504 Géographie-Cités.

More Posts

Comment cartographier des données relationnelles et les analyser à l’aide de l’extension Network_Analysis ?

Ce tutoriel a été créé à l’occasion de l’école d’été thématique en analyse de réseaux organisée à Cargèse par le GDR AR-SHS. Elle s’est tenue entre le 24 et le 28 septembre 2018 dans des conditions climatiques miraculeuses.

Demandant d’utiliser la toute dernière version 3.2 de QGIS, cet atelier pratique sur les données spatiales a provoqué une petite mise à jour de l’extension Network_Analysis de Serge Lhomme, déjà présentée à plusieurs reprises sur ce blog.

Nous demanderons donc à celles et ceux qui l’avaient déjà installée sur QGIS 3, de la désinstaller, de la re-télécharger sur le site internet : http://serge.lhomme.pagesperso-orange.fr/dev.html , puis de la réinstaller en suivant les indications ci-dessous.

Pour rappel, l’extension Network Analysis est une extension développée par Serge Lhomme, maître de conférence à l’Université Paris-Est Créteil. Il s’agit d’un outil facile d’utilisation permettant d’effectuer de l’analyse de réseaux sous QGIS, logiciel de Système d’Information Géographique (SIG) libre et gratuit. En effet, dans les SIG, les outils permettant d’analyser les propriétés structurelles de réseaux spatiaux ne sont pas si nombreux.

Installation de l’extension

Marche à suivre

Lancer Qgis

Aller dans le menu Extension -> Installer/Gérer les extensions

Aller dans la section « Installées » et désinstaller le plugin « Network_analysis » s’il apparaît dans la liste des extensions déjà installées

Aller rechercher le plugin « network_analysis_2_1 » sur le site : http://serge.lhomme.pagesperso-orange.fr/dev.html

Retourner dans Qgis au menu Extension -> Installer/Gérer les extensions

Sélectionner « Installer depuis un ZIP » et charger le fichier ZIP que vous venez juste de télécharger « network_analysis ».

Exemple de données relationnelles: les collaborations scientifiques entre villes françaises

Ce tutoriel s’appuie sur des données de recherche permettant de cartographier le réseau français des collaborations scientifiques en chimie. Ces données sont le résultat d’un travail de codage des données de publications scientifiques contenues dans une base de données bibliographique de référence pour les chimistes: le Web of Science.

Deux fichiers sont nécessaires, un fichier précisant la localisation des villes d’où ont été signées des publications scientifiques en chimie entre 2008 et 2012, et un fichier de lien indiquant la fréquence des collaborations entre ces villes mesurées par les co-signatures (le fait qu’une publication soit signée depuis plusieurs lieux différents).

Un fond de carte des régions françaises est également rendu disponible.

Ces fichiers sont téléchargeables depuis le dépôt suivant : https://framagit.org/MarionMai/using-network_analysis-on-qgis-3

Charger les données relationnelles

Marche à suivre

Aller dans le menu Couche -> Ajouter une couche -> Ajouter une couche de texte délimité

Sélectionner le fichier « Point_chimie_France.csv »

Sélectionner le délimiteur « ; »

Dans la section « géométrie », sélectionner « point » et indiquer dans quelles colonnes se trouvent les coordonnées géographiques du fichier (X, Y pour Longitude, Latitude) : soit les colonnes « V2 » et « V3 »

Sélectionner « WGS 84 » comme système de référence spatial puis cliquer sur « Ajouter »

Recommencer l’opération pour charger le fichier de liens appelé « liens_chimie_France.csv »

Ce fichier n’a pas de géométrie (de coordonnées spatiales X,Y). Dans la section « Définition de la géométrie », il faut donc sélectionner « pas de géométrie »

La spatialisation de ce fichier se fera grâce aux informations relationnelles qu’il contient puisqu’on y précise quels sont les points ─ en l’occurrence, les entités urbaines ─ qui sont reliées ensemble :

La colonne V1 indique le point de départ des liens

La colonne V2 indique leur point de destination

Et la colonne V3, l’intensité des liens

À l’aide du package « Network_Analysis », ces trois informations vont suffire à créer une couche spatialisée de liens.Générer une couche spatialisée de liens

Marche à suivre

Pour cela, aller dans le menu Extension -> Network Analysis -> Tools

Sélectionner « Table to graph » qui permet de passer d’une table de liens à un graphe

Sélectionner le nom de la couche de points dans la section « Nodes layer » et sélectionner le nom du fichier de liens dans la section « Edges layer ».Cliquer sur OK

Renseigner la boîte de dialogue en indiquant dans :

– Node ID, le nom de la colonne de la couche de points où sont indiqués les identifiants uniques (sans doublons) des points (qui peuvent être numérique ou textuels) – ici V1

– Field X, le nom de la colonne de la couche de points où est indiquée la longitude des villes – ici V2

– Field Y, le nom de la colonne de la couche de points où est indiquée la latitude des villes – ici V3

– Start Field, le nom de la colonne du fichier de liens où est indiquée l’ID de départ des liens (nom de la ville de départ) – ici V1

– End Field, le nom de la colonne du fichier de liens où est indiquée l’ID de destination des liens (nom de la ville d’arrivée) – ici V2

-EPSG, le nom ou code du système de référencement spatial utilisé, ici « 4326 » comme indiqué sur le bas droit de l’écran. Ce code correspond au système de référencement « WGS 84 » qui correspond au système du GPS.

Cliquer sur OK

Modifier la projection géographique

Marche à suivre

Aller dans Projet->Propriétés du projet

Sélectionner la section « SCR », taper « lambert 93 » (système de projection adapté au territoire français) dans la barre de recherche, sélectionner « RGF_1993_Lambert_93 » et cliquer sur « Appliquer »Sauvegarder les couches « Edges » et « Nodes » avec la projection adaptée

Marche à suivre

Faire un clic droit sur chacune des couches, choisir Exporter et Sauver

Indiquer format « GeoJSON », choisir le répertoire et le nom à donner au fichier (par exemple « Edges.geojson » pour la couche Edges et « Nodes.geojson » pour la couche Nodes

Sélectionner le « SCR du projet » dans la section SCR soit « Lambert 93 »

Cliquer sur OK

Supprimer les couches Edges et Nodes précédentes (clic droit sur la couche-> supprimer la couche)

Glisser déplacer la nouvelle couche « Edges » en dessous de la nouvelle couche « Nodes »

Modifier la couleur des liens selon l’intensité des collaborations

Marche à suivre

Faire un clic droit sur la couche Edges et sélectionner « Propriétés » puis « Symbologie »

Sélectionner « Gradué » dans le menu déroulant se trouvant en haut de la fenêtre de dialogue

Dans Colonne, sélectionner le nom de la variable contenant la valeur associée à l’intensité des collaborations scientifiques, en l’occurrence V3

Dans Palette de Couleur, sélectionner le dégradé de vert

Dans Mode, sélectionner le mode de discrétisation de Jenks

Décocher, la première valeur de classe [de 0 à 13,5] pour que ne s’affichent que les liens de collaborations d’une valeur supérieure à 13,5

Pour information -> les valeurs de collaboration sont décimales car fractionnées en fonction du nombre d’agglomérations urbaines d’où ont été signées les publications scientifiques en chimie. Pour en savoir plus sur cette méthodologie, se référer au site internet du projet de recherche : http://geoscimo.univ-tlse2.fr/

Cliquer sur Appliquer puis sur OK

Calculer le degré des nœuds

Marche à suivre

Commencer par modifier les ID des champs en utilisant l’option « Correct ID » de l’extension Network Analysis

Pour cela Aller à Extension->Network Analysis->Tools->Correct ID

Sélectionner « Nodes » dans Nodes layer et « Edges » dans Edge layer

Sélectionner les colonnes où se trouvent les identifiants uniques de la couche « Nodes » et de la couche « Edges », en l’occurrence V1 dans la couche « Nodes », et V1 et V2 dans la couche « Edges ».

Aller à Extension-> Network Analysis-> Basic Analysis

Sélectionner « Nodes » dans Nodes layer et « Edges » dans Edge layer

Choisir « Nodes » dans la fenêtre permettant d’indiquer que l’on souhaite calculer un indicateur portant sur les nœuds plutôt que sur les liens

Indiquer dans la fenêtre de dialogue, les colonnes correspondant aux nouveaux identifiants de la couche « Edges » à savoir « StartNode » et « EndNode »

Choisir « No » dans Normalization pour que l’indicateur de degré ne soit pas normalisé.Pour consulter le résultat, effectuer un clic droit sur la couche « Nodes » et ouvrir la table des attributs

Le résultat apparaît dans une nouvelle colonne intitulée « Degree »

Faire varier la taille des nœuds en fonction de leur degré

Marche à suivre

Effectuer un clic droit sur la couche « Nodes »

Aller dans Propriétés puis Symbologie

Choisir comme couleur de nœud un vert par défaut – code rgb(51, 160, 44)

Cliquer sur l’icône se trouvant à droite de l’indice de « Taille » du symbole (ci-dessous en rouge)

Aller dans Assistant, sélectionner le nom de la variable où est stocké le Degré, soit « Degree »

Indiquer l’intervalle entre lequel se situe les valeurs de l’indicateur, en l’occurrence 1 et 119 (comme on l’observe en consultant la table attributaire)

Choisir de faire varier la taille des nœuds entre une taille de 1 à 5

Choisir de faire varier la surface des cercles (méthode de calcul : Surface)

Ajouter un fond de carte de la France

Marche à suivre

Pour finir, charger le fichier shapefile « FRA_adm1.shp » en allant dans :

Ajouter une couche->Ajouter une couche vecteur

Sélectionner le fichier « FRA_adm1.shp » dans la section « Source » de la boîte de dialogue

Cliquer déplacer la nouvelle couche en dessous des couches « Nodes » et « Edges »

Changer la couleur de la couche en faisant un clic droit sur le nom de la couche puis choisir une couleur légère comme par exemple la couleur correspondant au code html #fdf0c1

Une fois satisfait du résultat obtenu, vous pouvez mettre en page, ajouter une légende et un titre en allant dans le composeur d’impression :  Projet->Composeur d’Impression (ou en anglais : Layout Manager)

Pour en savoir plus sur l’utilisation du composeur d’impression, consulter par exemple :

http://www.qgistutorials.com/fr/docs/automating_map_creation.html

Pour toutes questions ou problèmes regardant l’utilisation de l’extension Network Analysis, vous pouvez vous adresser à serge.lhomme@u-pec.fr

Et pour suivre les mises à jour, consulter son site : http://serge.lhomme.pagesperso-orange.fr/index.html

Bonne chance !

Atelier d’Analyse de réseaux avec R : Exploration de réseaux dynamiques

Le 28 mars 2018 a eu lieu un atelier d’analyse de réseaux avec R, animé par Robin Lamarche-Perrin, chercheur au CNRS (ISC, LIP6). Les slides de la présentation, le script et les données utilisées sont disponibles en téléchargement ici.

Nombre d’articles citant chacun des pays du G8 en fonction du temps (données Geomédia)

 

 

Ryma Hachi

Ryma Hachi est doctorante à l’UMR Géographie-cités depuis octobre 2014, sous la direction de Lena Sanders. Architecte de formation, sa thèse vise à révéler, grâce à la théorie des graphes, les processus de formation et de transformation des réseaux viaires.

More Posts

Le 28 mars: retour des ateliers d’analyse de réseaux avec R

Après le succès de la première édition, les ateliers d’Analyse de réseaux avec R organisés par le groupe fmr reviennent!

Cette fois-ci, l’atelier portera sur l’exploration de réseaux dynamiques. En voici une courte présentation:

Dans cet atelier, nous présentons une librairie R pour l’exploration de données multidimensionnelles. Appliquée à l’étude des réseaux dynamiques, cette librairie permet notamment l’exploration et la visualisation d’interactions entre individus au cours du temps. Sur le plan théorique, il s’agit de manipuler une matrice tridimensionnelle (émetteur x récepteur x temps) à l’aide d’opérateurs simples (filtrage, agrégation, normalisation) pour ouvrir différentes perspectives sur les données. En particulier, ces opérateurs permettent de comparer les interactions entre elles et d’identifier des outliers, c’est-à-dire des anomalies statistiques qui pourraient constituer des pistes intéressantes pour une recherche empirique approfondie.

Cet atelier sera animé par Robin Lamarche-Perrin (Chargé de recherche CNRS, ISC, LIP6).

La séance aura lieu le mercredi 28 mars, de 10h à 12h, sur le campus de l’Université Paris 7, Bâtiment Olympe de Gouges (8 rue Albert Einstein, 75013), salle 109 (premier étage).

Les personnes intéressées sont invitées à s’inscrire en envoyant un mail à hachiryma@gmail.com.

En espérant vous voir nombreux!

 

Ryma Hachi

Ryma Hachi est doctorante à l’UMR Géographie-cités depuis octobre 2014, sous la direction de Lena Sanders. Architecte de formation, sa thèse vise à révéler, grâce à la théorie des graphes, les processus de formation et de transformation des réseaux viaires.

More Posts

3ème séance du cycle de formation à l’analyse de réseaux avec R

La troisième séance du cycle de formation organisé par fmr sur l’analyse de réseaux avec R a eu lieu le 19 décembre 2017, à l’Institut de géographie de Paris. Elle était animée par Hadrien Commenges, maître de conférence à l’université Paris 1. Le contenu de la séance est détaillé ci-dessous. Les données utilisées sont téléchargeables ici.

La séance avait pour objectifs de:

  • Savoir construire un graphe à partir d’une liste de liens
  • Connaître les principes de la détection de communautés
  • Savoir choisir parmi les différents algorithmes de détection
  • Être capable de concevoir une chaîne de traitement efficace

Présentation des données

Le fichier citibike042017.Rds contient tous les trajets effectués sur le réseau Citibike durant le mois d’avril 2017. Les données brutes sont téléchargeables sur le site http://www.citibikenyc.com/system-data. Elles sont enrichies par :

  • des variables calculées : distance euclidienne, distance de Manhattan, vitesse (calculée sur la distance de Manhattan)
  • une variable météorologique : pluie, variable binaire 0-non, 1-oui

Traitements préalables

Charger les packages

library(sf)
library(cartography)
library(igraph)
library(dplyr)

Charger les données

citiBike <- readRDS("DATA/citibike042017.Rds")

Créer un fichier de stations : tableau de points (data.frame) et objet spatial (sf)

# vérifier le nombre total de stations
citiBike$start_station_id %>% unique() %>% length()
## [1] 609
citiBike$end_station_id %>% unique() %>% length()
## [1] 608
c(citiBike$start_station_id, citiBike$end_station_id) %>% unique() %>% length()
## [1] 609
# créer un index de valeurs dupliquées
idUnic <- !duplicated(citiBike$start_station_id)

# filtrer et mettre en forme le tableau de points
tabStations <- citiBike[idUnic, c(1, 3, 4)] %>% 
  rename(id = start_station_id,
         lat = start_station_latitude,
         lon = start_station_longitude) %>% 
  arrange(id)

# transformer le tableau en objet spatial
spStations <- st_as_sf(tabStations,
                       coords = c("lon", "lat"),
                       agr = "constant",
                       crs = 4326, 
                       stringsAsFactors = FALSE)

Cartographier les stations

osmTiles <- getTiles(x = spStations, type = "osm", zoom = 14, crop = FALSE)
## Loading required namespace: raster
tilesLayer(osmTiles)
plot(spStations$geometry, pch = 20, add = TRUE)

Pour l’exploration utiliser leaflet

library(leaflet)
leaflet() %>% addTiles() %>% addCircleMarkers(data = spStations)

Construction du graphe

Le tableau dont on dispose (citiBike) peut être considéré comme une liste de liens : chaque station représente un noeud (sommet) du graphe, chaque trajet reliant deux stations représente un arc (arrête). En l’état il s’agit donc d’une liste de liens multiples non pondérés : entre deux stations il y a un nombre n de trajets. Pour pouvoir analyser ce réseau il sera utile d’agréger ces liens multiples : si 10 trajets relient la station A à la station B, on ne considère pas qu’il y a dix arcs non valués mais un seul arc de poids 10.

Pour faire l’agrégation il est possible de créer le graphe non valué qui aura 609 noeuds et 12,4 millions d’arcs puis de collapser les arcs multiple avec la fonction simplify() et l’argument remove.multiple. Cette option est assez mauvaise parce qu’elle demande une opération coûteuse de création d’un graphe à 12,4 millions d’arcs. Il est donc préférable de faire l’agrégation en amont, avec aggregate() ou avec les fonctions du packages dplyr.

tabAgr <- citiBike %>% 
  group_by(start_station_id, end_station_id) %>% 
  summarise(NB = n())

Explorons ce réseau.

summary(tabAgr$NB)
##    Min. 1st Qu.  Median    Mean 3rd Qu.    Max. 
##   1.000   1.000   3.000   9.111  10.000 761.000
nrow(tabAgr) / (609 * 608)
## [1] 0.3686587

Il y a donc 136504 arcs pondérés reliant les 609 stations. C’est un réseau très dense : le rapport entre nombre d’arcs observés et nombre d’arcs maximal est de 0,37. Les poids varient entre 1 et 761, avec une distributions très concentrée à gauche : min à 1, Q1 à 1, médiane à 3, Q3 à 10.

Ce tableau peut maintenant être transformé en objet de type igraph.

citiNet <- graph.data.frame(tabAgr, directed = TRUE, vertices = tabStations)

On peut explorer l’objet, mais éviter de le représenter : avec 136504 arcs ce serait long et le résultat serait illisible.

summary(citiNet)
## IGRAPH DN-- 609 136504 -- 
## + attr: name (v/c), lat (v/n), lon (v/n), NB (e/n)
components(citiNet)
## $membership
##   72   79   82   83  116  119  120  127  128  143  144  146  150  151  152 
##    1    1    1    1    1    1    1    1    1    1    1    1    1    1    1 
##  153  157  161  164  167  168  173  174  195  212  216  217  223  225  228 
##    1    1    1    1    1    1    1    1    1    1    1    1    1    1    1 
##  229  232  236  237  238  239  241  242  243  244  245  247  248  249  251 
##    1    1    1    1    1    1    1    1    1    1    1    1    1    1    1 
##  252  253  254  257  258  259  260  261  262  264  265  266  267  268  270 
##    1    1    1    1    1    1    1    1    1    1    1    1    1    1    1 
##  274  275  276  278  279  280  281  282  284  289  291  293  295  296  297 
##    1    1    1    1    1    1    1    1    1    1    1    1    1    1    1 
##  301  302  303  304  305  306  307  308  309  310  311  312  313  314  315 
##    1    1    1    1    1    1    1    1    1    1    1    1    1    1    1 
##  316  317  319  320  321  322  323  324  325  326  327  328  330  331  332 
##    1    1    1    1    1    1    1    1    1    1    1    1    1    1    1 
##  334  335  336  337  339  340  341  342  343  344  345  346  347  348  349 
##    1    1    1    1    1    1    1    1    1    1    1    1    1    1    1 
##  350  351  353  354  355  356  357  358  359  360  361  362  363  364  365 
##    1    1    1    1    1    1    1    1    1    1    1    1    1    1    1 
##  366  368  369  372  373  376  377  379  380  382  383  384  385  386  387 
##    1    1    1    1    1    1    1    1    1    1    1    1    1    1    1 
##  388  389  390  391  392  393  394  395  396  397  398  399  400  401  402 
##    1    1    1    1    1    1    1    1    1    1    1    1    1    1    1 
##  403  405  406  407  408  409  410  411  412  414  415  416  417  418  419 
##    1    1    1    1    1    1    1    1    1    1    1    1    1    1    1 
##  420  421  422  423  426  427  428  430  432  433  434  435  436  437  438 
##    1    1    1    1    1    1    1    1    1    1    1    1    1    1    1 
##  439  440  441  442  443  444  445  446  447  448  449  450  453  454  455 
##    1    1    1    1    1    1    1    1    1    1    1    1    1    1    1 
##  456  457  458  459  460  461  462  465  466  467  468  469  470  471  472 
##    1    1    1    1    1    1    1    1    1    1    1    1    1    1    1 
##  473  474  476  477  478  479  480  481  482  483  484  485  486  487  488 
##    1    1    1    1    1    1    1    1    1    1    1    1    1    1    1 
##  490  491  492  494  495  496  497  498  499  500  501  502  503  504  505 
##    1    1    1    1    1    1    1    1    1    1    1    1    1    1    1 
##  507  508  509  511  513  514  515  516  517  518  519  520  522  523  524 
##    1    1    1    1    1    1    1    1    1    1    1    1    1    1    1 
##  525  526  527  528  529  530  531  532  533  534  536  537  539  540  545 
##    1    1    1    1    1    1    1    1    1    1    1    1    1    1    1 
##  546 2000 2001 2002 2003 2005 2006 2008 2009 2010 2012 2021 2022 2023 3002 
##    1    1    1    1    1    1    1    1    1    1    1    1    1    1    1 
## 3016 3041 3042 3043 3044 3046 3047 3048 3049 3050 3052 3053 3054 3055 3056 
##    1    1    1    1    1    1    1    1    1    1    1    1    1    1    1 
## 3057 3058 3059 3060 3061 3062 3063 3064 3065 3066 3067 3068 3069 3070 3071 
##    1    1    1    1    1    1    1    1    1    1    1    1    1    1    1 
## 3072 3073 3074 3075 3076 3077 3078 3080 3081 3082 3083 3085 3086 3087 3088 
##    1    1    1    1    1    1    1    1    1    1    1    1    1    1    1 
## 3090 3091 3092 3093 3094 3095 3096 3100 3101 3102 3103 3105 3106 3107 3108 
##    1    1    1    1    1    1    1    1    1    1    1    1    1    1    1 
## 3109 3110 3111 3112 3113 3114 3115 3116 3117 3118 3119 3120 3121 3122 3123 
##    1    1    1    1    1    1    1    1    1    1    1    1    1    1    1 
## 3124 3125 3126 3127 3128 3129 3130 3131 3132 3134 3135 3136 3137 3139 3140 
##    1    1    1    1    1    1    1    1    1    1    1    1    1    1    1 
## 3141 3142 3143 3144 3145 3146 3147 3148 3150 3151 3152 3155 3156 3157 3158 
##    1    1    1    1    1    1    1    1    1    1    1    1    1    1    1 
## 3159 3160 3161 3162 3163 3164 3165 3166 3167 3168 3169 3170 3171 3172 3173 
##    1    1    1    1    1    1    1    1    1    1    1    1    1    1    1 
## 3175 3176 3177 3178 3179 3180 3182 3221 3223 3224 3226 3231 3232 3233 3235 
##    1    1    1    1    1    1    1    1    1    1    1    1    1    1    1 
## 3236 3238 3241 3242 3243 3244 3245 3249 3254 3255 3256 3258 3259 3260 3263 
##    1    1    1    1    1    1    1    1    1    1    1    1    1    1    1 
## 3282 3283 3284 3285 3286 3288 3289 3290 3292 3293 3294 3295 3297 3298 3300 
##    1    1    1    1    1    1    1    1    1    1    1    1    1    1    1 
## 3301 3302 3303 3304 3305 3306 3307 3308 3309 3310 3311 3312 3313 3314 3315 
##    1    1    1    1    1    1    1    1    1    1    1    1    1    1    1 
## 3316 3317 3318 3319 3320 3321 3322 3323 3324 3325 3326 3327 3328 3329 3330 
##    1    1    1    1    1    1    1    1    1    1    1    1    1    1    1 
## 3331 3332 3333 3335 3336 3337 3338 3339 3340 3341 3342 3343 3344 3345 3346 
##    1    1    1    1    1    1    1    1    1    1    1    1    1    1    1 
## 3347 3348 3349 3350 3351 3352 3353 3354 3355 3356 3357 3358 3359 3360 3361 
##    1    1    1    1    1    1    1    1    1    1    1    1    1    1    1 
## 3362 3363 3364 3365 3366 3367 3368 3370 3371 3373 3374 3375 3376 3377 3378 
##    1    1    1    1    1    1    1    1    1    1    1    1    1    1    1 
## 3379 3381 3382 3383 3384 3386 3387 3388 3389 3390 3391 3392 3393 3394 3395 
##    1    1    1    1    1    1    1    1    1    1    1    1    1    1    1 
## 3396 3397 3398 3399 3400 3401 3402 3403 3404 3405 3407 3408 3409 3410 3411 
##    1    1    1    1    1    1    1    1    1    1    1    1    1    1    1 
## 3412 3413 3414 3415 3416 3417 3418 3419 3420 3421 3422 3423 3424 3425 3427 
##    1    1    1    1    1    1    1    1    1    1    1    1    1    1    1 
## 3428 3429 3430 3431 3434 3435 3436 3438 3440 3441 3443 3445 3447 3449 3450 
##    1    1    1    1    1    1    1    1    1    1    1    1    1    1    1 
## 3452 3453 3454 3455 3456 3457 3459 3462 3463 
##    1    1    1    1    1    1    1    1    1 
## 
## $csize
## [1] 609
## 
## $no
## [1] 1
diameter(citiNet)
## [1] 4

Ces mesures confirment le diagnostic précédent, une seule composante connexe et un diamètre égal à 4, le réseau est très dense. Quelques mesures sur les degrés des noeuds permettent de se faire une idée plus précise de la structure des flux.

degIn <- strength(citiNet, mode = "in", weights = E(citiNet)$NB)
degOut <- strength(citiNet, mode = "out", weights = E(citiNet)$NB)
hist(degIn, col = "firebrick", border = "white")

hist(degOut, col = "firebrick", border = "white")

plot(degIn, degOut, pch = 20)
abline(a = 0, b = 1, col = "red")

Détection de communautés

Sur un graphe simple, tous les algorithmes de détection de communautés donneront un résultat correct et rapide. Voici un exemple.

g <- make_full_graph(5) %du% make_full_graph(5) %du% make_full_graph(5)
g <- add_edges(g, c(1,6, 1,11, 6, 11))

Avec l’algorithme basé sur l’intermédiarité des liens :

betweenClus <- cluster_edge_betweenness(g, weights = NULL, directed = FALSE)
plot(g, vertex.color = betweenClus$membership)

Avec l’algorithme fast greedy :

greedyClus <- cluster_fast_greedy(g, weights = NULL)
plot(g, vertex.color = greedyClus$membership)

Avec l’algorithme de Louvain :

louvainClus <- cluster_louvain(g, weights = NULL)
plot(g, vertex.color = louvainClus$membership)

La notion principale mobilisée dans la détection de communauté est la modularité (modularity), elle s’écrit :

où m est la demi-somme des poids, Aij est le poids de l’arc reliant les noeuds i et jki et kj sont les sommes marginales des noeuds i et (i.e. leur degré entrant et sortant) et la fonction δ une fonction binaire qui prend la valeur 1 si i et j sont dans la même communauté (et 0 sinon).

La modularité peut être calculée a posteriori sur n’importe quel objet de type communities pour caractériser le partitionnement :

modularity(betweenClus)
## [1] 0.5757576
modularity(greedyClus)
## [1] 0.5757576
modularity(louvainClus)
## [1] 0.5757576

Dans un grand nombre d’algorithmes, la modularité n’est pas utilisé comme mesure a posteriori de la qualité du partionnement mais comme quantité à maximiser. C’est ce que font les algorithmes suivants :

  • fast greedy avec cluster_fast_greedy()
  • Louvain avec cluster_louvain()
  • optimum de modularité avec cluster_optimal()
  • principale valeur propre avec cluster_leading_eigen()

Application aux données citibike

Parmi les algorithmes présentés (il existe d’autres algorithmes qui ne s’appuient pas sur la modularité et qui n’ont pas été présentés) :

  • celui de l’intermédiarité des liens est clairement hors de propos : il est itératif, donc lent, et surtout la notion d’intermédiarité a peu de sens dans un graphe aussi dense (voir plus haut)
  • celui de la valeur propre est rarement applicable parce qu’il crée seulement deux clusters
  • celui de l’optimum de modularité donnerait le meilleur résultat mais il est inapplicable sur un graphe d’une telle taille
  • les deux autres – fast greedy et Louvain – sont applicables et donneront des résultats semblables, il donnent un approximation rapide de l’optimum de modularité

Attention la plupart des algorithmes demandent un graphe non orienté. On commence donc par transformer le réseau : on considère que s’il y a un lien bidirectionnel entre une station i et une station j il convient de sommer les deux sens au moment de l’agrégation. Bien sûr d’autres fonctions pourraient être appliquées.

citiNetUn <- as.undirected(graph = citiNet, mode = "collapse", edge.attr.comb = sum)
summary(citiNetUn)
## IGRAPH UN-- 609 84105 -- 
## + attr: name (v/c), lat (v/n), lon (v/n), NB (e/n)

On applique maintenant l’algorithme de Louvain et on récupère l’appartenance des noeuds aux communautés. L’intérêt de cette méthode est de produire plusieurs niveaux d’agrégation (multilevel) si le réseau est complexe. Dans ce cas, le dernier niveau est donné par le vecteur membership, l’ensemble des niveaux est donné dans la matrice memberships. Dans l’exemple de Citibike le réseau est simple et un seul niveau d’agrégation est produit, la matrice memberships ne contient qu’une seule ligne :

multCom <- cluster_louvain(graph = citiNetUn, weights = E(citiNetUn)$NB)
vecMember <- multCom$membership
matMember <- multCom$memberships

Le réseau reste difficile à représenter avec ses 84105 arcs, on sélectionne une centaine d’arcs parmi les flux principaux en supprimant tous les arcs dont le poids inférieur à 300.

mainNet <- delete_edges(graph = citiNetUn, edges = E(citiNetUn)[E(citiNetUn)$NB < 300])
summary(mainNet)
## IGRAPH UN-- 609 124 -- 
## + attr: name (v/c), lat (v/n), lon (v/n), NB (e/n)

On cherche à afficher les noeuds aux coordonnées géographiques correspondantes aux stations. Il faut donner dans la fonction plot() une matrice de coordonnées : les noeuds du graphe (qui contiennent comme attribut la longitude et la lattitude), on fabrique une matrice contenant long et lat (dans cet ordre : la longitude est l’axe des x et la latitude l’axe des y), on désigne cette matrice avec l’argument layout =.

tabCoord <- get.data.frame(citiNetUn, what = "vertices")
matCoord <- as.matrix(tabCoord[, c(3, 2)])

plot(mainNet, 
     vertex.color = multCom$membership, 
     vertex.label = NA, 
     vertex.frame.color = NA,
     vertex.size = 2,
     edge.color = "firebrick",
     edge.width = 2,
     layout = matCoord)

Si on veut cartographier le résultat il faut extraire un tableau, éventuellement l’enrichir de mesures calculées sur le graphe (ici les clusters et les degrés des noeuds), puis créer un objet spatial.

tabCoord$CLUS <- multCom$membership
tabCoord$DEGIN <- degIn
tabCoord$DEGOUT <- degOut

spClus <- st_as_sf(tabCoord,
                   coords = c("lon", "lat"),
                   agr = "constant",
                   crs = 4326, 
                   stringsAsFactors = FALSE)

Cet objet peut être représenté :

  1. avec la fonction plot()
  2. avec les fonctions du packagecartography
  3. avec le packageleaflet si on veut explorer et comprendre pourquoi certaines stations du Sud de Manhattan font partie du même cluster que Brooklyn.

Option 1

plot(spClus$geometry)

Option 2

tilesLayer(osmTiles)
propSymbolsLayer(x = spClus, var = "DEGIN", inches = 0.1, col = "black", border = "white")
## Warning in st_centroid.sfc(st_geometry(x), of_largest_polygon =
## of_largest_polygon): st_centroid does not give correct centroids for
## longitude/latitude data

Option 3

Ici on ajoute des tuiles CartoDB (voir la liste des tuiles disponibles sur ce site)

colPal <- c("firebrick", "grey", "springgreen", "blue")
leaflet() %>% 
  addProviderTiles(provider = "CartoDB.DarkMatter") %>% 
  addCircleMarkers(data = spClus, 
                   stroke = FALSE, 
                   fillColor = colPal[spClus$CLUS],
                   fillOpacity = 0.6)

Poursuite de l’analyse

Créer des sous-graphes en filtrant le tableau des déplacements en amont, faire par exemple :

  • le graphe des déplacements en jour de pluie
  • le graphe des déplacements des abonnés vs. utilisateurs occasionnels
  • le graphe des déplacements en heure de pointe du matin

 

Ryma Hachi

Ryma Hachi est doctorante à l’UMR Géographie-cités depuis octobre 2014, sous la direction de Lena Sanders. Architecte de formation, sa thèse vise à révéler, grâce à la théorie des graphes, les processus de formation et de transformation des réseaux viaires.

More Posts

Compte rendu de l’atelier « Analyse de réseaux spatiaux et SIG » – SAGEO 2017

L’atelier « Analyse de réseaux spatiaux et SIG » s’est déroulé le lundi 6 novembre 2017 dans le cadre du colloque SAGEO qui s’est tenu à Rouen. L’objectif de cet atelier était de se familiariser avec l’analyse de réseaux ou d’approfondir ses connaissances en la matière dans un environnement SIG. Il visait aussi à questionner la pertinence : d’utiliser des SIG pour faire de l’analyse de réseaux ; d’hybrider les méthodes d’analyse spatiale et d’analyse de réseaux.

La journée a commencé par une présentation de Laurent Beauguitte qui a introduit les fondements de l’analyse de réseaux afin que les participant.e.s puissent partager un vocabulaire commun. En m’appuyant sur cette introduction, j’ai pu présenter la version 1.3 de mon plugin QGIS nommé « Network_Analysis ». Ainsi, à partir d’un graphe simplifié du réseau autoroutier français, des exemples concrets de l’utilisation du plugin ont été donnés : modélisation d’un réseau sous la forme d’un graphe ; calcul d’indicateurs simples ; étude de corrélations entre les indicateurs ; prise en compte de l’espace pour enrichir ces indicateurs (ici le support de la présentation). A la fin de la matinée, Ryma Hachi a présenté différents outils permettant d’analyser plus finement ce type de réseaux viaires, en particulier l’outil SDNA (ici le support de la présentation). Cette présentation a de nouveau insisté sur les problématiques relatives à la modélisation d’un réseau sous la forme d’un graphe.

Après la pause méridienne, nous avons introduit une nouvelle thématique : celle de l’analyse de flux. Françoise Bahoken a alors commencé cette deuxième partie de journée en présentant les enjeux relatifs à la visualisation des flux. Sa présentation recense notamment des outils permettant de manipuler et de visualiser des flux avec QGIS  (ici le support de la présentation). L’utilisation de R lui semble néanmoins indispensable, les outils disponibles sous QGIS lui semblant encore insuffisants. Ensuite, j’ai effectué une courte présentation sur la détection de communautés spatiales. En effet, les algorithmes de détection de communautés peuvent être considérés comme des outils puissants pour étudier des flux (ici le support de la présentation). Le plugin  « Network_Analysis » propose d’ailleurs des algorithmes permettant de détecter des communautés au sein d’un graphe. Néanmoins, les communautés détectées apparaissent souvent contraintes spatialement, c’est pourquoi le plugin propose aussi de détecter des « communautés spatiales ».

Les deux dernières présentations de cette journée ont permis à deux jeunes doctorantes de présenter leurs travaux de thèse. Premièrement, Laura Pauchard nous a présenté ses travaux sur les échanges parcellaires dans les régions d’élevage de l’ouest de la France. Ainsi, après nous avoir initié avec Maxime Marie à sa problématique de recherche, elle a présenté sa méthodologie. Cette méthodologie l’a conduite à avoir recours à de l’analyse de réseaux. En effet, les échanges parcellaires peuvent se formaliser sous la forme d’un graphe. Cette formalisation lui permet notamment d’identifier les acteurs ayant le plus d’intérêts à collaborer (ici le support de la présentation). Deuxièmement, Ryma Hachi a présenté ses travaux de thèse portant sur la description de l’évolution temporelle des réseaux viaires (ici le support de la présentation). Après avoir introduit précisément ce qu’elle cherchait à identifier, elle a présenté les indicateurs qu’elle développe actuellement. Ces indicateurs lui paraissent pertinents pour identifier les phases d’exploration et de densification de ces réseaux.

Voilà un résumé très rapide et malheureusement trop succinct de cette journée plutôt dense. A noter que ce compte rendu ne peut répondre qu’imparfaitement à des demandes qui m’ont été formulées. Néanmoins, les personnes n’ayant pas pu assister à l’atelier trouveront ici des éléments relatifs à cette journée, en espérant renouveler prochainement ce type d’atelier !

Serge Lhomme

Maitre de conférences à l'université Paris Est Créteil - Docteur en géographie de l'université Paris VII spécialité "dynamique des milieux et risques"

More Posts - Website

2ème séance du cycle de formation à l’analyse de réseaux avec R

La deuxième séance du cycle de formation à l’analyse de réseaux avec R a eu lieu le 21 novembre 2017 à Paris dans le bâtiment Olympe de Gouges (Université Paris 7). Elle était animée par Antoine Peris (doctorant, TU Delft) et Romain Leconte (doctorant, UMR Géographie-cités).

La séance s’est déroulée en deux parties. Un premier temps était consacré au calcul des indicateurs les plus fréquemment utilisés en analyse de réseau, à l’aide du package igraph. Les personnes présentes ont ainsi pu se familiariser avec les lignes de commandes permettant d’inspecter le graphe (nombre de liens et de nœuds, attributs, requêtes attributaires), de calculer des indicateurs globaux (connexité, densité, degré moyen, diamètre), ainsi que des indicateurs locaux (degré de centralité total, degrés de centralités entrant et sortant, centralité d’intermédiarité). Ces résultats ont ensuite été visualisés de façon graphique.

La seconde partie de séance était consacrée à l’analyse d’un réseau dont les nœuds étaient spatialisés. Le but était de partir d’un gros volume de données individuelles brutes (les trajets des vélos partagés à New York) afin de les modéliser sous la forme d’un graphe valué et orienté, calculer quelques indicateurs et faire une carte de résultat avec ggplot2.

Distribution et cartographie des degrés des stations du réseau citibike

Les scripts et les données ayant servi à animer la séance sont disponibles ici.

À noter que la troisième et dernière séance de ce cycle de formation aura lieu le 19 décembre 2017, entre 10h et 12h30. Elle sera animée par Hadrien Commenges (UMR Géographie-cités), et permettra notamment d’aborder la question du filtrage des données, de la pondération des graphes, et de la détection de communautés.

Les inscriptions sont ouvertes. Il suffit d’indiquer votre intérêt pour la formation par mail à l’adresse de Ryma Hachi (hachiryma<a>gmail.com).

Cette fois-ci la formation se tiendra à l’Institut de géographie de Paris, 191 rue Saint-Jacques, 75005, en salle 405.

Ryma Hachi

Ryma Hachi est doctorante à l’UMR Géographie-cités depuis octobre 2014, sous la direction de Lena Sanders. Architecte de formation, sa thèse vise à révéler, grâce à la théorie des graphes, les processus de formation et de transformation des réseaux viaires.

More Posts

Initiation à sDNA (Spatial Design Network Analysis) sous Qgis

Ce tutoriel reprend en partie la présentation « Initiation à sDNA sous Qgis » préparée dans le cadre de l’atelier « Analyse de réseaux spatiaux et SIG » organisée par le groupe fmr à SAGEO 2017 (6-9 Novembre, Rouen). Les slides de la présentation sont disponibles ici.

Ces dernières années, plusieurs plugins permettant d’analyser des réseaux spatiaux grâce à Qgis ont été développés ; citons notamment Space Syntax Toolkit (J. Gil et al.), Network Analysis (S. Lhomme), Morpheo (C. Lagesse) ou encore sDNA (C. Cooper, A. Chiaradia, C. Webster). Ces plugins sont souvent utilisés pour analyser des réseaux viaires, mais chacun d’entre eux a une conception différente de la manière de passer de ce réseau à un graphe. Dans ce tutoriel, nous présenterons le plugin sDNA pour Spatial Design Network Analysis. Ce tutoriel est basé sur le manuel du plugin, disponible à l’adresse: http://www.cardiff.ac.uk/sdna/software/documentation.

1) Préalable théorique :

sDNA peut être utilisé pour tout type de réseaux spatiaux, mais la communauté de chercheurs qui l’utilise s’intéresse particulièrement aux réseaux urbains et aux systèmes de transport : réseau de véhicules, réseaux piétons (en intérieur ou en extérieur), cyclistes, transport public. Le plugin peut donc être utilisé aussi bien en planification des transports, en aménagement et en architecture.

Le postulat de ces travaux est que la structure des réseaux permet de capturer des informations sur un très grand nombre de phénomènes : la santé, la cohésion sociale, la valeur du foncier, la « vitalité » d’un quartier, l’usage du sol, les déplacements piétons, la pollution, les accidents ou encore l’insécurité. Ainsi, l’objectif de ces travaux est de fournir des arguments pour la conception de « meilleurs » réseaux dans l’environnement bâti.

sDNA permet d’étudier des réseaux spatiaux, c’est-à-dire des réseaux contenant des informations spatiales. Les nœuds ont donc des positions dans un espace euclidien à deux ou trois dimensions.

L’une des particularités de sDNA, par rapport aux plugins d’analyse de réseaux les plus classiques, est qu’il se focalise sur l’analyse des liens plutôt que des nœuds. Dans le cas des réseaux viaires, les rues sont souvent représentées par la polyligne qui passe par leur centre. Ces polylignes seront donc les liens du réseau, et les carrefours entre les rues seront les nœuds du réseau.

Autre particularité, ces liens ne prennent pas nécessairement la route la plus directe : ils peuvent avoir une forme physique différente de la ligne droite.

sDNA accepte le format « lien-nœud » mais seuls les liens sont réellement indispensables. On peut ainsi importer un shapefile contenant uniquement les rues d’une ville, et l’analyser avec sDNA.

2) Avant de commencer :

Installation :

Préparation du réseau :

A noter que l’analyse des réseaux viaires requiert souvent un travail préalable de nettoyage du réseau. Bien que sDNA propose quelques outils de nettoyage dans « Network preparation », nous recommandons d’utiliser plutôt les outils de nettoyage de vecteurs de Qgis, et de nettoyage topologique d’un réseau disponibles sur OpenJump.

Pour que le réseau soit correctement traité par sDNA, quelques vérifications sont nécessaires :

  • Vérifier le système de projection ;
  • Vérifier la connectivité : pour que deux lignes soient connectées, leurs extrémités doivent coïncider. Dans le cas contraire, sDNA considérera que c’est un pont ou un tunnel, un non-lien ;
  • Vérifier les erreurs de géométrie, particulièrement pour les analyses où les changements de directions sont importants ;
  • Les traffic islands (cf. figure) introduisent un changement de direction et une augmentation de la longueur de ces rues. Pour ne pas en tenir compte (les considérer comme des liens simples) ajouter un champ avec la valeur 1 pour les traffic islands à supprimer et 0 pour le reste. Utiliser ensuite le « Network preparation » de sDNA en cochant la case de correction des traffic islands.

Traffic island (sDNA 3.4.5 documentation)

3) Quelques basiques :

Définitions :

Un lien désigne soit la portion située entre deux jonctions, soit entre une jonction et une extrémité. Une jonction est un point où sont connectées au moins trois liens.

sDNA utilise souvent le terme polyligne plutôt que lien, et ce afin de signifier que ces liens peuvent avoir une forme physique.

Chaque polyligne de sDNA est considérée comme une origine indivisible, tous les flux partants d’une polyligne sont considérés comme émanant de son milieu. En revanche, en tant que destinations, deux choix sont possibles. Dans le Discrete Space Mode, les polylignes sont soit considérées comme des destinations indivisibles. En revanche, dans le Continuous Space Mode, elles sont considérées comme divisibles.

Quelques options :

  • Start grade separation et End grade separation:
    • Cette option permet de choisir une colonne origine et une colonne destination dans la table attributaire. Dans ce cas, seuls les liens qui partagent une origine ou une destination seront connectés.
    • Cette option peut s’avérer utile dans le cas d’un réseau multi-niveaux: rue et métro par exemple. En effet, cela permet de connecter les rues ensemble et les lignes de métro ensemble, en jouant sur les valeurs de grade separation (utiliser par exemple les valeurs 0, 1, 2… pour les rues, et 10, 11, 12… pour le métro).
  • La métrique d’analyse (le type de distance à prendre en compte):
    • Euclidienne= distance ordinaire
    • Angulaire= distance mesurée en termes de changement angulaire, que ce soit sur le même lien ou aux jonctions
    • Customisée= sélectionner un champ de métrique (par exemple un champ avec la distance en temps..)
    • Hybride= nécessite d’écrire la formule correspondante (en utilisant la ligne de commande- voir advanced_config dans le manuel)
    • Métrique prédéfinies= piéton, véhicule, cycliste, transport public, mais dont la formule peut être modifiée en utilisant advanced_config. Les formules sont décrites dans Preset metric variables (cf. manuel)– ce sont des distances pondérées selon les tournants, le trafic, les arrêts (si transport en commun) …
  • La pondération (Weight) :
    • Elle peut se faire sur les liens, les longueurs ou les polylignes.
    • Elle dépend de ce qu’on considère comme quantité importante dans notre analyse: le nombre de liens, la longueur, ou une variable donnée telle que la population, le nombre d’emplois…
    • La pondération recommandée est le nombre de liens, car la densité de liens est connue pour augmenter avec le nombre d’emplois et la population, ainsi en pondérant par le nombre de liens on capture déjà ces informations.

4) Les mesures calculées par sDNA :

Mesures sur les polylignes :

  • Lconn= nombre d’extrémités de lignes connectées à cette ligne
  • Llen= longueur de la polyligne
  • LAC= courbure angulaire cumulée le long de la ligne (en degré)
  • Line Hybrid Metrics= la métrique pour les polylignes est donnée, on peut utiliser cela pour signaler les sens interdits, les escalators, …
  • LSin= longueur de la ligne divisée par la distance à vol d’oiseau entre ses extrémités
  • LBear= écart d’orientation entre les deux extrémités de la ligne
  • Lfrac= proportion du lien que cette ligne représente

Mesures de la forme globale du réseau :

  • HullA= surface de l’enveloppe convexe couverte par le réseau
  • HullP = périmètre de l’enveloppe convexe
  • HullR (convex hull maximum radius)= plus longue distance à vol d’oiseau
  • Convex Hull Bearing= orientation de la plus longue distance à vol d’oiseau (souvent par rapport au nord cardinal)
  • Hull Shape Index= Hull Perimeter au carré, divisé par le produit de 4π et Hull area

Farness, Betweenness et Analyse de détours :

farness :

  • MEDn= longueur moyenne des chemins les plus courts entre ce lien et les autres (farness). C’est l’inverse de la closeness centrality. Cette mesure est pondérée par le poids des destinations.
  • La farness peut être calculée avec les autres types de métrique. Par exemple, MADn= longueur moyenne des chemins qui minimisent le changement de direction entre ce lien et les autres.

Betweenness :

  • BtEn= nombre de chemins les plus courts entre deux liens qui passent par ce lien. La betweenness peut aussi être calculée avec les autres types de métrique.

Analyse de détour : à quel point le réseau dévie des chemins les plus directs ?

  • MCFn= moyenne des distances à vol d’oiseau entre chaque origine et tous les liens.
  • DivEn= proportion de détour = ratio moyen entre plus courts chemins et chemins directs (à vol d’oiseau).

Analyse de voisinage :

  • L’ensemble des mesures évoquées jusqu’ici peut être calculée dans un rayon n choisi. Ceci permet de s’intéresser par exemple aux plus courts chemins, non pas par rapport à l’ensemble du réseau, mais dans le voisinage de chaque polyligne. Ce voisinage dépendra par exemple du type de déplacement (piéton, cycliste, …).
  • Quelques mesures de voisinage :
    • Lnkn= nombre de liens dans un rayon choisi
    • Lenn= longueur du réseau dans un rayon choisi
    • AngDn=courbure totale des liens dans le rayon choisi (en degré)
    • Wtn= poids total dans le rayon choisi

« Learn » et « Predict » :

  • Certaines des mesures calculées par sDNA sont connues pour être corrélées à des phénomènes réels tels que le trafic ou le prix du foncier.
  • Pour repérer ces corrélations, sDNA propose les outils Learn et Predict:
    • Learn = après avoir joint au réseau des données réelles – de population par exemple, Learn prend un échantillon de ces données et crée un modèle qui les relie aux mesures calculées par sDNA ;
    • Predict = permet de prendre le modèle créé par Learn et de l’appliquer à des régions où les données réelles ne sont pas disponibles (en se basant sur les mesures sDNA calculées dans ces régions).

 

Pour citer ce logiciel: Cooper, C., Chiaradia, A., Webster, C. (2016) Spatial Design Network Analysis software, version 3.4, Cardiff University, http://www.cardiff.ac.uk/sdna/

Ryma Hachi

Ryma Hachi est doctorante à l’UMR Géographie-cités depuis octobre 2014, sous la direction de Lena Sanders. Architecte de formation, sa thèse vise à révéler, grâce à la théorie des graphes, les processus de formation et de transformation des réseaux viaires.

More Posts

1ere séance du cycle de formation à l’analyse de réseaux avec R

La première séance du cycle de formation à l’analyse de réseaux avec R s’est tenue le 24 octobre 2017 à Paris (bâtiment Olympe de Gouges).

La séance était organisée en deux partie. En première partie, une introduction à l’analyse de réseaux a été proposée. Elle revient sur le vocabulaire de la théorie des graphes, montre plusieurs champs d’application dans le domaine de l’analyse des réseaux spatiaux et sociaux et décrit les principales approches  (calculs d’indicateurs locaux, globaux, visualisation, partitionnement, modélisation).

Le diaporama suivant a servi de support pour cette présentation:

 

La seconde partie de la séance était consacrée à la manipulation avec R Studio. L’interface de travail ainsi que les rudiments du langage R ont été présentés puis, pour débuter avec le package igraph, nous nous sommes appuyés sur les supports de cours développés par Rosemonde Letricot en juin 2017 pour l’école d’été d’initiation à l’analyse de réseaux en sciences humaines et sociales organisée par le GDR AR-SHS qui sont téléchargeables au lien suivant:
https://arshs.hypotheses.org/480

Les scripts et données utilisés lors de la séance sont disponibles ici.

La prochaine séance, le 21 novembre 2017, permettra d’aller plus loin dans la manipulation et apprendra à conduire une analyse de réseaux en calculant des indicateurs locaux sur les sommets et sur les liens. Les différents moyens de visualiser les résultats obtenus seront présentés en détail (visualisation de réseaux permettant de faire varier la taille des cercles et des liens, distribution de degrés etc.).

Les inscriptions sont ouvertes. Il suffit d’indiquer votre intérêt pour la formation par mail à l’adresse de Ryma Hachi (hachiryma<a>gmail.com).

La formation se tiendra au même endroit que précédemment de 10h à 12h: Bâtiment Olympe de Gouges, 8 Place Paul-Ricoeur, Paris

Séance du 25 avril 2017 : Geoseastems, un géoportail dédié aux réseaux (maritimes)

La prochaine séance du groupe fmr aura lieu le mardi 25 avril 2017 à 10 h, au 13 rue du four, 5e étage (bibliothèque), à Paris. Elle sera animée par Matthia Bunel, Ingénieur d’études à l’UMR 8504 Géographie-cités (équipe PARIS).

Matthia Bunel présentera le Geoseastems, portail  développé dans le cadre du projet Worldseastems de l’ERC coordonné par César Ducruet (par ailleurs cofondateur du Groupe fmr).

Titre : De la Lloyd’s list à GeoSeastems : développement d’un géoportail spécialisé dans l’étude des réseaux maritimes sur le temps long.

Présentation : Malgré son rôle prépondérant dans le commerce mondial, force est de constater que le transport maritime est longtemps resté le parent pauvre de la géovisualisation et des analyses de réseaux. Mais l’essor des données radar (AIS) et satellitales, disponibles depuis à peine une décennie, a permis à un grand nombre de chercheurs et d’experts de se questionner — à l’aide de méthodologies très variées — sur ce vecteur d’échanges en tous genres (marchandises, personnes, informations, polluants, microbes, …).
Le portail Geoseastems, positionné parmi les solutions existantes, se distingue par trois objectifs majeurs :
(1) il vise à renforcer la dimension analytique par
rapport à la pure visualisation en temps réel fournie par la plupart des projets existants à ce jour ;
(2) il souhaite fournir une approche sur le temps long du commerce maritime, à partir des données inédites de la Lloyd’s qui publie des registres de « mouvements » de navires depuis la fin du 17ème siècle ;
(3) le portail prévoit d’intégrer des données complémentaires sur les autres réseaux de transport (terrestres, aériens), les villes, et celles issues de projets voisins dans le domaine des humanités numériques afin de fournir une plate-forme centralisée et harmonisée à but pédagogique et de recherche, ouverte à tous.
Cette présentation sera l’occasion de discuter du processus de développement du portail, mais également d’aborder tous les problèmes liés au traitement des données de la Lloyd’s en vue de leur intégration à GeoSeastems.

Ces séances ont lieu les mardis matin de 10 heures à midi au 13 rue du Four à Paris, 5e étage, bibliothèque. Elles sont ouvertes à toute personne intéressée mais il peut être prudent de signaler sa venue (groupe_fmr@yahoo.fr), la bibliothèque étant vite remplie.

Françoise Bahoken

Géographe et cartographe, Chargée de recherches à l'IFSTTAR et membre-associée de l'UMR 8504 Géographie-Cités.

More Posts

Séance du 21 mars 2017 : Analyse et représentation d’une matrice de flux avec QGIS

La prochaine séance du groupe fmr aura lieu le mardi 21 janvier 2017 à 10h, au 13 rue du four, 5e étage (bibliothèque), à Paris. Elle portera sur l’analyse et la représentation d’une matrice de flux avec QGIS. Elle sera  animée par Françoise Bahoken.

La séance est composée de deux parties. Une première partie donnera lieu à la préparation des données numériques : import de la matrice, calcul d’indicateurs,…, filtrages de champs selon un critère unique global qui sera soit endogène (sélection des valeurs de flux supérieures à une valeur unique) soit exogène (sélection des flux selon un critère de distance continu …). Une seconde partie sera consacrée au tracé de tout ou partie des flux : le choix du figuré sera fonction du type de matrice (asymétrique ou symétrique) et leur représentation fonction des possibilités de symbolisation des liens ou des bandes proposées par QGIS, voire celles de stylisation suggérées par Anita Graser.

Extensions et outils « de flux » disponibles

En pratique, différentes extensions additionnelles et outils intégrés à QGIS peuvent être mobilisés pour représenter des flux. D’après ce que j’ai pu observer, ils diffèrent selon 1) qu’ils mobilisent en entrée une matrice de type liste (format long) ou de type matriciel (format wide) : voir ce billet pour les différents types de matrice asymétriques et celui-ci, pour les symétriques ; 2) aussi selon que le figuré qu’ils permettent de tracer : un lien, plus ou moins large ou une bande, autrement dit à un lien valué dont la surface géométrique est mesurable (ce qui change potentiellement beaucoup de choses, sinon tout sur le plan sémiologique).

N’étant pas spécialiste de QGIS, je ne saurai citer que les outils qui ont attiré mon attention, parmi lesquels, dans le désordre :

  • OURSINS (plugin Oursins), est une extension efficace et opérationnelle proposée par Lionel Cacheux et maintenue sur son dépôt Github ici et qui, comme son nom ne l’indique pas, permet de représenter soit tous les flux soit une sélection d’entre eux ; elle n’est donc pas limitée à la seule représentation dite en « oursins ».
  • MMQgis (Plugin MMQgis), est une extension proposée par Michael Minn (présentée ici) permettant notamment de cartographier des flux. Le groupe fmr a déja mentionné (ici) le tutoriel que Laurent Jégou en a proposé sur le PortailSIG pour réaliser de « jolies cartes de flux ». De mon point de vue, cette application très complète par bien des aspects présente trois inconvénients pour la représentation de flux : 1) elle fonctionne mal sur Mac, ce qui est pour le moins gênant ; 2) elle mobilise deux fichiers de nœuds pour tracer les liens et 3) elle impose la sélection a priori des nœuds d’origine (les hub) alors que ces derniers peuvent justement être révélés par l’analyse statistique, par l’exploration des valeurs de la matrice via leur cartographie puisque l’on est dans un environnement SIG. Cette application permet donc de représenter, à l’échelle interne, des « oursins » soit un phénomène d’accessibilité (des flux selon la focale des lieux de destinations) et non d’interactions … ;
  • FLOWMAPPER plugin for QGIS2x (Plugin FlowMapper), développée par Cem Gulluoglu, correspond à la version QGIS du FLOWMAPPER de Waldo Tobler, sachant que la version pour ArcGis de ce même logiciel ne semble pas (à ma connaissance) été actualisée depuis la version 10x du logiciel. Je suis donc d’emblée plutôt favorable à son utilisation, ce d’autant plus qu’elle permet de représenter les trois principaux types de matrices (asymétriques : les valeurs observées ; symétriques : le volume bilatéral  et antisymétriques : le solde bilatéral). A noter cependant qu’elle nécessite quelques précautions à l’installation : la présence de Python 2.6 (déjà effectuée si vous utilisez également ArcGis) et OGR/GDAL, sinon je vous conseille de suivre les conseils de l’auteur ici, ainsi que ses développements en cours sur son dépôt Github, son installation n’est pas très simple, ce qui peut être pénible ;
  • ARROWS est le nom de deux extensions :
    • La première, très intéressante ne mentionne pas le nom du développeur. Elle permet de générer des bandes orientées (ou non) à partir de liens existants, une documentation bien complète est disponible sur Géoinformations, le site de l’espace interministériel de l’information géographique, accessible ici ;
    • La seconde (Plugin Arrows), développée par Grégoire Piffault est également intéressante : elle permet aussi de générer des bandes orientées à partir de lignes et polylignes (mais je ne l’ai pas testée) ;
  • RTQSPIDER (Plugin rt_qspider), est une extension développée par Giuseppe Sucameli, pour Faunalia, disponible ici sur leur dépôt Github. Cette application est très facile d’accès, simple dans son utilisation et efficace. Elle ne pose aucun problème particulier. Elle permet de tracer des liens (que l’on va ensuite éventuellement pouvoir transformer en bande via ARROWS de Géoinformations ici) à partir d’un unique fichier .csv que l’on va transformer à loisir pour créer des nœuds, des liens et calculer différents attributs grâce aux outils intégrés de QGIS. Si elle peut apparaître comme la moins aboutie par rapport à MMQGIS ou FLOWMAPPER, elle présente l’avantage de la simplicité et de permettre de conserver une très grande liberté dans l’analyse des flux
  • QGIS RESOURCE SHARING (Plugin Resource sharing), une extension développée par Akbar Gumbira pour accéder aux ressources partagées par les utilisateurs, en particulier Flow map arrows proposé par Anita Graser.

Il est possible d’aller plus loin en explorant les ressources disponibles dans la planète QGIS, en particulier celles dédiées aux flux : Movement data in GIS #5: current research topics.

Outils mobilisés dans l’atelier

La séance sera réalisée sur la version en cours de QGIS : 2.18 Las Palmas.

Il est nécessaire de télécharger les extensions suivantes sur le site officiel des plugins QGIS, leur installation pourra être effectuée sur place :

  • pour préparer les données de flux : éventuellement les extensions STATIST et GROUPSTATS ; les outils VECTEUR (éventuellement Geoprocessing / Réallocation de champs) étant déjà intégrés  ;
  • pour tracer des liens et des bandes : RTQSPIDER, ARROWS de Géoinformations,  éventuellement OURSINS ;
  • pour symboliser les liens, les outils intégrés de QGIS seront utilisés ;
  • pour styliser les liens, les ressources de  Anita Graser (en particulier New style flow map et Gradient Arrows) accessibles via le Plugin Resource sharing

Ces séances ont lieu les mardis matin de 10 heures à midi au 13 rue du Four à Paris, 5e étage, bibliothèque. Elles sont ouvertes à toute personne intéressée mais il peut être prudent de signaler sa venue (groupe_fmr@yahoo.fr), la bibliothèque étant vite remplie.

Françoise Bahoken

Géographe et cartographe, Chargée de recherches à l'IFSTTAR et membre-associée de l'UMR 8504 Géographie-Cités.

More Posts

10 janvier 2017 : Analyse de graphe avec QGis

La prochaine séance du groupe fmr aura lieu le mardi 10 janvier 2017 à 10h, au 13 rue du four, 5e étage, bibliothèque, Paris. Elle portera sur l’analyse de graphes planaires (mais pas seulement) avec QGIS,
Séance animée par Ryma Hachi et Serge Lhomme.

Cette séance sera décomposée en deux parties : une première partie présentera l’extension nommée « Network_analysis » (http://serge.lhomme.pagesperso-orange.fr/dev.html) ; une deuxième partie sera consacrée à l’extension « Spatial Design Network Analysis » (sDNA) (http://www.cardiff.ac.uk/sdna/).
Dans les deux cas, il faudra bien entendu vous munir d’une version de QGIS (http://www.qgis.org/fr/site/forusers/download.html). A titre d’information, la version 2.14 est parfaitement adaptée.

Pour la partie consacrée à l’extension « Network_analysis », il faudra télécharger le dossier zippé suivant : http://serge.lhomme.pagesperso-orange.fr/data/network_analysis_1_2.zip. Attention, si votre version de QGIS est un peu datée (inférieure à la version2.4), veuillez aussi télécharger ce dossier : http://serge.lhomme.pagesperso-orange.fr/data/network_analysis_1_1.zip. Pour l’installation de cette extension, c’est simple et rapide, elle pourra donc être effectuée juste avant le début de la séance (à 9h45). Les données de cette partie sont téléchargeables en suivant ce lien : https://faust.u-pec.fr/get?k=2slxm3mKYoxMmJY6L1WCette première partie permettra d’aborder les questionnements liés à la différenciation entre effets réseaux et effets spatiaux, de tester les propriétés scale-free d’un graphe, de générer et de « simplifier » des graphes spatialisés (planaires ou non planaires) à partir de données diverses.

La deuxième partie permettra d’aborder plus particulièrement le cas des réseaux intra-urbains (le réseau de rues en l’occurrence), avec la présentation de l’extension sDNA, particulièrement adaptée aux données type OpenStreetMap.
Sur cette page : http://www.cardiff.ac.uk/sdna/software/download/ vous pourrez demander un numéro de série (gratuit), puis télécharger l’extension. Il n’existe pas de version Mac, et il faut a minima QGIS 2.8.
Une fois l’extension téléchargée, son installation est relativement simple (elle pourra également être effectuée juste avant la séance).
L’extension sDNA requiert des données au format SIG (shapefile). Nous ferons un test sur le réseau de rues de Paris au XIXe siècle (données téléchargeables ici : https://filex.univ-paris1.fr/get?k=nsOl3HqSpK0ydOmKjDr). Nous verrons comment préparer le réseau, calculer des indicateurs (de centralité…), puis nous discuterons les résultats.

Analyse des forces et des faiblesses d’un réseau avec R : le package NetSwan

Suite à l’école thématique RESEM « Etudier les réseaux sociaux : espaces, mobilités » qui s’est tenue du 21 au 25 septembre sur l’île d’Oléron, je me suis dit qu’il serait pertinent de sensibiliser davantage d’autres disciplines aux extensions que je développe concernant l’analyse des forces et des faiblesses des réseaux. En effet, durant cette école thématique pluridisciplinaire, seuls des géographes m’ont posé des questions concernant le plugin QGIS que je développe périodiquement. Il faut dire que les SIG restent avant tout utilisés par des géographes et que le plugin en question se focalise sur des réseaux spatiaux !

Ainsi, durant la semaine de pause pédagogique de cette fin d’octobre, j’ai entrepris d’écrire quelques fonctions permettant d’analyser les forces et les faiblesses d’un réseau à l’aide du logiciel R. Puis, afin de diffuser ces fonctions, je n’ai trouvé d’autres solutions que de produire un package. Autant le dire de suite, l’aide est très cursive et rédigée dans un anglais très moyen. Néanmoins, ce package est depuis le 31 octobre disponible sur le CRAN. Une des tâches les plus difficiles a finalement été de trouver un nom à ce package : ce sera finalement NetSwan pour « NETwork Strengths and Weaknesses ANalysis ». Ce package repose sur le package Igraph.

Cette version 0.1 est un ballon d’essai visant à étudier si ces développements sont pertinents en dehors du champ des réseaux spatiaux. Ainsi, seulement quatre fonctions sont proposées actuellement. Une fonction « swan_efficiency » qui se focalise sur la comparaison des valeurs d’éloignement entre le réseau normal et le réseau perturbé. Une fonction « swan_closenness » qui se focalise sur la comparaison des valeurs de proximité entre le réseau normal et le réseau perturbé. Une fonction « swan_connectivity » qui mesure le nombre de relations rendues impossibles lorsqu’un nœud est supprimé. Une fonction « swan_combinatory » qui reproduit les algorithmes d’erreurs et d’attaques développés par Albert et al. [1] [2].

Au-delà des exemples proposés dans l’aide, nous pouvons désormais analyser un réseau social aspatial comme le Zachary Karaté Club et tester sa résistance aux algorithmes développés par Albert et al. Pour cela, il convient de taper le code suivant :

library(igraph)
library(NetSwan)
karate<-make_graph("zachary")

res<-swan_combinatory(karate,10)

Le plus long consiste finalement à produire le graphique représentant les résultats de l’analyse :

plot(res[,1], res[,5], type="o", col="yellow", xlab="Fraction of nodes removed", ylab="Connectivity loss")
lines(res[,1],res[,3], type="o", col="red")
lines(res[,1],res[,4], type="o", col="orange")
lines(res[,1],res[,2], type="o", col="blue")
legend("bottomright",c("Random", "Betweenness", "Degree", "Cascading"),
lty=c(1,1,1,1), pch=c(1,1,1,1),

col=c("yellow","blue","red", "orange"))

Le code final est disponible ici. Il apparaît qu’avec 3 nœuds supprimés, il est possible de perturber plus de 60% des relations de ce réseau, quel que soit le type d’attaques. Seules les erreurs aléatoires produisent des perturbations moins importantes.

Si le besoin s’en fait ressentir, les pistes de développement pour ce package sont nombreuses. Premièrement, ce package ne supporte que les graphes définis avec igraph, il serait tout aussi pertinent de permettre l’analyse de graphes construits avec d’autres packages, comme par exemple statnet. Deuxièmement, les fonctions développées dans NetSwan proviennent avant tout de travaux se focalisant sur l’analyse des forces et des faiblesses de réseaux spatiaux. Il conviendrait de développer plus de fonctions qui tiennent compte des particularités des réseaux non spatiaux.

Serge Lhomme

Maitre de conférences à l'université Paris Est Créteil - Docteur en géographie de l'université Paris VII spécialité "dynamique des milieux et risques"

More Posts - Website

ENPC TD1 : Python (NetworkX) et analyse de réseaux

Dans le cadre d’un enseignement sur les risques à l’Ecole Nationale des Ponts et Chaussées, j’ai élaboré une séquence de cours concernant plus spécifiquement les réseaux techniques. Ce billet propose le résumé d’une séance qui est en lien direct avec les préoccupations de ce blog, puisqu’elle traite de l’analyse de réseaux avec une bibliothèque Python nommée NetworkX. Pour reproduire ce billet, il conviendra bien entendu d’installer Python, puis les bibliothèques : Numpy, Scipy et NetworkX 1.7.

Pour ce billet, nous disposons d’un fichier Python définissant trois listes (ici). Ces listes correspondent à une modélisation simplifiée d’un graphe du réseau autoroutier français. Il convient tout d’abord d’ouvrir ce fichier dans l’IDLE Python, puis d’exécuter ce code. Il est alors possible de construire le graphe du réseau à étudier.

import networkx as nx # import de la bibliothèque networkx
g=nx.Graph() # création du graphe g
g.add_edges_from(arcs) # ajout des arcs de la liste arc au graphe
print(g.nodes()) # consultation des nœuds du graphe g

print(g.edges()) # consultation des arcs du graphe g

Plusieurs indicateurs pouvant nous servir par la suite peuvent être calculés. Pour chaque nœud, on peut ainsi calculer le degré, la centralité intermédiaire ou l’intermédiarité (betweenness), l’éloignement moyen.

deg=nx.degree(g) # calcul des degrés des nœuds du graphe g
bet=nx.betweenness_centrality(g)  # calcul des centralités
aspl=nx.average_shortest_path_length(g)

print(aspl) # consultation des éloignements moyens

Si l’on souhaite afficher le nom des villes suivant leur niveau de centralité intermédiaire, il est possible d’utiliser la bibliothèque Operator :

import operator # import de la bibliothèque operator
tri=sorted(bet.items(), reverse=True, key=operator.itemgetter(1))
for i in range(len(tri)): # boucle affichant le nom des villes

    print(villes[int(tri[i][0])])# en fonction de l’opération de tri

Pour analyser les forces et les faiblesses d’un réseau, il faut le mettre à l’épreuve. Pour cela, il existe un moyen radical : supprimer des éléments du réseau et recalculer des indicateurs calculés au préalable afin de comparer les résultats obtenus. Pour un réseau transport, l’éloignement moyen peut être considéré comme un indicateur pertinent. Afin de conserver un graphe « intact », il peut être pertinent de travailler sur un deuxième graphe créé pour être perturbé.

g2=nx.Graph() # création du graphe g2 créé pour être perturbé
g2.add_edges_from(arcs) # le graphe g2 est au départ identique au graphe g
g2.remove_node(20) # suppression du nœud 20
aspl2=nx.average_shortest_path_length(g2) # calcul sur le graphe perturbé
vul20=aspl2-aspl # comparaison des valeurs obtenues pour un même indicateur

print(vul20) # affichage du résultat correspondant à la perturbation engendrée par la suppression du nœud 20

Dès lors, il est possible de généraliser ce calcul pour l’ensemble des nœuds du réseau étudié :

vul=[] # création du tableau qui contiendra les résultats
for i in range(len(g.nodes())): # boucle de la taille du nombre de nœuds
   g2=nx.Graph() # à chaque itération, création du graphe g2 qui sera perturbé
   g2.add_edges_from(arcs) # le graphe g2 est au départ identique au graphe g
   g2.remove_node(i) # à chaque itération, suppression d’un nœud (le numéro i)
   aspl2=nx.average_shortest_path_length(g2) # calcul sur le graphe perturbé
   dif=aspl2-aspl # à chaque itération on calcule la perturbation engendrée

   vul=vul+[(i,dif)] # ajout dans le tableau de la valeur obtenue pour un nœud supprimé

Néanmoins, à partir du 8ème élément (print(vul)), une erreur se produit. En effet, retirer un ou plusieurs éléments à un réseau n’est pas une opération neutre. En l’occurrence, certains éléments, s’ils sont retirés, peuvent notamment engendrer des ruptures de connexité (des pertes de connectivité). Ici, les ruptures de connexité engendrent l’impossibilité de calculer l’éloignement moyen puisque certaines distances deviennent incalculables (ces distances tendent en fait vers l’infini). Il faut alors créer des exceptions.

vul=[] # création du tableau qui contiendra les résultats
for i in range(len(g.nodes())): # même code que ci-dessus
   if (i!=8 and i!=53): # on rajoute juste deux exceptions
      g2=nx.Graph()
      g2.add_edges_from(arcs)
      g2.remove_node(i)
      aspl2=nx.average_shortest_path_length(g2)
      dif=aspl2-aspl

      vul=vul+[(i,dif)]

Comme précédemment, il est possible de trier les résultats obtenus afin d’identifier les éléments les plus problématiques. Il apparaît alors que ces éléments sont presque identiques à ceux apparaissant comme les plus centraux.

On peut alors chercher à mesurer le degré d’intensité de la relation existant entre la « vulnérabilité » et la « centralité » d’un nœud. Pour cela, il convient de trouver un indicateur de vulnérabilité pouvant se calculer pour tous les nœuds. NetworkX propose un indicateur qui fonctionne comme nous avons procédé, mais en utilisant un indicateur de proximité (closeness) et non d’éloignement, ce qui permet de palier au problème de rupture de connexité (en effet, en s’appuyant sur les inverses des distances, les valeurs tendant vers l’infini tendent vers zéro).

import numpy
vul2=nx.closeness_vitality(g) # calcul de vulnérabilité avec networkx
mvul2=list(vul2.items()) # transforme la bibliothèque en une liste
avul2=numpy.array(mvul2) # transforme cette liste en une array
x=avul2[:,1] # la variable x correspondant à la vulnérabilité des nœuds
mbet=list(bet.items()) # transforme la bibliothèque en une liste
abet=numpy.array(mbet) # on transforme cette liste en une array
y=abet[:,1] # la variable y correspondant à la centralité des nœuds
from scipy import stats
slope, intercept, r_value, p_value, std_err = stats.linregress(x,y)
r2=r_value*r_value # calcul du r2

print(r2) # affichage du r2

A la fin, on obtient un code propre que vous pouvez télécharger ici. S’il existe un lien entre vulnérabilité et centralité, celui-ci est imparfait. On essaiera de le montrer dans un prochain billet relatif à ces enseignements.

Serge Lhomme

Maitre de conférences à l'université Paris Est Créteil - Docteur en géographie de l'université Paris VII spécialité "dynamique des milieux et risques"

More Posts - Website

Cartographie de flux avec le package cartography

Depuis hier, le package cartography développé par nos collègues Timothée Giraud (http://rgeomatic.hypotheses.org/) et Nicolas Lambert (http://neocarto.hypotheses.org), tous deux ingénieurs à l’UMS RIATE, est en ligne sur le CRAN. Il permet de faire beaucoup de cartes différentes dont des cartes de flux. Le script et les données utilisés dans ce billet sont téléchargeables ici (j’arrête provisoirement github, j’y fais un peu n’importe quoi…) – le script est encodé en utf-8 (pour règler l’encodage dans RStudio : Tools > Global Options > Default text encoding).

La documentation sur les fonctions est lisible et homogène et les exemples fonctionnent mais, bien entendu, ce qui est intéressant est de pouvoir importer et cartographier ses propres données. Deux fichiers sont attendus en entrée : une liste de liens (origine, destination, intensité de la relation) et un fond de carte au format .shp. Les deux donneront dans R un data.frame et un  SpatialPolygonsDataFrame (noté SPDF dans la suite du  billet). Il est bien entendu nécessaire que le code des unités spatiales soit le même dans les deux fichiers…

La première étape consiste à attribuer des coordonnées à la liste de liens à l’aide de la fonction getLinkLayer. La fonction prend comme argument : le nom du SPDF et les colonnes origine-destination du data.frame. Si l’identifiant commun n’est pas la première colonne du SPDF, il est nécessaire de préciser la colonne adéquate avec l’argument spdfid = « Nom_de_la_colonne ». Dans l’exemple téléchargeable, l’argument est utilisé.

La fonction plot(SPDF) permet ensuite de visualiser le fond de carte.

Deux fonctions permettent de cartographier les flux : propLinkLayer (épaisseur proportionnelle à l’intensité) et gradLinkLayer (flux discrétisés). Le script téléchargeable devrait vous permettre de comprendre la logique d’utilisation et les principales options. Dans les deux cas, l’orientation des flux n’apparaît malheureusement pas.

Signalons enfin la fonction legendPropLines qui permet de personnaliser la légende de la carte réalisée (fonction non encore testée à ce jour).

La réalisation de cartes est plutôt aisée mais, comme toujours pour la cartographie des flux, cela ne garantit pas nécessairement un résultat d’une grande lisibilité…