D’après mes collègues, je ferais mieux d’utiliser SigmaJS qui est plus adapté aux graphes. Alors que D3JS est plus générique (data vizualisation : courbes, histogrammes, nuages de points…). Donc, prochainement j’essaierai d’adapter mon code pour SigmaJS. Ce serait l’équivalent de Gephi en javascript
Développement de wotmap
3 J'aimes
J’appui dans ce sens. Techniquement, SigmaJs m’a l’air bien plus :
- spécialisé graph
- capable de gérer avec fluidité des graphe de grande taille
en revanche, j’ai l’impression qu’il est plus difficile d’interagir avec le graph qu’avec D3js (je n’ai pas vu de visualisation très dynamique en sigma (avec des noeud qui se groupe au dézoom, des fiche à la sélection de noeud, des placement personnalisable…) mais pour de la visualisation de la WOT, ça me semble l’outil web idéal en effet !
3 J'aimes
J’ai commencé à étudier SigmaJS. A priori c’est possible grâce aux plugins fournis dans le code source. A priori, il serait assez facile de faire aussi ses propres plugins. Il y a d’ailleurs plein d’exemples de fournis ! Les possibilités sont bien plus importantes qu’avec D3JS c’est évident. On m’a dit aussi qu’il serait sûrement possible de faire de la “détection de communautés”. C’est-à-dire, identifier les différents ensemble de nœuds qui seraient “proches” dans la wot. Ce qui permettrait d’identifier les “groupes locaux” apr exemple. De plus, je viens d’afficher les noeuds et les links de la wot duniter grâce à SigmaJS et ça rame carrément moins dans le navigateur (sûrement grâce à WebGL) Bref, ça me semble aussi l’outil idéal en effet 
3 J'aimes
Suite à la présentation que j’ai réalisée lors des RML11 sur D3JS et SigmaJS (voir doc de présentation), certains (dont @cgeek) avaient demandé que je mette en ligne la version SigmaJS. C’est désormais chose faite sur ce lien. De plus, j’ai rajouté la possibilité de n’afficher qu’un noeud et ses voisins en cliquant dessus. Et les données sont aussi mises à jour toutes les 24H.
J’ai commencé à regarder ce qui se faisait sous SigmaJS concernant les détections de communautés (algorithme Louvain), mais je n’ai pas encore trouvé de solutions… Je continue de chercher.
6 J'aimes
Désormais vous pouvez faire de la détection de communauté avec l’algo de Louvain :https://duniter.normandie-libre.fr/wotmap2
3 J'aimes
On peut aller bien plus loin dans l’analyse, ces images révèles quantités passionnantes d’information : notamment la forme d’une communauté nous révèle les comportement de certification des membres de cette communauté et donc le respect plus ou moins bon de la licence Ğ1 :
Les communautés de forme ronde ou ellipsoïdale de faible excentricité respectent bien la licence Ğ1.
Plus l’excentricité de l’ellipse circonscrite a la communauté est élevée et moins la licence Ğ1 est correctement appliquée : notamment les communautés très allongés ne certifie quasiment que des nouveaux et ne se certifient pas assez entre-elles, la règle de distance finie par bloquer ces communautés la.
Une attaque sybil se visualiserai comme une communauté a excentricité très très élevée, donc très allongée, presque un trait.
Actuellement il y a 3 communautés dont la forme est douteuse, je les est encercler sur cette image :
Je vais contacter les gens de Lodève (en violet), j’ai l’impression qu’il ont besoin d’un rappel a la Licence Ğ1 
Concernant les 2 autres communautés encercler je n’ai reconnu personne, vous voyez qui c’est ? Si vous voyez qui c’est ce serait bien de les contacter.
A l’inverse les communautés les plus denses et rondes sont la Mayenne et la Bretagne, avec beaucoup de certifs internes, des exemples a suivre 
6 J'aimes
Je suis en train de voir pour rajouter des fonctionnalités dans la wotmap. Malheureusement, webGL ne m’offre pas bcp de flexibilité pour arriver à faire ce que je veux (à moins que je me forme à webGL ou que j’attende la v2 de SigmaJS qui risque de se faire attendre). C’est pourquoi, j’ai déployé ce matin une version de dev qui utilise canvas au lieu de WebGL.
Les fonctionnalités sont les suivantes :
- Nouveau format des liens (certifications) : les liens sont courbés et fléchés pour bien voir le sens des certifications
- Nouveau format des noeuds : ils possèdent dorénavant une bordure pour bien les distinguer.
- Recherche de membres grâce à une liste déroulante : la caméra se place sur le membre puis zoome dessus en affichant les liens avec ses voisins directs
- Affichage ou non des liens (pour afficher l’ensemble des liens, il vaut mieux attendre que la position des nœuds se stabilise, sinon le navigateur rame un peu)
- Coloration des liens lors de la détection de communautés
Voici le lien de dev : https://duniter.normandie-libre.fr/wotmaptest/
N’hésitez pas à me remonter vos remarques
Si tu veux repasser à du webgl, quelques propositions :
Si tu sais faire des disques en webgl mais pas leur ajouter une bordure : Un disque plus large derrière un premier disque te donne le même rendu visuel.
Si faire des liens courbé en webgl est le problème, tu peux faire des liens droits, mais décentré exemple :
Si c’est le calcul de la position de la flèche en fonction du diamètre du cercle cible… C’est un peu chiant à faire manuellement je te l’accorde, mais voici comment j’ai procédé dans mycelia (et donc Gvu) https://framagit.org/mycelia/mycelia-front-app/blob/master/staticApp/graph.js#L380 sans garantie que ce soit transposable facilement en webgl.
EDIT :
Autre option pour distinguer les double lien des liens uni-directionnel (mais moins efficace pour identifier le sens, sauf à avoir une couleur différent selon le sens, en vu centré sur un noeud uniquement :
1 J'aime
SigmaJS permet de mettre des images sur les noeuds du graphe. Il serait donc possible d’interroger un noeud Cesium+ pour récupérer les photos des membres. Par contre, on avait essayé d’installer duniter4j sur mon serveur avec @Benoit_Lavenier mais nous ne sommes pas allés jusqu’au bout. Est-ce que je peux interroger un noeud distant ou je suis obligé de finir l’installation/configuration sur mon serveur ?
4 J'aimes
Ca devient carrément artistique la wot la 
Sinon, je pense que tu ferais plaisir à @kimamila en faisant l’effort d’installer ton propre noeud ES Quitte à ce que tu poses des questions sur le forum lorsque tu bloques. Ca enrichira tout le monde 
EDIT : la doc est là http://doc.e-is.pro/duniter4j/
1 J'aime
Plusieurs choses :
- j’ai maintenant une image docker qui fonctionne pour lancer une noeud Cesium+. Attends quand même que @1000i100 (ou un autre dev) regarde si ca marche bien. Les lignes de commande docker sont en entête de fichier.
- Si tu veux taper sur les noeuds existants, tu peux prendre par exemple celui du Sou (moins sollicité que celui de duniter.fr) :
https://g1.data.le-sou.org/user/profile/PUBKEY/_image/avatar.png(exemple ici)
4 J'aimes
Espérons car pour le moment la toile est encore petite mais quand on sera 10.000 se sera pas la même 
Ce serait bien si on pouvait fournir dans les paramètres GET de l’url des paramètres permettant d’avoir besoin de moins de puissance, comme n’afficher que les référents, m’enfin je ne sais pas si ca demanderai effectivement moins de calcul derrière, qu’en pense tu ?
Actuellement, tout se fait côté client (à part la génération du fichier JSON). C’est le navigateur qui fait tout le travail. Je ne sais pas trop si ce serait possible de faire ça avec sigmaJS mais c’est une bonne idée. Faudra y réfléchir en effet.
1 J'aime
C’est aussi et surtout que le calcul des forces ne s’arrête jamais même lorsque la toile s’est stabilisée et que tout les nœuds ne bougent plus, donc si on veut garder l’onglet wotmap ouvert pour le consulter juste de temps en temps on doit garder un cœur à 100% tout le temps ça n’a pas de sens.
Du coup maintenant je met en pause une fois le calcul des forces terminé, afin de pouvoir garder l’onglet wotmap ouvert tout en faisant d’autres choses.
Idéalement se serait top que le calcul des forces s’arrete automatiquement lorsque les variations de positions des noeuds passent sous un certain seuil
Faudrait que l’api Cesium+ puisse te fournir le hash de l’avatar et que tu le compare au hash que tu a en cache, mais en attendant il est préférable que tu flush entièrement ton cache d’avatars de temps a autre (par exemple une fois par semaine) car a la longue les changement d’avatar pas pris en compte ça va devenir gênant .
1 J'aime
@Paidge j’ai une autre suggestion : J’ai remarquer que tu attribue la couleur d’un lien en fonction de la couleur de la cible, il me semblerait plus pertinent de te baser sur la couleur de la source.
En effet en tant que membre de la communauté verte, ma certif vers toi est en bleu clair parce que tu est membre de la communauté bleu clair. Mais ce n’est pas logique, c’est moi qui est émis et signé cette certif, donc elle devrait être en vert.
J’ai lu des choses à ce sujet et apparemment rien ne permet de déterminer si le graphe est “stabilisé”. De mémoire, l’idée avait été émise de calculer le delta de la position des noeuds…Mais trop gourmand évidemment.
Justement, je me suis posé la question. Mais à la réflexion je pense que tu as raison Comme pour le flush des avatars.
Je me demandais aussi si, une fois les communautés détectées, ce serait intéressant de pouvoir filtrer communauté par communauté (mmmh, je viens d’avoir une idée : avec des checkbox, une pour chaque communauté).
2 J'aimes
@Paidge comment est calculée la taille des cercles ?
je croyais que c’était le degré mais je vois que Yann a un plus grand cercle que JeanF alors que leurs degrés sont identiques (102).
les détails m’intéresse, si tu peut me dire quel algo calcule cette taille et comment, merci
@Paidge tiens l’export SVG n’affiche pas les avatars et ne donne que des liens droits. Ça serait cool d’avoir les liens courbés et fléchés sur l’export SVG, tu crois que c’est possible ?
Dans mon script PHP, je compte le nombre de voisins UNIQUES. C’est cette valeur que j’enregistre dans l’attribut “size” des nodes du fichier JSON. Apparemment Yann a 82 voisins directs alors que Jean n’en a que 66.
Par contre, le filtre avec le curseur utilise la méthode mygraph.degree(node.id) qui est une fonction de la librairie SigmaJS et qui retourne le degree, càd le nbre de liens (ou certifications) total qui partent et qui arrivent au nœud. Avec cette métode, on peux aussi récupérer le in-degree ou le out-degree (je pense que je n’ai pas besoin de préciser pour le coup).
Pas sûr du tout. J’avais testé une autre méthode pour afficher des images ds les noeuds et, cette fois, l’export SVG affichait les images, mais de forme carrée…Quand j’ai vu que le nouveau procédé que j’utilise n’affichait pas les images, je me disais que c’était pas bien grave. J’essaierai de voir ce qu’il est possible de faire mais ce sera tout en bas de la roadmap à mon avis.
Je ne comprend pas ta définition de voisins uniques alors. Parce que en théorie des graphes, les voisins d’un noeud sont les nœuds reliés par un arc a ce noeud, (dans un seul sens pour les graphes orientés).
Or les nombres que tu donne ne correspondent ni a leur degré intérieur ni a leur degré extérieur.
Quel est le nom de l’algo que tu utilise ? Peut etre que cet algo considère comme “voisin unique”, les nœuds reliés par 2 arcs dans les 2 sens ? Ou alors il y a une notion de centralité ?
En tout les cas ce n’est pas clair et c’est bien dommage, car je vais utiliser des screen de wotmap pour ma conf du 1er juillet, et pour l’instant je suis bien incapable de répondre a la question : que représente la taille des cercles ? 
Ok pas de souci c’est déjà génial tout ce que tu a fait
Ce qui importe le plus c’est qu’on sache comment est calculé ce qui est représenté !