Introduction à COGugaison

Nous allons balayer dans cette vignette les principales fonctionnalités du package COGugaison.

Le découpage des territoires français, en particulier les communes, n’est pas un phénomène immuable. Chaque année certaines communes changent de codes, ou bien de nom, fusionnent ou encore se divisent. Certains périmètres supra-communaux changent également, comme celui des cantons qui a été récemment redéfini. C’est à l’Insee que revient le suivi de ces changements afin d’établir chaque année le code officiel géographique (COG).

Ce package R a alors pour objectif global de manipuler des données communales produites à différents millésimes et de les agréger à différents niveaux supra-communaux. Plus précisément, il permet actuellement de :

  • détecter le millésime du code officiel géographique d’une table de données communales : fonction COG_akinator, faire un diagnostic de COG plus détaillé avec diag_COG et apparier une liste de communes d’une base de données avec celle du COG d’un millésime donné avec apparier_COG
  • visualiser les modifications communales (fusions, défusions, changements de codes ou de noms) qui ont eu lieu entre deux dates : modifications_communales
  • visualiser sur un graphique interactif la trajectoire d’une commune donnée, c’est-à-dire toutes les modifications qui ont eu lieu depuis 1968 : trajectoire_commune et trajectoire_commune_shiny.
  • transformer des tables de données numériques en géographie au premier janvier d’une année souhaitée : changement_COG_varNum.
  • transformer des typologies de communes en géographie au premier janvier d’une année souhaitée en ayant le choix entre plusieurs hypothèses de classement en cas de fusion de communes de classes différentes (attribuer une unique classe à toutes les communes fusionnées, attribuer la classe qui contient le plus de population, définir une classe absorbante, une classe absorbée ou une classe spécifique aux regroupements de plusieurs communes de classes différentes) : changement_COG_typo. Il est également possible d’isoler dans une table les communes fusionnées appartenant à des classes différentes : changement_COG_typo_details.
  • permettre d’agréger les tables de données communales à de nombreux échelons supra-communaux administratifs (EPCI, arrondissements, cantons-villes, départements, régions) ou d’étude (bassins de vie, zones d’emploi, unités urbaines, aires urbaines) : nivsupra.
  • gérer des cas particuliers comme les codes Insee des communes corses (modification_Corse) ou des arrondissements municipaux de Paris, Lyon, et Marseille (enlever_PLM) ou encore l’ancienne commune de l’Oudon (modification_Oudon)

Il est important de souligner que les données utilisées ici s’appuient sur des tables publiées par l’Insee :

Il est évidemment conseillé de se référer aux données officielles de l’Insee en cas de doute sur un résultat.

Commençons par installer le package COGugaison et à le charger dans R.

#devtools::install_github("antuki/COGugaison")
library(COGugaison)
## Afin de mieux connaitre les utilisateurs des packages COGugaison et CARTElette et de mieux repondre a vos besoins, merci de repondre a cette rapide enquete en ligne :
## https://antuki.github.io/2019/11/08/opinion_package/

Le millésime le plus récent contenu dans le package peut être visualisé de la manière suivante :

COGugaison:::annee_ref
## [1] 2023

Les bases de données utiles dans COGugaison

En plus de contenir des fonctions permettant la gestion des codes officiels géographiques, COGugaison contient également, dans des Rdata, des bases de données qui peuvent vous être également utiles par ailleurs.

  • COG

Ce Rdata contient des data.frame (tables de données) intitulés COGXXXX, XXXX étant à remplacer par une année de COG donnée. Les tables intitulées COGXXXX_insee correspondent à des tables selon le COG pris en compte par l’Insee dans la diffusion de ses données (qui est presque identique au COG à quelques exceptions près listées dans la documentation).

head(COG2017)
##   CODGEO                  LIBGEO   POP
## 1  01001 L'Abergement-Clémenciat   767
## 2  01002   L'Abergement-de-Varey   241
## 3  01004       Ambérieu-en-Bugey 14127
## 4  01005     Ambérieux-en-Dombes  1619
## 5  01006                 Ambléon   109
## 6  01007                Ambronay  2615

Les variables des tables sont les suivantes :

  • CODGEO contient le code Insee des communes
  • LIBGEO contient le nom des communes
  • POP contient la population de référence de la commune selon l’année du COG
  • TABLES_PASSAGE

Ce Rdata contient des data.frame intitulées PASSAGE_XXXX_YYYY, XXXX et YYYY étant à remplacer par des années de COG données. Il s’agit de tables de passages permettant de passer d’un COG à un autre (plus récent ou plus ancien). Le suffixe “_insee” correspond également à des tables qui tiennent compte des COG pris en compte par l’Insee.

head(PASSAGE_2015_2016_insee)
##   cod2015 cod2016      annee typemodif ratio
## 1   14697   14472 2016-01-01         c     1
## 2   01015   01015 2016-01-01         f     1
## 3   01340   01015 2016-01-01         f     1
## 4   01080   01080 2016-01-01         f     1
## 5   01119   01080 2016-01-01         f     1
## 6   01176   01187 2016-01-01         f     1

