mardi 13 octobre 2015

Construire des hostspots à partir de points localisés

Un hotspot (point chaud en français) désigne en cartographie une zone de concentration d’un phénomène social, économique, biologique ou physique.

En géomarketing, on s’intéresse par exemple aux hotspots de population : blocs d’immeubles ou quartier d’habitat très dense et vertical. On identifie aussi les hotspots de richesse (zones de concentration de hauts revenus résidentiels) ou encore les hotspots d’attraction commerciale : limite de zones commerciales drainant des flux liés à une forte densité de points de vente, etc.

Techniquement une carte de hotspots est une couche de polygones : chacun délimite les frontières d’un hotspot et les polygones ont un attribut qui hiérarchise l’importance de la zone au regard du phénomène étudié. Lors de la restitution, il est souhaitable de coupler une couche de hotspots avec une couche carte de chaleur (heatmap), calculée sur la même base.

Après beaucoup d’errances sur ce sujet, je pense que j’ai validé une méthode empirique acceptable pour la mise au point d’une carte de hotspots à partir de fichier de points localisés. Si les points sont correctement placés, la méthode dessine des contours de concentrations réels qui s’affranchissent des zonages administratifs. Elle fonctionne aussi très bien sur les bases de points volumineuses. Ce tutoriel en quatre temps est destiné aux praticiens des données géo localisées familiers des systèmes d’information géographique.


1/ Le fichier de points : la localisation des photos du site Panoramio

Considérons l’exemple de l’identification des zones à forte fréquentation touristique en France métropolitaine. Notre beau pays regorge de zones d’intérêt touristique et il n’existe pas de recensement, carte exhaustive de ces zones. Je vous propose de la créer.

Pour cela, je dispose d’un fichier de plus de deux millions de points : chaque point correspond aux coordonnées géographiques d’une prise de vue photographique publiée sur Google Map (via Panoramio). Les photos sont prises par de nombreux contributeurs touristes et Panoramio fait un contrôle pour valider que la photo est pertinente pour décrire un lieu. Les photos sont prises avec des appareils obligatoirement équipés d’un système GPS. La localisation chargée sur Google/Panoramio est donc très précise (< 5 mètres). Une API de Google/Panoramio permet d’extraire les coordonnées géographiques de chaque photo sur tout ou partie de la planète. Le fichier que j’exploite couvre la France métropolitaine et toutes ses zones frontalières. Merci aux données massives (« bigdata ») : nous disposons ainsi d’une source libre de grande qualité pour établir une carte des hotspots de fréquentation touristique.



La localisation à Paris des photos chargées sous Panoramio, reflet brut des zones touristiques
Chaque point bleu = coordonnée GPS d’une photographie

Je surligne à la main en rouge les hotspots bien connus. On distingue au Sud-Ouest le château de Versailles, la zone de La Défense (la Grande Arche attire des travailleurs et aussi beaucoup de touristes), Montmartre, la Tour Eiffel, les Champs-Elysées, tout le centre de Paris et la Seine avec le trajet des bateaux Mouches. Au Nord, la Cité des Sciences et plus à l’Est, le cimetière du Père-Lachaise, qui accueille plus de 3 millions de visiteurs par an, soit le cimetière le plus visité au monde. En zoomant un peu plus sur ce cimetière, on trouve des concentrations inédites de photos sur la tombe de Jim Morrison.

La localisation des photos prises au cimetière du Père-Lachaise (Paris 20°)



Cette source est donc vraiment précise pour bien situer les lieux de fréquentation. Le parisien peut surligner à la main les hotspots, mais on conviendra que c’est arbitraire et fastidieux à généraliser sur un grand territoire !


2/ « rastérisation » des points avec une carte de chaleur

Passons donc à notre deuxième point, la génération d’une carte de chaleur à partir des points photos. Il s’agit d’une grille raster carroyée pour laquelle on attribue à chaque pixel (carreau) une valeur de mesure correspondant à la densité de points photos dans et autour du carreau. Pour une photo donnée de valeur 1, nous distribuons cette valeur sur tous les carreaux avoisinants dans la limite d’un rayon fixé et à raison inverse quartique de la distance du point au carreau. Ce calcul est fait pour les 2 millions de points et il faut utiliser une bonne technologie. QGIS (version 2.10) fait très bien le travail. Ce logiciel est libre et il possède de très riches et bons algorithmes pour générer des cartes de chaleurs et traiter les couches rasters. Voici le lien de téléchargement de QGIS.

