Retour d’expérience sur l’implémentation avec Mapstraction

But du développement

Le but du développement de ce plugin était essentiellement de tester à la fois les possibilités de la librairie Mapstraction et le support de nouvelles implémentation de carte dans GMap.

Le premier besoin est venu d’une discussion sur la mailling list SPIP-Zone à propos de l’opportunité d’utiliser Mapstraction plutôt qu’une couche d’abstarction propriétaire comme c’est le cas dans GMap. Or je déteste parler de choses que je connais peu ou pas, il me fallait donc mettre l amain à la pâte en utilisant Mapstraction pour me faire une idée correcte des possibilités de la libaririe.

Le deuxième besoin est opportuniste : quitte à développer avec Mapstraction, pourquoi ne pas en faire une implémentation pour GMap, et quitte à en faire une implémentation, pourquoi ne pas tester ce que ça donne depuis un plugin externe à GMap.

Mapstraction

La librairie Mapstraction est assez facile d’emploi. Malgré la maigreur de la documentation (la principale source est le dossier "docs" inclu dans la librairie), le code est assez simple et l’on s’y retrouve rapidement.

Couche d’abstraction

Mapstraction est une couche d’abstraction qui offre un socle commun pour attaquer différents fournisseurs de services cartographique (cf. plus bas). Cependant, l’uniformisation a ses limites, et on est rapidement confronté aux spécificités de tel ou tel fournisseur.

Par exemple, certains fournisseurs (Cloudmade et Google) utilisent des icones séparées pour l’image d’un marqueur et son ombre, d’autres ne le supportent pas et il faut leur fournir des images incluant l’ombre (si on veut une ombre, mais le but n’est-il pas d’avoir une certaine homogénéïté entre les fournisseurs ?).

De même, le code des pages qui contiennent les cartes doivent inclure les scripts spécifiques à chaque fournisseurs pour fonctionner, avec les éventuelles clef d’enregistrement (ce dernier point est inévitable…).

Ce qui manque le plus, il me semble, est une déclaration des capacités de chaque fournisseur que l’on pourrait utiliser dans un code général pour activer ou non certaines fonctionnalités. Ce mécanisme est ajouté dans GMapMXN, sur la base du tableau suivant :

FournisseurCloud.Google v2Google v3BingOpen LayersOviYahoo
Clef d’activation X X X
Geocoder X X
Support KML X X X X X
Choix du fond de carte X X X X X
Ombre séparée X X X
Interception du clic sur marqueur X X X X
Déplacement des marqueurs
Commande de zoom X X X X X X X
Commande de déplacement X X
Affichage de l’échelle X X X X
Affichage d’une carte de situation X X X
Commande de choix du fond X X X X X

Il s’agit là des possibilités accessibles par l’intermédiaire de Mapstraction. Par exemple le déplacement des marqueurs est supporté par les API Google et Microsoft, mais Mapstraction ne permet pas de récupérer l’évènement "drop-marker", rendant cette possibilité inexploitable.

Fournisseurs

La documentation de Mapstraction mentionne les fournisseurs suivants, ceux qui sont implémentés dans le plugin apparaissent suivis d’une étoile :

Cartociudad

Basée sur OpenLayers, c’est une API limitée à l’Espagne. Je ne l’ai pas testé dans le cadre du plugin GMapMXN pour cette raison.

Cloudmade*

Carte en mode plan plutôt bien présentée. Demande une clef d’enregistrement, pas de geocoder. Cloudmade

GeoCommons

À l’heure où je rédige cet article le site web ne répond pas. Encore maintenu ?

Google Maps v2 et v3*

Très bonnes cartes avec les possibilités complètes du plugin (normal vous me direz, gMap a été initialement codé pour cette API). L’implémentation Mapstraction retire quelques fonctionnalités, notamment à cause des notifications d’évènement manquantes. La version 2 demande une clef d’enregistrement, la version 3 non… La version 4 ? Les paris sont ouverts ! Google Maps v2 Google Maps v3

MapQuest

L’API semble bien, mais Mapstraction n’implémente qu’un geocoder. On n’a donc pas accès aux cartes. Mais bon, ça me donne une idée : dans le plugin GMapMXN, voire dans GMap, je pourrais dissocier l’implémentation de la carte de l’implémentation du geocoder, celà permettrait d’utiliser un géocoder d’un autre fournisseur pour ceux qui n’en proposent pas.

Microsoft Virtual Earth v6 (Bing)*

L’API permet de définir un point d’ancrage sur les images des marqueurs, mais ne le prend pas en compte. Ce n’est pas pratique et ça donne l’impression que les marqueurs GMap (avec un point d’ancrage en bas) sont décalés par rapport aux autres fournisseurs et changent de place en fonction du zoom. C’est apparement un problème connu de l’API.
On s’en tire en redéfinissant des images spéciales, centrée : on rond par exemple. La version 0.1.1 de GMapMXN contient ces icones spécifiques. Microsoft Virtual Earth v6

Par rapport aux autres fournisseurs, le fonctionnement des info-bulles est différent : elles s’affichent toujours des qu’on laisse un peu la souris sur le point. Ça rend complexe le développement d’une couche d’abstraction homogène.

Une implémentation Mapstraction pour l’API Microsoft V7 est en cours, il faudra voir ce que ça donne.

Multimap

L’API cesse d’être opérationnelle dans deux semaines (18 novembre 2011), donc je ne me suis pas donné la peine de tester.

