Développement de wotmap

wotmap
graph
sigmajs

#41

Ce qui serait vraiment très pratique c’est de pouvoir stopper le mouvement des noeuds lorsque la toile s’est stabilisée. La j’ai toujours un cœur qui tourne à 100% alors que la toile ne bouge plus, je suis obligé de fermer l’onglet du coup.

Avec la possibilité de stopper le mouvement des noeuds, on pourrait ouvrir la wotmap une seule fois, stopper le mouvement quand ça c’est stabilisé puis garder l’onglet sous le coude pour le consulter quand on veut sans avoir besoin de refaire suer le processeur :slight_smile:


#43

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 :
liens-directionnels
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 :
liens-directionnels


#44

Merci @1000i100 mais je n’ai pas du tout regardé le code de SigmaJS qui traite le webGL. Je suis juste tombé sur qqes articles de forums qui en parlaient. Je n’ai utilisé jusqu’alors que du javascript et c’est sigmaJS qui fait le travail. Du coup, c’est vrai, ça m’intéresse un peu d’apprendre donc j’essaierai de trouver le temps un de ces 4. Sauf si la v2 de SigmaJS sort avant. Le dév m’a dit que je pouvais tester la branch dev de son dépôt github mais je ne suis pas si aventureux que ça :stuck_out_tongue:


#45

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 ?


#46

Ca devient carrément artistique la wot la :smiley:

Sinon, je pense que tu ferais plaisir à @kimamila en faisant l’effort d’installer ton propre noeud ES :wink: Quitte à ce que tu poses des questions sur le forum lorsque tu bloques. Ca enrichira tout le monde :slight_smile:

EDIT : la doc est là http://doc.e-is.pro/duniter4j/


#48

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)

#57

@Pierre_Jean_CHANCELL haaaaa la ça de la gueule :smiley:

Pour la compréhension ce serait bien d’indiquer dans la légende a quoi correspond la taille des cercles :wink:


#60

Espérons car pour le moment la toile est encore petite mais quand on sera 10.000 se sera pas la même :stuck_out_tongue:

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 ?


#61

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.


#63

Sinon @Pierre_Jean_CHANCELL comme tu garde déjà en cache les données de la wot pendant 24h tu pourrait aussi garder en cache tout les avatars pendant 24h et ne les redemander au réseau Cesium+ qu’une fois par jours :wink:


#64

C’est déjà fait @elois :wink: Et même mieux. Je ne tente de re-télécharger que les images des membres pour lesquels je n’en ai pas encore. Je ne vérifie pas encore si l’image est différente. C’est ptet faisable avec la signature du fichier… Faudra que je regarde ça


#66

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 :slight_smile:

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 .


#67

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


#68

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 :wink: 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é).


#70

ça y est. J’ai implémenté vos remarques. Le script télécharge à nouveau les images Cesium+ si elles ont plus d’une semaine, la couleur d’un lien est la même que sa source et le visiteur peut activer/désactiver l’affichage des avatars.


#71

@Pierre_Jean_CHANCELL 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 :slight_smile:


#72

@Pierre_Jean_CHANCELL 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 ?


#73

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.


#74

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 ? :confused:

Ok pas de souci c’est déjà génial tout ce que tu a fait :slight_smile:
Ce qui importe le plus c’est qu’on sache comment est calculé ce qui est représenté !


#75

Je pensais que le fait de mettre en gras le mot UNIQUE te permettrait de comprendre. Apparemment ce n’est pas le cas, alors je m’explique :
Si tu me certifies et que c’est ma seule certification, alors j’ai 1 seul voisin UNIQUE et mon degree est égal à 1. Si je te certifie en retour, j’ai toujours un seul voisin UNIQUE mais mon degree passe à 2.

En fait, le degree, c’est le nbre total de certifications entrantes ET sortantes. Alors que le nombre de voisins uniques, c’est le nombre de voisins uniques (y’a pte une autre expression ou alors le mot unique est peut-être en trop)

C’est plus clair comme ça ? :stuck_out_tongue: