3/13/2017

Tableau 10.2 : Les fichiers géospatiaux

Hello World [Map] !!

Tableau 10.2 est arrivé il y a environ 2 semaines et avec cette nouvelle version des fonctionnalités toutes neuves font leur apparition ! Parmi toutes celles qu'on retrouve sur ce magnifique article web, mon cœur a déclaré sa flamme, belle et pure, à l'intégration des fichiers géospatiaux. Eh oui, Mesdames, Mesdemoiselles, Messieurs, Tableau lit ENFIN les fichiers géospatiaux et comprend, a fortioti, la géométrie !! Si c'est pas un progrès de "déglingos" ça ?!


Vous imaginez tout ce qu'il est possible de faire en terme de cartographie dorénavant ? On n'a pas les communes de France ? PAF, le shapefile provenant d'Open Street Map. On veut présenter les tracés des lignes de chemins de fers et c'est pénible de les redessiner en "custom polygons" ? BIM, un géojson qui va bien issue d'Open Street Map ou du portail Open Data de la SNCF ! On est sportif et on a une envie de faire une visualisation "Quantified Myself" ? CRAC, le fichier kml de mes itinéraires de footing... Ah la la, que c'est beau, mais que c'est BEAU !! A croire que Tableau cherche à nous simplifier la vie ! Bon ce ne sont pas les idées qui manquent mais concrètement, comment ça marche ? Et, est-ce que ça fonctionne bien ? C'est ce que nous allons essayer de voir ensemble, durant les 5 prochaines minutes de lecture de cet extraordinaire billet de blog.

Alors, comment que ça marche donc ?


Bon. Soyons honnête, pour tester tout ça on s'est dit : "Testons tout ça en utilisant un shapefile." ça paraît dingue mais ça s'est passé comme ça. Du coup, nous sommes allé gentiment sur le portail Open Data du gouvernement français (http://www.data.gouv.fr/fr/datasets/geofla-r/) récupérer le découpage administratif des communes (rôle géographique qui brille par son absence dans Tableau) issu de Géofla, un service proposé par l'IGN. Après un petit traitement obligatoire pour convertir les coordonnées Lambert 93 (système de coordonnées franco-français) en coordonnées WGS84 (utilisé quasiment par tout le monde, si je ne m'abuse), nous avons pu tenter la connexion de Tableau à ce magnifique fichier shapefile. Et là, quelle ne fut pas notre surprise : ça fonctionne ! HALLELUJAH !.... bon, on se calme, rien n'est fait, ceci n'est que la connexion au fichier... En revanche, aussi étrange et mystérieux que cela puisse paraître, Tableau reconnaît bien les différents attributs présents dans le shapefile. Eh oui ! Cela veut dire qu'en plus de la géométrie des communes, on retrouve le code insee et la population ! Tout ça devient de plus en plus fou !


Donc la source de données est construite, fabuleux, ne reste plus qu'à créer des viz, c'est quand même l'intérêt de la chose !! Ni une ni deux, on bascule sur l'interface de conception et on glisse et dépose ce qui va bien c'est à dire : la géométrie (qui devient donc un nouveau rôle géographique de Tableau ?!? :D .... non, non, il ne faut pas rêver tout de même... :( ), le code insee et la population (pour faire une joooooolie légende des couleurs). Allez soyons fou-fou, on va même calculer une densité de population (sum([Population])/sum([Superficie])). Et c'est assez fou car tout ce petit monde fonctionne sans problème et sans latence. J'avoue avoir eu, à un moment, une petite larme de joie en repensant à tout ce temps passé à construire les fichiers de polygones personnalisés depuis mes débuts avec la version 7.0 de Tableau...


Tout ça c'est très bien et très intéressant mais bon, ne nous leurrons pas, il faut pousser le test plus loin... beaucoup plus loin... Comme dirait Benjamin Parker : "Un grand pouvoir implique de grandes responsabilités". C'est pourquoi, Maurice, nous avons osé pousser le bouchon plus loin en se posant ces questions : et qu'en est-il des fichiers GEOJSON ? et peut-on faire des jointures de fichiers spatiaux ? et pourquoi pas des cartes à 2 couches de fichiers spatiaux ?! Tout ceci est dingue ! Mais nous n'avions pas vu que notre aventure ne faisait que commencer...

"Allez Hop, on y va, en route pour l'aventure !"


La deuxième phase de notre test, ô combien aventureux et plein d'audace, nous a conduit à utiliser un développement fait en interne. Eh oui, ce test était fait pour mettre à l'épreuve nos compétences et nos réalisations... Nous avons donc jeté notre dévolu sur une API d'isochrone ! TA-DAA ! Bon, le but de cette API est de retourner des fichiers GEOJSON contenant la géométrie des isochrones en fonction d'une liste de points fournis au préalable. En gros, on donne un fichier CSV avec des points d'intérêts et la machine nous renvoie des GEOJSON avec les isochrones correspondant à chaque point d'intérêt. Tout ça est très prometteur mais une question fondamentale subsiste : qu'allons-nous utiliser comme fichier source ? Et c'est à ce moment précis que nos esprits se sont éclairés pour nous révéler la solution : des magasins issus du répertoire SIRENE ! Eh oui, vous n'êtes pas sans savoir "[qu']une courbe isochrone est une courbe géométrique délimitant les points accessibles par un véhicule – terrestre ou aérien – en un temps donné" (dixit wikipédia). Dans notre cas ce ne sera pas des courbes mais plutôt des zones. Toujours est-il que pour être pertinent il nous faut des isochrones correspondant à un point d'intérêt accessible en voiture (nous calculons actuellement des isochrones pour du transport routier) par exemple des magasins et non pas la salle de bain de l'appartement de Chuck Norris... bien que...