Les variables des tables sont les suivantes :

  • codXXXX : code Insee de la commune de départ
  • codYYYY : code Insee de la commune d’arrivée
  • annee : année de la modification
  • typemodif : type de modification communale (f = fusion, d = défusion, c= changement de code).
  • ratio : poids de répartition des effectifs en cas de défusion (vaut 1 sinon). Ce poids est proportionnel à la population des communes défusionnées.
  • DATA_SUPRACOM

Ce Rdata contient, pour chaque année depuis 2014, deux data.frame intitulées table_supracom_20XX et libelles_supracom_20XX qui correspondent aux tables d’appartenance des communes aux différents niveaux géographiques produites par l’Insee (cliquez sur le lien pour voir la documentation sur les variables présentes). La première table associe chaque code communal insee aux niveaux supra-communaux associés (en COG le plus actuel, actuellement 2017) et la seconde indique les libellés de ces différents niveaux supra-communaux.

head(table_supracom_2017)
##   CODGEO                  LIBGEO DEP REG      EPCI NATURE_EPCI ARR   CV ZE2010
## 1  01001 L'Abergement-Clémenciat  01  84 200069193          CC 012 0108   8213
## 2  01002   L'Abergement-de-Varey  01  84 240100883          CC 011 0101   8201
## 3  01004       Ambérieu-en-Bugey  01  84 240100883          CC 011 0101   8201
## 4  01005     Ambérieux-en-Dombes  01  84 200042497          CC 012 0122   8213
## 5  01006                 Ambléon  01  84 200040350          CC 011 0104   8216
## 6  01007                Ambronay  01  84 240100883          CC 011 0101   8201
##   UU2010 TUU2014 TDUU2014 AU2010 TAU2014 CATAEU2010 BV2012
## 1  01000       0       05    997      00        120  01093
## 2  01000       0       04    002      09        112  01004
## 3  01302       3       32    002      09        112  01004
## 4  01000       0       06    002      09        112  69123
## 5  01000       0       03    998      00        300  01034
## 6  01000       0       07    002      09        112  01004
head(libelles_supracom_2017)
##   NIVGEO CODGEO          LIBGEO NB_COM
## 1    ARR    011          Belley    115
## 2    ARR    012 Bourg-en-Bresse    201
## 3    ARR    013             Gex     27
## 4    ARR    014          Nantua     65
## 5    ARR    021 Château-Thierry    108
## 6    ARR    022            Laon    244
  • HISTORIQ_MODIF_COM

Ce Rdata contient un data.frame intitulé historiq qui correspond à l’historique des géographies communales produit par l’Insee (cliquez sur le lien pour voir la documentation sur les variables présentes). La dernière édition de ce fichier date de 2018 car l’Insee a changé le format de mise à disposition de cette base en 2019 et cette mise à jour n’a pas encore été effectuée dans le package.

Quel code officiel géographique est utilisé ?

Nous allons maintenant manipuler une table exemple incluse dans le package, la table exemple_popcom qui contient comme variables le code géographique de la commune (CODGEO), son nom (LIBGEO), sa population en 2012 (P12_POP), sa superficie (SUPERF) ainsi que deux typologies de territoires générées aléatoirement (typoA et typoB). Il faut veiller à ce que les variables numériques soient au bon format dans R et que les typologies et identifiants soient au format caractère (si ce n’est pas le cas, il faudra les transformer avec les fonctions as.numeric et as.character).

head(exemple_popcom)
##   CODGEO                  LIBGEO P12_POP SUPERF    typoA typoB
## 1  01001 L'Abergement-Clémenciat     777     16 CLASSE 2     F
## 2  01002   L'Abergement-de-Varey     235      9 CLASSE 3     D
## 3  01004       Ambérieu-en-Bugey   14233     25 CLASSE 1     B
## 4  01005     Ambérieux-en-Dombes    1642     16 CLASSE 3     F
## 5  01006                 Ambléon     110      6 CLASSE 4     E
## 6  01007                Ambronay    2437     34 CLASSE 5     A
str(exemple_popcom)
## 'data.frame':    36664 obs. of  6 variables:
##  $ CODGEO : chr  "01001" "01002" "01004" "01005" ...
##  $ LIBGEO : chr  "L'Abergement-Clémenciat" "L'Abergement-de-Varey" "Ambérieu-en-Bugey" "Ambérieux-en-Dombes" ...
##  $ P12_POP: int  777 235 14233 1642 110 2437 739 338 1069 385 ...
##  $ SUPERF : int  16 9 25 16 6 34 5 7 29 15 ...
##  $ typoA  : chr  "CLASSE 2" "CLASSE 3" "CLASSE 1" "CLASSE 3" ...
##  $ typoB  : chr  "F" "D" "B" "F" ...
##  - attr(*, "spec")=List of 2
##   ..$ cols   :List of 6
##   .. ..$ CODGEO : list()
##   .. .. ..- attr(*, "class")= chr [1:2] "collector_character" "collector"
##   .. ..$ LIBGEO : list()
##   .. .. ..- attr(*, "class")= chr [1:2] "collector_character" "collector"
##   .. ..$ P12_POP: list()
##   .. .. ..- attr(*, "class")= chr [1:2] "collector_integer" "collector"
##   .. ..$ SUPERF : list()
##   .. .. ..- attr(*, "class")= chr [1:2] "collector_integer" "collector"
##   .. ..$ typoA  : list()
##   .. .. ..- attr(*, "class")= chr [1:2] "collector_character" "collector"
##   .. ..$ typoB  : list()
##   .. .. ..- attr(*, "class")= chr [1:2] "collector_character" "collector"
##   ..$ default: list()
##   .. ..- attr(*, "class")= chr [1:2] "collector_guess" "collector"
##   ..- attr(*, "class")= chr "col_spec"

