search

3liz / QgisCadastrePlugin

A QGIS plugin which helps users to import the french land registry ('cadastre') data into a database. It is meant to ease the use of the data in QGIS by providing search tools and appropriate layer symbology.
GNU General Public License v2.0
60 stars 41 forks source link

Pas de chargement des parcelles dans QGIS problème création table parcelle_info #189

Closed benjaminsaut closed 3 years ago

benjaminsaut commented 5 years ago

Description du bug

je n'arrive pas à charger correctement les parcelles d'une base spatialite, tout apparaît (bâti, étiquettes, ...) sauf les parcelles. Lors de l'import pas de bug particulier, c'est en chargeant les données que la couche n’apparaît pas. Sur QGIS 2.18 et avec module cadastre antérieur je n'avais pas de soucis pour importer sur base spatialite puis charger. je précise que j'ai créé une nouvelle base.

Merci d'avance pour votre aide

Reproduire le bug

la donnée EDIGEO (PCI-Vecteur) est importée dans une base spatialite. quand cette base spatialite est chargé, tout apparait mais la couche parcelle est vide (table attributaire vide). Tests fait sur des communes différentes.

Log

log issue de l'interface de chargement des données (pas l'import des données dans base spatialite), fait pour une commune (Oise)

0 s 
Chargement des tables : 
Filtrage à partir des communes, expression invalide : syntax error, unexpected $end 
* Communes 
* Tronçons de route 
* Voies, routes et chemins 
* Noms de voies 
* Secteurs 
* Subdivisions fiscales 
* Subdivisions fiscales (étiquette) 
* Bâti 
* Parcelles (étiquettes) 
* Lieux-dits 
* Lieux-dits (étiquettes) 
* Sections 
* Parcelles 
* Sections (étiquettes) 
* Bornes 
* Croix 
* Repères géodésiques 
* Murs, fossés, clotûres 
* Cours d'eau 
* Cours d'eau (étiquettes) 
* Tronçons de route (étiquettes) 
* Surfaces 
* Surfaces (étiquettes) 
* Objets ponctuels 
* Objets ponctuels (étiquettes) 
* Objets linéaires 
* Objets linéaires (étiquettes) 
* Numéros de voie 
* Établissements publics 
0 s 
Ajout des couches dans le registre de QGIS 
0 s 
Ajout des couches dans le groupe Cadastre 
0 s 
Zoom sur les couches 
0 s 
Mise à jour des outils cadastre 
0 s

Recopier ci-dessous l'erreur Python de QGIS

ce qui semble suspect est au début du log : "Filtrage à partir des communes, expression invalide : syntax error, unexpected $end"

Environnement

PGP-94 commented 5 years ago

Bonjour, Je rencontre le même problème, la couche parcelle est vide (QGIS 3.2.3).

A l'import : la donnée EDIGEO (PCI-Vecteur) est importée dans une base spatialite. quand cette base spatialite est chargé, tout apparaît mais la couche parcelle est vide (table attributaire vide). Tests fait sur des communes différentes.

LOG INITIALISATION

arno974 commented 5 years ago

Hello,

Problème confirmé et rencontré également de mon côté. Import OK. Dans le module recherche affichage de la commune et de la section mais pas des parcelles. ( WARNING cadastre debug - error while fetching data from database). Tests réalisés sur Windows et Ubuntu avec base SQLite & PostGIS. Après vérification, dans la base les tables lots et parcelles sont vides.

MaelREBOUX commented 5 years ago

Bonjour,

Je viens de tester un import de données EDIGEO + MAJIC 2018 sur une commune vers une base spatialite sans problème.

infos :

A vous relire j'ai l'impression que vous voulez insérer des données dans une base existante. Est-ce le cas ? Si oui il vous faut rajouter l'attribut inspireid

ALTER TABLE parcelle ADD COLUMN inspireid text ;
ALTER TABLE geo_parcelle ADD COLUMN inspireid text ;

Vous avez une idée de la version du plugin avec laquelle vous avez créé vos bases de données ?

Ettezaz commented 5 years ago

Bonjour,

J'ai moi aussi cette erreur, tout y est sauf les parcelles. Chargement des tables : Filtrage à partir des communes, expression invalide : syntax error, unexpected $end

