Une cartographie des livres en bibliothèque

Posted on

Bonjour !

Tout d’abord, toutes nos excuses pour le peu de mouvements sur ce blog, et l’absence d’évènements grand public autour de l’open data sur Rennes. Ces évènements vont prochainement revenir, et seront bien sûr annoncés ici et via la Cantine Numérique.

Cependant, ce n’est pas pour autant que les membres du collectif se tournent les pouces : nous travaillons sur différents projets et nous essayons de donner régulièrement des nouvelles et des réflexions sur ce blog, comme le fait par exemple Sylvain sur son travail d’extraction des données du catalogue des Bibliothèques de Rennes (voir ses deux articles ici et ).

C’est également un retour d’expérience que je vous propose aujourd’hui, et qui portera aussi sur la bibliothèque… eh oui, c’est un sujet qui passionne plusieurs membres du collectif, d’autant plus que nos interlocuteurs sont très ouverts sur le sujet et acceptent volontiers de discuter de leurs données avec nous. Cet article est donc un récit de nos essais, nos réflexions et nos bidouillages sur notre nouveau projet.

Une carte de la bibliothèque des Champs Libres

La bibliothèque des Champs Libres à Rennes s’étend sur six étages et dispose de plus de 200 000 documents en libre accès. Notre idée de départ était de cartographier la bibliothèque afin de pouvoir repérer l’emplacement de chaque livre. Par exemple, après une recherche dans le catalogue, pouvoir indiquer au lecteur que l’ouvrage se trouve non seulement aux Champs Libres, mais à tel étage, et pourquoi pas dans telle étagère, tel rayon ?

3d

Un beau dimanche du mois de mars, quatre membres du CODRennes se sont donc retrouvés aux pieds de la bibliothèque. Papier et crayons en main, nous avons rapidement défini l’objectif : cartographier le quatrième étage (Littérature) de la bibliothèque afin d’indiquer précisément où se trouvaient chaque tranche de cote.

La cote est un système de classification des ouvrages, que l’on retrouve par exemple sur la tranche des livres. La classification de Dewey est la plus utilisée, et propose de diviser le fonds de la bibliothèque en dix classes, elles-mêmes subdivisées, etc.
Ce système est noté avec des chiffres, par exemple : 641.5 -> Livres de cuisine. Plus d’informations sur Wikipédia

Nous n’avions pas réfléchi au préalable à une méthode particulière pour notre prise de notes : nous nous sommes simplement réparti l’espace afin de travailler chacun sur une partie de l’étage.

A la fin de l’opération (cela a été assez rapide : un peu moins d’une heure), nous nous sommes retrouvés pour comparer les données collectées. Nous avons constaté que nous avions tous adopté à peu près la même méthode, qui nous semblait la plus logique. Dans un second temps, nous sommes revenus sur cette méthode, afin de la rendre la plus claire possible, compatible avec la partie technique (entrer les informations dans une base de données) et surtout reproductible pour les autres étages.

Une carte et des données

D’un côté, nous avons tracé un rapide schéma représentant l’étage vu du dessus, avec ses étagères et ses points de repère (porte d’entrée, poteaux, bornes informatiques).

Sans titre 4

D’autre part, il nous fallait représenter le contenu d’une étagère. Mais qu’est-ce qu’une étagère au fait ? C’est un meuble qui a deux faces, ces deux faces sont découpées en rayons et en colonnes, ce qui forme des cases.

Jelizawjeta_P._Bookshelf_1

Finalement, une étagère ressemble beaucoup à un tableau. Le plus simple est donc de ranger nos données sur papier dans des tableaux. Dans chaque case, nous avons indiqué les cotes que nous trouvions dans les cases des étagères.

Pour relier les tableaux à la carte, chaque étagère a un numéro, et ses deux faces s’appellent A et B.

Sans titre 3

Sur place, plusieurs questions se sont posées : jusqu’à quel niveau de détail est-il raisonnable d’aller ? (profondeur des cotes, position exacte du livre dans l’étagère, voire dans la case) Comment indiquer que plusieurs cotes différentes sont présentes dans une case ? Comment indiquer au contraire qu’une même cote s’étend sur des rayons, voire des étagères entières ? Comment gérer les cas spécifiques, les sélections, les périodiques, les BDs ?

Dans un premier temps, nous avons choisi de mettre de côté la Mezzanine (étage ados) et le rez-de-chaussée (étage enfants) car la disposition et la structure des rayonnages sont trop différents de ceux des autres étages.

Une première feuille de route pour cartographier

Lors d’une deuxième session, nous sommes retournés à la Bibliothèque pour tenter de cartographier les étagères de l’ensemble des étages. Le but n’était cette fois pas de relever les cotes, mais simplement de situer les étagères, et de noter combien de rayons et de colonnes chacune contenait.

cartobibli3

Nombre du bas : numérotation – nombre du haut : nombre de rayons en hauteur – longueur en petits carreaux : nombre de colonnes.

Nous avons entré ensuite ces informations dans un tableur, ce qui nous a permis d’arriver aux chiffres suivants : sur les cinq étages supérieurs de la bibliothèque se trouvent 135 étagères, soit environ 1000 rayons et un total de plus de 4000 cases !

A partir de ce premiers tableau, nous pouvons facilement générer et imprimer les tableaux vierges qui, associés à une carte de l’étage, vont permettre de continuer la collecte des cotes sur les autres étages de la bibliothèque. Avis aux bonnes volontés, si on organisait un atelier ? :)

Des idées d’applications

Au delà de l’idée de représenter de manière originale le plan des étages de la bibliothèque (tout est à inventer : un plan de métro ? des continents ? en 3D ?), nous avons envisagé la possibilité de représenter les informations de façon dynamique.

Par exemple, à la suite d’une recherche sur le catalogue, l’utilisateur apprend que le document qu’il cherche se trouve dans la bibliothèque des Champs Libres ou une bibliothèque de quartier. On peut alors imaginer lui suggérer la façon de s’y rendre, en transports en commun, puis lui indiquer exactement le chemin à parcourir sur place et dans les rayonnages pour trouver son bonheur.

maq

Ces informations pourraient également donner lieu à des jeux de piste, des statistiques…

Et ensuite ?

Ce petit projet est une très bonne expérimentation du principe de crowdsourcing, c’est à dire que les habitants peuvent aller directement chercher et construire les données. Il est facilement reproductible dans d’autres bibliothèques, d’autres lieux…

De notre côté, le travail n’est pas fini : nous souhaitons aller jusqu’au bout de l’idée et proposer des prototypes de représentations des données ou d’applications. Il nous reste donc plusieurs étapes :

  • Finir de collecter les cotes sur les autres étages
  • Entrer ces informations dans une base de données structurée
  • Relier les cotes entrées avec la classification Dewey afin de pouvoir manipuler des thématiques compréhensibles et non plus des chiffres (d’ailleurs, nous cherchons toujours une version brute des quatre premiers niveaux Dewey, en xml ou csv par exemple, si un de nos lecteurs a ça sous la main :) )
  • Concevoir et réaliser des visualisations avec ces données, en nous appuyant sur les idées et besoins des utilisateurs des bibli, mais aussi des bibliothécaires eux-mêmes
  • Renouveler l’expérience dans les autres bibliothèques de Rennes ?

