[fait] Clustering des pictos ?

[Dominique]

Dans le cadre des remarques de Léo, j’ai regardé ce qu’on peut faire pour n’afficher qu’un picto « groupe » là ou les pictos unitaires sont trop denses.

Il y a 3 solutions :
- Le faire avec Openlayers dans l’explorateur.
La fonction ol.source.Cluster est là pour ça : https://openlayers.org/en/latest/examples/cluster.html
Problème : si on zoom sur le monde (ou une zone très large) le serveur mouline tous les points de la base et les envoie à l’explo qui les groupe. Voilà qui risque de faire ramer le serveur (et le réseau)

- Le faire en SQL dans le serveur
La fonction ST_ClusterWithin est là pour ça, avec un peu de post traitement pour transformer les GeometryColections générées pour un groupe de points en un picto « nombre »
L'avantage est de ne pas envoyer tous les pictos de la base quand le groupe est grand mais ça risque de ramer quand même un peu sur SQL car il rend des GeometryColections contenant tous les points groupés (ce qui n'arrive pas quand on met seulement un LIMIT = 250)
A noter que ClusterWithin existe en PgSql et pas en MySql
Pas mal, mais on risque d’augmenter la complexité la superfonction SQL d’extraction (à moins qu’on en profite pour la « casser » en fonctions plus petites ?

- Ne rien faire (ça énerve les )

Des avis avant que je me lance là-dedans ?
(j’aime pas PG)

[leosw]

Salut !

J'ai un avis sur la question. Je ne trouve pas les clusterings graphiquement intéressants : on doit cliquer un peu partout, ça ne représente pas bien la répartition géographique, ça nécessite pas mal de bande passante (car tout est envoyé)...

Je trouve la solution adoptée par Geocaching pas mal : sur les petits niveaux de zoom, générer des tuiles avec les pictogrammes et les ajouter en overlay, et sur les grands niveaux de zoom laisser tel quel.
Ça limite les calculs sur le navigateur de l'utilisateur, et ça donne une image réaliste.

Freins :
1. À quelle fréquence réactualiser les tuiles (1/semaine)
2. Que faire si quelqu'un clique sur un pictogramme d'une tuile (ouvrir le point le plus proche à moins de 3km ?)
3. Calque vecteur ou raster ?

Léo

[Dominique]

Ta solution me donne une idée : utiliser la couche "massifs" comme couche d'agrégats pour les zooms larges.

[sly]

Bon, je suis silencieux sur ce sujet et le retour d'expé utilisateur fourni par léo mais pas du tout car je m'en fiche, mais plutôt car je ne sais pas par quel bout le prendre pour y répondre car c'est en entremêlement de bof, pour, contre, indécis ou génial.
Et comme je souhaite argumenter mon avis, je voudrais me poser le temps de formuler une réponse, mais j'ai pas réussi alors je vais tenter de le découper par morceaux.


Clustering des pictos donc, et bien j'ai un a priori plutôt négatif car :
- j'ai peur que ça ralentisse le premier affichage
- les exemples que je connais me sont désagréables en terme de manipulation, de sensation de vue tronquée (on me clusterize la vue sans raisons valables) et de lenteur.

Prenons un cas concret ; s'ils me lisent, ne le prenez pas mal, c'est justement pour voir ce qui peut être amélioré :

Rendez vous sur https://www.pyrenees-refuges.com/ à l'aide de votre smartphone, le mien est de 2014, page d'accueil, avec une 4G qui marche bien et balladez vous entre zoom pour afficher tous les pyrénéés et zoom proche pour voir les refuges.

Comment dire... c'est lent, très lent. Une fois zoomé, on est mieux en réactivité, mais passe alors au problème curieux suivant :

tt.jpeg

Pourquoi avoir clusterisé ce groupe de 2 ou de 3, y'avait bien de la place pour mettre des icônes, là, je ne sais pas s'il y a des refuges dans la zone qui m'intéresse, je suis obligé de zoomer encore, reperdre du temps.
Vous me direz, c'est sûrement un réglage

Après, si on restreint aux faibles zoom ce clustering, bon, pourquoi pas. En restant intelligent du genre : si y'a de la place, on les place, si tassé, ok, on met une puce "y'en a 50 là dedans"

A noter cette variante :
https://paraglidingearth.com/

qui s'en sort mieux en terme de réactivité et de choix de clustering
(et pis y'a pas, on l'a eu à un moment et ça me manque, mais afficher le nom sur une carte quelle idée génial ! .......)

[Dominique]

- j'ai peur que ça ralentisse le premier affichage
- les exemples que je connais me sont désagréables en terme de manipulation, de sensation de vue tronquée (on me clusterize la vue sans raisons valables) et de lenteur.

J'ai fait une petite maquette. A essayer sur ton téléphone très lent :
http://dom.refuges.info/MyOl1/examples/newvector.html
Mais sur les zooms larges, je pense afficher plutôt la carte des massifs.

Pourquoi avoir clusterisé ce groupe de 2 ou de 3, y'avait bien de la place pour mettre des icônes,

J'ai essayé de déclusteriser un groupe de 2 alors qu'ils étaient trop proches et ça donne une icone en cachant une autre.
J'ai mis le paramètre : clusteriser tout ce qui est plus proche que 8 pixels. En dessous, c'est inexploitable

afficher le nom sur une carte quelle idée génial !

ça donne ça : http://dom.refuges.info/MyOl2/examples/newvector.html
Franchement, sur des zones denses, c'est pas le pied

[aphyl]

Bonjour, pour minimiser le trafic réseau, une solution est de partir du centre de la carte par exemple et de ne renvoyer que les items inférieurs à une certaine distance (cette distance pouvant varier avec le niveau de zoom)
Par contre, je ne sais pas si cela serait complexe à mettre en œuvre sur votre site

[sly]

Je crois que c'est tout à fait réaliste, on à l'outil sous le capot pour le faire.

Et ça me rappel ce site : Keepright sur lequel j'allais souvent.

Ergonomiquement c'est surprenant d'avoir l'impression "qu'on nous cache les choses" mais à l'usage, c'est assez clair que se regroupement centré signifie : "t'as pas assez zoomé pour qu'on te montre tout"

Dans la même idée, qui est de signaler à l'utilisateur qu'il faut qu'il zoom pour en voir plus, on avait par le passé un message en rouge à gauche qui disait, dès qu'on atteignait la limite un truc genre "zoom insuffisant, seul 250 points sont affichés"

Mais je ne dis pas que ce sont les bonnes solutions, je suis aussi ouvert aux essais de clustering.

Et pis bon, à la fin, perso, je fonctionne toujours pareil, je fini par zoomer jusqu'a ce que tout s'affiche, parce que pour ces densités, ça colle à la fin bien avec le zoom carte qui m'est de toute façon nécessaire. Donc en étant extrémiste, je dirais que ne rien n'afficher me conviendrait tout autant

[sly]

J'ai fait une petite maquette. A essayer sur ton téléphone très lent :
http://dom.refuges.info/MyOl1/examples/newvector.html

Ça réagit plutôt bien.
Le OpenLayers ne semble pas ajouter les mêmes lourdeurs d'effets bling-bling comme sur PRC (ou autre raison) qui font que ça réagit bien au déplacement/zoom
En terme de transfert, le fond d'écran et finalement largement le plus consommateur depuis que j'ai bien divisé par ~10 la taille de renvoi par l'api (compression et ménage) et vu que tu ne charges tout qu'une fois, ça ne se ressent pas ensuite.

ça donne ça : http://dom.refuges.info/MyOl2/examples/newvector.html
Franchement, sur des zones denses, c'est pas le pied

C'est vrai, mais dès qu'on zoom un peu, ça devient plutôt intéressant et j'aime bien.
En ajoutant l'altitude très utile, et en évitant un bleu en gras qui chevauche l'icône je suis sûr que ça donnerait au premier coup d'oeil de l'info utile sans devoir frénétiquement passer sa souris sur chaque picto.

Je me demande où je vais chercher l'idée

présentation-IGN.png

[Dominique]

Bonjour, pour minimiser le trafic réseau, une solution est de partir du centre de la carte par exemple et de ne renvoyer que les items inférieurs à une certaine distance (cette distance pouvant varier avec le niveau de zoom)
Par contre, je ne sais pas si cela serait complexe à mettre en œuvre sur votre site

Nous utilisons la technique "BBox" qui ne demande au serveur que les points à l'intérieur de la zone visible.
Si on zoome plus large, on redemande une zone plus large.
Comme le site ne commence que par des cartes locales (une cabane, un massif) l'ensemble de la base n'est que rarement demandé.
Ce ne serait le cas pour quelqu'un voulant afficher le monde (zoom 1) mais ça ne doit pas être fréquent.

La différence entre la méthode clustering et la méthode actuelle (limitation à 250 points) est que, une fois une les points d'une zone reçus, si on zoome plus serré, on ne redemande rien au serveur puisque l'explorateur a déjà toutes les infos.
Alors qu'avec la méthode actuelle, comme on court le risque ne n'avoir reçu qu'une partie des points avec un zoom large, je force la demande à chaque pas de zoom.
Donc, bizarrement, la méthode clustering devrait générer un trafic moindre et un affichage plus rapide.

[sly]

Donc, bizarrement, la méthode clustering devrait générer un trafic moindre et un affichage plus rapide.

J'imagine que la réponse est plutôt "ça dépend" : du comportement de l'internaute d'une part : si sa porte d'entrée sur la carte se fait par un massif précis, un permalink précis ou une fiche de point existant, il y a des chances que quelques points seulement soient récupérés avant son prochain clic.
et de comment c'est codé : s'il ne zoom pas mais slide la carte, soit on a tout récupéré avant et ça pourrait être trop lourd par rapport au besoin potentiel, soit on n'a clusterisé que la vue et il va falloir alors télécharger tout à nouveau pour un coût plus grand que celui avec limite des 250.

Et le système hybride zoom fort/zoom faible demande de coder un peu plus encore de spécificités. Mais ça, à toi de nous dire !

Bref, pas sûr qu'il y ait une réponse unique.

Coté Openstreetmap et rendu de cartes vectorielles autrement plus massives en données, la mode du moment c'est le rendu vectoriel coté navigateur avec un système de tuile vectorielles : certains appels mutualisent la même donnée de sorte qu'un pan ne charge que ce qui manque, et les "tuiles" vecto contiennent des versions simplifiés de la données selon niveau de zoom.

[Dominique]

Une petite idée de ce que pourrait être la carte.
https://dom.refuges.info/MyOl3/examples/newvector.html

Je pense que dans le sélecteur (que je n'ai pas encore fait) on peut ne sélectionner que les logements par défaut (et pas les cols, lacs ou sommets)

s'il ne zoom pas mais slide la carte, soit on a tout récupéré avant et ça pourrait être trop lourd par rapport au besoin potentiel, soit on n'a clusterisé que la vue et il va falloir alors télécharger tout à nouveau pour un coût plus grand que celui avec limite des 250.

C'est vrai et je ne vois pas comment l'éviter simplement mais le passage en massifs (non bboxées) au delà d'un certain zoom limite le nombre de points à ce qu'on a aujourd'hui.

Coté Openstreetmap et rendu de cartes vectorielles autrement plus massives en données, la mode du moment c'est le rendu vectoriel coté navigateur avec un système de tuile vectorielles : certains appels mutualisent la même donnée de sorte qu'un pan ne charge que ce qui manque, et les "tuiles" vecto contiennent des versions simplifiés de la données selon niveau de zoom.

J'aime bien mais je te laisse le codage côté serveur (avec étiquettes et survol...

[Dominique]

Bonjour

Après de "longues" recherches sur le thème du "clustering", voici quelques remarques :

- Le but est de passer d'un mode d'affichage où on limite à 250 points à un regroupement des points trop proches ou trop nombreux dans des pictos "cluster".
On ne perd alors plus d'informations "il y a quelque chose là" pour les grandes échèles.

- Pour des bases au dessus de 1000 points, comme refuges.info ou chemineur.fr, le clustering par l'affichage de l'explorateur n'est pas viable pour les grandes échèles (temps de traitement de la requête SQL + taille du fichier transmis + temps de traitement par l'explorateur). Il faut introduire un niveau supérieur de regroupement au niveau du serveur.

Propositions :
1/ Le modèle "refuges.info" : pour les grandes échèles, je me rabats sur la carte colorée des massifs
http://dom.refuges.info/nav?map=9/6/45& ... chemineur= (zoomer à plus grande échèle pour voir la couche massifs)
Avantages :
- Le niveau supérieur existe déjà : les massifs
- Les filtres de type de points permettent de calculer la répartition de chaque type.
- Le traitement par le serveur et l'explorateur, la taille des fichiers transmis restent raisonnables (à tester sur de vieux mobiles)
Inconvénients :
- on ne le sait pas s'il y a des points en dehors des massifs déclarés
- on ne sait pas combien de points sont recensés dans chaque massif

2/ Le modèle "chemineur.fr" : un niveau supérieur de regroupement
http://dom.refuges.info/nav?map=9/6/45& ... =3,8,20,23
J'ai triché au niveau de la base en créant un niveau artificiel composé de carrés de 1/5 de ° longitude & latitude.
Soit : 180° (longitude) * 360° (latitude) * 5 (groupes par ° longitude) * 5 (groupes par ° latitude) = 1620000 groupements carrés possibles.
Mais il n'y en a que très peu qui contiennent réellement des points (océans, pôles, ... sont des zones vierges)
Pour les niveaux forts, la base ne renvoie que ces groupements qui sont par ailleurs regroupés suivant le zoom lors de l'affichage.
Avantages :
- Le "clustering" est efficace et rapide à toutes les échèles.
- La création du niveau supérieur est automatique (lors de la création ou modification des points)
- Le traitement par le serveur et l'explorateur, la taille des fichiers transmis restent raisonnables (à tester sur de vieux mobiles)
Inconvénient :
- Nécessite de créer un niveau supplémentaire


Note : les distance de clustering, le nombre de pictos affichables, ... sont réglables.
Les avis de goûts et couleurs sont bienvenus

[Claude Mauguier]

2/ Le modèle "chemineur.fr" : un niveau supérieur de regroupement
http://dom.refuges.info/nav?map=9/6/45& ... =3,8,20,23
J'ai triché au niveau de la base en créant un niveau artificiel composé de carrés de 1/5 de ° longitude & latitude.
Soit : 180° (longitude) * 360° (latitude) * 5 (groupes par ° longitude) * 5 (groupes par ° latitude) = 1620000 groupements carrés possibles.
Mais il n'y en a que très peu qui contiennent réellement des points (océans, pôles, ... sont des zones vierges)
Pour les niveaux forts, la base ne renvoie que ces groupements qui sont par ailleurs regroupés suivant le zoom lors de l'affichage.
Avantages :
-
-
-.
Inconvénient :
- Nécessite de créer un niveau supplémentaire
....

C'est génial !
Et le fait qu'il faille progresser d'un pas de zoom à un autre n'est en aucune façon une gène, d'autant que la mention du contenu de la "box" est annoncé...

les vieux mobiles

Je suis vieux ET mobile... ergo c'est parfait pour moi : cadre, format, nb de points par unité de regroupement, couleurs y compris !

[sly]

En préambule, j'ai navigué les deux options avec débit réduit (FF dév bar) histoire de me rendre compte.
Ma bécane n'étant pas une vielle brouette, la fluidité de l'ensemble est excellente
Essayé sur mon smartphone de 2012 en 3G, toujours excellente réactivité.

Je n'ai pas saisi tous les tenants et aboutissants techniques, mais le résultat est fonctionnel et agréable à utiliser en première instance.
C'en est presque louche ! Je me demande à quel moment ça va ramer !

Je laisse pour l'instant de coté les mini défauts trouvés et le choix d'un jaune fluo criard :

Il faut introduire un niveau supérieur de regroupement au niveau du serveur.

Pour les zoom faibles :
En rapidement expliqué, ça prend quelle forme ? tu stockes le nombre de point avec un pré-calcul au niveau du polygone ? ou tu fais faire à l'api un count par polygone et par type de point à afficher ?
Option "grille" tu génère les polygones en base ? juste ceux qui ont des points ? Tu pré-calcul pour chaque le nombre de point de chaque type ? ou juste le nombre total de point dans chaque "dalle" ?


Sinon, j'ai du mal à me rendre compte de la balance bénéfice/inconvénients en terme d'usage.
Les deux m'ont l'air acceptables vu que ce qui m'inquiétait le plus, la réactivité, est bonne.

tu dis : "Les filtres de type de points permettent de calculer la répartition de chaque type." ! heu, je ne comprends pas, vu que aucun nombre n'est affiché de toute façon ? (à zoom faible)

Voilà il est possible que je n'ai pas tout compris mais ça à l'air bien à voir en tout cas !

[Dominique]

Je me doutais que ça allait un peu fumer côté explications techniques (ce qui ce conçoit bien s'énonce clairement, et ce qui est fumeux dans ma tête ne vas pas s'arranger en l'écrivant)
Merci pour ces questions précises.

Pour les zoom faibles :
En rapidement expliqué, ça prend quelle forme ?

C'est très basique :

Lors de chaque modification j'enregistre dans la table "point" un entier qui est le même pour chaque carré de 1/5° par 1/5° :

Code : Tout sélectionner

id_carre = entier ((180 + lon) * 5) * 180 * 5 + entier ((90 + lat) * 5)

Lors de la visu zoom élévé, je ne fais que compter le nombre de points pour chaque ID de carré :

Code : Tout sélectionner

SELECT count(*) AS id_carre GROUP BY id_carre

C'est donc une requête hyper rapide.
Eventuellement, les carrés sont regroupés (en faisant le total des points inclus) lors de l'affichage par la fonction cluster d'Openlayers.

La visu en zoom rapproché est la même que d'habitude au niveau du serveur.
Le regroupement est fait dans l'explorateur par la fonction cluster d'Openlayers.

Sinon, j'ai du mal à me rendre compte de la balance bénéfice/inconvénients en terme d'usage.
Les deux m'ont l'air acceptable vu que ce qui m'inquiétait le plus (la réactivité) est bonne.

Il n'y a pas de raison technique : il faut juste décider ce qu'on préfère.
Avec les zones massifs en zoom élévé, on risque de ne pas voir les points qui ne sont pas dans un massif.
Par contre c'est très fluide pour naviguer de massif en massif : il suffit de zoomer arrière et de cliquer sur le massif.

tu dis : "Les filtres de type de points permettent de calculer la répartition de chaque type." ! heu, je ne comprends pas, vu que aucun nombre n'est affiché de toute façon ? (à zoom faible)

je veux parler du nombre dans le peti cercle blanc pour chaque regroupement;
Il pourrait être intéressant d'afficher le nb de pictos dans l'étiquette de chaque massif.

Je laisse pour l'instant de coté les mini défauts trouvés et le choix d'un jaune fluo criard :

Hum. J'en étais content. Bon : on revient au noir et blanc ?