Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

evolution dgfip -> plus de FANTOIR en 2022, remplacé par TOPO #345

Open
landryb opened this issue Jan 27, 2022 · 27 comments
Open

evolution dgfip -> plus de FANTOIR en 2022, remplacé par TOPO #345

landryb opened this issue Jan 27, 2022 · 27 comments
Labels
amélioration import concerne les fonctions d'import et de traitement des fichiers DGFiP major stand by

Comments

@landryb
Copy link
Contributor

landryb commented Jan 27, 2022

il va probablement falloir faire evoluer les moulinettes d'import, cf https://www.data.gouv.fr/fr/datasets/fichiers-fimoca-et-fimoct-relatifs-aux-structures-de-la-dgfip/

Cela induit la mise en place de nouveaux fichiers qui remplaceront les actuels FANTOIR (voies et lieux-dits), FIMOCA (structures de la DGFIP) et FIMOCT (compétences géographiques des structures de la DGFIP).
Les fichiers actuels FANTOIR, FIMOCA et FIMOCT ne seront plus disponibles à compter de mars 2022.

format_TOPO.PDF

serait la spec du 'nouveau' fichier TOPO qui remplacerait FANTOIR.

@landryb
Copy link
Contributor Author

landryb commented Jan 27, 2022

https://georezo.net/forum/viewtopic.php?pid=349671#p349671 a aussi potentiellement des infos.

@MaelREBOUX MaelREBOUX added amélioration import concerne les fonctions d'import et de traitement des fichiers DGFiP major labels Jan 27, 2022
@stephanerolle
Copy link

Bonjour,
Vu ici : https://www.data.gouv.fr/fr/datasets/disparition-des-fichiers-fantoir-fimoca-et-fimoct-en-juillet-2022-mise-en-place-des-fichiers-topo-structures-uamissions-et-competences/
"Initialement prévus en mars 2022, les travaux de réécritures du référentiel Topad ont été reculés à la fin du premier semestre 2022.
Les derniers fichiers FANTOIR, FIMOCA et FIMOCT disponibles seront ceux de juillet 2022."

Du coup plus forcement urgent...

@MaelREBOUX
Copy link
Collaborator

Bonjour,

Vu pour la dernière publication juillet 2022 mais il faut construire l'avenir.

"On" m'a dit justement confirmé dans l'oreillette que dans le cadre de la BAN un fichier FANTOIR sera reconstruit à partir des données TOPO et sera mis en téléchargement. Probablement ici.

@MaelREBOUX
Copy link
Collaborator

MaelREBOUX commented Sep 13, 2022

Mise à jour de août 2022 sur : https://www.data.gouv.fr/fr/datasets/objet-disparition-des-fichiers-fantoir-fimoca-et-fimoct-en-fevrier-2023-mise-en-place-des-fichiers-topo-structures-uamissions-competences-et-acheminement/

Initialement prévus en mars 2022, les travaux de réécritures du référentiel Topad ont été reculés à début 2023.
Les derniers fichiers FANTOIR, FIMOCA et FIMOCT disponibles seront ceux de janvier 2023.

@landryb
Copy link
Contributor Author

landryb commented Jun 27, 2023

jeté un oeil au contenu de https://adresse.data.gouv.fr/data/fantoir/fantoir-2023-04.gz, c'est un seul fichier gzippé avec a priori (pas creusé) la meme structure que FANTOIR, mais avec les données pour la france entière (1go décompressé) alors qu'auparavant c'était région par région ou département par département.

comme les fichiers fonciers, il y'a une ligne d'en-tete et une de pied de page a faire sauter, et pour les autres lignes les 6 premiers caractères correspondent a dept+direction+insee, donc pour avoir "uniquement les données nous concernant" il faut filtrer. Enfin bref, le principe est le meme que pour les autres fichiers MAJIC.