Voilà pour un premier aperçu de nos préoccupations actuelles. Un évènement public sera organisé dans les prochains mois, et permettra aux personnes intéressées de voir l’avancement des projets et d’échanger avec nous et nos interlocuteurs à la Bibliothèque.

D’autre part, si vous souhaitez dès maintenant faire des remarques, poser des questions, ou nous aider sur les tâches listées ci-dessus, n’hésitez pas ! Toutes les idées sont les bienvenues, en nous contactant ou en laissant un commentaire ici-même.

A bientôt,

Léa

Sylvain (dit “l’Ingénieur”), Florian (Database Guru) et Benoît (let’s design this, fools)

 

Schémas et maquettes : Collectif Open Data Rennes, CC-BY.
Photo d’étagère : Jelizawjeta P., CC-BY, sur Wikimedia Commons


Explorer le catalogue des bibliothèques de Rennes Métropole

Posted on

Dans un précédent article, j’ai pu poser quelques bases pour enclencher la relation avec un acteur public dans le cadre de l’Open Data. Passons à présent à un peu de technique.

Sources de données

La première chose fut de déterminer ce sur quoi je pourrais travailler et comment y accéder. Rennes Métropole utilise depuis longtemps un SIGB tout-en-un. Ce logiciel gère à la fois le catalogue et la gestion des prêts. Nous souhaitions accéder au catalogue afin d’offrir à termes une API facilitant l’accès aux données du réseau des bibliothèques de Rennes Métropole.

Nous avons rapidement déchanté, non pas que l’accès aux données soit impossible, mais le seul point d’entrée du catalogue est son moteur de recherche public. En effet, aucun point d’accès programmatique déjà proposé par le SIGB. Ou plutôt si, mais il s’agit d’une option payante et donc d’un investissement dont les services des bibliothèques de Rennes Métropole n’ont jamais eu besoin.

Heureusement, ces mêmes services nous ont offert un beau soutient et fourni leur accord pour exploiter le catalogue via le moteur de recherche.

Au pied de la montagne

L’intérêt d’une API est qu’elle cible les machines plutôt que les humains. Par conséquent, elle n’expose que l’essentiel et, en principe, de manière structurée ce qui facilite grandement le travail d’exploration de la donnée de manière automatisée. A contrario, le moteur de recherche lui cible les humains et se soucie assez peu d’une systématisation de l’exploration.

Mon point de départ était donc celui-ci:

Page d'accueil du moteur de recherche

Page d’accueil du moteur de recherche

La première approche, naïve, fut de chercher toutes les oeuvres commençant par la lettre a puis par b, etc. Deux difficultés sont immédiatement apparues :

  • Débuter par des lettres et des chiffres serait il suffisant pour extraire l’ensemble des oeuvres ?
  • Le moteur de recherche limite le nombre de résultats à 32000 lors d’une recherche aussi large

Un affinage était nécessaire mais sans complexifier la tâche. J’ai donc décidé de chercher par auteur en tablant sur le fait qu’il pouvait facilement y avoir plus de 32000 oeuvres débutant par un motif donné, mais probablement pas 32000 auteurs. Par ailleurs, comme un auteur amène par lien hypertexte à ses oeuvres, je retombais sur mes pattes. L’indirection présente un coût de traitement comme je l’expliquerai plus loin mais se révèle simple à mettre en place. Par ailleurs, le motif n’est plus un unique caractères mais une série de deux: aa, ab, etc. Toujours afin d’éviter la limite des 32000. Malgré tout, il subsiste des recherches l’atteignant encore mais j’ai considéré que je pouvais, pour le moment, accepter une légère perte d’information.

Do you speak HTML?

Puisque je naviguais au sein des résultats du moteur de recherche, ma matière première était du code HTML. Celui-ci offre une structure mais bien plus limitée que le résultats d’une API spécifique. Malgré tout, le code HTML de la page de résultat possédait suffisamment d’indicateurs pour en extraire de la donnée pertinente: titre, méta-données, éditeur, côte, etc.

Notice

Notice

 

Il est assez évident que le code HTML généré par le moteur de recherche a été développé à une époque où les standards du web étaient encore balbutiants. En d’autres termes, il pique les yeux.

Heureusement, j’avais à ma disposition des outils programmatiques capables de lire chaque page HTML retournée par le moteur de recherche. Une fois ces pages décomposées, je pouvais extraire les données qui me semblaient utiles. Il a fallut du temps et de la patience néanmoins pour tout extraire. En effet, ce code HTML n’utilisant pas, ou peu, d’identifiants uniques au sein de sa structure, pointer vers les éléments contenant des données s’est révélé un peu plus compliqué. Il a été nécessaire de trouver un contournement se basant sur les informations à ma disposition:

  • Le label exposé, par exemple TITRE.
  • Puis chercher l’élément le juxtaposant pour en extraire l’information.

Voici un exemple tiré directement du résultat du moteur de recherche :

<table width="100%" cellspacing="3" cellpadding="0">
<tr><!-- next row for fieldtag=t -->
<td valign="top" width="20%"  class="bibInfoLabel">TITRE</td>
<td class="bibInfoData">
<strong>Nevermind / Nirvana, groupe voc. et instr.</strong>
</td>
</tr>
</table>

Cette approche a bien fonctionné. Le désavantage le plus notable est le surcoût lié au chargement et à la navigation au sein de tant d’éléments superflus à notre objectif final. Unitairement ce n’est pas un problème mais j’ai collecté quelques 600 000 notices…

Par ailleurs, comme je l’indiquais plus haut, le fait de devoir utiliser les auteurs comme point d’entrée du catalogue m’a obligé à consommer bien plus de pages HTML que si j’avais pu directement parcourir la liste exhaustives des oeuvres.

Vous avez bien un peu de temps ?

Comme indiqué ci-dessus, j’ai récolté environ 600 000 notices en un peu moins de trois jours. Un conseil, estimez à l’avance le nombre global de notices via le moteur de recherche. L’idée est que si vous avez un plafond vous pourrez potentiellement optimiser votre récolte afin d’en réduire la durée.

Quoiqu’il en soit, les performances de la récolte avaient plusieurs facteurs limitant :

  • Le moteur de recherche n’est probablement pas optimisé pour subir des recherches aussi larges et soutenues
  • J’ai tenté de distribuer la charge en multipliant les agents de récolte mais il semblerait que les services informatiques de Rennes aient placé des gardes fous (et ils ont bien raison) diminuant mes capacités
  • Il aurait été intéressant que je puisse essayer mes agents de récoltes depuis un serveur plus performant (dans ce bon vieux cloud) et déterminer si ma machine elle-même posait ses contraintes

Le principal désavantage à une récolte si longue est de ne pas pouvoir la rejouer chaque nuit afin de synchroniser les données le plus régulièrement possible, notamment en ce qui concerne les attributs de prêts (date de retour par exemple).

Stockage de masse