Environnement OS: Windows 7 x64 Version de QGIS : 3.8.0-Zanzibar Version du plugin : 1.7.1

MaelREBOUX commented 5 years ago

Hmm : je ne suis pas @mdouchin ni expert dev python mais pour moi on ne devrait utiliser et supporter que des versions LTR. Donc des versions 3.4.x

@Ettezaz : ça vous embêterait de re-tester avec la dernière version 3.4 LTR (soit 3.4.11) à cette heure ?

@arno974 : vous pourriez me transmettre ou me dire où trouver vos fichiers EDIGEO ?

Ettezaz commented 5 years ago

J'ai testé avec QGis 3.4.11 LTR et plugin 1.7.1, le résultat est le même.

J'ai aussi testé avec QGis 3.8.0 et plugin 1.7.0 et là ça fonctionne, les parcelles sont bien présentes. Le log contient quand même cette phrase : Chargement des tables : Filtrage à partir des communes, expression invalide : syntax error, unexpected $end

arno974 commented 5 years ago

Hmm : je ne suis pas @mdouchin ni expert dev python mais pour moi on ne devrait utiliser et supporter que des versions LTR. Donc des versions 3.4.x

@Ettezaz : ça vous embêterait de re-tester avec la dernière version 3.4 LTR (soit 3.4.11) à cette heure ?

@arno974 : vous pourriez me transmettre ou me dire où trouver vos fichiers EDIGEO ?

Les données sont celles proposées en téléchargement par le Cadaste. J'utilise celle sur la réunion :

https://cadastre.data.gouv.fr/data/dgfip-pci-vecteur/2018-10-01/edigeo/departements/dep974.zip

MaelREBOUX commented 5 years ago

Les données sont celles proposées en téléchargement par le Cadaste. J'utilise celle sur la réunion :

ok. je testerai

et @Ettezaz : vos données c'est quelle commune ? les fichiers viennent d'où ?

Ettezaz commented 5 years ago

J'utilise moi aussi les données disponibles en téléchargement sur data.gouv.fr : https://cadastre.data.gouv.fr/data/dgfip-pci-vecteur/latest/ Je télécharge les EDIGEOà la feuille cadastrale, en L93 ou en CC en fonction de mon projet.

Le problème survient avec n'importe quelle feuille téléchargée, quelle que soit la commune.

benjaminsaut commented 4 years ago

Bonjour,

j'ai rententé avec MAJIC 2019 + PCI millésime juillet et toujours les problèmes suivants (version QGIS 3.4.7 et plugin 1.7.1) :

voici le log

0 s Chargement des tables : Filtrage à partir des communes, expression invalide : syntax error, unexpected $end

@Ettezaz du coup vous utilisez le plugin 1.7.0 pour importer ? Avec QGIS 3.8.0 ? il faut ces deux conditions ou alors c'est juste le plugin qu'il faut reprendre en 1.7.0 ? merci

Ettezaz commented 4 years ago

@benjaminsaut J'utilise le plugin 1.7.0 avec n'importe quelle version de QGis (même les plus récentes).

MaelREBOUX commented 4 years ago

Bonjour,

Je viens de traiter La Réunion avec ce fichier : https://cadastre.data.gouv.fr/data/dgfip-pci-vecteur/latest/edigeo-cc/departements/dep974.zip J'ai mis la projection EPSG:2975 (aucune idée si c'est ce qui convient).

QGIS 3.4 plugin version master (future 1.8.0) PostgreSQL 11 et PostGIS 2.5

Tout a très bien été mouliné. Par contre : si on charge le plan cadastral via le plugin : il y a plein de couches qui ne s'affichent pas. Il faut aller chercher les données en base pour les voir. ex : geo_parcelle et geo_tline.

capture_220

Je teste avec Spatialite maintenant.

MaelREBOUX commented 4 years ago

Donc re-test en spatialite ce coup-ci QGIS 3.4 plugin version master (future 1.8.0) mêmes données que ci-dessus.

Tout s'est très bien déroulé. Le plugin charge très bien les couches. Tout semble présent.

capture_222

benjaminsaut commented 4 years ago

@Ettezaz ok merci, il faudrait que je test avec ce plugin si je retrouve

