neogeo

Les nouvelles qui tombent de la conférence WHERE2.0 2008 sont assez réjouissantes : une nouvelle API GoogleMaps dédiée au Flash d’un côté, et l’intégration de nouvelles fonctionnalités dans le GoogleMaps “traditionnel” de l’autre. Merci à RenaLId, présent sur place, de nous en avoir fait profité aussi vite.  Mais je ne peux non plus m’empêcher d’y voir une tendance envahissante de la maison de Moutain View. Toutes ces “nouvelles” fonctionnalités existaient déjà ailleurs. Pour du GoogleMaps en Flash, voir par exemple ici et bien sûr là. Et côté intégration des articles de Wikipedia dans GoogleMaps, il y avait déjà aussi quelques essais ici et là. C’est donc un peu comme si GoogleMaps reprenait à son compte les idées à succès nées de la diffusion de son API. C’est bien dans un sens, dans la mesure où ça donnera une audience bien plus large à ces fonctionnalités. Mais c’est dommage aussi pour la créativité des mash-ups initiales, qui perdent désormais tout intérêt. Google ne risque-t-il pas d’assécher les sources qui ont fait la formidable popularité de ses applications cartographiques ?

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 !

Comme le remarque justement Peter Batty Google vient de changer les règles d’utilisation de son service de géocodage. On passe d’un mode de fonctionnement basé sur un nombre de requêtes journalières par clé à un nombre de requêtes journalières par IP, le nombre limite tombant de 50000 à 15000. Ca change tout, et chacun y trouvera avantage ou inconvénient selon son utilisation du service :

- vous proposez un service de géocodage en ligne ? Chacun de vos clients (au sens informatique, et, peut-être, commercial ;-)) pourra effectuer 15000 opérations par jour. MAIS le traitement devra être effectué par son navigateur, et non plus par votre serveur, car sinon vous n’auriez plus que 15000 opérations à partager entre tous vos clients. Donc les scripts doivent être éventuellement adaptés, de manière à tourner sur le navigateur, en utilisant l’API javascript du Geocoder. Ce qui ne va pas faciliter l’ergonomie, car concrètement cela se traduit par : upload d’un fichier d’adresses sur le serveur, renvoi du contenu du fichier au client (en XML par exemple, ou en JSON), traitement par javascript des adresses, renvoi des résultats au serveur, mise en forme et enfin renvoi au client du fichier d’adresses initial augmenté des coordonnées. Ces multiples allers-retours ne vont pas faciliter la manoeuvre. L’utilisateur quant à lui va devoir laisser ouvert son navigateur pendant tout le traitement, quand l’exécution côté serveur pouvait simplement lui renvoyer par mail un lien de téléchargement quand toutes le adresses avaient été traitées (ce qui donnait une raison très légitime à la demande d’identification de l’utilisateur).

- vous géocodez vous-même beaucoup d’adresses ? Sous réserve de recomposer vos scripts s’ils s’effectuaient sur un serveur (ce qui semble logique pour des traitements de masse), vous allez pouvoir mettre tout le monde au travail, chacun des postes de vos collègues pouvant traiter 15000 adresses par jour. En plus, ils auront même l’impression de travailler en regardant Firefox tourner tout seul ! SAUF QUE… vous avez un proxy ! Pas de chance, vous avez tous la même IP publique, donc c’est en fait 15000 pour toute la boîte. Ce n’est pas demain que vous terminerez de géocoder les Pages Jaunes (quoiqu’avec quelques stagiaires travaillant à domicile…)

Donc l’un dans l’autre, Google nous donne plus de souci que de liberté avec ses nouvelles règles (qui peuvent changer à tout moment, sans préavis, parce que Google c’est gratuit, mais ce n’est ni OpenSource ni Free Software). D’autant que la clé est toujours nécessaire et que le nouveau mode de fonctionnement donne à Google moyen de savoir plus précisément ce que vous faites avec son géocodeur puisque les cas d’utilisation ci-dessus sont facilement identifiables : beaucoup d’IP avec votre clé pour le premier, très peu mais flirtant quotidiennement avec la limite autorisée pour le second. Donc Google sait ce que vous faites, qui sont vos clients et quel est votre volume d’activité. Ne l’oubliez pas !

