Il faut
distinguer parmi les acteurs deux types de production de
données.
- Les producteurs de données privées : le généalogiste, le notaire, le géomètre expert.
- Les producteurs de données publiques : le cadastre, la conservation des hypothèques.
Ces derniers sont sensés
représenter et évaluer pour l’un, garantir et publier pour
l’autre, les données produites par les acteurs
privés. L’examen des données produites
par les acteurs publics doit permettre leur définition. Il
faut remarquer que le cadastre est censé être en
conformité avec les documents établis par la CH,
et comme nous le constaterons plus avant, qu’il est le plus
en mesure de produire des données rapidement exploitables.
Nous pourrons donc dans un premier temps simplifier l’analyse
à ce seul producteur.
II) Modèle de données cadastrales.
II.1
La donnée cadastrale :
L’histoire cadastrale a conduit à la production de
différents types de documents :
- Le plan cadastral napoléonien (récemment scanné pour la région Corse)
- Les matrices cadastrales anciennes et les matrices de passage au cadastre rénové (support papier)
- Les plans cadastraux : rénovés, refaits, remembrés, remaniés. Scannés par la DGI ils sont gérés sous l’application PCI-Image
- Les plans numérisés des communes conventionnées, gérés sous PCI-Vecteur.
- La base de donnée hiérarchique MAJICII permettant la mise à jour des données littérales.
La
modernisation du
cadastre par la numérisation de ses données, a
réellement pris corps au début des
années 2000. Elle permet la gestion et la visualisation de
celles-ci au travers de deux applications informatique, PCI-Image et
PCI-Vecteur. Elle s’est enrichie d’un partenariat
avec un producteur de données cartographiques :
l’IGN.
Comme
toutes
applications informatiques, PCI-Vecteur et Image sont capables
d’exporter la majorité des données
qu’ils contiennent. Ce sous trois formes :
- Communes gérées sous PCI-Image :
- L’image scannée de chaque feuille, au format tif
- Un fichier de localisant parcellaire (N° parcelle, X, Y)
Ces
deux
données étant définies dans le
repère de l’image (0,0,Largeur en
mètre, Hauteur en mètre)
- Communes gérées sous PCI-Vecteur :
Des
fichiers «
vectoriels » au format DXF ou EDIGEO.
Ceux-ci sont géoréférencés dans le système de projection Lambert IV.
Ceux-ci sont géoréférencés dans le système de projection Lambert IV.
- Données MAJICII :
Livrées
sous
forme de cinq fichiers texte, accompagnés du descriptif de
leur composition :
Un fichier bâti, un fichier FANTOIR (adresse), un fichier propriétaire, un fichier non bâti, un fichier PDL(propriété divisée en lots).
Un fichier bâti, un fichier FANTOIR (adresse), un fichier propriétaire, un fichier non bâti, un fichier PDL(propriété divisée en lots).
Ces données,
disponibles pour chaque commune quel que soit
sa gestion, sont inutilisables en l’état. Elles
doivent être traduites et intégrées
dans une base de donnée relationnelle. Cette base contiendra
les informations contenues dans les cinq fichiers. Une
définition simplifiée des données
littérales et les relations qui les lient
peut-être donnée par le schéma suivant.
Ce
schéma
conceptuel de données permet d’interroger la base
sous forme simple, afficher tous les propriétaires dont la
date de naissance est 1937, ou sous forme plus complexe, quels sont les
propriétaires qui possèdent un lot appartenant
à un local.
Comme
nous l’avons vu au
§I.1 la donnée cadastrale est composée
de deux types de données. Nous allons nous
intéresser aux données topographiques
et affiner la définition de la donnée cadastrale.
La donnée cadastrale est-elle toujours composée d’une donnée topographique ?
Oui, et à l’inverse elle n’est pas toujours composée d’une donnée littérale, un puits est un élément topographique qui n’a pas de donnée MAJICII correspondante.
La donnée cadastrale est-elle toujours composée d’une donnée topographique ?
Oui, et à l’inverse elle n’est pas toujours composée d’une donnée littérale, un puits est un élément topographique qui n’a pas de donnée MAJICII correspondante.
Par contre
certaine
données MAJICII peuvent avoir la même
donnée topographique comme homologue, la parcelle
étant l’élément de
référence par défaut. La localisation
est le procédé qui permet de créer la
relation donnée littérale, donnée
topographique, elle devient géolocalisation lorsque la
donnée topographique est exprimée dans un
système de coordonnées définit par le
producteur de données cartographique (IGN) : la projection
Lambert IV pour la Corse.
Les données des communes gérées sous PCI-Vecteur sont géolocalisées. Mais il ne s’agit pas de la majorité des communes.
Les données issues de PCI-Image ne sont pas géolocalisées.
Les données des communes gérées sous PCI-Vecteur sont géolocalisées. Mais il ne s’agit pas de la majorité des communes.
Les données issues de PCI-Image ne sont pas géolocalisées.
Le processus
qui permet de
transformer la gestion d’une commune de Image vers Vecteur,
est la numérisation. Elle fait l’objet
d’une politique conventionnelle entre les acteurs
à mission de service publique et la DGI. Cette politique
sera examinée au prochain chapitre.
Si nous admettons a priori qu’il existe un processus qui
permet de géolocaliser les objets issus de PCI-image, nous
pouvons intégrer à notre modèle les
objets issus des deux applications DGI.
Comme
nous
l’avons vu précédemment les
éléments issus de PCI-Image sont simples, des
images, des localisants parcellaires.
En revanche les objets issus de PCI-Vecteur sont plus complexes. Ils peuvent prendre deux formes, EDIGEO ou DXF-PCI, mais ce sont tous des objets « cadastre », qui sont composés de 1 à n objets vectoriels. Une parcelle par exemple est un objet cadastre composé d’une polyligne (ou face) et d’un texte. Notre modèle s’enrichira donc des éléments vectoriels de base, la polyligne, le point, le texte…ce au sens de leur représentation graphique
En revanche les objets issus de PCI-Vecteur sont plus complexes. Ils peuvent prendre deux formes, EDIGEO ou DXF-PCI, mais ce sont tous des objets « cadastre », qui sont composés de 1 à n objets vectoriels. Une parcelle par exemple est un objet cadastre composé d’une polyligne (ou face) et d’un texte. Notre modèle s’enrichira donc des éléments vectoriels de base, la polyligne, le point, le texte…ce au sens de leur représentation graphique
A
ce stade nous pouvons
déjà tirer une première conclusion :
S’il existe une application permettant de géoréférencer les données issues de PCI-Image, alors les données cadastrales sont exploitables au travers d’un SIG. Et donc analysables tant sur la forme (nom, adresse …) que sur le fond, cadastral et cartographique.
S’il existe une application permettant de géoréférencer les données issues de PCI-Image, alors les données cadastrales sont exploitables au travers d’un SIG. Et donc analysables tant sur la forme (nom, adresse …) que sur le fond, cadastral et cartographique.
III) La Politique Conventionnelle :
III.1 Les atouts et contraintes d’une convention DGI
La D.G.I. soutient depuis plusieurs années une politique de
conventionnement, visant à fournir ses données
aux signataires, sous réserve que ceux-ci
numérisent celles-ci selon un standard défini
(EDIGEO, DXF-PCI), et fournissent ensuite ces données
numérisées à la DGI, ce pour permettre
la bascule entre la gestion PCI-Image des communes
concernées vers la gestion PCI-Vecteur.
Le fait de signer une convention implique pour la DGI de fournir régulièrement des données à jour, gratuitement pour la partie graphique, et de manière payante pour les données littérales, il s’agit du coût de production de la donnée. Ce coût comprend une partie fixe, à la quelle s’ajoute une valeur fonction du Mo de données produites. Donc plus la quantité de données est importante plus le coût relatif est faible. L’achat de ces données pour la région corse aura un coût équivalent à l’achat séparé par une dizaine de communes.
D’autre part la DGI s’engage à vérifier la qualité et l’intégrité des données vectorisées.
Pour ce faire elle attribue un label, si ce label est attribué cela veut dire que le plan en possession des signataires sera le reflet à l’identique du plan cadastral.
La contrainte principale se situe au niveau de la structuration des données.
La norme exigée par la DGI pour permettre l’intégration des données graphique est Edigeo, cette norme complexe implique un coût de numérisation plus élevé, mais en revanche la structuration des données permet de nombreux échanges.
Le fait de signer une convention implique pour la DGI de fournir régulièrement des données à jour, gratuitement pour la partie graphique, et de manière payante pour les données littérales, il s’agit du coût de production de la donnée. Ce coût comprend une partie fixe, à la quelle s’ajoute une valeur fonction du Mo de données produites. Donc plus la quantité de données est importante plus le coût relatif est faible. L’achat de ces données pour la région corse aura un coût équivalent à l’achat séparé par une dizaine de communes.
D’autre part la DGI s’engage à vérifier la qualité et l’intégrité des données vectorisées.
Pour ce faire elle attribue un label, si ce label est attribué cela veut dire que le plan en possession des signataires sera le reflet à l’identique du plan cadastral.
La contrainte principale se situe au niveau de la structuration des données.
La norme exigée par la DGI pour permettre l’intégration des données graphique est Edigeo, cette norme complexe implique un coût de numérisation plus élevé, mais en revanche la structuration des données permet de nombreux échanges.
La signature d’une convention DGI/Acteur_Publique impose un traitement particulier des données. On distinguera deux cadres d’interaction DGI/AP :
- La phase primaire : assemblage et validation des données.
- La phase secondaire : fourniture des mises à jours.
De façon chronologique, la signature de la convention puis le choix d’un prestataire entraîne un échange de données entre le prestataire et la DGI, plan scannés et fichiers littéraux.
Les plans sont géoréférencés soit par les services du cadastre, soit par le prestataire (la vérification incombant à la DGI).
Le prestataire utilise ces données pour les transformer en fichiers vectoriels structurés selon la norme Edigéo.
Il transmet pour vérification un fichier de points par feuille numérisée, et un lot de données Edigéo.
Le label est accordé à l’issue de la vérification si le travail de numérisation respecte les tolérances de précision fixées par la DGI, si le travail est exhaustif, si la structuration des fichiers edigeo testées obtient une note minimale de 4/5.
La première phase est décrite dans le synoptique suivant :
Si cette solution est à terme la meilleure pour permettre une exploitation efficace des données foncières, il n’en reste pas moins qu’elle ne peut-être que de long terme, en effet il existe deux obstacles majeurs :
- Le coût de numérisation supporté par les signataires (sauf DGI) : de 0.25€ à 0.60€ la parcelle
- Le temps passé avant d’obtenir la numérisation complète de la région.
D’autre part il est légitime de savoir si le coût d’une numérisation atteint un seuil de rentabilité pour certaine communes où il y a eu 10 constructions et 2 documents d’arpentage depuis ces quinze dernières années.
Le temps reste le problème majeur. En effet les techniques de géoréférencement (ou sa vérification) font appel à un GPS différentiel, matériel coûteux, les services du cadastre ne peuvent en disposer que quelques semaines par ans (2 appareils pour PACA & Corse par exemple) dans chaque département.
D’autre part les vérifications de structure et d’exhaustivité restent des tâches lourdes même si un centre de traitement spécialisé a été mis en place par la DGI (le CSI d’Angers).
IV) DIANA2D DIANACarto Une interface de géoréférencement publique
Depuis 2003 la DGI utilise le programme DIANA2D pour géoréférencer ses plans scannés, il est basé sur un moteur de calcul en bloc, réalisé à partir du code original de VERLAN par M. Michel Martin, géomètre du cadastre, et sur un moteur graphique permettant la gestion des images de grandes tailles, conçu par mes soins, la gestion des images est basée sur une DLL fournie en tant que gratuiciel par www.xnview.com .
Ce logiciel a permis, par rapport aux techniques existantes, d’effectuer un gain de productivité et de qualité. Ce dans la partie traitement des raccords de feuilles par digitalisation des points dits « de liaison », cette opération était auparavant réalisée à l’aide d’une table à digitaliser, opération longue. Le traitement d’une commune de 20 feuilles prenait environ 5 jours, le traitement logiciel prend suivant la puissance de la station de travail, de huit à 12 heures.
D’autre part le traitement numérique permet d’éliminer le problème des échelles différentes des feuilles d’une même commune et de leur juxtaposition a priori, il permet par ses fonctions de zoom d’augmenter la qualité du pointé, c’est donc la qualité globale du processus qui est augmentée.
Par contre le logiciel n’a pas résolu la problématique majeure, celle du GPS différentiel.
Dans le cadre d’une convention nationale avec la DGI, l’IGN a fourni à chaque CDIF de France le jeu d’orthophotographies de leur territoire d’exercice.
Disposant de ces données j’ai décidé de créer un nouveau logiciel permettant l’utilisation des données IGN et des données issues de DIANA2D. Il s’agit du projet DianaCarto. Il permet d’utiliser l’orthophotographie pour remplacer la phase GPS. Il permet d’exporter les données géoréférencées de PCI-Image selon un format standard intégré par la plus part des SIG du marché.
L’utilisation conjointe du couple Diana/Carto permet de traiter complètement une commune de 20 feuilles en 12 heures environs. Le GPS n’intervient qu’a posteriori et ce éventuellement pour contrôle. D’autre part la géographie de certaines régions ne permet pas de traiter le problème autrement que part orthophotographies, de nombreuses zones étant difficilement accessibles, d’autres ayant un tel couvert végétal que l’utilisation d’un GPS est impossible.
Un autre avantage du logiciel est la complète compatibilité avec la chaîne de traitement cadastrale de mise à jour, ce à double sens, tant pour l’import des données mises à jour, que pour l’export en vue d’une mise à jour. De même il intègre en partie les données DXF-PCI issues de PCI-Vecteur.
Ce produit peut être décliné en SIG minimaliste : affichage des plans, des fonds IGN, recherche parcellaire, calcul d’une distance et d’une surface.
Le traitement, DIANA2D/ DIANACARTO, est a priori applicable aux plans napoléoniens scannés.
Le produit doit être perfectionné pour permettre, le traitement des agrandissements et extraits en marges des plans « papiers », le détourage des plans scannés (éliminer le cadre les cartouches etc. …), par une polyligne, ce en conservant la compatibilité avec le traitement cadastre.
Comme souligné en début de § ces logiciels sont des œuvres originales utilisant diverses sources, ils sont par nature interdits d’utilisation dans un cadre commercial, et voués à être utilisés uniquement dans le cadre d’une mission de service public.
Intégration des logiciels dans la chaîne de traitement cadastral.
Christophe Vergon 02/2007
V) Modélisation d'un Intégrateur de données MajicII
V.1 Utilisation des données majicii : étude de cas Définission d'un mcd
Cette étude s'appuiera sur le guide d'utilisation des données majicII produit par le CERTU, celui-ci fournit une description détaillée des données et de leur interprétation. Ce chapitre tentera de définir l'architecture d'un intégrateur vers une base de donnée relationnelle et en conséquence un modèle décrivant les données littérales plus affiné que celui présenté au chapitre II .
Nous nous placerons dans le contexte d'un utilisateur à mission de service publique ayant accès aux différentes données cadastrales produites par la DGI, telles que définies dans les précédents chapitres. Il est bon de rappeler que ces données sont soumises à autorisation de la CNIL dans le cadre de leurs délivrance et exploitation.
La nature des fichiers fournis par la DGI oblige à une "traduction" pour permettre l'exploitation des données. Cette exploitation consistera principalement à l'interrogation de la base au travers de requêtes.
MajicII est une application informatique DGI utilisée depuis les années 80. Le site de téléchargement du CERTU propose un document de René DESMOND de la DGI permettant de visualiser l'alimentation et la modification des données majic dans le cadre des flux définis au chapitre I . Il s'agit de la situation actuelle (sur le plan liaison BNDP-MAJIC), mais elle était différente il y a peu (3 ans). Depuis 1980 l'ensemble des saisies était manuel, il le reste pour les locaux. La nature hiéarchique de la base et les garde fous de saisie mis en place (quelque fois étranges) ajoutés aux éventuelles fautes de frappes et au système déclaratif pour les locaux, peuvent conduire à des erreurs dans les données et dans les liens, plus certainement à leur absence.
En conséquence il faut garder à l'esprit que les données majic ne sont pas toujours le reflet des données Hypothécaires.
Même si l'on peut raisonnablement espérer que le taux d'erreur soit faible, la phase d'intégration se doit d'inclure une vérifications des liens, et donc définir les différents états d'anomalies constatés.
Comme nous l'avons vu précédement, un des intérêts est l'exploitation dans le cadre d'un SIG, ce qui implique une liaison entre données littérales et données graphiques. Certains SBDR possèdent une cartouche spatiale qui permet d'intégrer la géométrie des objets et d'effectuer des requêtes spatiales. Dans le registre libre PostGrès/PostGis, sous licence payante Oracle spatial, sont des exemples. L' option spatiale est une extention des cas d'utilisation généraux.
Ceci a une première conséquence sur le modèle, il ne doit pas exister de dichotomie entre les objets (données littérales) stockés dans les tables de la base et leur éventuel frère graphique (données topo). Ceci en ne prenant pas en compte certains objets géocodables comme les adresses, de façon à pouvoir utiliser les données PCI dans leur ensemble (image ou vecteur). L'ensemble de données foncières commun aux deux systèmes de gestion est composé des objets suivants :
Une commune est composée de n sections, qui sont composées de sous-sections qui sont composées de parcelles. Si l'unicité du numéro de parcelle est au niveau de la section, la notion de sous section est impérative pour associer les images, si c'est ce type de gestion PCI. Dans le cas étendu des BD spatiales la géométrie des images sera le rectangle englobant, sections et commune le rectangle résultant de l'union des rectangles des objets composant, les parcelles auront comme géomètrie un point. Les autres données littérales (propriétaires, lots, adresse) peuvent se greffer directement ou indirectement à une ou des parcelles, comme vu au chapitre II. Cette définition de la géométrie image est simplifiée. Une modification de l'application de géoréférencement, permettant d'associer une polyligne de contour de feuille cadastrale, doit permettre de traiter les agrandissements et raccords en marge des feuilles cadastrales scannées (définis en tant que subsection supplémentaire), et d'utiliser ces polylignes dans les algorithmes spatiaux , ce sans topologie, car il existe toujours un polygone non vide résultant de l'intersection de deux polygones de contour de feuille.
Le lien entre parcelle et lot est particulier. En effet si la parcelle ne contient aucun lot, c'est elle qui devient l'objet de relation avec les propriétaires,ou les locaux. Qu'est-ce qu'un lot ? C'est une fraction de propriété. Si cette fraction est égale à 1, ce lot est la parcelle. Pour permettre l'homogénéité du modèle, nous définirons donc un lot, dit "lot fictif", qui représentera la parcelle et qui sera présent systématiquement. le numérateur et dénominateur seront égaux à "*". Le compte communal sera celui de la parcelle, donc dans le cas d'une PDL (ou BND) il commencera par *. Une parcelle est composée d'une à n surfaces (cf guide), surfaces qui peuvent éventuellement être en lien avec un lot. C'est une relation 1 à 1 non explicite au niveau de la base de donnée (pas de contrôle d'intégrité référentielle). La table Surface contiendra un champs ptrlot contenant soit 0 ( Null ) soit la valeur de la clef primaire du lot impliqué.
L'utilisation de requêtes sera le cas d'utilisation le plus fréquent du sytème, il se spécialisera en fonction des besoins de l'utilisateur et de son imagination. Nous devons donc établir un modèle qui permette via une interface SQL de poser des questions naturelles. Nous prendrons comme point de départ des questions et des hypothèses simples.
Mr Y possède des droits de propriété dans 1 appartement d'une copropriété (sur la parcelle X), et une maison, dans la commune 1, un terrain dans la commune 2.
Nous devrons donc pouvoir interroger le système pour obtenir ces informations, en partant du principe que nous ne connaissons que les parcelles, ou le nom, prénom, et date de naissance de Mr Y .
De même nous souhaitons obtenir facilement l'ensemble des copropriétaires de la parcelle X, et non pas obtenir comme unique propriétaire "Les copropriétaires de X".
L'existence d'une personne de même nom, prénom, date de naissance mais de numéro de personne différent est un homonyme (réel ou fictif ?) , qui même s'il est rare, mérite la création d'une alerte.
La notion de propriété est utilisée ici au sens large, non au sens juridique. Car les locaux sont évalués sur le système déclaratif . Même si l'apport des données DRE à travers l'application Lascot permet une fiabilisation, la nature de la base Lascot associée à la présence d'un taux important de données inexploitables au sens cadastral du terme (pas de parcelle identifiable) incitent à la prudence. De plus, la mise à jour du plan cadastral n'est pas toujours en phase avec l'évaluation, le recoupement avec une requête spatiale doit donner des résultats instructifs mais cela ne permet pas d'affirmer que les résultats seront exhaustifs. En conséquence lorsque l'on interroge la base en terme de propriété d'un local, il faut retenir que l'on obtient les locaux évalués d'un lot ou d'une personne.
Une personne peut exercer des droits sur un bien au sens juridique sans pour autant que le bien ou la personne soient présents dans la base ou que les liens soient établis, le septième enfant d'une succession récente, s'il ne possède rien d'autre dans le secteur géographique du CDIF ne sera pas connus ou sera sans lien avec le bien (résultat à vérifier).
L'utilisation de requêtes se réalise à travers l'emploi du langage SQL, ce qui implique une contrainte dans la réalisation d'une relation n à n. Un exemple de relation n-n : Mr Y possède 2 parcelles, une de ces parcelles a plusieurs propriétaires, La femme de Y née Z, par exemple.(un propriétaire est toujours identifié par son nom de naissance). SQL n'utilisant que les jointures 1-n on utilise un artifice pour créer une jointure n-n, la création d'une table supplémentaire : "jointproplot" par exemple, où chaque table (proprio, lot) possède une relation 1-n avec elle. Ces tables sont composées de deux champs de type Long stockant la valeur de la clef primaire de chaque objet du couple composant la relation. La création d'une clef primaire pour ces tables n'est d'aucune utilité.
La lecture du guide CERTU nous apprend que le propriétaire est en fait représenté dans les fichiers, à l'intérieur d'un compte communal contenant les 6 premières personnes exerçant un droit sur un bien donné. Donc si Mr Y possède en propre le lot de copro et avec sa femme la maison, Mr Y apparaîtra dans deux comptes communaux pour la commune 1, et dans un compte sur la commune 2. En conséquence, propriétaires et comptes communaux possèdent une relation n-n, qui est caractérisée par la nature du droit exercé (propriétaire,propriétaire indivisaire, usufruitié etc ...).
Le modèle présenté chapitre II doit donc être modifié, en tenant compte des précédentes remarques. Il peut-être défini comme présenté dans le shéma ci-dessous. Chaque objet peut être stocké sous forme de tables, les relations qui les lient étant toutes utilisables sous forme de jointure au sens SQL. Il faut noter que mis à part les relations unaires surface/lot, adresse/lot, adresse/local, les liens sont des compositions. Ce qui se traduira en SQL par la création de ces jointures en mode "suppression en cascades". Si une parcelle est supprimée, les lots qui la composent le seront aussi mais les propriétaires, les locaux concernés ne le seront pas. Les fichiers Majic étant annuels, cette remarque prends son sens dans le cadre d'une mise à jour de la base de donnée, permettant la création d'un historique. Le maintien du compte communal en tant qu'attribut de Lot ou de Local paralellement à l'existence d'une jointure et l'existence d'une table CompteCommunal est voulu. Il permet d'interroger la base selon différents chemins. "Quelles sont les propriétés de Mr Y" utilisera le joint lotprop, "Quels sont les propriétaires partageant des droits avec Mr Y", utilisera le joint PropCompteCom, le résultat sera calculé sur l'ensemble des communes de la base
V.2 Données Initiales, traduction primaire dans des tables temporaires, processus general:
Comme nous l'avons déjà vu, les données initiales dont nous pouvons disposer sont les données topo et les données littérales. Nous allons y ajouter un nouveau fichier "DonneeDepartementale" qui contiendra a minima le code INSEE de la commune et son nom. La provenance peut-être diverse selon les utilisateurs: Table Commune d'une base TPLascot ou Lascot pour les membres de la DGI, fichiers rdf téléchargeables sur le site de l'INSEE, ou BDCarto de l'IGN. Nous y ajouterons un champs de données de type booleen "Vecteur" avec la valeur Faux par défaut. Cette base aura pour vocation de permettre une reconnaissance automatique de la commune dans le traitement des données initiales. Qu'il s'agisse du contenu Edigéo ou DXF-PCI , des noms de fichiers image ou localisant, la normalisation existante permet d'atteindre rapidement les données, code insee, section, subsection. La base départementale n'a pas vocation à exister dans le cas d'un SGBR puissant permettant d'intégrer tout un département. Elle est remplacée par la table "Commune". Dans le cadre d'un projet mettant en oeuvre une base par commune (Type access + vb), cette base sert au système pour diffuser une requête sur les communes choisies par l'utilisateur. Dans ce cadre l'unicité du propriétaire n'est pas assurée au delà de la commune autrement que par la valeur du champs DNUMPER.
Les données MajicII initiales sont des fichiers texte.
La date d'édition de ces fichiers diffère de celle des fichiers topo. Ceci induit un état d'anomalie pour les parcelles qui peuvent être absentes d'un des deux ensembles. La codification des fichiers et les abrévations de noms de champs rendent peu intelligibles le contenu des fichiers Majic. La réalisation du cas d'utilisation "Integration données dans un SGBR" se révèle donc être complexe. Traduire les fichiers texte, vérifier le formatage et le type de valeur obtenu, enregistrer les valeurs dans les tables, vérifier et créer les liens, pour les parcelles établir les discordances avec les données topo ... et assurer en plus la compatibilité du processus avec les BD spatiales.
Une façon de simplifier les choses est de considérer le cas d'utilisation "intégration des données" comme un processus automatisé composé d'étapes successives formés des cas d'utilisation inclus. Sous cet angle vient l'idée que les données peuvent être transformées, formatées puis intégrer dans une BD sans création de liens. Puis l'ensemble de ces données est à nouveau traité pour établir les liens et les vérifier. Il est possible d'utiliser une base de donnée temporaire.Les tables de cette BD seront préfixées "BdTemp". Cette BD est la traduction des fichiers textes Majic sans établir de relations entre les entités autre que PEV et local, Parcelle et Surface. Le fichier FANTOIR (adresses) et lui directement intégré dans la base finale. La notion de compte communal est définie comme attribut d'un proprietaire de la base temporaire. Chaque compte communal verra donc la création de 1 à 6 propriétaires différents dans la base temporaire, en conséquence une même personne physique pourra avoir plusieurs représentations. L'unicité de la personne sera crée lors de la seconde phase.
L'avantage de la création d'une base
temporaire est double, il permet de se focaliser sur les pbs de
formatage de données dans la phase d'intégration MajicTxtFile vers
BdTemp, et d'utiliser ensuite des requêtes SQL pour l'intégration dans
la base finale.
Les fonctions de gestion d'une base de donnée manipulent en général un objet général Record (enregistrement) et renvoient un jeu d'enregistrement (Recordset). Les paramètres BOF et EOF s'ils sont vrais tous les deux indiquent que le "recordset" ne contient aucun enregistrement. Nous partirons du principe que le système intégrateur que nous modélisons comporte une interface "SQL" permettant de manipuler l'ensemble des objets contenus dans une base de donnée et d'executer des requêtes. Les résultats étant délivrés sous forme de jeu d'enregistrements.
Nous étendrons le principe précédent à l'implementation des interfaces de lecture des fichiers textes et des données EDIGéo ou DXF-PCI. L'interface est un service capable de réaliser des opérations spécifiques, dont seul le résultat est visible à l'utilisateur du service. Ceci est par exemple le cas avec Spatial Data Integrator de la société Talend, la lecture EDIgéo est un service accéssible. L'intégration des données Majic2 est modélisée ici sous forme de méthode du système intégrateur, ceci pour porter l'accent sur ce que nous cherchons à réaliser. Dans la pratique l'intégration des données majic serait implémentée sous forme d'interface utilisée par le système intégrateur.
Le
processus général d'intégration peut-être défini par un diagramme
d'activités, qui sera le reflet de l'utilisation séquentielle des
interfaces. Activité décomposée en trois phases majeures, qui reflètent
les trois états possibles du système intégrateur . La phase 1 n'a
lieu qu'une fois, les phases 2 et 3 se répétant pour chaque commune.
Les activités de la phase 2 peuvent se dérouler dans un ordre
quelconque, mais elles doivent toutes être achevées pour passer à la
phase 3.
V) Modélisation d'un Intégrateur de données MajicII
V.1 Utilisation des données majicii : étude de cas Définission d'un mcd
Cette étude s'appuiera sur le guide d'utilisation des données majicII produit par le CERTU, celui-ci fournit une description détaillée des données et de leur interprétation. Ce chapitre tentera de définir l'architecture d'un intégrateur vers une base de donnée relationnelle et en conséquence un modèle décrivant les données littérales plus affiné que celui présenté au chapitre II .
Nous nous placerons dans le contexte d'un utilisateur à mission de service publique ayant accès aux différentes données cadastrales produites par la DGI, telles que définies dans les précédents chapitres. Il est bon de rappeler que ces données sont soumises à autorisation de la CNIL dans le cadre de leurs délivrance et exploitation.
La nature des fichiers fournis par la DGI oblige à une "traduction" pour permettre l'exploitation des données. Cette exploitation consistera principalement à l'interrogation de la base au travers de requêtes.
MajicII est une application informatique DGI utilisée depuis les années 80. Le site de téléchargement du CERTU propose un document de René DESMOND de la DGI permettant de visualiser l'alimentation et la modification des données majic dans le cadre des flux définis au chapitre I . Il s'agit de la situation actuelle (sur le plan liaison BNDP-MAJIC), mais elle était différente il y a peu (3 ans). Depuis 1980 l'ensemble des saisies était manuel, il le reste pour les locaux. La nature hiéarchique de la base et les garde fous de saisie mis en place (quelque fois étranges) ajoutés aux éventuelles fautes de frappes et au système déclaratif pour les locaux, peuvent conduire à des erreurs dans les données et dans les liens, plus certainement à leur absence.
En conséquence il faut garder à l'esprit que les données majic ne sont pas toujours le reflet des données Hypothécaires.
Même si l'on peut raisonnablement espérer que le taux d'erreur soit faible, la phase d'intégration se doit d'inclure une vérifications des liens, et donc définir les différents états d'anomalies constatés.
Comme nous l'avons vu précédement, un des intérêts est l'exploitation dans le cadre d'un SIG, ce qui implique une liaison entre données littérales et données graphiques. Certains SBDR possèdent une cartouche spatiale qui permet d'intégrer la géométrie des objets et d'effectuer des requêtes spatiales. Dans le registre libre PostGrès/PostGis, sous licence payante Oracle spatial, sont des exemples. L' option spatiale est une extention des cas d'utilisation généraux.
Ceci a une première conséquence sur le modèle, il ne doit pas exister de dichotomie entre les objets (données littérales) stockés dans les tables de la base et leur éventuel frère graphique (données topo). Ceci en ne prenant pas en compte certains objets géocodables comme les adresses, de façon à pouvoir utiliser les données PCI dans leur ensemble (image ou vecteur). L'ensemble de données foncières commun aux deux systèmes de gestion est composé des objets suivants :
- commune
- section
- subsection
- parcelle
Une commune est composée de n sections, qui sont composées de sous-sections qui sont composées de parcelles. Si l'unicité du numéro de parcelle est au niveau de la section, la notion de sous section est impérative pour associer les images, si c'est ce type de gestion PCI. Dans le cas étendu des BD spatiales la géométrie des images sera le rectangle englobant, sections et commune le rectangle résultant de l'union des rectangles des objets composant, les parcelles auront comme géomètrie un point. Les autres données littérales (propriétaires, lots, adresse) peuvent se greffer directement ou indirectement à une ou des parcelles, comme vu au chapitre II. Cette définition de la géométrie image est simplifiée. Une modification de l'application de géoréférencement, permettant d'associer une polyligne de contour de feuille cadastrale, doit permettre de traiter les agrandissements et raccords en marge des feuilles cadastrales scannées (définis en tant que subsection supplémentaire), et d'utiliser ces polylignes dans les algorithmes spatiaux , ce sans topologie, car il existe toujours un polygone non vide résultant de l'intersection de deux polygones de contour de feuille.
Le lien entre parcelle et lot est particulier. En effet si la parcelle ne contient aucun lot, c'est elle qui devient l'objet de relation avec les propriétaires,ou les locaux. Qu'est-ce qu'un lot ? C'est une fraction de propriété. Si cette fraction est égale à 1, ce lot est la parcelle. Pour permettre l'homogénéité du modèle, nous définirons donc un lot, dit "lot fictif", qui représentera la parcelle et qui sera présent systématiquement. le numérateur et dénominateur seront égaux à "*". Le compte communal sera celui de la parcelle, donc dans le cas d'une PDL (ou BND) il commencera par *. Une parcelle est composée d'une à n surfaces (cf guide), surfaces qui peuvent éventuellement être en lien avec un lot. C'est une relation 1 à 1 non explicite au niveau de la base de donnée (pas de contrôle d'intégrité référentielle). La table Surface contiendra un champs ptrlot contenant soit 0 ( Null ) soit la valeur de la clef primaire du lot impliqué.
L'utilisation de requêtes sera le cas d'utilisation le plus fréquent du sytème, il se spécialisera en fonction des besoins de l'utilisateur et de son imagination. Nous devons donc établir un modèle qui permette via une interface SQL de poser des questions naturelles. Nous prendrons comme point de départ des questions et des hypothèses simples.
Mr Y possède des droits de propriété dans 1 appartement d'une copropriété (sur la parcelle X), et une maison, dans la commune 1, un terrain dans la commune 2.
Nous devrons donc pouvoir interroger le système pour obtenir ces informations, en partant du principe que nous ne connaissons que les parcelles, ou le nom, prénom, et date de naissance de Mr Y .
De même nous souhaitons obtenir facilement l'ensemble des copropriétaires de la parcelle X, et non pas obtenir comme unique propriétaire "Les copropriétaires de X".
L'existence d'une personne de même nom, prénom, date de naissance mais de numéro de personne différent est un homonyme (réel ou fictif ?) , qui même s'il est rare, mérite la création d'une alerte.
La notion de propriété est utilisée ici au sens large, non au sens juridique. Car les locaux sont évalués sur le système déclaratif . Même si l'apport des données DRE à travers l'application Lascot permet une fiabilisation, la nature de la base Lascot associée à la présence d'un taux important de données inexploitables au sens cadastral du terme (pas de parcelle identifiable) incitent à la prudence. De plus, la mise à jour du plan cadastral n'est pas toujours en phase avec l'évaluation, le recoupement avec une requête spatiale doit donner des résultats instructifs mais cela ne permet pas d'affirmer que les résultats seront exhaustifs. En conséquence lorsque l'on interroge la base en terme de propriété d'un local, il faut retenir que l'on obtient les locaux évalués d'un lot ou d'une personne.
Une personne peut exercer des droits sur un bien au sens juridique sans pour autant que le bien ou la personne soient présents dans la base ou que les liens soient établis, le septième enfant d'une succession récente, s'il ne possède rien d'autre dans le secteur géographique du CDIF ne sera pas connus ou sera sans lien avec le bien (résultat à vérifier).
L'utilisation de requêtes se réalise à travers l'emploi du langage SQL, ce qui implique une contrainte dans la réalisation d'une relation n à n. Un exemple de relation n-n : Mr Y possède 2 parcelles, une de ces parcelles a plusieurs propriétaires, La femme de Y née Z, par exemple.(un propriétaire est toujours identifié par son nom de naissance). SQL n'utilisant que les jointures 1-n on utilise un artifice pour créer une jointure n-n, la création d'une table supplémentaire : "jointproplot" par exemple, où chaque table (proprio, lot) possède une relation 1-n avec elle. Ces tables sont composées de deux champs de type Long stockant la valeur de la clef primaire de chaque objet du couple composant la relation. La création d'une clef primaire pour ces tables n'est d'aucune utilité.
La lecture du guide CERTU nous apprend que le propriétaire est en fait représenté dans les fichiers, à l'intérieur d'un compte communal contenant les 6 premières personnes exerçant un droit sur un bien donné. Donc si Mr Y possède en propre le lot de copro et avec sa femme la maison, Mr Y apparaîtra dans deux comptes communaux pour la commune 1, et dans un compte sur la commune 2. En conséquence, propriétaires et comptes communaux possèdent une relation n-n, qui est caractérisée par la nature du droit exercé (propriétaire,propriétaire indivisaire, usufruitié etc ...).
Le modèle présenté chapitre II doit donc être modifié, en tenant compte des précédentes remarques. Il peut-être défini comme présenté dans le shéma ci-dessous. Chaque objet peut être stocké sous forme de tables, les relations qui les lient étant toutes utilisables sous forme de jointure au sens SQL. Il faut noter que mis à part les relations unaires surface/lot, adresse/lot, adresse/local, les liens sont des compositions. Ce qui se traduira en SQL par la création de ces jointures en mode "suppression en cascades". Si une parcelle est supprimée, les lots qui la composent le seront aussi mais les propriétaires, les locaux concernés ne le seront pas. Les fichiers Majic étant annuels, cette remarque prends son sens dans le cadre d'une mise à jour de la base de donnée, permettant la création d'un historique. Le maintien du compte communal en tant qu'attribut de Lot ou de Local paralellement à l'existence d'une jointure et l'existence d'une table CompteCommunal est voulu. Il permet d'interroger la base selon différents chemins. "Quelles sont les propriétés de Mr Y" utilisera le joint lotprop, "Quels sont les propriétaires partageant des droits avec Mr Y", utilisera le joint PropCompteCom, le résultat sera calculé sur l'ensemble des communes de la base
V.2 Données Initiales, traduction primaire dans des tables temporaires, processus general:
Comme nous l'avons déjà vu, les données initiales dont nous pouvons disposer sont les données topo et les données littérales. Nous allons y ajouter un nouveau fichier "DonneeDepartementale" qui contiendra a minima le code INSEE de la commune et son nom. La provenance peut-être diverse selon les utilisateurs: Table Commune d'une base TPLascot ou Lascot pour les membres de la DGI, fichiers rdf téléchargeables sur le site de l'INSEE, ou BDCarto de l'IGN. Nous y ajouterons un champs de données de type booleen "Vecteur" avec la valeur Faux par défaut. Cette base aura pour vocation de permettre une reconnaissance automatique de la commune dans le traitement des données initiales. Qu'il s'agisse du contenu Edigéo ou DXF-PCI , des noms de fichiers image ou localisant, la normalisation existante permet d'atteindre rapidement les données, code insee, section, subsection. La base départementale n'a pas vocation à exister dans le cas d'un SGBR puissant permettant d'intégrer tout un département. Elle est remplacée par la table "Commune". Dans le cadre d'un projet mettant en oeuvre une base par commune (Type access + vb), cette base sert au système pour diffuser une requête sur les communes choisies par l'utilisateur. Dans ce cadre l'unicité du propriétaire n'est pas assurée au delà de la commune autrement que par la valeur du champs DNUMPER.
Les données MajicII initiales sont des fichiers texte.
La date d'édition de ces fichiers diffère de celle des fichiers topo. Ceci induit un état d'anomalie pour les parcelles qui peuvent être absentes d'un des deux ensembles. La codification des fichiers et les abrévations de noms de champs rendent peu intelligibles le contenu des fichiers Majic. La réalisation du cas d'utilisation "Integration données dans un SGBR" se révèle donc être complexe. Traduire les fichiers texte, vérifier le formatage et le type de valeur obtenu, enregistrer les valeurs dans les tables, vérifier et créer les liens, pour les parcelles établir les discordances avec les données topo ... et assurer en plus la compatibilité du processus avec les BD spatiales.
Une façon de simplifier les choses est de considérer le cas d'utilisation "intégration des données" comme un processus automatisé composé d'étapes successives formés des cas d'utilisation inclus. Sous cet angle vient l'idée que les données peuvent être transformées, formatées puis intégrer dans une BD sans création de liens. Puis l'ensemble de ces données est à nouveau traité pour établir les liens et les vérifier. Il est possible d'utiliser une base de donnée temporaire.Les tables de cette BD seront préfixées "BdTemp". Cette BD est la traduction des fichiers textes Majic sans établir de relations entre les entités autre que PEV et local, Parcelle et Surface. Le fichier FANTOIR (adresses) et lui directement intégré dans la base finale. La notion de compte communal est définie comme attribut d'un proprietaire de la base temporaire. Chaque compte communal verra donc la création de 1 à 6 propriétaires différents dans la base temporaire, en conséquence une même personne physique pourra avoir plusieurs représentations. L'unicité de la personne sera crée lors de la seconde phase.
Les fonctions de gestion d'une base de donnée manipulent en général un objet général Record (enregistrement) et renvoient un jeu d'enregistrement (Recordset). Les paramètres BOF et EOF s'ils sont vrais tous les deux indiquent que le "recordset" ne contient aucun enregistrement. Nous partirons du principe que le système intégrateur que nous modélisons comporte une interface "SQL" permettant de manipuler l'ensemble des objets contenus dans une base de donnée et d'executer des requêtes. Les résultats étant délivrés sous forme de jeu d'enregistrements.
Nous étendrons le principe précédent à l'implementation des interfaces de lecture des fichiers textes et des données EDIGéo ou DXF-PCI. L'interface est un service capable de réaliser des opérations spécifiques, dont seul le résultat est visible à l'utilisateur du service. Ceci est par exemple le cas avec Spatial Data Integrator de la société Talend, la lecture EDIgéo est un service accéssible. L'intégration des données Majic2 est modélisée ici sous forme de méthode du système intégrateur, ceci pour porter l'accent sur ce que nous cherchons à réaliser. Dans la pratique l'intégration des données majic serait implémentée sous forme d'interface utilisée par le système intégrateur.
- Phase 1 terminée : Toutes les communes sont identifiées
- Phase 2 terminée :
Toutes les parcelles d'une commune sont connues à l'état graphique dans la base finale
Les adresses de la commune sont dans la base finale
les fichiers textes majic2 ont été transformé en enregistrements dans la base temporaire
les fichiers textes majic2 ont été transformé en enregistrements dans la base temporaire
- Phase 3 terminée : La commune est exploitable.
V.3 BDFinale création des parcelles
La première activité consiste à obtenir un jeu d'enregistrement (recordset) correspondant à toutes les parcelles de la communes (dans la base finale) crées avec les données graphiques. Ensuite pour chacun de ces enregistrements on cherche l'enregistrement correspondant dans la base temporaire et on l'utilise pour attribuer une valeur aux champs composants de la parcelle.
La comparaison des deux jeux de données doit, induire des anomalies, le différentiel de date d'export en est une cause suffisante. Dans la base de donnée finale, une parcelle sera donc dans différents états d'anomalie :
- Pas d'anomalies
- Anomalie Plan : la parcelle existe dans majic mais pas au plan
- Anomalie Majic : la parcelle existe au plan mais pas dans majic
- Anomalie NoPdlAss : la parcelle d'assise de la PDL n'existe pas dans la base finale
- GPDL = 0 la parcelle est composée d'un lot unique (dit lot fictif). Ce lot est créé automatiquement
- GPDL = 1 la parcelle est la parcelle d'assise d'une PDL
- GPDL = 2 la parcelle est composante d'une PDL sans être la parcelle d'assise
La valeur de l'attribut PtrPDLAss contient l'Identificateur de la parcelle d'assise, il est égal à la parcelle en cours pour les valeurs GPDL différentes de 2. L'attribut PtrAdresse est toujours affecté d'une valeur pointant sur une adresse existante. Concernant la liaison Parcelle-Lot, il est nécessaire de créer un lot dit "lot fictif", dont le numérateur et le dénominateur valent "*". Dans le cas d'une parcelle GPDL=0 ce sera le seul lot. Dans tous les cas il aura pour valeur de compte communal, le compte communal de la parcelle associée.
V.4
BdFinale création des Lots et du lien Parcelle Lot
Nous allons maintenant procéder à l'intégration des lots, la première action consiste à sélectionner l'ensemble des parcelles de la base finale ayant un GPDL égal à 1. Ensuite pour chacune de ces parcelles on cherche dans la BD temporaire les lots ayant pour assise cette parcelle. Ensuite chaque lot est créé, la valeur ptrparcelle contenant l'identificateur de la parcelle en cours, ceci permettra d'assurer la relation parcelle lot.
V.5 BdFinale création des propriétaires et de la relation Lot-Propriétaire
On sélectionne l'ensemble des propriétaires dans la base temporaire.
modifié Aout 2008