La première étape a donc été de constituer un jeu de données provenant du répertoire SIRENE (en Open Data depuis janvier 2017). Pour rester le plus possible cohérent, nous avons choisi comme périmètre les grandes enseignes de la vente de meubles à savoir : ALINEA, BUT, CONFORAMA, FLY et IKEA. Cela nous a permis de ressortir environ 530 points d'intérêt correspondant évidemment à 530 magasins. Après avoir constitué un fichier CSV contenant le SIRET (code unique de l'établissement), la latitude, la longitude et deux paramètes de fonction (le pas et le rang) permettant de définir nos isochrones, nous avons envoyé tout ce petit monde à notre API qui, en un temps record de plusieurs dizaines de minutes, nous a retourné 530 fichiers GEOJSON. Et voilà, la magie de la technologie moderne avait fait son oeuvre. Nous avons ensuite forgé en secret dans nos bureaux "un GEOJSON pour les gouverner tous, un GEOJSON pour les trouver, un GEOJSON pour les amener tous et dans Tableau les lier". Ceci nous a permis de créer ce qui suit, une extraordinaire carte des isochrones de chaque magasin.


Après avoir fêté dignement notre réussite, nous nous sommes aperçu que, bon, cette carte était quand même plutôt pauvre... Nous avons donc décidé d'utiliser d'autres fichiers spatiaux pour enrichir notre visuel. De la même manière que pour les isochrones, nous avons créé un fichier avec chaque point d'intérêt géolocalisé et nous avons réutilisé le shapefile des communes françaises. Cela nous a permis de construire une source de données beaucoup plus intéressante. A cela nous avons joint un extrait de données Tableau contenant les informations relatives à chaque SIRET (adresse, effectif, activité, nature juridique...). Cette étape nous a permis de tester une autre nouvelle fonctionnalité de Tableau 10.2 : les jointures sur des calculs ! En effet, pour joindre les différents fichiers, il a été nécessaire de faire des calculs avant les jointures notamment pour convertir certains types de données et pour concaténer des champs (par exemple SIRET = SIREN + code NIC). Tout ceci nous a permis d'obtenir cette magnifique source de données :


Vous ne serez pas sans remarquer que nous utilisons, au passage, une fonctionnalité récente (version 10.0) qui nous permet de croiser différents systèmes sources. Cet outil est un vrai concentré de technologie, n'est-ce pas ? Suite à tout cela, il ne restait plus que la construction du tableau de bord. Une seule question restait en suspend : est-il possible de faire des cartes doubles avec des fichiers spatiaux ? La réponse est évidemment oui !

Une carte c'est bien, deux cartes c'est mieux !


Lors de la construction du tableau de bord nous avons souhaité placer à la fois les magasins sous forme de points et également les zones isochrones. Nous sommes d'accord pour dire que c'est mieux d'avoir l'endroit où se situe le magasin en plus de ses zones isochrones. Pour cela, la jointure entre les deux fichiers GEOJSON (les isochrones et les magasins) a été salvatrice. Etant donné que la géométrie est interprétée comme telle par Tableau, les coordonnées géographiques sont donc "générées". Cette particularité fait que pour construire une carte double, il est obligatoire d'avoir des coordonnées "générées" des deux côtés. Eh oui, il n'est malheureusement pas possible de superposer des coordonnées "générées" et des coordonnées lues à partir d'un fichier source. Triste monde me dirait vous... Heureusement, nous avions prévu le coup en amont en créant ces deux fichiers GEOJSON. Cela nous a donc permis de construire LA carte, THE carte :