Je suis un peu inquiet de voir à quel point GoogleMaps semble être l’alpha et l’omega de bien des développeurs du monde OpenSource, comme si tous les efforts actuels devaient se concentrer sur la mise en oeuvre d’une solution concurrente. Entre OpenLayers, dont les fonctionnalités se veulent le décalque de celles de GoogleMaps, et les interrogations surgissant ici ou là, c’est comme si toute application de webmapping devait se résumer à singer GoogleMaps. On a l’impression que, surfant sur la vague du Web 2.0, les applications cartographiques sur le web on été investies par des gens pour lesquels elles se résument à afficher des points, traits ou polygones à un endroit convenable.

Mais rappelons-le, GoogleMaps, quelques soient ses indéniables qualités (plus architecturales que fonctionnelles au demeurant), n’en est pas moins une application qui affiche 1 ou 2 couches de données images précalculées et permet quelques facéties dans un calque de dessin vectoriel. L’ergonomie est certes remarquable, mais fonctionnellement on est loin de ce que peut réclamer une réelle application SIG en ligne.

Loin de devoir garder la tête dans le guidon à la poursuite de GoogleMaps, je pense donc que la communauté OpenSource, forte de son expérience dans le domaine du SIG en général, à plutôt intérêt à développer des WebServices cartographiques performants, permettant peu à peu de transférer vers le navigateur ce qui ne se fait encore que dans des applications SIG desktop. A trop vouloir faire du web 2.0 en WebMapping, on dégrade les fonctionnalités purement cartographiques pour ne conserver que l’affichage. C’est bien pour partager de l’information géolocalisée (ou des ressources géolocalisées : photos, parcours…), mais c’est insuffisant pour traiter ces informations au sens cartographique du terme et donc exploiter la réelle plus-value spatiale et attributaire qu’elles recèlent.

En complément à un précédent post, le FOSS m’a permis d’y voir un peu plus clair sur les différents formats “interropérables” pour les données géographiques et surtout de percevoir un distinction majeure entre ceux-ci : il y a d’un côté les formats issus du monde géographique et créés pour diffuser l’information géographiques sous la formes de services web : WMS, WFS et donc GML sont de ceux-là.
D’un autre côté, on trouve les formats du Web 2.0 qui intègrent peu à peu la dimension géographique : AtomPub, GeoRSS en font partie. Le KML/Z quant à lui se situant entre ces deux approches : imaginé pour diffuser de l’information géographique (et rien de plus, comme le rappelle Raj Singh), il intègre aussi étroitement la notion d’interropérabilité totale.

Car c’est bien en termes d’interropérabilité que les formats se distinguent. Là où les premiers ont été faits pour permettre à des systèmes géographiques d’interropérer (afficher dans MapInfo une carte issue d’un serveur WMS, crééer un application web à partir de multiples serveurs WMS-WFS différents), le deuxième groupe est fait pour permettre à des applications web d’interropérer, nonobstant leur capacité à analyser ou traiter la donnée géographique. Ce point est central pour la compréhension des avantages et inconvénients de chacuns. Là où un flux AtomPub intégrant des balises de géolocalisation en GeoRSS pourra être interprété par n’importe quel client Atom, qu’il exploite les données géographiques ou pas, le flux GML d’un serveur WFS ne sera correctement affiché sous forme de carte que par des clients dédiés à l’affichage cartographique. Cependant, pour des raisons d’homogénéité et de standardisation, l’AtomPub, tout comme le KML, ne diffuse qu’un contenu attributaire restreint (nom - description de l’objet, même si celle-ci peut-être complexe, de la forme d’un bloc HTML complet), tandis que le GML transporte toute la richesse attributaire nécessaire à une réelle exploitation des données. Les usages sont donc forcément différents. Là où le GeoRSS répond au besoin de “Affiche mes posts dans GoogleMaps”, le GML est porteur d’une réelle richesse attributaire et d’une plus value qualitative évidente, qui se paye par une plus grande complexité.