Le portail francophone de la géomatique

Bonjour,

J'attends avec impatience d'avoir accès à ces données ...

Loin de moi l'idée de critiquer bêtement réaliser par le CEREMA, mais une fois encore je serai critique.

Le modèle présenté correspond à quelle norme ? (en tout cas pas UML)
Quelle est la connaissance métier de ceux qui ont créer ce modèle ? J'invite vivement ceux ci à relire le décret de 1955 sur la publicité foncière ...
En effet la seule chose qui peut faire l'objet d'une cession ou mutation est un lot ou une parcelle : un acte ne porte jamais sur un local ou autre ....
Le cadastre foncier comme le nomme Pascal est un métier et ce n'est pas celui du CEREMA.
Dans un MCD "cadastre-foncier" la seule relation qui devrait exister est le lien n-n entre un acte et un lot (qui peut être une parcelle).

Bref tout vient en fait du MCD des données MAJIC produit par le CEREMA ou autre arcopole ...
La méconnaissance du métier est flagrante ...
Peut être que la DGFiP devrait mettre en ligne un MCD ....

Certains me trouverons réducteur invitent à venir sur nôtre belle île pour constater que je ne raconte pas des bêtises et qu'il existe une façon propre et efficace d'utiliser les données issues de la DGFiP.

Bonjour,

Il me semble qu'il est, à l'heure des IDG et autre, de la responsabilité du producteur de données de fournir le MCD. J'ajoute que quelque soit le sujet la modélisation est un métier à part entière.

Pourquoi les géomaticiens exigent que les géométries soient normées OSGEO, alors que la production d'un modèle qui ne correspond à aucune norme ne les choque pas ?

Ben non justement, un bon MCD c'est comme une requête SQL, si ma requête prend plus de deux minutes je me dis qu'il y a un problème, pour un modèle dès que je commence à avoir des lignes qui se croisent ...
Regardez le MCD proposé : une table volume, une table lot. Qu'est ce qu'un volume ? C'est un lot et la valeur du type de PDL nous renseigne. Donc on passe de deux tables à une (en plus si il y a vente d'un lot de BND en suivant la logique du MCD proposé il manque une table).

Comme je l'écrivais dans mon msg précédent avec un MCD MAJIC correct, la seule liaison existante avec les données DVF NON Incluses dans le MCD MAJIC, est une liaison n-n avec les mutations.

Cela simplifie les choses non ?

Bonjour,

Ce modèle n'est pas la seule réflexion du Cerema mais bien le fruit d'une collaboration active entre différents organismes (collectivités territoriales, Etablissements Publics Fonciers, Etat, Agence d'urbanisme) au sein d'un groupe de travail national sur DVF.

L'objectif n'est pas nécessairement de recomposer le MCD de la DGFiP mais d'avoir un outil de travail qui puisse répondre correctement au besoin du plus grand nombre (plutôt thématicien ou plutôt géomaticien) pour l'observation foncière et immobilière.

Cet outil a déjà commencé à répondre à des besoins, et nous l'espérons, au fur et à mesure de ses évolutions et améliorations, répondra à beaucoup d'autres. C'est une première étape et nous ne manquerons pas de vous informer des suites du projet et d'illustrer son intérêt à travers différentes utilisations.

Pour ceux qui disposent des données DVF, n'hésitez à tester l'outil d'import et à nous transmettre vos remarques.

Antoine Herman, Magali Journet, Jérôme Douché
dv3f@texte-a-enlever.cerema.fr

Bonjour,

A noter cette nouvelle ressource pour mieux comprendre ces données:
http://www.geoinformations.developpemen … a3272.html

Bruno

Bonjour à tous,

ayant participé au GNDVF et contribué (modestement) à la réflexion autour du MCD des données DVF, je rejoins les propos du CEREMA. Ce travail est le résultat d'une collaboration de nombreuses structures qui se sont lancées (dès 2010) dans l'expérimentation, l'exploitation et la valorisation de cette (nouvelle) donnée (à l'époque sous l'égide de l'ADEF et aujourd'hui pilotée par Bordeaux Métropole).

Comme pour majic, il n'existe pas de modèle, et cette donnée est issue d'un croisement entre Fdji et Majic via la BNDP (pour les initiés), aussi nous avons essayé de produire un modèle de données qui serait une base de travail pour chacun d'entre nous. L'objectif étant d'éviter la multiplicité des modèles (comme cela a pu être le cas pour Majic) permettant l'interopérabilité et le partage des traitements, requêtes... Bref une sorte de mutualisation de l’ingénierie autour des usages de cette donnée.

Le modèle n'est certainement pas le plus parfait et le plus "pur" d'un point de vue technique voire métier ceci dit il a fait l'objet d'un consensus au sein du groupe et mérite d'exister. L'idée est aussi qu'il puisse vivre au sein des structures et des usages qu'elles peuvent en avoir afin éventuellement de le faire évoluer. Ce n'est qu'au travers des nombreuses utilisations que l'on connaîtra mieux ses forces et faiblesses.

Une dernière chose, un guide d'accompagnement des données DVF devrait prochainement paraître afin de faciliter l’utilisation des données.

Bien cordialement


Julien

Bonjour,

A la lecture du post de jdeniel et dans une moindre mesure (non musicale) de Marc, j'insiste encore sur la normalisation du modèle.
En effet il existe des structures dans lesquelles Mr MICHU est un informaticien qui sait très bien concevoir des bases de données mais qui n'est pas géomaticien pour deux sous, il conçoit ces BDR pour Mr Lambert son collègue géomaticien. Que peut-il faire d'un tel modèle ? Pas grand chose.
Certes il a le mérite d'exister, mais le simple fait que l'on ne connaisse pas la nature du lien entre deux tables, agrégation simple ou composition (?), induit un problème, en effet dans le cas d'une composition l'informaticien va introduire la notion d'intégrité référentielle et la suppression en cascade, en cas d'agrégation il y a intégrité mais pas suppression en cascade ... bref utiliser un modèle normé c'est

Bonjour,
Ce qui pêche depuis de nombreuses années c'est la méconnaissance de la matière (DVF, MAJIC, pour ce qui concerne notre sujet) de la part des utilisateurs, de plus en plus nombreux, de plus en plus mobiles voire en emploi à durée variable...
Cà s'apprend, çà prend du temps, mais le temps manque toujours.

Les données brutes DVF, MAJIC, sont complexes, et ont pour première finalité : établir les bases de l'impôt, calculer cet impôt, et l'adresser au bon redevable.
Si on n'a pas un minimum de connaissances sur le sujet (c'est quoi un EDD, une division en lots, en volumes, sur quelles bases et comment l’impôt est calculé), on commet des erreurs ou imprécisions, dans la modélisation, et a fortiori dans l'exploitation.
Même si on manipule des données très techniques, j'aime bien la vulgarisation (lire Marc L. le maitre en vulgarisation ! ) . Fournir par exemple une copie d'un acte notarié et l'expliciter en le mettant en regard des données DVF serait un premier pas à la compréhension tout ce b...

Si je prend simplement ( ! ) l'exemple des copropriétés en volumes, fruit je crois, des cogitations d'aménageurs du complexe de la Défense dans les années 1970, on peut avoir des choses très simples, assimilables à des copropriétés en lots classiques, jusqu'à des montages très complexes (des copropriétés imbriquées, constituées de volumes, eux mêmes composés éventuellement de lots "classiques"...tous ces lots étant bien entendu rattachés à des locaux identifiés dans MAJIC (sauf si ces lots ne sont pas taxés à la TF, et dans ce cas, pas de local associé dans MAJIC...)... Ouf !

Mais merci au Groupe national DVF pour cette production, qui a le mérite d'exister et ouvre des champs d'investigation nouveaux à beaucoup d'observateurs des territoires...

