Import Majic - spatialite - avec contenu incohérent (préfixes avec l'année) et fonctionnalités non opérantes

[FrancoisB74]

Description du bug

Après import Edigeo + Majic III, avec paramètres {année = 2020 ; département = 74}, nous avons constaté :

• manque d'informations via la fenêtre "info_parcelle" : VIDE pour Résumé / Propriétaires / Subdivisions / Locaux
• relevé parcellaire / relevé de propriété non fonctionnel
• des tables vides (geo_unite_fonciere notamment)
• une vue incomplète (v_geo_parcelle)
• des tables incomplètes (parcelle_info notamment) -> c'est-à-dire absence des attributs provenant de jointures (proprio, voie, etc.)
• pour les tables de données Majic (ex : parcelle, pev, local00, etc.) des identifiants commençant par '2020'
• pour les tables de données Majic (ex : parcelle, pev, local00, etc.) des "clé étrangère" (dans l'esprit) commençant par '2020''
• pour 1 table de données Majic (local10) 1 "clé étrangère" (dans l'esprit) commençant par '74' - local00 - alors que l'identifiant de la table local00 ne contient pas '74'

Dans les parties restant fonctionnelles, on a simplement :

• le rendu visuel (à l'import) du cadastre graphique ;
• l'outil de recherche de parcelle (Commune>Section>Parcelle) ;
• la possibilité d'agir sur une parcelle identifiée via cet outil (déplacement carte, zoom, sélection, affichage fenêtre "info_parcelle"

Pistes de résolution

1. Le problème nous semble possiblement provenir d'un script SQL d'import, et/ou d'une non adéquation d'un script d'import avec les données MAJIC nouvelle version.

2. Plus sûrement, nous avons pu constater que le paramètre de date (saisi avant l'import), était bien utilisé pour préfixer certains champs, ce qui semble poser un problème (de lien entre tables à priori) ; Ainsi, la modification de la date dans l'import cadastre (ex : 2020->2013) a pu confirmer que cette date est utilisée pour préfixer les champs.

3. Actions correctives - manuelles - qui nous ont permis de retrouver une cohérence de BD et de faire fonctionner les outils à priori du mieux possible :

• modifier les identifiant comportant le millésime de l'année (suppression de '2020') ;
• modifier les "clés étrangères" (dans l'esprit) comportant le millésime de l'année (suppression de '2020') ;
• modifier la "clé étrangère" (dans l'esprit) local00 de la table local10 (suppression de '74') ;
• relancer le script de création de geo_unite_fonciere
• relancer le script de création de parcelle_info

Note : le changement du préfixe pour le champ local00 de la table local10 (suppression de '74') a permis in-fine d'afficher les données du local dans la fenêtre 'd'infos parcelle'

(Actions correctives réalisées sur QGIS 3.16, non testées sur QGIS 3.4 à ce jour)

4. Notre souhait : Si possible, que soit identifié via la communauté les parties de script Python/SQL d'import en cause pour les rectifier dans une nouvelle version de l'outil.

Reproduire le bug

Etapes pour reproduire le bug (remplacer)

1. Ouvrir la fenêtre...
2. Lancer l'import...

Log

Ci-dessous le log du plugin Cadastre (pas/peu informatif, sauf pour savoir où sont situés les scripts SQL utilisés) :

_INITIALISATION
* Copie du répertoire C:\Users\Benjamin\AppData\Roaming\QGIS\QGIS3\profiles\default\python\plugins\cadastre\scripts/plugin 
0 s 
STRUCTURATION BDD
Création des tables 
Création des tables edigeo 
Ajout de la nomenclature 
4 s 
MAJIC
Suppression des contraintes 
4 s 
- SUPPRESSION DES CONTRAINTES D'INTEGRITEES : DEBUT 
4 s 
- suppression clefs primaires 
4 s 
Suppression des indexes 
4 s 
Import des fichiers majic 
Y:/ETUDES/SIG_COLLECTIVITES/SIG_GESTION/PRAZ_SUR_ARLY/CADASTRE_2020/Matrice_2020_74215_RGD\REVBATI.txt 
Y:/ETUDES/SIG_COLLECTIVITES/SIG_GESTION/PRAZ_SUR_ARLY/CADASTRE_2020/Matrice_2020_74215_RGD\FANTOIR.txt 
Y:/ETUDES/SIG_COLLECTIVITES/SIG_GESTION/PRAZ_SUR_ARLY/CADASTRE_2020/Matrice_2020_74215_RGD\REVD166.txt 
Y:/ETUDES/SIG_COLLECTIVITES/SIG_GESTION/PRAZ_SUR_ARLY/CADASTRE_2020/Matrice_2020_74215_RGD\REVNBAT.txt 
Y:/ETUDES/SIG_COLLECTIVITES/SIG_GESTION/PRAZ_SUR_ARLY/CADASTRE_2020/Matrice_2020_74215_RGD\REVFPDL.txt 
Y:/ETUDES/SIG_COLLECTIVITES/SIG_GESTION/PRAZ_SUR_ARLY/CADASTRE_2020/Matrice_2020_74215_RGD\REVPROP.txt 
73 s 
Mise en forme des données 
73 s 
- FORMATAGE DONNEES : DEBUT 
73 s 
- Traitement: parcelle 
73 s 
- Traitement: suf 
74 s 
- Traitement: sufexoneration 
74 s 
- Traitement: suftaxation 
74 s 
- Traitement: local00 
74 s 
- Traitement: local10 
82 s 
- Traitement: pev 
82 s 
- Traitement: pevexoneration 
82 s 
- Traitement: pevtaxation 
82 s 
- Traitement: pevprincipale 
83 s 
- Traitement: pevprofessionnelle 
83 s 
- Traitement: pevdependances 
83 s 
- Traitement: proprietaire 
83 s 
- création: comptecommunal à partir de proprietaire 
83 s 
- Traitement: pdl 
83 s 
- Traitement: parcellecomposante 
83 s 
- Traitement: lots 
84 s 
- Traitement: lotslocaux 
84 s 
- Traitement: commune 
84 s 
- Traitement: voie 
84 s 
- purge des doublons : voie 
84 s 
- INDEXES 
84 s 
- ANALYSES 
84 s 
- FORMATAGE DONNEES : FIN 
84 s 
Purge des données brutes 
84 s 
EDIGEO
Type de base : spatialite, Connexion: 74215_Re_Import_date_2020-bis.sqlite, Schéma: 
* Décompression des fichiers 
* Recherche des fichiers .bz2 
0 fichier(s) .bz2 dans Y:/ETUDES/SIG_COLLECTIVITES/SIG_GESTION/PRAZ_SUR_ARLY/CADASTRE_2020/CADATRE_EDIGEO_74215_RGD 
0 fichier(s) .bz2 dans C:\Users\Benjamin\AppData\Local\Temp\cad_edigeo_plain_hnqrx3s6 
84 s 
Suppression des contraintes 
84 s 
- SUPPRESSION DES CONTRAINTES D'INTEGRITEES : DEBUT 
84 s 
- suppression clefs primaires 
84 s 
* Import des fichiers EDIGEO dans la base 
- Import des fichiers via ogr2ogr 
- Import des relations (*.vec) 
- 0 multipolygones mis à jours dans la base de données 
110 s 
Mise en forme des données 
110 s 
- FORMATAGE DONNEES : DEBUT 
110 s 
- Suppression des données du lot '_01' 
110 s 
- index pour optimisation 
110 s 
- geo_commune 
110 s 
- geo_section 
110 s 
- geo_subdsect 
110 s 
- geo_parcelle 
111 s 
- Indexes sur geo_parcelle et geo_commune pour optimisation 
111 s 
- geo_subdfisc 
111 s 
- geo_subdfisc_parcelle 
111 s 
- geo_voiep 
111 s 
- geo_numvoie 
111 s 
- geo_numvoie_parcelle 
111 s 
- geo_lieudit 
111 s 
- geo_batiment 
111 s 
- geo_batiment_parcelle 
111 s 
- geo_zoncommuni 
111 s 
- geo_tronfluv 
111 s 
- geo_tronroute 
111 s 
- geo_sym 
111 s 
- geo_ptcanv 
111 s 
- geo_borne 
112 s 
- geo_borne_parcelle 
112 s 
- geo_croix 
112 s 
- geo_croix_parcelle 
112 s 
- geo_symblim 
112 s 
- geo_symblim_parcelle 
112 s 
- geo_tpoint 
112 s 
- geo_tpoint_commune 
112 s 
- geo_tline 
112 s 
- geo_tline_commune 
112 s 
- geo_tsurf 
112 s 
- geo_tsurf_commune 
112 s 
- suppression des index temporaires 
112 s 
- analyses 
112 s 
- FORMATAGE DONNEES : FIN 
112 s 
Placement des étiquettes 
113 s 
Création des indexes spatiaux 
113 s 
- attributes 
114 s 
Ajout des contraintes 
114 s 
- CREATION DES CONTRAINTES D'INTEGRITEES : DEBUT 
114 s 
- création clé primaire 
114 s 
Ajout de la table parcelle_info 
114 s 
114 s 
FINALISATION
115 s_ 

Recopier ci-dessous l'erreur Python de QGIS

Sans objet (pas d'alerte)

Environnement

• OS: Windows 10 - 64 bits - 8Go de Ram
• Version de QGIS : 3.4
• Version du plugin : 1.10.2

(bug constaté dans QGIS 3.16 + plugin cadastre 1.10.2 , puis reproduit sur qgis 3.4 LTR avant communication sur GitHub)

[NikAub4]

Bonjour,
Je rebondis également sur ce post, dans le cadre de l'utilisation de l'extension Cadastre sur QGIS (actuelle, la version 1.10.2 du plugin avec la version 3.16.1-Hannover de QGIS).

J'utilise ce plugin pour générer des fichiers .sqlite par commune ou par territoire, à partir des données PCI vecteur et Majic III.

En réalisant cette fusion, je constate que certaines parcelles, pourtant existantes dans le PCI vecteur, disparaissent dans le fichier .sqlite. A titre d’exemple, sur Draguignan (code INSEE : 83050), les parcelles BK0356, AN0158, G0519 ou AM0066 (et d’autres, sur Draguignan ou d'autres communes) sont bien présentes sur le PCI vecteur, mais disparaissent lorsque je crée une fusion .sqlite avec l’outil Cadastre.

Après quelques recherches et échanges avec le CRIGE PACA, j'ai trouvé l'origine du problème.

Dans les fichiers EDIGEO du PCI Vecteur (ex : edigeo-83050000AH01.tar.bz2 pour Draguignan : 83050), si on prend la donnée des Parcelles et que, via QGIS, on fait vérification de la validité (Vecteur > Outils de géométrie > Vérifier la validité), il y plusieurs parcelles qui ressortent comme invalides, avec différents types d’invalidités :
- Enveloppes imbriquées : pour ces parcelles, pas de problème, elles se retrouvent bien dans la couche sqlite extraite avec l’outil cadastre obtenue par fusion du PCI vecteur et des fichiers Magic III
- Trou à l’extérieur de l’enveloppe : ce sont ces parcelles là qui sont supprimées lors de la création du fichier sqlite avec l'outil Cadastre

Que l’on coche ou non la case « Corriger les géométries invalides » dans l’extension Cadastre ne change rien, les parcelles sont supprimées. Il semble donc que la correction des géométries invalides omette la correction de l'erreur "trou à l'extérieur de l'enveloppe", ce qui génère alors un manque sur les fichiers sqlite obtenus.

Une information a été remontée à la DGFIP pour tenter de corriger ces erreurs sur le PCI Vecteur, mais une optimisation du plugin Cadastre pour la correction du type d'erreur susmentionné pourrait être bénéfique aux usagers.

[DJeremyy]

Bonjour,
Je rencontre également le problème d'affichage lors de la visualisation des informations d'une parcelle. Les fenêtres Résumé, Propriétaires, Subdivisions et Locaux sont vide.

À savoir que j'ai réalisé l'import du cadastre 2020 Edigéo et Majic III avec le plugin 1.10.2 sur QGis 3.16.4 pour un peu plus de 70 communes sur le département 88 et 3 communes sur le département 54.

Guidé par le message de @FrancoisB74 j'ai cherché à vérifier les cohérences des clés étrangères dans les tables local10, local00, parcelle et prev. Celles-ci semblent correcte, je n'ai pas de préfix avec le millésime de l'année 2020 mais j'ai un préfix avec le département 88 ou 54. Néanmoins cela semble cohérent pour réaliser les liaisons, le préfix est présent dans la clé primaire de la table local00 comme dans la clé étrangère local00 de la table local10.

[DJeremyy]

J'ajoute que dans les logs PostGIS, j'ai un warning lors de l'interrogation des informations d'une parcelle.

Le message d'erreur de la base de données est :
             ERROR: syntax error at or near "="
             LIGNE 1 : ...ber() OVER () AS __rid__, * FROM (SET search_path = "cadastr...

^
             .
             SQL : SELECT * FROM (SELECT row_number() OVER () AS __rid__, * FROM (SET search_path = "cadastre", public, pg_catalog;WITH infos AS (
              SELECT
              p.parcelle,
              -- identification
              l.dnubat AS l_batiment, l.descr AS l_numero_entree,
              l.dniv AS l_niveau_etage, l.dpor AS l_numero_local,
              l.invar AS l_invariant,
              (l.dnubat || l.descr || l.dniv || l.dpor) AS l_identifiant,