« STIC:STIC III (2018)/Physicalisation de statistiques au hockey sur glace » : différence entre les versions

De EduTech Wiki
Aller à la navigation Aller à la recherche
(objectifs)
 
(31 versions intermédiaires par le même utilisateur non affichées)
Ligne 7 : Ligne 7 :
|cat tutoriel=Physicalisation de données
|cat tutoriel=Physicalisation de données
}}
}}
==Description du projet==
[[Fichier:Heatmap au hockey sur glace.png|gauche|vignette|393x393px|Heatmap générée avec pHpOCKEY]]
 
==Introduction==
Ce projet créé dans le cadre du cours [[STIC:STIC III|STIC III]] a pour but de proposer des visualisations évocatrices des statistiques de hockey sur glace. Elle se reposera sur un ''[[wp_fr:Analyse_syntaxique|parser]]'' XML écrit en php, qui produira une ''[[wp_fr:Heat_map|heatmap]]'' qui sera déclinée sur divers supports.
Ce projet créé dans le cadre du cours [[STIC:STIC III|STIC III]] a pour but de proposer des visualisations évocatrices des statistiques de hockey sur glace. Elle se reposera sur un ''[[wp_fr:Analyse_syntaxique|parser]]'' XML écrit en php, qui produira une ''[[wp_fr:Heat_map|heatmap]]'' qui sera déclinée sur divers supports.


Ce projet est en construction est sera terminé d'ici fin août 2019.
Ce projet est terminé dans le cadre du cours mais il sera poursuivi afin d'arriver à un projet plus abouti.


==Objectifs==
==Objectifs==
La compréhension de données statistiques est une tâche difficile, surtout lorsqu'elles sont présentées dans un tableau. Il existe actuellement des représentations visuelles assez basiques qui consiste à indiquer l'emplacement d'une action de jeu à l'endroit où elle a eu lieu. Cependant ces représentations graphiques en deux dimensions ont comme faiblesse de ne pas fournir d'indications quant à la concentration des actions qui peuvent se superposer. Ce problème s'amplifie lorsque le nombres d'actions augmente.
La compréhension de données statistiques est une tâche difficile, surtout lorsqu'elles sont présentées dans un tableau (la situation actuelle). Il existe actuellement des représentations visuelles assez basiques qui consistent à indiquer l'emplacement d'une action de jeu à l'endroit où elle a eu lieu. Bien que ces représentations graphiques en deux dimensions possèdent une certaine affordance, elles ont comme faiblesse de ne pas fournir d'indications quant à la concentration des actions qui peuvent se superposer. Ce problème s'amplifie lorsque le nombre d'actions augmente, comme on peut le voir sur l'illustration jointe.
[[Fichier:Illustration SOG STICIII KOul.png|alt=Sur cette image on a un exemple de visualisation bidimensionnelle que l'on utilise en hockey sur glace. Elle illustre bien le problème de la précision lorsque des évènements se superposent.|vignette|Sur cette image, on a un exemple de visualisation bidimensionnelle que l'on utilise en hockey sur glace. Elle illustre bien le problème de la précision lorsque des évènements se superposent.]]
 
== Apports théoriques ==
Un coach n'a que très peu de temps à consacrer à l'analyse statistique de son équipe, il faut donc que la physicalisation soit simple à comprendre tout en étant précise (nous avons vu précédemment que les visualisations actuellement utilisées sont simples à comprendre mais peu précises).
 
En s'appuyant sur la notion d'affordance popularisée par James Gibson nous allons chercher à créer un objet dont l'ergonomie suggère sa propre utilisation. Nous allons également nous intéresser aux apports de William Gaver pour qui l'affordance est « les propriétés de l'environnement qui rendent certaines actions possibles pour un individu équipé à cette fin ».
 
Nous allons donc proposer des objets tangibles qui seront évocateurs pour leur public cible (joueurs, coachs) en lui donnant une forme de patinoire, en ajoutant les lignes et les cages. Cette conclusion n'est pas simplement le fruit de la littérature scientifique mais d'une consultation avec les utilisateurs finaux.  


Pour mener à bien ce projet il y a plusieurs défis à relever.
== Méthode utilisée ==
* En premier lieu il faudra récupérer les données saisies sous un format utilisable par l'ordinateur (actuellement elles sont sous une forme visuelle).
Il s'agit là d'une méthode centrée utilisateur, puisque tout a commencé par un entretien avec les utilisateurs. Ce projet va essayer de répondre du mieux possible à leurs besoins. On est en droit de se demander pourquoi ne pas utiliser une ''heatmap'' traditionnelle ? Toutes les ''heatmaps'' ont une échelle de couleurs pour pouvoir les lire. En remplaçant l'information de couleur par un ajout d'une information de hauteur physique, on contourne ce problème et on y rend plus simple à lire. De même, on peut opérer des comparaisons plus facilement. Par exemple, sur une ''heatmap'' classique les valeurs en orange seront deux fois plus élevées que les valeurs en vert, sans lire la légende c'est impossible à déterminer, en revanche si vous comparez des hauteurs physiques, cela devient trivial.
* Dans un deuxième temps il faudra développer un algorithme d'interprétation des données.
* Ensuite il faudra développer un algorithme permettant de produire des objets tangibles à partir de ces données.


==Projet 1 - ''Heatmap'' en 3D des tirs cadrés==
Après s'être entretenu avec les utilisateurs, il reste encore des défis à relever :
Dans ce projet je vais imprimer en 3D une réplique de patinoire dont la topographie indiquera l'emplacement et la quantité de tirs cadrés.
* En premier lieu, il faudra récupérer les données saisies sous un format utilisable par l'ordinateur (actuellement elles sont sous une forme visuelle).
* Dans un deuxième temps, il faudra développer un algorithme d'interprétation des données.
* Ensuite, il faudra développer un algorithme permettant de produire des objets tangibles à partir de ces données.
 
==pHpOCKEY - ''Heatmap'' en 3D des tirs cadrés==
Dans ce projet, je vais imprimer en 3D une réplique de patinoire dont la topographie indiquera l'emplacement et la quantité de tirs cadrés.


Les données statistiques sont exportées au format XML. Le fichier obtenu ressemble à ce qui suit.<syntaxhighlight lang="xml" line="1">
Les données statistiques sont exportées au format XML. Le fichier obtenu ressemble à ce qui suit.<syntaxhighlight lang="xml" line="1">
Ligne 47 : Ligne 60 :
</GAMEACTION>
</GAMEACTION>
</syntaxhighlight>Pour réaliser ma heatmap je vais avoir besoin des éléments suivants :  
</syntaxhighlight>Pour réaliser ma heatmap je vais avoir besoin des éléments suivants :  
* <DETAIL> pour identifier si il s'agi d'un tir cadré
* <DETAIL> pour identifier s'il s'agit d'un tir cadré.
* <POSITION_X> et <POSITION_Y> pour pouvoir y situer sur la surface de jeu.
* <POSITION_X> et <POSITION_Y> pour pouvoir y situer sur la surface de jeu.
Il y a là un premier problème, je ne sais pas à quoi correspondent ces valeurs. Où se trouve le 0 ? Quel est le maximum ?
Il y a là un premier problème, je ne sais pas à quoi correspondent ces valeurs. Où se trouve le 0 ? Quel est le maximum ?
Ligne 55 : Ligne 68 :


===Démarche===
===Démarche===
La première étape est la collecte de données, ces données ayant déjà été collectées je peux passer à l'étape suivante qui consiste à extraire les données pertinentes.
La première étape est la collecte de données, ces données ayant déjà été collectées, je peux passer à l'étape suivante qui consiste à extraire les données pertinentes.
Pour ce faire je vais coder un algorithme utilisant XPath qui me permettra de cibler les GAMEACTION correspondant à un tir cadré, puis à en récupérer la position.
Pour ce faire je vais coder un algorithme utilisant XPath qui me permettra de cibler les GAMEACTION correspondant à un tir cadré, puis à en récupérer la position.