Sur le plan technique, et comme je suis en plein dans la compréhension de la structure des données, j'ai quelques interrogations :
- plusieurs tables n'ont pas de clé primaire : choix délibéré ou oubli ?
- certaines données sont entourées d’accolades {} : bug lors de l'import ou données brutes fournie mal structurées ou autre raison ?
- DVF+ crée 3 schémas à minima : DVF (template), DVF_annexe, DVFdXX ou XX est le (ou les) département(s) de localisation. Pourquoi ce choix, alors que DVF_annexe ne comporte que 6 tables de constantes et que le volume des données est largement acceptable sous POSTGRES sous un seul schéma ?
- l'outil d'import supprime les schémas précédemment créés. Il faut donc ré-importer les données en cours, auxquelles on rajoute un nouveau millésime. Est-ce viable à terme, sachant qu'il faut conserver les fichiers des données brutes pour les ré-importer à chaque mise à jour. Je défie de trouver un administrateur de BD qui, dans 5 ans et plus, saura où sont conservés les fichiers bruts initiaux...
- les requêtes et vues : rien.. alors que c'est sur cela que DVF peut être un outil de mutualisation de savoir-faire et de compétences...
(c'est d'ailleurs la même chose que pour la base des fichiers fonciers)

liste à compléter...

Je ne sais pas, à ce stade, si le forum GeoRezo est le meilleur lieu pour échanger sur ces questions (mais je le pense très fort !). S'il existe un lieu de discussion ouvert, ou des modalités spécifiques, merci de nous aiguiller.
Si ces questions peuvent être résolues ici, on verra comment on organise tout çà, le principe ici est une question : un sujet de discussion (ce que pour l'instant je n'ai pas fait).
A Julien, Pascal, Antoine, Aline et tous les participants à ce travail, ne voyez rien de personnel à ces critiques... On essaie juste de faire avancer le schmili...
Cordialement

Bonjour,
Merci Edouard pour l'info sur les tableaux : un aspect technique de POSTGRES que je ne connaissais pas.
Reste maintenant à voir comment les utilisateurs exploiteront ces champs avec leurs outils propres (suites Office, logiciels SIG...)

Bonjour,

Je pense qu'il est clair pour tous ici, que le débat évolue et ce de façon positive.

Voilà une excellente nouvelle.

reBonjour,

Oui, évolution à prévoir effectivement. En attendant, pour chaque schéma départemental (dvf_dXX), les requêtes suivantes peuvent, a priori, résoudre ce problème:

ALTER TABLE dvf_dXX.adresse_dispoparc ADD CONSTRAINT adresse_dispoparc_pkey PRIMARY KEY (idadresse, iddispopar);
ALTER TABLE dvf_dXX.adresse_local ADD CONSTRAINT adresse_local_pkey PRIMARY KEY (idadresse, iddispoloc);

Bonne journée,

Antoine Herman
dv3f@texte-a-enlever.cerema.fr

Bonjour,

Je ne sais pas répondre à votre question, mais n'hésitez pas à partager ici si la DGFiP ne vous donne pas accès à ces données.
Généralement, une administration décourage "ses clients" quand elle manque de ressources (humaines ou financières) pour organiser la diffusion des "ses" données.

Bruno

Bonjour,

Disposant maintenant des donnés DVF je reviens vers vous.
Une première remarque : la notion de millésime est importante, les données portant sur les cinq dernières années.

Une seconde provenant d'un extrait de la documentation officielle : "Important, le descriptif des biens de l'acte notarié n'est pas repris dans le fichier résultat ..."
Les données descriptives sont donc les données "déclaratives" issues de l'application MAJIC, le lien étant réalisé à la parcelle (ou lot).

Une troisième, une parcelle (ou un lot) peut faire l'objet au cours d'une même année de plusieurs actes. La liaison parcelle (ou lot) et disposition est donc une liaison n-n nécessitant une table de jointure en SQL.

Une dernière : une disposition étant l'unité d'analyse juridique il existe une disposition pour chaque "mutation à titre onéreux". Donc dans le cadre d'une vente en l'état futur par exemple, les cinq premiers lots mentionnés sont ceux qui sont vendu à une seule et même personne (ou groupe de personne). Si je vends 7 lots à Mr X et 4 lots à Mr Y il y aura une ligne avec les cinq premiers lots pour MrX et une ligne avec 4 lots pour Mr Y.

Toute tentative de lien avec un local, une adresse, une surface est aléatoire et ne relève que de l'état des données MAJIC. Pour rappel seul un lot ou une parcelle peuvent faire l'objet d'un acte notarié (cf loi sur la publicité foncière 1955).