COG_akinator

La fonction COG_akinator permet de donner des pistes à l’utilisateur sur le code officiel géographique (COG) utilisé dans sa table de données communales, c’est-à-dire de savoir si la liste de communes utilisée correspond à la liste officiel au premier janvier de 2017 ? de 2016 ? ou d’une autre année.

Le paramètre donnees_insee vaut TRUE si les données manipulées sont produites par l’Insee. En effet, quelques rares modifications communales (la défusion des communes Loisey et Culey au 1er janvier 2014 par exemple) ont été prises en compte dans les bases de données communales de l’Insee plus tard que la date officielle (se référer à la documentation de la fonction pour plus de précisions).

COG_akinator(vecteur_codgeo = exemple_popcom[,1], donnees_insee = TRUE)
## [1] "COG2014"

En l’occurrence la liste de communes utilisée dans cette table correspond à la liste des communes au 1er janvier 2014.

apparier_COG

Une fois que le COG d’une base de données est détecté, ou bien si justement le COG n’arrive pas à être détecté par la fonction COG_akinator, il est possible d’utiliser la fonction apparier_COG pour comparer la liste des communes présente dans une table de données avec le COG d’un millésime donné.

COG_akinator(exemple_popcom$CODGEO, donnees_insee = TRUE)
## [1] "COG2014"
apparier_COG(vecteur_codgeo = c(exemple_popcom[which(exemple_popcom$CODGEO!="01001"),1],"XXXXX"),
             donnees_insee = TRUE, COG = 2014)
## $absent_de_bdd
##  [1] "01001" "97601" "97602" "97603" "97604" "97605" "97606" "97607" "97608"
## [10] "97609" "97610" "97611" "97612" "97613" "97614" "97615" "97616" "97617"
## 
## $absent_de_COG
## [1] "XXXXX"
appariement <- apparier_COG(vecteur_codgeo = c(exemple_popcom[which(exemple_popcom$CODGEO!="01001"),1],"XXXXX"),
                            donnees_insee = TRUE, COG = 2014)
cat(appariement$absent_de_bdd)
## 01001 97601 97602 97603 97604 97605 97606 97607 97608 97609 97610 97611 97612 97613 97614 97615 97616 97617
cat(appariement$absent_de_COG)
## XXXXX
# regarder le libellé des communes présentes dans le COG mais pas dans la base de données
COG2014_insee[which(COG2014_insee$CODGEO %in% appariement$absent_de_bdd),c(1,2)]
##       CODGEO                  LIBGEO
## 1      01001 L'Abergement-Clémenciat
## 36665  97601                   Acoua
## 36666  97602              Bandraboua
## 36667  97603                Bandrélé
## 36668  97604                  Bouéni
## 36669  97605                 Chiconi
## 36670  97606               Chirongui
## 36671  97607                 Dembeni
## 36672  97608                Dzaoudzi
## 36673  97609                KaniKéli
## 36674  97610                 Koungou
## 36675  97611               Mamoudzou
## 36676  97612               Mtzamboro
## 36677  97613            Mtsangamouji
## 36678  97614                Ouangani
## 36679  97615                Pamandzi
## 36680  97616                    Sada
## 36681  97617                Tsingoni

diag_COG

Enfin, la fonction diag_COG permet de vous outiller encore davantage. Elle réalise un diagnostic complet du ou des COG présents dans votre base de données.

diagnostic <- diag_COG(exemple_popcom)
## [1] "# ------------------------------"
## [1] "# DIAGNOSTIC DE COG"
## [1] "# ------------------------------"
## [1] "# Synthèse"
## [1] "# COG2014"
## [1] "# ------------------------------"
## [1] "# Diagnostic détaillé"
## [1] "# Le fichier compte 36664 codes communes."
## [1] "# Le diagnostic de COG correspond au COG le plus récent dans lequel l'ensemble des codes communes du fichier en entrée sont présents."
## 
## 
## |              | Nombre d'observations|
## |:-------------|---------------------:|
## |COG2014       |                 36664|
## |codes uniques |                 36664|
head(diagnostic)
##   CODGEO diag_cog                  LIBGEO P12_POP SUPERF    typoA typoB
## 1  01001  COG2014 L'Abergement-Clémenciat     777     16 CLASSE 2     F
## 2  01002  COG2014   L'Abergement-de-Varey     235      9 CLASSE 3     D
## 3  01004  COG2014       Ambérieu-en-Bugey   14233     25 CLASSE 1     B
## 4  01005  COG2014     Ambérieux-en-Dombes    1642     16 CLASSE 3     F
## 5  01006  COG2014                 Ambléon     110      6 CLASSE 4     E
## 6  01007  COG2014                Ambronay    2437     34 CLASSE 5     A

Ici le diagnostic nous montre que la base de données est bien construite puisqu’elle ne comporte que des codes communes d’une même année, 2014.

Mais cette fonction permet également de diagnostiquer des bases de données qui comportent des mix entre plusieurs COG (oh, horreur !) comme dans l’exemple ci-dessous :

exemple_popcom_deforme <- exemple_popcom %>% 
  add_row(CODGEO = c(rep("01001",5),"76601","75101",NA,"98756","ZZZZZ"))
diagnostic2 <- diag_COG(exemple_popcom_deforme)
## [1] "# ------------------------------"
## [1] "# DIAGNOSTIC DE COG"
## [1] "# ------------------------------"
## [1] "# Synthèse"
## [1] "# COG non identifiable"
## [1] "# ------------------------------"
## [1] "# Diagnostic détaillé"
## [1] "# Le fichier compte 36674 codes communes."
## [1] "# Dans la mesure où le COG n'est pas identifiable, pour chaque commune considérée, le diagnostic de COG correspond au COG le plus récent qui contient son code commune."
## 
## 
## |                         | Nombre d'observations|
## |:------------------------|---------------------:|
## |2023                     |                 34932|
## |2015                     |                   773|
## |2016                     |                   467|
## |2018                     |                   387|
## |2017                     |                    59|
## |2014                     |                    25|
## |2022                     |                    21|
## |2019                     |                     3|
## |2020                     |                     3|
## |arrondissement municipal |                     1|
## |code indéterminé         |                     1|
## |code manquant            |                     1|
## |collectivité d'outre-mer |                     1|
## |codes uniques            |                 36669|

La fonction diag_COG ne reconnaissant pas le COG, elle identifie pour chaque ligne de la table, l’année la plus récente d’apparition de la commune dans les tables de COG.

Toutefois, lorsque le COG est relativement ancien, comme ici 2014, cette sortie par défaut ne permet pas de réaliser diagnostic de COG utile. Il peut alors être utile de faire une hypothèse préalable sur le COG initial de la table, en utilisant notamment la fonction COG_akinator puis le paramètre hypothese_COG de la fonction diag_COG comme ci-après.

COG_akinator(exemple_popcom_deforme$CODGEO)
## [1] "COG2014"
diagnostic3 <- diag_COG(exemple_popcom_deforme, hypothese_COG = 2014)
## [1] "# ------------------------------"
## [1] "# DIAGNOSTIC DE COG"
## [1] "# ------------------------------"
## [1] "# Synthèse"
## [1] "# COG non identifiable"
## [1] "# ------------------------------"
## [1] "# Diagnostic détaillé"
## [1] "# Le fichier compte 36674 codes communes."
## [1] "# Dans la mesure où le COG n'est pas identifiable, pour chaque commune considérée, le diagnostic de COG correspond au COG le plus proche de l'année de référence (2014) qui contient son code commune."
## 
## 
## |                         | Nombre d'observations|
## |:------------------------|---------------------:|
## |2014                     |                 36669|
## |2017                     |                     1|
## |arrondissement municipal |                     1|
## |code indéterminé         |                     1|
## |code manquant            |                     1|
## |collectivité d'outre-mer |                     1|
## |codes uniques            |                 36669|

La sortie est alors davantage conforme aux souhaits de l’utilisateur. Une commune a été identifiée comme étant de COG2017 et est à expertiser. Il s’agit de la commune 76601 qui est issue d’une scission ayant eu lieu en 2017.

Visualiser les modifications communales

La fonction trajectoire_commune permet d’observer sur un diagramme interactif la trajectoire d’une commune depuis 1968 (aucun changement, fusions, défusions ou changements de codes).

Le paramètre codgeo est une chaîne de 5 caractères qui indique le code Insee de la commune considérée et le paramètre COG indique l’année de COG de la communes considérée.

La fonction trajectoire_commune_shiny lance une application shiny qui permet de sélectionner la commune pour laquelle vous souhaitez observer ses modifications depuis 1968.

# Ici, nous allons observer sur un graphique interactif la trajectoire de la commune ayant pour code 01003 en 1968
# (fusion avec 2 autres communes le 1er janvier 1974)
trajectoire_commune("01003", 1968, donnees_insee = FALSE)
# Cette fonction lance une application shiny permettant d'observer toutes les trajectoires des communes.
#trajectoire_commune_shiny()

La fonction modifications_communales permet, comme son nom l’indique, de visualiser les modifications communales (fusions, défusions, changements de codes ou de noms) qui ont eu lieu entre deux dates. Ici entre le 01/01/2014 et le 01/01/2015. Cette fonction est encore en cours de développement il est donc possible que certains évènements ne soient pas encore pris en compte. Il ne faut pas hésiter à le signaler.

modifs <- modifications_communales(date_debut = "01-01-2014", date_fin = "01-01-2015")
## Warning: En raison d'un changement de fichier d'historique de l'Insee en 2019,
## cette fonction n'est à ce stade plus maintenue pour les millésimes après 2018.
cat(modifs$fusions)
## 2015-01-01 : Notre-Dame-d'Estrées-Corbon (14474) est un rassemblement de Corbon (14178), Notre-Dame-d'Estrées (14474) [commune nouvelle avec commune(s) déléguée(s)].
## 2015-01-01 : Auxons (25035) est un rassemblement de Auxon-Dessous (25034), Auxon-Dessus (25035) [commune nouvelle avec commune(s) déléguée(s)].
## 2015-01-01 : Goussainville (28185) est un rassemblement de Champagne (28069), Goussainville (28185) [commune nouvelle avec commune(s) déléguée(s)].
## 2015-01-01 : Eclose-Badinières (38152) est un rassemblement de Badinières (38024), Eclose (38152) [commune nouvelle avec commune(s) déléguée(s)].
## 2015-01-01 : Saint-Crépin-Ibouvillers (60570) est un rassemblement de Montherlant (60417), Saint-Crépin-Ibouvillers (60570) [commune nouvelle avec commune(s) déléguée(s)].
## 2015-01-01 : Montsecret-Clairefougère (61292) est un rassemblement de Clairefougère (61109), Montsecret (61292) [commune nouvelle avec commune(s) déléguée(s)].
## 2015-01-01 : Boischampré (61375) est un rassemblement de Marcei (61249), Saint-Christophe-le-Jajolet (61375), Saint-Loyer-des-Champs (61417), Vrigny (61511) [commune nouvelle avec commune(s) déléguée(s)].
## 2015-01-01 : Tinchebray-Bocage (61486) est un rassemblement de Beauchêne (61031), Frênes (61177), Larchamp (61223), Saint-Cornier-des-Landes (61377), Saint-Jean-des-Bois (61410), Tinchebray (61486), Yvrandes (61513) [commune nouvelle avec commune(s) déléguée(s)].
## 2015-01-01 : Vaugneray (69255) est un rassemblement de Saint-Laurent-de-Vaux (69221), Vaugneray (69255) [commune nouvelle avec commune(s) déléguée(s)].
## 2015-01-01 : Clux-Villeneuve (71578) est un rassemblement de Clux (71138), Villeneuve (71578) [commune nouvelle avec commune(s) déléguée(s)].
## 2015-01-01 : Villeneuve-en-Perseigne (72137) est un rassemblement de Chassé (72069), Fresnaye-sur-Chédouet (72137), Lignières-la-Carelle (72162), Montigny (72207), Roullée (72258), Saint-Rigomer-des-Bois (72318) [commune nouvelle avec commune(s) déléguée(s)].
## 2015-01-01 : Saint-Offenge (73263) est un rassemblement de Saint-Offenge-Dessous (73263), Saint-Offenge-Dessus (73264) [commune nouvelle avec commune(s) déléguée(s)].
## 2015-01-01 : Orvanne (77316) est un rassemblement de Écuelles (77166), Moret-sur-Loing (77316) [commune nouvelle avec commune(s) déléguée(s)].
cat(modifs$defusions)
## ATTENTION, l'évènement suivant a été pris en compte dans les données de l'Insee seulement au 01/01/2015 : 2014-01-01 : Loisey (55298) s'est séparée en Loisey (55298), Culey (55138) [rétablissement].
cat(modifs$changements_codes)
## 2014-01-07 : Le code commune de Oudon passe de 14697 à 14472 [changement de code dû à un changement de chef-lieu].
cat(modifs$changements_noms)
## 2014-12-06 : La commune de Barisis (02049) change de nom en Barisis-aux-Bois [changement de nom].
## 2014-12-06 : La commune de Sainte-Colombe (21544) change de nom en Sainte-Colombe-en-Auxois [changement de nom].
## 2014-12-06 : La commune de Pont-de-Roide (25463) change de nom en Pont-de-Roide-Vermondans [changement de nom].
## 2014-12-06 : La commune de Cazaril-Laspènes (31129) change de nom en Cazarilh-Laspènes [changement de nom].
## 2014-12-06 : La commune de Saint-Martin (66184) change de nom en Saint-Martin-de-Fenouillet [changement de nom].
## 2014-12-06 : La commune de Cré (72108) change de nom en Cré-sur-Loir [changement de nom].
## 2014-12-06 : La commune de Belbèse (82015) change de nom en Belbèze-en-Lomagne [changement de nom].
## 2014-12-06 : La commune de Saint-Vincent (82174) change de nom en Saint-Vincent-d'Autéjac [changement de nom].

