[BACKEND] Amélioration de l'identification des bateaux

[rv2931]

Nous avons identifié plusieurs cas qui restent à formaliser ici de souci de d'identification d'un bateau
Un bateau peut être identifié par son numéro MMSI, son numéro IMO, son nom (Name), son indicatif radio (Callsign)
Question: Est-ce que l'immatriculation correspond à l'une des information précédente ou c'est une information administrative (et physique puisque peinte sur le bateau) supplémentaire mais difficile à connaître ?
Nous pouvons déjà lister ces quelques cas problématiques:

• Spoofing => deux bateaux ont le même MMSI sur le globe. Le résultat est une succession de positions aberrantes (cas de la péniche à Orléans) pour une même trajectoire et même MMSI
• Changement/échange de mmsi mais pas de nom/imo. Cela peut arriver lorsqu'un bateau change de propriétaire/armateur. Cela a pour conséquence notamment que l'ancien bateau n'est plus surveillé puisqu'aujourd'hui nous nous basons exclusivement sur le mmsi qui a changé et qui ne fait donc plus parti de la liste des mmsi surveillés
• Information partiellement erronée pendant une certaine période de quelques minutes à quelques jours. Le nom ou le callsign peuvent être mal orthographié ou correspondre à une autre information (immatriculation)

Il faudrait compléter cette liste et pour chaque cas préciser quel comportement de l'application serait souhaitable
Par exemple, on peut dire que ce qui nous intéresse c'est de suivre le bateau physique, peu importe que ces informations d'identification électronique et/ou administrative changent. Dans ce cas il faudra tenir à jour une table de correspondance => et éventuellement y gérer aussi son historique
Comment gérer le cas du bateau qui change toutes ses données d'identification mais qu'on sait être le même bateau physique ? nouveau bateau ? nouvelle version du précédent ? (il est possible de traiter le deux cas selon la solution mise en place)

Sinon consolider le besoin

Spire informe sur certains aspects et problématiques d'identification des bateaux
Cf message de @marthevienne "Handling vessel MMSI"

Originally posted by @marthevienne in #330

Proposition technique

Pour la partie des problématique d'identification, je préconise de mettre en place une table de "mapping" ou "transcodage" qui d'un côté liste les différents cas d'information complètes ou incomplètes rencontrés et de l'autre côté renvoie vers l'identifiant unique de la table de dimension des bateaux.

A ce stade on peut identifier deux cas:

• soit nous avons une solution permettant d'identifier de manière quasi certaine le bateau avec les données reçues même partielles et déjà présentes dans la base et alors on ajoute ce nouveau cas on l'associe automatiquement au seul et unique bateau associé (moyennant une traçabilité tout de même, genre compte rendu périodique)
• soit on ne sait/peut pas identifier le bateau de manière quasi certaine et nous ajout ce nouveau cas à la table de "mapping" en laissant bien l'identification bateau à NULL et nous envoyons une notification mail à une liste de diffusion d'administrateur/ices de l'outil périodiquement pour venir associer ou non ce nouveau à un bateau clairement identifier manuellement. Ce mécanisme permet de continuer à tracer des bateaux et à postériori venir les associer à un bateau qui nous intéressait et qui a changé d'information entre temps et donc rattacher ces informations au bateau de dim_vessel
  Cas pratique:
• un bateau change de mmsi MMSI2 mais pas de callsign CS1 et l'IMO est non valide (comme régulièrement). On ajoute la ligne avec mmsi + callsign mais on considère qu'on ne sait pas l'associer au bateau MMSI1+CS1+IMO1
  • on ajoute une ligne MMSI2+CS2 et un mapping à NULL
  • après un certain temps, un.e administrateur.ice confirme que c'est le même bateau qui a changé de MMSI et "mappe" donc MMSI2+CS1 => identifiant unique du bateau ayant MMSI1+CS1+IMO1
  • les données récoltée pendant la période sur le MMSI2+CS1 peuvent donc maintenant être associées au bateau MMIS1+CS1+IMO1

A voir si il n'y a pas des cas plus problématiques et la fréquence d'occurrence de ce genre d'évènement

[rv2931]

Ensuite pour exploiter l'information, je pense qu'il faudrait prévoir une colonne vessel_id_source et vessel_id_mapped (foreign key nullable sur dim_vessel) au niveau des excursions et des metrics en plus de la table de mapping
En effet pour éviter des jointures à tout va avec la table de mapping et les requêtes complexes et pertes de perfos liées il vaut mieux propager l'information sur les excursions et les metrics, même pourquoi pas sur les segments et positions puisqu'elles sont censées être liée au même vessel_id_source encore une fois pour éviter quelques jointures vessel, excursions, segments, positions parfois inutiles