Le portail francophone de la géomatique

Bonjour Aline,

Je suis intéressé par ta question :

Dans ma ville on est en phase avec cette problématique pour les données Observatoire social/Insee/Logement social et plus si affinités...

On s'oriente clairement sur la construction d'un entrepôt de données à l'usage du SI traditionnel et du SIG (le tout sur Oracle), avec une chaîne d'intégration (Talend Open Source) et des outils de restitution :

- portail décisionnel avec du géodécisionnel, i.e. simplement avec une interface cartographie
- utilisation de Geomédia, Mapinfo ou autre pour l'analyse cartographique à façon.

Pour s'étendre un peu sur la partie INSEE, le nouveau mode de recensement par échantillonnage tournant (8 % par an sur 5 ans je crois) induit des intervalles de confiance sur le variables et les classes et nécessite un nouveau mode de représentation cartographique notamment (Krigeage ???) pour s'affranchir de ces intervalles de confiance.

Merci jean-michel et françois pour ces premiers apports,

De mon côté la problématique est :
-déployer un outil relativement simple sans maintenance interne parce qu'il n'y a personne qui est clairement responsable de l'observatoire à part moi pour ma partie habitat
-sortir de l'organisation access parce que je suis la seule à maîtriser cet outil
-trouver un moyen  de mettre à jour les données chaque année sachant que ça prend du temps et qu'elles évoluent vite ..
-et intégrer ça dans un outil qui permette de travailler les données un peu "dans tous les sens"

Pour ce qui concerne les intervalles de confiance je suis bien d'accord, c'est pourquoi par exemple je milite pour qu'on ne diffuse pas n'importe quelle données (par exemple ce qui concerne les migrations alternantes est difficile à utiliser et bien interpréter); Néanmoins avant c'était déjà des statistiques et on avait un peu oublié cette problématiques des intervalles de confiance ....

Jean-Michel, par rapport à ton expérience et aux questions que je me pose :
-comment organise tu tes donnée stat ? par théme ? quels schémas de données ? comment s'organisent les mises à jour ? comment a été définie la liste de variable ?

je m'arrête là pour aujourd'hui ! les questions sont tellement nombreuses

AlineC

Bonjour,

Je me permets ici un avis d'informaticien. La principale erreur à mon sens et de choisir une technologie. Qu'elle soit ACCESS, MySQL ou autre elle est par essence dans le comment faire et non dans le quoi faire. Ce qui est l'antithèse de la philosophie objet qui qu'on le veuille ou non est (devrait être ) l'essence de la philosophie de la structuration de la partie "données" des SIG.
La donnée stat est par essence une donnée calculée, ou pour le moins un agrégat, donc un résultat de requête, de données brutes.
Qui peut envisager de connaître l'évolution des technologies de manipulation de données ? Personne.
Comme en mathématiques il s'agit de déterminer le PPCM de la donnée. Ce PPCM est le fichier texte, il peut être structuré selon une forme un peu évoluée comme XML, mais la certitude est qu'il s'agit d'un fichier texte lisible par n'importe quel programme ou langage de programmation ce maintenant ou dans 20 ans.
Donc l'idée est de stocker la donnée brute dans un format texte, selon une classification comme celle proposée par JM. (notez que la donnée géographique est stockée sous forme texte comme pour mif/mid ou le standard OGC WKT). Sachant qu'actuellement (et c'est la philo d'XML) il est bon d'intégrer le shéma de donnée de façon lisible, mais un modèle UML annexé va bien aussi.
Reste à écrire en fonction des technologies et de leur évolution des Interfaces d'intégration dans les SGBD ou SIG utilisés.

Certes ceci peut paraître à certain un peu HS voir compliqué mais ceci a l'avantage d'être une solution pérenne. Mais si je reprends la question initiale d'Aline :

Que cherche t'elle si ce n'est un format d'échange ? Et un format d'échange n'est jamais contraint par l'outil d'intégration.