Après chargement de notre couche vectorielle de 2 millions de points photos, générons une grille de chaleur raster (menu QGIS Raster + Carte de chaleur) : fixons d’abord un rayon de calcul de 200 m (un rayon trop étroit fait planter le soft). QGIS propose alors par défaut une grille à carreaux trop macro ; il faut re-calibrer la dimension de la grille. Si le système de projection est métrique, le redimensionnement est fait en mètres. Mes données sont en projection long/lat EPSG 4326, je dimensionne mes carreaux en degré. Ici je demande la création d’une grille raster format GeoTIFF de 10 551*16 880 carreaux, soient près de 180 millions de pixels avec un écartement de 0.001 degré de longitude et de latitude (soient en France des carreaux de 80m de large et 160m de haut).


Le choix du rayon et de la taille des carreaux dépend du problème que l’on traite. Il faut choisir un rayon court pour des mesures avec impact fort de proximité ou si les frontières de hotspots sont très tranchées. Si le nombre et la densité de points est faible ou si l’on veut une vision macro de la mesure, il faut élargir le rayon et la taille des carreaux de la grille. La taille du rayon doit aussi être compatible, supérieure aux côtés du carreau de la grille.

Notez que vous pouvez intégrer des paramètres complémentaires pour la définition de la carte de chaleur : pondération des points par un indice d’attractivité ou de taille, ou encore variation du rayon de calcul selon la nature de vos points.

QGIS mouline seulement quelques minutes pour ce calcul. Par défaut, le style de la grille résultat s’affiche en noir et blanc



En allant dans les propriétés de la couche, je définis un style d’affichage plus explicite pour cette couche raster. Il y a quelques paramètres à changer : choisir un rendu avec pseudo-couleur, choisir sa palette, puis recalculer les valeurs réelles minimum et maximum de la grille, n’oubliez pas ensuite de classer en mode continu les tranches de la palette de couleur, puis ajuster le nombre de classes et manuellement les tranches. Ici, je ne voulais pas que des photos trop isolées apparaissent dans le rendu de ma carte de chaleur, j’ai donc relevé le minimum de la valeur affichable de la grille.



On obtient une couche de chaleur et l’on vérifie qu’elle cale bien avec la densité de points :





3/ Création de courbes de niveaux à partir de la grille raster

Attention : le rayon de 200 m est bien calé pour le rendu visuel de l’attraction. En revanche, il est trop court pour le calcul des hotspots. En effet, l’identification des courbes de niveaux s’appuie sur la grille et ne fonctionne pas dans ses trous. Une courbe de niveau relie les carreaux de même mesure. Si la grille est trop resserrée autour des points photos, une courbe de plus bas niveau risque de ne pas se refermer sur elle-même du fait de carreaux manquants. Pour cette raison, j’ai généré une deuxième grille similaire hormis le rayon que j’ai étendu à 500 mètres. Cette grille très (trop) lissée est exploitable uniquement pour la définition des courbes de niveau.



Pour calculer les courbes de niveaux sur QGIS, rendez-vous sur le panel Raster+Extraction+Création de contours. Il faut préciser le nom de la grille raster en entrée, le nom du répertoire d’accueil du fichier vectoriel des contours en sortie, la variable attribut (ici TourismS) qui accueille le seuil de définition de chaque courbe de niveau.

Par défaut, QGIS propose la création d’une série de courbes de niveaux basées sur la mesure de la grille par pas de 10 entre les valeurs minimum et maximum de la grille. Notre grille de photo a une très forte variabilité de mesure. Ce n’est pas adapté. L’outil pré-génère une commande Gdal (outil libre de commandes SIG très puissant que QGIS exploite abondamment). Rentrons en édition sur cette commande et modifions le paramètre de définition des intervalles « –i 10.0 » en le remplaçant par une définition d’intervalles fixes « -fl 10 50 200 500 1000 ». J’ai un peu tâtonné en regardant la distribution de la mesure de la grille pour fixer ces seuils de 5 courbes de niveau de fréquentation touristique. Je souhaitais définir 5 seuils « d’étoilage » des niveaux de fréquentation et respecter la variance de la fréquentation. J’ai appliqué une recette bien parisienne ; j’ai calé mes seuils sur la région parisienne avec ses hotspots touristiques très importants et j’ai vérifié que cela collait bien pour le reste du pays. D’autres démarches sont certainement plus convaincantes…


J’ai donc demandé à QGIS de lancer la commande :
gdal_contour -a TourismS -fl 10 50 200 500 1000 10.0 "E:/0. PAUL RECUP/1. data/PhotosPanoramio/FR_HotSpot_Photos.tif" "E:/0. PAUL RECUP/0. PaulTemporaire/1. Dev/Tourisme/Fréquentation/FR_HotSpot_Contours"

J’obtiens 5 courbes de niveau et je leur applique un style catégorisé.


4/ « Polygonisation » des courbes de niveaux

Nous y sommes presque. Les courbes de niveaux qui délimitent les hotspots sont des objets lignes. Or, les requêtes cartographiques les plus courantes (inclusion, proximité…) fonctionnent avec des polygones. Avec QGIS, on « polygonise » donc la couche vecteurs de lignes de niveaux en allant sur Vecteur + Outil de géométrie + Lignes vers polygones. A l’affichage, la couche stylée et polygonisée est la même que celle des contours lignes, mais chaque Hotspot est désormais un objet polygone. Notons qu’un polygone de niveau inférieur englobe la surface de tous les polygones hotspots de niveaux plus élevés.



En fin de course, une série de traitement de vérifications et de nettoyage des géométries des polygones hotspots peut être nécessaire. Paris, par exemple est enserrée d’un très large hotspot de bas niveau (mesure = 10) qui couvre quasiment toute la ville. Il est vrai que la ville de Paris est une grande promenade touristique. Mais on peut aussi considérer des seuils relatifs plus élevés pour la définition des hotspots urbains et supprimer les hotspots de bas niveau qui couvrent un territoire trop vaste. A chacun de valider la bonne cohérence de sa nouvelle couche.


Voilà, c’est fait. Nous avons nos hotspots de fréquentation touristique avec une grille conjointe de compréhension de la géographie de l’intensité de la mesure. Il ne reste plus qu’à publier cela sur le net, mais c’est une autre histoire (pas forcément toujours simple) et que je ne vais pas développer ici.
Je vous remercie de m’avoir suivi jusqu’ici, j’espère que vous êtes équipé pour adapter cette méthode empirique à votre jeu de données points. Bonne session « hotspots ».

dimanche 27 septembre 2015

Télécharger les contours des zones touristiques internationales (en format SIG)

La loi Macron (août 2015) autorise l'ouverture des magasins le dimanche à Paris sur une dizaine de zones à très forte fréquentation commerciale et touristique.

Lien vers la carte interactive des ZTI (source OSM)

Open Street Map a édité ces zones et je les communique ici en téléchargement avec différents formats : KML, GeoJson, MapInfo et Shape.

La terminologie "zones touristiques internationales" est "politique". La carte ne correspond pas exactement à une notion de fréquentation touristique : l'île de la Cité (Notre Dame) et la tour Eiffel sont oubliées...

Il y a de multiples façons d'approcher les flux touristiques et j'espère revenir préciser ce sujet passionant lors d'un prochain post.

samedi 19 septembre 2015

Des courbes isochrones à moindre coût (gratuit)

Un contour isochrone est un objet polygone qui délimite les points accessibles par un véhicule quelconque en un temps donné.  Les applications des courbes isochrones sont nombreuses avec par exemple :
  • Définir la zone de proximité des usagers d’un équipement public, la zone de chalandise des clients d’un commerce ou d’un supermarché ;
  • Tracer la zone de livraison à 15mn en deux roues (motorisés ou non) d’un restaurant rapide ;
  • Connaitre la zone accessible en transport en commun autour de mon lieu de travail;
  • Délimiter la zone de desserte d’un point relais, un lieu physique auquel des marchandises achetées en ligne sont livrées par les services postaux et récupérées par la population des clients particuliers résidents dans cette zone...