Enfin dernière remarque, le prix (ou valeur) indiqué porte sur l'ensemble de la disposition, si une disposition comprend 5 parcelles c'est le prix de vente de l'ensemble qui est mentionné, pour connaître la valeur fiscale de chaque parcelle (ventilation) il faut aller lire l'acte.

Pour ma part les données DVF sont intégrées comme suit : une table acte liaison 1-n avec la table disposition liaison 1 n avec la table jointure disposition-lot et liaison n-1 avec la table lot de mon MCD MAJIC (du bon millésime !).

Dernière modification par ChristopheV (Tue 17 November 2015 17:37)

et en complément le communiqué de presse associé :

Communiqué de presse
Présentation du Guide d’accompagnement DVF (Demande de valeurs foncières)
et de son site Internet www.guide-dvf.fr
Novembre 2015


Le Guide d’accompagnement à la mobilisation et l’exploitation des données Demande de Valeurs Foncières (DVF), porté par le Groupe national DVF, marque une avancée importante sur la connaissance des marchés fonciers et des prix de l’immobilier. Il va permettre aux élus, décideurs, équipes techniques et prestataires des organismes ayants droit, de renforcer leur compétence en matière de politique foncière et d’aménagement.

Ces données fiscales listant l’ensemble des ventes immobilières sur un territoire sont disponibles via un service de téléchargement du Ministère des Finances ; leur accès apporte aujourd’hui la possibilité pour les collectivités territoriales de connaître sur l’ensemble de leur territoire, les flux immobiliers touchant à l’évolution et à la transformation de l’espace urbain, mais aussi aux mutations agricoles, naturelles et forestières. Les collectivités disposent déjà d’outils de connaissance de leur territoire mais un déficit d’informations est constaté pour les politiques publiques et l’observation des dynamiques territoriales. DVF améliore sensiblement  cette connaissance objective et particulièrement sur la réalité des marchés et la place des acteurs.

La connaissance des marchés fonciers et immobiliers est un élément clé pour la compréhension des enjeux d'aménagement aux différentes échelles et constitue un outil d'aide à la décision pour les acteurs publics. Elle se heurte néanmoins à la difficulté d'accéder à des bases de données fiables.DVF vient utilement compléter les informations foncières et immobilières existantes, et le guide d'accompagnement permet de faciliter son accès et son utilisation.

Contact presse - GNDVF
Jean Louis FOURNIER : Coordinateur du Groupe national DVF 
- 05 56 99 87 30 : jlfournier@texte-a-enlever.bordeaux-metropole.fr

Issu d’un groupe technique de l’Association des Etudes foncières, le Groupe national DVF s’est constitué début 2014, et entretien des liens avec la DGFiP et le Ministère du logement. C’est un groupe de personnes  issues des structures qui sont ayants droits à DVF, ou utilisatrices pour les ayants droits. Il travaille à la diffusion et à la bonne utilisation de cette donnée DVF qui améliore très sensiblement la connaissance des territoires, sous l’angle des marchés fonciers et immobiliers, et sur le jeu des acteurs qui y participent.

Contacts presse - Guide:
Cyril QUEFFEULOU ; Responsable de la coordination du guide d’accompagnement DVF
– 02 35 63 77 94 c.queffeulou@texte-a-enlever.epf-normandie.fr


Au sein de Groupe national DVF, la maitrise d’ouvrage du guide a été portée par l’EPF Normandie adossé sur un groupe de cofinanceurs rassemblant les 13 Etablissements publics fonciers d’Etat et la Fnsafer.

Bonjour ChristopheV,

De ce que j'ai pu observé dans DVF et MAJIC, un croisement DVF - MAJIC à partir des données DVF relatives aux lots me paraissait difficile voire impossible.

Les numéros de lots fournis dans DVF ne sont pas intégralement reconstitués (limités à 5) et un bon nombre de mutations (ou dispositions si on se place à ce niveau), n'a pas de lots associés.

Par ailleurs, les numéros des lots fournis dans DVF correspondent (à priori) à la variable dnulot de MAJIC. Or, pour caractériser véritablement le lot et faire une jointure, il faudrait également avoir accès à la variable dnupdl de MAJIC qui n’apparaît pas dans DVF.

Mais je n'ai peut-être pas bien saisi le principe du rapprochement proposé pour le modèle.

Bonne journée