search

ecotaxa / ecotaxa_front

Front end of the EcoTaxa application
Other
6 stars 6 forks source link

Recalcul des features erronées issues de Zooprocess #417

Open picheral opened 4 years ago

picheral commented 4 years ago

Certaines features ont été calculées avec un code erronée et le sont maintenant de façon correcte. Il faudrait homogénéiser sans réimporter tous les TSV recalculés.

grololo06 commented 4 years ago

Ca me semble une bonne idée. Quel jeu d'images est erroné?

jiho commented 4 years ago

Une erreur connue est sur l'ESD qui devrait être calculé comme

ESD = 2 * sqrt(area / pi)

On pourrait recalculer cela pour tous les projets qui ont des champs area et esd. Quand c'est déjà juste on retrouvera la même valeur, quand c'est faux, ça corrigera. Ça ira plus vite que d'identifier précisément quels projets sont erronés.

Il faut le faire par projet cela dit parce que les champs area et esd ne sont pas toujours à la même position.

NB: le pb vient du fait que Java donc ZooProcess ne connait pas ^0.5 pour faire sqrt.

@picheral : d'autres champs dérivés impactés par ce pb?

picheral commented 4 years ago

Pour les instruments Zooscan, UVP5, FlowCam et Generic :

esd = 2*(sqrt(area/PI));
centroids = sqrt(pow(xm-x,2)+ pow(ym-y,2));
perimareaexc = perim/(sqrt(area_exc));
feretareaexc = feret/(sqrt(area_exc));
circexc = (4*PI*area_exc)/(pow(perim,2));
cdexc = (1/(sqrt(area_exc))) * sqrt(pow(xm-x,2)+pow(ym-y,2));
grololo06 commented 4 years ago

Considérant qu'on stocke les flottants en double précision, ils prennent 8 octets chacun, donc pour 100M de features on tape dans le giga octets pour chaque colonne. A considérer: stocker les formules et les données de départ au lieu de résultats.

picheral commented 4 years ago

Compliqué à mettre en oeuvre car il faudrait alors un traitement spécifique pour les données issues de Zooprocess seulement ! Je propose de refaire le calcul comme "demandé" et donc sans réduire la taille de la base. Il y a pour moi d'autres "niches" pour diminuer les tailles des bases.

grololo06 commented 4 years ago

Ma foi. Issue à finir de spécifier.

jiho commented 4 years ago

Il s'agit d'une modif one shot, à faire directement sur la base.

  1. on liste les projets traités par zooprocess à partir de leur titre contenant zooscan, flowcam, uvp5 et generic
  2. pour chacun, on détecte l'existence et la localisation des variables nécessaires au calcul dans mappingobj: area, area_exc, perim, xm, ym, feret
  3. de même, on détecte l'existence et la localisation des 6 features dérivées via le mappingobj
  4. on recalcule les 6 features derivées et on les écrit dans la base. Quand c'était faux, ça corrige, quand c'était OK, ça ne change rien.

@picheral : ça laisse quand même un pb: si les gens réimportent des .tsv à partir d'anciens projets générés avec une version de zooprocess contenant encore l'erreur, ça va écraser cette correction. Je ne sais pas combien de temps la version problématique de zooprocess a été diffusée et à quel point c'est prévalent.

picheral commented 4 years ago

Les utilisateurs ne font malheureusement pas les MAJ de Zooprocess. Cela risque donc de perdurer. Il faut donc prévoir de les recalculer à l'import ????

jiho commented 4 years ago

Les utilisateurs ne font malheureusement pas les MAJ de Zooprocess. Cela risque donc de perdurer. Il faut donc prévoir de les recalculer à l'import ????

Dans ce cas, je suis avec @grololo06 : il ne faut même pas les entrer dans la base mais les définir dynamiquement comme un calcul à partir des features existantes. Ça signifie implémenter une fonction qui permet la spécification de fonctions de transformation à partir des champs dans le mapping. Je pense que cela doit être une fonction au niveau projet, copiable d'un projet à l'autre pour éviter d'avoir à taper n fois la même chose.

Mais j'ai des doutes sur le rapport coût (importants!) / bénéfice :

Donc je serai pour:

  1. faire la correction une fois; garder le code dans un coin pour éventuellement la relancer à la main de temps en temps mais ne pas en faire une feature d'EcoTaxa
  2. hardcoder le calcul de features pertinentes écologiquement (#455) et laisser le reste au choix/à la responsabilité de l'utilisateur.
picheral commented 4 years ago

OK

grololo06 commented 3 years ago

Même si elles sont fausses, les data ne nous appartiennent pas donc il est éthiquement impossible de modifier sous les pieds des utilisateurs des données. On peut offrir une fonction aux managers de projets (similaire à Fix Category Issues). A discuter.

picheral commented 3 years ago

Je vote pour 👍

Il faudrait le faire une fois au moins sur une liste de projest sélectionnés (A discuter un jeudi).

grololo06 commented 3 years ago

Pour des questions de volumes de données, il faudra rajouter la fonction dans le back-end. Donc, ce sera un point d'entrée dans l'API, donc on pourra faire une boucle avec nos projets.