Transformer des variables numériques en autre géographie

La fonction changement_COG_varNum permet de transformer des tables de données numériques communales en géographie au premier janvier d’une année souhaitée.

Ici, nous allons transformer les variables numériques de la table exemple_pop afin de récupérer les données de population et de superficie des communes au 1er janvier 2017 (au lieu de 2014).

exemple_popcom_COG2017_num <- changement_COG_varNum(table_entree = exemple_popcom, annees = c(2014:2017),
                                                    agregation = TRUE, libgeo = TRUE, donnees_insee = TRUE)
head(exemple_popcom_COG2017_num)
##   CODGEO             nom_commune P12_POP SUPERF
## 1  01001 L'Abergement-Clémenciat     777     16
## 2  01002   L'Abergement-de-Varey     235      9
## 3  01004       Ambérieu-en-Bugey   14233     25
## 4  01005     Ambérieux-en-Dombes    1642     16
## 5  01006                 Ambléon     110      6
## 6  01007                Ambronay    2437     34

Le paramètre agregation vaut TRUE si la table souhaitée doit sommer toutes les lignes qui concernent une même commune et FALSE si l’on souhaite volontairement conserver les doublons dans les codes commune (dans les tables de flux par exemple, cf. plus bas). Le paramètre libgeo vaut TRUE si l’on veut rajouter dans la table une colonne nommée “nom_commune” qui indique le nom de la commune issu du code officiel géographique et FALSE sinon.

Transformer des typologies en autre géographie

La fonction changement_COG_typo permet de transformer des typologies de communes en géographie au premier janvier d’une année souhaitée. Ici nous allons transformer les deux typologies (typoA et typoB) de la table exemple_pop en géographie communale au 1er janvier 2017 (au lieu de 2014).

Ici, l’hypothèse de classement en cas de fusion de communes (methode_fusion) choisie est celle d’une classe spécifique (methode_difference, classe appelée mot_difference=“differents”) aux regroupements de plusieurs communes de classes différentes. Les autres hypothèses possibles auraient pu être l’hypothèse du maximum de population methode_max_pop, de classe absorbée methode_classe_absorbee, de classe absorbante methode_classe_absorbante ou d’indiquer un nom de classe spécifique pour toutes les communes qui ont fusionnées : methode_classe_fusion. Pour plus de détails, référez-vous à ?changement_COG_typo.

exemple_popcom_COG2017_typo <- changement_COG_typo(table_entree = exemple_popcom[,-2], annees = c(2014:2017),
                                                   methode_fusion = "methode_difference", typos = c("typoA","typoB"),
                                                   mot_difference = "differents", libgeo=TRUE,
                                                   donnees_insee=TRUE)
head(exemple_popcom_COG2017_typo)
##   CODGEO             nom_commune    typoA typoB
## 1  01001 L'Abergement-Clémenciat CLASSE 2     F
## 2  01002   L'Abergement-de-Varey CLASSE 3     D
## 3  01004       Ambérieu-en-Bugey CLASSE 1     B
## 4  01005     Ambérieux-en-Dombes CLASSE 3     F
## 5  01006                 Ambléon CLASSE 4     E
## 6  01007                Ambronay CLASSE 5     A

La fonction changement_COG_typo_details permet quant à elle d’isoler dans une table les communes fusionnées appartenant à des classes différentes, ici selon la typologie “typoA” entre 2014 et 2015 puis 2015 et 2016 et 2016 et 2017.

details_exemple_popcom_COG2017_typo <- changement_COG_typo_details(table_entree = exemple_popcom[,-2],
                                                                   annees = c(2014:2017), typo = "typoA",
                                                                   donnees_insee = TRUE)
head(details_exemple_popcom_COG2017_typo[["2014_2015"]])
##   cod2014              lib2014 cod2015                     lib2015    typoA
## 1   14178               Corbon   14474 Notre-Dame-d'Estrées-Corbon CLASSE 2
## 2   14474 Notre-Dame-d'Estrées   14474 Notre-Dame-d'Estrées-Corbon CLASSE 4
## 3   25034        Auxon-Dessous   25035                  Les Auxons CLASSE 1
## 4   25035         Auxon-Dessus   25035                  Les Auxons CLASSE 3
## 5   38024           Badinières   38152           Eclose-Badinières CLASSE 4
## 6   38152               Eclose   38152           Eclose-Badinières CLASSE 3
head(details_exemple_popcom_COG2017_typo[["2015_2016"]])
##   cod2015             lib2015 cod2016            lib2016    typoA
## 1   01015           Arbignieu   01015    Arboys en Bugey CLASSE 3
## 2   01340          Saint-Bois   01015    Arboys en Bugey CLASSE 2
## 3   01119           Corcelles   01080 Champdor-Corcelles CLASSE 1
## 4   01080            Champdor   01080 Champdor-Corcelles CLASSE 2
## 5   01176 Le Grand-Abergement   01187      Haut Valromey CLASSE 2
## 6   01409             Songieu   01187      Haut Valromey CLASSE 5
head(details_exemple_popcom_COG2017_typo[["2016_2017"]])
##   cod2016             lib2016 cod2017          lib2017    typoA
## 1   01095 Chavannes-sur-Suran   01095 Nivigne et Suran CLASSE 5
## 2   01172           Germagnat   01095 Nivigne et Suran CLASSE 1
## 3   01098         Chazey-Bons   01098      Chazey-Bons CLASSE 3
## 4   01316              Pugieu   01098      Chazey-Bons CLASSE 4
## 5   03168             Meaulne   03168   Meaulne-Vitray CLASSE 2
## 6   03318              Vitray   03168   Meaulne-Vitray CLASSE 5

