Evolutions zones FAO

[VincentAntoine]

Deux éléments concernant les zones FAO nous amènent à revoir la gestion des zones FAO :

• pour le calcul des segments attribués aux contrôles : sur les navires n'ayant pas de JPE et donc pas de zone de capture déclarée, la zone FAO utilisée dans le calcul des segments est déterminée à partir de la position du contrôle. Le référenciel de zones FAO utilisé n'inclue pas les eaux intérieures (étang de Thau, autres étangs salés de Méditerranée...) et s'arrête parfois à quelques centaines de mètres au large du trait de côte, ce qui a pour conséquence que les contrôles réalisés dans ces zones n'ont pas de zone FAO et se retrouvent systématiquement et artificiellement hors segment.
• l'affichage des zones FAO dans Monitorfish présente toujours un important problème de performances malgré le passage en WMS [Zones FAO] Affichage des zones avec Geoserver #2923. La navigation n'est pas fluide du tout, ce qui est vraiment gênant pour une couche qui est pratiquement toujours affichée sur les postes. De plus l'affichage est moins joli qu'en WFS.

--> Pour le calcul des segments, la solution semble être d'utiliser une autre version du référenciel des zones FAO, également fourni par la FAO, dans lequel les zones ne s'arrêtent pas au trait de côte mais vont très largement dans les terres :

Référenciel de zones FAO utilisé actuellement s'arrêtant au trait de côte :

Référenciel de zones FAO alternatif :

Exemples de zones problématiques avec le référentiel qui s'arrête au trait de côte :

--> Pour le problème d'affichage, deux solutions :

• Soit on utilise également le référenciel alternatif ci-dessus, qui rentre loin dans les terres. Ne suivant pas le trait de côte, il est beaucoup plus léger et le problème de performances sera résolu directement sans rien changer d'autre dans l'appli. De plus ou pourra repasser en affichage WFS plutôt que WMS, ce qui était mieux esthétiquement. Ceci représente peu de travail (remplacement des données du référenciel par la version alternative).
• Soit on crée un deuxième référentiel dédié à l'affichage, différent du référentiel utilisé pour le calcul des segments de flotte, de sorte à garder à l'affichage une référentiel qui s'arrête au trait de côte. Dans ce cas
  • il faut retravailler le fonctionnement en WMS pour améliorer les performances et l'esthétique
  • il y a un travail plus conséquent puisqu'il faut créer deux versions du référentiel et utiliser une version différente pour l'affichage et pour le calcul. Travail en dev et en data à prévoir.
  • Au delà de la question esthétique - il est a priori plus "joli" d'avoir une zone qui suit la côte qu'une grosse patate qui rentre dans les terres - se pose la question de la justesse (les zones d'eaux intérieures doivent être considérées comme faisant partie des zones FAO donc on affiche quelque chose de faux sur ces zones actuellement) ainsi que la question de la cohérence entre ce qu'on affiche et ce qui est utilisé pour le calcul (l'attribution d'un segment à un contrôle réalisé dans une zone d'eaux intérieures dont on voit dans l'appli qu'elle n'est dans aucune zone FAO est incohérente).

@AdelineCelier @louptheron WDYT ?

[louptheron]

On passe sur un affichage par défaut des labels sur les zones FAOs.
Si ce n'est pas satisfaisant, on pourra afficher la zone FAO sur la zone visible à l'écran de l'utilisateur (viewport - cf. ici)