Le calcul des zones isochrones reste le domaine réservé de sociétés spécialisées dans les  Systèmes d’Information Géographique. Il nécessite en effet une infrastructure lourde de données vectorielles routières (et de transports en commun) avec une bonne connaissance des réseaux (sens de circulation, vitesses limites, spécificité de limitations pour certains véhicules…) ainsi qu’un algorithme de calculs intelligents (rapides) et réalistes des iso-itinéraires autour d’un point. Cependant le développement de la cartographie collaborative Open Street Map et l’ouverture de divers calculs d’itinéraires offre de nouvelles opportunités pour ce type de calculs avec des coûts réduits. Voici quatre exemples :

1/ Calcul d’isochrones inter-frontaliers sur grandes distances

Récemment un collègue m’a demandé de lui transmettre une zone isochrone de 4 heures autour de Paris. Je me suis enquis d’utiliser mes outils « Pro » traditionnels. Cependant 240 minutes autour de Paris, cela déborde de nos frontières et je disposais seulement du réseau France.  Les manipulations d’installation d’un réseau Europe sur mon maigre PC étant dissuasives, j’ai donc fait un petit tour sur le web où l’on trouve tout.

Sur le site freemaptools.com j’ai utilisé un utilitaire « how far can I travel ».  En paramétrant une adresse parisienne de départ, les 4 heures de mon périmètre isochrone, le mode véhicule DRIVING avec un véhicule roulant en moyenne à 105 km/h, j’obtiens la courbe isochrone :

Paris à moins de 4 h de route
Détail suivre ce lien

Je crois que cette application mobilise la très précise API de calculs d’itinéraires de Google Map sur un réseau allégé des plus grandes routes (Major roads) en mode "précision intermédiaire".

Le résultat est assez réaliste excepté deux points :
  •  La pointe du Cotentin devrait être complétement intégrée dans le périmètre (Cherbourg est à 3h45 de Paris).  Le réseau routier « Major » (autoroute et Nationale 4 voies) s’arrête à Valognes en amont de Cherbourg, le calcul est donc tronqué à ce niveau ;
  • L’Angleterre est à plus de 4h en voiture de Paris. Au Nord, la courbe devrait s’arrêter à Douvres, le temps de traversée du tunnel de la manche semble sous-évalué. De fait, Londres est à 5h30/6h de Paris en voiture…

En adaptant la vitesse de déplacement moyenne, l’utilitaire permet aussi de calculer des isochrones piétons, vélos (en évitant les autoroutes) sur un réseau plus précis, les temps de calculs sont alors très longs.

2/ Calcul d’isochrones « courts » (<2h en France)

Un internaute anonyme m’a communiqué l’adresse de son site de calcul et de caractérisation de zones de chalandise. Pour la définition de la zone isochrone autour d’un point, ce site propose un calcul isochrone sur réseau Open Street Map en France métropolitaine qui me semble très précis. On a la possibilité de superposer plusieurs zones isochrones et de multiples autres options très utiles pour les études d’implantation de sites commerciaux.   

Isochrone 15, 30 et 45 mn à partir d'Auray (56)
http://www.owlapps.net/application-geomarketing
  
Les deux sites  freemaptools.com et owlapps.net  proposent le stockage de la zone calculée en format  KML. Pour tous les utilisateurs de SIG, c’est bien pratique : on passe par le convertisseur  Kml2shp pour  convertir le fichier KML généré par chacune de ces applications en format SIG (Shp). Utilisez cet utilitaire pour récupérer votre polygone isochrone sous MapInfo, ArcGis ou Qgis et effectuer d’éventuelles modifications manuelles sur vos isochrones.

3/  Calcul d’isochrones en temps de transport en région parisienne

Pour les usagers des transports en commun parisiens, le SDIS a mis au point cette application http://www.atelier01.net/metro/paris/isochrone en béta qui utilise un graphe de réseau des métros RER, SNCF et bus pour tracer des isochrones. 

En partant par exemple du centre de Paris, cela dessine une jolie pieuvre à bulles multicolores autour des points d’arrêts. C’est beau et surtout très réaliste !

Isochrones en transport en commun au départ de la place du Chatelet (Paris centre)

4/ Isochrones multi-modaux en France métropolitaine (à moins de 60mn du point de départ):


Je garde le meilleur et le plus prometteur pour la fin. Des barbus spécialistes d'OSM basés à Postdam ont développé Route 360°. C'est une API de routing et d'isochonie sur réseau OSM. Elle comprend aussi la possibilité de construire des isochrones en transports en commun pour Paris, Toulouse, Rennes, Strasbourg sur données GTFS. Les temps de calculs sont exceptionnels. Les calculs d’isochronies et d'itinéraires sont a priori d'un très bon niveau de précision.