Agréger des tables de données communales à des échelons supra-communaux

La fonction nivsupra permet d’agréger les tables de données communales à de nombreux échelons supra-communaux administratifs (EPCI, arrondissements, cantons-villes, départements, régions) ou d’étude (bassins de vie, zones d’emploi, unités urbaines, aires urbaines) en indiquant le COG de la base de donnée en entrée et de référence des niveaux supra-communaux grâce au paramètre COG (par défaut vaut la valeur de annee_ref, la plus récente valeur contenue dans le package). Le paramètre COG peut prendre les valeurs 2008 à annee_ref.

Ici nous agrégeons la population et la superficie des communes à l’échelon géographique des zones d’emploi afin d’obtenir une table des densités de population par zone d’emploi.

exemple_popcom_COG2017 <- merge(exemple_popcom_COG2017_num, exemple_popcom_COG2017_typo[,-2], by = "CODGEO",
                                all = TRUE)
exemple_popcom_ZE2010 <- nivsupra(table_entree = exemple_popcom_COG2017, nivsupra="ZE2010", agregation = TRUE,
                                  COG = 2017)
exemple_popcom_ZE2010$densite <- exemple_popcom_ZE2010$P12_POP / exemple_popcom_ZE2010$SUPERF
head(exemple_popcom_ZE2010)
##   ZE2010                         LIBGEO P12_POP SUPERF  densite
## 1   0050                 Mont-de-Marsan  160717   4956 32.42877
## 2   0051                        Alençon  122263   2405 50.83701
## 3   0052                Cosne - Clamecy   75052   2553 29.39757
## 4   0053                          Mâcon  143358   1543 92.90862
## 5   0054               Nogent-le-Rotrou   48665   1227 39.66178
## 6   0055 La Vallée de la Bresle - Vimeu   99095   1134 87.38536

Gérer des cas particuliers dans les bases de données

Enlever les arrondissements municipaux des tables de données communales

Nous allons maintenant manipuler une autre table exemple incluse dans le package, la table exemple_flux qui contient des exemples de flux entre une communes de résidences (COMMUNE) et de travail (DCLT). Elle contient comme autres variables le code de la catégorie socio-professionnelle des individus (CS1), la catégorie d’âge (AGEREVQ) et le poids de l’individu statistique (IPONDI).

head(exemple_flux)
##   COMMUNE  DCLT CS1 AGEREVQ IPONDI
## 1   55298 45055   5      25      4
## 2   55298 52448   3      50      4
## 3   55298 54323   5      55      4
## 4   55298 55010   6      35      4
## 5   55298 55029   6      20      4
## 6   55298 55029   6      40      4

La fonction enlever_PLM permet de remplacer les codes Insee des arrondissements municipaux de Paris, Lyon et Marseille par leurs codes communes respectifs.

Le paramètre vecteur_entree vaut TRUE si l’élément à transformer est un vecteur de codes insee et FALSE s’il s’agit d’une table de données (data.frame) numériques. Attention, cette fonction ne gère pas les conversions de typologies (variables de type caractère).

Ici nous allons remplacer les arrondissement municipaux par les codes communaux dans la table exemple_flux pour les variables COMMUNE puis DCLT.

exemple_flux_sansPLM <- enlever_PLM(table_entree = exemple_flux, codgeo_entree = "COMMUNE", libgeo = NULL,
                                    agregation = FALSE, vecteur_entree = FALSE)
exemple_flux_sansPLM <- enlever_PLM(table_entree = exemple_flux_sansPLM, codgeo_entree = "DCLT", libgeo = NULL,
                                    agregation = FALSE, vecteur_entree = FALSE)

Jongler avec les différentes possibilités pour les codes communaux corses

