Plugin GMapMXN : utiliser la librairie Mapstraction dans GMap

À quoi sert ce plugin ?

GMapMXN met à disposition du plugin GMap une implémentation de carte qui permet d’utiliser l’interface graphique de plusieurs fournisseurs de services cartographique : Cloudmade, Google Maps, Bing, Open Layers, Ovi Nokia et Yahoo. Pour atteindre ce but, le plugin s’appuie s’appuie sur la librairie Mapstraction.

Une fois GMapMXN installé et activé, il s’intègre complètement à GMap en proposant simplement une nouvelle entrée dans la liste des implémentations disponibles.

Compatibilité et installation

GMapMXN n’a été testé que sur des versions de spip supérieures à 2.1.11. Il a peu de dépendances envers spip.

Le plugin a par contre une dépendance forte vis-à-vis de GMap. Il ne fonctionne qu’à partir de la version 0.1.3 et les icones spéciales pour Bing et Yahoo ne seront utilisées qu’avec une version de GMap supérieure à 0.1.4.

GMapMXN utilise la librairie Mapstraction en version 2.0.17, elle doit être installée dans le dossier lib/h12833bc5-mxn-2.0.17 du site. L’utilisation d’une autre version de Mapstraction n’est possible qu’en intervenant dans le code du plugin.
Quand le plugin est activé, SPIP propose de télécharger automatiquement la librairie dans le dossier /lib situé à la racine de votre site, ce dossier doit exister pour que l’opération réussisse.

Le plugin s’installe selon la procédure habituelle de SPIP (voir Installer un plugin).

Configuration

GMapMXN n’est actif qu’après avoir sélectionner Mapstraction comme API cartographique dans le paramétrage système de GMap.

Une fois activé, le paramétrage spécifique à l’API permet de choisir le fournisseur de l’API. Pour chaque fournisseur, l’interface indique les plus caractéristique les plus importantes. Quand c’est nécessaire, une zone permet de saisir la clef d’activation nécessaire.

Dans la configuration de l’interface utilisateur, seules les possibilités offertes par le fournisseur sont disponibles. Pour certains fournisseurs, il est nécessaire de valider les modifications pour les voir apparaître sur la carte, GMapMXN affiche un message d’avertissement quand c’est le cas.

Utilisation en géolocalisation

Après le paramétrage, l’interface de géolocalisation utilise l’API cartographique sélectionnée.

L’option de recherche d’un point par adresse n’est disponible que pour les fournisseurs qui intègrent un geocoder. Il n’est actuellement pas possible d’utiliser un autre fournisseur de service pour le geocoder.

Sur la carte elle-même, le déplacement du point central par glisser-déplacer n’est pas possible. La modification du point se fait par un simple clic sur la carte.

Rendu final des cartes

Sur le site public, le rendu des cartes utilise le fournisseur sélectionné. La fonction de regroupement des info-bulles n’est pas disponible avec l’implémentation Mapstraction.

Bing et Yahoo ne permettent pas de définir le point d’ancrage des icones. Pour contourner le problème, GMapMXN contient deux thèmes graphiques spécifiques à chacun de ces fournisseurs.
Attention : lors du changement de fournisseur, il peut être nécessaire de vider le cache avant que les cartes utilisent le nouveau thème graphique. Il faut en effet que les requêtes passées pour obtenir les points à représenter soit recalculées.

Pour Bing, il s’agit d’un rond, le point d’ancrage est au centre.

Pour Yahoo, le point d’ancrage est en bas à gauche de l’image.

Possibilités selon le fournisseur

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

Discussion