Cette application http://france.route360.net/ est très pratique et illustrative des capacités et performances de l'API. 

Isochrones 10, 20 et 30 mn à partir de la place Chatelet (Paris)

A pied
En vélo
En Transports en commun
En voiture




Avec ces applications, on peut donc monter des analyses locale ad-hoc au coup par coup sans équipement logiciel et sans données graphes lourdes : tout est dans le nuage. Mais cela ne marche pas pour des applications plus industrielles où il faut par exemple générer des isochones et distances routières en masse, ou encore utiliser des webs services d'isochronie dans des systémes logistiques front end opérationels. Les composants d'isochronies peuvent rester dans le nuage, mais deviennent payants.

La communauté des spécialistes d’Open Street Map se mobilise cependant sur les exploitations possibles des données libres en matière de transport. Les logiciels et API autour des calculs d’itinéraires sont en effervescence (Voir par exemple les projets Open Source Routing Machine ou PG routing). La qualité des calculs de routing sur les données libres OSM se rapproche de celle des grands editeurs de cartes : GoogleMap, Here, TomTom.

A suivre ...

Le trompe l’œil de Mercator

La terre est ronde, nos écrans sont plats. C’est le casse-tête de la géodésie et il faut déambuler dans la jungle des systèmes de projections pour représenter le globe sur nos terminaux numériques. Mercator nous guide parfaitement sur les mers grâce à un système de projection qui conserve les angles. Mais sur terre et sur nos globes virtuels, Mercator nous dessine des cartes peu conformes, qui ne respectent pas les distances et surfaces, pleines de distorsions azimutales ! Les déformations sont d’autant plus fortes que l’on se rapproche des pôles.

Un site Internet tente avec brio de rétablir les faits : http://thetruesize.com/. On y déplace à loisir nos frontières en longitude et en latitude avec quelques résultats insolites. En voici un échantillon :

  • Rétablissons une vérité physique, la France au 70° parallèle prend du relief, c’est un grand pays !
  • Mais le logiciel est « con sur les bords » ; aux pôles les rapports de surfaces ne sont pas respectés. La France au 80° parallèle Nord est énorme !
  • Bien sûr, la solution est de placer le Groenland au  45° parallèle :


  • Dernier constat mal connu : l’Afrique est plus vaste que toutes les grandes puissances réunies !
 


Conclusion ; Mercator : menteur à la carte.
Plus de détail, voir aussi cet article du Monde






jeudi 3 septembre 2015

DataShine : le recensement anglais à la carte

Vous vous intéressez à notre voisin anglais ; ses us et coutumes qui nous semblent parfois étranges ? Vous êtes curieux de la géographie de sa population, de sa démographie, de la pratique de la langue de Shakespeare  ?

DataShine est un site de webmapping qu'il faut absolument visiter. L'objectif est de présenter au grand public les données locales du dernier recensement anglais (2011). Deux universitaires anglais ont relevé ce defi avec maestria. DataShine est une carte interactive avec une sémiologie très bien travaillée, facile d'accès et qui permet rapidement de visualiser les diversités locales de la société anglaise sous de multiples aspects :  caractéristiques sociodémographiques, culturelles (origine ethnique, religions, langues), santé, logement, éducation, activité/emploi, flux et déplacements...

