Olivier Mengué – Code & rando

Je viens de découvrir ce soir que la Mairie de Paris a commencé une expérimentation de diffusion de contenu par Bluetooth à partir des stations Vélib’ : le Paris Bluetooth MobiGuide. Voici mes premières réactions, plutôt d'un point de vue technique (comme souvent ici), c'est à dire sur la forme plutôt que sur le fond et notamment du point de vue d'un utilisateur de Nokia N800.

Il y a quelques mois j'avais déjà reçu par Bluetooth une image JPEG de l'affiche du film Spiderman 3 en passant à coté d'un panneau d'affichage sur le boulevard Haussmann. J'ai repéré un panneau semblable du côté de la rue de la Gaîté. Dans le cas du MobiGuide, c'est potentiellement, pour le récepteur, une utilisation plus intéressante de la technologie Bluetooth.

Le MobiGuide est disponible de plusieurs façons :

• pour consultation hors-ligne sur un téléphone mobile, sous la forme d'une application Java à installer après téléchargement :
  • par diffusion vers le téléphone mobile depuis des fontaines Bluetooth placées à des stations Vélib' ;
  • par téléchargement depuis en allant naviguer sur http://mobile.paris.fr/ ;
  • par téléchargement avec un ordinateur sur paris.fr ;
• par consultation en ligne sur http://mobile.paris.fr/.

Ma première réaction : malgré la multiplicité des moyens d'accès, aucun ne me permet d'accéder facilement au MobiGuide avec les appareils dont je dispose :

• L'application Java ne fonctionne que sur appareils mobiles, pas sur PC.
• Le Nokia N800 est un appareil mobile qui dispose d'un chip Bluetooth, mais il n'a pas de machine virtuelle Java.
• Mon téléphone mobile (Nokia 3100) n'a pas la capacité mémoire suffisante pour stocker l'application. 300 Ko, c'est trop pour lui !
• Le site en ligne est inaccessible aux navigateurs web standards à cause d'un bête problème de configuration du serveur :

  C:\>curl -I http://www.v2asp.paris.fr/v2/mobile/bluetooth/site_PB1er/index.xhtml
  HTTP/1.1 200 OK
  Server: Microsoft-IIS/5.0
  Date: Sun, 02 Sep 2007 22:04:48 GMT
  Content-Type: application/octet-stream
  Accept-Ranges: bytes
  Last-Modified: Mon, 30 Jul 2007 14:25:45 GMT
  ETag: "20399984b5d2c71:86e"
  Content-Length: 1383

  Le Content-Type devrait être « application/xhtml+xml; charset=iso-8859-1 ». Ce simple paramètre bloque la consultation sur le N800 ou sur un PC (MSIE, Firefox) : au lieu de simplement montrer le fichier, le navigateur propose de le télécharger. Quant aux téléphones mobiles, le navigateur intégré de mon Nokia 3100 indique « Réponse inconnue », et Opera Mini signale « Opera Mini Basic ne supporte pas les téléchargements. Ignore "index.xhtml" avec le type "application/octet-stream". »

