Salut Jean, Le 12/12/2019 à 10:56, Jean Couteau a écrit :
Salut, j'étais en salon tout le début de semaine, je rattrape un peu ;)
Pas de souci, j'étais aussi en réunion une bonne partie de la semaine. Mes réponses dans le message
On Fri, 6 Dec 2019 10:59:40 +0100 Mathieu DORAY <Mathieu.Doray@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 ?
oui
* 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
Finalement, pas besoin d'ajouter les champs : - "frequency" : il est déjà défini dans "acousticInstrument" - "transceiverPower" : redondant avec "transceiverAcquisitionPower" (cf. ta dernière question dans ce message)
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
non, après réflexion, on peut le garder
* protected float frequency; <- à supprimer non, après réflexion, on peut le garder
* protected float transceiverPower; <- à supprimer oui
* protected float transmitPulseLength; <-pulseLength à supprimer ? oui * 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 ? Oui tu as raison, on pourrait ne le mettre que dans l'export xml CIEM
ç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 ?
Pardon, j'avais oublié que chaque "acousticInstrument" avait une fréquence propre. Si on a un dataAcquisition par acousticInstrument, c'est bon, pas besoin de changer. Peut on faire un point téléphonique en début de semaine prochaine? Merci et A+ Mathieu
Jean _______________________________________________ Echobase-devel mailing list Echobase-devel@list.forge.codelutin.com http://list.forge.codelutin.com/cgi-bin/mailman/listinfo/echobase-devel
-- Mathieu Doray, PhD Ifremer Unité Ecologie et Modèles pour l'Halieutique rue de l'Ile d'Yeu B.P. 21105 44311 Nantes Cedex 03 mathieu.doray@ifremer.fr Tel./Phone: 02 40 37 41 65 / International: 332 40 37 41 65 Fax : 02.40.37.40.01 / International: 332 40 37 40 01 CV / resume: http://annuaire.ifremer.fr/cv/17093/