Le portail francophone de la géomatique

Bonjour,

Votre demande est très intéressante, nous avons le projet d'intégrer l'ensemble des données INSEE dans une base postgis/postgres.
Si vous le souhaitez on peux échanger à ce sujet et pourquoi pas essayer de mutualiser la prestation.
Bien cordialement

Bonjour,

De notre côté, nous avons réalisé cela en créant un véritable entrepôt de données (au sens de l'informatique décisionnelle, c'est-à-dire avec une modélisation en étoile, indépendante des bases de données relationnelles ou des fichiers à plat du site de l'INSEE) dans PostgreSQL / PostGIS et nous pouvons rendre accessible dans une plateforme web toutes ces données de l'INSEE (avec l'antériorité disponible sur le site de l'INSEE, 1962 ou 1968 en général) dans :
- des rapports,
- des tableaux de bord,
- et des hypercubes (vues analytiques multidimensionnelles OLAP).

Nous intégrons la composante géoagraphique / géostatistique dans les rapports et les tableaux de bord, avec l'intégration de librairies de DataViz (comme D3.js par exemple pour des visualisations de flux de personnes dans des diagrammes de Sankey) et les librairies Leaflet ou OpenLayers.

Cela nous permet de produire des tableaux, des graphiques et des cartographies (choroplèthes et symboles proportionnels), à partir d'un entrepôt de données, véritable colonne vertébrale de la plateforme, et de croiser / d'analyser les données de l'INSEE, à toutes les échelles de territoire et selon tous les types de découpage possibles pour la France entière :
- analyse et forage de données (avec les agrégations) pour les découpages administratifs : France / Région / Département / Arrondissement / Canton / Commune (et même infracommunal lorsque la donnée est disponible) ;
- découpages "politiques" : EPCI, SCOT, "Pays", etc.
- découpages statistiques : aires urbaines, bassins de vie, zones d'emploi, unités urbaines, etc.

Je peux envoyer à toutes les personnes intéressées un document PDF (un peu trop volumineux pour l'intégrer en pièce jointe à ce message) qui illustre avec de nombreuses captures d'écran nos travaux actuels.
Et au passage, nous sommes preneurs de toutes les remarques, critiques et conseils :-)

Bien cordialement,

Pascal

Je tire déjà plusieurs enseignement de vos réponses :

1- Je vois que beaucoup de monde s'est intéressé/penché sur le sujet
2- Il y a autant de personnes qu'il y a de méthodes de traiter la donnée
3- Même si en finalité tout finit dans postgres/postgis !

Il est clair qu'une prestation est sûrement le plus simple, mais cela à un coût et nous souhaitons faire l'intégralité de nos traitements en interne.

J'avais en effet pensé à passer par FME pour traiter les données même s'il y a toujours un risque que l'INSEE modifie la structure de ses fichiers ou ne modifie la structure de ses variables.

M. Chevallot, même si votre technique semble des plus abouties je ne suis pas sûr que cette méthode puisse s'appliquer à notre configuration mais votre structure m'intéresse et je suis toujours preneur sur des retours d'expérience, votre PDF volumineux m'intéresse donc :-)

Geo-x

Désolé d'intervenir si tard : "charrette-recensement" oblige...
   Je travaille depuis des années avec les fichiers INSEE France entière, au niveau communal ou infra-communal. Lorsque j'ai essayé de les gérer plus globalement que selon les ensembles diffusés par l'INSEE (populations légales, état-civil, recensements, revenus, etc.) je me suis heurté en particulier à la difficulté de prendre en compte, tout spécialement pour les évolutions, les modifications territoriales résultant des fusions/séparations de communes (plus de deux cents en vingt ans), avec, évidemment, leurs conséquences sur les regroupements communaux. Dans la pratique, si l'on veut préparer les données pour une évolution t1-t2, il faudra regrouper (chiffres, mais aussi polygones) pour t1 les communes qui , entre t1 et t2, se sont unies, et pour t2 celles qui se sont séparées... sachant que certaines (Béthune, par exemple) ont pu entretemps fusionner et se séparer  sans que cela aie des répercussions ni en t1, ni en t2 !
   Bien sûr, je suis intéressé par tout retour d'expérience ou solution(s) sur ce sujet, et je suis à la disposition de qui le souhaite pour partager mes propres expériences. Celles-ci étant d'ailleurs plus tournées vers la cartographie statistique proprement-dite. Et j'espère ne pas trop m'éloigner du sujet des "entrepôts de données" en ajoutant que je complète et finalise la gestion des fichiers en les "branchant" sur une application web de cartographie interactive et dynamique, et surtout automatique, ce qui permet à mon site http://www.cartostat.eu/cartes/TABLEAU_GENERAL.html de compter une vingtaine de milliers de cartes (librement téléchargeables), outre une centaine de milliers sur mon serveur (libres, zip sur demande).

