neogeo

C’est bien connu, à Toulouse nous ne sommes jamais en retard d’une mode parisienne. Le Vélô, version locale du Vélib’ a donc fait son apparition mi-novembre dans les rues de la Ville Rose, le ô étant là pour rappeler l’inoubliable Ô Toulouse du regretté Claude Nougaro.

Pour permettre aux toulousains de repérer facilement la station la plus proche de chez eux, j’ai réalisé une petite application avec OpenLayers. Les fonds de plan sont issus du service WMS de Geosignal. Les emplacements des stations de Vélô sont issus de la mairie de Toulouse. Pour les exploiter sur le serveur de ce site, dépourvu de serveur cartographique, je les ai transformées au format GeoJSON (au passage, merci à Pierre Giraud pour ses lumières), dans un fichier texte donc, qu’OpenLayers exploite directement depuis une requête XMLHttpRequest. Il y a aussi un fichier KML pour visualiser tout ça dans vous savez quoi.

Sean Gillies n’est pas un plaisantin. Quand il s’attaque à un sujet, ce n’est pas pour faire un truc qui clignote en vous donnant l’heure. Alors quand il s’est penché sur l’implémentation d’OGR en Python, qu’il trouvait médiocre dans sa version native, il a déjà réfléchi plusieurs jours, savoir s’il vallait mieux utiliser CTypes ou Cython pour lier la librairie C native. Le genre de sujet qu’on lui laisse avec soulagement. Mais quand il teste l’ami Sean, il ne se contente pas de dire “Ctypes sucks dude…”, il sort des statistiques :

Refinery (with ctypes): 4972288.61 usec/pass

Ogre (Cython/Pyrex) : 682301.81 usec/pass

ogr.py (old-school bindings) : 9183181.72 usec/pass

Le coup du old-school bindings en a énervé quelques-uns, qui ont fait remarquer qu’il avait utilisé une vieille version d’OGR. Trop facile ! Mais avec la nouvelle, même si celle-ci est 15 fois plus rapide que la précédente (bravo Howard), Cython garde le dessus :

Refinery (with ctypes)
4994133.40 usec/pass

Ogre (Cython/Pyrex)
593522.91 usec/pass

ogr.py (next generation bindings)
594103.50 usec/pass

De cette implémentation efficace avec Cython, Sean a fait un premier prototype, WordMill. Quelques exemples permettent de se rendre compte de la souplesse du programme. La définition d’un workspace (répertoire de données) suffit à permettre l’accès à toutes les sources de données supportées par OGR qui s’y trouvent, et de parcourir ainsi les fichiers et leur contenu de manière transparente quant à leur format, sans appel à un driver particulier et à travers des structures simples. On peut ainsi accéder aux données, les interroger, les filtrer très efficacement. De la belle ouvrage, doublée d’une installation simplissime. Chapeau Sean !

Chez GoogleMaps, on sait combien la géolocalisation est souvent un exercice difficile, dans lequel la fantaisie du réel sait déjouer les finesses des meilleurs algorithmes. Mais chez GoogleMaps, on a des idées, on paie même des gens rien que pour ça. Plutôt que de faire venir des étudiants tchèques et les coller au volant d’un minibus suréquipé pour alimenter sa base d’adresses, GoogleMaps a eu cette lumineuse idée de NOUS mettre TOUS au boulot. Une nouvelle fonctionnalité de GoogleMaps permet en effet de déplacer les marqueurs d’adresse à un emplacement plus opportun (fonction limitée actuellement aux USA, Australie et Nouvelle-Zélande). Comme ça chacun peut rectifier lui-même les adresses qu’il recherche. Au-delà d’un déplacement de 200m le système se méfie quand-même, c’est qu’il y a des farceurs sur la Toile, et prévient qu’une validation sera nécessaire.  Cependant, dans le rayon des 200m, on peut faire ce qu’on veut, et voir l’historique des déplacements précédents, avec les noms de leur auteur. Apparemment, l’adresse proposée par défaut au 10 Market St, San Francisco a fait les frais de plusieurs géolocaliseurs en herbe :