L’idée d’extraire l’ensemble des notices du catalogue est une étape mais, dans une optique Open Data, il fallait proposer cet ensemble de données de manière structurée au public afin d’éviter de devoir toujours passer par une collecte fastidieuse.

A l’heure actuelle, il n’est pas encore clair quel medium de distribution je choisirai mais il est évident que celui-ci devra faciliter l’exploration des données récoltées. Une base de donnée relationnelle, ou NoSQL, semblerait un bon candidat.

Par ailleurs, récemment j’ai pu découvrir le projet BibServer de l’OKFN sur le sujet des données bibliographiques et je dois avouer aimer leur approche. Il s’agit d’une application web assez simple proposant un moteur de recherche, mais aussi une API, sur des notices (des records). Le serveur ne stocke pas les notices dans une base de données traditionnelle, ni sur le système de fichier lui même mais directement dans un moteur de recherche qui les indexe et propose une interface de recherche très poussée et efficace. Cela répond bien aux origines de notre intérêt des données de bibliothèques, ouvrir l’accès aux données par une API. Tout cela en participant à un effort international sur le sujet.

D’autre part, le projet BibServer promeut un format d’encodage des données bibliographiques simple et flexible s’appuyant sur des méthodes et ontologies standardisées: le BibJSON. Ce format offre une souplesse intéressante dans la manipulation des données et donc de belles perspectives.

Parlez-vous bibliothécaire ?

L’un des aspects les plus enrichissant de travailler sur des données est d’en comprendre le contexte, le vocabulaire, le jargon. Et pour le coup, le milieu des médiathèques est passionnant mais néanmoins complexe. Il s’agit d’une vieille discipline qui s’est enrichi dans le temps et qui continue d’évoluer. La BnF propose par exemple une revue de la complexité du catalogage.

Un exemple simpliste mais illustratif est celui du nom d’un auteur. En général, les notices utilisent le format “Nom, Prénom” qui semble moins intuitif que “Prénom Nom”. Mais il s’agit d’une règle de la norme NF Z 44-061 publiée par l’AFNOR. Tout est donc codifié suivant des règles strictes. La difficulté réside dans l’automatisation du traitement des ces règles afin d’en extraire l’information désirée, et potentiellement les rendre plus consommables en dehors du modèle français de catalogage et d’indexation. Par exemple dans la liaison avec des sources externes telles que Wikipedia (via DBPedia), MusicbrainzIMDBGoodReads, etc.

Ainsi, dans le cas de l’album Nevermind du groupe Nirvana, on se rend compte que le titre affiché est : Nevermind / Nirvana, groupe voc. et instr. Or nous ne sommes pas intéressés par la seconde partie du titre, qui ne nous apporte pas grand chose pour une exploration générique du catalogue. La difficulté est que nous n’avons pas toujours un motif clair pour scinder le titre ou l’auteur en différentes composantes. Nous pourrions ainsi avoir Nevermind Nirvana, groupe voc. et instr: Comment déterminer le titre de la description qui l’accompagne de manière automatisée ? Notons que le catalogue s’est construit durant des dizaines d’années, bien avant que l’outil informatique existe, expliquant que les données puissent induire en erreur un outil informatique.

Un autre exemple découvert au fil de l’eau est celui de la traduction. Le moteur de recherche retourne les traducteurs comme des auteurs donc je les traitais de cette façon. Evidemment ceci n’a pas de sens. Il a fallu par conséquent ajouter une vérification que l’ “auteur” retourné était effectivement l’un des auteurs réels de l’oeuvre, pas un traducteur, exécutant, etc.

Bref, l’extraction systématique des données est une étape. L’exploration en sera une autre plus complexe.

Et la suite ?

A l’heure actuelle, les données et le code ne sont pas encore publics. Le code qui nous a permis d’extraire le catalogue le sera bientôt (après un sérieux nettoyage de fond). est désormais accessible. Quant aux données, nous attendons le retour officiel des bibliothèques de Rennes Métropole afin, par exemple, de spécifier la licence avec laquelle nous pourrions distribuer les données.

Edit. du 26/02/2013: Il semblerait que l’Etat porte un projet d’aides aux bibliothèques désireuses d’avancer vers le numérique (merci Léa du lien).


Réutiliser des données du réseau Star

Posted on

Le Service des transports en commun de l’agglomération rennaise, que je vais appeler le réseau Star, a commencé à ouvrir ses données vers le 1er Mars 2010. En tant que membre du collectif et usager quotidien du métro et des bus de Rennes, ces données m’intéressent. En tant que développeur (web, mais pas que), c’est plutôt le transport de ces données qui m’intéresse.

Et c’est ce dont je suis venu vous parler aujourd’hui : comment ces données se retrouvent dans nos téléphones, dans les applications de développeurs indépendants, voire le plus souvent complètement bénévoles (oui, je pense à l’excellente application Android de Yan Bonnel (et le compte twitter associé @TransportRennes)). Plus exactement, je vais vous parler de ma propre expérience, cela devrait vous donner un aperçu du travail que cela représente, et des difficultés rencontrées.

Si vous n’êtes pas développeur, j’essaie dans la suite de l’article de rester dans la vulgarisation, j’espère donc rester assez accessible. Mon but est de transmettre mes impressions sur mon expérience avec les données, en ajoutant le temps que cela m’a pris. N’hésitez pas à poser des questions en commentaire !

Où sont les données ?

Première question à se poser : où sont les données ? Non, la réponse n’est pas si simple que ça, parce que les données ne sont pas à un seul et même endroit. Le bon point, c’est que les données sont référencées à la même adresse : sur le site officiel data.keolis-rennes.fr. Mais il y a les données à télécharger, et les données de l’API.

Télécharger n’est pas encore réutiliser

Celles à télécharger sont dans un format normalisé par Google : le format GTFS. C’est une bonne et une mauvaise nouvelle. La bonne, c’est que c’est un format ouvert et relativement bien documenté, donc après quelques heures de lecture de la documentation, un développeur peut comprendre comment interpréter les fichiers. Si vous savez vous servir d’un tableur, vous pouvez ouvrir ces fichiers aussi (avec le mode CSV), et vous en sortir avec quelques bons filtres.

La mauvaise nouvelle, c’est que ce format est vu du point de vue du transporteur. C’est à dire que si vous cherchez à adopter le point de vue d’un usager, vous n’allez pas arriver bien loin. Ce qui est un peu dommage, parce que le but de ces données, quand même, c’est d’être finalement présentées par le développeur aux usagers. Orienter la structure des données vers la vision des usagers, c’est faciliter le travail des développeurs (sauf si vous voulez développer un système pour le transporteur).

Bon, pour comprendre, rien ne vaut un exemple : un usager voudra savoir si une ligne de bus peut l’emmener de l’arrêt de bus A à l’arrêt de bus B. Il regarde la fiche d’une ligne, et voit que c’est possible, parce que la fiche lui donne toute la liste des arrêts, dans l’ordre.

