Le portail francophone de la géomatique

Bonjour
@ Aline :
Tu as téléchargé le millésime 2018 ?
De mon côté, je l'ai fait il y a quelques jours, et le résultat est décevant : exemple sur notre territoire principal :
2017 : 4772 mutations
2018 : 1318 mutations dont 10 seulement pour la période du 01/05 au 31/12.

Les deux livraisons annuelles étant prévues en Avril et Octobre, j'ai supposé que la livraison d'Avril 2019 était disponible. Par rapport à celle  d'Octobre 2018, il y a des différences marginales, mais force est de constater qu'il y a du retard dans les livraisons cette année.

Bonne journée

Bonjour

Je suis nouveau ici et j'espère être au bon endroit.
Je m'intéresse beaucoup à la base DVF que je trouve super. J'ai pas mal joué avec la version en CSV (mes connaissances en base de données sont trop limitées).
Je pense en avoir compris les grands principes, mais je bloque sur de transactions qui ont le même numéro de mutation, mais sont ventilées sur plusieurs lignes.
Dans le cas général il s'agit d'une mutation qui concerne un lot avec plusieurs biens: bâti, sols, vergers, forêt... La je comprends.
Mais j'ai certaines transactions (par ex: 2020-131636) qui ressemblent à des doublons si l'on y regarde pas de plus près.
Par exemple: mutation n° 2020-131587
Elle correspond à la vente de 2 locaux industriels (168 et 24m²) et d'une maison (95m²), le tout sur un terrain de 570m² de sols et de 155m² de jardins.
Je pensais naïvement avoir 5 lignes sur le fichier DVF, une par type de bien vendu.
Mais ce n'est pas ainsi. Elle comporte 6 lignes sur le fichier (CSV). Chaque bâti est sur 2 lignes (1 par type de terrain sur lequel il est implanté).
Pourquoi pas, c'est une autre logique, sûrement excellente et correcte.
Mais du coup comment faire pour être sûr que je prends pas le surface en triple dans la consolidation de ma transaction? J'avais fait un tableau croisé dynamique dans Excel sur le numéro de mutation et somme de surface de terrain, mais j'ai tout faux dans ce cas.

En gros je n'arrive pas à reconstituer les transactions avec d'un côté surface de bâti, de l'autre surface de terrains, puisque cette dernière est une info dans une ligne et pas une ligne séparée.

J'ai peut-être pas la bonne logique, si vous avez une idée?

Merci

Bonjour,

Je complète la liste de liens du post précédent par celle-ci qui est une "bonne" synthèse et une "bonne" approche de cette donnée : http://doc-datafoncier.cerema.fr/dv3f/t … f_tutoriel et la page 2 : http://doc-datafoncier.cerema.fr/dv3f/tuto/g1_denombrer

En grossissant le trait, il ne faut pas oublier que cette donnée DVF est publié en Open-data par "contrainte" par la DGFiP. Autrefois réservé aux ayants-droits (administration, établissement public, etc.), sa diffusion était brut, avec une documentation quasi inexistante, sans modèle de données associées.
C'est la raison pour laquelle, plusieurs de ses ayants-droits se sont "fédérés" en un groupement national (Groupe National DVF) pour informer et structurer au maximum cette donnée et devenir un interlocuteur privilégié auprès de la DGFiP pour tenter d'obtenir une donnée de plus en plus fiable et structuré.
L'ouverture de cette donnée en Open-data n'a pas fondamentalement changé la donne. La DGFiP livre ses moutures bruts de chez bruts et "demerden Sie sich".
Le travail du CEREMA vient compléter celui du GN DVF sous un angle assez pratique et propose un modèle de données bien structuré, une amélioration de la base, des outils périphériques, etc. -- Ce n'est pas le producteur de la donnée mais il propose un modèle et une interprétation de cette donnée qui est aujourd'hui le plus complet et à mon sens le plus qualitatif.

Et pour revenir à la question de cboengrand, même si votre usage de DVF se limite à une observation des mutations autour de chez vous, cela vaut la peine de lire les liens que je vous indique car vous y comprendrez peut-être le rôle de la disposition qui va vous permettre de définir correctement une mutation sans doublons !

Dernière modification par Edouard Hyvernat (Tue 02 February 2021 11:16)

Bonjour Christophe,

pourrais-tu préciser ce qu'est ce "champs de référence de publication de l'acte" et ce qu'apporte (ou retire) ce changement STP?

Merci

Bonjour,

En PJ un extrait de la doc DVF mode DGFiP (pas opendata) qui précise cette notion.
En fait le code d'identification de la Conservation et le champ "référence document" qui est en fait ce que l'on nomme référence de publication car on oublie le code CH. C'est ce code qui est délivré lors de la réception d'un acte par le SPF.
Composé de : année de publication (qui est en fait la référence au volume d'enliassement) suivi de "P" puis d'un numéro unique sur 4 chiffres.
Pour les actes publié avant 1990 cette référence est différente, un numéro suivit de "-" et d'un autre numéro.

C'est cette référence qui est présente sur la page de garde d'un acte publié, avec le tampon du conservateur.

Cette référence permet de connaître toutes les lignes de DVF qui concernent un acte, donc dans le cas de vente de plusieurs biens immeubles, permet de savoir quelles sont toutes les parcelles ou lots concernés par l'acte, sachant que le champ "valeur" exprime en euros le prix global de la vente.

La suppression de ce champs ne permet donc plus d'identifier toutes les lignes de DVF concernée par un acte donc une valeur.
Ce champ a été supprimé par la DGFiP sous couvert de données à caractère personnel car permet de remonté à l'acte, donc aux parties. Ce qui est fallacieux car l'acte est par essence opposable aux tiers ... Et il est impossible d'effectuer un traitement numérique de masse sur ces références, faudra toujours lire l'acte ligne à ligne pour identifier les parties.
J'ajoute que ce numéro étant unique il était facile de le remplacé par un autre numéro unique pour empêcher de remonter à l'acte et de préserver l'intégrité des données.

Les modèles actuels proposés pour DVF ne marchent que pour les ventes ne comportant qu'un seul bien, et j'ajoute en sus qu'ils ne fonctionnent vraiment bien sur l'aspect statistique que pour les régions urbaines où la majorité des ventes concernent des lots de copro. En matière de vente de parcelles, les modèles sont inadaptés, car statistiquement erronés. En effet la distribution statistique des ventes de parcelles est une Loi de puissance et non une loi normale, parler de moyenne dans ce cas n'a aucun sens.
Pour éclaircir la notion de loi de puissance :
Il y a beaucoup de vente à petit prix et très peu de ventes à prix élevé. Une autre comparaison, les salaires, il y a beaucoup de gens qui perçoivent un salaire "petit" et peu qui sont très bien payés.
Cette loi de puissance applique aussi le principe dit "loi de Parot" ou principe des 70%-30%
30 % des ventes génèrent 70% du volume financier.

Dernière modification par ChristopheV (Mon 08 February 2021 10:24)

Bonsoir,

J'ajoute que si qqu'un démontre l'existence d'une fractale temporelle dans les ventes de parcelles, alors :
Loi de puissance + fractale spatiale (facile un polygone est une fractale par essence) + Fractale temporelle, alors on démontre que le foncier pour les parcelles est un système organisé critique ou SOC.

Beaucoup (le GNDVF par exemple) se préoccupent de segmentation du marché foncier.
En utilisant mon approche il est assez facile de constater que pour les parcelles, un segment correspond peu ou prou à l'intégrale de a à b de la courbe de loi de puissance.

Bon je dis ça comme ça, car en fait tout le monde s'en fout, et quand tu entends des aménageurs publics (le grand Paris par exemple), des mines ponts, dont un devenu Préfet que le foncier c'est les terrain et l'immobilier c'est les immeubles (les bâtiments hein !), tu te dis que t'emmerdes le monde avec tes histoires.

C'est toujours pareil avec les données DGFiP sur le foncier, la DGFiP explique rien, et les "sachants urbanistes" expliquent qu'ils ont tout compris, sans connaître le BA BA du système foncier français et de ce qu'il produit et pourquoi ... et quelles sont les limites de l'exercice et la qualité et l'histoire de ces données.

C'est un détail mais Christophe semble confondre la loi de Parot avec la loi de Pareto (dite des 80-20)

Bonjour,

Voici une adresse pour signaler cette anomalie au service producteur:
bureau.cl2a-dvf@texte-a-enlever.dgfip.finances.gouv.fr

Source:
https://www.data.gouv.fr/fr/datasets/de … foncieres/

N'hésitez pas à nous dire si dans le millésime 2021 à venir en 2022, le producteur a pris en compte votre signalement.

Bonne journée!

Les process pour prendre en compte les signalement d'erreurs dans des données opendata sont l'exception bien plus que la règle actuellement.

Cela n'a donc malheureusement rien d'étonnant. Ce qui l'est plus c'est l'absence d'auto-contrôle sur des valeurs aberrantes.

Je crains de ne pas être assez expert pour tout à fait bien comprendre les explications des deux messages précédents.
   Je rappelle cependant à Christian Quest que le problème ne provient pas des données opendata de la DGFiP qui, certes, ne sont pas trop faciles à exploiter, mais qui, du moins dans le cas signalé, sont tout à fait correctes. En réalité, comme je le précisais dans mon message initial, il y a une erreur systématique de traitement par l'"Explorateur de données de valeur foncière (DVF)" publié sur data.gouv et produit par etalab.
   Et libre à Bruno Iratchet de considérer que la DINUM n' a rien à voir avec les "univers" (sic) data.gouv.fr et etalab.gouv.fr.

Jean-Philippe Gautier

C'est tellement facile de reporter sur les autres (la DGFiP, en l'occurrence) ses propres insuffisances.
   Tout d'abord, concernant l'"Explorateur de données de valeur foncière (DVF)", je trouve déjà, avec Christian Quest, que "l'absence d'auto-contrôle sur des valeurs aberrantes" est "étonnante".
   Ensuite il me paraît problématique (pour ne pas dire consternant) que, dès le départ,  l'auteur de l'explorateur n'aie pas pensé qu'une même vente pouvait porter sur plusieurs biens identiques, depuis la vente d'un immeuble entier jusqu'à l'acquisition de deux emplacements de stationnement.
    Et puis, si, selon votre affirmation, "il ne peut pas y avoir de correction sans une évolution de la donnée DGFiP", comment se fait-il que - sans parler de moi-même - la réutilisation "Immo Data", par exemple, ne commette pas votre erreur ?
   Enfin, j'ai signalé le problème début août. Je trouverais bien utile, en fait simplement correct, que, tant que vous ne le corrigez pas, cela soit explicitement signalé aux utilisateurs éventuels de l'Explorateur, ou (rêvons un peu) que vous recommandiez plutôt la réutilisation Immo Data https://www.data.gouv.fr/fr/reuses/cons … une-carte/
   Sur ce, je vous laisse ricaner.

