Actuellement, à chaque demande de traduction, on charge «from scratch» les ressources nécessaires à une traduction.

Même si cette opération n'est pas très coûteuse, cela semble quand même un peu excessif, une seule instance peut être chargée en mode paresseux avec réinitialisation si l'utilisateur change de langue.

On peut aussi appliquer le même principe pour le chargement de la locale qui est à chaque fois recalculée.

Le code 1335 est utilisé à deux endroits différents.

• une première fois dans le contrôle fr.ird.akado.avdth.sample.SuperSampleNumberConsistentInspector (contrôle qui a été supprimé dans le pilote ObServe)
• une seconde fois dans le contrôle fr.ird.akado.avdth.sample.DistributionInspector (contrôle conservé dans ObServe)

Je me permets alors de modifier le premier contrôle en lui assignant un nouveau code E1337, afin de pouvoir rendre le plus possible ISO-fonctionnel les contrôles des deux pilotes.

Akado alerte sur le temps de mer, et il indique la somme qu'il obtient en sommant les temps de mer des toutes les routes :

Il faudrait qu'il affiche, de la même manière, la somme calculée des temps de pêche.

Il se trouve que nous avons distinguer deux listes d'espèces (alors que dans le pilote AVDTH il n'y en avait qu'une seule...).

La première liste est utilisée dans le contrôle fr.ird.akado.observe.inspector.activity.WeightingSampleInspector et la seconde pour le résultat des échantillons.

Celle du premier

    public static boolean specieMustBeSampled(Species species) {
        return species.isYFT() // avdth code 1
                || species.isSKJ() // avdth code 2
                || species.isBET() // avdth code 3
                || species.isALB() // avdth code 4
                || species.isLTA() // avdth code 5
                || species.isFRI() // avdth code 6
                || species.isTUN() // avdth code 9
                || species.isTUS() // avdth code 40
                || species.isKAW() // avdth code 10
                || species.isLOT() // avdth code 11
                || species.isFRZ() // avdth code 18
                || species.isBLT() // avdth code 17
                ;
    }

La seconde

public static boolean specieMustBeSampled(Species species) {
        return species.isYFT()
                ||species.isSKJ()
                ||species.isBET()
                ||species.isALB()
                ||species.isLTA()
                ||species.isKAW()
                ||species.isTUN()
                ||species.isLOT()
                ;
    }

Je pense qu'on peut utiliser uniquement la première, mais j'ai besoin d'une confirmation.

Nous ne parvenons pas à exécuter l'installer sur nos postes Windows 10 Pro.

Java openJDK 17 x64.

Commande exécutée : java -jar akado-xxxxx-exe.jar

Rappel

Ce contrôle permet de vérifier que la date de début de la marée est le jour de première activité, mais aussi que la date de débarquement est la date de dernière activité.

Or dans le contrôle AVDTH existant, le même message est utilisé (code E1012) 👍

{0}> Marée[{1}] La date de départ saisie est {2} mais la date de la première activité est {3}.

Ce qui n'est pas correcte vis à vis du second contrôle :(

Solution

Faire de même que dans le nouveau contrôle ObServe et avoir deux messages distincts :

• E1012 vérifie la date de début de marée
• E1026 vérifie la date de débarquement

Je me permets alors de modifier ce contrôle, afin de pouvoir rendre le plus possible ISO-fonctionnel les contrôles des deux pilotes.

Existant

Dans avdth, nous avons ce message :

E1428> Activité[427 30/06/2023 30/06/2023 0] Il y a des positions VMS pour le 2022-01-21T00:01:00.372Z mais aucune activité.

À noter que la date de débarquement et celle de l'activité est celle du jour courant.

