République
Française
Documentation Datafoncier
Toutes les ressources sur les données foncières
République
Française
Documentation Datafoncier
Toutes les ressources sur les données foncières
| Informations principales | |
|---|---|
| Nom | coddep |
| Description | code du département |
| Fiabilité | |
| Position | 5 |
| Type | Chaîne de caractère |
| Contrainte | Controle |
Code du département de la ou des parcelles cadastrales concernées par la mutation.
La variable est codée sur 2 caractères pour la France métropolitaine et la Corse et sur 3 caractères pour les départements d'outre-mer.
Exemple :
SELECT ...
FROM ...
WHERE coddep = '59' AND ...
Cette variable est systématiquement remplie.
Cette variable est directement issue de la donnée source.
On peut décomposer les tables de la base selon l'arborescence suivante :
| Tables | Informations |
|---|---|
| pnb10_parcelle | Table des parcelles |
| pb0010_local | Table des locaux |
| proprietaire_droit | Table des droits des propriétaires sur chacuns de leurs biens |
| Tables | Informations |
|---|---|
| lots_locaux | Table de correspondance entre les lots et les locaux |
| pb21_pev | Table des parties d'évaluation |
| pb30_pevexoneration | Table d'exonération des parties d'évaluation |
| pb31_pevexoneration | Table d'exonération s'appliquant sur la base imposée |
| pb36_pevtaxation | Table de taxation des parties d'évaluation |
| pb40_pevprincipale | Table des parties principales d'habitation |
| pb50_pevprofessionnelle | Table des parties d'évaluation professionnelles |
| pb52_pevlissage | Table des quotes-parts de lissage sur les locaux professionnels |
| pb60_pevdependances | Table des parties d'évaluation dépendances |
| pdl10_pdl | Table des propriétés divisées en lots |
| pdl20_parcellecomposante | Table des parcelles composantes |
| pdl30_lots | Table des lots de copropriété |
| pnb21_suf | Table des subdivisions fiscales |
| pnb30_sufexoneration | Table d'exonération des subdivisions fiscales |
| pnb36_suftaxation | Table de taxation des subdivisions fiscales |
| Tables | Informations |
|---|---|
| TUP | Table unifiée du parcellaire |
| carroyage100 | Table carroyage 100m |
| commune | Table des communes |
| section | Table des sections |
| canton | Table des cantons |
| arrondissement | Table des arrondissements |
| departement | Table des départements |
| region | Table des régions |
| carroyage | Table des carroyages |
| pdlmp | Table des pdlmp |
| uf | Table des unités foncières |
| batiment | Table des bâtiments |
| carreaux_vides | Table des carreaux vides |
Le Cerema garde toutes les variables déjà présentes dans les fichiers MAJIC fournis par la DGFiP. La présence de ces champs permet aux utilisateurs originels de MAJIC de reconstituer leurs propres variables, ou de faire fonctionner avec les Fichiers fonciers les outils conçus pour les fichiers MAJIC. Cependant, en cas de doute entre plusieurs variables, il est plutôt conseillé d'utiliser les variables créées par le Cerema.
Dans les fichiers bruts, les informations relatives à un local ou à une parcelle sont parfois situées dans des tables secondaires, nécessitant parfois des jointure nombreuses. À la demande des utilisateurs et pour faciliter l'utilisation des données, le Cerema a donc regroupé les informations les plus demandées dans 3 tables dites essentielles :
Ainsi le Cerema a croisé certaines variables provenant de tables différentes (variables affiliées). Par exemple, sur la table des parcelles, du groupe « propriétés non bâties », on ne trouve originellement que des données sur le foncier. Le Cerema a ajouté de nombreuses données provenant de la table des locaux. On peut ainsi connaître le nombre de logements, d’activités, de dépendances, etc présents sur une parcelle.
Par abus de langage, ou parce que certains sont habitués à travailler avec les données d’origine (MAJIC), des utilisateurs parleront de table « propriétés bâties » pour parler de la table des locaux et d’autres de « non bâties » pour les parcelles. En réalité, cette appellation ne s’applique qu’aux variables d’origine et non aux Fichiers fonciers retraités. Le plus simple consiste donc à reprendre les intitulés exacts des tables ou, à défaut, les noms usuels : table des locaux, table des parcelles, table des propriétaires.
Les variables créées par le Cerema ne représentent qu’une partie du potentiel de variables pouvant être créées. En gardant disponibles les variables d’origine dans les livraisons des Fichiers fonciers, un utilisateur averti peut les combiner pour créer ses propres variables.
Trois variables sont couramment utilisées dans les Fichiers fonciers dès que l’on veut associer deux tables. Ces jointures sont liées par les relations suivantes :
Dans de rares cas, un local ou une parcelle peuvent ne pas avoir de propriétaire. Il s’agit en réalité d’une erreur dans la base.
Pour chaque local (notion explicitée par la suite), un numéro unique est attribué sur la France entière. Ce numéro se retrouve dans les tables des locaux et des pev. Il est composé des variables ccodep (code département) et invloc (numéro local invariant). Cet identifiant est unique dans la table des locaux.
Pour chaque parcelle (notion explicitée par la suite) un numéro unique est attribuée sur la France entière. Ce numéro se retrouve dans les tables des locaux et des parcelles. Il est composé des variables ccodep (code département), ccocom (code communal), ccopre (préfixe de section ou quartier servi pour les communes associées), ccosec (code section cadastrale), dnupla (numéro de la parcelle). Cet identifiant est unique dans la table des parcelles.
Pour chaque compte-propriétaire (notion explicitée par la suite) un numéro unique est attribué sur la France entière. Ce numéro se retrouve dans les tables des locaux, des parcelles et des propriétaires. Il est composé de ccodep (code département), ccocom (code communal), dnupro (numéro du propriétaire).
En outre, les Fichiers fonciers contiennent des données permettant des liaisons avec d’autres bases de données.
La variable ccodep contient le code du département.
Cependant, le nom du champ n’est pas toujours le même selon la table utilisée. Le plus courant est ccodep, mais d’autres intitulés existent : ccodepb, ccodepl.
La variable idcom contient le numéro INSEE de la commune. Le code idcomtxt correspond au nom de la commune en toutes lettres, comme présent dans les données INSEE au 1er janvier.
Les Fichiers fonciers 20XX contiennent les données au 1er janvier 20XX.
⚠️ Il est nécessaire de prendre des précautions concernant les fusions de communes. En effet, certaines communes existent toujours dans les Fichiers fonciers au 1er janvier 20XX, alors qu’elles ont été absorbées lors d’une fusion à la même date. De même, certaines fusions non prises en compte par l'INSEE sont anticipées par les Fichiers fonciers. Ces problèmes sont rares à l'échelle nationale (quelques communes par millésimes), mais doivent tout de même faire l'objet d'une vérification.
Il est possible de réaliser des jointures avec d’autres bases de données en se servant de l’adresse.
⚠️ Les adresses des Fichiers fonciers n’étant pas normalisées, il peut être délicat d’effectuer cet appariement. Dans tous les cas, il est toujours préférable d’utiliser des jointures géographiques.
Les Fichiers fonciers (tables des parcelles et des locaux) sont géolocalisés. Il est donc possible de les croiser avec des autres objets géomatiques.
Il est ainsi possible de repérer les locaux / parcelles dans les zones U des PLU, dans les quartiers prioritaires de la ville, autour d’arrêts de transports collectifs, etc.
Le champ idpar (identifiant parcellaire) permet de faire la jointure avec d’autres bases. On peut ainsi citer la BD Parcellaire de l’IGN, ainsi que les données cadastrales, mais aussi toutes les données locales (liste des acquisitions d’une collectivité, emprise d’une opération d’aménagement, registre parcellaire graphique etc.)
Dans la table des propriétaires, il existe la colonne dsiren, qui reprend le code siren du propriétaire.
