Contrôle cohérence sur les floatingobject (Pascal)

Contrôles sur activité 13 (Opération sur FOB)

• VesselActivity = 13 + absence d'objet flottant (ps_logbook.floatingobject) --> erreur

• VesselActivity = 13 + Opération objet = 'Déploiement' + présence du SO '20 - FOB' --> erreur (l'objet n'était pas présent dans l'environnement du bateau à son arrivée)

• VesselActivity = 13 + Opération objet IN {'Visite', 'Pêche', 'Renforcement', 'Retrait', 'Remplacement', 'Destruction', 'Coulage'} + absence de SO '20 - FOB' --> erreur [pertinent ?]

• VesselActivity = '13 - Opération sur FOB' -> si aucune balise (ps_logbook.TransmittingBuoy) -> warning

Contrôles sur activité 6 (Pêche)

• VesselActivity = 6 + schooltype = BO + absence d'au moins 1 SO avec schoolType = BO --> erreur Déjà implémenté dans AkadoR car fait partie des contrôles historiques

• VesselActivity = 6 + présence SO = '20 - FOB' + absence de floatingObject --> erreur

• VesselActivity = 6 + présence de floatingObject + absence SO = '20 - FOB' --> erreur

• VesselActivity = 6 + présence floattingObject + si opération objet (ps_common.ObjectOperation) = '1 - Déploiement' --> erreur (les déploiements doivent être dissociés des coups de pêche)

Contrôles sur balises

• Les balises (ps_logbook.TransmittingBuoy) doivent avoir (erreur ferme) :

  • une opération sur balise (ps_logbook.TransmittingBuoy.transmittingbuoyoperation NOT NULL) inutile car assuré par la base
  • un type de balise (ps_logbook.TransmittingBuoy.transmittingbuoytype NOT NULL) inutile car assuré par la base

• Les balises devraient avoir (warning) :

  • un propriétaire (ps_logbook.TransmittingBuoy.transmittingbuoyownership NOT NULL)
  • un ID (ps_logbook.TransmittingBuoy.code NOT NULL)

• Les ID balise (ps_logbook.TransmittingBuoy.code) ne doivent pas commencer par des 0. Par exemple '0004576' -> erreur

• Les ID balise (ps_logbook.TransmittingBuoy.code) doivent avoir un format spécifique (nombre de digits) selon leur fabriquant (ps_logbook.transmittingbuoy.transmittingbuoytype). Ce contrôle n'est pas indispensable car il est assuré par l'appli. Toutefois AkadoR pourrait :

  • Si ID (ps_logbook.TransmittingBuoy.code) NOT NULL
  • réappliquer l'expression régulière stockées dans la base (ps_common.transmittingBuoyType.regex). Si mismatch --> erreur

• Sur une opération 'Récupération et pose d'une nouvelle balise' (= 1 enregistrement transmittingBuoy 'Recupération + 1 Enregistrmeent 'Mise à l'eau' sous le même enregistrement floatingObject), si les deux champs code ont le strict même identifiant balise --> erreur (cf #29)

• Si deux objets déclarés à moins de 1h d'intervale ont un id balise commun --> erreur

• • Si deux objets déclarés à moins de 12h d'intervale ont un id balise commun --> warning

Divers Objets

• Les objets flottant (ps_logbook.floatingobject) doivent avoir une opération sur objet != NULL inutile car contrainte assurée par la base

Vérifications sur les matériaux d'objets (ps_common.objectmaterial) (à enrichir)

• Les objets (ps_logbook.floatingobjectpart) ne doivent pas être des FAD ancré ( = absence du code '1-2 - AFAD' dans ps_common.objectmaterial) --> sinon erreur

• Si opération sur objet = 'Modification/Renforcement' :

  • le nombre d'éléments (floattingObjectPart) booléens "When leaving" doit être supérieur au nombre d'éléments booléens "When arriving" -> sinon warning
  • les éléments de type booléen présents à l'arrivée doivent aussi paraître dans l'état 'au départ' (champ floatingObject.whenArriving=TRUE AND floatingObject.whenLeaving=TRUE)

• Si opération objet = 'Déploiement', vérifier que parmi les matériaux (floatingObjectPart) il y a au moins un élément de la hiérarchie DFAD (branche 1-1) dans 'When leaving' --> sinon erreur

• Si opération objet = 'Déploiement', vérifier que parmi les matériaux (floatingObjectPart) il y a au moins deux dimensions saisies -> sinon warning. Au moins deux parmi :

  • 1-1-1-1-6 Length (raft)
  • 1-1-1-1-7 Width (raft)
  • 1-1-1-1-8 Height (raft)
  • 1-1-1-1-9 Depth (raft)
  • 1-1-2-10 Length (submerged part)
  • 1-1-2-11 Width (submerged part)
  • 1-1-2-12 Height (submerged part)
  • 1-1-2-13 Depth (submerged part)

L'idée sous-jacente de ce contrôle est la suivante :

• si on déploie, alors on déploie nécessairement un DFAD (objet artificiel) pour lesquels la CTOI exige les dimensions
• mais les équipages ne remplissent pas toujours, donc on ne peut pas en faire une erreur dure. Warning parait plus raisonnable.
• parfois il y a longueur, parfois longueur/largeur/profondeur, parfois rien
• de plus en Atlantique j'avoue ne pas savoir si l'ICCAT demande ces détails alors je me suis dit que 2 dimensions à tester ce serait plus pertinent que 1, et plus réaliste que 3... choix arbitraire, mais que trouver de mieux ?

A passer en revue, revue encore non faite (Pascal)

• Si une vesselActivity 13 avec opération objet 'Visite' précède de moins de 10 minutes une autre activité 13, et que les 2 mentionnent le même id balise --> erreur (il y a de très fortes chances pour que ces 2 activités n'aient dû faire qu'une)

Autres contrôles pas forcément réalisables dans AkadoR

• Croisement entres les logbook (ps_logbook.TransmittingBuoy.code), les observateurs et la base balise pour vérifier la cohérence des codes/id balise --> nécessite accès à ces données. Or AkadoR sera utilisé par les prestaires, qui n'y ont pas accès