[GeoNature V2] Gestion des périodes et graphs phénologiques

[sig-pnrnm]

(suite à notre échange de mails) En prévision de la V2 qui intègre la notion de période pour les observations, avec date_debut et date_fin, les graphs phénologiques (par mois pour l'instant) ne seront plus opérationnels. Il faudra donc filtrer les données prises en compte pour le graph.

Proposition :

• si le graph est mensuel, on ne prend pas en compte les données dont la période est < 1 mois.
• si le graph est hebdomadaire (n'existe pas pour l'instant, mais qui sait), on ne prend pas en compte les données dont la période est < 1 semaine.

Voici ce que ça pourrait donner pour le script altas.sql, et le CREATE materialized view atlas.vm_mois (lien).

• on ajoute une CTE avant la requête : WITH observations_mois AS (SELECT * FROM atlas.vm_observations WHERE vm_observations.date_fin IS NULL OR (vm_observations.date_fin - vm_observations.date_debut) < 31)

• puis on remplace atlas.vm_observations par observations_mois dans le reste de la requête.

(une logique similaire pourra être utilisée pour les données surfaciques et les graphs d'altitudes)

Qu'en pensez-vous ?

[sig-pnrnm]

Et j'oubliais, pour les données conservées dans observations_mois, il faut calculer le mois de la "date moyenne" de la période. Je cherche la fonction SQL qui le permet et je la poste ici.

Edit : la voici :

SELECT date_part('month'::text, date_debut + (date_fin - date_debut)/2) as mois_moyen;

[camillemonchicourt]

Si on veut faire ça côté ATLAS, ça veut dire qu'il ne faut plus lui envoyer qu'une date mais date_debut et date_fin. J'avais pensé faire les traitements en amont, quitte à ne pas renvoyer les données qui ne sont pas précises. Derrière il faut gérer le slider aussi, et si une obs court sur 2 années ? Et quelle date on affichera quand on cliquera sur une observation ?

[sig-pnrnm]

Du coup on pourrait créer "en dur" côté GeoNature (via trigger) les champs date_moyen (date) et date_duree (nb jours).

SELECT  date_debut + (date date_fin - date_debut)/2 as date_moyen,
    date_fin - date_debut as date_duree ;

Et les filtres pourraient se baser sur une combinaison des deux.

Derrière il faut gérer le slider aussi, et si une obs court sur 2 années ?

possible de l'exclure (si date_duree > 365) ou de prendre date_moyen dans le cas contraire

Et quelle date on affichera quand on cliquera sur une observation ?

date_moyen sauf si date_duree > 365

Heureusement, et à part pour les données historiques, ce genre de cas sera certainement marginal. Certes, il faut le prévoir, mais la majorité des données ne seront pas filtrées.

[sig-pnrnm]

Et quelle date on affichera quand on cliquera sur une observation ?

On pourrait créer dynamiquement la valeur à afficher ? Moi je le ferais en SQL, mais je suppose que vous feriez plutôt ça en python. En SQL ça donnerait quelque chose ça : SELECT CASE WHEN date_fin NOT NULL AND date_fin <> date_debut THEN 'entre ' || to_char(date_debut, 'dd/mm/yyyy') || ' et ' || to_char(date_fin, 'dd/mm/yyyy') ELSE to_char(date_debut, 'dd/mm/yyyy') END as date_affichee

[DonovanMaillard]

Héhé, bonne question...

Bon déjà je serais pas d'accord avec un seuil à 365j (au délà d'un mois la date est floue, la donnée n'apparait pas).

Pour l'affichage..... je pense qu'il ne faut pas afficher de données transformées, donc pas de calcul de moyenne. Soit on indique les deux dates si date_min≠date_max, soit on indique "période" ou je ne sais quoi au lieu de la date...