- Echobase-devel - mailman.cloud.codelutin.com

Re: [Echobase-devel] EchoBase, le retour?
by Jean Couteau Viney Oct. 7, 2025

Oct. 7, 2025

Bonjour Mathieu, je ne t'ai pas répondu plus tôt, j'étais très pris la semaine dernière et je n'ai pas pu regarder les soucis d'import encore pour te faire une réponse. Peux-tu déjà me fournir les fichiers que je puisse regarder. Ensuite, pour l'export CIEM, quel est le soucis rencontré exactement ? Jean Le Wed, 1 Oct 2025 12:05:56 +0200, Mathieu DORAY <Mathieu.Doray(a)ifremer.fr> a écrit : > Bonjour Jean > > ça faisait longtemps, j'espère que tu vas bien. > > Je déterre un sujet mis en sommeil depuis lontemps : EchoBase. > > On a recommencé à bancariser nos données dans la base grâce à > l'obtention d'un CDD. ça avance bien globalement, mais on a des > soucis avec quelques fichiers d'import qui ne passent pas, et je ne > comprends vraiment pas pourquoi. > > Suite à cette première phase de bancarisation, l'objectif serait > d'exporter les données importées vers la base du CIEM. J'ai testé > l'export des données de EchoBase vers CIEM : ça ne fonctionne pas, > probablement car le format CIEM a évolué et il faudrait adapter > l'export EB. > > Il faudrait donc retoucher EchoBase pour régler les problèmes > identifiés et permettre (enfin) une utilisation opérationnelle de la > base. > > J'ai donc 2 questions : > > - Pourriez vous jeter un oeil sur les problèmes d'import rencontrés, > au moins pour déterminer si le pb vient d'EB ou des fichiers ? J'ai > bien scruté les fichiers et je ne vois pas d'erreur dedans. > > - Seriez vous dispos pour faire les adaptations dans EB ? > > Merci et bonne journée > > Mathieu >

1 0

Re: [Echobase-devel] Test echobase
by Jean Couteau Dec. 15, 2020

Dec. 15, 2020