Pour aller un peu plus loin dans l'analyse et la mise en forme, nous avons créé quelques feuilles en plus notamment pour compter les magasins, les communes d'implémentation et l'effectif total approximatif (arrondi à la centaine près dans le répertoire SIRENE), ainsi qu'un graphique en barre pour présenter l'âge, la durée d'activité et de nouveau l'effectif de chaque magasin. Ce premier tableau de bord nous a paru intéressant pour analyser la stratégie d'implémentation des magasins. On a notamment remarqué que l'enseigne IKEA est placée tout autour de Paris. On se doute que les magasins sont d'une superficie très grande, ce qui empêche d'en construire en centre ville, mais il est important de remarquer qu'à 30/35 minutes de voitures du centre de Paris, il y a un magasin IKEA. Seul point noir pour cette enseigne, au nord ouest, il y a une zone de vide où il serait potentiellement intéressant de construire un établissement. Nous avons également créé un second tableau de bord où cette fois nous avons positionné toutes les enseignes afin de voir les zones de recouvrement des concurrents.


Bon, et dans tout ça les nouvelles fonctionnalités ?


Pour conclure cette grande aventure, je dirai que nous avons réussi à tester comme nous le souhaitions cette intégration des fichiers spatiaux. Cette fonctionnalité m'a fait "rêver" depuis l'annonce faite il y a déjà plus d'un an et force est de contaster qu'elle fonctionne vraiment bien. D'un point de vue purement technique, les performances sont bonnes (à voir avec des très très gros fichiers) avec des fichiers tels que les 37 000 communes françaises ou les 530 magasins, les jointures sont possibles, la lecture des données GEOJSON est bien réalisée. Un seul bémol concernant le rôle géographique "geométry" : en effet, nous avons tenter de construire un "web data connector" pour interroger directement l'API mais malheureusement il est impossible de trouver le rôle géographique "geometry" ce qui ne permet pas de générer les coordonnées géographiques. C'est relativement dommage... D'un point de vue fonctionnel, les applications peuvent être nombreuses d'autant plus que les représentations cartographiques sont de plus en plus utilisées. Certains clients pourront dorénavant cartographier leur propres découpages commerciaux ou leur points d'intérêt en quelques clics et sans les désavantages des "customs polygons".
Bref, autant être honnête, cette fonctionnalité est globalement une réussite. Comme dirait Cyril Lignac : "Simple mais efficace !". Enfin, je remercie Franck Nguyen, mon padawan, pour son aide tout au long de cette traversée. Et merci à vous pour la lecture de ce billet de blog !

2 comments:

  1. This comment has been removed by the author.

    ReplyDelete
  2. Bonjour,

    Merci pour votre article qui m'aide pas mal sur un projet d'étude personnel, puisque je débute avec Tableau.

    Je cherche à déterminer le nombre de personnes dans des zones de 60 minutes autour de plusieurs points chauds en France (des stades). Pour ce faire j'ai déjà récupéré les fichiers shapefile des contours des communes françaises ainsi que le fichier de la population de ces communes. La liaison se fait avec l'ID INSEE de ces communes.

    Je cherche maintenant à générer facilement les zones isochrones autour de ces lieux et c'est la que ça se corse :
    - j'ai déjà trouvé un outil qui me permette de générer cette zone (fichier KML) mais il faut que je le fasse point chaud par point chaud ce qui est très fastidieux... Pourriez-vous me donner le nom de l'API Isochrone que vous utilisez pour générer le fichier des zones de manière massive en fonction d'une liste de points chaud?
    - lorsque je cherche à lier cet export de zones avec mes tables existantes (contours des communes et population), je ne voit pas trop comment faire puisque je n'ai aucun identifiant commun entre ces fichiers (mon fichier KML ne comporte que 3 information : Nom, Description, et le fichier "géométrie")

    J'espère que j'ai été assez clair, n'ayant pas un profil technique à la base, mais plutôt un profil marketing.

    Merci pour votre aide.
    Nicolas,

    ReplyDelete