Anecdotes pedroviennes / blog

Réflexions sur les métadonnées géospatiales

Même après avoir décidé de changer d'orientation professionnelle pour différentes raisons, je continue à m'intéresser au domaine de la géomatique et des données géospatiales ; certes je participe moins à l'enrichissement de la base de données libre OpenStreetMap, mais je continue à faire le concierge sur le canal irc #osm-fr, ce qui amène parfois à des discussions que je trouve intéressantes.

Hier, un contributeur sur le canal m'interpellait sur le rôle que pouvaient jouer les métadonnées géospatiales dans le projet. Et après avoir travaillé environ 2 ans et quelques mois sur GeoNetwork, le principal outil de catalogage des métadonnées géospatiales, je suis toujours un peu perplexe.

Les métadonnées géospatiales sont - pour simplifier au maximum, et sans rentrer dans les détails -, une nomenclature sous forme de fichiers XML permettant de caractériser un jeu de données spatiales. Par exemple, admettons que je m'intéresse à recenser les informations sur les terrains de tennis en Bretagne, le producteur de données est normalement tenu en Europe il me semble (du fait de la directive INSPIRE), de caractériser ses relevés le plus précisément possible, afin d'assurer d'une part une recherche facilitée pour les autres acteurs, d'autre part à des fins de tracabilité, à l'aide d'une métadonnée précisant qui a fait quoi, où avec quelle précision, quel matériel, ... Le processus de création de métadonnées peut par ailleurs être douloureux du fait de la complexité (de la richesse ?) du format, ratifié sous la forme de la norme ISO19139. Mais quel intéret pour le projet OpenStreetMap ?

