Nous utilisons des cookies pour vous garantir la meilleure expérience sur notre site. Si vous continuez à utiliser ce dernier, nous considèrerons que vous acceptez l'utilisation des cookies. J'ai compris ! ou En savoir plus !.
banniere

Le portail francophone de la géomatique


Toujours pas inscrit ? Mot de passe oublié ?
Nom d'utilisateur    Mot de passe              Toujours pas inscrit ?   Mot de passe oublié ?

Annonce

Rencontres QGIS 2025

L'appel à participation est ouvert jusqu'au 19 janvier 2025!

#1 Thu 05 April 2018 15:06

ChristopheV
Membre
Lieu: Ajaccio
Date d'inscription: 7 Sep 2005
Messages: 3199
Site web

données MAJIC 2017 BATI

Bonjour,

Le fichier descriptif des données bâti 2017 fourni par la DGFiP comporte une grossière erreur.
Le champ valeur locative de l'année, (ou DVLPERA de l'enregistrement 21 pour les fans d'acronymes incompréhensibles et autres ), n'est pas codé sur 9 mais 7 caractères .......

Bref comme d'habitude c'est la faute à personne ... (c'est quand qu'il embauche des pro dans leur service informatique à la DGFiP ?).

Dernière modification par ChristopheV (Thu 05 April 2018 21:22)


Christophe
L'avantage d'être une île c'est d'être une terre topologiquement close

Hors ligne

 

#2 Thu 05 April 2018 18:49

christian
Participant assidu
Lieu: Isère
Date d'inscription: 20 Sep 2005
Messages: 207
Site web

Re: données MAJIC 2017 BATI

Il vaut mieux manquer de caractère que d'avoir mauvais caractère ... big_smile