@MaelREBOUX merci mais donc avec un plugin master futur 1.8.0 cela marche mais peut-être pas le 1.7.1 ? sinon je me demande si la version de PostgreSQL peut poser problème car il est dit dans la doc les prérequis suivants :

QGIS 3.4 LTR PostgreSQL : > 9.6 + PostGIS : > 1.5 Spatialite : 4.3.0

or j'ai dans la section à propos de QGIS version 3.4.7, SpatialIte 4.3.0 ok mais mention que la version client PostgreSQL est 9.2.4 (j'ai installé plus récent mais QGIS semble pas détecter)

Ettezaz commented 4 years ago

La mise à jour vers la version du plugin 1.8.0 a corrigé le problème de mon côté ! Les parcelles sont maintenant bien visibles.

mathieuTOUBLANC commented 4 years ago

Pour ma part j'ai réalisé pas mal de tests. Malgré la nouvelle version du plugin (1.8.0), j'observe quelques bugs selon les situations.

Tests réalisés sur les données EDIGEO 2019 / MAJIC 2019:

Bilan: dans tous les cas les problèmes surviennent lorsqu'on cherche à importer uniquement les données EDIGEO sans les données MAJIC.

OS: Windows 10 QGIS: 3.4 LTR PostgreSQL : 9.6 Spatialite : je ne sais pas (intégré dans QGIS 3.4) Plugin CADASTRE: 1.8.0

sigmoe commented 4 years ago

Bonjour à tous,

Etant formateur et développeur Python sur QGIS, j'ai analysé ce problème et trouvé comment le résoudre.

Le problème n'est aucunement lié à la version de QGIS utlisée (cela étant dit, on devrait toujours utiliser une version LTR de QGIS lorsqu'on travaille au quotidien avec QGIS, donc QGIS 3.4 LTR actuellement).

En fait c'est le script de création de la table parcelle_info (table utilisée pour la couche Parcelles dans QGIS) qui contient une petite erreur. Ce script est utilisé uniquement lorsqu’il n'y a pas de fichier MAJIC à intégrer, c'est pourquoi le problème n'apparaît que lorsqu'on importe uniquement les fichiers EDIGéO.

Vous trouverez ci-dessous le script edigeo_create_table_parcelle_info_simple.sql corrigé. edigeo_create_table_parcelle_info_simple.zip

Utilisez ce fichier dézippé pour remplacer l'original dans le répertoire C:\Users\[NOM_UTILISATEUR]\AppData\Roaming\QGIS\QGIS3\profiles\default\python\ plugins\cadastre\scripts\plugin

Cordialement.

mdouchin commented 4 years ago

Bonjour @sigmoe Pourriez-vous svp proposer un pull request pour qu'on puisse intégrer ce bug fix en vous créditant ?

mathieuTOUBLANC commented 4 years ago

Parfait merci à toi Sigmoe, ça marche parfaitement bien avec ta correction.

sigmoe commented 4 years ago

@MaelREBOUX Juste une petite remarque concernant les changements de titre et de tags: Il s'agit bien d'un problème d'import et non de chargement: lors de l'import, la table parcelle_info n'était pas correctement remplie. Lors du chargement, cette table est correctement chargée, mais comme elle est vide du fait d'un mauvais import, il n'y a pas de parcelles dans QGIS.

MaelREBOUX commented 4 years ago

PR mergée. A tester maintenant SVP.

@sigmoe : oui effectivement.

benjaminsaut commented 4 years ago

Bonjour,

merci @sigmoe pour la correction mais de mon côté je suis bien toujours et depuis le début sur un import MAJIC+EDIGEO et le problème malheureusement demeure, alors que pour @mathieuTOUBLANC cela fonctionnait apparemment et le problème était que sur le EDIGEO.

Je reocpie ici le log de chargement qui semble d'après vos posts le point bloquant , puis à la suite celui de création de la base (problème lié aux fichiers sources ?)

merci d'avance pour toute aide

plugin 1.8.0 QGIS 3.4.12 PostgreSQL 10.8 SpatiaLite Version 4.3.0 windows 10

log de chargement des données 0 s Chargement des tables : Filtrage à partir des communes, expression invalide : syntax error, unexpected $end

log création base

INITIALISATION

mathieuTOUBLANC commented 4 years ago

