FESP_FRONTEND_4 - Ajout d'un picto illustrant le groupe taxonomique

[andriacap]

Epic: "Fiche espèce" #2981

On souhaite ajouter un pictogramme illustrant le groupe taxonomique (voir image ci dessous)

Il s'agit ici de faire une recherche parmi l'existant pour trouver une représentation libre, satisfaisante, et couvrant le maximum d'usage.

Le choix de représentation qui sera fait ici ne fera pas l'unanimité, et devra donc être customizable.

Dev envisagés et Discussion:

Se baser sur ce qui est fait dans l'atlas , à savoir donner à l'utilisateur la possibilité de choisir ces propres icones .
Actuellement dans l'atlas , c'est utilisé de cette manière :

src="{{ url_for('static', filename='images/picto_' + obs.group2_inpn | replace(" ", " _")
                            +'.png') }}"

Ce qui est commenté dans le ticket (PnX-SI/GeoNature#2981 (comment))

On n'a pas de picto pour les rangs ou les groupes INPN. Il faudra donc en ajouter dans la BDD au niveau de TaxHub. On a vu dans GeoNature-atlas pas évident d'avoir les mêmes pour un même groupe selon les contextes de chaque GeoNature, et qu'il fallait que cela soit customisable. A voir si on peut avoir des pictos (libres, à créditer) assez génériques pour que la plupart s'y retrouve ?
Idem pour les pictos des statuts. On n'a pas ça dans la BDD actuellement. A ajouter, libres, partageables et assez simples et génériques.

Du coup si l'orientation bdd serait validé , est ce qu'un picto par défaut devrait être stocké en bdd pour le groupe 2 inpn? dans quelle table serait ajouté les pictos ?

Sachant qu'il y a des discussions en cours sur la structure meme du schema taxonomie (suppression de bib_noms ?) où est ce qu'il serait envisagé de stocker les pictos ?

[camillemonchicourt]

En effet, il faut gérer cela dans la BDD au niveau de TaxHub.
Ça serait plus propre que l'Atlas pour la customisation.
Un champs picto faisant référence à une image PNG ou un SVG proprement stocké et modifiable niveau BDD.
Il faut certainement ajouter une table pour cela dans TaxHub, si il n'y a pas déjà une table des rangs (je ne sais plus), ainsi que son API.
Cela n'a pas de rapport avec la suppression de bib_noms il me semble.
Pour faire simple, pas forcément besoin de fournir des pictos par défaut, même si ça serait mieux.
Dans tous les cas, prendre en compte le cas où on n'a pas de picto pour le rang ou groupe souhaité.

A terme l'Atlas pourrait aussi se baser dessus, mais c'est un autre sujet.

[andriacap]

Merci pour ton retour Camille.

Concernant la mise en place de pictogramme dans la BDD , si on se base sur la relation suivante : Un pictogramme peut être associé à une entité rang ou statut . Un rang ou Statut peut être associé qu'à un seul pictogramme. Avec notamment une contrainte d'exclusion qui fait qu'un pictogramme ne pas être associé à la fois à l'entité rang et l'entité statut.
Alors on créé une table bib_pictograms qui aura une relation one to one avec les deux autres entités:

erDiagram
   PICTOGRAMME {
       int id_pictogramme
       string nom_pictogramme
       string chemin_fichier
       int id_rang FK
       int id_statut FK
   }

   BIB_TAXREF_RANG {
       int id_rang
       string nom_rang
       string nom_rang_en
       string tri_rang
   }

   BIB_TAXREF_STATUTS {
       int id_statut
       string nom_statut
   }

   PICTOGRAMME o|--|| BIB_TAXREF_RANG : "associe à"
   PICTOGRAMME o|--|| BIB_TAXREF_STATUTS : "associe à"
   %% Contrainte d'exclusion : Un pictogramme ne peut être associé qu'à un rang ou à un statut, mais pas les deux.

Loading

Ce qui donne au format MCD :

ents/assets/53667ee7-a4d2-420c-962a-4955a292b46e)

Et en modèle relationnel on aurait

STATUT (id, id_statut, nom_statut)
    clé primaire : id
    clé étrangère : id référence PICTOGRAMME(id)

PICTOGRAMME (id, nom_pictogramme, chemin_fichier, idRANG, idSTATUT)
    clé primaire : id
    clé étrangère : idRANG référence RANG(id)
    clé étrangère : idSTATUT référence STATUT(id)

RANG (id, id_rang, nom_rang, nom_rang_en, tri_rang)
    clé primaire : id
    clé étrangère : id référence PICTOGRAMME(id)

[camillemonchicourt]

Ça me semble plus simple et plus classique d'ajouter un champs "picto" dans chacune de ces 2 tables.

Il faut néanmoins vérifier si ces tables ne sont pas vidées et repeuplées à chaque mise à jour de Taxref.
Et il faudrait déplacer cette discussion dans le dépôt de TaxHub.

[andriacap]

Pour le déplacement d'issues, pour éviter de le faire manuellement avec une nouvelle issue et des copié coller , j'ai tenté via le github CLI mais je n'ai pas les droits (@Pierre-Narcisi , @jacquesfize ) : gh issue transfer 3130 --repo PnX-SI/GeoNature PnX-SI/TaxHub GraphQL: andriacap does not have the correct permissions to execute TransferIssue(transferIssue)
Du coup si quelqu'un à les droits je veux bien qu'il s'en charge en CLI .

