Plugin GMapMXN : utiliser la librairie Mapstraction dans GMap - commentaires

Plugin GMapMXN : utiliser la librairie Mapstraction dans GMap

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.

Plugin GMapMXN : utiliser la librairie Mapstraction dans GMap

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 ?

Plugin GMapMXN : utiliser la librairie Mapstraction dans GMap

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.

Plugin GMapMXN : utiliser la librairie Mapstraction dans GMap

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

Plugin GMapMXN : utiliser la librairie Mapstraction dans GMap

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