====Description de l'algorithme d'analyse syntaxique (''parsing'')====
====Description de l'algorithme d'analyse syntaxique (''parsing'')====
*Scanner le dossier dans lequel se trouve les fichiers XML, placer leurs noms dans un array et les passer au ''parser''.
*Scanner le dossier dans lequel se trouve les fichiers XML, placer leurs noms dans un array et les passer au ''parser''.
*Repérer tous les tirs cadrés d'une équipe dans le XML avec XPath et les placer dans un array (ces paramètres seront des arguments, utile si on veut travailler sur d'autres équipes ou d'autres actions de jeu).
*Repérer tous les tirs cadrés d'une équipe dans le XML avec XPath et les placer dans un array (ces paramètres seront des arguments, utiles si on veut travailler sur d'autres équipes ou d'autres actions de jeu).
*L'array créé par SimpleXML contient des objets, il faut donc récupérer les valeurs contenues dans les objets les arrondir et les ''push'' dans un autre array.
*L'array créé par SimpleXML contient des objets, il faut donc récupérer les valeurs contenues dans les objets, les arrondir et les ''push'' dans un autre array.
*Ensuite on crée un tableau (''multidimensional array'') que l'on rempli de 0.
*Ensuite, on crée un tableau (''multidimensional array'') que l'on remplit de 0.
*Pour remplir les case correspondantes à chaque tir on récupère chaque paire de coordonnées (un x et un y), et ensuite on incrémente la case du tableau correspondant.
*Pour remplir les cases correspondantes à chaque tir, on récupère chaque paire de coordonnées (un x et un y), et ensuite on incrémente la case du tableau correspondant.
*On répète l'opération pour tous les fichiers présents dans le dossier.
*On répète l'opération pour tous les fichiers présents dans le dossier.
*On exporte le tableau dans le dossier de travail.
*On exporte le tableau dans le dossier de travail.


Le code s'exécute en ligne de commande mais on pourrait imaginer lui donner une interface utilisateur dans le navigateur. L'avantage de l'exécution en ligne de commande est de s'affranchir de la durée d'exécution maximale. On peut augmenter cette valeur en modifiant <code>php.ini</code> cependant cela ne devrait pas être nécessaire.
Afin de respecter les bonnes pratiques, l'utilisateur n'appelle pas directement le parser mais un script unique qui s'occupe lui d'appeler les autres fonctions.
==== Code du parser ====
==== Code du parser ====
Le code s'exécute en ligne de commande mais on pourrait imaginer lui donner une interface utilisateur dans le navigateur. L'avantage de l'exécution en ligne de commande est de s'affranchir de la durée d'exécution maximale. On peut augmenter cette valeur en modifiant <code>php.ini</code> cependant cela ne devrait pas être nécessaire.
Le code est disponible sur GitHub : https://github.com/oulevey/pHpOCKEY.
 
==== Comment utiliser les scripts ====
Pour info : les informations qui vont suivre sont complémentaires à la lecture du README. On lance l'application en exécutant <code>php index.php dossier_d'entrée dossier_de_sortie [options]</code> les options que l'on peut entrer sont <code>--scad</code> pour créer une ''heatmap'' au format OpenSCAD ou <code>--png</code> pour créer une ''heatmap'' qui est une image PNG. On peut également solliciter l'aide et la version avec, respectivement, <code>--help</code> et <code>--version</code>.
 
Dans le dossier d'entrée, on place les fichiers XML respectant la grammaire mentionnée auparavant. Dans le dossier de sortie, on trouvera nos ''heatmaps'' (si le dossier n'existe pas, il sera créé).
 