Le format GTFS n’a pas de concept de “fiche de voyage type”. Il propose l’ensemble des voyages complets (chacun part à telle heure, termine à telle heure, et passe par A, B, C, D, E, etc. dans un ordre précis). Mais il ne permet pas facilement de savoir quels sont les arrêts de bus d’une ligne.

C’est tout à fait logique du point de vue du transporteur, mais c’est un vrai casse-tête pour le développeur qui veut présenter l’information aux voyageurs.

En bonus point, nonobstant une qualité générale plutôt bonne, il y a des incohérences dans les données fournis dans ces fichiers par Keolis.

Deux trajets peuvent indiquer la même direction dans le même sens (c’est à dire qu’ils viennent par le même côté de la ligne, et dans le même ordre), mais ils ne partent pas toujours du même endroit. Pourtant, si vous lisez la seule donnée disponible à ce sujet, vous allez faire comme moi : vous tromper et obtenir une fausse analyse des données.

Un autre soucis que j’ai remarqué : pour un usager, globalement, un bus a trois types de journées de circulation. Les journées de la semaine (lundi au vendredi), le Samedi, et enfin le Dimanche et jour férié. Il y a un fichier pour ça dans le format GTFS, mais il est très mal exploité par Kéolis. Il n’y a pas de service type pour 5 jours, un pour le samedi, un pour le dimanche et jours fériés, et d’autres pour les cas spécifiques. À la place, il y a plusieurs fois le même service par jour de circulation. Cela créé des “faux” doublons dans la base, et si vous recherchez la performance, il faut, là encore, faire un travail long et coûteux supplémentaire.

Heureusement, vous pouvez quand même déterminer quels sont les trajets types en poussant vos analyses avec de gros traitements un petit peu plus lourd (à programmer et à exécuter). Autant vous dire que ce n’est pas pour nous rendre la tâche facile.

La faute à qui ? Un peu à GTFS, mais l’utilisation par Kéolis n’est vraiment pas optimale (même si je veux bien croire qu’il y a un effort fourni, j’ai pu en discuter rapidement avec l’ingénieur qui travaille sur le sujet pour Kéolis).

API mon amour

Une autre partie des données est disponible via une API. Ce qui est bien, car cela permet d’obtenir des données en temps réel : prochain passage, disponibilité des vélos, etc. Le soucis, de mon point de vue (d’usager et de développeur), c’est que cette API n’est ni complète ni bien documentée.

Attention, je ne critique pas ici ni l’intention ni l’ouverture des données via une API. C’est une bonne idée et je remercie Rennes, Star et Kéolis de proposer cette API. Mais en tant que développeur, je suis souvent frustré par ce que j’ai à ma disposition.

J’ai d’ailleurs écrit un petit article sur un sujet bien précis au sujet des API : “Pour qui sont les API ?”. Cet article fait suite à la rencontre qui s’est tenue à la Cantine Numérique Rennaise en décembre dernier. Lors de cette rencontre, j’ai présenté mon travail à quelques autres développeurs sur les données.

Travailler avec les données.

Une fois les données en main (façon de parler), j’ai beaucoup travaillé à les rendre réutilisables (pour moi entre autres). Tout d’abord j’ai commencé par l’API, en proposant un client python (pour développeur). Sur la douzaines d’heures que cela représente, je me suis confronté à plusieurs problèmes :

  • L’API est mal documentée. Certes il y a toutes les méthodes appelables, mais la présentation des paramètres, leur usage, etc. est très peu voire parfois pas du tout expliqué. J’ai dû passer plusieurs heures à comprendre comment faire certains appels, pourtant relativement simples une fois le tout posé à plat. Pour l’exemple, ma documentation du client pour Le Velo Star, et la documentation de la méthode principale côté API Kéolis.
  • Détail supplémentaire, la langue de la documentation est un mélange entre l’anglais et le français, ce que je trouve pour le moins surprenant, et ne me donne pas confiance en ce que je lis.
  • L’API ne retourne pas d’erreur lorsqu’il ne peut pas y avoir de contenu. Ce n’est pas normal : si je demande la ligne de bus 7814, je demande une ligne qui n’existe pas, mais l’API ne m’informe pas de mon erreur. Cela peut paraître anecdotique, mais cela induit, encore une fois, un manque de confiance dans les résultats obtenus.
  • En fonction du format de sortie demandé (JSON ou XML), les données ne sont pas toujours identiques. J’ai eu l’occasion de remonter une erreur sur l’API temps réel pour le bus (et elle a été corrigée). C’est inquiétant, parce qu’une API en laquelle on ne peut pas avoir confiance nuit à la qualité générale. S’il y a une erreur sur un cas, rien ne dit qu’il n’y en a pas pour d’autres.
  • Quelques soucis de latences, d’autres soucis avec les formats, les paramètres, la clé de l’application qui passe en clair dans l’url, etc. mais ça devient vraiment très technique.

Mais mon plus gros problème a été le suivant : L’API ne dispose pas de toutes les données. Il faut coupler les appels avec une analyse et un traitement des données à télécharger. Autant dire qu’il est impossible de se reposer naïvement sur une seule source de données.

Objectifs et réalisations

À l’origine je souhaitais simplement tester l’API, comprendre son fonctionnement, et pourquoi pas, proposer un client en python complet, pour que d’autres développeurs puissent, sereinement, reposer toute leur application sur ce client. Lorsque je me suis rendu compte que toutes les données n’étaient pas dans l’API, et qu’une bonne partie devaient être récupérer dans le flux GTFS, je me suis posé quelques questions.

Et j’ai foncé tête baissée dans un WE (environ 16h sur deux jours) de développement de scripts, d’analyses, de traitements et de formatages des données. J’ai ensuite continué quelques jours de plus (environ 20h de plus) à développer un concept d’API REST autour des données complètes (pour information, c’était mi-Décembre 2012).

En un peu moins d’une semaine de travail (aux 35h et des poussières), j’ai obtenu une API qui présente les données statiques du réseau de bus de Rennes, avec ses arrêts de bus, ses lignes, ses trajets et ses heures de passage, le tout avec des données liées les unes aux autres, une structure plus à plat et plus facile à comprendre.

Bref, quelque part, j’ai refait le travail de Kéolis avec ses propres données. Et je ne sais pas quoi en faire.

La motivation après le premier effort

Au début j’étais très motivé. Le sujet me passionne toujours autant aujourd’hui, mais après une semaine de développement, je ne suis plus trop sûr de vouloir continuer.

Parce que si mon objectif de base est à peu près atteint (un client python fonctionnel, bien que largement améliorable), je sens bien qu’il y a beaucoup plus que ça à faire. Et une partie de mon travail d’analyse et de réflexion, je ne suis pas complètement certain que c’est à moi de le faire.

Je m’explique.

Je pense qu’il faut un juste milieu. D’un côté il y a une API et des données à télécharger. De l’autre il y a des développeurs. Je veux bien travailler pour créer des outils pratiques pour les développeurs : client python, php, java, ou que sais-je encore. Je veux bien travailler pour rendre la vie plus facile aux développeurs, avec des outils d’analyses des requêtes, un vérificateur, etc.