Finalement je me demande si ton correctif @sigmoe fonctionne vraiment si bien. Je n'avais , de mémoire, testé ton fichier SQL que sur une seule commune et cela fonctionnait très bien au départ. Malheureusement j'ai depuis tenté de réaliser des bases plus conséquentes sans succès: voici ci-dessous mes tests non concluants pour importer des communes en EDIGEO (sans les données MAJIC) dans une base Spatialite.

Je m'y reprends à plusieurs fois pour refaire certains lots que je divise éternellement, cela m'a permis d'écarter l'hypothèse d'un éventuel fichier EDIGEO erroné mais finalement, pris commune par commune ça fonctionne. J'ai l'impression que le nouveau fichier SQL proposé par @sigmoe ralenti considérablement l'import des données. A ce rythme il est illusoire de créer une base pour un département entier. Suis-je le seul dans ce cas?

J'ai aussi tenté de charger les données après les imports bogués pour voir: les parcelles (table "parcelle-info") ne s'affichent pas, par contre la table "geo-parcelle" est en partie complétée et on peut l'afficher mais malheureusement il manque des zones entières de parcelles.

Processeur I7 et 8 Go de ram OS: Windows 10 QGIS: 3.4 LTR PostgreSQL : 9.6 Spatialite : je ne sais pas (intégré dans QGIS 3.4) Plugin CADASTRE: 1.8.0

sigmoe commented 4 years ago

@mathieuTOUBLANC Mon correctif fonctionne concernant le bug qu'il corrige, à savoir faire en sorte que la création de la table parcelle_info soit renseignée correctement. Maintenant les problèmes que tu continues de rencontrer sont probablement du à un autre bug. Ce que tu décris à la fin semble plus faire penser à un problème lié à la table geo_parcelle qui n'est pas correctement créée.

mdouchin commented 4 years ago

La versino 1.8.1 vient de sortir. Merci de tester et voir si c'est OK. @sigmoe il faudrait créer une demande spécifique, car d'après le commentaire ci-dessus, le souci est aussi un problème de performance, ou autre.

benjaminsaut commented 4 years ago

@mdouchin merci j'ai testé mais malheursement le problème suivant demeure en utilisant Spatialite : la table parcelle ne se charge pas.

Message lors du chargement : "- Aucune table trouvée pour Parcelles "

par ailleurs toujours le message "Filtrage à partir des communes, expression invalide : syntax error, unexpected $end "

j'ai importé à l'échelle du département la donnée MAJIC et EDIGEO en même temps, et quand je vais dans le gestionnaire BD de QGIS je vois que j'ai une table parcelle renseignée mais il manque parcelle_info.

J'ai testé en créant une autre base avec une seule commune et cela fonctionne (la couche parcelle est là, et parcelle_info est dans la base). Donc je ne comprend pas si il y a une taille limite d'import ou un élément de mon fichier MAJIC global à l'échelle du département qui bloque.

benjaminsaut commented 4 years ago

@mdouchin bonjour, j'ai refait un test avec la version 1.8.1 toujours le même problème lors du chargement "* Parcelles

dans la base spatialite il y a bien une table "parcelle" avec des lignes renseignées mais pas la table "parcelle_info". L'import a duré près de 12h00 (département de l'Oise).

PGP-94 commented 4 years ago

Bonjour, Je constate aussi toujours le même problème.

Le mar. 19 nov. 2019 à 12:24, benjaminsaut notifications@github.com a écrit :

@mdouchin https://github.com/mdouchin bonjour, j'ai refait un test avec la version 1.8.1 toujours le même problème lors du chargement "* Parcelles

  • Aucune table trouvée pour Parcelles

dans la base spatialite il y a bien une table "parcelle" avec des lignes renseignées mais pas la table "parcelle_info". L'import a duré près de 12h00 (département de l'Oise).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/3liz/QgisCadastrePlugin/issues/189?email_source=notifications&email_token=AMY73QPKHH5RWQ63GXIXDZDQUPEGRA5CNFSM4H3RJQ6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEN3LOQ#issuecomment-555464122, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMY73QIVYKKLHC3MFLAOJ63QUPEGRANCNFSM4H3RJQ6A .

-- Patricia Guinchard-Panseri