Ok donc tu me confirmes ce qui serait envisagé :

• Ajout des champs "picto" dans chacune des deux tables (à condition qu'elle ne soit pas repeuplé) ?
• Des développements devront être réalisés pour gérer la gestion de ces picto via l'interface taxhub ?

Pour la question de savoir si ces tables sont repeuplées, j'imagine qu' @amandine-sahl saura nous répondre assez facilement.

Merci

[andriacap]

Salut,

J'ai regardé l'impact de la mise à jour de TaxRref. De ce que je comprend ce sont les tables bdc_statut qui sont vidées et repeuplées
Voir :

TaxHub/apptax/taxonomie/commands/utils.py

Lines 210 to 222 in 14614a7

	def truncate_bdc_statuts():
	db.session.execute(
	"""
	TRUNCATE
	taxonomie.bdc_statut,
	taxonomie.bdc_statut_type,
	taxonomie.bdc_statut_text,
	taxonomie.bdc_statut_values,
	taxonomie.bdc_statut_taxons,
	taxonomie.bdc_statut_cor_text_values,
	taxonomie.bdc_statut_cor_text_area
	"""
	)

Pour les tables bib_taxref_rang et bib_taxref_statut de nouvelles données sont insérées mais je ne vois pas de mise à jour où de processus de mise à jour ou de suppression de données existantes .

Voir :

TaxHub/apptax/taxonomie/commands/taxref_v15_v16.py

Lines 63 to 82 in 14614a7

	with archive.open("rangs_note.csv") as f:
	logger.info(f"Insert TAXREF v{num_version} rangs…")
	copy_from_csv(
	f,
	"bib_taxref_rangs",
	encoding="WIN1252",
	delimiter=";",
	dest_cols=("tri_rang", "id_rang", "nom_rang", "nom_rang_en"),
	)
	with archive.open("statuts_note.csv") as f:
	logger.info(f"Insert TAXREF v{num_version} statuts…")
	copy_from_csv(
	f,
	"bib_taxref_statuts",
	encoding="WIN1252",
	delimiter=";",
	dest_cols=("id_statut", "nom_statut"),
	source_cols=("statut", "description"),
	)
	with archive.open(taxref_file_name) as f:

La question je me pose du coup c'est est ce que lorsqu'on parle de statut il s'agit bien de bib_taxref_statut ou de ce qu'il y a dans les bcd_statut_.. ?
Et du coup savoir à quel niveau de granularité on associe des pictogrammes aux statuts .

Merci

[camillemonchicourt]

Je ne peux pas regarder en détail actuellement, mais clairement les statuts de protection c'est dans bdc... Et pas bib_taxref_statut qui est autre chose et pas utile pour ce qui est attendu.

[andriacap]

Ok donc a priori ça peut poser problème avec la mise à jour TaxRef

[camillemonchicourt]

Oui il faudrait voir ce qu'Amandine et Théo pensent de tout ça.
Pour le fait de pouvoir gérer les pictos au niveau de l'interface, peut-être à faire directement dans la refonte v2 en Flask-admin qui est déjà bien avancée.

[edelclaux]

Informations extraites d'un message de Camille traitant de plusieurs sujets:

[...] Et pour le picto principal, on s'appuiera surement sur un des groupes INPN (2 comme GN-atlas ?) car ils sont pas mal pour rapidement comprendre de quel type d'espèce il s'agit.

[andriacap]

Pour le déplacement d'issues, pour éviter de le faire manuellement avec une nouvelle issue et des copié coller , j'ai tenté via le github CLI mais je n'ai pas les droits (@Pierre-Narcisi , @jacquesfize ) : gh issue transfer 3130 --repo PnX-SI/GeoNature PnX-SI/TaxHub GraphQL: andriacap does not have the correct permissions to execute TransferIssue(transferIssue) Du coup si quelqu'un à les droits je veux bien qu'il s'en charge en CLI .

Ok donc tu me confirmes ce qui serait envisagé :

* Ajout des champs "picto" dans chacune des deux tables (à condition qu'elle ne soit pas repeuplé) ?

* Des développements devront être réalisés pour gérer la gestion de ces picto via l'interface taxhub ?

Pour la question de savoir si ces tables sont repeuplées, j'imagine qu' @amandine-sahl saura nous répondre assez facilement.

Merci

Salut,
je me permet de relancer ce ticket , concernant le déplacement de l'issue sur le dépot Github . Est ce qu'il serait possible de votre coté de faire ce déplacement de ticket avec le cli de github car je n'ai pas les droits (@Pierre-Narcisi , @jacquesfize ) .
La commande est la suivante gh issue transfer 3130 --repo PnX-SI/GeoNature PnX-SI/TaxHub
Merci d'avance

[camillemonchicourt]

Salut, je me permet de relancer ce ticket , concernant le déplacement de l'issue sur le dépot Github . Est ce qu'il serait possible de votre coté de faire ce déplacement de ticket avec le cli de github car je n'ai pas les droits (@Pierre-Narcisi , @jacquesfize ) . La commande est la suivante gh issue transfer 3130 --repo PnX-SI/GeoNature PnX-SI/TaxHub Merci d'avance

OK je m'en charge avec le bouton TRANFER ISSUE présent directement sur Github :