En général, le mappeur lambda pourra être intéressé par qui a fait la saisie d'une donnée dans OSM, éventuellement quand cela a été fait, et tout cela est déjà traduit sous forme de clés/valeurs attachées à la donnée brute. Ainsi, l'auteur est décrit par le tag author=contributeur, éventuellement la source (le cadastre en France nous a autorisé à créer de la donnée à partir de sa source, à condition d'y indiquer clairement le millésime et la source, ce qui est fait logiquement au sein du tag "source=Cadastre DGI ..."). La dessus, pourquoi le contributeur perdrait-il du temps à en plus rédiger 2 kilomètres de XML. La dessus, l'approche OSM peut être considérée comme particulièrement profane, mais aussi novatrice, au fond.

Si l'on peut se permettre de comparer les données d'OpenStreetMap à celles de l'IGN par exemple, cette dernière est tenue légalement de fournir avec ses données commerciales les métadonnées géospatiales qui l'accompagnent (de mémoire, il me semble avoir vu que c'était le cas pour les limites administratives françaises, le produit GeoFLA). De ce que j'en ai vu dans mon précédent emploi, c'est aussi le cas pour d'autres fournisseurs comme Navteq. Un des reproches évoqués par les détracteurs du projet est le manque de tracabilité, sans doute lié à l'absence de métadonnées. Mais on a déjà l'essentiel dans la donnée brute, pourquoi vouloir complexifier ? Surtout qu'aux dernières nouvelles, la base de données du projet dans PostGreSQL pèse déjà pas loin de 1.5 téraoctets, nul besoin de rajouter quelques kilotonnes de XML.

La mouvance "OpenData" visant à intégrer entre autres le citoyen lambda ayant contribué financièrement à la constitution de jeux de données, pousse évidemment à caractériser la donnée afin de la retrouver le plus facilement possible au travers de l'utilisation de catalogues, mais j'ai beau creuser, je trouve que l'emploi d'une norme faisant autorité dans le géospatial n'est pas vraiment applicable dans le cadre d'OSM.

Amusant donc de voir qu'un projet libre peut finalement s'assoir sur les "conventions établies", "imaginer quelquechose d'autre dans son coin" et pourtant se montrer de plus en plus crédible auprès de différents acteurs (Apple, Yahoo, ...). Je ne retrouve malheureusement pas la présentation d'un employé d'ESRI (un des leaders dans le domaine de l'information géographique propriétaire) aux State Of The Map en 2010 intitulée "Why metadata sucks", mais je serais curieux de revisionner l'intervention.

Station météo, systèmes alternatifs et reverse engineering

Le 2 décembre dernier, j'avais 27 ans. S'en suit une petite fête en famille et ma soeur qui m'offre une station météo (en fait l'expression est un peu abusive, mais nous le verrons par la suite) censée être raccordée par USB à un PC. Ce qui est assez fantasque c'est que le terme "PC" implique encore trop souvent pour les constructeurs "quelquechose qui boote avec un drapeau en arrière plan et plein de fenêtres partout".

Bref, il a fallu un peu creuser afin de pouvoir intégrer l'outil au sein de mon appartement.

Analyse géodécisionnelle, épisode #2

Si vous avez suivi l'épisode précédent, vous savez que je m'intéresse (intéressais ?) à l'analyse décisionnelle (ou business intelligence, pour le terme anglophone). J'avais comme quête du graal de représenter les données d'openstreetmap par provenance, en étudiant le champ "source" utilisé parfois pour indiquer d'où proviennent les items géographiques.

En effet, les contributeurs OpenStreetMap ont la possibilité d'utiliser différentes sources afin de peupler la base de données libres de données géographiques. Parmi eux, des fournisseurs d'imageries aériennes (comme Bing Maps depuis que Steve Coast, un des fondateurs du projet, a négocié avec Microsoft un partenariat afin de permettre les contributeurs d'utiliser le fond d'images aérien pour ajouter des données, mais aussi plus anciennement Yahoo!), mais aussi le cadastre français, ou encore (sous certaines conditions) l'IGN, qui fournit une base de données de repères géodésiques, importée il y a quelques temps dans le projet.

En bref, pour reprendre l'histoire précédente, je voulais monter un entrepôt de données permettant de faire l'analyse sur la provenance ayant permis de tracer les différents items géographiques.

Le montage du cube

Afin de permettre de faire un import prenant en compte le tag "source" inclus dans les objets, j'ai là aussi utilisé osm2pgsql. Seulement, il m'a fallu un peu modifier l'application de base, car, osm2pgsql étant prévu pour faire du rendu (c'est d'ailleurs le rendu par défaut sur le site officiel du projet), celui-ci ignore le tag source, et ceci est "hardcodé" directement dans le code C de l'outil. Pour les curieux, vous trouverez en fin de billet le patch (trivial) permettant de prendre en compte ce détail.

L'import s'effectue comme d'habitude, modulo quelques heures étant donné la quantité de données non négligeable que notre pays connait, et nous nous retrouvons alors avec une base classique permettant le rendu, si ce n'est que nous avons une nouvelle colonne dans les tables planet_osm_point, planet_osm_line, planet_osm_roads, et planet_osm_polygon.

C'est à ce moment que le montage du cube prend place. J'ai dans un premier temps effectué quelques requêtes sur cette colone source, afin de savoir comment traiter des données, sur un tag qui ne suit aucune loi "logique" dans la façon dans laquelle il est renseigné. J'ai choisi donc de faire des requêtes du type "Je veux tous les éléments dont la colone source ressemble à Cadastre, ou BING ou Yahoo, sans distinction de majuscules et minuscules ...". J'ai ensuite modifié le script PHP que j'avais partagé précédemment, afin de permettre la transformation de ma base en une base utilisable pour faire les différentes analyses qui m'intéressaient. C'est aussi à ce moment que j'ai compris que cette étape ne s'effectuait pas du tout comme je le pensais. Une première tentative reprenait la précédente méthode, mais je me suis rendu compte que le temps de calcul était bien trop importante. Il m'aurait fallu environ 1 semaine et quelques jours pour y venir à bout.

J'ai donc cherché une autre méthode, pensant que c'était PHP qui était en tort, mais après une nuit passée sur une requête SQL monstrueuse, je ne me suis retrouvé qu'avec un peu plus de 200 000 objets en base. Ce qui était dommage, car encore moins efficace que la première approche, mixant du PHP et des requêtes SQL. Il a fallu alors checher une approche différente, et au troisième essai, je me suis retrouvé avec une méthode quasi-acceptable en terme de temps de calcul.

Cette méthode consistait à prendre la géométrie de chaque département, et de déterminer alors à l'aide d'une requête SQL l'appartenance géographique des objets en base suivant chaque géométrie. Il fallait compter 20 minutes, voire une demi-heure par département pour cela. Et comme j'en avais 92 à passer en revue, cela faisait tomber le temps de calcul à quelques jours (2 jours et quelques heures). Ce fut long, et je dois dire assez frustrant. Sur la quantité de données mises en jeu (une trentaine de gigaoctets), mon entrepôt de données tombait à un "dump SQL" ne pesant que 14 Mo une fois compressé en bzip2 au final. Tant de données à traiter, tant de temps passé à calculer, pour 14 pauvres mégaoctets ... Je trouve cela impressionnant, et me demande encore comment je pourrais optimiser afin de diminuer drastiquement ce temps de calcul.

Un autre problème sur lequel j'ai pu réfléchir était l'utilisation mémoire d'un script PHP rapidement (et sans doute mal) écrit. En effet, comme j'itérais sur tous mes départements en base, et que j'effectuais des insertions assez importantes, le processus en charge de l'insertion en base finissait par saturer la mémoire disponible sur la machine utilisée (qui dispose pourtant de 4 Go de mémoire RAM, et 10 Go de mémoire Swap). Contrairement à ce que je pensais au départ, il ne s'agissait pas d'une fuite au niveau de PHP mais d'une utilisation toujours plus importante de la session vers PostGreSQL qui était ouverte. Le moyen que j'ai trouvé pour contourner ce problème était de fermer la connexion à la base de données à chaque itération, et de la rouvrir.

Au final, vers 17h20 aujourd'hui, cette construction a fini par se terminer, et il était temps de tester ce nouveau cube.

L'exploitation

Là encore, j'ai utilisé l'application développée dans le cadre de mon activité professionnelle, afin de voir ce qui ressortait de ce nouvel entrepôt de données.

Le résultat est graphiquement intéressant, mais aussi étonnant que cela puisse paraître, je trouvais que la chose la plus intéressante à apprécier suite à quelques requêtes multi-dimensionnelles simples, était le tableau donnant la source des données par portions administratives :

Voila, je ne sais pas si tout cela méritait un calcul de 3 jours, mais cela permet de se rendre compte de l'impact de l'autorisation d'utiliser le cadastre sur les autres systèmes mis à disposition. Et cela est sans doute aussi lié à la frénésie qui fait suite à l'import du bâti, et ce, quelque soit la région géographique considérée.

On remarque aussi (certes pas sur cette capture), que certaines régions jouissent d'un plus grand nombre de contributeurs que d'autres. Ainsi, apparemment, la région centre comptabilise environ un peu plus 965 000 objets géographiques, alors qu'on en compte plus de 1 866 000 rien qu'en Île-de-France.

Quelques pistes d'améliorations

Je suis un peu déçu du temps de génération de l'entrepôt de données, j'aurais bien aimé que cela ne prenne pas 3 jours. Mais au fond je n'ai pas eu vraiment le choix : le temps de calcul est évidemment proportionnel au nombre d'éléments qui finira dans la table des faits. Je n'avais pas le choix de prendre tous (ou presque) les éléments disponibles dans les différentes tables, et de calculer leur appartenance géographique à la plus petite entité de ma dimension géographique (au départ les communes, mais j'ai vite laissé tomber ce niveau pour me concentrer sur les départements, vu que de toutes façons mon application ne permet pas en l'état de présenter 23 000 éléments).

Ensuite, il ne faut pas oublier que OpenStreetMap contient des données assez "volatiles", pouvant changer à chaque minute. Ainsi, n'importe quel contributeur lambda détruisant l'intégrité d'une région pouvait être responsable de la disparition d'une région ou d'un département sur mon application. Peut-être que j'aurais pu etre un peu plus téméraire et réparer les limites administratives cassées avant de monter mon entrepôt. Ou alors me baser sur GeoFla (le produit de l'IGN, au format shapefile sur les limites administratives), qui est libre d'utilisation tant que cela reste dans un cadre non commercial. Je l'avais déjà utilisé par le passé, et la qualité du produit aurait amplement suffi dans mon expérimentation.

J'ai pu aussi me demander comment pouvait-on faire de la "BI" en temps réel ? C'est juste impossible dans mon cas. Je ne fait que récupérer les données de la base de données, je n'ai pas accès au système en production sur le projet. Sinon, on aurait pu imaginer des "triggers", qui mettent à jour les données du cube en temps réel à chaque modification effectuée par les contributeurs. C'est sans doute possible, mais techniquement je ne peux pas.

... Et après ?

Je ne sais pas si c'est le fait d'être un peu fatigué ou autre, mais j'ai envie de passer à autre chose. J'ai vu ce que j'avais eu envie de voir sur l'analyse géodécisionnelle, cela m'a appris beaucoup, mais il y a tellement de domaines à creuser que je trouve que le temps passé sur celui-ci est échu. Il y aurait sans doute plein d'axes à creuser, notamment dans une potentielle participation au projet libre olap4j, ou même l'interface sur laquelle j'ai travaillé (et qui je l'espère sera open-sourcée un jour), voire d'utiliser des technologies autres que celles basées sur le langage Java, mais ce soir, j'ai envie de m'intéresser à autre chose.

Pour les curieux

- Le patch pour osm2pgsql
- L'entrepôt de données (dump SQL)
- Le nouveau cube XML
- Le générateur de l'entrepot de données ("should work", modifié après son exécution suite optimisations)
- Le journal de mes aventures, plus détaillé que ce billet, sur mes différentes réflexions

Vers une meilleure compréhension du monde de la (Geo) Business Intelligence

Tout a commencé ...

En avril 2010, un chef de projet dans mon entreprise actuelle arrive avec un sourire radieux :

"Tu vas voir, tu vas travailler sur un projet trèèèèèèèèèèèès intéressant !". CM

L'expérience m'a ainsi montré qu'il était important de se méfier des chefs de projets lorsqu'ils annoncent quelque chose de la sorte (comme on dit en latin, "Timeo danaos et dona ferentes") ;-) ; en effet, je me retrouvais propulsé sur un projet à base de Business Intelligence. Depuis, le projet a bien avancé, le client en est plutot content, mais j'avais l'impression frustrante d'être passé à coté de quelquechose : je n'avais acquis aucune connaissance dans le domaine, je me contentais pour résumer de coder des controlleurs qui renvoyaient du JSON et des graphiques sous forme d'image, et les données servant à alimenter le projet ont été construites par un prestataire canadien extérieur.

J'ai donc décidé d'en savoir un peu plus en montant mon propre "cube" (voir définitions du jargon technique plus loin) ; après tout, pour schématiser à outrance, la Business Intelligence (ou BI), c'est un peu l'étude efficace d'un gros tas de données, et il se trouve que les données d'OpenStreetMap, rien qu'en France représentent déjà un aspect de "gros tas de données" que l'on pourrait agencer pour des études spécifiques. Du moins, j'en avais l'intime conviction, sans trop savoir comment j'allais y arriver, je me suis donc lancé.

Quelques définitions et prérequis

Voila, j'ai déjà commencé à dire des gros mots dans le paragraphe précédent et je m'en excuse, il faut donc repréciser quelques termes (de ce que j'ai pu comprendre) avant de pouvoir continuer mes explications :

- Cube : En Business Intelligence, on cherche à faire grosso-modo des statistiques sur des données, en les croisant d'une telle façon qu'une base de données classique ne permet pas (vraiment) de le faire. En effet, une table dans une base de données a une structure en deux dimensions (lignes / colones). Ici, on cherche à représenter des choses avec des données distinctes, et des dimensions supplémentaires. Cela parait un peu "fumeux", mais afin que vous compreniez, l'exemple le plus répandu se base sur les ventes de produits d'une chaine de grande surface (cherchez "foodmart" ou "geofoodmart" sur google pour plus d'informations). Une vente de produits peut en effet être rattaché (thématiquement) à diverses dimensions décrivant le type de produit, la "classe" du produit ou autres. Les solutions logicielles existantes continuent de stocker ces données dans une base de données classique, mais utilisent en sus un fichier de description en XML (en ce qui concerne la solution que l'on a utilisé dans le cadre de notre projet, on est parti sur GeoMondrian) permettant de faire le lien entre les différentes entités et "monter" cette représentation sous forme de cube (cube, car le nombre de dimensions est supérieur à deux, on sort du schéma classique "ligne / colone").

- Dimensions : Comme expliqué dans le point précédent, notre cube est composé de dimensions, permettant d'obtenir des informations plus précises sur ce que l'on souhaite analyser. Ces dimensions dans notre cas peuvent être de nature différente, thématiques ou spatiales. Cela est facilement imaginable dans notre exemple précédent, imaginez par exemple d'étudier les ventes de soda sur l'Ile-de-France uniquement, pour une période de temps donnée. Les dimensions sont décomposées sous forme de hiérarchies, elles-mêmes composées de différents niveaux (on peut par exemple avoir une dimension spatiale, auquel cas il est facile d'imaginer une hiérarchie dont les niveaux seraient communes / départements / régions, ou encore une dimension thématique plus "temporelle" avec une hiérarchie en mois / année, et une autre hiérarchie par mois / trimestre /année). Bref, le principe est de décomposer les données à analyser sous forme d'entités.

- Mesure : On peut considérer la mesure comme la pièce maitresse de notre cube. C'est, en gros, ce que l'on souhaite représenter. Ces informations sont stockées dans ce qu'on appelle une "table des faits".

- MDX : Une sorte de langage permettant d'effectuer des requêtes sur un cube ; c'est en 2 mots le "SQL de la BI".

- ETL : "Extract Transform and Load". Peut désigner un logiciel quelconque facilitant la mise en oeuvre de notre entrepôt de données (voir explications qui suit sur la structuration des données propres à une étude "BI"). J'ai toujours été rétissant aux clickodromes, et chez moi cette étape a été réalisée à l'aide de scripts PHP écrits à la main (ou bien dans le cas de mon premier cube, à l'aide d'un simple fichier SQL). J'ai ainsi le sentiment d'une meilleure appréciation de ce qui se passe vraiment à la construction.

- Table des faits : Table contenant les données que l'on souhaite ... "évaluer". Je n'ai malheureusement pas de définition plus précise à donner, tout du moins pour le moment. Pour reprendre l'exemple précédent, la vente d'un produit ira dans cette table. Chose toutefois notable : La table des faits contient tout le matériel de clés étrangères permettant de faire le lien avec les tables décrivant les différentes dimensions (je me suis basé sur cette assertion dans le cadre de mon projet personnel).

Cette structuration des données nécessite en général de repenser complètement son système de gestion de bases de données, afin de permettre un accès correct à l'information. Pour les adeptes des bases de données, on peut parler je pense de dénormalisation. Dans un schéma classique, il est évident que les données ne sont pas présentées comme attendu pour de l'analyse ; pour poursuivre l'exemple précédent, une chaine de grandes surfaces ne peut décemment pas stocker ses données dans un but d'analyse "BI" directement, sous peine de se faire trucider par le premier expert de base de données venu. Il faut donc monter un entrepôt de données (un datawarehouse dans la langue de shakespeare), indépendant du système "source", qui permettra ensuite l'analyse (les analyses) attendue.

Premier essai

J'ai utilisé l'outil incontournable de tout bidouilleur de données osm, Osm2Pgsql afin de charger les données francaises d'OpenStreetMap dans une base de données PostGreSQL / PostGis. Les habitués savent donc qu'on se retrouve ensuite avec des tables préfixées "planet_osm_*", selon le type d'objet géographique (planet_osm_point pour les points, planet_osm_polygon pour les polygones). D'autres tables sont créées, mais nous nous intéresserons pour le moment qu'à celles-ci.

La question évidente qui arrive suite à cela est la suivante "J'ai quelques gigaoctets de données en base maintenant, qu'est ce que je peux représenter avec ?".

J'ai donc recherché assez longuement sur cette question de "comment représenter quoi ?", mais en fait, en commençant d'abord par définir la structuration des tables définissant nos différentes dimensions, et en exprimant nos "mesures", on finit par imaginer le cube tel qu'il doit (devrait ?) être. Je reste volontairement hypothétique, car j'ai encore moi-même du mal à comprendre ce que j'avance. Finalement, j'ai opté pour la volonté de représenter ceci :

Un tag assez répandu sur OpenStreetMap est le tag "amenity". Ce dernier permet de géolocaliser sous forme de points ou de polygones un médecin, un bar, un hopital, une maison de retraite, un café, un distributeur automatique de billets ... On pourrait donc avoir un cube construit sur les limites administratives francaises donnant la densité de ce tag par emplacement géographique (communes, départements, régions). On distingue alors assez aisément les différents items :

- Dimension spatiale, avec une hiérarchie (communes, départements, régions). Pour des raisons de commodité, j'ai d'abord limité cette dimension / hiérarchie, sur un seul niveau : département.

- Dimension thématique : le type d'amenity (en langage OSM, la valeur du tag "amenity"). On y retrouvera donc "hospital", "bar", "cafe" ... J'ai là aussi limité aux tags dont la valeur apparaissait au moins dix fois en base (inutile par exemple de représenter les fautes d'orthographe des contributeurs).

- Mesure : Le décompte de ces "amenities", suivant les différentes entités définies dans les dimensions. En d'autre terme la densité.

Ce qui donne ainsi la table des faits ("la quête du graal" dans la construction d'un cube) suivante :

osm=# \d osmbi
           Table « public.osmbi »
      Colonne      |  Type   | Modificateurs 
-------------------+---------+---------------
 departement_osmid | integer | 
 osm_amenity_id    | integer | 
 count             | integer | 

Pour infos, ci-après la structuration des tables représentant les deux dimensions :

osm=# \d osmbi_amenity
                                         Table « public.osmbi_amenity »
   Colonne    |          Type          |                             Modificateurs                              
--------------+------------------------+------------------------------------------------------------------------
 amenity_id   | integer                | non NULL Par défaut, nextval('osmbi_amenity_amenity_id_seq'::regclass)
 amenity_type | character varying(512) |

osm=# \d osmbi_departement 
 Table « public.osmbi_departement »
 Colonne |   Type   | Modificateurs 
---------+----------+---------------
 osm_id  | integer  | 
 name    | text     | 
 way     | geometry | 

Nous avons à peu près tout. Je vous passe les détails sur la construction et le remplissage du cube, cela risquerait d'alourdir le billet inutilement. Pour les curieux, allez voir les liens en fin de billet.

Une fois l'étape d'extraction / chargement des données (voir la définition de ETL plus haut) dans ces tables effectuée, il ne restait plus qu'à rédiger notre fichier XML, qui sera lu par le logiciel GeoMondrian, et qui nous permettra de faire des requêtes MDX.

J'ai ensuite repompé sans vergogne le code de l'applicatif que nous avons développé pour notre client hispanique, et j'ai tenté de le brancher sur mon nouveau cube. Suite à quelques remaniements (il s'agissait d'un prototype, donc il n'était pas parfait, et quand bien même cela aurait été un projet pour une application "de production", il ne l'aurait sans doute pas été non plus), j'ai pu effectuer des requêtes du type "Je veux la proportion de bars, boites de nuit et cafés en Isère et en Savoie". Graphiquement, cela donne le résultat suivant :

Et ensuite ?

Trouvant ce premier cube trop simpliste, je me suis lancé, cette fois-ci à grand renfort d'un script PHP (on dira ce que l'on voudra, mais lorsque je souhaite être expressif dans un langage et passer le moins de temps possible pour arriver à mes fins, il s'agit là encore mon langage de prédilection) dans la construction d'un nouveau cube, cette fois-ci contenant toutes les communes francaises disponibles en base, les départements (que j'avais déjà), et les régions. J'ai aussi ajouté une nouvelle dimension thématique décrivant le type d'objet spatial (qu'il s'agisse d'un point ou d'un polygône) dans OSM.

Malheureusement, au branchement de mon cube dans l'application, la sentence ne s'est pas faite attendre trop longtemps :

        /webbi/getcubeproperties
        java.lang.OutOfMemoryError: Java heap space

J'ai sans doute eu les yeux plus gros que le ventre. Mes prochaines expérimentations à prévoir la dessus sera d'oublier les 23 000 communes que j'ai en base pour le moment, pour me focaliser sur les quelques départements et régions disponibles. De toute facon, dans l'affirmative où cela serait passé, cela signifie que l'on se serait retrouvé dans son navigateur Web à avoir la possibilité de sélectionner des éléments parmi ces 23 000. Inutile d'espérer pouvoir le faire décemment, même dans le meilleur navigateur au monde.

En conclusion ...

Cela a été une investigation intéressante, et m'a donné pas mal de recul sur le sujet. C'est un peu dommage de ne pas avoir réfléchi à tout le domaine avant, mais peut-être était-il nécessaire d'attendre d'avoir un certain recul avant d'imaginer se lancer dans l'aventure. Je garde sous le coude un autre projet qui intéressera potentiellement des fournisseurs de données à OSM : Monter un cube sur le tag source des objets en base. Mais cela va demander une modification du code de Osm2pgsql, ce dernier étant prévu en effet pour le rendu, il ignore (et c'est "hardcodé") le tag source qui sera intéressant pour notre analyse.

Pour les curieux

- Le journal plus détaillé de ce périple, notant mes diverses "random thoughts"

- Le premier cube en XML

- Les quelques requêtes permettant de monter le premier cube

Attention, certaines requêtes peuvent prendre quelques heures, et cela donne juste l'idée générale, n'espérez pas avoir un entrepôt de données correct juste en le jouant. Désolé, j'ai un peu perdu l'historique de la démarche de mon premier cube, lorsque je me suis mis à travailler sur une version 2.

Autre détail, je n'ai déontologiquement pas le droit de fournir le code de l'applicatif web ayant permis d'effectuer la capture d'écran présentée dans ce billet. Désolé pour cela. La solution étant toutefois basée sur GeoMondrian, vous devriez être en mesure de cabler le cube sur une interface Olap4J.

Edit de début de nuit

J'ai retravaillé un peu ma version 2 du cube, et j'ai compris certaines choses en terme de définition de cube telle qu'attendue par les outils utilisés. Quelques screenshots sont disponibles ici. Pour le coup, je crois que j'ai à peu près tous les éléments en main (même si ma connaissance du domaine me parait encore un peu trop sporadique en toute sincérité) pour monter des cubes de données sur tout et n'importe quoi. Mission accomplie !

Edit 2, vers 1h du matin

Je dois être un peu insomniaque, et du coup, je fournis les sources pour monter la "version 2" de mon cube :

- Script PHP permettant de monter le cubev2 (Il met environ 3 heures à s'éxécuter, et si vous voulez "dénormaliser" (?) afin de se concentrer sur juste les niveaux départements et régions, n'oubliez pas de jouer les 2 dernières requetes SQL en commentaire dans la source.

- La définition du cube en XML

Les dérives de l'addiction à OpenStreetMap

L'histoire se passe entre Thiviers et Saint-Jean de Côle, en voiture avec ma soeur qui n'en peut presque plus de la route Grenoble / Quelque part perdu dans le Sud-Ouest, sur laquelle nous nous trouvons depuis 6 bonnes heures dans le but d'assister à un mariage de famille. Puis le portable sonne, mon père qui s'inquiète :

Papa : - Pierre ? Vous êtes où la ? il est 16h10, la cérémonie commence à 16h00 ; c'est bien à Saint-Jean-de-Côle hein ... Et n'oublie pas ton alto, je te rappelle que tu es censé jouer à la messe ...

Moi : - On est au courant, on vient de se changer avec Claire, on arrive d'ici 10 minutes, je suis au courant pour l'alto, et puis quand bien même je l'aurais oublié, on va pas faire demi tour pour aller le chercher à Grenoble ... Quant aux partitions, désolé, mais j'ai vraiment pas eu le temps de les travailler alors je vais un peu déchiffrer / réinventer Mozart pendant la messe si tu n'y vois pas d'inconvénient ... Non, la faute à mes tortionnaires de patrons, on dira (ndR : il fallait bien une excuse presque bidon) ... Mais sinon, t'es chiant : en me téléphonant, tu as encore fait bugger ma trace GPS, comment vais-je pouvoir faire avancer le monde des données géographiques libres ; tu as pensé aux conséquences de ton acte, hein ?

Papa : - .........

Bref, la morale de cette histoire est certainement que la vie est une question de priorités (ou tout simplement qu'il faut que j'investisse dans un vrai bon GPS datalogger). Pour la petite histoire, ayant eu des bons retours de mon déchiffrage altistique, j'ose imaginer que ca a plu. Ou alors j'étais peut-être entouré d'hypocrites ; la prochaine fois je tacherai de soigner tout de même un peu plus quand on me demandera de jouer de l'alto à une cérémonie, parce que la, cela faisait plus figurant que concertiste. Et les traces GPS, dans tout ça ? il faut encore que je jette un coup d'oeil; mais j'ai un import massif et breton sur le feu.

(PS : Oui, il ne se passe pas grand chose par ici, il m'arrive d'avoir envie de dépoussiérer, mais bon ; pour ceux qui se demandent ce que je deviens, ca va, je suis vivant, toujours Chambérien ; depuis la dernière fois - i.e. depuis le dernier billet -, pas grand chose de neuf, j'ai suspendu mon compte facebook en attente de mieux, donc si vous voulez me contacter, il faudra dorénavant choisir un autre moyen)

Bonne soirée !

Les sysadmins, ces héros des temps modernes

Je sais, cela fait un moment que je n'ai pas écrit par ici. Sans vouloir me justifier auprès de mes potentiels lecteurs, sachez que c'est avant tout dû à un manque profond de motivation, de réflexions diverses sur le fait que je pouvais éventuellement perdre mon temps à rédiger tout ca, ou encore le droit à l'oubli et les traces que l'on peut laisser sur internet. Et puis au fond, au point où j'en suis, peut-être qu'un jour mon employeur me reprochera de trouver des photos de moi sur un réseau social bien connu, devant un gigantesque plat de gauffres et avec un sourire provocateur. Bien, de toutes façons, ce n'est pas de cela qu'il s'agit.

Tout d'abord, comme vous avez pu l'apprendre si vous me cotoyez ou si vous êtes lecteur assidu, oui, je n'habite plus Aix-en-Provence, et oui, tout va bien, le boulot tout ça, l'alto est en réparation, donc pour les loisirs musicaux, il va falloir patienter quelques jours. Ce n'est pas de tout cela non plus qu'il s'agit. Du moins, pas directement.

Mon nouveau boulot, comme j'avais eu l'occasion de l'expliquer à mes supérieurs, me plait dans le sens où l'on touche à un certain nombre de technologies - certes en rapport avec le web - mais il serait réducteur de penser que notre domaine d'activité se limite à la création de sites web, domaine d'activité de très nombreuses agences, et comme vous pouvez le constater par ici, je n'ai pas les talents d'artistes nécessaires pour justifier un emploi dans ce domaine. Le web-SIG réclame tout de même des compétences plus poussée que l'écriture de scripts PHP que l'on envoie sur un serveur FTP. Bref, la dessus, j'ai dû manger du python, du Java, et pléthore de langages divers et variés, et bien évidemment tout ce qui a trait au Web. Mais venons-en au byzutage qui a en quelque sorte joué le rôle de cadence parfaite de ma période d'essai.

J'ai en effet eu deux jours en début de semaine allouée à la mise en production (pas encore de lancement officiel) du projet sur lequel j'ai travaillé en majorité depuis mon arrivée. Et je me suis senti bien seul. Et c'était monstrueusement flippant. Dans l'idéal, on m'aurait donné l'administration d'un serveur tout neuf avec des noms de domaines pré-réglés pour configurer un serveur Web rapidement, modulo l'installation des différentes briques logicielles, tout aurait été réglé en une demi-journée voire moins. Mais non, c'eût été trop facile :-) Il a donc fallu traiter avec un serveur sur lequel tournait déjà 2 sites en production, et l'installation hâtive d'un python2.5 a complètement fait tomber l'un des sites. Indisponibilité pendant une nuit. Et j'en étais seul responsable. Je connaissais pourtant le système d'exploitation utilisé, j'avais pourtant pris le maximum de précautions. Et malgré cela, ... Bref, j'ai appris que le métier d'administrateur système était loin d'être aussi trivial que d'être un linuxien de tous les jours. Ca ne s'invente pas, il faut être un peu super-héros, ou James Bond des systèmes d'informations, mais au lieu de draguer des blondasses niaiseuses au service du KGB et conduire des Aston Martin, il nous faut avec nos seules mains et une bonne bobine de scotch numérique recoller les morceaux, avant que le client ne remarque quelquechose et ne déclenche une guerre nucléaire sous prétexte que l'on a joué à l'apprenti sorcier avec son serveur.

Donc après avoir passé une très mauvaise nuit, se réveiller à 4 heures du matin, ouvrir un oeil, et se dire "où j'en suis déjà ? ah oui, la nuit, pour le site du client que j'ai atomisé, on verra demain à tête reposée, cela ne sert à rien de stresser maintenant ...", avec l'aide de nos super-héros suisses (comprendre l'équipe de sysadmins), j'ai rapidement pu réparer et rétablir le service. S'en est suivi une journée à perdre une bataille contre des dépendances logicielles incompréhensibles, puis en rentrant dans le bus, j'ai eu une petite révélation. Arrivé chez moi, je me reconnecte, et en moins de 40 minutes, j'arrive à peu près à finaliser cette installation qui trainaît depuis trop longtemps.

Je passerai sur les aspects techniques (parce qu'on s'en fout au fond), mais finalement, même si j'ai "failli mourir" d'excès de stress, j'ai bien aimé cette expérience, cela m'a appris des choses - évidemment techniquement - sur la façon dont un administrateur peut avoir l'esprit tordu en terme de configuration serveur, mais aussi sur la maîtrise de soi, savoir relativiser sur les problêmes (au fond, tout le monde s'en foutait de son instance de django qui sert à répertorier des observations de feuilles qui tombent en automne, la preuve, l'indisponibilité est passée inaperçue), et puis j'ai signé "pour le meilleur et pour le pire" après tout.

Je me demande quelle sera la prochaine épreuve dans ce fort boyart professionnel, mais ce qu'il y a de sûr, c'est que je ne manquerai pas de l'aborder sous un angle différent dorénavant (en espérant que je serais moins trouillard et moins stressé que sur l'expérience dont il est question ici). Et puis au fond, le métier d'ingénieur, c'est savoir régler des problèmes (contrairement aux mauvaises langues qui diraient que ca consiste à tchatter sur gtalk à longueur de journée). Et je suis maintenant sûr d'une chose, je veux bien faire "un peu de sysadmin", mais jamais à temps plein.

Bientôt un an ...

Cela va bientôt faire un an que j'ai obtenu mon diplôme d'ingénieur, et un petit peu plus que j'ai commencé ma vie professionnelle à proprement parler. Donc c'est le moment d'être un peu nostalgique sans doute. Les gens "décalés" de ma promotion et ceux de la suivante vont donc bientôt recevoir à leur tour leur "bout de papier" attestant de leur capacité à intégrer le monde du travail.

Bref, cet instant visant à sceller les quelques années d'études passées à Belfort, je n'ai pas pu le vivre l'an dernier, non sans quelques regrets sans doute ; mais au fond, à quoi bon toute cette symbolique ? Est-ce que tout cela a un sens et nécessite de déployer des "vidéoprojecteurs 20 000 lumens Full HD" ? (non, cette information n'est pas tirée d'un de mes contacts facebook travaillant à la communication de mon école ; de surcroit, lorsque l'on apprend que la location de ces bestioles a couté 10 000 euros à l'école, je suis bien content que la force des choses m'ait poussé à ne pas cautionner ce genre d'initiatives l'an dernier, en séchant allégrement ma remise des diplomes pour cause de soucis ferroviaire ; je sais pas, ne pourrait-on pas "régler le problème de la faim dans le monde" en réinjectant les sous ailleurs ?). Est-ce réellement nécessaire toute cette mise en scène quasi-théatrale, petits fours et champagne, habillés en pingouins, et discours de grands pontes de la région Belfortaine opus 42 en crise économique dièse majeur ? Quoiqu'il en soit et en retrospective, j'ai bien aimé mon gala chaotique de l'an dernier. Heureusement que je pouvais compter sur vb, Bertrand et Barbu pour lui donner un sens inattendu ; mais plaisant, au vu du flou artistique mélant amertume et catastrophes avec lesquelles tout cela avait commencé.

Bertrand, tu me faisais remarquer à juste titre que je désertais un peu ce blog ; alors ce billet est pour toi, à défaut de venir au Congo t'organiser ta remise des diplômes entre deux bananiers de l'ambassade de France, tu as toute mes félicitations, pour les bons moments qu'on a pu passer en ta compagnie durant ces 5 ans et plus (et les bons moments à venir), je te donne même le mineur de la jovialité à l'unanimité ! (Et bien entendu, bravo à tous les autres diplomés cette année, cela va de soi, et amusez-vous bien).