vignettes/COGugaison.Rmd
COGugaison.RmdNous 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 :
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
modifications_communalestrajectoire_commune et
trajectoire_commune_shiny.changement_COG_varNum.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.nivsupra.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] 2024En 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 2615Les variables des tables sont les suivantes :
- 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 1Les variables des tables sont les suivantes :
- 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.
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 Tsingonidiag_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 AIci 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|
## |:------------------------|---------------------:|
## |2024 | 34922|
## |2015 | 771|
## |2016 | 467|
## |2018 | 386|
## |2017 | 59|
## |2014 | 25|
## |2023 | 13|
## |2022 | 11|
## |2021 | 10|
## |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)## NULL
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.
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].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 34Le 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.
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 ALa 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 5La 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.38536Nous 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 4La 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)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")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 DLa 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)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çonBonne découverte…!