search

3liz / QgisCadastrePlugin

A QGIS plugin which helps users to import the french land registry ('cadastre') data into a database. It is meant to ease the use of the data in QGIS by providing search tools and appropriate layer symbology.
GNU General Public License v2.0
61 stars 41 forks source link

Base multidépartementale #199

Closed slaget closed 5 years ago

slaget commented 5 years ago

Bonjour,

Il y a deux communes du département voisin qui sont rattachées au notre de par son appartenance à une communauté de commune "trans-départementale".

Depuis que j'ai ajouté à la base spatialite que j'avais réalisée pour mon département, les deux communes du département voisin (importées en deux sessions: une pour EDIGEO, puis une pour MAJIC), seules ces deux communes s'affichent. Pourtant cette base trans-départementale pèse un poids légèrement supérieur à la base départemental initial: Il est donc probable que les données sont toujours là, mais non lues. Cette manip est-elle possible et si oui, s'agit-il d'un bug ou d'une config à préciser? Merci SRL

MaelREBOUX commented 5 years ago

Bonjour,

je tique sur

importées en deux sessions: une pour EDIGEO, puis une pour MAJIC

Si vous n'avez pas mis le même code de lot pour ces 2 imports cela va considérer que ce sont des données totalement différentes. L'usage et de traiter les EDIGEO et les MAJIC en même temps.

Je n'ai pas suffisamment de pratique pour pouvoir affirmer que c'est bien ou mal mais normalement on importe tout en même temps. @landryb tu en penses quoi ?

Si vous chargez la couche geo_commune ou geo_section directement dans QGIS sans utiliser le plugin : vous retrouvez toutes vos communes ?

slaget commented 5 years ago

Bonjour, Merci pour le coup de main! Je n'avais pas changé le code lot, juste le numéro du département. Si je charge directement les couches dans un projet depuis la base, je n'ai que les communes du second département. A moins que les choses aient changées avec cette version, j'avais complété une base spatialite l'année dernière avec une seconde session d'import, et je n'avais pas eu de disparition des données de la première session. Je viens de relancer la manip,, avec import simultané EDIGEO+MAJIC, mais peut être aurais-je dû ne prendre que quelques communes parce que le traitement est assez long, même pour un petit département comme le mien. Cdlt, SRL

landryb commented 5 years ago

Ca ne pose pas de soucis d'avoir des "lots" différents, cette notion est la surtout pour les imports. Si tu fais un import avec "lot1" puis un import avec "lot2", les données des 2 lots sont "connues"/agrégées par le plugin. Ici j'ai 12 départements, chacun avec un lot différent parce que j'importe en 12 lots.

Par contre si tu fais un import EDIGEO + MAJIC avec "lot1" pour ton département entier, puis un import EDIGEO + MAJIC avec "lot1" pour uniquement ces 2 communes, ton département sera "écrasé"/caché par le 2e import.

Cf la doc (qui pourtant l'explique bien) sur https://github.com/3liz/QgisCadastrePlugin/blob/master/doc/index.md#principe

slaget commented 5 years ago

..."quand le sage montre la Lune, l'idiot regarde le doigt".... c'est tellement logique que le numéro du lot ne soit pas une clef de la concaténation! Question subsidiaire: quid du chargement de EDIGEO puis de MAJIC? Merci SRL

landryb commented 5 years ago

Comme la doc l'explique ;), a priori pas de soucis pour importer EDIGEO et MAJIC séparement pour le même lot, mais personellement j'importe toujours les 2 ensemble.

MaelREBOUX commented 5 years ago

Comme la doc l'explique ;), a priori pas de soucis pour importer EDIGEO et MAJIC séparement pour le même lot, mais personellement j'importe toujours les 2 ensemble.

Merci pour la confirmation

slaget commented 5 years ago

çà n'est pas pour avoir le dernier mot, mais pour faire avancer le machin, je rappelle ma remarque concernant le poids de la BD après écrasement: poids identique à la BD non écrasée (~2.6Go), contre 110Mo pour une base n'étant chargée que des communes du lot "écraseur",

Merci pour cette aide estivale! SRL

MaelREBOUX commented 5 years ago

Est-ce que vous avez tenté un VACUUM sur les tables ?

Pcq une base écrit informatiquement toujours à côté les nouveaux enregistrements et ne libère pas l'espace-disque des anciens enregistrements.

MaelREBOUX commented 5 years ago

http://www.sqlitetutorial.net/sqlite-vacuum/

MaelREBOUX commented 5 years ago

La commande est VACUUM ;tout simplement et s'applique à toute la base / le fichier spatialite.

Ca écrit une nouvelle base à côté. Sur une base de test monocommunale toute neuve j'ai gagné 9 % (98 -> 81 Mo). Donc sur une base plus grosse et réécrite ce doit être plus important

slaget commented 5 years ago

Bonjour,

pour faire simple, je me suis servi de vacuum du DB manager

Merci pour votre aide!

SRL

MaelREBOUX commented 5 years ago

Super !

Quelle taille avant / après ?

slaget commented 5 years ago

De 2,8Go à 136Mo ... c'est mon SI qui like "vacuum"!

MaelREBOUX commented 5 years ago

Super ! Puis-je ferme ce ticket du coup ?

slaget commented 5 years ago

Uoi, et encore merci!

Stéphane R. LAGET Technicien SIG Direction de l'Ingénierie Départementale (DiD) DGA Solidarité Territoriale Téléphone: 04 66 49 66 09 (4221)

----- Le 29 Aoû 19, à 13:08, Maël REBOUX notifications@github.com a écrit :

Super ! Puis-je ferme ce ticket du coup ?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub , or mute the thread .