Mais je ne veux pas refaire le travail de Kéolis, c’est à dire, refaire une API complète. Peut-être que je vais y venir quand même. Peut-être que d’autres développeurs vont trouver l’idée intéressante finalement, et je les invite à me contacter. Peut-être que, dans tout ça, il y a quelque chose “en plus” à faire, que je n’ai pas vu, pas compris, pas utilisé.

Le premier effort était super, et mes résultats sont très satisfaisants. Aujourd’hui, ma motivation fait défaut face à ce que je considère comme un service à moitié rendu – et je me demande si cela ne soulève pas non plus la question de cette notion de “service rendu” – et des attentes que cela provoque !

J’ai beaucoup d’autres choses à dire sur ces données, notamment sur ce que l’on peut faire avec, ce dont je n’ai pas parlé ici. Mais pour le moment, j’en suis là, avec mes interrogations d’usager et de développeur. Avec mon temps libre vaguement réduit et mes différents projets.

Le mieux peut-être maintenant, c’est de faire comme je le disais le 19 décembre dernier en introduction : discutons !

Edit : Petite annexe sur le “coût” de développement.


Les bibliothèques de Rennes Métropole à l’heure de l’Open Data

Posted on

Depuis 2010, Rennes Métropole s’est lancée dans l’open data et a ouvert des données d’horizons variés. Un domaine reste malgré tout plutôt pauvre, c’est celui de la culture. Pourtant Rennes ne manque pas d’acteurs publics ou privés liés à la culture sous toutes ses formes. Le terreau est riche et fertile.

Un acteur a quand même commencé à proposer certains jeux de données, il s’agit de la bibliothèque des Champs Libres, avec ses statistiques de fréquentations par heure et par jour. Ces données sont intéressantes car elles permettent de percevoir la distribution des visites tout au long de l’année et peut-être en faire des corrélations (va-t-on plus à la bibliothèque lorsqu’il fait froid ? quand il pleut ? le printemps est-il plus propice à la lecture ? etc.). Le Collectif Open Data Rennes s’est d’ailleurs appuyé sur ces données pour en proposer un jeu de visualisations. La culture nourrit la culture.

Néanmoins, nous pensons qu’il y a plus à faire avec l’information qu’une bibliothèque peut générer et manipuler au quotidien: nombre de documents empruntés, retournés, en retard, emprunts par heure ou jour, quelle section d’une bibliothèque est la plus dévalisée. Bien entendu on peut ajouter aussi son catalogue, l’âme d’un tel lieu.

Une approche en douceur

Initialement, lorsque vous souhaitez travailler sur des données d’un acteur public, il est bon de faire un tour sur leur site afin de voir ce qui est accessible, même si ce n’est pas programmatiquement exploitable. Ainsi les Champs Libres possèdent une section évoquant l’histoire et les chiffres, notamment ceux liés à la bibliothèque.

Mais nous parlons d’open data, nous voulons des données structurées. Si aucun jeu de données ou d’API n’est proposés librement par l’acteur public en question, il est temps de prendre contact avec eux pour en discuter. La manière pour le faire dépend très largement de la politique d’ouverture de la commune et des institutions qui en dépendent, ainsi que de l’acteur lui même. Bien entendu, une sensibilisation à l’open data et à ses enjeux est un préalable important pour que l’acteur s’engage dans l’initiative. La prise de contact peut se faire par email mais il est probable qu’une entrevue de visu sera plus productive. Trouver le bon interlocuteur va requérir toute votre sagacité. Dans le cas de la Bibliothèque, ils étaient déjà engagés dans une démarche d’ouverture des statistiques, et nous avons eu la chance de les avoir rencontrés au travers de réunions sur le sujet à la Cantine Numérique Rennaise. Par ailleurs, Léa étant en très bon rapport avec des membres de la bibliothèque facilitant ainsi les premiers échanges.

Ne jamais hésiter à ouvrir la discussion, si vous trouvez le bon interlocuteur.

Un jeu de patience donnant/donnant

Dans le cas où l’acteur répond positivement à la demande d’ouverture de certaines de ses données, vous allez devoir vous armer de patience. En effet, l’existence d’une donnée ne signifie pas qu’elle soit facilement accessible ou exploitable. L’open data demande un effort et un processus qui peut se révéler complexe ou coûteux, au moins en temps.

Par ailleurs, afin de justifier ce surcoût, il est possible que l’acteur public ou privé propose d’abord un jeu de données simples afin de voir l’engouement à son égard. Cela peut faire bondir les défenseurs de l’open data qui estiment que les données ne doivent pas être prises en otage, mais le pragmatisme est de mise dans l’action publique. Par conséquent, un jeu de donnée basique attisant les appétits, il peut se révéler judicieux de montrer qu’il y a effectivement une attente réelle pour plus de données. Le collectif, sous l’impulsion de Léa, a ainsi proposé l’opération #biblioviz.

Une fois que la discussion est engagée, il convient alors de faire un état des lieux des données qu’une bibliothèque manipule et celles qui peuvent intéresser la collectivité, et enfin lesquelles entrent dans le cadre légal de l’open data.

Des contraintes à prévoir

Techniques

Les communes possèdent des fonds patrimoniaux bien antérieurs aux nouvelles technologies sans parler des mouvements d’ouvertures comme l’open data, l’open content, voire l’opensource et le logiciel libre (on parle de dizaines d’années pour les logiciels, et des centaines d’années pour certain bien du patrimoine). Ces considérations ne sont pas entrées en ligne de compte dans les appels d’offres de logiciels tels que les SIGB. Par conséquent, il est fort à parier que le logiciel équipant votre bibliothèque soit fermé (qu’il soit privateur ou privé, en tout cas non-libre d’accès). Cela pose des difficultés certaines pour l’ouverture des données, sans parler de requérir parfois une licence spécifique d’un montant substantiel. C’est le cas des bibliothèques des Rennes Métropole et ce qui a poussé le collectif à contourner cette contrainte en aspirant le catalogue via le moteur de recherche. Nous y reviendrons dans un prochain article.

Légales et politiques

La culture n’est pas un domaine simple lorsqu’il s’agit d’accéder à des données. Celles-ci sont gardées jalousement et/ou sont simplement trop complexes et coûteuses à rendre disponibles. Par ailleurs, la culture est le monde du droit : droit d’auteur, droits voisins, etc. Il peut se révéler très complexe pour un acteur de savoir comment l’open data s’inscrit dans ce contexte. Dans tous les cas, les acteurs de la culture se doivent d’être prudents avec les données, car il peut ne pas leur appartenir le droit de les mettre à disposition.

Compétences métier

Comme tout domaine, la bibliothèque a ses métiers, avec ses codes, ses règles, et son vocabulaire. Lorsque le Collectif a rencontré la Bibliothèque, il a d’abord fallu expliquer certain termes employés (rien que SIGB par exemple). De même, les données peuvent être classées et codifiées selon une norme spécifique à un métier. Cette contrainte est indéniablement une occasion de s’intéresser et de discuter du métier de la bibliothèque, et d’écouter ses acteurs et ses professionnels.

Demandeur mais aussi acteur