Salut, On Mon, 7 Dec 2020 18:21:06 +0100 Mathieu Doray <mathieu.doray(a)ifremer.fr> wrote: > Peux tu me dire quels colonne doivent être dans le fichier d'import > d'echotypes et mettre à jour la doc? J'ai mis à jour la doc (pas encore déployé). Mais c'est bien la colonne sizeCategory qu'il te manquait. Par contre, une seule occurrence d'espèce par echotype. Donc une ligne par espèce par echotype. Cela dit, on ne stocke pas le sizeCategory donc je me demande bien pourquoi il est présent dans cet import (ça date de Tony et je n'ai pas d'info sur le pourquoi c'est là). Il faut peut-être l'enlever tout simplement. Jean

1 1

Test echobase
by Jean Couteau April 6, 2020

April 6, 2020

Bonjour Mathieu, pour faire suite à tes tests, je n'arrive pas à reproduire tes soucis, je commence à me poser des questions sur l'installation, car par example sur le #10768, on dirait que tu es en 4.0.15 ou en 4.1-SNAPSHOT. Le #10761 laisserai penser à une version 4.2-rc1. Pourrais-tu vérifier quelle version est installée ? Jean

1 0

Nouvelle version 4.2-rc1
by Jean Couteau Feb. 27, 2020

Feb. 27, 2020

Bonjour, nous avons produit une nouvelle version d'Echobase que vous trouverez ici : https://forge.codelutin.com/attachments/download/6064/echobase-ui-4.2-rc1-f… https://forge.codelutin.com/attachments/download/6063/echobase-ui-4.2-rc1-l… La procédure de mise à jour reste la même que d'habitude : http://echobase.codelutin.com/v/latest/update.html Bonne journée. Jean

1 0

Re: [Echobase-devel] Test nouvelle version EchoBase
by Jean Couteau Jan. 30, 2020

Jan. 30, 2020

On Wed, 29 Jan 2020 16:59:05 +0100 Mathieu DORAY <Mathieu.Doray(a)ifremer.fr> wrote: > Le 29/01/2020 à 16:37, Jean Couteau a écrit : > > Ok, sauf que j'ai une opération manquante du coup (U0386), présente > > dans le fichier biometry mais pas operations. > Peux tu enlever les données associées à U0386 pour le test? Oui, pour l'instant je teste sur 2015 pour pas me mélanger les pinceaux, mais quand je valide sur 2016, c'est ce que je ferai > >>> L'export des echotypes dans le Vocabulary échoue car le > >>> SpeciesCategory n'est pas un entier. Pour rappel, nous utilisons > >>> alors le champ id de l'echotype qui est une chaîne de caractère > >>> et, dans mes imports vaut : 1,5,G ou vide. Du coup, les valeurs G > >>> ou vide posent problème. On avait fait ça au mois d'avril, mais > >>> peut-être n'est-ce pas bon. > >> Le "SpeciesCategory" de l'export CIEM echotype correspond à la > >> colonne "id" de la table "echotype" d'EB. La valeur de cette > >> colonne "id" doit correspondre à la colonne "label" de la table > >> "VocabularyCIEM". Il faut exporter le "code" de la table > >> "VocabularyCIEM" correspondant comme "SpeciesCategory" de l'export > >> CIEM echotype. > > Ok, donc : > > - 0 -> AC_CatchCategory_1 > > - G -> AC_CatchCategory_2, > > > > mais chaîne vide ? et 5 ? > > je ne comprend pas pourquoi tu as des valeurs vides et 5. Les seules > valeurs possibles sont "0" et "G" (cf. fichier import echotypes en > PJ). Euh, tu as dû oublier la pièce jointe. Moi le fichier que j'ai est en PJ. LE tableau que tu m'a donné ne correspond pas complètement. Peux-tu me renvoyer le bon ? Sinon, le biotic est prêt à 1 détail près. Dans les fichiers d'import j'ai 3 Haul avec des weightAtLength a plus de 3 chiffres après la virgule, et du coup j'ai des erreurs d'arrondis (je tombe à 0.1 près au dessus ou en dessous, mais pas pile :( ). Est-ce normal d'avoir 6 ou 7 chiffres significatifs ? Jean

1 0

Re: [Echobase-devel] Test nouvelle version EchoBase
by Jean Couteau Jan. 29, 2020

Jan. 29, 2020

On Wed, 29 Jan 2020 11:49:41 +0100 Mathieu DORAY <Mathieu.Doray(a)ifremer.fr> wrote: > Le 28/01/2020 à 16:42, Jean Couteau a écrit : > > j'avance, tout est bien importé sauf les biometry pour Pelgas 2015. > > Pourrais-tu me les envoyer ? > > En PJ Super, ça s'importe bien ! > > Il faudrait mettre à jour la doc en ligne d'EB avec les nouveaux > champs des fichiers d'import. Le "sizeCategory" n'est par exemple pas > présent dans les colonnes requises de BiometrySample > <http://echobase.codelutin.com/v/latest/importData.html#biometrysample> Doc mise à jour chez moi > > Le "sizeCategory"de BiometrySample est égal à zéro pour toutes les > données PELGAS2016 Ok, sauf que j'ai une opération manquante du coup (U0386), présente dans le fichier biometry mais pas operations. > > Quand j'exporte les résultats, pour le D4, j'ai souvent du NA et > > donc pas de data à l'export -> erreur. Donc : > > 1. Est-ce normal de pas avoir de data ? > oui, ça veut dire qu'il n'y avait pas de poisson dans la couche > proche de la surface > > 2. Si pas de data, est-ce que je ne devrais pas ne pas exporter le > > sample ? > > 3. Si il faut quand même exporter, qu'est-ce que je mets ? > Il faudrait exporter quand même le sample en mettant la valeur à zéro > au lieu de NA Ok, nickel. > > L'export des echotypes dans le Vocabulary échoue car le > > SpeciesCategory n'est pas un entier. Pour rappel, nous utilisons > > alors le champ id de l'echotype qui est une chaîne de caractère et, > > dans mes imports vaut : 1,5,G ou vide. Du coup, les valeurs G ou > > vide posent problème. On avait fait ça au mois d'avril, mais > > peut-être n'est-ce pas bon. > > Le "SpeciesCategory" de l'export CIEM echotype correspond à la > colonne "id" de la table "echotype" d'EB. La valeur de cette colonne > "id" doit correspondre à la colonne "label" de la table > "VocabularyCIEM". Il faut exporter le "code" de la table > "VocabularyCIEM" correspondant comme "SpeciesCategory" de l'export > CIEM echotype. Ok, donc : - 0 -> AC_CatchCategory_1 - G -> AC_CatchCategory_2, mais chaîne vide ? et 5 ? Quelle est la valeur par défaut ? > > Il devrait y avoir des "0" et "G" dans la colonne "id" de la table > "echotype" d'EB. Je n'ai que des "0" dans ma version de la base pour > 2015, ce qui n'est pas normal. Effectivement, j'ai fait la modif,mais tu ne l'as pas encore Jean

1 0

Test nouvelle version EchoBase
by Jean Couteau Jan. 28, 2020

Jan. 28, 2020

Salut, j'avance, tout est bien importé sauf les biometry pour Pelgas 2015. Pourrais-tu me les envoyer ? Sinon, je teste l'export Acoustic Atlantos et j'identifie plusieurs soucis : Quand j'exporte les résultats, pour le D4, j'ai souvent du NA et donc pas de data à l'export -> erreur. Donc : 1. Est-ce normal de pas avoir de data ? 2. Si pas de data, est-ce que je ne devrais pas ne pas exporter le sample ? 3. Si il faut quand même exporter, qu'est-ce que je mets ? L'export des echotypes dans le Vocabulary échoue car le SpeciesCategory n'est pas un entier. Pour rappel, nous utilisons alors le champ id de l'echotype qui est une chaîne de caractère et, dans mes imports vaut : 1,5,G ou vide. Du coup, les valeurs G ou vide posent problème. On avait fait ça au mois d'avril, mais peut-être n'est-ce pas bon. Jean

1 0

Test import des résultats
by Jean Couteau Dec. 19, 2019

Dec. 19, 2019

Mathieu, j'ai refait le point sur les imports de résultat cellule ESDU. Voilà ce qui pose problème : ESDU/échotype : 2015-05-27 17:15:37.0000_16 ESDU/échotype/catégorie d'espèce : 2015-05-27 16:28:24.0000_16 ESDU/échotype/catégorie d'espèce/taille : 2015-05-27 16:28:24.0000_16 ESDU/espèce/âge : 2015-05-27 16:28:24.0000_16 Si tu regénère un fichier de données accoustiques, n'oublie pas de rajouter les colonnes MOVIES_EILayer\sndset\acousticFrequency et MOVIES_EILayer\sndset\bandWidth qui sont désormais obligatoires. Jean

1 0

Re: [Echobase-devel] Questions Echobase
by Jean Couteau Dec. 16, 2019

Dec. 16, 2019

Salut, j'étais en salon tout le début de semaine, je rattrape un peu ;) On Fri, 6 Dec 2019 10:59:40 +0100 Mathieu DORAY <Mathieu.Doray(a)ifremer.fr> wrote: > Ta question m'a amené à revoir ce qui était sauvegardé dans > dataAcquisition et dataProcessing. Et j'ai trouvé du mélange entre > ces deux notions. > > dataAcquisition, c'est comment la donnée a été acquise, > dataProcessing, c'est comment elle a été analysée. > > "acousticFrequency", "bandwidth", "transceiverPower" et > "transmitPulseLength" sont des champs qui concernent l'acquisition > des donnée acoustiques. Or ils sont actuellement dans la table > "dataProcessing". Ils devraient en fait être en fait stockés dans la > table "dataAcquisition", et alimentés à partir des mêmes champs du > fichier d'import que précédemment. Ok, c'est tout le propos du ticket https://forge.codelutin.com/issues/9739 ;) : Pour résumer : DataAcquisition : * protected String acquisitionSoftwareVersion; * protected String loggedDataFormat; * protected String loggedDataDatatype; * protected float transceiverAcquisitionPulseLength; <- pulseLength ? * protected float transceiverAcquisitionGain; * protected float transceiverAcquisitionAbsorption; * protected String transceiverAcquisitionAbsorptionDescription; * protected float transducerAcquisitionBeamAngleAthwartship; * protected float transducerAcquisitionBeamAngleAlongship; * protected float transducerAcquisitionPsi; * protected float transceiverAcquisitionPower; * protected float transceiverAcquisitionSacorrection; * protected String echosounderSoundSpeed; * protected String soundSpeedCalculations; * protected String pingDutyCycle; * protected String softwareName; * protected String storedDataFormat; * protected String comments; * protected Collection<DataProcessing> dataProcessing; * protected AcousticInstrument acousticInstrument; * protected Transect transect; * protected Mooring mooring; * protected float bandWith; <- à créer * protected float frequency; <- à créer * protected float transceiverPower; <- à créer DataProcessing : * protected String processingTemplate; * protected String processingDescription; * protected String sounderConstant; * protected float digitThreshold; * protected int eIThresholdLow; * protected int eIThresholdHigh; * protected float transceiverProcessingGain; * protected String processingSoftwareVersion; * protected float transceiverProcessingSacorrection; * protected float transceiverProcessingAbsorption; * protected String transceiverProcessingAbsorptionDescription; * protected float transducerProcessingPsi; * protected float transducerProcessingBeamAngleAthwartship; * protected float transducerProcessingBeamAngleAlongship; * protected String acousticDensityUnit; * protected String echosounderSoundSpeed; * protected String soundSpeedCalculations; * protected String notes; * protected String id; * protected String softwareName; * protected float bandWith; <- à supprimer * protected float frequency; <- à supprimer * protected float transceiverPower; <- à supprimer * protected float transmitPulseLength; <-pulseLength à supprimer ? * protected String transceiverGainUnits; * protected String comments; * protected String channelId; * protected DataAcquisition dataAcquisition; * protected Collection<Cell> cell; > > A propos, j'ai vu que les champs "channelId", "transceiverGainUnits" > et "transmitPulseLength" n'avaient pas de valeur dans le > dataProcessing. Ok, c'est tout le propos du ticket https://forge.codelutin.com/issues/9739 ;) > "transceiverGainUnits" devrait avoir comme valeur par défault > "Decibel (dB)" Là je n'ai pas de colonne dans le fichier d'import, donc c'est fixe ? Du coup, pourquoi mettre un champ en base de données ? > ça résoudrait ton problème : si l'acousticFrequency varie, il faut > créer un dataAcquisition différent pour chaque "acousticFrequency", > auquel sera rattaché un dataProcessing (il y aura autant de > dataProcessing que d'acousticFrequency). Actuellement, on a un dataAcquisition par acousticInstrument, mais en fait, il faudrait un dataAcquisition par acousticInstrument et par acousticFrequency ? Jean

2 2

Questions Echobase
by Jean Couteau Dec. 5, 2019

Dec. 5, 2019

Mathieu, j'avance sur les tickets et j'avais plusieurs questions/précisions sur quelques tickets : - Ajouter un menu pour importer les calibrations : Je pensais rajouter le menu dans "Sélection du type d'import pour les voyages :", avec une entrée "Import des calibrations" où je vais choisir le fichier et valider, ou bien je le rajoute dans l'import des données acoustiques en rajoutant le fichier à cet endroit ? - Le "sampleDataType" des sampleData "numberSampled" devrait être "NumberAtLength" dans l'import des subsamples : Tu me confirmes que je dois mettre "NumberAtLength" pour tous les sampleDataType au lieu de "LTcm1" ou "LTcm0.5" ? A noter qu'on a : public static final String L_TCM_1 = "LTcm1"; public static final String LTCM0_5 = "LTcm0.5"; public static final String NUMBER_AT_LENGTH = "NumberAtLength"; je peux supprimer LTcm1 et LTcm0.5... - Champs non valués dans la table "DataProcessing" d'EB (et donc dans le chapitre "DataProcessing" de l'export acoustic) : bandwidth correspond bien à la colonne "MOVIES_EILayer\\sndset\\bandWidth" (actuellement ignorée) ? Si oui, faut-il la rendre obligatoire ? frequency correspond bien à la colonne "MOVIES_EILayer\\sndset\\acousticFrequency" (actuellement ignorée) ? Si oui, faut-il la rendre obligatoire ? Merci d'avance. Jean

3 3