UnicodeDecodeError: 'utf-8'

cpornin commented 5 years ago

Bonjour,

Voici le problème que j'ai rencontré à l'utilisation du plugin :

Description du bug

Lors du lancement de l'import des données en base spatialite dans le plugin Cadastre, un message d'erreur python apparaît concernant l'encodage. Y aurait-il un moyen de le résoudre simplement en changeant l'encodage ? si oui, dans quels fichiers et comment savoir par quel encodage ?

Reproduire le bug

Étapes pour reproduire le bug

Configuration du plugin
Lancement de l'import en base spatialite
Blocage de l'import à 35% et apparition du message d'erreur

Même problème rencontré en changeant de version Qgis et en réinstallant l'extension. Idem avec une base existante ou une nouvelle base spatialite. Idem avec la création d'un schéma sous Postgres/postgis.

Log

Une erreur est survenue lors de l'éxécution du code Python: 

UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe0 in position 369: invalid continuation byte 
Traceback (most recent call last):
  File "C:/Users/cpornin/AppData/Roaming/QGIS/QGIS3\profiles\default/python/plugins\cadastre\cadastre_dialogs.py", line 727, in processImport
    qi.importMajic()
  File "C:/Users/cpornin/AppData/Roaming/QGIS/QGIS3\profiles\default/python/plugins\cadastre\cadastre_import.py", line 444, in importMajic
    item['method']()
  File "C:/Users/cpornin/AppData/Roaming/QGIS/QGIS3\profiles\default/python/plugins\cadastre\cadastre_import.py", line 581, in importMajicIntoDatabase
    for a in self.chunk(fin, self.maxInsertRows):
  File "C:\OSGEO4~1\apps\Python37\lib\codecs.py", line 322, in decode
    (result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe0 in position 369: invalid continuation byte

Environnement Windows 7 Version de Python : 3.7.0 (v3.7.0:1bf9cc5093, Jun 27 2018, 04:59:51) [MSC v.1914 64 bit (AMD64)] Version de QGIS : 3.8.1-Zanzibar Zanzibar, dcd95cc648 Version du plugin : Version 1.7.1

Testé et reproduit en version QGIS LTR 3.4.1

Merci d'avance pour le temps que vous pourrez consacrer à ce problème.

MaelREBOUX commented 5 years ago

C'est ici que ça semble se produire : https://github.com/3liz/QgisCadastrePlugin/blob/master/cadastre_import.py#L597-L602

Est-ce qu'il y aurait un caractère non UTF-8 dans un des fichiers MAJIC ?

BastienPA commented 5 years ago

Bonjour,

J'ai exactement la même erreur qu'évoquée ci-dessus en tentant d'importer les fichiers MAJIC 2019 avec Qgis 3.4. Ce qui est étonnant, c'est que l'importation avec le 2.19 fonctionne bien.

Voici le message d'erreur :

UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe0 in position 1948: invalid continuation byte
Traceback (most recent call last):
  File "C:/Users/pajot.bastien/AppData/Roaming/QGIS/QGIS3\profiles\default/python/plugins\cadastre\cadastre_dialogs.py", line 727, in processImport
    qi.importMajic()
  File "C:/Users/pajot.bastien/AppData/Roaming/QGIS/QGIS3\profiles\default/python/plugins\cadastre\cadastre_import.py", line 444, in importMajic
    item['method']()
  File "C:/Users/pajot.bastien/AppData/Roaming/QGIS/QGIS3\profiles\default/python/plugins\cadastre\cadastre_import.py", line 581, in importMajicIntoDatabase
    for a in self.chunk(fin, self.maxInsertRows):
  File "C:\PROGRA~1\QGIS3~1.4\apps\Python37\lib\codecs.py", line 322, in decode
    (result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe0 in position 1948: invalid continuation byte

Ma configuration :

Version de Python : 3.7.0 Version de QGIS : 3.4.8-Madeira Madeira, Version du PLugin: Version 1.7.1

sebGIS commented 5 years ago

Bonjour,

J'ai la même chose. J'ai chargé 6 départements sans pb et au 7ème bug suivant : Une erreur est survenue lors de l'éxécution du code Python:

UnicodeDecodeError: 'utf-8' codec can't decode byte 0xf7 in position 1199: invalid start byte 
Traceback (most recent call last):
  File "C:/Users/s.maison/AppData/Roaming/QGIS/QGIS3\profiles\default/python/plugins\cadastre\cadastre_dialogs.py", line 727, in processImport
    qi.importMajic()
  File "C:/Users/s.maison/AppData/Roaming/QGIS/QGIS3\profiles\default/python/plugins\cadastre\cadastre_import.py", line 444, in importMajic
    item['method']()
  File "C:/Users/s.maison/AppData/Roaming/QGIS/QGIS3\profiles\default/python/plugins\cadastre\cadastre_import.py", line 581, in importMajicIntoDatabase
    for a in self.chunk(fin, self.maxInsertRows):
  File "C:\PROGRA~1\QGIS3~1.4\apps\Python37\lib\codecs.py", line 322, in decode
    (result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xf7 in position 1199: invalid start byte

Version de Python : 3.7.0 (v3.7.0:1bf9cc5093, Jun 27 2018, 04:59:51) [MSC v.1914 64 bit (AMD64)] 
Version de QGIS : 3.4.11-Madeira Madeira, 9a8a6d4687 
Chemin Python :
•   C:/PROGRA~1/QGIS3~1.4/apps/qgis-ltr/./python
•   C:/Users/s.maison/AppData/Roaming/QGIS/QGIS3\profiles\default/python
•   C:/Users/s.maison/AppData/Roaming/QGIS/QGIS3\profiles\default/python/plugins
•   C:/PROGRA~1/QGIS3~1.4/apps/qgis-ltr/./python/plugins
•   C:\Program Files\QGIS 3.4\bin\python37.zip
•   C:\PROGRA~1\QGIS3~1.4\apps\Python37\DLLs
•   C:\PROGRA~1\QGIS3~1.4\apps\Python37\lib
•   C:\Program Files\QGIS 3.4\bin
•   C:\PROGRA~1\QGIS3~1.4\apps\Python37
•   C:\PROGRA~1\QGIS3~1.4\apps\Python37\lib\site-packages
•   C:\PROGRA~1\QGIS3~1.4\apps\Python37\lib\site-packages\win32
•   C:\PROGRA~1\QGIS3~1.4\apps\Python37\lib\site-packages\win32\lib
•   C:\PROGRA~1\QGIS3~1.4\apps\Python37\lib\site-packages\Pythonwin
•   C:/Users/xxxx/AppData/Roaming/QGIS/QGIS3\profiles\default/python
C:\Users\xxxx\AppData\Roaming\QGIS\QGIS3\profiles\default\python\plugins\cadastre\forms

A mon avis c'est dans le MAJIC qui bug mais pas encore trouvé Si vous avez des pistes je suis preneur.

sebGIS commented 5 years ago

Le truc c'est que cela passe en QGIS 2.18.21 et plug 1.5.6

mathieuTOUBLANC commented 5 years ago

Salut pour info j'ai eu le problème sur l'une des communes de Loire-Atlantique. Le problème ne vient pas du plugin CADASTRE mais d'un fichier MAJIC: en effet j'ai trouvé des caractères en hexadécimale au beau milieu d'un de mes fichiers Majic.

Repère dans le log, le fichier sur lequel le plugins s'est arrêté, celui-ci contient à coup sûr une caractère qui n'est pas en UTF-8. Il faut trouvé ce caractère en ouvrant ton fichier dans un éditeur de texte et l'effacer. Le caractère est évident à voir il est sous forme hexadécimal (dans mon cas il s'affichait de manière assez visible sous Notepad : un espèce de "xBD" sur fond noir. le bloc-note de Windows interprète quant à lui ce caractère sous la forme d' un "Û". tente une recherche avec ce fameux caractère avec un peu de chance ce sera le même que dans mon cas sinon t'es bon pour te taper quelques milliers de lignes à décortiquer.

Pour ma part j'ai enlevé ce caractère et ça roule.

Bon courage

mdouchin commented 5 years ago

Le souci vient en effet des fichiers MAJIC, mais le plugin doit pouvoir les gérer. Est-ce que toutes les personnes concernées par ce bug peuvent tester de modifier la ligne 579 du fichier cadastre_import.py

et remplacer

                with open(fpath) as fin:

par

                with open(fpath, 'rb') as fin:

Puis redémarrer QGIS, et retenter l'import.

mathieuTOUBLANC commented 5 years ago

J'ai testé ta modification, je n'ai pas d'erreur lors de la création de la base Postgres. Par contre lorsqu'on charge les données pour visualiser le cadastre, les géométries sont ok par mais il n'y a aucune donnée sur les propriétaires: voici le journal d'erreur ci-dessous.

> 2019-09-26T16:49:03     WARNING    Récupération du HTTP . échouée avec l'erreur Protocol "" is unknown
> 2019-09-26T16:49:04     WARNING    La clé primaire est ctid - le changement des entités existantes est désactivé (geom; "test"."geo_label")
> 2019-09-26T16:49:05     WARNING    La clé primaire est ctid - le changement des entités existantes est désactivé (geom; "test"."geo_label")
> 2019-09-26T16:49:05     WARNING    La clé primaire est ctid - le changement des entités existantes est désactivé (geom; "test"."geo_label")
> 2019-09-26T16:49:06     WARNING    La clé primaire est ctid - le changement des entités existantes est désactivé (geom; "test"."geo_label")
> 2019-09-26T16:49:07     WARNING    Récupération du HTTP ../../../../.. échouée avec l'erreur Protocol "" is unknown
> 2019-09-26T16:49:07     WARNING    La clé primaire est ctid - le changement des entités existantes est désactivé (geom; "test"."geo_label")
> 2019-09-26T16:49:09     WARNING    La clé primaire est ctid - le changement des entités existantes est désactivé (geom; "test"."geo_label")
> 2019-09-26T16:49:09     WARNING    La clé primaire est ctid - le changement des entités existantes est désactivé (geom; "test"."geo_label")
> 2019-09-26T16:49:10     WARNING    La clé primaire est ctid - le changement des entités existantes est désactivé (geom; "test"."geo_label")
> 2019-09-26T16:49:11     WARNING    La clé primaire est ctid - le changement des entités existantes est désactivé (geom; "test"."geo_label")
> 2019-09-26T16:49:11     WARNING    La clé primaire est ctid - le changement des entités existantes est désactivé (geom; "test"."geo_label")
> 2019-09-26T16:49:12     WARNING    La clé primaire est ctid - le changement des entités existantes est désactivé (geom; "test"."geo_label")
> 2019-09-26T16:49:12     WARNING    La clé primaire est ctid - le changement des entités existantes est désactivé (geom; "test"."geo_label")
>

Je te fournis un extrait très minimaliste du fichier MAJIC (il reste 5 lignes sur les 19000 d'origine) avec les fameux caractères qui posent problème pour que tu te rendes compte également des décalages que cela génère (J'ai trafiqué quelques chiffres sans incidence sur la forme du fichier pour m'éviter un coup de marteau de la CNIL)--> je pense que le soucis vient des décalages et ça me parait difficile de résoudre ça via le plugin: à mon avis il faut mettre les mains dans les fichiers MAJIC et les corriger à la main. Ce n'est pas très sorcier et je pense c'est un cas quasi exceptionnel: sur 200 communes téléchargées je n'ai eu qu'un seul fichier erroné. Je pense même que c'est mieux de laisser le plugin en l'état car l'erreur python permet de savoir quel fichier pose problème. ART.DC21.W19440.PDLL.A2019.N000933.txt

sebGIS commented 5 years ago

Désolé pas encore testé je test ce soir

sebGIS commented 5 years ago

oupss la log tu l'as trouve où

sebGIS commented 5 years ago

J'ai fais le test et même résultat que mathieuTOUBLANC

mathieuTOUBLANC commented 5 years ago

@sebGIS --> Le log est là (voir la capture ci-dessous) la procédure d'import s'arrêtera sur le fichier ayant un caractère non-reconnu, soit le dernier qui s'affiche dans le journal (log). Dans mon cas, comme tu peux le voir sur la capture, le plugin s'est arrêté sur le chargement du fichier "ART.DC21.W19440.PDLL.A2019.N000933.txt" qui est un des fichiers MAJIC de la commune de Pornichet. Reste à trouver à l'intérieur de ce fichier le caractère qui pose problème comme je l'ai expliqué précedemment.

erreur_python

sebGIS commented 5 years ago

ok merci moi c'est un majic d'un département pas encore trouvé ce Pù^* de caractère ahhhhhh

mathieuTOUBLANC commented 5 years ago

Tente une recherche du caractère "Û" avec le bloc-note de Windows, avec un peu de chance ça matchera (repère l'endroit dans le fichier). Après c'est plus lisible de modifier avec un autre éditeur de texte comme Notepad ou PSPad. T'as combien de lignes dans ton fichier?

sebGIS commented 5 years ago

768891 lignes tu as chercher via le blocnote? moi j'utilise Notepad+++ mais je perd mes yeux

mathieuTOUBLANC commented 5 years ago

Presque un million de lignes ce n'est pas envisageable de le faire manuellement, moi j'avais seulement 19000 lignes. Tente la recherche avec le caractère que je t'ai indiqué sous le bloc-note, as tu essayé au moins? (difficile de faire une recherche sous Notepad car tu ne peux pas taper le caractère au clavier, il s'affichait en hexadécimal dans mon cas)

sebGIS commented 5 years ago

bah oui mais avec le bloc note cela plante trop de ligne pas moyen d'utiliser l'outil recherche

mathieuTOUBLANC commented 5 years ago

Il doit bien y avoir une solution: par exemple je penserais aussi à découper mon fichier en 10 pour avoir 10 fichiers de 80000 lignes. Là ça doit passer facilement ou alors ton ordinateur manque terriblement de puissance. Chez moi la recherche aboutie instantanément (Processeur I7 et 8Go de mémoire vive). Dans la recherche copie/colle ça: Û

Ou alors donne moi ton mail qu'on échange en privé pour éviter de pourrir la discussion ici. Tu pourras me fournir ton fichier MAJIC pour que je regarde si tu me fais confiance: évidemment dans ma structure nous avons l'autorisation de la CNIL pour accéder au fichiers MAJIC.

sebGIS commented 5 years ago

non c'est fait mais c'est Û avec plaisir voici mon mail sebastien.maison@grandparisamenagement.fr

MaelREBOUX commented 5 years ago

j'ai trouvé des caractères en hexadécimale au beau milieu d'un de mes fichiers Majic.

ça confirme que le pb vient des données. Pb à remonter à votre centre des impôts pour correction car c'est pas normal ça !

J'ai tendance à croire que ça va pas être possible de gérer ça dans le code d'import. N'est-ce pas @mdouchin ?

sebGIS commented 5 years ago

Oui j'ai trouvé aussi mon caractère de merde. Pour avoir pratiqué le DGFIP les faire modifier quelque chose même une coquille c'est (enfin dans mon cas) euhh non mais on sait jamais

BastienPA commented 5 years ago

De mon côté, j'ai aussi testé le "Û"sur le fichier propriétaire (celui qui pose problème) dans le bloc note mais ça ne renvoi aucun caractère. Il faut que je poursuive les recherches...

mathieuTOUBLANC commented 5 years ago

Oui nous avons échangé en privé avec @sebGIS pour son cas, il a fini par trouvé lui-même son fameux caractère hexadécimal qui pose problème et malheureusement ce n'était pas le même que le mien.

Voilà pour info à quoi cela ressemblait dans mon fichier sous NotePad ("Û" sous le bloc note):

pour seb

et voici pour @sebGIS à la ligne 109801 (faut être courageux, bravo à lui)!

pour_le (2)

mdouchin commented 5 years ago

Merci à tous pour vos tests, solutions, etc. Et bienvenue dans la joie des fichiers MAJIC (avec parfois des caractères hiéroglyphes, ou des dates 'NSP' ou 'INCONNU' au lieu de 20191001).

J'avais déjà intégré du code pour nettoyer les données non ASCII ici

expression régulière qui permet de trouver tous les caractères à supprimer: https://github.com/3liz/QgisCadastrePlugin/blob/master/cadastre_import.py#L475
suppression dans la création de la ligne INSERT: https://github.com/3liz/QgisCadastrePlugin/blob/master/cadastre_import.py#L591

Mais cela ne suffit pas car là c'est carrément la function chunk qui pose souci en amont

NB: l'idée de chunk, c'est de pouvoir justement charger les gros fichiers MAJIC par bout, pour ne pas surcharger la RAM. Je vais devoir modifier cette méthode pour y intégrer un test/remplacement des caractères pourris

mdouchin commented 5 years ago

Corrigé via 89b8e11 Pouvez-vous tester svp ?

lecault commented 5 years ago

Bonjour, J'ai un problème similaire sur le Morbihan :

Traceback (most recent call last):
  File "./do_import.py", line 886, in <module>
    cii.processImport()
  File "./do_import.py", line 876, in processImport
    qi.importMajic()
  File "/var/QgisCadastrePlugin/cadastre_import_cli.py", line 439, in importMajic
    item['method']()
  File "/var/QgisCadastrePlugin/cadastre_import_cli.py", line 537, in importMajicIntoDatabase
    self.dialog.edigeoDirection
UnicodeDecodeError: 'ascii' codec can't decode byte 0xef in position 0: ordinal not in range(128)

Je viens de mettre à jour les scripts avec la modification de hier, j'ai toujours l'erreur. A voir pour les autres si ça change quelque chose...

sebGIS commented 5 years ago

Je test à mon retour de congés

lecault commented 5 years ago

Pour info, dans notepad on peut trouver où sont les caractères non ASCI. Recherche => Rechercher des caractères dasn une plage => caractères non-ASCII Il m'en a trouvé 2 lié à un compte. ça ne marche toujours pas mais on avance.

mdouchin commented 5 years ago

@lecault

mon correctif dans la 1.8.1 est sur l'import réalisé dans l'interface graphique du plugin, pas l'import en ligne de commande, car je n'en était pas l'auteur, et je n'ai pas vu qu'il y avait ici du code redondant. Il faut qu'on refactorise le code. Pouvez-vous tester avec le plugin dans QGIS, et non en ligne de commande avec ce script ? Sinon, il suffit d'appliquer la modification que j'ai poussée : https://github.com/3liz/QgisCadastrePlugin/commit/89b8e11247d0b08ae34cd1fc09e19cc871aa54d7#diff-2018dbba00fa2e82ce18f5df2d7d6044R579
ouvrir un fichier dans notepad++, ça va si le fichier est petit. Sur les fichiers départementaux, on peut vite atteindre 1Go pour certaines, et là, il faut d'autres outils.
Pour info, on peut aussi supprimer les caractères avec d'autres outils en ligne de commande, sous Linux, par exemple remplacer ces caractères par des espaces

tr -c "[:space:] -~" "X"<PROP.txt>NEWPROP.txt

lecault commented 5 years ago

@mdouchin

Le passage sur QGis confirme que le soucis n'est plus au niveau de l'encodage (il n'arrivait pas à afficher l'erreur).

ERREUR : MAJIC - Les données concernent des départements et codes direction différents : département : 5 et direction : 6, département : 56 et direction : 0

Alors que tout commence par 560.

mathieuTOUBLANC commented 5 years ago

@mdouchin

Pour ma part, la version 1.8.1 du plugin corrige bien l'erreur: pour rappel,j'avais un fichier MAJIC sur une de mes communes du 44 (Loire-Atlantique) qui contenait des caractères non-ASCII. Cela ne pose plus de problème, l'import et le chargement des données est correct, les données des propriétaires apparaissent bien.

mathieuTOUBLANC commented 5 years ago

Par contre j'ai une grosse différence de performance entre la version 1.8.0 et 1.8.1: test réalisé sur une seule commune: --> 1.8.1 import en 766 secondes --> 1.8.0 import en 126 secondes Cependant je me demande si cela n' est pas dû à une autre modification réalisée sur le plugin (voir issue #189 )

mathieuTOUBLANC commented 5 years ago

deuxième test réalisé à l'instant sur une autre commune: --> 1.8.1 import en 618 secondes --> 1.8.0 import en 204 secondes

Je devrais peut-être poster mon commentaire sur un autre sujet, je ne sais pas. Cela dit j'observe une nette régression des performances entre la version 1.8.0 et 1.8.1 du plugin.

Mes tests sont réalisés communes par commune, mais j'imagine qu' à l'échelle d'un département la différence peut se compter en heures, voir en jours selon la machine qu'on possède.

mdouchin commented 5 years ago

@mathieuTOUBLANC Merci de créer une nouvelle demande sur github pour les soucis de performance. Pouvez vous y ajouter le log de chaque import, histoire de voir quelle requête prend du temps ?

sebGIS commented 5 years ago

Bonjour, J'ai testé et bien c'est nickel. Import de deux départements dont celui qui était vérolé en plus ou moins le même temps qu'avant et en plus maintenant avec MAJIC2019 et plus 2018. Merci

djes commented 5 years ago

@mdouchin Merci pour le correctif ! Je pense qu'il faut aussi faire la même chose pour la ligne 501, à la place de "with open(fpath) as fin:" -> "with open(fpath, encoding='ascii', errors='replace') as fin:"

sebGIS commented 5 years ago

Bonjour, Bon bah sur mes gros département ce fut beaucoup plus long avec le 1.8.1 le 77 et 78 je suis passé de 2h30 à plus de 6h pour chaque. Mais cela marche nickel

mdouchin commented 5 years ago

@djes pourriez vous proposer un pull request ? Si vous n'êtes pas familier avec Github, vous pouvez modifier directement le fichier ici: https://github.com/3liz/QgisCadastrePlugin/edit/master/cadastre_import.py

@sebGIS merci pour le retour. Il faut absolument qu'on trouve ce qui rallonge l'import. Pourriez-vous SVP lancer l'import sur une bdd de test avec les 2 versions et poser ici le log complet de l'import ?

sebGIS commented 5 years ago

@mdouchin Pas de pb une avec la version 1.8.1 et l'autre en 1.8.0 (j'ai pas gardé je le trouve où) Postgres 9.6 J'essaie de faire cela pour la fin de semaine prochaine.

mdouchin commented 5 years ago

Merci @sebGIS La version 1.8.0 peut être trouvée ici: https://github.com/3liz/QgisCadastrePlugin/archive/1.8.0.zip

On peut dans QGIS 3.4 ajouter une extension depuis un ZIP. Il faut bien sûr supprimer d'abord l'extension 1.8.1

djes commented 5 years ago

N'oubliez pas de renommer le fichier zip en cadastre.zip ainsi que le dossier contenu, sinon ça ne fonctionne pas.

djes commented 4 years ago

@djes pourriez vous proposer un pull request ? Si vous n'êtes pas familier avec Github, vous pouvez modifier directement le fichier ici: https://github.com/3liz/QgisCadastrePlugin/edit/master/cadastre_import.py

C'est fait : https://github.com/djes/QgisCadastrePlugin/pull/1/commits/ddcbd31907defe92a3e60b8098eba25e5938c901

sebGIS commented 4 years ago

Désolé j'ai pas encore eu le temps de faire les tests . Mais j'ai pas oublié. Je vais essayer de faire le premier vendredi.

sebGIS commented 4 years ago

log 1.8.1

INITIALISATION
* Copie du répertoire C:\Users\s.maison\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 
7 s 
MAJIC
Suppression des contraintes 
- SUPPRESSION DES CONTRAINTES D'INTEGRITEES : DEBUT 
- suppression clefs primaires 
- SUPPRESSION DES CONTRAINTES D'INTEGRITEES : FIN 
7 s 
Suppression des indexes 
7 s 
Import des fichiers majic 
D:/Z_TAF/cadastre2019/Cad2019/grand paris dir 780\BATI.A2019.N000499 
D:/Z_TAF/cadastre2019/Cad2019/grand paris dir 780\FANTOIR0119 
D:/Z_TAF/cadastre2019/Cad2019/grand paris dir 780\LLOC.A2019.N000499 
D:/Z_TAF/cadastre2019/Cad2019/grand paris dir 780\NBAT.A2019.N000499 
D:/Z_TAF/cadastre2019/Cad2019/grand paris dir 780\PDLL.A2019.N000499 
D:/Z_TAF/cadastre2019/Cad2019/grand paris dir 780\PROP.A2019.N000499 
421 s 
Mise en forme des données 
- FORMATAGE DONNEES : DEBUT 
- Traitement: parcelle 
- supprime en 2018 
457 s 
- Traitement: suf 
485 s 
- Traitement: sufexoneration 
507 s 
- Traitement: suftaxation 
532 s 
- Traitement: local00 
568 s 
- Traitement: local10 
- supprime 
629 s 
- Traitement: pev 
768 s 
- Traitement: pevexoneration 
788 s 
- Traitement: pevexoneration_imposable 
807 s 
- Traitement: pevexoneration_imposee 
812 s 
- Traitement: pevtaxation 
862 s 
- Traitement: pevprincipale 
902 s 
- Traitement: pevprofessionnelle 
908 s 
- Traitement: 
915 s 
- Traitement: pevdependances 
939 s 
- Traitement: commune_majic 
948 s 
- Traitement: proprietaire 
1095 s 
- création: comptecommunal à partir de proprietaire 
1097 s 
- Traitement: pdl 
1114 s 
- Traitement: parcellecomposante 
1114 s 
- Traitement: lots 
1131 s 
- Traitement: lotslocaux 
1147 s 
- Traitement: commune 
1147 s 
- Traitement: voie 
1148 s 
- purge des doublons : voie 
1148 s 
- INDEXES 
1149 s 
- ANALYSES 
- FORMATAGE DONNEES : FIN 
1246 s 
Purge des données brutes 
1247 s 
EDIGEO
Type de base : postgis, Connexion: serveurlocal, Schéma: ajeter1.8.1 
* Décompression des fichiers 
1457 s 
Suppression des contraintes 
- SUPPRESSION DES CONTRAINTES D'INTEGRITEES : DEBUT 
- suppression clefs primaires 
- SUPPRESSION DES CONTRAINTES D'INTEGRITEES : FIN 
1458 s 
* Import des fichiers EDIGEO dans la base 
- Import des fichiers via ogr2ogr 
- Import des relations (*.vec) 
- 451 multipolygones mis à jours dans la base de données 
4792 s 
Mise en forme des données 
- FORMATAGE DONNEES : DEBUT 
- Suppression des données du lot '78' 
4792 s 
- index pour optimisation 
4792 s 
- geo_commune: utilisation de max et non distinct on pour compatibilite sqlite 
4835 s 
- geo_section 
4842 s 
- geo_subdsect 
- geo_parcelle 
4842 s 
- Indexes sur geo_parcelle et geo_commune pour optimisation 
4938 s 
- geo_subdfisc 
4946 s 
- geo_subdfisc_parcelle 
4946 s 
- geo_voiep 
4947 s 
- geo_numvoie 
4949 s 
- geo_numvoie_parcelle 
4949 s 
- geo_lieudit 
4962 s 
- geo_batiment 
5027 s 
- geo_batiment_parcelle 
5027 s 
- geo_zoncommuni 
5104 s 
- geo_tronfluv 
5105 s 
- geo_tronroute 
5107 s 
- geo_sym 
5107 s 
- geo_ptcanv 
5107 s 
- geo_borne 
5108 s 
- geo_borne_parcelle 
5108 s 
- geo_croix 
5116 s 
- geo_croix_parcelle 
5116 s 
- geo_symblim 
5119 s 
- geo_symblim_parcelle 
5121 s 
- geo_tpoint 
5132 s 
- geo_tpoint_commune 
5132 s 
- geo_tline 
5141 s 
- geo_tline_commune 
5141 s 
- geo_tsurf 
5152 s 
- geo_tsurf_commune 
5152 s 
- suppression des index temporaires 
5152 s 
- analyses 
5152 s 
- FORMATAGE DONNEES : FIN 
5166 s 
Placement des étiquettes 
5186 s 
Création des indexes spatiaux 
- attributes 
5225 s 
5275 s 
Ajout des contraintes 
- CREATION DES CONTRAINTES D'INTEGRITEES : DEBUT 
- création clé primaire 
- création clé étrangère 
- CREATION DES CONTRAINTES D'INTEGRITEES : FIN 
5324 s 
Création Unités foncières 
5533 s 
Ajout de la table parcelle_info 
5629 s 
5629 s 
FINALISATION
5669 s

sebGIS commented 4 years ago

Bah après trois test avec la version 1.8 j'arrive à la + ou - la même chose. J'ai retesté (2 fois) en 1.8.1 le département (77 en 6h) qui m'avait fait halluciné et résultat (2h50 + ou - a chaque fois). Mes 6H de la dernière fois doivent provenir d'un ralentissement de ma machine.

MaelREBOUX commented 4 years ago

Bonjour @sebGIS

Peut-on fermer ce ticket ?

SebCasa commented 4 years ago

oui c'est bon merci

SebCasa commented 4 years ago

pas retrouver le bon je suis sebGIS

Gustry commented 4 years ago

Merci pour le retour

SebCasa commented 4 years ago

c'est normal

Le jeu. 3 sept. 2020 à 15:37, Étienne Trimaille notifications@github.com a écrit :

Merci pour le retour

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/3liz/QgisCadastrePlugin/issues/191#issuecomment-686497222, or unsubscribe https://github.com/notifications/unsubscribe-auth/AI2ZGB7RMANB4KT5LNMCRRDSD6LYZANCNFSM4IJ7AZ3A .

boillodmanuel commented 3 years ago

Bonjour, J'ai rencontré un problème similaire : UnicodeDecodeError: 'ascii' codec can't decode Mon env :

QGIS : 3.18
Plugin Cadastre :1.10.2
OS : macos bigsur 11.2.3

J'ai fini par trouver comment corriger mon problème (la résolution de celui-ci est peut-être similaire)

Dans le fichier cadastre_import.py, fonction replaceParametersInScript, il manque l'encoding sur cette ligne : https://github.com/3liz/QgisCadastrePlugin/blob/2b2c0e3affcf67b49c88bda31f54cdb3b904a617/cadastre/cadastre_import.py#L1015-L1016

Voici le fix:

with open(scriptPath, 'w', encoding='utf-8') as fout:
    fout.write(data)

La locale système ne doit pas être configuré comme il faut dans QGIS. Pour le vérifier, j'ai ouvert la console python (Plugins > Console Python) et exécuté le code suivant :

# Explicitly open with ascii encoding:
# ❌ Error:
#   UnicodeEncodeError: 'ascii' codec can't encode character '\u2122' in position 0: ordinal not in range(128)
with open('/tmp/test', 'w', encoding='ascii') as fout:
    fout.write(u"\u2122")

# Open without encoding specified:
# ❌ Error or ✅ Works depending of system locale :
#   UnicodeEncodeError: 'ascii' codec can't encode character '\u2122' in position 0: ordinal not in range(128)
with open('/tmp/test', 'w') as fout:
    fout.write(u"\u2122")

# Explicitly open with utf-8 encoding:
# ✅ Works
with open('/tmp/test', 'w', encoding='utf-8') as fout:
    fout.write(u"\u2122")

Pour forcer la locale dans QGIS, j'ai ajouté la variable d'environnement LC_ALL dans les préférences (interface en anglais) :.

Open QGIS > Preferences > System
Check "Use custom variable"
Add LC_ALL = en_US.UTF-8 or whatever you want.

Je ne suis pas sûr qu'il faille garder ce paramétrage mais ca aide pour débugger.

3liz / QgisCadastrePlugin

UnicodeDecodeError: 'utf-8' #191