Jean-Philippe Gautier

Euuuhhhhhh quand un bug est signalé, qu'on parle d'erreur systématique, c'est tout de même mieux de retirer temporairement l'outil (ou comme demandé par JPG d'adjoindre une note en texte), d'autant plus si il est utilisé par des "centaines de millions de personnes".

Enfin faut se rendre compte du nombre de conneries qui peuvent être publiées au final.

Mieux vaut pas de données du tout que des données fausses.

Dernière modification par tevrard (Thu 16 September 2021 12:15)

Ca fait bien longtemps que j'avais sorti le popcorn sur ce fil ^^

Tu ne trouves pas de qualificatif car je suis aussi "militant open-data" ( et je te prie de ne pas me le retirer ) et c'est précisément pour ça que oui, j'appelle à un peu de rigueur. Car je considère que c'est vertueux et que l'open data ne peut se développer que si les producteurs sont majoritairement rigoureux (ce qui permet aux ré-utilisateurs d'être confiant vis à vis de la donnée qu'ils utilisent).

Je ne pense pas qu'ici le problème proviennent des spécifications ou de la documentation. bien qu'un travail de documentation aurait peut être pu aider à se rendre compte de l'erreur, elle aurait très bien pu passer entre les mailles malgré tout.  Même en documentant correctement, ça peut arriver de faire une erreur. Et bon c'est pas grave, l'utilisateur fait remonter, il comprend.

Pour en revenir sur le message de Mr Desboeufs, au fond, il fait les choses correctement, il transmet au service concerné pour vérification et/ou correction. Il explique qu'il ne peut pas mettre en avant une solution commerciale et c'est normal.

La dessus se pose, à mon sens deux problèmes.
1/ Il ne fait pas confiance à l'utilisateur qui lui remonte un problème. "PEUT", "potentiel bug". Niveau communication, c'pas ouf
2/ Il s'appuie sur le fait que son outil est gratuit (osef, ça change rien) et largement diffusé (+100M utilisateurs mensuel) pour sous entendre qu'une seule remontée de bug c'est pas très grave et qu'il ne va pas bouger.
C'est ce qui me fait bondir personnellement, puisque au contraire, vu qu'il a énormément d'utilisateurs il devrait être attaché à fournir une donnée de qualité car les répercussions sont importantes et la moindre remontée devrait le mettre en alerte.

Un dernier point que je voudrais souligner, c'est que la DINUM s'appelle .gouv.fr, et que les données que ce service produit sont de fait des données de référence. Par conséquent, si ce service n'est pas attaché à produire des données de qualité, et bien ça pose des problèmes bien plus importants que si c'est la ptite asso du coin. Il y a un statut à assumer et la réaction épidermique n'est pas bon présage.


Bref, c'est plutôt un problème de communication, mais je ne voulais pas le laisser passer.

Dernière modification par tevrard (Fri 17 September 2021 14:47)

Montons un club pour nous exprimer aux prochains GeoDataDays ; j'en ressort écœuré de 'amazing revolutionnary apllication / tool / method / ...' et de 'open data inside' alors que ce dont j'ai besoin c'est d'un bon vieux back to basics: spécifications, contrôle, qualité, documentation, métadonnées avant de penser catalogue et diffusion...

Bonjour, soir à tous.

@Jerôme Tu fais ce que tu peux avec ce qu'on te donne. Et il n'existe pas d'algo fiable à 100% en l'état des données.
Suffirait que DGFiP mette un ID unique à la place de no data pour la référence de l'acte lors de l'export et le soucis est réglé. C'est quoi le service public (lol).

Après la grande manie avec les données de la DGFiP c'est de leur faire dire ce qu'elles ne peuvent pas dire.

Quand les gens auront compris que ce sont des données foncières mélangées à des données fiscales, et que le géniteur principal de ces données est l'acte notarié relatif à des mutations à titre onéreux. De savoir ce que contient un acte et de comprendre enfin que la notion de bâti est une notion d'urbanisme qui N'EXISTE PAS en matière foncière nous auront fait un grand pas en avant. Et ils arrêterons de parler de prix moyen du m² constructible, qui est une hérésie scientifique et statistique. Le prix moyen des lots de copropriétés je veux bien c'est gaussien comme distribution, mais le prix des parcelles, c'est une loi de puissance, pas une distribution normale. Et avec deux sous de logique ça ce comprend, pas besoin d'avoir fait bac +12, il y a beaucoup de vente de parcelles à bas prix et peu à des prix très élevés, comme la répartition des salaires, beaucoup gagnent peu et très peu gagnent beaucoup. Ceux que ça intéressent regardez du coté des SOC (ou systèmes organisés critiques) ça vous donnera une idée de ce que ces données peuvent dire.

Les gars ils veulent faire de la segmentation avant d'avoir compris ce qu'est la donnée et ce qu'elle contient vraiment, l'envie de courir avant de savoir marcher en quelque sorte.

Ceci pour ceux qui ne me connaîtraient pas, j'ajoute que de part mes fonctions j'ai accès à l'ensemble des données cadastre, SPF, y compris les actes et ce sur un ensemble conséquent. Les résultats de nos traitements nous pouvons les comparer à la réalité.

Dernière modification par ChristopheV (Tue 21 September 2021 00:09)