Le portail francophone de la géomatique

Bonjour

Dans QGIS, avec l'outil refactor fields (refactoriser les champs), on peut normaliser les champs assez rapidement et je pense que l'on peut sauvegarder ce process via le modeleur sextante, sur la base d'un modèle.

Avec un outil ETL, on peut aussi appliquer des renommages de champs / changements de type.

Enfin, un script SQL Postgre doit permettre de normaliser les champs, en particulier pour partir d'un fichier d'association [noms de champs avant] -> [noms de champs après]

Dans le cadre de mon travail, nous nous sommes posés la question du stockage des millésimes, et de l'enregistrement des changements entre deux millésimes, consécutifs ou pas.

Nous avons décidé, pour des raisons d'ergonomie, de gestion et de performance lors de la visu QGIS (on bosse sur la France entière), de ne pas stocker l'ensemble des millésimes dans une seule table, mais d'avoir une table par communes. Mais il est certain que dans un cadre relationnel (au sens BDD), une table unique serait plus appropriée => On pourrait alors créer des vues par millésime. Nous n'avons pas retenu cette méthode pour autant car la séparation par millésime nous paraissait plus simple et intuitive.

Nous avons choisi d'enregistrer dans une table "changements" tous les changements s'opérant entre deux millésimes : fusion de communes, cission, changement de contour, renommage et avons opté pour une structure de table qui permette, pour chaque code insee et millésime ayant fait l'objet d'une modif', de savoir de quelle nature était cette dernière, et connaître son état "après".

- Ainsi, pour une commune ayant fusionné, on saura si c'est la commune qui a absorbé, ou bien quelle commune l'a absorbée.
- Pour une commune s'étant scindée, on saura, via un tableau {insee1, insee2} en quels insees elle s'est séparée.
- Pour une commune ayant changé de contour, on saura la géométrie qui a changé, celle-ci étant issue d'une différenciation symétrique entre deux millésimes d'une commune.
- Pour une commune renommée, son nouveau nom.
A noter qu'une commune peut avoir été absorbée et avoir changé de contour simultanément.

L'intérêt, c'est de pouvoir exécuter des requêtes rapides permettant de savoir si telle ou telle commune a fait l'objet de changements entre deux millésimes, ou par exemple, savoir entre quelles années une commune a été absorbée par une autre.

Sur le point de la détection, il est évidemment possible de procéder à la comparaison de millésimes via QGIS par une chaîne de traitements puisque QGIS possède toutes les fonctions pour ce faire, mais étant donné que vous disposez déjà d'un serveur Postgre, il paraît plus cohérent d'exécuter ces travaux en SQL dans cette base.

Aussi, à cette fin, je vous livre en PJ le script (perfectible) que j'ai mis au point pour la comparaison de millésimes. Ce n'est ni une fonction, ni du pgscript, donc ça fait un peu bricolage, mais bon, ça nous a calculés le schmilblick. Il faudra que vous l'adaptiez un minimum pour que cela fonctionne chez vous.