Petit exemple vécu récemment : dans le cadre de la mise en oeuvre d’une application web de suivi de véhicules en Algérie, j’ai construit une interface proposant les fonds GoogleMaps.

Sauf qu’une fois les trajets intégrés, ils n’étaient absolument pas alignés avec le fond de plan. Donc on vérifie, les données source, les paramètres de projection en Spherical Mercator, la configuration de l’application, l’ellipsoïde de référence… bref, tout ce qu’on peut imaginer être à l’origine de ce qu’on considère comme un problème d’intégration de NOS données.

Puis on affiche le fond satellite :

Et on découvre que mise à part une aberration GPS en début de parcours, tout colle parfaitement, et que c’était donc le fond de plan GoogleMaps qui étaient trompeur. D’autant plus trompeur d’ailleurs que la voirie qu’il présente n’a pas grand chose à voir avec ce qu’on voit sur l’image satellite. Nulle trace sur le plan des lacets visibles en haut à gauche par exemple.

Chez OpenStreetMap par contre, le tracé est de bien meilleure qualité…

mais uniquement quand il existe !

Données fragmentaires, obsolètes, erronées (et je m’en tiens à leur composante graphique, même pas attributaire !), sont autant d’écueils que les utilisateurs de services web cartographiques auront à gérer. Les métadonnées, quand elles existent, donnent des informations utiles (échelle, date…), mais rien ne permet de déterminer la qualité absolue d’une couche de données. Il ne faut donc jamais oublier que la donnée cartographique n’est, à l’instar des sondages, qu’une représentation simplifiée et conceptualisée de la réalité à un moment donné, et jamais une vérité définitive.

Les résultats ont été obtenus en utilisant Google Local Search API sur un maillage de 1,123,855 points différents situés dans les 40 plus grandes villes américaines. Sur chacun des points, un ensemble de divers services a été recherché, pour donner in fine un score. La grille des scores a ensuite été rastérisée. On ne va pas discuter de la méthodologie, c’est une réflexion que WalkScore continue d’affiner. Mais la démarche est enthousiasmante car elle rappelle que les phénomènes spatiaux sont bien plus souvent continus que discrets, et qu’ils ne s’arrêtent pas aux frontières comme on voudrait vous le faire croire.

Pas aussi balourd que « Les élections législatives dans GoogleEarth » quand-même :

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 !

- 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 !

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.

• Itinéraires modifiables par glisser-déplacer
• Personnalisation avec MyMaps
• Vues des rues avec le mode StreetView sur certaines villes américaines (pour l’instant)
• Intégration directe d’une carte dans un page web, sans recours à l’API
• Intégration dans iGoogle

A chaque innovation GoogleMaps redéfinit les conventions de la cartographie sur internet. Avec le recul, le travail accomplit en moins de trois ans est immense. Souvenez-vous, sur les premières versions, il n’y avait que les images satellites, la plupart étant du Landsat…
Ci-dessous, une GoogleMap du point le plus chaud de la Terre dimanche prochain…

Agrandir le plan

Une fois de plus GoogleMaps réinvente les règles de l’ergonomie des applications cartographiques sur le web. Désormais leurs itinéraires sont déplaçables à la souris ! Il suffit de cliquer sur un point de l’itinéraire pour aller le dropper un peu plus loin, et l’itinéraire se recompose en temps réel. Bluffant, vraiment bluffant. Surtout quand on envisage la technicité de l’opération. D’une part leur moteur de calcul d’itinéraire est capable de renvoyer un résultat en moins d’une seconde, et ce sans bénéficier du temps de chargement de la page complète qui masque souvent les performances réelles du calcul ; et d’autre part le tracé (qui s’appuie si je ne m’abuse sur le composants vectoriels internes aux navigateurs, comme le vml pour internet explorer par exemple) est également mis à jour en un temps record. Même si les autres options de calculs d’itinéraire (le plus rapide, court, autoroute…) sont absentes, et que certains résultats sont parfois hasardeux (essayez d’allez à bayonne…), le coeur de cette application reste au dessus du lot. (via Tech4d)