425/426 reprendre tâche clean_positions

[marthevienne]

J'ai utilisé position_update_timestamp dans spire_ais_data mais je ne vois pas de contre indication à utiliser spire_update_statement #402

Je ne me suis pas fiée au modèle d'archi qu'on aimerait pour la refacto. Je ne sais pas encore quel modèle a finalement été choisi.

[marthevienne]

Pour switcher d'un traitement basé sur created_at vers position_update_statement sans retraiter l'ensemble des données Spire :

Populate position_updates :

INSERT into position_updates 
SELECT ROW_NUMBER() OVER(ORDER BY foo.vessel_id ASC), * FROM (
  SELECT DISTINCT fe.vessel_id, 
  CASE 
	  WHEN sad.position_update_timestamp NOTNULL THEN sad.position_update_timestamp 
	  ELSE fe.arrival_at
  END, now() FROM fct_segment fs2 
  LEFT JOIN fct_excursion fe ON fs2.excursion_id = fe.id
  LEFT JOIN dim_vessel dv ON fe.vessel_id = dv.id 
  LEFT JOIN spire_ais_data sad ON sad.vessel_mmsi = dv.mmsi AND fs2.timestamp_end = sad.position_timestamp 
  WHERE last_vessel_segment
) AS foo

[marthevienne]

Je pense qu'en déliant created_at et updated_at et en reprécisant bien la définition déjà on peut arriver à optimiser certaines choses
Created_at: datetime effective à laquelle la ligne a été ajoutée à la table spire_ais_data
Updated_at: date de dernière mise à jour effective de la position
Si on prend bien position_update_timestamp comme date de mise à jour (enfin de ce que j'ai pu voir) on récupère bien la date effective de la vraie dernière position reçue par spire. Vu que c'est une date UTC qui vient de spire, on a pas non plus le problème de mauvais réglage de l'heure de l'horloge du bateau.
Le fait d'avoir un created_at et updated_at qui disent bien ce qu'ils veulent dire, cela permet pour la suite du traitement que sur un slot entre interval_start et interval_end, on peut éventuellement dans une première étape traiter toute nouvelle position issue de la requête API en se basant sur created_at par contre on peut déjà optimiser sur le fait que la suite du traitement ne traitera que les updated_at qui sont effectivement entre interval_start et interval_end
Ça élimine déjà toutes les requêtes API qui remontent des positions de bateaux qui n'ont pas été mise a jour depuis un certain temps côté spire (arrêt transpondeur, arrêt d'exploitation, ...). En rajoutant une première étape déjà de notre côté on peut aussi en éliminer toutes les positions qui n'ont pas évolué géographiquement depuis un certain temps (transpondeur ON mais bateau au mouillage) et corriger éventuellement ce updated_at a la véritable première position mise a jour avant arrêt bien qu'il répond toujours et que le created_at soit toujours a la date de requête

@rv2931, dans ta proposition, tu veux quand même ingérer toutes les données spire_ais_data et te baser sur spire_ais_data.position_update_timestamp pour soit, créer une nouvelle position dans vessel_positions, soit mettre à jour une position existante dans vessel_positions ?

Pour ta proposition de détecter le mouillage, le bateau bouge un tout petit peu ce qui fait que les coordonnées ne seront pas exactement les mêmes entre 2 positions successives. De plus, on arrive déjà très bien à détecter lorsqu'un navire est au mouillage en regardant sa vitesse et s'il est dans le périmètre d'un port.

[rv2931]

Je refais une passe et quelques vérifs sur le sujet et j'essaie d'expliquer plus clairement la problématique pour du traitement et retraitement par lot dans le passé (qu'on appelle backfill pour info)

[marthevienne]

Merci ! J'ai effectivement pas du tout géré le backfill dans cette PR... pas facile !

[marthevienne]

C'est moi qui ai utilisé position_update_timestamp, tu proposais spire_update_timestamp