changement_COG_typo: Changer les typologies de geographie communale
In antuki/COGugaison: Gestion des codes officiels géographiques (COG)

changement_COG_typo

R Documentation

Changer les typologies de geographie communale

Description

Transformer des typologies 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 la classe qui contient le plus de population, définir une classe absorbante ou une classe spécifique aux regroupements de plusieurs communes de classes différentes).

Usage

changement_COG_typo(
  table_entree,
  annees,
  codgeo_entree = colnames(table_entree)[1],
  typos = colnames(table_entree)[-which(colnames(table_entree) == codgeo_entree)],
  methode_fusion = c("methode_difference", "methode_classe_fusion", "methode_max_pop",
    "methode_classe_absorbante", "methode_classe_absorbee"),
  mot_difference = NULL,
  mot_fusion = "commune fusionnée",
  classe_absorbante = NULL,
  classe_absorbee = NULL,
  donnees_insee = TRUE,
  libgeo = FALSE
)

Arguments

`table_entree`	correspond à la table à transformer en une autre géographie
`annees`	est un vecteur qui liste l'ensemble des années qui séparent le code officiel géographique de départ et d'arrivée. Par exemple c(1968:1985). Le package rend possible l'utilisation de tables de passages d'une année de COG vers une année antiérieure (par exemple c(2016:2014)).
`codgeo_entree`	est une chaîne de caractères qui indique le nom de la variable contenant les codes Insee communaux. Par défaut, il s'agit du nom de la première colonne de table_entree.
`typos`	est un vecteur de chaînes de caractères qui indique les noms des typologies à convertir . Elles peuvent être de types numeric, character ou factor. Par défaut, il s'agit de l'ensemble des variables de table_entree sauf codgeo_entree.
`methode_fusion`	méthode choisie en cas de fusion de communes de classes différentes : - "methode_classe_fusion" : pour toutes les communes qui ont fusionné entre 2 dates indiquer comme classe la valeur inscrite dans "mot_fusion" y compris pour les fusions de communes de mêmes classes (sinon utiliser la méthode : "methode_difference"). Remarque : La fonction changement_COG_typo peut très bien s'utiliser avec des variables numériques (populations...) si l'on choisit cette hypothèse en cas de fusions de communes. - "methode_difference" : créer une classe spécifique dont le nom est contenu dans mot_difference - "methode_max_pop" : attribuer la classe contenant le maximum de population des communes fusionnées - "methode_classe_absorbante" : attribuer la classe dite absorbante à toute commune fusionnée contenant au moins une ancienne commune appartenant à cette classe absorbante - "methode_classe_absorbee" : ne pas tenir compte de cette classe dite "absorbée" pour toute commune fusionnée contenant au moins une ancienne commune appartenant à cette classe absorbée
`mot_difference`	n'est à définir que si methode_fusion = "methode_difference". Si ce paramètre est laissé à NULL alors la commune fusionnée possède comme libellé de classe l'ensemble des libellés présents dans ses communes fusionnées séparés d'un "et". Sinon, il indique un nom de classe à attribuer aux communes fusionnées de classes différentes.
`mot_fusion`	n'est à définir que si methode_fusion = "methode_classe_fusion". Sa valeur par défaut vaut "commune fusionnée".
`classe_absorbante`	n'est à définir que si methode_fusion = "methode_classe_absorbante". Si ce paramètre est laissé à NULL alors la commune fusionnée possède comme libellé de classe l'ensemble des libellés présents dans ses communes fusionnées séparés d'un "et". Sinon, il indique le nom de la classe dite absorbante à attribuer à toute commune fusionnée contenant au moins une ancienne commune appartenant à cette classe absorbante.
`classe_absorbee`	n'est à définir que si methode_fusion = "methode_classe_absorbee". Si ce paramètre est laissé à NULL alors la commune fusionnée possède comme libellé de classe l'ensemble des libellés présents dans ses communes fusionnées séparés d'un "et". Sinon, il indique le nom de la classe dite absorbée à attribuer à toute commune fusionnée contenant au moins une ancienne commune appartenant à cette classe absorbante.
`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.
`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.

Details

Le code officiel géographique le plus récent du package est actuellement celui au 01/01/2023.

Les millésimes des COG qui peuvent être utilisés sont à ce stade les suivants : 1968, 1975, 1982, 1990, 1999, 2008 à 2023.

Les dates de référence des codes officiels géographiques utilisés dans COGugaison sont les suivantes :

COG 1968 : à partir du 01/03/1968
COG 1975 : à partir du 20/02/1975
COG 1982 : à partir du 04/03/1982
COG 1990 : à partir du 05/03/1990
COG 1999 : à partir du 08/03/1999
Pour tous les autres COG : à partir du 01/01 de chaque année

Les différences entre les tables de passage Insee et non Insee sont les suivantes :

1982-03-03 (pris en compte par l'Insee seulement après le 04/03/1982): Flaignes-Havys (08169) est un rassemblement de Flaignes-Havys (08169), Havys (08221) [fusion simple].
2014-01-01 (pris en compte par l'Insee seulement au 01/01/2015) : Loisey (55298) s'est séparée en Loisey (55298), Culey (55138) [rétablissement].
1990-02-01 (pris en compte par l'Insee seulement après le 05/03/1990) : Le code commune de Oudon passe de 14624 à 14697 [changement de code dû à un changement de chef-lieu].
2014-01-07 (pris en compte par l'Insee dès le 01/01/2016) : Tôtes est rattachée à Notre-Dame-de-Fresnay qui devient L'Oudon (changement de code de l'Oudon de 14697 à 14472) [transfert de chef-lieu].
1981-09-28 (pris en compte par l'Insee dès le 20/02/1975) : Vaudreuil-Ex-Ensemble Urbain (27701) est créée à partir des parcelles d'Incarville (27351), de Léry (27365) , de Porte-Joie (27471) , de Poses (27474) , de Saint-Étienne-du-Vauvray (27537), de Saint-Pierre-du-Vauvray (27598), de Tournedos-sur-Seine (27651) et du Vaudreuil (27528) [création]. Cette situation étant complexe, nous avons pour le moment considéré que Vaudreuil-Ex-Ensemble Urbain (27701) est créée à partir de parcelles du Vaudreuil (27528) uniquement.
En 1968, les 4 communes qui auraient dû d'après le COG être codées 2B044,2B076,2B151 et 2A325 sont codées 20044,20076,20151 et 20325 dans les données Insee.

References

Examples

## Exemple 1
# Ici nous allons transformer les deux typologies (typoA et typoB) de la table exemple_pop en geographie communale au 1er janvier 2017 (au lieu de 2014).
# L'hypothese de classement en cas de fusion de communes (*methode_fusion*) choisie est celle d'une classe specifique (*methode_difference*, classe appelee *mot_difference*="differents") aux regroupements de plusieurs communes de classes differentes. Les autres hypotheses possibles auraient pu etre l'hypothese du maximum de population *methode_max_pop* ou de classe absorbante *methode_classe_absorbante*.
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)
# Nous allons maintenant isoler dans une table les communes fusionnees appartenant à des classes differentes, ici selon la typologie "typoA" entre 2014 et 2015, 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"]])
head(details_exemple_popcom_COG2017_typo[["2015_2016"]])
head(details_exemple_popcom_COG2017_typo[["2016_2017"]])

antuki/COGugaison documentation built on May 9, 2023, 1:27 a.m.