Open Layers*

L’API de cartographie libre. Assez technique mais très fonctionnelle. Des différences notables avec les autres fournisseurs au niveau de l’interface (contrôle de gestion des couche notamment).

Le plus gros problèmeme semble être est l’absence d’une base de données satellite pérenne : le fond de carte par défaut est Open Street Map, ce qui est tout de même moins joli. Mais bon, l’avantage est que c’est et ça restera libre, et aussi que c’est l’API préférée du monde de la cartographie professionnelle. Open Layers

Bien que Mapstraction ne propose pas cette option par défaut, MapQuest propose des fond de carte satellite, gratuits, qui peuvent être interfacés avec Open Layers.

OpenSpace

Comme cartociudad, une implémentation de Open Layers limitée à l’Angleterre. Trop spécifique pour que je le teste.

Ovi / Nokia*

Ma foi une API que je ne connaissais pas mais qui fonctionne bien. Rien à dire si ce n’est que l’a notoriété de l’API est très inférieure à celles de Google ou d’Open Layers. Ovi Nokia

Yahoo !*

Plusieurs problèmes de compatibilité avec les autres fournisseurs, notamment le fait qu’on ne maîtrise pas le point d’ancrage des marqueurs et que le titre de ces derniers apparait très mal formaté sur le point alors que les autres ne l’affichent que sous forme d’info-bulle.
GMapMXN corrige ces deux inconvénients en définissant des icones spécifiques à Yahoo et en supprimant le titre du marqueur. Yahoo ! Maps

Yandex

Je l’avais implémentée au début, mais… je n’ai pu obtenir de clef d’enregistrement par ce que le site est entièrement en russe. La barrière de la langue… Si quelqu’un parle russe, je veux bien la remettre.

Ajouter une implémentation sur GMap

La réalisation de cette nouvelle implémentation de carte pour GMap a permit de tester la possibilité réelle d’ajouter une carte, et donc la couche d’abstraction, propriétaire celle-ci, incluse dans GMap.

Plusieurs modifications ont cependant été nécessaires :

  • Tout d’abord la prise en compte d’un plus grand nombre de paramèters dans les déclaration de capacités des implémentations pour intégrer les différents niveaux de services auxquels on accède par Mapstraction. Notamment l’ajout de la capacités "Geocoder" qui permet de ne pas proposer la recherche par adresse dans le formulaire de géolocalisation.
  • Ensuite la transmission des icones "complètes" (incluant l’ombre) vers le script. Ces icones étaient déjà présentes dans GMap pour les fichiers KML exportés, mais elles n’étaient jusqu’ici pas transmises au code javascript.
  • Meilleur support des paramétrages absents : ne pas planter mais seulement ne rien afficher dans les pages de paramétrages.

Au-delà d’une nouvelle implémentation de carte, le développement de GMapMXN a été l’occasion de tester l’ajout d’une implémentation isolée dans un nouveau plugin, donc le fonctionnement du pipeline de déclaration de l’implémentation et l’arborescence des fichiers d’implémentation (tout ce qui est sous mapimpl/).

Point négatif, mais qui était déjà connu : le code nouveau à implémenter n’est pas assez isolé du code générique de l’implémentation de carte. Plus concrètement, les méthodes du fichier gmap_impl_public.js ne sont pas toutes à redéfinir, certaines sont valables pour toutes les implémentations. Pour rendre le code plus propre, il faudrait coder une interface (au sens de la progrmmation objet), ce qui n’est pas aisé en javascript.

De ce côté, la façon de faire de Mapstraction (une classe générique sur laquelle on plug des implémentations) est interessante. Mais le but de GMap n’est PAS de fournir une couche d’abstraction, il est de fournir un service à un niveau plus élevé. Le refactoring de la classe MapWrapper (ce qui est dans gmap_impl_public.js) n’est donc pas une priorité.

Conclusion

Rapidement, on peut dire que l’expérience ne m’a pas convaincu du bien-fondé de l’utilisation de Mapstraction, pour deux raisons :

  • Parmi les fournisseurs de service proposés, seuls Google et Open Layers sont, à mon avis, crédibles. Bing et Yahoo s’écartent pas mal du fonctionnement standard (format d’icone peu souple notamment). L’apparence des cartes Yahoo n’est franchement pas excellente. Les autres fournisseurs sont spécifiques à une région ou à une utilisation.
    Esthétiquement, je trouve également que l’API Google est de loin la plus aboutie. Open Layers est moins joli mais est crédible par sa nature de logiciel libre, amené à évoluer et qui profitera certainement du fait que Google commence à rogner sur la gratuité du service.
  • Mapstraction ne propose pas une homogénéisation assez approfondie de l’API. Très rapidement, on se heurte aux spécificités des fournisseurs, et, plus embêtant, il n’y a pas de méthode dans l’API pour tester si une fonctionnalité est implémentée ou non par un fournisseur. Certes, Mapstraction permet de redescendre au niveau de l’API du fournisseur, mais quel est alors l’avantage d’une couche d’abstraction si on est obligé de redevenir spécifique pour atteindre son but ?

J’ai bien conscience que cet avis est assez franco-français : un espagnol, un anglais ou un russe verront probablement l’avantage d’utiliser Cartociudad, Open Space ou Yandex. Et plus encore si ces API peuvent être utilisées avec le même code que les autres.