Une discussion

  • 4

    Mais pourquoi continuer de recoder ce qui a déjà été codé pour GIS2 ? C’est juste pour le plaisir intellectuel de l’avoir fait soi-même ?

    Il y a même une branche pour GIS2 en train d’intégrer côté serveur le regroupement des bulles et le clustering, avec rechargement en AJAX à chaque modif de déplacement ou de zoom...

    • J’ai développé GMapMXN pour voir ce que valait la librairie (c’est toujours difficile de parler de quelque-chose qu’on ne connait pas) et de tester l’ajout d’implémentations sur GMap (cf. http://www.loceanique.org/spip/arti...). C’est pourquoi je le présente sous la forme d’un plugin annexe.
      Par ailleurs ce n’était pas un gros effort : à peine une journée de travail en comptant les modifs de GMap, un peu plus avec le coup des thèmes pour changer les marqueurs sur Bing et Yahoo.


      Plus généralement, je ne vois pas bien le sens de ton message. Voudriez-vous que j’abandonne GMap parce que GIS2 existe ?
      Je ne le ferai pas parce que je trouve, honnêtement, que GMap est bien plus riche que GIS2. Il contient des fonctions et des possibilités d’extension qui me sont très utiles et que je ne voudrais pas abandonner.
      Je continuerai d’améliorer GMap tant que j’aurai des besoins et des idées pour le faire...


      En ce qui concerne, le clustering côté serveur, pour le coup, je ne crois pas que je m’y lancerai : je pense que ça génèrera trop d’attente sur le client, que ça limite la liberté de requête côté serveur. En regardant les temps d’affichage des pages, j’ai l’impression que le temps pris par l’implémentation de carte est bien plus important que le temps d’attente et de traitement des liste de points. Donc la principale optimisation à faire est de limiter le nombre de points ajoutés à la carte. Donc un clustering côté client est efficace. Je suppose que ça se discute selon le nombre de points. À partir de 10 000 points le clustering côté serveur doit commencé à avoir des avantages...

    • Plus généralement, je ne vois pas bien le sens de ton message. Voudriez-vous que j’abandonne GMap parce que GIS2 existe ?

      En fait ma priorité c’est toujours que les gens travaillent ensemble plutôt que chacun fasse son petit truc dans son coin.

      Moi, en tant que développeur, je m’en fiche : je sais ajouter des fonctionnalités, je sais effectuer des recherches complexes pour trouver mon bonheur, etc. Donc ce n’est pas pour mon confort personnel.

      Mais pour les utilisateurs, ça signifie 4 plugins différents sur Contrib qui ont les mêmes fonctionnalités, et les non-développeurs n’ont pas les moyens de savoir lesquels sont développés par une unique personne, lesquels par une association de personnes, d’évaluer la qualité du code (qu’on ne peut évaluer qu’en travaillant à plusieurs pour avoir plusieurs regards sur le même code), etc. Du coup ils sont perdus et ne savent pas quoi choisir, et finissent par choisir au hasard, par date inverse ou celui qui communique le mieux.

      Alors évidemment que tu fais ce que tu veux, le déoôt SVN et Contrib sont là pour ça. Mais c’est mieux quand on travaille ensemble quand même.

      Donc la principale optimisation à faire est de limiter le nombre de points ajoutés à la carte. Donc un clustering côté client est efficace. Je suppose que ça se discute selon le nombre de points.

      Pour cette branche de dev, j’ai dû mal m’exprimer : elle fait ces DEUX points.

      1) Elle fait du clustring côté serveur et 2) elle ne charge QUE les points contenus dans la « box » de la carte, en rechargeant en AJAX cette liste de points dès qu’on déplace ou zoom la carte.

      Autrement dit, si on augmente le zoom, ça ne chargera en mémoire que les points contenus dans le nouveau rectangle, et du coup c’est super optimisé. En revanche si on DÉzoom alors ça peut potentiellement afficher un nombre énorme de points (si on affiche tout un pays, continent, etc) et dans ce cas, ça peut si on le désire générer un cluster côté serveur.

      Et c’est pas à partir de 10000 points que ça devient intéressant, mais dès 3000 ou 4000 (en ce qui me concerne j’en ai 25000). Je n’ai pas trop compris la remarque comme quoi ça limiterait la « liberté de requête », je ne comprends pas le sens. Ya aucune limite, ce sont les mêmes requêtes qu’avant, sauf que c’est le serveur qui chauffe et pas le navigateur client.

    • En fait ma priorité c’est toujours que les gens travaillent ensemble plutôt que chacun fasse son petit truc dans son coin.

      Oui, je comprends ça. C’était aussi mon but en publiant GMap. J’accueillerai bien toute proposition de collaboration pour améliorer le plugin.
      Par rapport à GIS2, et bien que j’aie proposé plusieurs fois d’en parler, je ne crois pas qu’on pourrait fusionner les deux parce qu’il sont partis dans des directions différentes.
      GMap répond d’abord au besoin de customiser à la fois les requêtes (quel sont les points à afficher ?) et l’apparence des cartes et des points. C’est ce but qui justifie les pages de configuration, le système de surcharge des icones et pratiquement tout le code. GIS2 n’aborde pas ce problème.
      Je n’arrive pas à formuler correctement une caractéristique saillante de GIS2, je vous laisse faire.

      Et c’est pas à partir de 10000 points que ça devient intéressant, mais dès 3000 ou 4000 (en ce qui me concerne j’en ai 25000).

      La caractéristique principale ? Il est clair que GMap n’a par contre pas été conçu pour un tel volume de points. Je ne sais franchement pas ce que ça donne, mais je suis sûr qu’il faut un clustering côté client pour que ça passe.

      Je n’ai pas trop compris la remarque comme quoi ça limiterait la « liberté de requête », je ne comprends pas le sens.

      J’ai du mal à imaginer qu’on puisse efficacement filtrer les fichiers de points générés par un squelette qui peut être surchargé, donc contenir n’importe quoi. Mais je me trompe peut-être.

      1) Elle fait du clustring côté serveur et 2) elle ne charge QUE les points contenus dans la « box »

      Là c’est moi qui ne comprends pas : c’est du clustering côté serveur, oui. Le fait que le client ne charge que les points à afficher, c’est du clustering serveur, même si ça se part du client.


      Cette discussion ne serait-elle pas plus adaptée sur la mailing-list de SPIP-Zone ?

    • Bon ben si c’est complémentaire et différent, et si tout le monde a envie de travailler ensemble, ya matière à fusionner en donnant le meilleur de chaque développement alors ?

      Chouette, ce sera plus sympa pour les développeurs, et c’est tous les utilisateurs qui vont y gagner aussi, avec une équipe élargie de personnes qui s’y connaissent et qui sont motivées, équipe plus solide donc pour mieux développer des fonctionnalités et les maintenir dans la durée.

    Répondre à ce message

Ajouter un commentaire

Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :

  • Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
  • Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
    • version de SPIP, en bas de la partie privée
    • version du plugin testé et des éventuels plugins nécessités
    • version de PHP (exec=info en partie privée)
    • version de MySQL / SQLite
  • Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
  • En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparaît.

Merci d’avance pour les personnes qui vous aideront !

Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.

Qui êtes-vous ?
[Se connecter]

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom