Le portail francophone de la géomatique

Bonjour

Une des solutions serait que le numero d'invariant qui identifie les locaux
dans les fichiers litteraux figure egalement en donnee associee aux objets
batis du PCI. Helas, la DGI ne le propose pour l'instant pas meme si elle
semble avoir conscience des limites que ceci genere. A quand une evolution
dans ce sens?

Il reste techniquement possible de generer par soi meme cet attribut n°
invariant a chaque objet bati mais ceci ne serait raisonablement
envisageable que pour des petites communes ou des communes rurales n'ayant
pas un nombre trop important de batis...

Comment les grosses collectivites gerent elles cette question?

Cordialement

Yannick Ardouin
Mairie de Meylan
Responsable SIG
DAUDD
y.ardouin@texte-a-enlever.mairie-meylan.fr

Bonjour,

Je pense qu'il doit etre possible de faire une requete spatiale en
croisant les surfaces parcelle et bati, qui cree une table
BATI-dans-PARCELLE dans la BD en recuperant les cles de la parcelle et
cree un lien graphique-alpha entre le bati graphique et l'alpha cree
suivant la methode evoquee.
Il ne reste plus qu'a enrichir la table a partir de donnees MAJIC II.
Contrairement a d'autres, je ne nommerai pas notre SIG europeen qui sait
faire ca.

Cordialement.

            Franck BERTON
Communaute d'Agglomeration Tour(S)plus

De: JM LE BARH
Je suis tout a fait d'accord avec les reserves apportees par C. BREDEL.
La methode exposee par F. BERTON me semble egalement interessante.
J'apporte cependant des reserves supplementaires:
Il y a beaucoup de difficultes a etablir une correspondance stricte entre les batiments issus de MAJIC II et les objets graphiques de meme type:
la representation graphique des batiments du cadastre obeit a des reles qui ne sont pas les memes que leur identification dans MAJIC II,notamment les suivantes:
- un batiment (au sens le plus courant) a cheval sur x parcelles est represente par x objets graphiques (cf le cas des coproprietes evoque par C. BREDEL),
- la distinction BATIDUR, BATILEGER, sur le plan n'a pas systematiquement de correspondance dans MAJIC II (par ex une maison d'habitation a laquelle est accolee une veranda: la veranda dans MAJIC II est une piece annexe de l'habitation)
- sur le plan fiscal: ne pas perdre de vue que les batiments publics non productifs de revenus et donc exoneres de TF ne sont pas identifies dans MAJIC II (les collectivites locales qui ont tente d'identifier leur patrimoine immobilier a partir du cadastre en savent quelque chose...)
- idem pour les batiments agricoles (localiser et identifier les batiments d'elevage intensif revet de plus en plus d'importance en Bretagne par ex.).
Cette liste n'est sans doute pas exhaustive, mais ce sont ces divers problemes qui me conduisent a penser que le choix que nous avons fait est pour l'instant le moins mauvais, tant que la structuration des donnees MAJIC II et celle du PCI ne seront pas concordantes (le seront-elles un jour?).

De: JM LE BARH
Chaque local possede un invariant unique a l'echelle du CDIF attribue par le systeme a la maniere d'un index.
Chaque local possede par definition au moins une PEV (Partie d'EValuation) numerotee (de 001 a nnn). Il n'y a pas d'invariant par PEV.
Si vous possedez des donnees provenant de plusieurs CDIF, il vous suffit d'indexer sur les champs codeCDIF+invariant .
Sur la perennite de l'invariant: a priori la perennite existe...
Mais, il faut raisonner humainement: quelle que soit la BD sur laquelle on travaille, il existe des circonstances ou il est plus facile de detruire une ligne de donnees et de la reconstruire, plutot que de faire une Mise a Jour qui prendrait plus de temps, de par sa complexite...
C'est le cas parfois pour la saisie dans MAJIC II... (de maniere residuelle cependant).

Quand est ce que l'on pourra acquérir un géoréférencement avec le code invariant ?
J'ai une jointure où les identifiants de mes objets géographiques sont resté orphelins des numéros invariants de la BDD MAJICII :'(

Quelqu'un a trouvé depuis d'autres solutions, ou d'autres approches ?

OK
Donc si je comprends bien autant joindre les données MAJIC à la parcelle et aux lots de copropriété ?
Même si le bâti physique ne suit pas tout le temps le découpage cadastrale (puisque nous sommes dans du découpage de fiscalité) et se retrouve parfois à cheval sur plusieurs grilles de parcelles...

C'est dommage, j'ai des données attributaires comme l'âge de construction, la surface, les valeurs locatives (PEV), les catégories ...et cela j'aimerais le représenter à partir de mes couches "bâtiments".

Donc actuellement, je travaille sur une petite table de correspondance pour lier ainsi le code des objets géographiques aux probables codes invariants... ( on triche un peu, sans trop dénaturer les choses finalement)

Qu'en pensez vous ?

Dernière modification par damienfauries (Thu 22 September 2011 19:02)

Bonjour,

Avec un bémol, il est indiqué dans la doc DGFiP (descriptif) que le lien lot local n'est pas toujours réalisé. Mais comme en matière de plan donc de géométrie de support de la donnée le lot n'a pas de consistance, il est préférable de rattacher à la parcelle d'assise. Concernant les copro sur plusieurs parcelles, il existe une seule parcelle assise de la copro, et un indicateur GPDL à 2 pour les autres parcelles de la copro.

Après suivant la qualité du plan (adressage lettre de bâtiments) et la qualité des données local (bat porte entrée niveau) on peut tenter de jouer mais ce ne sera pas un modèle générique (template).

Bonjour,

Parce que le service des finances publiques ne gèrent pas les taxes foncières à l'aide d'un plan mais avec une application plus toute jeune qui ne gère les locaux qu'avec un invariant créé par lui même.
La seule solution est d'utiliser les parcelles d'assise et de faire affichier dans votre système cartographique tous les locaux située dans la parcelle voulue. Cela reste quand même assez efficace.
Faites attention quand les locaux sont à cheval sur plusieurs parcelles, prenez le plus petit numéro de parcelle.

Cordialement

Bonjour,

Pas tant que ça en fait. Je dérive un peu du sujet initial, mais c'est vendredi.
Si l'on compare la gestion des matrices cadastrales napoléoniennes et de rénovation, avec l'actuel MAJIC3, il existe une différence fondamentale.
Pour les matrices anciennes il est possible de tracer la vie complète d'une parcelle (ou de ses lots), ie les différentes mutations de propriétaires.
C'est impossible avec MAJIC, sauf à faire une analyse comparative des différents millésimes.
Le principal défaut de MAJIC (qui ne sert pas qu'à la taxe foncière mais plus généralement à l'évaluation des biens) est d'être une base de donnée hiérarchique. (d'où l'absence d'un modèle relationnel )