^@^@^@^@^@^@^@^@^@^@ ENEVERS                  2023050120231220000000
010        AIN                                             00000000000000 00000000000000
010001    WL'ABERGEMENT-CLEMENCIAT        N  3      000082500000000000000 00000001987001
010001A008WLOT BELLEVUE                   N  3  0          00000000000000 00000002001351               000592   BELLEVUE
010001A015DLOT LES CHARMILLES             N  3  0          00000000000000 00000001998274               000562   CHARMILL
010001A025PLOT LES COQUELICOTS            N  3  0          00000000000000 00000001999300               000572   COQUELIC
010001A028TLOT LES LILAS                  N  3  0          00000000000000 00000002001025               000582   LILAS
010001A030VLOT MUNETVILLE                 N  3  0          00000000000000 00000001991302               000522   MUNETVIL
...
9766171952LAV  ZOUBERT ADINANI            R     0          00000000000000 00000002019175               002711   ADINANI
9766176000LCD  3                          R     0          00000000000000 00000002011192               000221   3
9766176200DCD  1                          R     0          00000000000000 00000002011192               000231   1
9766176250HCD  1A                         R     0          00000000000000 00000002011192               000241   1A
9999999999 8276922109370608239751000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

@stephanerolle
Copy link

J'ai trouvé ça il y a quelques jours mais pas d'infos précises de dates....
https://www.collectivites-locales.gouv.fr/mise-en-ligne-des-fichiers-fantoir-2023

@MaelREBOUX
Copy link
Collaborator

Well well well.

Alors sur https://www.collectivites-locales.gouv.fr/mise-en-ligne-des-fichiers-fantoir-2023 on peut bien télécharger les fichiers FANTOIR 2023. 1 fichier ZIP par région administrative. Ce fichier ZIP contient n fichiers FANTOIR départementaux.

Donc on peut encore utiliser ça cette année ?! Alors que c'est censé ne plus exister ?
Je n'y comprends rien.

Et ils sont où les nouveaux fichier TOPO ?
Si je lis bien https://www.data.gouv.fr/fr/datasets/objet-disparition-des-fichiers-fantoir-fimoca-et-fimoct-en-juillet-2023-mise-en-place-des-fichiers-topo-structures-uamissions-competences-et-acheminement/ : ils ne sont pas encore disponibles ?

@sigCCTC
Copy link

sigCCTC commented Oct 31, 2023

La DGFiP vient de publier les fichiers suivants :

@stephanerolle
Copy link

Le nouveau Fantoir (TOPO) est devenu un foutoir apparemment...plus la même structure qu'avant :
https://www.economie.gouv.fr/cedef/cadastre-topo-fantoir
https://www.data.gouv.fr/fr/datasets/fichier-des-entites-topographiques-topo-dgfip-1/#/resources

FANTOIR (2023):

040068    CDAUPHIN                        N  3      000059000000000000000 00000001987001
040068A001MQUA CHAMOURAS                  N  3  0          00000000000000 00000001988340               000372   CHAMOURA
040068A002NQUA LA RENCONTRE               N  3  0          00000000000000 00000001988340               000212   RENCONTR
040068A003PQUA LA GAUDINE                 N  3  0          00000000000000 00000001988340               000422   GAUDINE
040068A004RQUA LE LAUVAS                  N  3  0          00000000000000 00000001988340               000452   LAUVAS

TOPO (2024) :

991009304068    13;DAUPHIN;N;N;3;3;;;00000000;18750101;;;00000000
991009304068A00214;QUA LA RENCONTRE;;;;;0;;00000000;19881205;2;RENCONTR;00000000
991009304068005114;CHE SEYNET;;;;;0;;00000000;19971126;1;SEYNET;00000000
991009304068006214;CHE DU FRAIL;;;;;0;;00000000;19881205;1;FRAIL;00000000
991009304069B00514;LES BASSES TRAVERSES;;;;;0;;00000000;19910714;3;TRAVERSE;00000000 

@landryb
Copy link
Contributor Author

landryb commented Jul 16, 2024

en pratique, on fait quoi ?

  • on continue d'utiliser le fantoir de mai 2023 ?
  • on trouve/fait une moulinette pour convertir TOPO au format FANTOIR ?
  • on modifie l'importeur du plugin qgis pour supporter TOPO ?