La fonction modification_Corse permet quant à elle de modifier les codes Insee des communes corses. En effet, en 1976, les codes de toutes les communes corses sont modifiés : alors qu’ils commençaient tous par “20”, leurs deux premiers caractères sont remplacés par “2A” (Corse du Sud) ou “2B” (Corse du Nord). Les codes postaux conservent d’ailleurs aujourd’hui le préfixe historique “20”. Cette fonction est notamment utile pour la raison suivante : dans certaines tables issues des recensements Insee de 1968 ou 1975, les communes sont déjà codées avec les préfixes 2A et 2B.

Le paramètre sens vaut “20vers2A2B” pour changer tous les codes communes corses commençant par 20 par 2A ou 2B et vaut “2A2Bvers20” quand l’effet inverse est recherché.

exemple_flux_sansPLMsansCorse <- modification_Corse(table_entree = exemple_flux_sansPLM, sens = "2A2Bvers20")

Corriger le code commune de l’Oudon dans le Calvados

La fonction modification_Oudon permet de modifier les codes Insee de l’ancienne commune de l’Oudon (Calvados, 14). Cette commune a connu une modification assez rare (transfert de chef-lieu) qui implique donc parfois des erreurs de codage de la commune dans certaines bases de données. En effet, la commune de l’Oudon a toujours été codée “14697” puis a changé de code devenant “14472” à partir du 07/01/2014 suite à un transfert de chef lieu. Cette commune a depuis disparu puisqu’elle est devenue commune déléguée au sein de Saint-Pierre-en-Auge (14654).

# Ici, nous allons remplacer les codes communes de l'Oudon dans une table de l'Insee
# (en COG 2014 mais que nous considérons en COG 2015 uniquement pour cet exemple).
head(exemple_popcom[which(exemple_popcom$CODGEO %in% c("14472","14697")),])
##      CODGEO  LIBGEO P12_POP SUPERF    typoA typoB
## 5159  14697 L'Oudon    1551     55 CLASSE 1     D
exemple_popcom_oudon <- modification_Oudon(table_entree = exemple_popcom,
                                           donnees_insee_entree = TRUE, donnees_insee_sortie = FALSE, COG = 2015)
head(exemple_popcom_oudon[which(exemple_popcom$CODGEO%in%c("14472","14697")),])
##      CODGEO  LIBGEO P12_POP SUPERF    typoA typoB
## 5159  14472 L'Oudon    1551     55 CLASSE 1     D

Transformer des variables numériques en autre géographie dans des données de flux

La fonction changement_COG_varNum peut également s’appliquer à des tables de flux (codes communes pouvant comporter des doublons) grâce à l’option agregation = FALSE. Les variables de type caractère sont alors conservées comme telles ou dupliquées en cas de défusion et les variables numériques (ici IPONDI) sommées en cas de fusion ou réparties proportionnellement à la population de chaque commune en cas de défusion.

exemple_flux_COG2017 <- changement_COG_varNum(table_entree = exemple_flux_sansPLMsansCorse,
                                              annees = c(2014:2017), codgeo_entree = "COMMUNE", agregation = FALSE,
                                              libgeo = FALSE, donnees_insee = TRUE)
exemple_flux_COG2017 <- changement_COG_varNum(table_entree = exemple_flux_COG2017,
                                              annees = c(2014:2017), codgeo_entree = "DCLT",
                                              agregation = FALSE, libgeo = FALSE, donnees_insee = TRUE)

Insérer dans des tables de données de flux communales des échelons supra-communaux

La fonction nivsupra peut également s’appliquer à des tables de flux (non agrégées par codes communes) grâce à l’option agregation = FALSE. La table en entrée est alors conservée comme telle avec une nouvelle colonne qui correspond au niveau supracommunal du code commune considéré.

Ici, on ajoute les colonnes ZE2010_COMMUNE et ZE2010_DCLT à la table de flux domicile-travail utilisée précédemment.

exemple_flux_COG2017_etZE <- nivsupra(table_entree = exemple_flux_COG2017, codgeo_entree = "COMMUNE",
                                      nivsupra = "ZE2010", agregation = FALSE, COG = 2017)
exemple_flux_COG2017_etZE <- nivsupra(table_entree = exemple_flux_COG2017_etZE, codgeo_entree = "DCLT",
                                      nivsupra = "ZE2010", agregation = FALSE, COG = 2017)
head(exemple_flux_COG2017_etZE)
##   COMMUNE  DCLT CS1 AGEREVQ   IPONDI ZE2010_COMMUNE ZE2010_nom_COMMUNE
## 1   61001 61001   4      25 2.856389           0051            Alençon
## 2   61001 61001   3      55 3.040441           0051            Alençon
## 3   61213 53185   2      40 4.142349           0051            Alençon
## 4   61203 61001   5      25 5.234542           0051            Alençon
## 5   61491 61500   5      40 5.578419           0051            Alençon
## 6   61077 61117   4      35 4.153005           0051            Alençon
##   ZE2010_DCLT ZE2010_nom_DCLT
## 1        0051         Alençon
## 2        0051         Alençon
## 3        0051         Alençon
## 4        0051         Alençon
## 5        0051         Alençon
## 6        0051         Alençon

Bonne découverte…!