La démarche de l’open data doit se faire avec de la patience au ventre. Il est en effet indispensable de se remémorer que les acteurs publics ou privés, même lorsqu’ils sont moteurs, prendront le temps qu’il faut pour libérer leurs données. Il existe un temps incompressible dont il faut tenir compte, et prendre patience afin de respecter le planning des différents interlocuteurs.

Malgré tout, il est possible, comme avec le catalogue des bibliothèques, de déjà vous faire une idée des données que vous pourriez traiter et ainsi aiguiller votre interlocuteur.

L’opendata propose au citoyen un outil supplémentaire pour agir sur sa vie locale.

Conclusion

Les bibliothèques de Rennes Métropole semblent accueillir avec bienveillance l’idée d’un accès à leurs données. Mais pour des raisons de contraintes techniques liées à leur SIGB ainsi qu’à des impératifs liés à leur planning, il apparaît clair au Collectif qu’une partie du travail devra se faire par des moyens indirects tels que nous évoquions plus haut. Nous présenterons ce travail lors d’un prochain article.


Une cartographie des jardins potagers des rennais

Posted on

Quelles sont les habitudes potagères des habitants de Rennes Métropole ? Est-ce qu’ils font pousser des fruits et légumes dans leur jardin, est-ce qu’ils échangent leur productions ? Existe-t-il des réseaux de partage de denrées locales ?

Ce sont les questions que se posait Bernadette Kessler, responsable du service Innovation Numérique de Rennes Métropole, lorsqu’elle a proposé au collectif Open Data Rennes et Rennes1720 de réaliser une cartographie collaborative durant l’évènement Viva-Cités, fin septembre.

L’idée ? Afficher une grande carte de la métropole et proposer aux visiteurs de venir ajouter leur contribution, sous forme d’une punaise plantée sur leur lieu -approximatif- d’habitation.

“Alors j’ai des tomates, des fraises, des carottes, ah et aussi de la menthe sur le balcon”

Lorsque les visiteurs approchaient de la carte, deux questions leur étaient posées :

  • Combien de variétés de fruits, légumes et plantes aromatiques cultivez-vous chez vous ?
  • Quel usage global en faites-vous ?

A cette deuxième question nous proposions trois réponses : garder (pour un usage personnel et familial), donner (régulièrement à des amis, collègues, voisins) ou vendre.

Sur les neuf jours de l’évènement, plus de 120 habitants de Rennes Métropole ont participé à l’expérience et apposé leur punaise sur la carte. Une grande majorité de Rennes même, des habitants des communes de l’agglomération, et même quelques visiteurs venus de plus loin qui ont quand même voulu apporter leur contribution… tant que leur commune était visible sur la carte !

La carte en ligne

Une fois Viva-Cités terminé, nous avons numérisé les participations afin de reconstituer une carte en ligne, que voici. (cliquer pour accéder à la carte dynamique)
CarteJardinsOSM

Légende :

De 1 à 5 variétés produites

De 6 à 15 variétés

Plus de 15 variétés

Blanc : je garde / Vert : je donne / Rouge : je vends (cette option n’a jamais été donnée par les participants)
Remarque : compte tenu de l’échelle de la carte d’origine, l’emplacement des points est approximatif. Ils ne pointent pas exactement le jardin de chacun mais restent représentatifs de la rue ou du quartier choisi.

“Bien sûr, je donne quand j’en ai trop. A mes voisins surtout, on s’échange des légumes”

Le panel de participants est trop petit pour pouvoir tirer de véritables conclusions statistiques sur les usages des rennais et de leurs potagers. Néanmoins, au travers des résultats obtenus et de tous les témoignages que nous avons recueillis, nous pouvons tout de même proposer des pistes de réflexion sur le sujet.

De nombreux habitants cultivent des végétaux consommables, en ville comme en campagne, ne serait-ce qu’un pot de thym ou de ciboulette sur le balcon. Nous n’avons eu que peu de visiteurs qui déclaraient ne rien faire pousser chez eux, et les réponses étaient le plus souvent de la forme “j’aimerais bien” ou “je viens d’emménager, mais je vais m’y mettre !”

Ceux qui cultivent peu de produits ont plutôt tendance à les garder pour eux. Même si notre expérience étudiait le nombre de variétés produites, et non pas la quantité, les deux vont souvent de paire. Et cela paraît logique : celui qui ne récolte que quelques tomates dans l’année va les garder pour un usage personnel, tandis que les personnes qui font pousser de multiples légumes auront plus de facilité à donner ou échanger autour d’eux.

Cela suffit-il à expliquer le fait que, d’après nos résultats, les habitants du centre-ville de Rennes ne donnent que peu leurs fruits et légumes ? Pas forcément. L’ambiance urbaine, ne pas connaître ses voisins, ne pas savoir avec qui échanger… sont aussi des pistes à creuser pour améliorer ou créer cet esprit de partage entre les résidents d’une même zone.

Cependant, l’un des quartiers de Rennes s’est fait remarquer lors de notre expérience : Sainte-Thérèse, quartier résidentiel au sud-est de la ville, semble être un lieu très vivant, très potager, où les habitants de “ce petit village”, dixit un de nos visiteurs, se connaissent et n’hésite pas à partager entre eux les fruits de leurs cultures saisonnières. Nous avons d’ailleurs rencontré plusieurs membres de l’association Les Jardins (ou)verts, dont nous avions sans le savoir emprunté le nom pour notre opération. Les Jardiniers cherchent à développer le locavorisme (consommer des produits locaux) et la protection de l’environnement, tout en créant du lien social. Opération réussie au vu des témoignages des habitants de Sainte-Thérèse !

A la découverte des usages

Dès la conception de l’expérience, nous nous sommes rendus compte qu’il serait impossible de détailler précisément toutes les données : chaque plante cultivée, chaque utilisation, pour chaque participant, cela n’aurait pas été lisible sur la carte. Nous avons donc fait le choix de conserver seulement trois données, le nombre de variétés, l’usage global et la localisation.

Cependant, dès l’arrivée des premiers visiteurs, nous avons découvert de multiples cas auxquels nous n’avions pas pensé. “Moi je fais du troc, alors je choisis donner ou vendre ?” “Et le don de graines, ça compte ?” Untel fait partie d’un jardin familial, un autre partage le sien avec ses voisins, un troisième squatte illégalement un bout de terrain inoccupé pour faire pousser ses légumes. Autant d’usages qui font la diversité de l’expérience.

Une habitante du quartier Sainte-Thérèse nous racontait par exemple qu’elle produit plus d’une trentaine de variétés de plantes aromatiques, qu’elle dépose sur le bord de la route avec un “pot d’honnêteté” où les passants sont invités à déposer une pièce ou deux après s’être servis. On n’est plus très loin du concept britannique des incredible edible, jardiner collectivement dans l’espace public et partager avec tous les fruits et légumes qui n’auront pas traversé le pays pour venir être mangés.

Le sujet des jardins familiaux est également beaucoup revenu dans les conversations, l’affaire des prairies Saint Martin ayant marqué les esprits.

Une expérience à renouveler

