Nous utilisons des cookies pour vous garantir la meilleure expérience sur notre site. Si vous continuez à utiliser ce dernier, nous considèrerons que vous acceptez l'utilisation des cookies. J'ai compris ! ou En savoir plus !.
banniere

Le portail francophone de la géomatique


Toujours pas inscrit ? Mot de passe oublié ?
Nom d'utilisateur    Mot de passe              Toujours pas inscrit ?   Mot de passe oublié ?

Annonce

Suite à un problème technique intervenu entre le 22 et le 23 mars, nous avons du procéder dans la soirée du 25 mars, à la restauration de la base de données du 24 mars (matinée).

En clair, nous avons perdu vos contributions et inscriptions du dimanche 24 et du lundi 25 mars.
Nous vous prions de nous excuser.

#1 Sat 13 May 2017 13:43

julie.marquez
Juste Inscrit !
Date d'inscription: 12 Apr 2017
Messages: 9

QGIS: Restructuration ?

Bonjour,

Voilà... Dans notre base de données PostGis on a des couches (données de références : lacs, communes, pays etc.). Les fichiers shapefiles et DBF proviennent de différentes sources, qui ont donc des attributs différents.

Actuellement les fichiers proviennent de deux sources : une dont les attributs sont assez complets avec des champs d'audit, une autre où il y a juste deux attributs qui ne sont pas significatifs.

Mes questions sont donc, à ce stade :

1) Est-ce que niveau qualité des données, il y a un intérêt à normaliser les tables dans la base de données (pour qu'elles aient toutes une structure complète) ? Et si oui, y a-t-il un moyen d'automatiser cette normalisation lors de l'ajout dans la base en leur donnant par exemple une structure prédéfinie ou c'est complètement inutile ?

2) Une fois les données dans la base, on se retrouve avec des fichiers, par exemple : communes_2015, communes_2016, communes_2017 etc. Est-ce que ce serait pertinent de ne faire qu'une seule table 'communes'  avec une gestion des versions de communes ?

A titre d'exemple, une table commune avec des attributs Effective Date et Current, et à chaque import d'un nouveau shapefile commune, on compare les attributs de la couche et celles de la table et on ajoute les nouvelles communes, et les communes fusionnées passeraient à current = no.

Est-ce que ce serait faisable ? ou viable dans QGis ensuite ?

Sachant qu'on aimerait récupérer des communes pour chaque année, selon ce qu'on veut faire.

Je suis vraiment coincée et si quelqu'un a une piste, un début de solution, une idée je lui en serais vraiment très reconnaissante...

merci beaucoup !!!!!

Dernière modification par julie.marquez (Sat 13 May 2017 13:43)

Hors ligne

 

#2 Tue 16 May 2017 14:01

MathieuR
Membre
Lieu: aix-en-provence
Date d'inscription: 16 Feb 2009
Messages: 1690
Site web

Re: QGIS: Restructuration ?

Bonjour

julie.marquez a écrit:

Bonjour,
1) Est-ce que niveau qualité des données, il y a un intérêt à normaliser les tables dans la base de données (pour qu'elles aient toutes une structure complète) ? Et si oui, y a-t-il un moyen d'automatiser cette normalisation lors de l'ajout dans la base en leur donnant par exemple une structure prédéfinie ou c'est complètement inutile ?


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]

julie.marquez a écrit:

2) Une fois les données dans la base, on se retrouve avec des fichiers, par exemple : communes_2015, communes_2016, communes_2017 etc. Est-ce que ce serait pertinent de ne faire qu'une seule table 'communes'  avec une gestion des versions de communes ?

A titre d'exemple, une table commune avec des attributs Effective Date et Current, et à chaque import d'un nouveau shapefile commune, on compare les attributs de la couche et celles de la table et on ajoute les nouvelles communes, et les communes fusionnées passeraient à current = no.

Est-ce que ce serait faisable ? ou viable dans QGis ensuite ?

Sachant qu'on aimerait récupérer des communes pour chaque année, selon ce qu'on veut faire.

Je suis vraiment coincée et si quelqu'un a une piste, un début de solution, une idée je lui en serais vraiment très reconnaissante...

merci beaucoup !!!!!


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.


Fichier(s) joint(s) :
Pour accéder aux fichiers vous devez vous inscrire.

geodata au cerema et petits billets en géomatique

Hors ligne

 

#3 Thu 18 May 2017 09:38

julie.marquez
Juste Inscrit !
Date d'inscription: 12 Apr 2017
Messages: 9

Re: QGIS: Restructuration ?

Merci beaucoup! Je vais regarder tout ça

Hors ligne

 

Pied de page des forums

Powered by FluxBB