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
61 stars 41 forks source link

Invalid value 'Ma' for "DD" #120

Closed landryb closed 5 years ago

landryb commented 6 years ago

Vu lors d'un import de données sur le dept 38 (isère)

.   - geo_subdsect
. invalid value "Ma" for "DD"
DETAIL:  Value must be an integer.

invalid value "Ma" for "DD"
DETAIL:  Value must be an integer.

La conséquence, c'est qu'il n'y a aucun objet pour le lot correspondant dans la table geo_subdsect .. ce qui ne va probablement pas plaire au plugin qadastre ni a cadastrapp.

J'imagine que le "DD" est peut-être le résultat d'un to_date() sur une substring, mais j'ai du mal a voir si le pb vient de majic ou d'edigeo, et dans quel fichier il faut creuser. Une piste d'exploration ?

landryb commented 6 years ago

Ok, trouvé.

  DIS (String) = Mai 1998

C'est sensé être DD/MM/YYYY ... et ca provient de

https://cadastre.data.gouv.fr/data/dgfip-pci-vecteur/latest/edigeo/feuilles/38/38507/edigeo-38507000AI01.tar.bz2

$grep 'Mai' *
EDAI01T2.VEC:ATVST08:Mai 1998

Dans ce cas, 2 problemes:

landryb commented 6 years ago