Collecter des informations individuelles avec les participants, pour construire une base de données, cela s’appelle du crowdsourcing. Ce mode de collecte existe sous bien d’autres formes et dans de nombreux domaines.

Lors de cette expérience, nous avons pu constater que le thème des jardins et potagers a attiré des publics très divers, sans connaissances particulières du crowdsourcing ou de l’open data. C’est également la conclusion de Simon Chignard qui a mené lors de Viva-Cités trois ateliers sur des thématiques diverses : choisir un angle précis et concret permet d’aborder en toute simplicité avec le public le sujet encore pointu de l’open data.

De plus, nous avions choisi de présenter la carte sur une structure physique : pas d’outil numérique, rien que du papier, du liège et des punaises. En enlevant cette barrière numérique, nous avons pu ainsi toucher tous les publics présents lors de l’évènement, ce qui aurait été plus difficile avec un écran d’ordinateur, un clavier ou une souris à appréhender avant de pouvoir ajouter un point sur la carte. Nous avons déjà constaté lors de notre atelier avec des élèves de CE2-CM1 que l’outil numérique n’est pas forcément nécessaire pour parler d’open data ou de visualisation des données.

Au vu des bons résultats de l’expérience et des retours enthousiastes, nous envisageons déjà de recommencer cette opération, pourquoi pas dans un autre cadre (un quartier précis de Rennes) ou sur d’autres sujets.

Partage et diffusion des résultats

Les données collectées lors de l’opération Jardin Ouvert sont rassemblées sous forme d’un fichier KML. Nous le proposons en open data, sous la licence “Licence Ouverte” : vous êtes libre de réutiliser, tranformer, republier ce fichier, à condition de mentionner l’auteur et la source de ces données (collectif Open Data Rennes).

Télécharger le fichier source .kml
Voir la carte sur Google Maps
Voir la carte sur Open Street Map

Les photos ainsi que les visuels de cet article sont publiés sous licence Creative Commons BY-SA : vous êtes libre de réutiliser, transformer, republier ces fichier, à condition d’en mentionner l’auteur (collectif Open Data Rennes) et de rediffuser les documents sous la même licence.


La dataviz et les enfants

Posted on

Comment parler de données et d’open data à de jeunes enfants ? Comment faire appréhender la visualisation de données à une classe de CE2 ?

C’est le défi que le collectif a relevé mardi dernier lors de l’évènement Viva-Cités. Un atelier ludique, sans outils numériques, pour faire découvrir à notre jeune public les joies de la dataviz.

Photo : Christophe Simonato, Ville de Rennes (source)

Ce matin-là, une classe de CE2 et CM1 d’une école de Rennes a découvert le village numérique de Viva-Cités. Alors que le premier groupe s’essayait à l’assemblage d’éléments électroniques sur le LabFab, le second s’est initié à la visualisation de données avec le collectif Open Data Rennes.

Notre objectif était de leur faire manipuler et mettre en forme des données. Sans imaginer les faire devenir de vrais designers en une heure, il s’agissait de leur faire rencontrer pour la première fois différentes manières de représenter l’information.

Pour cela, les deux piliers de notre atelier étaient les suivants :

  • faire manipuler des informations concrètes, simples, qui parlent aux enfants et faciles à décompter
  • oublier les outils numériques pour ce concentrer sur des objets manipulables : Legos, feutres et papier ont été nos supports de travail.

Une séance de découverte des données

Réunis autour d’une grande table, les douze enfants ont reçu un support papier sur lequel étaient préparées les formes des visualisations : cases à cocher, graphiques en barre, camemberts.

Après une rapide définition du mot “donnée”, nous sommes rentrés dans le vif du sujet. Nous avons abordé plusieurs thématiques au cours de l’atelier. Des caractéristiques visibles (garçon ou fille, lunettes ou pas ?) à des informations plus personnelles (le nombre de personnes vivant dans la maison, le nombre d’écrans de télévision), et les animaux de compagnie des enfants.

Pour chaque thème proposé, les enfants commençaient par construire leur information personnelle, et la reporter sur le support. Ils manipulaient également des pièces de Lego, en fonction de la donnée (une verte ou une orange pour le genre, autant de pièces que de télés…).

Ensuite, par petit groupe de 3 ou 4, nous avons regroupé ces informations et nous avons pu en faire une première visualisation. Les cinq animateurs du collectif ont accompagné les enfants dans leur appréhension des concepts.

Enfin, avec l’intégralité du groupe, nous avons repris certaines informations pour les rassembler, les ajouter, les comparer, les représenter. Est-ce qu’il y a plus de garçons ou de filles ? Combien d’enfants ont à la fois un chat et un chien ?

Nous avons conclu l’atelier en évoquant les données publiques, et en montrant l’application Qui sommes-nous ?, qui représentent à partir de données INSEE les différentes populations de Rennes Métropole.

Mission accomplie !

Faire appréhender la représentation de données à des élèves de primaire, qui n’ont pas encore acquis toutes les connaissances en mathématiques qui nous semblaient à la base indispensables (fractions, pourcentages), était un défi intéressant que nous avons relevé de notre mieux.

Les ateliers se sont très bien déroulés, les enfants intéressés, et d’ailleurs leur enseignant aussi !

Du côté des animateurs, l’avis est unanime : une expérience très intéressante, que nous aimerions renouveler à l’avenir, avec bien sûr des améliorations à apporter au support et à notre pratique.

L’expérience prouve dans tous les cas que quelque soit le public visé, les concepts d’open data et de dataviz sont plus attrayants et plus simples à expliquer lorsque l’on part avec un angle concret, une thématique à laquelle les participants s’intéressent et peuvent s’identifier.

Si vous souhaitez en savoir plus sur le contenu de l’atelier, ou les sessions que nous pouvons proposer, n’hésitez pas à nous contacter à opendatarennes @ gmail.com.

Le support que nous avons utilisé est à votre disposition, sous licence Creative Commons BY-SA. Vous pouvez télécharger le fichier .pdf ou le fichier source .svg, vous pouvez le partager, le modifier et le réutiliser à condition de citer l’auteur (collectif Open Data Rennes) et de rediffuser les documents sous la même licence.

collectif Open Data Rennes, CC-BY-SA


Opération #biblioviz : visualiser les données de la Bibliothèque

Posted on

Suite à la publication en open data des statistiques de fréquentation de la bibliothèque de Rennes Métropole, le collectif Open Data Rennes propose à chacun de s’emparer de ces informations pour les mettre en forme, les visualiser, les transformer… passionnés de dataviz, créatifs ou bidouilleurs, ceci est pour vous !

A partir du 1er juillet, nous invitons toutes les personnes à participer à l’opération en inventant une nouvelle manière de mettre en forme les données. Cela peut être une infographie, un dessin, une application, un site web, une vidéo, un assemblage d’objets… place à la créativité, tout est permis.

Retrouvez toutes les informations sur l’opération, les données et les réalisations, et n’oubliez pas de partager l’info.

A bientôt,

Léa / Auregann pour le collectif Open Data Rennes


Dataviz autour des résultats du 1er tour à Rennes

Posted on

Bonjour à tous,

