Invalid value 'Ma' for "DD"

[landryb]

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]

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:

• comment y faire remonter a la dgfip pour correction ? @jdesboeufs une idée ?
• comment gérer ce cas dans l'import pour juste ignorer lavaleur erronée ?

[landryb]

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]

@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]

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]

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

[jdesboeufs]

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]

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]

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]

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

[mdouchin]

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]

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

[mdouchin]

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]

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]

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]

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]

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]

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

[geofffl]

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]

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

[geofffl]

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]

@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]

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

• importation via postgresql
• table parcelle = peuplée
• table geo_parcelle = vide
• table parcelle_info = vide
• table proprietaire = peuplée

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

[mdouchin]

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]

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]

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]

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

[mdouchin]

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

[geofffl]

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]

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]

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]

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

[landryb]

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

[MaelREBOUX]

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