Version 3.0 de la base foncière

Une nouvelle interface, mais pas que

La version 3.0 de la base foncière a été réécrite sur la nouvelle plate-forme de développement web de nos applications, le framework symfony (merci à Mickael pour sa préciseuse aide sur cet environnement, spéciale dédicace à js !) . Son apparence est identique à toutes les dernières applications développées en interne, facilitant la consultation et les exports de données.
Les rapports et bilans sont mis en place avec l’outil de reporting Redash. Ils sont donc consultables depuis l’application ou directement dans Redash.

Voilà pour ce qui se voit tout de suite. Les autres gros changements tiennent à la structure de la base elle-même.
C’est ce que nous allons détailler dans le reste de cet article.

Modifications conceptuelles

Globalement
La première grosse différence est que la base est faite pour accueillir les données du[fond lavande] Cen CVL et du Cen 41[/fond lavande].

Au niveau de la notion d’[fond lavande]historisation[/fond lavande], une nouvelle stratégie est mise en œuvre. Finies les tables d’historisations qui rendaient complexe le suivi dans le temps des éléments passés. [fond lavande]Désormais, un acte ou une parcelle reste à vie dans la table[/fond lavande] correspondante. Seul la notion de [fond lavande]statut[/fond lavande] permet de savoir ou en est cet élément.

Pour remonter le temps, deux [fond lavande]tables de suivis[/fond lavande] vont tracer toutes les modifications apportées aux parcelles et aux actes stockant certaines informations clés.

Au niveau des informations cadastrales de référence, les données prises en compte sont désormais les données foncières fournies par le CEREMA et actualisées tous les ans.

Voyons maintenant dans le détail.

Actes

• La notion de type acte est devenue quasi inutile. Fini les actes de vie. Voici un résumé des types et de leur maintien ou pas.

•  Les champs suivants ont été ajoutés :
  • [vert]cen[/vert] : identification du cen d’appartenance,
  • [vert]renew_tacite[/vert] : permet d’indiquer qu’une convention est renouvelée tacitement,
  • [vert]frais_annexe[/vert] : permet d’ajouter des frais annexe de l’acte autre que les frais d’achat à proprement parler,
  • [vert]date_fin[/vert] : date de fin de validité de l’acte,
  • [vert]ref_cause_fin[/vert] : cause d’arrêt de la validité de l’acte. En quelque sorte, ce champ remplace la notion de type d’acte en terme d’information. Les valeurs possibles pour ce champ sont issues de la nouvelle table [vert]cause_fin_acte[/vert] dont voici le contenu :

• Les champs suivant sont rendus obsolètes et conservés uniquement par rétro-compatibilité :
  • [rouge]ref_code_site[/rouge] : servait pour indiquer un acte de vie, remplacé par le suivi des actes,
  • [rouge]nom_notaire[/rouge] : cf plus bas le traitement de ces valeurs,
  • [rouge]origine_propriete[/rouge] : cf plus bas le traitement de ces valeurs,
  • [rouge]saisie_access[/rouge] : marqueur de données saisies historiquement sous access,
  • [rouge]createur[/rouge] : remplacé par le suivi des actes,
  • [rouge]last_modif_by[/rouge] : remplacé par le suivi des actes.

• Parallèlement, le statut des actes voit uniquement une nouvelle valeur apparaître (fond vert dans le tableau ci-dessous), c’est le cas de l’acte déchu qui correspond aux actes qui étaient auparavant déplacés dans la table d’historisation :

• Lien acte <-> site : désormais, le lien entre l’acte et le site n’est plus uniquement accessible via les parcelles qui le composent, mais il est directement stocké dans une nouvelle table de relation [vert]rel_acte_site[/vert]. Intérêt de cette nouvelle structure :
  • quand l’acte n’a pas encore de parcelles, il est tout de même associé à un ou plusieurs sites,
  • la recherche de tous les actes liés à un site est plus rapide et permet également de retrouver les actes échus très facilement,
  • la date d’association d’un acte à un site est stockée dans cette table. Ceci [fond lavande]permet rapidement de retracer dans le temps les actes d’un site[/fond lavande], et notamment de calculer [fond lavande]l’âge d’un site[/fond lavande].

• lien acte <-> commune : de même que pour le lien entre les sites et les actes, désormais l’association entre un acte et une ou des communes est stockée dans une nouvelle table de relation [vert]rel_acte_comun[/vert]. Les intérêts sont les suivants :
  • quand l’acte n’a pas encore de parcelles, il est tout de même associé à des communes,
  • accélérer la recherche de communes liées à un acte,
  • facilite la saisie des parcelles qui seront associées a l’acte par la suite puisque seules les parcelles de ces communes seront proposées.

• lien acte <-> dpt : toujours dans le même esprit, pour éviter de passer par les parcelles pour avoir l’information du ou des départements liés à un acte, création d’une table de relation [vert]rel_acte_dpt[/vert]. Intérêts :
  • quand aucune parcelle n’est encore saisie, il est possible de connaître les départements concernés,
  • [fond lavande]associer un acte à plusieurs départements[/fond lavande], ce qui n’était pas possible auparavant, dans ce cas particulier, [fond lavande]le code de l’acte prendra arbitrairement le plus petit département en terme de numéro[/fond lavande],
  • accélérer la recherche d’acte par département,
  • permet de filtrer les sites qu’on va associer à l’acte.

• lien acte <-> acte : non, le chat ne se mord pas la queue. Le but de cette table de relation [vert]rel_acte_acte[/vert] est de pouvoir retracer correctement l’[fond lavande]enchaînement des actes entre eux[/fond lavande], ceci concerne les actes de maîtrise d’usage à l’occasion des renouvellements de convention. Il existait un tel mécanisme auparavant, mais moins bien conçu et trop complexe, rendant les requêtes compliquées voir inefficaces. Une partie de l’historique d’enchaînement a pu être traduite ici, malheureusement pas la totalité du fait de l’ancienne structure partiellement efficace.

Parcelle

• La grosse nouveauté est la notion de statut de parcelle. Deux statuts correspondent à des parcelles actives, les autres correspondent à des parcelles soit historisées, soit sorties de la maîtrise. Ce statut permet
  • de gérer l’historisation des parcelles,
  • de créer des parcelles en projet, quelque soit le statut de l’acte auquel il est associé,
  • de pouvoir tracer des parcelles projetées puis abandonnées,
  • de stocker toutes les parcelles dans une seule table pour faciliter le suivi et les requêtes.

La liste des statuts est la suivante

• Les champs suivants ont été ajoutés à la table des parcelles :
  • [vert]ref_statut[/vert] : id de référence du statut de parcelle,
  • [vert]date_fin[/vert] : date de fin du statut actif de la parcelle.

[fond saumon]Attention ![/fond saumon] La création du statut de parcelle indépendant du statut de l’acte oblige à bien faire attention à l’interrogation de la base, par exemple pour avoir la surface valide d’un site. Il faut deux critères, [rouge]un ou des acte(s) valide(s) ET des parcelles valides[/rouge]. Dans l’application, certains changement de statut de l’acte entraînent le changement de statut des parcelles associées, mais tout dépend de la procédure. Il ne faut donc pas oublier de bien gérer le statut des parcelles parallèlement au statut des actes.

Notaire, origine de propriété et lieu-dit

Ces trois informations étaient stockées auparavant directement dans les tables acte ou parcelle, créant de la redondance et facilitant des orthographes différentes d’un même élément. Il était possible d’indiquer une seule valeur, créant des agrégations de noms en tant que valeur.
Désormais, ces données sont stockées chacune dans une table et des tables d’associations permettent d’affecter à un acte un ou des notaire(s)/orgine(s) de propriété, ou à une parcelle un lieu-dit.
Les tables créés sont :

• [vert]notaire[/vert] et sa table de relation [vert]rel_acte_notaire[/vert],
• [vert]proprietaire[/vert] et sa table de relation [vert]rel_acte_proprietaire[/vert],
• [vert]lieudit[/vert].

Suivi

Afin de tracer ce qui arrive dans le temps aux actes et aux parcelles, l’application va tracer dans deux tables de suivi les manipulations de ces objets. Ceci permettra de [fond lavande]voir toutes les actions historiquement menés sur ces éléments[/fond lavande] et potentiellement de revenir en arrière dans le temps en terme de requête.

Pour le suivi des actes, chaque ligne contient les informations suivantes stockés après modifications de l’acte :

• code_acte : code de l’acte concerné,
• ref_statut_acte : statut de l’acte après modification,
• date_acte : date de l’acte après modification,
• ref_type_maitrise : identifiant du type de maîtrise après modification,
• surf_cumul : surface cumulée des parcelles actives au moment de l’enregistrement,
• operateur : qui a fait la modification,
• date_modif : date et heure de la modification,
• operation : nature de l’operation (insert, update, delete...)

Pour le suivi des parcelles, chaque ligne contient :

• cleparcabs : identifiant unique de la parcelle,
• code_acte : code de l’acte auquel elle est associée après modification,
• code_site : code du site auquel elle est associée après modification,
• ref_statut : identifiant de statut de parcelle après modification,
• surface : surface de la parcelle,
• geom : géométrie, [fond lavande]stockée uniquement lors de la première association de la parcelle à un acte[/fond lavande]. Ceci permettra d’avoir une trace de la géométrie en cas de disparition de la parcelle du référentiel cadastrale,
• operateur : qui a fait la modification,
• date_modif : date et heure de la modification,
• operation : nature de l’operation (insert, update, delete...).

Ce suivi est consultable à différents endroits de l’application :

• détail d’un acte dans le tableau des actes,
• détail d’une parcelle dans le tableau des parcelles,
• fiche d’acte.

La table mf.foncier_cen

Pour la consultation du foncier [fond lavande]dans le logiciel SIG[/fond lavande], il faut désormais [fond lavande]consulter uniquement cette table[/fond lavande], plus précisément cette vue matérialisée (requête enregistrée stockée physiquement et non seulement en mémoire du serveur), [vert]mf.foncier_cen[/vert]. Elle est actualisée à chaque modification dans la base foncière.
Cette table contient l’ensemble des détails issus de la base concernant chaque parcelle. Elle contient TOUTES les parcelles, issues du référentiel cadastrale ou d’une numérisation dite "maison",[fond lavande] y compris celles qui ne sont plus actives ou en projet[/fond lavande].

Pour distinguer les parcelles de tout statut, les champs suivant sont utiles :

• actif : permet de filtrer les parcelles valides et en projet de celles caduques,
• ref_statut_parcelle : filtrage sur l’identifiant de statut de parcelle,
• statut_parcelle : filtrage sur le libellé de statut de parcelle,
• date_fin_parcel : filtrage sur la présence ou pas d’une date de fin. Si une date est présente, la parcelle n’est plus active.

Vous pouvez également noter les informations complémentaires suivantes en partie issues du référentiel foncier :

• nature : nature foncière des terre (terres, landes, prairies, etc...),
• source_parcelle : permet de savoir si la géométrie est issue du référentiel cadastral ou d’une numérisation "maison",
• source_geo : indique la version du référentiel cadastral dont est issu la géométrie, ou la méthode de saisie "maison" de la parcelle.

Éléments abandonnés

Disparition des tables suivantes devenues inutiles ou obsolète :

• [rouge] mf.mf_BDP_actuel[/rouge]
• [rouge]mf.mf_bdp_histo[/rouge]
• [rouge]mf.histo_bdp_acte_actif[/rouge]
• [rouge]mf.histo_bdp_acte_histo[/rouge]
• [rouge]mf.histo_bdp_histo_acte_actif[/rouge]
• [rouge]mf.histo_bdp_histo_acte_histo[/rouge]
• [rouge]mf.mf_cad_maison[/rouge]
• [rouge]mf.vu_parcelle_mf_pour_fede[/rouge]
• [rouge]sites_emprise[/rouge] : la disparition de cette vue tient à la modification du format d’échange fédérale des données Cen. L’actualisation via la base foncière des données qu’elle contenait ne faisait plus sens. Désormais, penser à utiliser soit [bleu ciel]spatial.sites_et_nivo[/bleu ciel], pour visualiser sommairement les sites, ou alors si vous voulez le format fédéral avec une synthèse d’information selon la nouvelle nomenclature, c’est [bleu ciel]fede.sites_qgis[/bleu ciel]

• Disparition également de la synchronisation de tables dépendantes du foncier, lancée "à la main" depuis l’interface de l’application. Désormais, l’actualisation des vues (requêtes enregistrées) est lancée directement par le code de l’interface ou par des taches planifiées en base.