Le ''parser'' va ensuite procéder à l'analyse syntaxique et créer la matrice qui sera soit convertie en fichier SCAD (génération d'un fichier heatmap.scad par le ''parser'') ou alors la matrice est transmise à une nouvelle fonction qui va créer la ''heatmap'' en PNG (création d'un fichier heatmap.dat). Les deux options ne sont pas mutuellement exclusives.
 
Une fois le script exécuté, on trouve dans le dossier de sortie 3 fichiers au format SCAD :
* config.scad qui contient divers paramètres que l'on peut ajuster (notamment la taille des lignes, et des pucks qui vont servir à représenter les tirs)
* heatmap.scad qui contient la matrice qui sert à produire notre ''heatmap'' en 3D
* build.scad qui, à partir des deux fichiers précédents, va créer la représentation 3D
L'utilisateur doit donc ouvrir le fichier build.scad pour avoir sa heatmap en 3D.
[[Fichier:Rendu pHpOCKEY.png|alt=Rendu 3D représentant une patinoire avec des pucks de tailles différentes dessus symbolisant l'emplacement et le nombre de tirs.|vignette|Rendu en 3D de pHpOCKEY]]
 
==== Difficultés rencontrées ====
La difficulté principale résidait dans le codage de l'algorithme en PHP car il s'agi d'un langage que je ne maîtrise pas franchement, cependant j'ai pu trouver de l'aide auprès de [https://github.com/lautr3k Sébastien Mischler] (énormément) ainsi que [[Utilisateur:Nicolas Hürzeler|Nicolas Hürzeler]] et [[Utilisateur:SMorand|Stéphane Morand]] que je remercie tous.
 
C'était également assez compliqué de choisir comment représenter les évènements en impression 3D, l'idée de base était de faire des pics, mais c'était impossible de les imprimer. Je me suis donc tourné vers des formes plus basiques, en l'occurence des cylindres qui rappellent les pucks (brillante idée de Sébastien).
 
Finalement, ce n'est pas une difficulté à proprement parler mais plus une perte de temps considérable : la génération des fichiers XML doit se faire manuellement à l'heure actuelle et ils sont envoyés par email. C'était une tâche particulièrement chronophage.
 
== Evaluation de la solution ==
[[Fichier:Heatmap imprimée en 3D.jpg|alt=Heatmap imprimée en 3D|vignette|Heatmap imprimée en 3D]]
 
==== Avantages ====
* Le produit fini est très simple d'utilisation, personne n'a eu besoin d'explications.
* L'objet est plaisant, cela suscite beaucoup d'intérêt chez les gens, qui commencent donc à s'intéresser aux statistiques.
* Pour la plupart des joueurs, c'est quelque chose de nouveau qui attise leur curiosité.
 
==== Inconvénients ====
* Production trop lente, l'impression 3D est un processus trop lent.
* Manque encore d'automatisation à mon goût.
* L'application est un peu complexe à utiliser pour un néophyte (on peut avoir à utiliser <code>chmod</code> pour permettre à PHP d'écrire dans le répertoire).
* Bien que le code nécessite des optimisations il est à la peine lorsqu'il doit gérer plusieurs centaines d'éléments.
 
== Conclusion ==
Ce projet est un succès sur plusieurs aspects, tout d'abord car j'ai réussi à répondre aux demandes des utilisateurs. Le projet est fonctionnel à l'heure actuelle, quelques améliorations restent à apporter (voir section suivante). Les utilisateurs ont manifesté un intérêt nouveau pour les statistiques, qui sont une part grandissante du hockey sur glace moderne. Le utilisateurs ont également grandement apprécié d'avoir une représentation concrète du travail effectué.
 
== Evolutions futures ==
Ce projet ayant rencontré un grand intérêt et une bonne réception auprès du public, j'ai prévu de le faire évoluer selon les axes suivants (il n'y a aucune notion de priorité) :
* Création de ''heatmaps'' classiques automatiquement et pendant le match
* Ajouter un argument pour spécifier le nom de l'équipe
* Placer ce projet sur un serveur qui traiterait automatiquement les données
* Ajouter des arguments qui permettront de choisir quelles actions on veut obtenir
* Créer une interface utilisateur
* Pré-analyse automatique des données avec mise en évidence des statistiques problématiques


Afin de respecter les bonnes pratiques l'utilisateur n'appelle pas directement le parser mais un script unique qui s'occupe lui d'appeler les autres fonctions.
*
*
===Ressources===
==Ressources==
* [https://www.ibm.com/developerworks/library/x-xpathphp/index.html Using XPath with PHP (IBM Developper)]
* [https://www.ibm.com/developerworks/library/x-xpathphp/index.html Using XPath with PHP (IBM Developper)]
* [[Tutoriel XPath]]
* [[Tutoriel XPath]]
== Références ==
* Gaver, W. W. (1991, April). Technology affordances. In ''Proceedings of the SIGCHI conference on Human factors in computing systems'' (pp. 79-84). Acm.
* Gibson, J. J. (1979). The theory of affordances. The ecological approach to visual perception.

Dernière version du 20 octobre 2019 à 09:43

Physicalisation de données
Module: STIC:STIC III (2018)/Projets
brouillon débutant
2019/10/20
Heatmap générée avec pHpOCKEY

Introduction

Ce projet créé dans le cadre du cours STIC III a pour but de proposer des visualisations évocatrices des statistiques de hockey sur glace. Elle se reposera sur un parser XML écrit en php, qui produira une heatmap qui sera déclinée sur divers supports.

Ce projet est terminé dans le cadre du cours mais il sera poursuivi afin d'arriver à un projet plus abouti.

Objectifs

La compréhension de données statistiques est une tâche difficile, surtout lorsqu'elles sont présentées dans un tableau (la situation actuelle). Il existe actuellement des représentations visuelles assez basiques qui consistent à indiquer l'emplacement d'une action de jeu à l'endroit où elle a eu lieu. Bien que ces représentations graphiques en deux dimensions possèdent une certaine affordance, elles ont comme faiblesse de ne pas fournir d'indications quant à la concentration des actions qui peuvent se superposer. Ce problème s'amplifie lorsque le nombre d'actions augmente, comme on peut le voir sur l'illustration jointe.

Sur cette image on a un exemple de visualisation bidimensionnelle que l'on utilise en hockey sur glace. Elle illustre bien le problème de la précision lorsque des évènements se superposent.
Sur cette image, on a un exemple de visualisation bidimensionnelle que l'on utilise en hockey sur glace. Elle illustre bien le problème de la précision lorsque des évènements se superposent.

Apports théoriques

Un coach n'a que très peu de temps à consacrer à l'analyse statistique de son équipe, il faut donc que la physicalisation soit simple à comprendre tout en étant précise (nous avons vu précédemment que les visualisations actuellement utilisées sont simples à comprendre mais peu précises).

En s'appuyant sur la notion d'affordance popularisée par James Gibson nous allons chercher à créer un objet dont l'ergonomie suggère sa propre utilisation. Nous allons également nous intéresser aux apports de William Gaver pour qui l'affordance est « les propriétés de l'environnement qui rendent certaines actions possibles pour un individu équipé à cette fin ».

Nous allons donc proposer des objets tangibles qui seront évocateurs pour leur public cible (joueurs, coachs) en lui donnant une forme de patinoire, en ajoutant les lignes et les cages. Cette conclusion n'est pas simplement le fruit de la littérature scientifique mais d'une consultation avec les utilisateurs finaux.

Méthode utilisée

Il s'agit là d'une méthode centrée utilisateur, puisque tout a commencé par un entretien avec les utilisateurs. Ce projet va essayer de répondre du mieux possible à leurs besoins. On est en droit de se demander pourquoi ne pas utiliser une heatmap traditionnelle ? Toutes les heatmaps ont une échelle de couleurs pour pouvoir les lire. En remplaçant l'information de couleur par un ajout d'une information de hauteur physique, on contourne ce problème et on y rend plus simple à lire. De même, on peut opérer des comparaisons plus facilement. Par exemple, sur une heatmap classique les valeurs en orange seront deux fois plus élevées que les valeurs en vert, sans lire la légende c'est impossible à déterminer, en revanche si vous comparez des hauteurs physiques, cela devient trivial.

Après s'être entretenu avec les utilisateurs, il reste encore des défis à relever :

  • En premier lieu, il faudra récupérer les données saisies sous un format utilisable par l'ordinateur (actuellement elles sont sous une forme visuelle).
  • Dans un deuxième temps, il faudra développer un algorithme d'interprétation des données.
  • Ensuite, il faudra développer un algorithme permettant de produire des objets tangibles à partir de ces données.

pHpOCKEY - Heatmap en 3D des tirs cadrés

Dans ce projet, je vais imprimer en 3D une réplique de patinoire dont la topographie indiquera l'emplacement et la quantité de tirs cadrés.

Les données statistiques sont exportées au format XML. Le fichier obtenu ressemble à ce qui suit.

 1 <GAMEACTION>
 2 			<TEAM>Flaming Eagles HC</TEAM>
 3 			<TIME>3756</TIME>
 4 			<TYPE>SHOT</TYPE>
 5 			<DETAIL>SOG</DETAIL>
 6 			<SS>5-5</SS>
 7 			<SCORER>24</SCORER>
 8 			<PLUS1>3</PLUS1>
 9 			<PLUS2>11</PLUS2>
10 			<PLUS3>16</PLUS3>
11 			<PLUS4>25</PLUS4>
12 			<PLUS5>24</PLUS5>
13 			<PLUS6>14</PLUS6>
14 			<GK>14</GK>
15 			<GK_OPPONENT>149</GK_OPPONENT>
16 			<DATETIME>1541271623</DATETIME>
17 			<PERIOD>1</PERIOD>
18 			<POSITION_X>4.691489</POSITION_X>
19 			<POSITION_Y>20.90425</POSITION_Y>
20 			<POSITION>L-POINT</POSITION>
21 			<ZONE>OFFENSIVE</ZONE>
22 		</GAMEACTION>

Pour réaliser ma heatmap je vais avoir besoin des éléments suivants :

  • <DETAIL> pour identifier s'il s'agit d'un tir cadré.
  • <POSITION_X> et <POSITION_Y> pour pouvoir y situer sur la surface de jeu.

Il y a là un premier problème, je ne sais pas à quoi correspondent ces valeurs. Où se trouve le 0 ? Quel est le maximum ? Après avoir placé des données dans les coins de la patinoire j'ai pu déterminer que les positions vont de 0 à 30 sur l'axe des X (petit côté de la patinoire) et de 0 à 60 pour l'axe des Y (long côté). C'est assez logique puisque une patinoire européenne fait 30m*60m.

L'algorithme que je vais mettre en place devra donc extraire les positions X et Y de tous les tirs cadrés (SOG).

Démarche

La première étape est la collecte de données, ces données ayant déjà été collectées, je peux passer à l'étape suivante qui consiste à extraire les données pertinentes. Pour ce faire je vais coder un algorithme utilisant XPath qui me permettra de cibler les GAMEACTION correspondant à un tir cadré, puis à en récupérer la position.

Description de l'algorithme d'analyse syntaxique (parsing)

  • Scanner le dossier dans lequel se trouve les fichiers XML, placer leurs noms dans un array et les passer au parser.
  • Repérer tous les tirs cadrés d'une équipe dans le XML avec XPath et les placer dans un array (ces paramètres seront des arguments, utiles si on veut travailler sur d'autres équipes ou d'autres actions de jeu).
  • L'array créé par SimpleXML contient des objets, il faut donc récupérer les valeurs contenues dans les objets, les arrondir et les push dans un autre array.
  • Ensuite, on crée un tableau (multidimensional array) que l'on remplit de 0.
  • Pour remplir les cases correspondantes à chaque tir, on récupère chaque paire de coordonnées (un x et un y), et ensuite on incrémente la case du tableau correspondant.
  • On répète l'opération pour tous les fichiers présents dans le dossier.
  • On exporte le tableau dans le dossier de travail.

Le code s'exécute en ligne de commande mais on pourrait imaginer lui donner une interface utilisateur dans le navigateur. L'avantage de l'exécution en ligne de commande est de s'affranchir de la durée d'exécution maximale. On peut augmenter cette valeur en modifiant php.ini cependant cela ne devrait pas être nécessaire.

Afin de respecter les bonnes pratiques, l'utilisateur n'appelle pas directement le parser mais un script unique qui s'occupe lui d'appeler les autres fonctions.

Code du parser

Le code est disponible sur GitHub : https://github.com/oulevey/pHpOCKEY.

Comment utiliser les scripts

Pour info : les informations qui vont suivre sont complémentaires à la lecture du README. On lance l'application en exécutant php index.php dossier_d'entrée dossier_de_sortie [options] les options que l'on peut entrer sont --scad pour créer une heatmap au format OpenSCAD ou --png pour créer une heatmap qui est une image PNG. On peut également solliciter l'aide et la version avec, respectivement, --help et --version.

Dans le dossier d'entrée, on place les fichiers XML respectant la grammaire mentionnée auparavant. Dans le dossier de sortie, on trouvera nos heatmaps (si le dossier n'existe pas, il sera créé).

Le parser va ensuite procéder à l'analyse syntaxique et créer la matrice qui sera soit convertie en fichier SCAD (génération d'un fichier heatmap.scad par le parser) ou alors la matrice est transmise à une nouvelle fonction qui va créer la heatmap en PNG (création d'un fichier heatmap.dat). Les deux options ne sont pas mutuellement exclusives.

Une fois le script exécuté, on trouve dans le dossier de sortie 3 fichiers au format SCAD :

  • config.scad qui contient divers paramètres que l'on peut ajuster (notamment la taille des lignes, et des pucks qui vont servir à représenter les tirs)
  • heatmap.scad qui contient la matrice qui sert à produire notre heatmap en 3D
  • build.scad qui, à partir des deux fichiers précédents, va créer la représentation 3D

L'utilisateur doit donc ouvrir le fichier build.scad pour avoir sa heatmap en 3D.

Rendu 3D représentant une patinoire avec des pucks de tailles différentes dessus symbolisant l'emplacement et le nombre de tirs.
Rendu en 3D de pHpOCKEY

Difficultés rencontrées

La difficulté principale résidait dans le codage de l'algorithme en PHP car il s'agi d'un langage que je ne maîtrise pas franchement, cependant j'ai pu trouver de l'aide auprès de Sébastien Mischler (énormément) ainsi que Nicolas Hürzeler et Stéphane Morand que je remercie tous.

C'était également assez compliqué de choisir comment représenter les évènements en impression 3D, l'idée de base était de faire des pics, mais c'était impossible de les imprimer. Je me suis donc tourné vers des formes plus basiques, en l'occurence des cylindres qui rappellent les pucks (brillante idée de Sébastien).

Finalement, ce n'est pas une difficulté à proprement parler mais plus une perte de temps considérable : la génération des fichiers XML doit se faire manuellement à l'heure actuelle et ils sont envoyés par email. C'était une tâche particulièrement chronophage.

Evaluation de la solution

Heatmap imprimée en 3D
Heatmap imprimée en 3D

Avantages

  • Le produit fini est très simple d'utilisation, personne n'a eu besoin d'explications.
  • L'objet est plaisant, cela suscite beaucoup d'intérêt chez les gens, qui commencent donc à s'intéresser aux statistiques.
  • Pour la plupart des joueurs, c'est quelque chose de nouveau qui attise leur curiosité.

Inconvénients

  • Production trop lente, l'impression 3D est un processus trop lent.
  • Manque encore d'automatisation à mon goût.
  • L'application est un peu complexe à utiliser pour un néophyte (on peut avoir à utiliser chmod pour permettre à PHP d'écrire dans le répertoire).
  • Bien que le code nécessite des optimisations il est à la peine lorsqu'il doit gérer plusieurs centaines d'éléments.

Conclusion

Ce projet est un succès sur plusieurs aspects, tout d'abord car j'ai réussi à répondre aux demandes des utilisateurs. Le projet est fonctionnel à l'heure actuelle, quelques améliorations restent à apporter (voir section suivante). Les utilisateurs ont manifesté un intérêt nouveau pour les statistiques, qui sont une part grandissante du hockey sur glace moderne. Le utilisateurs ont également grandement apprécié d'avoir une représentation concrète du travail effectué.

Evolutions futures

Ce projet ayant rencontré un grand intérêt et une bonne réception auprès du public, j'ai prévu de le faire évoluer selon les axes suivants (il n'y a aucune notion de priorité) :

  • Création de heatmaps classiques automatiquement et pendant le match
  • Ajouter un argument pour spécifier le nom de l'équipe
  • Placer ce projet sur un serveur qui traiterait automatiquement les données
  • Ajouter des arguments qui permettront de choisir quelles actions on veut obtenir
  • Créer une interface utilisateur
  • Pré-analyse automatique des données avec mise en évidence des statistiques problématiques

Ressources

Références

  • Gaver, W. W. (1991, April). Technology affordances. In Proceedings of the SIGCHI conference on Human factors in computing systems (pp. 79-84). Acm.
  • Gibson, J. J. (1979). The theory of affordances. The ecological approach to visual perception.