Je suis finalement arrivé (mais c'est laborieux) à accéder au contenu hors-ligne entièrement depuis mon N800 en bidouillant ainsi :

1. téléchargement par wifi de Paris1.jar (j'aurais aussi pu aller me rendre à une fontaine Bluetooth pour récupérer le fichier, mais bon, j'habite pas à côté) ;
2. renommage de Paris1.jar en Paris1.zip ;
3. décompression de Paris1.zip dans le répertoire Paris1 ;
4. lancement du navigateur web (l'extension .xhtml n'est pas reconnue directement depuis le Gestionnaire de fichiers) ;
5. menu Page Web, Ouvrir fichier... pour ouvrir Paris1/microsite/index.xhtml ;
6. ça y est ! J'accède au contenu XHTML.

Le résultat : j'obtiens un site qui ne prend même pas un quart de l'écran parce que la largeur est fixée en dur sur chaque page à 176 pixels (alors que l'écran du N800 fait 800 pixels). Et j'aboutis à des impasses telles que http://www.v2asp.paris.fr/v2/mobile/bluetooth/site_PB1er/622_ballades.xhtml où les liens pointent vers des fichiers texte qui sont probablement utilisés par l'application Java pour afficher des cartes, mais qui ne sont visibles ni dans le N800 ni sur le PC.

En résumé, c'est plutôt un fiasco. Faut que ça mûrisse encore pour être disponible sur un plus grand nombre de plateformes.

Le site Vélib’ utilise des services web pour afficher les informations sur les stations :

• la liste statique des stations : numéro, nom, adresse, latitude, longitude ;
• les informations dynamiques sur une station : vélos disponibles, emplacements libres, impression de tickets.

Voilà donc une occasion d'expérimenter Yahoo! Pipes, l'application web de développement et d'hébergement de scripts de traitement de données du web.

J'ai réalisé ces quelques « pipes » utilisant les services web Vélib’ :

• des tuyaux orientés utilisateur final (tags : Vélib’, Paris) :
  • Vélib’ : disponibilité de plusieurs stations : afficher d'un coup le nombre de vélos et de places disponibles sur 1 à 4 stations. Mieux que sur le site officiel !
  • Vélib’ : localiser une station par son numéro
  • Vélib’ : toutes les stations : la liste des stations avec leurs coordonnées dans le format attendu par Yahoo! Pipes pour l'affichage sur une carte.
• des tuyaux orientés développeur, c.à.d. des interfaces Yahoo! Pipes à réutiliser (tags : Vélib’, Paris, api) :
  • API Vélib’ : infos statiques station brutes
  • API Vélib’ : infos dynamiques station brutes

J'ai voulu créer un pipe recherchant toutes les stations autour d'une adresse donnée. Récupérer une adresse est facile avec le tuyau Location Builder. Mais j'ai rencontré un obstacle insurmontable lorsque j'ai voulu comparer les coordonnées latitude/longitude obtenues avec celles des stations : il impossible de manipuler des nombres flottants et même de convertir du texte en nombre.

Bilan de cette utilisation de Yahoo! Pipes dans Firefox globalement positif :

• Le concept est génial : c'est la programmation fonctionnelle appliquée aux données structurées du web !
• L'interface d'enchaînement des tuyaux est très intuitive. Le drag'n drop est parfait : on oublie que l'on est dans une appli web et on est vraiment dans un outil de développement.
• Le debogueur est génial ! On visualise facilement le résultat de chaque étape de la plomberie.
• C'est bien plus facile à développer et déboguer que XSLT !

Néanmoins l'étiquette « beta » reste de rigueur :

• l'API, c.à.d. la liste des tuyaux disponibles, n'est pas très intuitive : je n'ai pas compris la logique du classement
• la documentation des tuyaux est inexistante : Yahoo! ne propose qu'un exemple comme forme de documentation.
• la documentation de l'affichage de la sortie des tuyaux est aussi inexistante : les éléments title ou y:location.lat/y:location/lon sont particuliers dans l'affichage final, mais il n'existe nulle part de liste complète de ces éléments.
• l'API est plutôt incomplète : j'aimerais pouvoir traiter des nombres flottants tels que des coordonnées (latitude, longitude)
• les regex soit-disant « Perl-like » ne le sont pas. Par exemple \L fonctionne pour mettre en minuscules, mais pas \E. Et comme rien n'est documenté...
• les transformations de types sont laborieuses : le concept d'« item » est nouveau par rapport à d'autres langages de programmation, mais n'est expliqué nulle part. C'est un Item builder qu'il faut utiliser pour convertir du texte en item, mais il est rangé dans la catégorie des Sources. La réorganisation de l'arbre d'un item se fait en utilisant un tuyau Rename. Et il est impossible de convertir du texte en nombre...

Il y a une semaine, j'ai souscrit un abonnement Vélib’ 7 jours attaché à mon passe Navigo.

Le bilan est simple : je suis accro ! Vélib’ est le complément idéal au métro, et même un substitut pour certains trajets. Et puis c'est aussi LE vélo du geek : les clés d'antivol, c'est has-been ! C'est la magie du passe sans contact qui libère le vélo. Enfin, cela me donne l'occasion d'utiliser mon N800 comme jamais !

J'avais emprunté 5 vélos dès le premier jour, mardi dernier. Je me suis calmé ensuite en m'en tenant à 2 par jour. Pour le dernier jour, j'en ai emprunté 8 !!! Un ce matin pour mon trajet habituel de la Gare d'Austerlitz aux Gobelins, malgré la petite pluie (j'ai pu constater comment cela effraye les utilisateurs : les stations étaient quasiment pleines). Deux ce midi pour aller faire une course du côté de la rue Montgallet. Et cinq ce soir pour une rando Vélib’ à travers Paris, en alternant vélo et marche à pied, de façon à rester dans la limite des 30 minutes gratuites et à laisser passer 10 minutes entre deux emprunts. Le point culminant fut l'ascension de la Bute Montmarte, avec un passage devant le Sacré Cœur. Un peu plus tard j'ai pu frimer avec mon plan électronique des stations lorsqu'un autre cycliste m'a demandé si je savais où étais la station la plus proche. Mais j'ai merdé sur l'un des trajets : je n'ai pas vu le temps passer le long du canal Saint-Martin et j'ai rendu le vélo à 30 minutes et 42 secondes (j'ai le reçu), donc 1 € facturé, d'après la consultation de mon compte sur la borne. On verra si c'est effectivement débité.

J'ai pu mettre en action le GPS Bluetooth Globalsat BT-359W acheté ce midi. Très petit, il tient dans la poche de chemise. Il a été directement détecté par le Nokia N800 et a presque immédiatement alimenté Maemo Mapper (le temps de « fix » initial m'a un peu fait peur). Heureusement parce que le seul logiciel de diagnostic fourni est un logiciel pour Pocket PC, donc d'aucune utilité pour moi.

Le GPS est l'outil indispensable pour optimiser ma balade dans des quartiers que je ne connais pas. Je peux profiter au maximum des 30 minutes de vélos (le GPS permet d'éviter de chercher les noms des rues sur le terrain puis sur le plan) en localisant à la dernière minute la station la plus proche. Ensuite, marche ou flânerie (selon le quartier) de 10/15 minutes vers une autre station pour reprendre un vélo. Le tout sauvegardé en trace GPX. Enfin presque tout, car Maemo Mapper a planté et m'a donc perdu la première heure de trace. Il a aussi tendance à planter lorsque j'éteins le GPS.

Le GPS m'a servi également à collecter les « vraies » coordonnées de quelques stations. En effet certaines coordonnées de stations sont incorrectes sur le site web. Celle de la rue du Chevaleret (13054) par exemple.

J'ai eu plus de mal à configurer l'accès au GPS depuis Ubuntu. Alors que tout était graphique sur le N800, la configuration sur Ubuntu est manuelle : il faut récupérer l'adresse MAC du périphérique (sudo hcitool scan) et le numéro de canal (sudo sdptool records), éditer /etc/bluetooth/rfcomm.conf pour ajouter la définition de rfcomm0 et enfin lancer la création du périphérique (sudo rfcomm bind /dev/rfcomm0). On peut vérifier que ça fonctionne avec « cat /dev/rfcomm0 ».