Évolutions du plugin

[mdouchin]

Un ticket pour lister certaines choses à améliorer. On ouvrira certaines demandes pour les points validés

Généralité

• Maintien du support Spatialite ?
• Support de PostGIS 3 ?
• Support du GeoPackage ?
• Support de QGIS 3.10 à 3.16
• Suppression du support QGIS 2.18

Plugin

• Ne plus utiliser les modules du gestionnaire de base de données pour faire les imports
• Ajouter les outils d'intégration continue comme sur les autres plugins de 3liz
• Déplacer la documentation de l'autre dépôt https://github.com/3liz/QgisCadastrePlugin/blob/master/doc/index.md dans ce dépôt
• Faire tourner flake8 !
• Refactorisation du code
• Enregistrer le log

Import des données DGFiP

• modifier l'UI: clarifier les appellations, basculer tout en haut le lot,
• simplifier la notion des dates: pourquoi garder Version du format et Année, alors qu'on utilise toujours les mêmes -> utiliser le vocable Millésime
• séparer les scripts MAJIC par millésime : structure SQL, formatage ET nomenclature.
• ajouter une table d'historique d'import, avec les lots, et un outil pour supprimer les données d'un lot: date d'import, lot, nombre de communes, sections, parcelles. Y ajouter le millésime des données EDIGEO, et un autre champ pour le millésime MAJIC (métadonnées)
• récupérer automatiquement la projection des données via lecture d'un fichier .GEO
• option pour créer les unités foncières ou pas (couteux)
• permettre de modifier le nom des fichiers MAJIC directement dans l'interface d'import
• ouvrir le dossier en lisant le chemin déjà enregistré si présent
• auditer les données à ne pas créer
• proposer un import light, pas exemple sans création des tables de liaison: geo_xxxxxx_parcelle et geo_xxxxxx_commune
• ajouter le code DGFIP de la commune dans les tables spatiales (geo_batiment, etc.)
• permettre de refaire un import sans avoir besoin de réimporter les fichiers MAJIC et/ou les EDIGEO, cad relancer directement les étapes "Formatage des données" (pour faciliter les tests de performance, les debugs, etc.). Ajouter des cases pour activer/désactiver: 1/ import edigeo 2/ import majic 3/ formatage edigeo 4/ formatage majic 5/ nettoyage des donnéees edigeo 6/ nettoyage des fichiers MAJIC 7/ ajout des clés étrangères
• Voir si suppression des indexes avant réimport et recréation des indexes une fois l'import réalisé pour accélérer l'import
• Faire une revue des contraintes d'unicités
• basculer l'import comme un algorithme processing
• atomiser les étapes d'import pour pouvoir relancer les étapes, notamment sur le formatage des données. Log du début et de la fin d'une étape, par ex: geo_parcelle: début et geo_parcelle: fin (30 s). Définir chaque étape avec un code, un titre
• afficher toujours le code d'erreur de PostgreSQL ou SQLite

Exploitation des données traitées

• Adapter les styles pour QGIS 3
• Supprimer l'outil pour ajouter une couche via requête (le gestionnaire de bdd le fait très bien) ou proposer un système via le QGIS resource plugin pour partager les requêtes
• Basculer vers le code vers un algorithme du menu Traitement

Barre d'outil

Identifier une parcelle

Exporter la vue

Le panneau de recherche

Recherche plein texte

• Utiliser la barre de QGIS CTRL+K

[Gustry]

Le travail sur la CI a été amorcé :

• déplacement dans un sous-répertoire cadastre
• Flake : beaucoup sont désactivés pour le moment :( Je ne coche pas pour le moment la coche ci-dessus.
• GitHub Pages : http://3liz.github.io/QgisCadastrePlugin/
• qgis-plugin-ci, Travis ...
• Premier tag quasi OK 1.9.0

[Gustry]

J'ajoute aussi un

• Support de PostGIS 3 ? (en gros les SELECT AddGeometryColumn) ?

[MaelREBOUX]

Oui : j'ai modifié un peu le post initial en conséquence pour voir toutes ces questions de support / versions / formats.

[Gustry]

Il faut aussi ajouter les modifications du Ministère de la Transition Écologique et Solidaire.
Peut-être regarder en détail la liste des modifications et écrire la liste à puce des améliorations ?
GitHub diff entre 1.7.0 et la branche mdd : https://github.com/3liz/QgisCadastrePlugin/compare/1.7.0..mdd

[benjaminsaut]

Bonjour, pas sûr de poster au bon endroit mais je remarque que l'info "surface bâtie" d'une parcelle peut porter à confusion. Il s'agit visiblement d'un calcul de l'emprise au sol du bâti, et non de la surface totale du bâti qui peut être supérieure et s'appréhende via les surfaces des locaux rattachés à la parcelle. Donc plusieurs pistes : renommer "surface bâtie" en "surface emprise bâti" ; et potentiellement nouveau champ "somme surface bâti" qui additionne les surfaces des locaux rattachés.

[Gustry]

Bonjour, pouvez-vous faire un nouveau ticket, en effet, sinon la demande va se perdre. En haut de cette page "New issue". Merci

[benjaminsaut]

Bonjour, pouvez-vous faire un nouveau ticket, en effet, sinon la demande va se perdre. En haut de cette page "New issue". Merci

c'est fait, merci à vous !