Support des évolutions majic 2018

[landryb]

Cf http://fichiers.craig.fr/temp/descript_majic/

PDLL et LLOC: rien PROP:

Nouvelles valeurs (cf. § 2.9) pour les champs DFORME « forme juridique » et DFORMJUR « forme juridique abrégée ».

NBAT:

Dans l’article 10, descriptif de la parcelle, suppression du champ « DSRPAR ».

BATI:

- Au sein de l’article 10, descriptif du local, suppression du champ « DSRPAR ».
- Au sein de l’article 30, décrivant les exonérations liées au local,
• le champ « GNEXTL » peut prendre de nouvelles valeurs : « ES » (équipements souterrains indissociables des casiers des installations de stockage de déchets non dangereux), « BS » (abattement de 30 % pour des logements faisant l’objet d’un bail réel et solidaire) et « MA » (minoration de 60 % de la valeur locative des locaux d’habitation situés à Mayotte).
• Le champ « CCOLOC » peut prendre de nouvelles valeurs : « TS » (TSE), « OM » (TEOM).
Par ailleurs, la valeur « TC » est éclatée en « C » (commune), « D » (département) et « GC »
(groupement de communes) ;
• Création du champ « VALPLAF » (montant du planchonnement).

Création d’un article 52 portant sur les lissages des locaux révisés.

[landryb]

On aura d'ores et déja un problème avec ce commit dans le modèle qgis: 3liz/QgisCadastrePlugin@7c48ec5dcb (oui, c'est dans une branche master_2 mais ca doit etre la v 1.5.2 du modele) - nos vues vomissent dessus car le type de champ date ne matche plus.

psql:/tmp/tmp.IHCPOmXapI/qgisProprietaire.sql:177: ERROR:  function to_char(text, unknown) does not exist
 psql:/tmp/tmp.IHCPOmXapI/qgisProprieteBatie.sql:132: ERROR:  function to_char(text, unknown) does not exist
psql:/tmp/tmp.IHCPOmXapI/qgisProprieteNonBatie.sql:113: ERROR:  function to_char(text, unknown) does not exist

a voir si on adapte nos vues, et comment.... j'imagine que supprimer les 3 appels a to_char serait le plus simple.