@landryb
Copy link
Contributor Author

landryb commented Jul 16, 2024

pour faire un mapping de TOPO vers FANTOIR, il faut:

pour 1 ce n'est pas 'extreme', car il y'a un opendatasoft avec une API sur https://data.economie.gouv.fr/explore/dataset/topo-fichier-des-entites-topographiques, donc p.ex si je veux extraire uniquement les enregistrements sur la region rhone alpes (mon cas d'usage pour le CRAIG) je peux filtrer sur le debut du champ code_topo ex https://data.economie.gouv.fr/explore/dataset/topo-fichier-des-entites-topographiques/api/?q=code_topo+like+%279910084%25%27

par contre il y'a peu de champs dans TOPO par rapport a tous ceux qui etaient dans fantoir, on en retrouve certain mais pas tous, a voir si ceux qui manquent étaient 'nécessaires' pour le plugin qgis.

@landryb
Copy link
Contributor Author

landryb commented Jul 16, 2024

evidemment, l'API d'opendatasoft a une limite a 100 enregistrements, donc si je veux exporter mes 763545 enregistrements je dois le faire en 8000 appels..

  "message": "Invalid value for limit API parameter: 763545 was found but -1 <= limit <= 100 is expected."

donc il semble que le plus simple est d'exporter tout le jeu de données france entière par l'onglet 'export' (2.7Go en JSON, 583Mo en CSV...) plutot que l'onglet 'API', et de le filtrer a posteriori.

j'ai l'impression de refaire un travail qui a déjà été fait 100x mais je ne l'ai trouvé nulle part donc.. je fais des hypotheses.

pour ce qui est d'un mapping des champs, dans TOPO on a ces champs (exemple du premier record de l'API):

  • "code_topo":"991005329014B71614",
  • "libelle":"GARSIGEN PLACE AR FEUNTEUN",
  • "type_commune_actuel_r_ou_n":null,
  • "type_commune_fip_rounfip":null,
  • "rur_actuel":null,
  • "rur_fip":null,
  • "caractere_voie":"0",
  • "annulation":null,
  • "date_annulation":"00000000",
  • "date_creation_de_article":19910714,
  • "type_voie":"3",
  • "mot_classant":"FEUNTEUN",
  • "date_derniere_transition":"00000000"

le schema json n'est pas trouvé sur https://schema.data.gouv.fr/ mais il est présent sur l'onglet information du dataset , et il y'a le pdf tout en haut de ce ticket (meme si le schema a pu changer depuis..)

pour la correspondance avec fantoir, on peut donc dire que:

  • code_topo doit correspondre a la concatenation des codes direction/commune/identifiant dans la commune/code rivoli ?/code nature de la voie ? (caracteres 1 a 15) , ex pour 991005329014B71614
    • on sait que 99100 = france
    • les 2 cars suivants (53) sont a priori le code région
    • donc 29014 est probablement le code insee de la commune
    • les 4 cars suivants sont a priori le code rivoli, commencant par une lettre ?
    • et les 2 derniers (13, 14..) seraient pour le type de l'enregistrement:14 = c'est une voie, 13 c'est une commune,12 = departement, 11=region, 10 = pays ?
  • libelle correspond au libelle (26 caracteres de 16 a 41)
  • type_commune_actuel_r_ou_n (ou type_commune_fip_rounfip ?) se mappe sur le champ 'type de la commune' (caractere 43 de l'enregistrement)
  • rur_actuel (ou rur_fip?) se mappe sur le champ 'caractere RUR' (caractere 46 de l'enregistrement)
  • caractere_voie (0=publique/1=privée) se mappe sur le meme champ dans fantoir (caractere 49 de l'enregistrement)
  • annulation (O ou Q) se mappe sur le champ 'caractere d'annulation' (caractere 74 de l'enregistrement)
  • date_annulation se mappe sur le champ identique (7 caracteres de 75 a 81)
  • date_creation_de_article se mapp sur le champ 'date de creation de l'article (7 caracetres de 82 a 88)
  • type_voie se mappe directement sur le meme champ dans fantoir (caractere 109 de l'enregistrement)
  • mot_classant se mapperait sur le champ 'Dernier mot entièrement alphabétique du libellé de la voie' (8 caracteres de 113 a 120)
  • date_derniere_transition inutilisé ?

ce qui manquerait de fantoir:

  • les champs d'information sur la population (necessaires pour le plugin QGIS)
  • le Code identifiant MAJIC de la voie ?

@landryb
Copy link
Contributor Author

landryb commented Jul 16, 2024

si on veut 'reconstruire' le champ cle rivoli (meme si a priori il ne sert pas dans le plugin qgis, j'imagine que des moulinettes peuvent se casser les dents dessus), j'ai trouvé https://georezo.net/forum/quickpost.php?tid=102292

en decryptant un peu ce message l'algo est le suivant:

  • (19 * les 6 chiffres du code dept + code direction + code insee) + (11 * le premier cararactere du code rivoli, chiffre si chiffre, 10 si A, 11 si B, etc..) + (1 * les 3 derniers chiffres du code rivoli) le tout modulo 23 pour avoir l'ordre de la clé dans la chaine ABCDEFGHJKLMNPRSTUVWXYZ en partant de 0 (attention il n'y a que 23 caracteres, ce n'est pas tout l'alphabet les lettres I O et Q ont sauté)

ex:
150001B262N -> ((150001 * 19) + (11 * 11) + 262) % 23) = 12 -> N est bien la 12e lettre, si A a l'indice 0
380003B001W -> ((380003 * 19) + (11 * 11) + 1) % 23) = 19 -> W est bien la 19e lettre de la chaine

@landryb
Copy link
Contributor Author

landryb commented Jul 17, 2024

petite update, j'ai 130 lignes de python qui me permettent de reproduire (à peu près) depuis un extrait du CSV de TOPO sur la commune 15001 le fichier FANTOIR correspondant, les seules pertes étant pour l'instant:

  • plus de champ 'identifiant majic', c'est le champ codvoi dans la table voie - 'Code identifiant la voie dans MAJIC2. - Permet de faire le lien entre le code voie RIVOLI et le code voie MAJIC2.')
  • valeur arbitraire a 1 pour le champ 'caractère du lieu dit' (1 = bati, 0 = non bati) - c'est le champ indlnbat dans la table voie - 'Indicateur lieu-dit non bâti - Zone servie uniquement pour les lieux-dits.Permet d’indiquer si le lieu-dit comporte ou non un bâtiment dans MAJIC.1 pour lieu-dit non bâti, 0 sinon.')
  • les informations sur les champs de population pour la commune

je ne sais pas si ces 2 champs ont une utilité dans le code du plugin qgis/la création des vues/requetes/etc. @mdouchin @Gustry une idée ?

par contre, pour la commune donnée, il y'a 0 différence en terme de voies par rapport au fantoir 2023, je vais comparer sur un département entier, mais s'il n'y a aucune nouvelle information intégrée dans TOPO, autant utiliser le fantoir 2023.

@MaelREBOUX
Copy link
Collaborator

Le dernier fichier FANTOIR disponible semble un millésimé avril 2023 téléchargeable ici : https://www.data.gouv.fr/fr/datasets/fichier-fantoir-des-voies-et-lieux-dits/

Dans le fichier TOPO téléchargeable ici : https://www.data.gouv.fr/fr/datasets/fichier-des-entites-topographiques-topo-dgfip-1/
j'y trouve des voies créées en décembre 2023 sur Rennes.

991005335238954414;RUE VICTOR GRIGNARD;;;;;0;;00000000;20240210;1;GRIGNARD;00000000

Donc, pour moi, TOPO est plus à jour.

@landryb
Copy link
Contributor Author

landryb commented Jul 18, 2024

Le dernier fichier FANTOIR disponible semble un millésimé avril 2023 téléchargeable ici : https://www.data.gouv.fr/fr/datasets/fichier-fantoir-des-voies-et-lieux-dits/

Dans le fichier TOPO téléchargeable ici : https://www.data.gouv.fr/fr/datasets/fichier-des-entites-topographiques-topo-dgfip-1/ j'y trouve des voies créées en décembre 2023 sur Rennes.

991005335238954414;RUE VICTOR GRIGNARD;;;;;0;;00000000;20240210;1;GRIGNARD;00000000

Donc, pour moi, TOPO est plus à jour.

je confirme, je viens déjà de trouver de nouvelles entrées pour la commune d'ALLY (150003). mon bout de script python est sur https://github.com/landryb/topo2fantoir

@landryb
Copy link
Contributor Author

landryb commented Jul 18, 2024

pour retrouver 'facilement' les voies ajoutées en 2023:

grep 00000002023 gen15.txt

ou dans le fichier topo source, pareil faire une recherche sur 202306 pour juin 2023..

@landryb
Copy link
Contributor Author

landryb commented Jul 19, 2024

je viens de tester l'import du pci 202404 & majic 2024 incluant un fichier fantoir généré depuis TOPO avec https://github.com/landryb/topo2fantoir, et il se passe pour l'instant bien. les 2 tables commune et voie sont correctement remplies depuis mon fantoir 'maison'.

reste a voir la génération de BP/RP/l'utilisation en réel; mais de ma compréhension du code, les champs manquants ne sont pas utilisés, les jointures/recherches se font sur les clef voie ou commune:

cadastre/dialogs/search_dialog.py:            sql = ' SELECT DISTINCT v.voie, c.tex2 AS libcom, v.natvoi, v.libvoi'
cadastre/dialogs/search_dialog.py:                sql += ' INNER JOIN "{}"."geo_commune" c ON c.commune = v.commune'.format(connectionParams['schema'])
cadastre/dialogs/search_dialog.py:                sql += ' INNER JOIN geo_commune c ON c.commune = v.commune'
cadastre/scripts/plugin/edigeo_create_table_parcelle_info_majic.sql:LEFT OUTER JOIN [PREFIXE]voie v ON v.voie = p.voie
cadastre/scripts/plugin/majic_recuperation_locaux_par_parcelle.sql:    LEFT JOIN voie v ON v.voie = l.voie
cadastre/templates/parcelle_info_locaux_detail.sql:    LEFT JOIN voie v ON v.voie = l.voie
cadastre/templates/parcelle_info_parcelle_majic.sql:    ON v.voie = p.voie
cadastre/templates/proprietes_baties_line.tpl.sql:LEFT OUTER JOIN $schema"voie" v ON v.voie = l.voie
cadastre/templates/proprietes_non_baties_line.tpl.sql:LEFT OUTER JOIN $schema"voie" v ON v.voie = p.voie

j'ai l'impression que pour la table voie surtout les champs libvoi et natvoi sont utilisés... donc a terme, pour les besoins du plugin QGIS une alimentation/import direct depuis TOPO serait possible.

@landryb
Copy link
Contributor Author

landryb commented Jul 19, 2024

je n'ai pas vraiment l'habitude d'utiliser le plugin, mais une recherche par adresse me trouve bien des voies qui sont présentes dans mon fichier fantoir (et qui n'étaient pas présentes dans le fantoir de l'année passée) donc elles sont bien "utilisables" par le plugin.

cependant, aucune parcelle ne remonte lorsque j'utilise une des valeurs du champ 'adresse' pour faire une recherche dans une commune.

image

cependant je ne sais pas si c'est moi qui n'ait pas de chance ou qui utilise mal le plugin .. mais il semble que dans la fiche d'info d'une parcelle, le champ natvoi et le champ libvoi soient concaténés sans un espace, alors que l'espace est présent dans le champ de selection des adresses:

image

mais en faisant une recherche sur un libvoi ou natvoi est vide, c'est pareil rien ne remonte.. donc je ne sais pas si c'est lié au fait que natvoi soit paddé ou pas avec un espace. Dans la base, la longueur du champ est la meme pour les données 2023 (donc source fantoir) ou 2024 (donc source topo)

@landryb
Copy link
Contributor Author

landryb commented Jul 19, 2024

a priori, cette recherche ne fonctionne pas car la requete faite sur la table parcelle_info filtre sur voie avec un parametre contenant ... la valeur du champ manquant codvoi.

 SELECT ogc_fid, tex, idu, geo_section, geom, comptecommunal, geo_parcelle
     FROM "qad152024"."parcelle_info" WHERE 2>1 AND voie = '15000300000B071' ORDER BY geo_parcelle

les 5 zéros après 150003 semblent une valeur par défaut, et aucune valeur dans la table ne matche, car elles ont la valeur venant de majic? si j'ai bien suivi ce champ voie dans la table parcelle est construit ici: https://github.com/3liz/QgisCadastrePlugin/blob/master/cadastre/scripts/plugin/2023/majic3_formatage_donnees.sql#L55

  • 2023
 select voie,codvoi,ccoriv,libvoi from qad2023.voie where commune = '150003' and ccoriv ='B071';
      voie       | codvoi | ccoriv |           libvoi
-----------------+--------+--------+----------------------------
 15000300042B071 | 00042  | B071   | LAFON
  • 2024
select voie,codvoi,ccoriv,libvoi from qad152024.voie where commune = '150003' and ccoriv ='B071';
      voie       | codvoi | ccoriv |           libvoi
-----------------+--------+--------+----------------------------
 15000300000B071 |        | B071   | LAFON

dans les tables parcelle_info et parcelle l'id 15000300000B071 n'existe pas, mais avec le codvoi.. qu'on n'a plus dans TOPO.

SELECT distinct(voie) FROM "qad152024"."parcelle_info" WHERE voie like '15000300%B071';
 15000300042B071
SELECT distinct(voie) FROM "qad152024"."parcelle" WHERE voie like '15000300%B071';
 15000300042B071

pour contourner ca ... j'hésite a massacrer un peu la requete SQL faite par le plugin, et remplacer le matching exact sur la voie par un LIKE en remplacant 00042 par %. mais évidemment, ca peut faire remonter des faux positifs ?

@landryb
Copy link
Contributor Author

landryb commented Jul 19, 2024

avec cette correction locale dans le code du plugin (eg remplacer voie = '15000300042B071' par voie LIKE '150003%B071' dans la requete construite), la requete pour lister les parcelles correspondant a une adresse fonctionne, mais il se peut qu'il y'ait trop d'enregistrements..

--- a/cadastre/dialogs/search_dialog.py
+++ b/cadastre/dialogs/search_dialog.py
@@ -858,7 +858,7 @@ class CadastreSearchDialog(QDockWidget, SEARCH_FORM_CLASS):
         # Set filter expression for parcell child data
         ckey = self.searchComboBoxes[key]['search']['parcelle_child']
         if key == 'adresse':
-            filterExpression = "voie = '%s'" % value['voie']
+            filterExpression = "voie LIKE '%s%%%s'" % (value['voie'][0:6], value['voie'][11:])
 
         if key == 'proprietaire':
             filterExpression = "comptecommunal IN (%s)" % ', '.join(value['cc'])

@landryb
Copy link
Contributor Author

landryb commented Jul 19, 2024

petite astuce au passage pour le debugging, ajouter la ligne QgsMessageLog.logMessage(sql, "cadastre", Qgis.Info) ici: https://github.com/3liz/QgisCadastrePlugin/blob/master/cadastre/cadastre_common_base.py#L168

permet de dumper toutes les requetes SQL faites par le plugin dans un onglet cadastre de la boite de messages QGIS, bien pratique pour debugguer..

landryb added a commit to landryb/QgisCadastrePlugin that referenced this issue Jul 24, 2024
…as l'identifiant majic (ccovoi) (3liz#345)

ces codes voies proviennent de l'import depuis TOPO
les valeurs sont quand même uniques en concaténant le code insee+ccoriv.
@Mavialle
Copy link

Bonjour,

Je viens de recevoir le nouveau millésime des données MAJIC et j'aimerais l'importer. Le soucis est qu'avec le remplacement de FANTOIR par TOPO, je ne sais pas quoi indiquer dans le panneau de configuration du plugin, rubrique "nom des fichiers MAJIC", encart "FANTOIR" ? J'ai épluché cette discussion et d'autres qui sont liées mais je ne suis pas sûre d'avoir bien compris.

Pourriez-vous me confirmer qu'il faut :

  • Soit utiliser le dernier millésime FANTOIR, mais qui n'a pas eût de mises à jour depuis avril 2023 (téléchargement ici)
  • Soit :
    1. Récupérer le fichier TOPO national ici
    2. Le passer dans la moulinette proposée ici
    3. Utiliser le fichier obtenu avec le plugin cadastre
  • Soit directement récupérer et utiliser le fichier issu de la moulinette citée plus haut ici, sur le site CRAIG

Je vous remercie d'avance pour votre retour, qui je pense aidera d'autres personnes à y voir plus clair.

@landryb
Copy link
Contributor Author

landryb commented Sep 13, 2024

@Mavialle oui c'est l'idée, tu as bien compris les différentes possibilités qui s'offrent à toi :)

@Mavialle
Copy link

Bonjour,

Juste pour info, j'ai utilisé le fichier du CRAIG après l'avoir dézippé (on obtient un .txt) et l'import semble avoir bien fonctionné. Je ne vois pas de soucis particulier dans ce qui est remonté par l'outil cadastre. Je dirais aux utilisateurs des données d'être alertes cette année sur les éventuelles problématiques amenées par l'arrêt de la base FANTOIR, et je vous ferais un retour si des anomalies nous sont remontées. Merci beaucoup pour votre aide en tout cas !

@stephanerolle
Copy link

Bonjour,

je sais pas si il y a un lien, mais je m'aperçois qu'à l'intégration d'un cadastre, le champ Propriétaires (infos détaillées) de la table Parcelles est incomplet. Il manque les informations d'adresse.

champ_incomplet

=>Je ne peux également pas faire de recherche par adresse.
J'ai testé avec un fantoir issu de la manip CRAIG (au passage merci @landryb ) et aussi avec un fantoir 2023, le tout sur une version QGIS 3.28 et plugin cadastre 1.20. Je l'ai testé sur deux communes différentes.
Le résultat est le même sur les 2 intégrations et les 2 communes, j'en conclus que cela ne vient pas du fichier fantoir.
Pour info une doc à jour et plus complète est sortie il y a peu : doc fichier TOPO

Question annexe :
Dans la table Parcelles, le champ Adresse contient les valeurs qui proviennent du fichier BATI, dans le champ Propriétaires (infos détaillées) l'adresse provient du fichier PROP, la recherche sur les parcelles s'effectue sur le fichier FANR.....ces 3 adresses peuvent être différentes. Pour contacter au mieux les propriétaires, l'idée est donc de se baser sur ce qui est censé remonter dans le champ Propriétaires (infos détaillées), càd lié à la personne ?
(on est d'accord qu'aucunes informations issues de la BAN sont prises en compte dans le plugin?).

Au plaisir pour échanger sur ces sujets.

@stephanerolle
Copy link

=>Je ne peux également pas faire de recherche par adresse. J'ai testé avec un fantoir issu de la manip CRAIG (au passage merci @landryb ) et aussi avec un fantoir 2023, le tout sur une version QGIS 3.28 et plugin cadastre 1.20. Je l'ai testé sur deux communes différentes. Le résultat est le même sur les 2 intégrations et les 2 communes, j'en conclus que cela ne vient pas du fichier fantoir. Pour info une doc à jour et plus complète est sortie il y a peu : doc fichier TOPO

Alors, je viens de tester avec la version LTR 3.34, là ca fonctionne, le champ Propriétaires (infos détaillées) est bien renseigné.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
amélioration import concerne les fonctions d'import et de traitement des fichiers DGFiP major stand by
Projects
None yet
Development

No branches or pull requests

5 participants