Import incrementaux de lots distincts melange les lots dans la table comptecommunal

[landryb]

J'ai une db qadastre ou j'ai importé (avec mon fork en cli mais utilisant le meme schema) dans des lots distincts des départements:

• dans un premier temps 03 puis 15 puis 43 puis 63.
• dans un second temps 01 puis 07 puis 26 puis 38 puis 42 puis 69 puis 73 puis 74.

étrangement, les données du 01 se retouvent dans le lot du 38, et ainsi de suite..

qadastre=>  select lot,count(*) from qad2017.comptecommunal group by lot order by count;
  lot  |  count
-------+---------
 dep15 |  357061
 dep43 |  603724
 dep03 | 1126860
 dep63 | 1126860
 dep01 | 1516868
 dep07 | 1790940
 dep26 | 2095964
 dep38 | 2839021
 dep42 | 3252326
 dep69 | 4045645
 dep73 | 4492617
 dep74 | 5093595

J'ai l'impression qu'une table/vue intermédiaire n'est pas nettoyée:

qadastre=>  select lot,count(*) from qad2017.comptecommunal where comptecommunal like '201763%' group by lot order by count;
  lot  | count
-------+--------
 dep42 | 523136
 dep73 | 523136
 dep01 | 523136
 dep63 | 523136
 dep03 | 523136
 dep74 | 523136
 dep07 | 523136
 dep26 | 523136
 dep38 | 523136
 dep69 | 523136

qadastre=>  select lot,count(*) from qad2017.comptecommunal where comptecommunal like '201738%' group by lot order by count;
  lot  | count
-------+--------
 dep42 | 743057
 dep74 | 743057
 dep38 | 743057
 dep69 | 743057
 dep73 | 743057

qadastre=>  select lot,count(*) from qad2016.comptecommunal where comptecommunal like '201603%' group by lot order by count;
  lot  | count
-------+--------
 dep03 | 228074
 dep15 | 228074
 dep63 | 228074
 dep43 | 228074
(4 rows)

qadastre=>  select lot,count(*) from qad2016.comptecommunal where comptecommunal like '201643%' group by lot order by count;
  lot  | count
-------+--------
 dep43 | 246378
 dep63 | 246378

Je n'ai pas l'impression que ca affecte les tables lots, proprietaire et parcelle, je vais creuser un peu plus..

[landryb]

La table geo_unite_fonciere a l'air ok:

qadastre=> select lot,count(*) from qad2017.geo_unite_fonciere group by lot order by count;
  lot  |  count
-------+---------
 dep15 |  325752
 dep03 |  326024
 dep26 |  429536
 dep69 |  568877
 dep42 |  579875
 dep07 |  701535
 dep43 |  716915
 dep01 |  841030
 dep74 |  916468
 dep38 | 1038567
 dep63 | 1076194
 dep73 | 1132029

[landryb]

C'est juste une idée, mais ptete qu'il manque un filtre sur le lot ici: https://github.com/3liz/QgisCadastrePlugin/blob/master/scripts/plugin/2017/majic3_formatage_donnees.sql#L703

je tenterais bien avec and lot='[LOT]' dans ce WHERE... @mdouchin ?

[landryb]

Et j'ai bien l'impression de tenir le bon bout du problème :)

avant:

qadastre=> select count(*) from qad2017.comptecommunal where lot='dep15';
 357061
qadastre=> select count(*) from qad2017.comptecommunal where lot='dep15' and comptecommunal like '201703%';
 228420
qadastre=> select count(*) from qad2017.comptecommunal where lot='dep15' and comptecommunal like '201715%';
 128641

après:

qadastre=> select lot,count(*) from qad2017test.comptecommunal  group by lot order by count;
  lot  | count
-------+--------
 dep15 | 128641
 dep03 | 228420

qadastre=> select count(*) from qad2017test.comptecommunal where lot='dep15' and comptecommunal like '201703%';
     0

[landryb]

Mon import court toujours, mais ca a bien l'air de corriger ce problème la:

avant:

qadastre=> select lot,count(*) from qad2017.comptecommunal group by lot order by count;
  lot  |  count
-------+---------
 dep15 |  357061
 dep43 |  603724
 dep03 | 1126860
 dep63 | 1126860
 dep01 | 1516868
 dep07 | 1790940
 dep26 | 2095964
 dep38 | 2839021
 dep42 | 3252326
 dep69 | 4045645
 dep73 | 4492617
 dep74 | 5093595

apres:

qadastre=> select lot,count(*) from qad2017.comptecommunal  group by lot order by count;
  lot  | count  
-------+--------
 dep15 | 128641
 dep03 | 228420
 dep43 | 246663
 dep07 | 274072
 dep26 | 305024
 dep01 | 390008
 dep42 | 413305
 dep63 | 523136
 dep38 | 743057

[mdouchin]

Merci pour le suivi. Voir le PR pour continuer la discussion https://github.com/3liz/QgisCadastrePlugin/pull/122

[landryb]

J'ai l'impression qu'il y'a en plus d'autres erreurs liées aux imports multiples dans les tables 'non geographiques' faisant le lien entre 2 tables geo, ex geo_tline_commune ou geo_borne_parcelle, je n'ai pas le meme nombre d'objets dans les tables entre mon dev et ma prod ou les imports ont été fait en plusieurs fois, mais ou je suis sensé avoir les memes données à la fin.

A priori pas de souci sur les tables ayant une 'vraie' geometrie comme geo_parcelle.

#dev
qadastre=> select count(*) from qad2017.geo_tline_commune;
 5496611
qadastre=> select count(distinct(geo_tline)) from qad2017.geo_tline_commune;
 3123322
qadastre=> select count(*) from qad2017.geo_tline;
 3638738
#prod
qadastre=> select count(*) from qad2017.geo_tline_commune;
 13726560
qadastre=> select count(distinct(geo_tline_commune)) from qad2017.geo_tline_commune;
 13726560
qadastre=> select count(distinct(geo_tline)) from qad2017.geo_tline_commune;
 6593258
qadastre=> select count(*) from qad2017.geo_tline;
 3638738

un filtre manquant en plus qqpart ? Un nettoyage intermédiaire oublié ?

[landryb]

@mdouchin j'ai l'impression que c'est la meme chose pour edigeo, si tu peux confirmer mon intuition..

je vois dans edigeo_formatage_donnees.sql que les tables geo_tpoint_commune et geo_symblim_parcelle (je prends 2 exemples au pif) sont créees en faisant une jointure entre les 2 tables geo correspondantes, avec un WHERE s.annee='[ANNEE]' mais sans filtrage sur le lot, alors que l'info de lot est présente dans la table spatiale.. il faut peut-être rajouter un AND lot='[LOT]' a ces endroits la aussi ?

[landryb]

La ou ca me fait une différence, c'est que d'un coté la base fait 205Go en prod, et 123Go de l'autre sur le dev.. donc si je pouvais arriver a alléger le tout.. ceci dit pour cadastrapp, une fois crée nos vues matérialisées je n'utilise plus que 4 tables spatiales du modèle QGIS donc je pourrais bien TRUNCATE toute les autres :)

[landryb]

Selon ma lecture, il faudrait ptete revoir aussi les tables local00 et local10 qui font un WHERE avec ANNEE sans LOT (mais pas sur pour ces deux), et sinon pour les tables de liaison edigeo:

• geo_subdfisc_parcelle
• geo_numvoie_parcelle
• geo_batiment_parcelle
• geo_borne_parcelle
• geo_croix_parcelle
• geo_symblim_parcelle
• geo_tpoint_commune
• geo_tline_commune
• geo_tsurf_commune

sont a mon avis a controler. Pas besoin d'importer des départements entiers pour tester, juste comparer un dump d'un import d'un lot de 2 communes vs 2 imports distincts de chacune des 2 communes...

[mdouchin]

Merci @landryb pour ces retours. Il faut en effet qu'on consolide cette histoire de lots. Est-ce que tu peux te charger de cette revue et compléter le PR #122 ? ou tu préférerais que je m'en charge ?

[landryb]

Compléter la PR c'est pas le souci, c'est sur la logique de la chose (ie le filtre manquant (?) sur les requetes remplissant ces 9 tables de liaison, et local00/local10) que j'ai besoin de ton retour :)

[MaelREBOUX]

@landryb est-ce que pour toi on est OK sur ça ou pas ?

dans le fichier majic3_formatage_donnees.sql je ne trouve en effet que un seul `lot='[LOT] pour la tble proprio en condition de requête.

Tu as un avis @EtienneRouvin ?

[landryb]

A priori ca a été mergé, cf les derniers commits référencant le ticket de @mdouchin

[MaelREBOUX]

Ici on n'a pas noté de pb avec les lots. @landryb je me permet de fermer suit eà ton dernier commentaire. A rouvrir au besoin. Merci.