Responsable de Recherches Archéologiques - Inrap île-de-France

Centre archéologique de Croissy-Beaubourg Espace Multi-Services - Lot 34 56 boulevard de Courcerin 77183 Croissy-Beaubourg

Tel : 06 86 18 87 20 www.inrap.fr

benjaminsaut commented 4 years ago

@PGP-94 avez-vous pu résoudre le problème ? j'ai commencé à intégrer EPCI par EPCI mais il faut compter quasiment une journée par EPCI...

Fred-PF commented 4 years ago

Bonjour,

J'ai changé de PC et un import qui se déroulait bien la semaine dernière sur le premier conduit à ce problème sur le deuxième. (je n'ai pas accès au premier PC depuis mon confinement). Ce n'est pas un problème de données. Donc même soucis qui conduit à ne pas voir de parcelles dans le panneau Outils de recherche. Import EDIGEO seulement, sans les données MAJIC. La table parcelle_info existe et contient les données. Idem pour la table geo_parcelle. Le plan cadastral s'affiche correctement. Les tables parcelle et lots sont vides (anormal).

Exemple en important une feuille cadastrale EDIGEO 2154 chargée sur https://cadastre.data.gouv.fr/datasets/plan-cadastral-informatise

`INITIALISATION

Configurations : Processeur I7 et 8 Go de ram OS: Windows 10 Version de QGIS 3.4.5-Madeira et Version du client PostgreSQL 9.2.4 Extension cadastre 1.8.1 PgAdmin4 V2.1 fonctionne avec PostgreSQL 10 et Postgis 2.5.1

Cordialement Frédéric

evinouze commented 4 years ago

Bonjour,

Je cherche à importer le cadastre (EDIGEO seulement) et je rencontre le même type de pb évoqué par @mathieuTOUBLANC L'import plante généralement à la fin de script d'import et me renvoie l'erreur suivante :

--ERREUR:  la transaction est annulée, les commandes sont ignorées jusqu'à la fin du bloc de la TRANSACTION
SET search_path = "dgi_cadastre", public, pg_catalog;DROP TABLE IF EXISTS "batiment_id";DROP TABLE IF EXISTS "borne_id";DROP TABLE IF EXISTS "boulon_id";DROP TABLE IF EXISTS "commune_id";DROP TABLE IF EXISTS "croix_id";DROP TABLE IF EXISTS "id_s_obj_z_1_2_2";DROP TABLE IF EXISTS "lieudit_id";DROP TABLE IF EXISTS "numvoie_id";DROP TABLE IF EXISTS "parcelle_id";DROP TABLE IF EXISTS "ptcanv_id";DROP TABLE IF EXISTS "section_id";DROP TABLE IF EXISTS "subdfisc_id";DROP TABLE IF EXISTS "subdsect_id";DROP TABLE IF EXISTS "symblim_id";DROP TABLE IF EXISTS "tline_id";DROP TABLE IF EXISTS "tpoint_id";DROP TABLE IF EXISTS "tronfluv_id";DROP TABLE IF EXISTS "tronroute_id";DROP TABLE IF EXISTS "tsurf_id";DROP TABLE IF EXISTS "voiep_id";DROP TABLE IF EXISTS "zoncommuni_id";

Tous les éléments semblent être importés, sauf la couche parcellaire qui n'apparait pas au chargement (la table _parcelleinfo exploitée par le plugin est vide, mais la table _geoparcelle est néanmoins remplie)

Cela fonctionne toutefois dans le cas où je n'importe qu'une seule commune. Sachant que je souhaite importer un département entier (> 500 communes), cela me semble pour l'instant compromis dans ces conditions.

La config utilisée :

Côté client :

Côté serveur :

Je me pose également la question déjà posée par @benjaminsaut dans un post plus haut Est-ce un problème de version de PostgreSQL ?

Merci d'avance pour vos éventuelles suggestions.

Eric.

evinouze commented 4 years ago

Re-bonjour,

Je pense avoir trouvé un début de réponse à ce bug.

En considérant que mon problème se limitait au remplissage de la table _parcelleinfo à partir de la table _geoparcelle, j'ai exécuté à part la requête INSERT du script edigeo_create_table_parcelle_info_simple.sql repris par @sigmoe 

SELECT gp.ogc_fid AS ogc_fid, geo_parcelle, gp.idu AS idu, gp.tex AS tex, gp.geo_section AS geo_section,
c.tex2 AS nomcommune, c.idu AS codecommune, Cast(ST_Area(gp.geom) AS integer) AS surface_geo,
gp.lot AS lot,
gp.geom AS geom
FROM dgi_cadastre.geo_parcelle gp
INNER JOIN dgi_cadastre.geo_commune c
ON c.geo_commune = SUBSTRING(gp.geo_parcelle,1,6)

En exécutant la requête, j'ai obtenu une erreur plus explicite que l'erreur remontée par le plugin :

SQL Error [23505]: ERREUR: la valeur d'une clé dupliquée rompt la contrainte unique « parcelle_info_pk »
  Détail : La clé « (ogc_fid)=(1) » existe déjà.

Pourtant, pas de doublon de parcelle pour l'ogc_fid en question. Tiens, tiens... Mais par contre, j'ai effectivement un doublon de commune d'appartenance dans la table _geocommune. Le doublon vient donc de là puis se reporte dans l'exécution de la requête SQL du dessus (chaque parcelle d'une commune en doublon est alors doublonnée par l'effet de la jointure)

Cela expliquerait sans doute aussi le caractère aléatoire du souci d'import (ça ne serait pas une question de nombre de communes importées, mais de savoir si le lot importé contient au moins une commune en doublon).

Du coup, j'en reviens à la suggestion de @MaelREBOUX dans l'issue https://github.com/3liz/QgisCadastrePlugin/issues/196, à savoir que ça serait bien que l'outil puisse gérer ce pb de doublon (à défaut de la DGFiP), sachant que le process d'import traite aussi bien les parcelles que les communes (à l'origine de bug).

Qu'en dites-vous ?

evinouze commented 4 years ago

Re-re-bonjour,

Pour info, le début de piste que j'ai énoncé hier semble être concluant. Du coup, pour contourner le problème, je procède de la manière suivante :

Pour faciliter le repérage des doublons, une requête SQL fait toujours l'affaire :

SELECT geo_commune, count(*)
FROM [monschema].geo_commune
GROUP BY geo_commune
HAVING count(*) > 1

Tip : le doublon à supprimer est celui dont le champ _updatedat comporte la date la plus ancienne

MaelREBOUX commented 3 years ago

On vous invite à re-tester avec la version 1.9.0 qui va sortir.

MaelREBOUX commented 3 years ago

@Zz95 : je me permet de supprimer votre post qui correspond à l'issue #277

MaelREBOUX commented 3 years ago

Bonjour @evinouze est-ce que la dernière version 1.10.2 corrige votre problème ?

evinouze commented 3 years ago

@MaelREBOUX pas encore eu le temps de vérifier, mais bientôt prévu de mettre à jour le cadastre complet du département (38). Je peux faire un retour pour info

evinouze commented 3 years ago

@MaelREBOUX j'ai fait un test avec la version 1.10.2 du plugin qui me renvoie l'erreur suivante :

ERREUR: la relation « edigeo_rel » n'existe pas LINE 1: ... = "dgi_cadastre", public, pg_catalog;INSERT INTO edigeo_rel...

image

J'utilise la version 3.10.13 de QGIS et le comportement renvoyé est le même sur une commune ou un lot de communes

Faut-il créer un ticket spécifique à ce problème ?

evinouze commented 3 years ago

@MaelREBOUX j'ai fait un test avec la version 1.10.2 du plugin qui me renvoie l'erreur suivante :

ERREUR: la relation « edigeo_rel » n'existe pas LINE 1: ... = "dgi_cadastre", public, pg_catalog;INSERT INTO edigeo_rel...

image

J'utilise la version 3.10.13 de QGIS et le comportement renvoyé est le même sur une commune ou un lot de communes

Faut-il créer un ticket spécifique à ce problème ?

Je pense ne pas avoir été assez vigilant. J'ai essayé d'importer les données dans un schéma créé pour l'import de l'année dernière. En supprimant ce schéma, j'ai pu importer le cadastre sur l'ensemble du département (en 3 lots) sans encombre :-)

MaelREBOUX commented 3 years ago

ok. alors je ferme ce ticket. merci pour le retour.