(pardon, j'ai pas pu m’empêcher wink )

Hors ligne

 

#3 Thu 05 April 2018 21:33

ChristopheV
Membre
Lieu: Ajaccio
Date d'inscription: 7 Sep 2005
Messages: 3199
Site web

Re: données MAJIC 2017 BATI

Bonjour,

@christian : lol en plus il y en a (avait) des gens compétents non ? (mais ceux là c'est pas des gens formatés "centrale").

Mais quand tu passes ta journée a reprendre un code qui fonctionnait, en mode debugg car tu sais pas quelle bêtise tu vas trouver, et qu'en plus t"es dans l'urgence car les ministres (oui les vrais) arrivent et qu'il faut des chiffres sur la situation foncière, t'as juste une envie, c'est de faire comme avec ton animal de compagnie préféré, lui mettre le nez dedans pour qu'il comprenne ...

Alors mauvais caractère peut-être, mais dans n'importe quelle boite privée une perte de productivité pareille en raison d'un fournisseur donnerait des débats autrement plus incisifs et je parle pas des conséquences financières. Tant que dans la fonction publique les mecs qui prennent des décisions ne seront pas responsables (donc virables) de celles ci ...

Dernière modification par ChristopheV (Thu 05 April 2018 21:38)


Christophe
L'avantage d'être une île c'est d'être une terre topologiquement close

Hors ligne

 

#4 Fri 06 April 2018 08:52

Alban NOIR
Participant occasionnel
Date d'inscription: 7 Sep 2005
Messages: 32

Re: données MAJIC 2017 BATI

Bonjour,
J'ai vérifié des matrices 2017 de plusieurs départements. Pour l'article 21, DVLPERA est bien stocké sur 9 caractères.

Dernière modification par Alban NOIR (Fri 06 April 2018 09:01)


Alban

Hors ligne

 

#5 Fri 06 April 2018 08:54

yartostout
Participant assidu
Lieu: Bretagne
Date d'inscription: 24 Jun 2015
Messages: 173

Re: données MAJIC 2017 BATI

Profite-en pour en parler directement aux ministres Christophe big_smile

Sans déc, comment ça se passe pour la correction de ce type d'erreur ? Ils refont un millésime ?

Dernière modification par yartostout (Fri 06 April 2018 08:54)

Hors ligne

 

#6 Fri 06 April 2018 09:21

ChristopheV
Membre
Lieu: Ajaccio
Date d'inscription: 7 Sep 2005
Messages: 3199
Site web

Re: données MAJIC 2017 BATI

Bonjour,

J'ai vérifié des matrices 2017 de plusieurs départements. Pour l'article 21, DVLPERA est bien codé stocké sur 9 caractères.


Merci d'avoir vérifié sur d'autres départements. (je n'en ai pas la possibilité).

En revanche je n'invente rien, et dans mes données, si je fais un substring(maligne,69,9) je récupère comme "EP" pour les deux derniers caractères, qui correspondent à l'exonération, donc au champs suivant (NB en VB une chaîne commence à 0 pas à 1 d'où le 69 et pas 70). Comme je le cast() direct en entier forcément ça plante.

Après plusieurs heures de contrôle, il s'avère que c'est uniquement UN enregistrement qui est incorrect. Pourquoi ? Peut-être une anomalie dans l'export. Sachant que mon fichier provient du CD-ROM officiel et que je n'ai fait que le copier puis l'extraire avec l'outil fourni.

D'une manière ou d'une autre c'est pas la première fois que nous constatons une différence entre ce qui est écrit dans le fichier descriptif et la réalité informatique du fichier. Jusqu'à ce jour c'était des arguties de spécialistes, mais cela n'avait jamais été un truc aussi gros. D'où ma mauvaise humeur.


Christophe
L'avantage d'être une île c'est d'être une terre topologiquement close

Hors ligne

 

#7 Fri 06 April 2018 17:48

Alban NOIR
Participant occasionnel
Date d'inscription: 7 Sep 2005
Messages: 32

Re: données MAJIC 2017 BATI

Si tu parles de

Code:

substring(maligne,69,9)

c'est probablement qu'on est déjà dans une base de données. Le fichier à donc déjà été manipulé/converti au moins une fois.
Pour être certain de l'origine de l'erreur il faudrait vérifier directement dans le fichier du bâti à la ligne concernée car on peut aussi imaginer qu'il y ait un bug dans la/les premières étapes de traitement que tu réalises.


Alban

Hors ligne

 

#8 Fri 06 April 2018 22:16

jmarsac
Participant assidu
Lieu: NICE
Date d'inscription: 26 Oct 2005
Messages: 572
Site web

Re: données MAJIC 2017 BATI

Bonsoir,
Je suppose que Christophe charge le fichier brut dans une table comportant une seule colonne (un enregistrement pour chaque ligne). Donc pas d'autre traitement que la lecture du fichier texte et l'INSERT de chaque ligne.


Jean-Marie
Azimut

Hors ligne

 

#9 Mon 09 April 2018 09:37

ChristopheV
Membre
Lieu: Ajaccio
Date d'inscription: 7 Sep 2005
Messages: 3199
Site web

Re: données MAJIC 2017 BATI

Bonjour,

Merci du suivi.

Je suis reparti depuis le CD d'origine. Extraction directement avec 7-zip. Apparemment pas de soucis, il n'y a plus la ligne en erreur.

J'ai manifestement travaillé sur un fichier corrompu la première fois.

Pour répondre à Jmarsac et Alban Noir la première phase se réalise en .NET. Ouverture des fichiers textes en mode lecture ligne à ligne, chargement dans des tables temporaires avec réplication des liens hiérarchiques de la base MAJIC, par exemple templocaux avec temppev. Donc c'est bien une lecture directe du fichier mais pour une inscription temporaire légèrement plus évoluée.

L'ensemble est ensuite transformé dans le modèle final par un script SQL.

Je profite du sujet pour une remarque (apaisée), dans le cadre d'une programmation efficace, il serait plus simple lors de l'ajout de nouveau champs dans les données MAJIC de ne pas le faire par insertion mais par ajout à la fin.
Ceci permet de garantir le fonctionnement de code plus anciens.


Christophe
L'avantage d'être une île c'est d'être une terre topologiquement close

Hors ligne

 

Pied de page des forums

Powered by FluxBB