J'ai regardé un peu toutes les données du 38, et pour le champ 'DIS' j'ai un peu de tout, du 'YYYY' seul sans DD/MM, du '(null)', du 20050121 (YYYYMMDD?), du 28072009 (DDMMYYYY), du 2002.02.27 (YYYY.MM.DD !? original) - il faut donc croire que le to_date() ici (https://github.com/3liz/QgisCadastrePlugin/blob/master/scripts/plugin/edigeo_formatage_donnees.sql#L58) bouffe toutes ces variantes horribles, et ne vomit que sur 'des vrais chars alphabétiques'.

jdesboeufs commented 6 years ago

@landryb on a pas mal d'anomalies à remonter, et on aimerait être en mesure d'assurer un minimum de suivi et de transparence. J'avais l'idée de créer un dépôt GitHub dédié au PCI, on pourrait du coup utiliser les Issues comme moyen de centraliser les problèmes. Au début je ferai peut-être une compilation mensuelle mais je suis sûr que c'est un outil qui pourrait être pris en main directement par les équipes cadastre de la DGFiP à moyen terme. Qu'en penses-tu ?

landryb commented 6 years ago

Ca serait génial, mais à ma connaissance les agents de la DGFiP n'ont pas forcément accès à internet..... ou alors les choses ont bien changé :)

jdesboeufs commented 6 years ago

Ça se tente quand même, et au pire ça leur fera un argument auprès de leur DSI.

jdesboeufs commented 6 years ago

Pour en revenir au problème, ce champ étant facultatif, même mal formaté il ne devrait pas être bloquant pour l'import dans les outils.

Et par ailleurs c'est dommage que ce champ soit de type T (texte) avec contrainte puisqu'il y a un type D (date) qui fonctionne plutôt bien.

landryb commented 6 years ago

Et par ailleurs c'est dommage que ce champ soit de type T (texte) avec contrainte puisqu'il y a un type D (date) qui fonctionne plutôt bien.

Mais ca j'imagine que c'est dépendant du process qui maj les données et de leur schéma.. vu que le champ en question autorise DD/MM/YYYY ..

En attendant de trouver ou faire remonter les incohérences dans le pci, le script d'import s'est aussi pris les pieds dans le tapis de la meme manière sur une feuille du 73, mais celle-ci a été plus drole a trouver.

. invalid value "" for "DD"
DETAIL:  Value must be an integer.

invalid value "" for "DD"
DETAIL:  Value must be an integer.

Pratique, pour trouver une valeur vide dans un champ.. bref, un peu de grep, et j'ai trouvé dans https://cadastre.data.gouv.fr/data/dgfip-pci-vecteur/latest/edigeo/feuilles/73/73015/edigeo-73015000AE01.tar.bz2, le fichier EDAE01T2.VEC contient ceci:

367 ATPCP23:EDAE01;SeSD;ATT;DEDI_id
368 TEXT 06:8859-1
369 ATVST01:-

Le - est pour montrer 'un espace en fin de ligne' dans mon editeur... donc une date du champ DEDI, j'imagine que l'outil devait se plaindre que le champ était vide, alors l'opérateur a mis un espace ?

geofffl commented 6 years ago

Bonjour à tous, Je suis confronté à ce problème, travaillant sur les départements 73 et 74 (tout est OK pour le 74). Auriez-vous une idée de contournement pour intégrer malgré tout les données ? Est-il possible de forcer le script d'import pour que le champ vide ne soit pas bloquant ? Merci d'avance !

landryb commented 6 years ago

Oui, corriger les données en éditant le fichier édigeo avec un éditeur de texte. Décompresser et recompresser la feuille évidemment...

mdouchin commented 6 years ago

Merci pour cet échange. Je vais ajouter un test dans le script d'import pour éviter le désagrément sur ce champ. Le souci, c'est que beaucoup de champs de différentes "tables" peuvent être concernées un jour ou l'autre par des incohérences dans les fichiers sources. Le mieux est toujours de revenir à la source, afin que le problème soit résolu en amont

mdouchin commented 6 years ago

Que pensez vous d'une valeur par défaut à 01/01/1900 dans le cas où la date n'est pas conforme ?

mdouchin commented 6 years ago

Je propose

CASE WHEN dis ~ '^\d{2}/\d{2}/\d{4}$' THEN to_date(dis, 'DD/MM/YYYY') ELSE to_date('01/01/1900', 'DD/MM/YYYY') END

et la même chose pour dedi

PostgreSQL est assez "intelligent" pour convertir des dates bizares comme 32/12/2017 en 01/01/2018, c'est pourquoi mon expression régulière reste simple.

landryb commented 6 years ago

Hm, je ne suis pas si certain qu'il faille une regex, car dans ce champ il y'a un peu de tout, pas forcément DD/MM/YYYY, cf mon 3e commentaire... il faudrait pouvoir "tester" le résultat de to_date, ou p-e juste des chiffres (et des points, / ?)..

mdouchin commented 6 years ago

justement, la regex permet de savoir si le "tout" qui est dans ce champ correspond au format attendu. Si non, on utilise 01/01/1900. Le vrai souci provient de l'absence de support de regexp pour spatialite.

Possible via https://stackoverflow.com/questions/5365451/problem-with-regexp-python-and-sqlite Je teste

landryb commented 6 years ago

Je ne sais pas si to_date sait analyser correctement 20050121, 2010, 28072009 et 2002.02.27, car ce sont des exemples que j'ai trouvé dans mes fichiers..si on requiert DD/MM/YYYY c'est bien plus strict

mdouchin commented 6 years ago

to_date n'analyse rien. C'est le 2ème paramètre on on lui signale le format. Dans notre cas, le to_date s'attend donc à avoir un format "français" DD/MM/YYYY.

C'est pourquoi ma regex, qui elle analyse le champ, ne permet que ce format, justement pour que le to_date ne plante pas. C'est le standard EDIGEO qui doit être respecté. Si c'est le cas, le plugin prendra la date. Sinon il mettra le 1er janvier 1900

landryb commented 6 years ago

ok, dans ce cas...c'est peut-être plus propre.

geofffl commented 6 years ago

Je n'ai pas les compétences pour tout suivre, mais merci de la proposition ! A disposition au besoin pour des tests ou autre.

mdouchin commented 6 years ago

@geofffl @landryb @jdesboeufs pouvez vous tester avec la version "master" téléchargeable via https://github.com/3liz/QgisCadastrePlugin/archive/master.zip

geofffl commented 6 years ago

L'importation vient de se terminer, et elle s'est déroulée sans blocage et retour d'erreur. Bon, par contre, ma table parcelle est vide !

mdouchin commented 6 years ago

@geofffl sous spatialite ou postgresql ? Si spatialite, via le DBManager de QGIS, est ce que la table parcelle issue du MAJIC est vide ? ou bien la table parcelle_info ? ou bien la table geo_parcelle issue du EDIGEO ?

geofffl commented 6 years ago

Désolé j'ai été avare en détails !

J'en déduis que ça coince toujours avec EDIGEO ? Je tente de nouveau, mais avec spatialite.

mdouchin commented 6 years ago

hum, rien à voir avec la modification que j'ai fait en tout cas, car elle concernait geo_subdsect. Pourriez vous m'envoyer le EDIGEO (si pas trop gros) via send.firefox.com ou framadrop.org svp ?

geofffl commented 6 years ago

Bien-sûr, je vous transmets une commune https://framadrop.org/r/wl7lr2ioqV#5np0uwhmQhUQVVVjy51wjaPIG+9Gv90RB/Gd4+KApu4= Sinon, c’est tout le département 73 que j'importe.

geofffl commented 6 years ago

Des nouvelles fraîches : je viens de tenter de nouveau l'import avec la version master du plugin fournie plus-haut. Les tables restent bien vides (voir ma liste plus haut) avec postgresql. MAIS, ça fonctionne avec spatialite. Mes tables sont bien peuplées et les parcelles apparaissent !

mdouchin commented 6 years ago

Mêmes tests et résultats pour moi : geo_parcelle vide après import sous PostgreSQL. Je cherche pourquoi.

mdouchin commented 6 years ago

Le souci vient de la table geo_subsect qui est vide sous PostgreSQL. Je regarde pourquoi

geofffl commented 6 years ago

Bonjour à tous, Je viens aux nouvelles concernant la table geo_subsect vide sous postgresql. Avez-vous une piste pour identifier la cause du souci ?

loicdouillard commented 6 years ago

Bonjour à tous, Je confirme avoir le même problème...à savoir aucun objet dans geo_parcelle ni dans geo_subsect suite à l'utilisation du plugin cadastre version master. C'est dommage parce que ça me permettait d'aller au bout de l'import Edigeo. Pour moi l'erreur d'import venait d'un date / time hors des limites sur le geo _subsect... Bonne journée

mdouchin commented 5 years ago

Pouvez vous svp retester, avec pour QGIS 2 la version de la branche master_2 et pour QGIS 3, la version de la branche master, et me faire un retour svp ?

MaelREBOUX commented 5 years ago

@landryb @geofffl @loicdouillard On est est où sur ce ticket ?

landryb commented 5 years ago

a priori fixé par 72df1402 - pas d'occurence de invalid value pour mes imports en 2019.

MaelREBOUX commented 5 years ago

Je crois qu'on peut fermer alors. @landryb à rouvrir au besoin.