$git grep to_char script/qgis/
script/qgis/views/qgisProprietaire.sql:                 COALESCE(to_char(pqgis.jdatnss, ''DD/MM/YYYY''), '''') as jdatnss,
script/qgis/views/qgisProprieteBatie.sql:                       COALESCE(to_char(l.jdatat, ''DD/MM/YYYY''), '''') as jdatat,
script/qgis/views/qgisProprieteNonBatie.sql:                    COALESCE(to_char(p.jdatat, ''DD/MM/YYYY''), '''') as jdatat,

[landryb]

Cf 3liz/QgisCadastrePlugin#137 pour la justification du changement de format.

[landryb]

A priori le fait que ces dates changent de format aurait un impact sur les infos renvoyées, pour l'historique de mutation d'un batiment j'ai jdatat: /99/0901 ou jdatat: /00/0304 dans le json renvoyé par /services/getFIC?onglet=4, j'imagine qu'il faut revoir la manière dont les dates sont formatées, a voir si ca doit être fait coté client ou coté serveur.

Dans la base auparavant jdatat contenait (de type text) DD/MM/YYYY, maintenant il y'a juste DDMMYYYY.

[landryb]

Ok, je pense avoir trouvé.. dans les vues QGIS c'est le commit e0eb0b7 qui formatait la date de cette manière, et les index de caractères ne collent plus.

[landryb]

Cf #311 pour la justification

[landryb]

C'est bien ce champ qui pose problème:

[db:5432] cadastrapp@cadastrapp=> select jdatat from cad2018.parcelledetails limit 10;
  jdatat
----------
 /00/3112
 /99/0202
 /00/1909
 //
 //
 /97/0101
 /97/0101
 /97/0101
 /98/0101
 /00/0405

[landryb]

La bonne forme pour la requète créant la vue matérialisée serait la suivante:

[db:5432] qadastre@qadastre=> select concat(substr(jdatat::text,1,2),'/',substr(jdatat::text,3,2),'/',substr(jdatat::text,5,4)) from qad2018.parcelle where ccocom='300' and lot='dep03' limit 10;
   concat
------------
 23/12/1991
 27/12/2013
 01/01/1975
 01/01/1975
 01/01/1975
 10/12/1991
 03/06/2005
 01/01/1981
 01/01/1981
 01/01/1975
(10 rows)

[pierrejego]

A tester mais je n'ai pas les données 2018 de mon côté.

[MaelREBOUX]

Bonjour @pierrejego Bonjour @landryb

Un nouvelle version 1.6.0 vient de sortir : https://twitter.com/kimaidou/status/1031467271112351744 + https://github.com/3liz/QgisCadastrePlugin/blob/1.6.0/CHANGELOG.md#version-160

Je rentre de congés ce jour. Je découvre qu'il y a des changements pour ce millésime 2018. Y'a de la doc qq part ? je vais me renseigner.

En tout cas : je propose de travailler sur une branche spécifique.

[MaelREBOUX]

Je compile tout le suivi dans ce document en partage : https://docs.google.com/document/d/1eQcf-k0MEeeLLJZ09Qse1xnoJkI3xe3JD0uwV36Hp4Q

Pas de casse : les moulinettes 2017 devraient traiter en transparence.

Et pas besoin de créer une branche spécifique du coup. On va voir comment on fait pour les releases.

[landryb]

Cf 3liz/QgisCadastrePlugin#148

[MaelREBOUX]

Bon : pour moi ce millésime 2018 est transparent sur les moulinettes. Ici on mouline du arcopole 2017 et ça passe. Ceux qui font du QGIS peuvent déjà utiliser les branches master ou master_2.

A ce stade je ne pense pas que cadastrapp soit à modifier. Je propose donc qu'on ne répercute pas les nouveautés 2018 maintenant / tout de suite. Mais dans un release ultérieure fin 2018 / début 2019. Car sur le fond je n'ai encore aucune info sur ces nouveauté et quoi en faire (planchonnement). Et encore moins sur l'article 52.

Votre avis @landryb @pierrejego @jusabatier ?

[landryb]

Il faut au moins merger #401 sinon brotch.

[MaelREBOUX]

Ben pas si tu continues pour cette année à mouliner en version QGIS 2017. Si on fait ça : cadastrapp va être hybride : arcopole 2017 et QGIS 2018.

M'enfin : ça concerne pas encore bcp de monde donc on peut se le permettre. Faudra être clair sur la note de version.

[catmorales]

Je viens de rencontrer un problème à l'intégration des données 2018, concernant les champs "DSUPK1" et "DSUPK2" de la table DGI_PPROF du modèle arcopole. Ils étaient auparavant, remplis avec des valeurs à 0 ou autre et maintenant sont remplis par une chaîne vide. Or, ils font l'objet d'un changement de type lors de la création de la vue cadastrapp_arcopole.descproffessionnel:

CAST(prof.dsupk1 AS integer),
CAST(prof.dsupk2 AS integer),

Ceci implique que la vue cadastrapp_arcopole.descproffessionnel n'est pas créée.

[landryb]

dans le modèle QGIS elle est crée mais toutes les valeurs sont a NULL a cause de https://github.com/3liz/QgisCadastrePlugin/blob/master/scripts/plugin/2018/majic3_formatage_donnees.sql#L552 qui met un NULL si il ne trouve que des espaces..

[MaelREBOUX]

Le problème est causé par une évolution de structure Majic qui est passée sous les radars. les valeurs dsupk1 et dsupk2 ne son pas lues correctement.

cf https://github.com/3liz/QgisCadastrePlugin/issues/148#issuecomment-418074777 pour la correction à la source et ainsi éviter de modifier cadastrapp.

Vu avec @landryb il y a un espèce de garde fou qui fait que tout est à null dans Qgis actuellement. Iic dans arcOpole c'est chaîne vide et ça casse. on v patcher notre base en attendant. et signaler aux utilisateurs.

[landryb]

A priori on ne s'en est pas rendu compte en 2017, car dsupk1 et dsupk2 sont utilisés que depuis 84ac0033 - le schéma 2017 n'avait pas ces champs.

[landryb]

Et ils ont été ajoutés aux scripts/schémas dans 583212e donc étaient dans 1.5..

[MaelREBOUX]

La (re)prise en compte des attributs dsupk1 et dsupk2 a été prise en compte par les PR 150 et 151 du plugin QGIS.

Il reste tjs à prendre en compte l'article 52. Je lance le chantier déjà sur le plugin qgis --> https://github.com/3liz/QgisCadastrePlugin/issues/152

[catmorales]

Je relance le ticket car il n'y a pas eu de correctif pour le modèle arcopole. et je viens de passer la mise à jour de juin avec la même erreur. Je vais corriger le pb en interne. @MaelREBOUX , dans le contexte actuel, je ne sais pas si ça vaut le coup de passer le correctif sur le modèle arcopole, ton avis ?

[MaelREBOUX]

@catmorales : question dépassé à ce jour ;)

@mdouchin m'a indique dans #152 que les données de l'article 52 devraient être en base. Reste à les utiliser et je suis pas encore revenu dessus.

TODO reste d'actualité donc...

[MaelREBOUX]

J'ai vérifié https://github.com/3liz/QgisCadastrePlugin/issues/152 et l'article 52 est toujours vide cette année donc on verra quand on en aura besoin... un jour...