Support des images géolocalisées

Je n’en ai pas personnellement l’utilité, mais il pourrait être intéressant d’ajouter le support des images géolocalisées liées à un article, sous forme de document.

• Les articles représentent sous forme de couches les document qui sont des images géoréférencées (on le reconnaît par un mot-clef ?).
• Les documents qui sont des images géoréférencés se représentent tout seuls sur la carte.
• Les sites liés qui pointent sur un serveur WMS ?

Édition de points indépendamment des objets SPIP

On peut vouloir ajouter dans le site des points qui ne sont a priori liés à aucun objet. Ils pourraient par la suite être ajoutés manuellement sur la carte ou sous forme de lien dans les textes.

Pour implémenter ça il faudrait :

1. Créer une interface dans le menu "Édition" permettant d’ajouter autant de points que l’on veut.
2. Ajouter un titre et une description à ces points (la base de données permet déjà d’ajouter une description). Ajouter des icones ?
3. Modifier la balise GEOMARKER pour qu’elle puisse prendre un ID de point.

Ce serait alors très intéressant de pouvoir récupérer ces points pour y accrocher a posteriori des objets. Mais ça pose un gros problème d’interface : comment fait-on pour rechercher un point ? Le plus simple est par le nom, mais ça peut être fastidieux pour l’utilisateur : se souviendra-t-il du nom des points ? Une interface géographique ne tiendrait pas s’il y a des centaines de points…

Portage pour SPIP 3

Sur spip 3.0 beta, le plugin GMap s’installe maintenant correctement et on accède aux pages de paramétrage. Par contre les pipelines ne semblent pas actifs : il faudra voir sur la version finale.

Plusieurs améliorations sont à faire :

• Tout d’abord, pour être plus "spip 3", il faut recoder les pages de la partie privée sous la forme de squelettes.
• Les styles de la partie privée ne sont pas gérés avec style_prive.html, ce qui peut présenter des risques d’incompatibilité avec les versions futures.
• La boucle GEOTEST est toujours codées "à la hussarde", il faudrait l’intégrer plus correctement dans SPIP en créant une base virtuelle.

Approfondir la boucle GEOTEST

La boucle GEOTEST permet de déterminer si un objet ou ses fils (au cas ou {recursif} est mentionné) sont géolocalisés. Les besoins de cette boucles pourraient être beaucoup plus pointus : seulement les fils, mais non l’objet lui-même (ajouter un {self} ou au contraire {!self}), les fils de tel niveau, etc.

Permettre de faire des liens vers une position dans un texte

Il faudrait ajouter un modèle pour pouvoir intégrer un lien vers la carte dans le texte d’un article.

En réponse à un clic sur le lien il faudrait centrer la carte sur le point et utiliser le zoom de ce point, et éventuellement faire défiler la page HTML pour que la carte soit visible.

Ce n’est pas faisable avec les liens usuels de SPIP ([tata->addr]) car il faut utiliser un code javascript sur l’évènement click du lien.

Je ne crois pas non plus qu’il soit pratique de le faire avec un simple modèle car on peut vouloir afficher un texte spécifique cliquable. Avec un modèle, on pourrait afficher le texte du marqueur, mais ce serait lourd de passer un texte possiblement long en paramètre du modèle.

Je verrais plutôt un filtre typographique sur <geolien id="id_marqueur">texte</geolien> qui offrirait toute la souplesse nécessaire…

On pourrait alors tout aussi bien transformer le modèle pour lui mettre un texte : <marker|latitude=yyy|longitude=xxx>ceci est un point</marker>

Ajout d’une fonctionnalité de regroupement des pointeurs

Des points proches, voire supperposés, ne sont pas différentiables sur les cartes. On ne voit que le dernier point ajouté.

La fonction de regroupement des bulles d’information permet déjà de solutionner une partie du problème : quand on clique sur un point, l’ensembles des points proches sont représentés dans la bulle d’information. Cependant il manque un retour visuel du regroupement.

Il y a plusieurs possibilités :

• Au plus simple, on peut utiliser les extensions ClusterManager qui remplaceront les point par des zones cliquables.
• Mais il pourrait également intéressant de gérer les regroupements au moment de la saisie des points, en définissant des zones dans lesquelles on sait qu’il y aura plusieurs points.

ClusterManager

Les extensions ClusterManager existent pour Google Maps V2 et V3. Il suffit de les intégrer dans les scripts, de modifier l’ajout des marqueurs sur la carte et, éventuellement, de personnaliser l’apparence des regroupements.

On peut réutiliser le regroupement des bulles pour afficher une bulle d’information sur le cluster au lieu de le faire zoomer.

Permettre de définir des "clusters" de points

• Ajouter un champs id_parent sur les points.
• Dans l’interface d’ajout des points, permettre de saisir un libellé sur les points (la table existe déjà en base de données).
• Toujours dans l’interface, permettre de désigner un point parent.
• La gestion du zoom pourrait être soit manuelle (saisie de zoom min et max dans l’interface pour chaque point), soit automatique : le zoom min des points qui ont un parent est le min des zooms des points fils, le zoom max du parent est le même. La saisie manuelle demande plus de travail (et une certaine cohérence) lors de la géolocalisation mais permet de gérer d’autres cas. La gestion automatique engendrera aussi des requêtes SQL supplémentaires lors de l’affichage ce qui peut alourdir le processus.

Permettre d’associer plusieurs objets à un même point

La base de données permet déjà d’associer plusieurs objet à un point, mais l’interface et le code ne le supportent pas.

Il faut :

1. Modifier les fonctions d’accès à la base de données pour autoriser d’avoir plusieurs points (inc/gmap_db_utils).
2. Ajouter dans l’interface de géoréférencement un moyen de récupérer un point.

Quand on choisit un voisin pour copier ses coordonnées, on pourrait ajouter le nouvel élément sur le même point au lieu de copier les coordonnées. Ce serait un moyen simple d’exploiter les possibilités de la base de données dans laquelle la relation point-élément est de type n-m.

Ça pose aussi quelques problèmes dans le cas où deux objets partageant un point sont représentés sur un même carte. Soit on doublonne, c’est-à-dire que le fait que, dans la partie publique, deux éléments partageant un point ne diffèrent pas de deux points ayant deux points aux même coordonnées. Soit on tente de gérer l’unicité du point :

1. Il semble très difficile de gérer correctement les objets multiples dans le fichier KML généré. Comme il est créé par des boucles sur les objets, il faut maintenir une liste d’exclus en dehors de chaque boucle. Ça pourrait se faire avec exclus et en ajoutant une requête qui fussionnerait les infos-bulles de tous les objets. On peut aussi supposer que c’est au logiciel exploitant le KML de fusionner les points.
2. Ajouter la fusion des points lors de l’ajout des marqueurs sur la carte (ajout direct ou par query). C’est assez simple à ce niveau puisqu’on peut se baser sur l’ID du point.