NikAub4
commented
3 years ago 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
Description du bug
Après import Edigeo + Majic III, avec paramètres {année = 2020 ; département = 74}, nous avons constaté :
Dans les parties restant fonctionnelles, on a simplement :
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 :
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)
Log
Ci-dessous le log du plugin Cadastre (pas/peu informatif, sauf pour savoir où sont situés les scripts SQL utilisés) :
Recopier ci-dessous l'erreur Python de QGIS
Environnement
(bug constaté dans QGIS 3.16 + plugin cadastre 1.10.2 , puis reproduit sur qgis 3.4 LTR avant communication sur GitHub)