Allez donc faire un tour sur DataShine en suivant ce lien. Le site et l'interface sont beaux, simples, pratiques et bien réfléchis. Sur une base d'informations importantes, les auteurs du site ont trouvé un juste compromis entre fluidité et richesses fonctionnelles. Les cartes détaillent des informations au niveau geographique fin des "census output area" (equivallent des iris de l'Insee).


Pour les professionels du "webMapping" souvent assimilés au mot valise "geek", j'attire l'attention sur deux fonctions novatrices, bien utiles et bluffantes:

1/ Integration dans l'analyse thématique d'un arrière fond du bâti

Par défaut l'analyse thématique de données censitaires couvre l'ensemble des zones bâties et non bâties. C'est une représentation biaisée et imprécise de la réalité. DataShine propose de montrer l'analyse thématique uniquement sur les polygones de description des bâtiments. Sur le complément des zones non bâties non habitées, il n'y a pas de raison de montrer l'analyse thématique.

Les vélomans : part des actifs se rendant au travail à vélo
version sans batis moche :

version avec couche des bâtiments, bien plus claire :



2/ Légende de l'analyse thématique automatiquement recalibrée sur la vue en cours

Par défaut la légende est calibrée automatiquement sur les données de l'ensemble de l'Angleterre. En fonction de la répartition de l'indicateur sélectionné, DataShine arbitre entre le calibrage en classes d'équi-amplitudes et le calibrage par la méthode de jenks (dite des "ruptures naturelles") basée sur la décomposition de la variance de l'indicateur (maximisation des variances interclasses et minimisation des variances intraclasses).

Pour les indicateurs avec une forte dispersion et une forte concentration sur certaines zones, la légende automatique n'est pas adaptée. DataShine propose une option "rescale on current view" qui recalcule automatiquement la légende sur les seuls quartiers de la vue écran.

Prenons l'exemple du français parlé à Londres.

Français comme langue principale en % de la population 
version avec une légende calibrée sur l'ensemble de l'Angleterre 
Cette carte est peu informative. On sait bien que Londres est cosmopolite et accueille une population d'origine française importante par rapport au reste de l'Angleterre. Partout dans Londres, on peut demander l'heure à au moins une personne sur 100 dans la langue de Molière.

Français comme langue principale en % de la population 
Version avec légende recalibrée sur la vue 

C'est beaucoup plus clair maintenant : le quartier huppé de South Kensington est colonisé par des francophones. Une personne sur cinq peut vous indiquer votre chemin en français dans Fulham Road ou devant chez Harrods.


Bravo à James Chesshire et Oliver o'Brien pour ce travail  "so inspiring". Merci à Paul Thompson pour m'avoir passé l'information.


Les bonnes sources libres pour les bonnes analyses géomarketing

A l'attention des analystes des territoires français et en géomarketing, voici une liste des données de base à intégrer dans votre système d'information géographique pour vos chères études. Les sources ouvertes sont foisonnantes et j'ai restreint la liste à l'essentiel.

1/ Le géocodage facile et gratuit :

Vous avez des données clients fournisseurs etc...  avec leurs adresses et vous souhaitez les géolocaliser pour des représentations cartographiques. Voici les deux sources incontournables : 


2/ Contours administratifs et des quartiers (Ilots Regroupés pour l'Information Statistiques, IRIS) :

  • Les contours Iris sur le site de l'IGN:  http://professionnels.ign.fr/contoursiris
    Ces contours sont lissés pour simplification d'usage et une meilleure fluidité informatique d'affichage de carte. Ils sont donc parfaits pour les représentations cartographiques. Ils ne sont pas calés avec les contours communaux OSM. Ils ne sont guère exploitables si vous devez "iriser" vos bases d'adresses car les limites des rues ne coïncident pas avec celles de ces contours (les cartes iris calés sur les contours communaux cadastraux et calées sur les rues pour l’irisation en complément du géocodage sont payantes). 
  • La table de correspondance administrative des communes (le code commune correspond aux 5 premiers caractères du code Iris) : http://www.insee.fr/fr/methodes/default.asp?page=zonages/table-appartenance-geo-communes.htm
    Cette table, appelée aussi Code Officiel Géographique (COG), est exploitée lorsque l'on souhaite agréger des analyses et données à des niveaux supra-communaux : bassins de vie, cantons, zones d'emploi, agglomérations, aires urbaines... 


3/ Données "attributaires" IRIS 

Voici pour l’année pivot[1] du recensement une série de données sociodémographique et d'activité pour caractériser la population résidentielle de chaque iris :




De multiples sources complémentaires sont accessibles sur le site des données censitaires locales infra communales de l'INSEE, sur le site des statistiques de la DGI on peut télécharger des données fiscales communales, ou encore à l'IGN avec par exemple le fichier vectoriel  "Route 500" des principales routes françaises. Le site "officiel" des données ouvertes  open data gouv comprend aussi un foutoir de données produits par divers organismes publics.
Allez fouiller ces sources, vous trouverez certainement les indicateurs locaux pertinents pour éclairer vos problématiques.    





[1] Ces sources sont réactualisées annuellement par l’INSEE. Le millésime pivot disponible au moment où j’écris ce post est 2011.   

mercredi 2 septembre 2015

Extraire des données Google Trends

Google Trend est un outil de suivi des tendances des recherches des internautes sur le fort populaire site et moteur de recherche du même nom. Les analystes utilisent cette source pour détecter les derniers "potins" en vogue sur le web. Les traces des recherches de tous les internautes sont compilées dans une grande base de données depuis plus de 10 ans. Les demandes de recherche sur Google sont qualifiées par théme, dans le temps et dans l'espace. Des recoupements sont faits pour identifier les associations de recherches fréquentes. Google a contruit un requeteur très facile d'emploi pour interroger cette base de données. Les résultats sont présentés sous la forme d'un indice de popularité de chaque recherche, que l'on peut comparer dans le temps et l'espace. La méthode de construction de cet indice de popularité n'est cependant pas transparente, c'est un secret statistique de Google.

https://www.google.fr/trends/?hl=fr


L'API google trends n'est pas documentée et il faut faire un travail de devinettes pour comprendre la structure des requêtes Http. Le mode d'interrogation par commande est cependant assez bien documenté en anglais dans cet article.

J'ai approfondi l'aspect géographique de ces requêtes. Voici quelques trucs pour les extractions. En "bidouillant" la syntaxe des requetes Google Trends, on peut faire des recherches géographiques par pays et région.

Je prends un exemple de mesure de la popularité web de certaines banques françaises.

Rapport de base France métropolitaine :
Requete web : http://www.google.com/trends/explore?hl=en-US#q=BNP,LCL,HSBC,Credit Agricole&geo=FR

Détail pour afficher des données carte régionale  pour LCL :
Carte : http://www.google.com/trends/fetchComponent?hl=en-US&q=LCL,BNP,HSBC,Credit%20Agricole&cid=GEO_MAP_0_0&export=5&w=500&h=300&geo=FR
Données au format  JSON : http://www.google.com/trends/fetchComponent?hl=en-US&q=LCL,BNP,HSBC,Credit%20Agricole&cid=GEO_MAP_0_0&export=3&w=500&h=300&geo=FR
Carte des villes BNP: http://www.google.com/trends/fetchComponent?hl=en-US&q=LCL,BNP,HSBC,Credit%20Agricole&cid=GEO_MAP_1_1&export=5&w=500&h=300&geo=FR

Le rapport de base mais avec zoom sur la région Ile de France :
http://www.google.com/trends/explore?hl=en-US&geo=FR-J&q=LCL,BNP,HSBC,Credit+Agricole

On peut parcourir l'ensemble des régions métropolitaine FR-A à FR-V
Si l'on veut les DOM et TOM préciser &geo=GF (Guyanne fse) ou GP (guadeloupe) MQ (Martinique)  BL (saint Bartelemy) RE (la réunion) MF (Saint Martin), DJ (Djibouti) MC (Monaco)


Extraire un fichier en format CSV avec tous les résultats de la recherche (temporel, géographique, recherches en vogue et associées) pour une lisibilité facile et des retraitements par exemple sous Excel.

Les données banques au format CSV pour la région Ile de France :
http://www.google.com/trends/trendsReport?hl=en-US&geo=FR-J&cmpt=q&q=LCL,BNP,HSBC,Credit%20Agricole&tz=Etc%2FGMT-2&content=1&export=2
ou une variante :
http://www.google.com/trends/viz?&graph=all_csv&hl=en-US&q=LCL,BNP,HSBC,Credit%20Agricole&geo=FR-J

Google précise diverses règles d'écriture des mots clefs pour affiner la recherche dans cet article
Exemple : sortie d'un fichier csv qui propose les comptages pour "Credit Lyonnais" et  sa nouvelle appelation LCL et les deux appelations cumulées Credit Lyonnais + lcl (attention pas d'accents dans les recherches...)
http://www.google.com/trends/trendsReport?hl=en-US&geo=FR-J&cmpt=q&q=credit%20lyonnais%2C%20LCL%2C%20Credit%20Lyonnais%20%2B%20LCL&cmpt=q&tz=Etc%2FGMT-2&content=1&export=2


Pour finir je renvoie le lecteur vers une représentation animée des derniers"hot trend" français :

 Hot trend français
http://hawttrends.appspot.com/?r=5&c=5&p=16