Pas de nouvelles du projet Geopeuple, à l'IGN et à l'EHESS, qui devait produire une base de données des limites administratives des communes sur les 200 dernières années ?

Bonjour,

OSM annonçait dans ces colonnes une mise à jour "en temps réel" des fusions-associations-divorces des communes dans le cadre de sa gestion des limites communales. Je ne sais pas si cela répond à cet observatoire que nos services attendent, mais c'est peut-être à creuser.

Cordialement

Bonjour à tous,
Je m'excuse de remonter ce fil fortement daté, mais il vient à point dans une réflexion que je mène depuis plusieurs mois !

Je cherche comme certains d'entre vous apparemment, à intégrer de nombreuses sources INSEE dans un base regroupée pour faire des extractions (géographiques et non géographiques) de façon automatisée et plus rapide.
Et comme je ne m'y connais que très peu en BDD et surtout encore moins en BI, ETL et tout le jargon qui va avec, j'étais assez désolé et perdu.
Et puis je tombe sur ce fil où je lis notamment cbredel expliquant qu'il met les fichiers INSEE dans PostgreSQL en forme brute puis qu'il les rend exploitable avec un ETL (ici geoKettle). D'où une grande avancée pour moi, et en mettant les mains dans geoKettle, effectivement je commence à comprendre tout l'intérêt d'un tel système, et toute la puissance de l'ETL.
Mais la route va encore être bien longue de mon côté, puisque je pars de bien loin, c'est pourquoi, si en faisant remonter ce fil, je donne envie à certains de partager à nouveau leurs retours, questions, réussites et difficultés, ça me serait super utile !

Merci par avance !

C'est effectivement impressionnant !

Merci pour la proposition, je vous contacte rapidement. Toutefois, si vous avez envie (et la possibilité) de préciser des choses ici sur la façon dont c'est construit/fonctionne par exemple (je pense entre autres à l'intégration des fichiers sources : quels fichiers, quels reformatages nécessaires, etc. mais aussi au temps/compétences nécessaires pour arriver à ce résultat…), je pense que ça pourrait intéressant d'autres membres du forum !

Bonjour,

Je profite de ce sujet pour indiquer que l'APUR a développé un outil qui se base sur l'INSEE et qui permet de faire des choses très sympathiques :

http://www.apur.org/dataviz/portrait_mgp/index.html

Merci Pascal pour cette vue d'ensemble. C'est intéressant en effet !

En revanche, je me questionne sur la logique du schéma en étoile, dans un entrepôt de données, appliqué à une telle liste de données (si vous pouvez répondre publiquement, sinon n'hésitez pas par message électronique).

Prenons une simple source de la population par communes, avec la pop13, la pop08, puis le détail par tranche d'âge. Est-ce que ça veut dire que dans un tel modèle, on privilégiera une table de faits par type d'info (une table de fait avec la pop13, une avec la pop08, et la dimension année viendra faire le lien entre ces 2 tables de faits, tout comme on fera une table de faits par tranche d'âge), ce qui crée un nombre impressionnant de tables, ou bien à l'inverse, une table de faits de population, qu'elle soit de 2008 ou 2013 (ou bien de n'importe quelle autre année), et qu'elle soit celle des 0-14 ans ou celle des 75+, ce qui me semble plus en accord avec l'idée du modèle en étoile, mais génère dans ce cas des tables de millions de lignes j'imagine (puisqu'il faut 36000 communes si on part de la communes * le nombre de dimensions. Par exemple, le fichier excel RP de l'évolution de la pop des communes en 2013 contient près de 4 millions de cellules remplies).

Et dans ce cas d'ailleurs, faut-il partir d'une table complète au niveau géographique le plus faible (type IRIS) puis, par le jeu des dimensions, reconstituer les populations pour les autres niveaux ?
Au regard du travail, ça me semble effectivement démesuré d'imaginer une solution maison pour mes besoins, mais depuis que j'ai mis le doigt dans ce monde tout nouveau pour moi du décisionnel, je trouve ça intellectuellement très stimulant à comprendre.

Message envoyé, merci

Il est vrai que GéoClip a toujours été un outil très attrayant et qui semble bien pensé.