Closed landryb closed 6 years ago
Après avoir regardé un peu plus en détails, j'ai l'impression que c'est aussi lié a des imports incrémentaux dans mon schéma dans la BDD qadastre
- je vais refaire un test à partir d'un schema vierge, mais il n'empeche que quelquechose cloche qqpart dans cette vue..
J'ai maintenant l'impression que c'est un pb lors de l'import dans le modele QGIS lui-meme, cf 3liz/QgisCadastrePlugin#121
Avoir en tête ma question sur les lots, leur usage et leur implémentation dans cadastrapp -> #333
Techniquement, c'était un bug de l'import dans le modèle QGIS, donc je ferme celui-ci.
Je suis en train de passer mon instance de cadastrapp de 4 à 12 départements, et le passage a l'échelle est... compliqué. Chaque département est importé dans un 'lot' indépendant (ie le lot pour le modele qadastre de QGIS)
Techniquement, la taille de majic/edigeo est multipliée par 3/4, mais certaines vues/tables explosent beaucoup plus.
Je gratte un peu les tailles de tables/vues, et certaines choses sont incohérentes:
C'est impossible de passer de 4 a 12 départements et de multiplier la taille totalle par ~12.
Et j'ai bien l'impression que pour certaines vues (je n'ai regardé que proprietebatie pour l'instant) il y'a autant de doublons que de 'lots' qgis:
Techniquement, pour un objet 'proprietebatie' du 03 je ne devrais avoir qu'une entrée.. et les X entrées sont identiques dans les 2 cas.
Autant dire qu'avec des tailles pareilles, postgres ne suit pas, et il est impossible de requêter des batiments...
J'ai regardé les tables
uf_parcelle
,parcelle
,proprietaire
et dans ces cas la taille est multipliée par ~3/4 donc cette croissance a l'air plus "logique". Il faudrait certainement refaire une passe sur toutes les tables/vues materialisées en faisant des tests avec plusieurs lots/departements..