Mais comme on a l’habitude des gros malins chez Google, on peut aussi “Voir l’original” et replacer correctement le marqueur. Bientôt des combats en ligne entre équipes de déplaceurs intempestifs et replaceurs acharnés ?

Tout cela à un goût très frais de communauté, où chacun apporte sa pierre à l’édifice afin de bâtir un GoogleMonde meilleur. Mais dis-moi Google, elles sont libres tes données ? On peut les récupérer après ? Non ? Donc on travaille sans aucune contrepartie ? Pour que tu valorises ta base de POI et la revendes plus cher aux annonceurs ? Allez, dégage !

Le célèbre site communautaire Facebook fait beaucoup parler de lui ces derniers jours, depuis qu’il a mis en place une centrale de publicité à destination des annonceurs leur permettant de cibler les utilisateurs en fonction des données personnelles que ceux-ci ont eux-même mis dans leur page. De plus les marques peuvent également créer des pages “produits”, qui pourront alors se retrouver dans les réseaux d’amis (genre ce soir je fais un petite fête avec mes nouveaux amis Coca, Heineken et Smirnoff, rejoins-nous, ils sont super-cools !). Au-delà du débat suscité par cette nouveauté, c’est surtout un superbe exemple de la différence entre logiciel libre et logiciel gratuit. Le logiciel libre a un code ouvert dont chacun peut se servir à sa guise, pour l’adapter, l’améliorer. Son utilisation n’est pas subordonnée à une inscription ou à l’acceptation de conditions d’utilisations autres que le respect de la licence.

Les APIs dites libres car d’utilisation gratuite (le mot anglais “free” est en effet ambivalent, pouvant signifier libre ou gratuit), n’ont pas cette philosophie, mais plutôt celle de dealers de drogue :

• on vous appâte avec un produit agréable et intéressant
• on vous incite à l’utiliser de manière intensive
• une fois que vous êtes accro, on vous envoie la facture.

La profonde imposture est de vous faire croire que VOUS êtes le client d’un service gratuit, alors que, comme pour les journaux gratuits ou la télévision privée, vous n’êtes que le PRODUIT vendu à des annonceurs qui eux sont les réels clients (ce sont eux qui payent non ? ). N’oublions jamais cela lorsque, utilisateurs d’une célèbre API cartographique, nous trouvons formidable d’avoir ces données à disposition. C’est certes vrai, tout comme il est vrai que chaque mash-up, chaque création personnelle de données via cette API la valorise et nous en rend un peu plus dépendant. Un jour, il faudra bien payer la note.

Mateusz Loskot vient de publier un nouveau driver pour OGR, la célèbre bibliothèque d’abstraction/conversion de formats SIG, qui va donc désormais pouvoir accéder en lecture seule à des flux GeoJSON. On en a déjà parlé, le GeoJSON est la version Geo (malin non ?) de la notation JSON (Javascript Simple Object Notation) qui permet d’échanger facilement des objets structurés entre un serveur et un client. Un tableau associatif PHP se converti ainsi directement en un objet javascript.

La particularité du driver de Mateusz est de pouvoir accéder directement à un flux http renvoyant du GeoJSON, car ce “format” n’est pas à proprement parler un format de stockage comme le Shapefile ou le GML, mais bien un format d’échange. Avoir un fichier .gjson serait par là même une aberration ! Le driver ouvre donc une connexion vers un service web délivrant du GeoJSON, et permet alors toutes les opérations habituelles des modules OGR : info sur le fichier et conversion :
ogr2ogr -f “ESRI Shapefile” cities.shp http://featureserver/cities/.geojson OGRGeoJSON transforme en shapefile le flux GeoJson des villes issu du serveur de données.

L’intérêt de cette implémentation est tout naturellement son utilisation dans un contexte mobile, où la limitation de bande passante empêche l’exploitation de “gros” formats tels que le WFS-GML, un petit client pouvant ainsi récupérer les données vectorielles dynamiquement pour une exploitation locale.

Notez bien que ce driver n’est pas encore disponible dans la version officielle de GDAL-OGR, mais uniquement à partir du svn osgeo . Le portage dans la version officielle devrait être faite sous peu.