Le blog du collectif n’est pas uniquement là pour annoncer les rencontres et en faire le compte-rendu ! Nous souhaitons aussi laisser la parole aux utilisateurs des données. Vous voulez présenter un projet, une idée, une application ou visualisation à partir des données open data ? Envoyez nous un petit mail à opendatarennes at gmail point com pour avoir un accès au blog.

Pour commencer, je me lance avec un petit essai de datavisualisation des données électorales.

Suite au premier tour des élections présidentielles et à la mise en ligne en open data des résultats complets par bureaux de vote à Rennes, j’ai tenter de visualiser et mettre en forme ces résultats.
J’y ai passé peu de temps et je ne suis loin d’être une experte en analyses politiques, aussi ce ne sont que quelques idées très simples qui ne demandent qu’à être améliorées.

Résultats des votes exprimés par canton

Attention : chaque canton limitrophe englobe également une petite partie de la commune voisine. Comme nous n’avons que les résultats de la ville de Rennes, ces cantons sont donc incomplets.

Il est connu que Rennes est une ville de gauche, et donc peu surprenant que le candidat arrivé en tête dans tous les cantons soit François Hollande.
Cependant, les proportions varient tout de même d’un canton à l’autre. On peut remarquer par exemple que le Centre a le plus fort pourcentage de votes Sarkozy, ou encore que Bayrou arrive en troisième place à Bréquigny et au Blosne.

Méthode : j’ai redessiné un fond de carte vectoriel à partir d’une carte existante. J’ai généré les graphiques camembert avec l’outil proposé par Google Documents, à partir des résultats bruts du jeu de données, qui propose les résultats par canton.

Résultats des votes exprimés par canton, bis

Pour tenter de mieux visualiser les différences de votes entre les cantons, j’ai repris les mêmes données mais cette fois sous forme de graphique à barres horizontales. J’ai tenté de classer les candidats par orientation gauche-droite, et j’ai arbitrairement décidé de trier les cantons en fonction du pourcentage obtenu par Hollande, arrivé en tête dans tous les cantons.

Ce graphique a également été généré avec Google Docs.

Candidat arrivé en tête dans chaque lieu de vote

Il y a 29 lieux de vote à Rennes, regroupant chacun entre 2 et 7 bureaux. Inspirée par la visualisation de Mounir et Simon, j’ai voulu représenter chaque lieu de vote par la couleur de son candidat favori, arrivé en tête dans ce lieu de vote.
Travail assez rapide : lors de ce scrutin, si six bureaux ont récolté une majorité de votes pour Sarkozy, au final seulement deux lieux de vote ont une majorité UMP : Clotilde Vautier (canton Nord) et Jean Zay (canton Centre). Le reste est pour Hollande.

Pourcentages de participation par canton

Enfin, je me suis intéressée à l’absention des rennais pour ce premier tour. Avec un taux de participation de 80,33%, nous sommes dans la moyenne nationale.
J’ai extrait du jeu de données les pourcentages de participation par canton, et les ai répartis sur la carte (arrondis au point) en appliquant une échelle de couleur. Elle est volontairement accentuée, mais il n’y a finalement que 7 points de différence entre les deux extrêmes.

Source originelle de l’article

Le contenu de cet article est sous licence CC-BY-SA : n’hésitez pas à le partager et le modifier, en n’oubliant pas de citer l’auteur.

Vous pouvez notamment télécharger et modifier le fond de carte, au format SVG, sur Wikimedia Commons.

Rennes1720 s’est également intéressés aux résultats du premier tour des présidentielles à Rennes :: voir l’article Où a-t-on le plus voté FN à Rennes ?

@Auregann


Rencontre du 22 février : le thème sera “politique et citoyens”

Posted on

Bonjour à tous !

Comme vous le savez (ou pas), la prochaine rencontre du collectif aura lieu le mercredi 22 février, à partir de 18h30 à la Cantine Numérique.

Je vous remercie encore une fois pour l’intérêt que vous portez au projet et votre présence en nombre à la rencontre de janvier.

Afin de structurer un peu ces rencontres, je vous propose de choisir un thème pour les rendez-vous à venir. Cela permettra d’encadrer et d’affiner les projets sur lesquels nous travaillerons pendant cette rencontre.

Cela ne se veut pas être une restriction, ni frustrer les porteurs de projets, aussi, si vous avez une idée géniale à nous proposer, vous pourrez quand même le faire durant la rencontre. Les projets portant sur le thème de la session seront simplement prioritaires.

Bien sûr, le choix des thèmes est collaboratif, j’ai donc créé une page sur le wiki où vous pouvez voter pour le thème de la prochaine rencontre. Vous pouvez même décider de ne pas avoir de thème ;)

En extrapolant sur les centres d’intérêt des participants à la précédente rencontre, nous avons choisi pour la rencontre du 22 février le sujet “politique et citoyens”.

C’est un thème assez vaste qui peut toucher autant les actions politiques, les actions citoyennes, la manière dont les habitants voient la politique, les élections, les partis…

Nous vous proposons donc de venir avec vos idées, vos envies, vos questions, et nous aborderons tous ces sujets lors de la rencontre du 22 février.

Voici les projets déjà en cours de réflexion sur le wiki :

Nos élus rennais (idée présentée lors de la dernière rencontre par Julien)
Projet de cartographie des institutions publiques

Mais également  :

  • et si on avait les chiffres résultats des élections en open data ?
  • et si on avait les arrêtés municipaux ?
  • et si on avait les compte-rendus des conseils municipaux ?

…et toutes les idées que vous nous présenterez.

En attendant le 22, n’hésitez pas à venir enrichir les projets sur le wiki, voire en créer de nouveaux. Vous pouvez également enrichir la liste des données à ouvrir.

Si vous avez le moindre souci, ou encore des questions, vous pouvez me contacter via @opendatarennes sur Twitter ou par mail.

A très bientôt pour faire bouger l’open data rennais !


Création d’une liste de propositions de données

Posted on

Bonjour à tous,

En attendant notre prochain rendez-vous, le collectif Open Data Rennes vous propose de participer à la création collaborative d’une liste de données que vous souhaiteriez voir libérées par les collectivités locales.

Pour cela, nous avons créé un wiki. Un wiki est un ensemble de pages web accessibles et modifiables par tous, sur lequel nous vous invitons à créer des pages pour vos projets et inviter les autres membres à vous aider à réfléchir et construire vos idées.

La page Liste des données vous permet d’ajouter des propositions, de détailler votre idée et enfin de voter pour les propositions que vous trouvez pertinentes.

Cette liste ne constitue ni une demande aux collectivités, ni une promesse vis à vis des réutilisateurs : elle nous sert simplement à réfléchir sur nos besoins, et dans un second temps pourra être utilisée lors de dialogues avec les collectivités.

Merci de bien lire l’introduction de la page avant de vous lancer, n’hésitez pas également à consulter l’aide de Wikia si vous avez un problème pour éditer des pages. Enfin, pour une gestion plus simple du wiki, nous vous conseillons de vous créer un compte, mais cela n’est pas obligatoire pour participer.

A très bientôt,

Auregann