blocage à l'import des données

[gege41]

Description du bug

blocage de l'import des données à 94% Il s'agit de données DGFIP 2020 et de données EDIGEO du 01/01/2020 En revanche j'ai réussi avec succès l'import sous QGIS 2.16 + version du plugin

Reproduire le bug

Etapes pour reproduire le bug (remplacer)

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

Log

Où trouve-t-on le log ?

bugue_plugin_cadastre.pdf

Environnement

• OS: Windows / Linux ? Windows
• Version de QGIS : ? 3.10.6
• Version du plugin : ? 1.9

[pedrogeo]

Bonjour,

Je rencontre le même problème que gege41. J'ai essayé de faire l'import de 54 communes (Majic 2020 + Edigeo 07/2020) avec Qgis 3.10.11 puis avec Qgis 3.4.15, dans les deux cas plugin cadastre 1.9 sous Windows 10. L'import est paramétré dans une base Spatialite créée par le plugin cadastre lors du paramétrage de l'import.

Dans les deux cas, il y a un blocage dans la mise en forme des données juste après "geo_borne_parcelle" à 94 %. Aucun message d'erreur n'apparaît dans le bas de la fenêtre d'import.

Pierre

[Gustry]

J'ai aussi le soucis sur une base spatialite à 94%. Aucun par contre avec une base Postgis.

En fait, ce n'est pas un blocage, mais c'est juste extrêmement long ...

[pedrogeo]

Quand tu indiques que c'est extrêmement long, ça veut dire que tu as quand même réussi, au final, à faire l'import dans une base Spatialite ? Je souhaitais mettre à disposition le cadastre sur un poste n'ayant pas de base Postgis en local ou en réseau, c'est pour ça que je souhaitais faire l'import en Spatialite.

[Gustry]

Quand tu indiques que c'est extrêmement long, ça veut dire que tu as quand même réussi, au final, à faire l'import dans une base Spatialite ?

Oui, mais très long comme je disais. Faire un test sur une commune par ex.

[mdouchin]

il faut qu'on trouve la requête problématique dans sqlite et proposer un fix. Par contre, le fix doit être dépendant de sqlite, sinon on va refaire comment avant: améliorer les perfs d'un côté (spatialite) et remettre de la lenteur de l'autre (dans PostgreSQL)

[pedrogeo]

Alors j'ai laissé tourné l'import et il s'est finalement terminé.

Mais entre "geo_borne_parcelle" et "geo_croix", il s'est passé 149 min. La fin du traitement s'est faite rapidement après.

[mdouchin]

En cours de correction

[mdouchin]

Commit poussé pour correction 6d39fb7 A tester sur différents jeux de données.

[Gustry]

Je viens juste d'essayer sur un jeu de données. Ca vient de marcher du feu de Dieu ⚡

[gege41]

Bonjour, j'aimerais bien savoir comment tu as fait Gustry. J'ai essayé de remplacer les 3 fichiers cadastre_import.py, edigeo_formatage_donnees.sql, majic3_drop_indexes.sql dans le plugin mais j'ai obtenu une erreur ! Merci

[Gustry]

Il ne faut pas chercher à appliquer le diff, c'est vraiment une source d'erreur.

• Soit télécharger le zip de github, mettre le sous dossier cadastre au bon endroit dans le répertoire des extensions QGIS
• ou attendre que l'on fasse la nouvelle version

[pedrogeo]

Bonjour,

J'ai relancé l'import avec la nouvelle version et je vous confirme que l'import est beaucoup beaucoup plus rapide. Avec le même jeu de données, l'import avait mis 2h54 avec la version 1.9 du plugin et 27 min avec la version 1.10.

Merci de votre réactivité / efficacité 👍

[gege41]

J'y suis arrivé, MERCI

[Gustry]

@gege41 Entre temps, il y a une version de cadastre qui est disponible sur plugins.qgis.org https://github.com/3liz/QgisCadastrePlugin/releases/tag/1.10.0

je clos, je pense que c'est bon

[MaelREBOUX]

@Gustry je note les commentaires à 4 tirets

Par contre j'ai pas tout compris la correction : tu as juste viré les indexes sur la table geo_borne ?

[Gustry]

Ce n'est pas moi mais @mdouchin qui a fait le travail sur ce ticket ;-)