Nouveau message pour ObServe (repris sur l'ancien contrôle)

E1428> Activité[427 null 21/01/2022 ??:?? 0] Il y a des positions VMS pour le 2022-01-21T00:01:00.201Z mais aucune activité.

La date d'activité est en fait celle de la position VMS en cours de test.

Ici pas de date de débarquement, puisqu'on ne la connaît pas.

Proposition

Puisque que nous n'avons ni date de débarquement, ni celle de l'activité et uniquement la position VMS (qui nous donne l'horodatage et celle-ci ainsi que le navire ciblé), je propose qu'on n'affiche plus du tout cette activité fictive.

E1428> Navire [427 - CORONA DEL MAR]  Il y a des positions VMS pour le 2022-01-21T00:01:00.201Z mais aucune activité.

Pour rappel, ce contrôle compare la somme des +10/-10 saisie dans les plans de cuve avec celle saisie dans l'échantillon.

Lors de la comparaison de ce contrôle entre ObServe et AVDTH je trouve un certain nombre de différences.

Dans le contrôle ObServe, le message d'erreur a été amélioré afin d'y afficher les quatre valeurs obtenues.

Dans le contrôle AVDTH, le message est un peu laconique :

{0}> Echantillon[{1}] Les valeurs de répartition -10/+10 sont incohérentes avec celle de la cuve {2}.

alors que dans le contrôle ObServe, ça semble plus parlant :

{0}> Echantillon[{1}] Les valeurs de répartition -10/+10 (valeurs : {2}/{3}) sont incohérentes avec celles de la cuve {4} (valeurs : {5}/{6}).

Afin d'y voir plus clair et de pouvoir bien comprendre où cela pêche, je vais alors reprendre ce nouveau message.

Je me permets alors de modifier ce contrôle, afin de pouvoir rendre le plus possible ISO-fonctionnel les contrôles des deux pilotes.

Elle permet de lancer des traitements en ligne de commande, mais ne sera pas adapté pour le pilote ObServe, donc autant ne pas la garder.

• observe_model_min_version pour avoir la version minimim du modèle (9.2 par défaut)
• observe_model_max_version pour avoir la version maximum du modèle (9.2 par défaut)

Actuellement l'installeur réclame au moins java 16.

On fait comme sous Linux et utilisons .config

Cette classe n'est pas utilisée dans le projet

Actuellement on utilise des messages de la forme 12xx, or cela est déjà utilisé pour les activités.

Le passage en 14xx permettra de mieux les distinguer

Pour rappel ce contrôle vérifie que la ZEE de l'activité est cohérente avec la ZEE déduite de sa position.

Ici on contrôle les cohérences sur les pays des ZEE.

Or, lorsque la zone ZEE saisie est XIN (eaux internationales), ne plus afficher de message (Warning) car manifestement il n'existe pas de pays associé à celle-ci.

J'ai appliqué la même logique que celle du pilote ObServe.

Cela se justifie car le message représente une part importante des messages et qu'il est tout bonnement faux :(

En effet, le message est :

W1234> Activité[1266 27/12/2022 18/12/2022 3] La ZEE (XIN) semble incorrecte par rapport à la position déclarée (-23.816666666666663 4.383333333333334).

Or la ZEE est bien la bonne, c'est la comparaison des pays de la ZEE qui est faite.

J'en profite aussi dans le cadre de cette amélioration, pour ajouter dans le message la zone qui a été déduite depuis la position, ça semble bien plus pertinent (sinon comment l'utilisateur va pouvoir corriger...)

W1234> Activité[427 20/01/2022 19/01/2022 01:21 1] La ZEE déclarée (GMB) semble incorrecte par rapport à la position déclarée (-18.5501 13.0501), la ZEE déduite de la position est (SEN).

Le message est de la forme :

W1234> Activité[551 29/03/2022 24/02/2022 2] La ZEE (-9.633333333333335 0.8500000000000001) semble incorrecte par rapport à la position déclarée (XIN).

alors qu'il devrait être :

W1234> Activité[551 29/03/2022 24/02/2022 2] La ZEE (XIN) semble incorrecte par rapport à la position déclarée (-9.633333333333335 0.8500000000000001).

Cela permet d'avoir plus de logs, d'avoir des temps d'exécution, de ne parcourir que les résultats pertinents sur chaque tâches et d'améliorer la lisibilité du code.

La mise en place de cela avait pour but de paralléliser les différents tâches (contrôles marées, activities,...).

Or il se trouve que cela sous-entends de bien gérer la synchronisation des résultats (qui sont des ressources partagées entre les différentes tâches), ce qui n'est manifestement pas le cas, car après un premier essai cela fait crasher l'application.

Je supprime alors d'utilisation de ce code, pour juste exécuter les différentes tâches les unes après les autres.

J'en profite aussi pour rajouter quelques logs pour voir un peu ce qui se passe (car des fois c'est très long et je me demande si ça fonctionne...)

Amélioration des bornes maxi taille acceptées en LD1 et LF

Ce contrôle AVDTH ajoute deux fois le message.

Je me permets alors de modifier ce contrôle, afin de pouvoir rendre le plus possible ISO-fonctionnel les contrôles des deux pilotes.

Contexte

Dans le contrôle AVDTH on se basait sur les codes d'espèces.

On préfère utiliser dans ObServe les topiaId.

Dans le calcul du raising factor, on distingue deux listes d'espèces (une pour la france, une pour l'espagne)

Mapping français

private static final String[] FRENCH_TARGET_SPECIES = new String[]{"1", "2", "3", "4", "9", "11", "42"};

a été remplacé par

private static boolean isFrenchTargetSpecies(Species species) {
        return species.isYFT() // avdth code 1
                || species.isSKJ() // avdth code 2
                || species.isBET() // avdth code 3
                || species.isALB() // avdth code 4
                || species.isTUN() // avdth code 9
                || species.isLOT() // avdth code 11
                // FIXME We do not know avdth code 42 ...|| species.is???() // avdth code 42
                ;
    }

Le code 42 n'existe pas dans AVDTH et on ne sait pas quoi en faire...

Mapping espagnol

 private static final String[] SPAIN_TARGET_SPECIES = new String[]{"1", "2", "3", "4", "5", "6", "9", "11", "12", "42", "43"};

a été remplacé par

private static boolean isSpainTargetSpecies(Species species) {
        return species.isYFT() // avdth code 1
                || species.isSKJ() // avdth code 2
                || species.isBET() // avdth code 3
                || species.isALB() // avdth code 4
                || species.isALB() // avdth code 5
                || species.isALB() // avdth code 6
                || species.isTUN() // avdth code 9
                || species.isLOT() // avdth code 11
                || species.isBLF() // avdth code 12
                // FIXME We do not know avdth code 42 ...|| species.is???() // avdth code 42
                || species.isRAV() // avdth code 43 FIXME Make sure this exists, did not find it in IRD referential
                ;
    }

Idem pour le code 42 mais aussi le 43 (dans AVDTH c'est du RAV). Je le trouve dans une de mes bases mais pas sur un référentiel de l'IRD. Il faut voir quoi faire.

Cette librairie (semi-obsolète) tire des dépendances encore plus obsolètes (:() et n'est utilisée que pour supprimer l'extension dans le nom d'un fichier.

On peut alors largement s'en passer.

Sur les activités du 19 au 25/06, le bateau est à Port Gentil (port du Gabon). La position renseignée est telle que le bateau est vu comme légèrement à terre. Donc Hord de toute ZEE :