search

ARPA-SIMC / arkimaps

generazione mappe meteorologiche da modelli previsionali
GNU General Public License v2.0
0 stars 1 forks source link

differenziazione cumulate in caso di output a tiles #122

Closed brancomat closed 1 year ago

brancomat commented 2 years ago

Attualmente la tipologia decumulated data è differenziata dalla riga 437 di arkimapslib/inputs.py:

        if self.step != 24:
            cmd.append("--comp-full-steps")

Che sostanzialmente implica che la sola cumulata delle 24 è trascinata (0-24, 1-25, 2-26) mentre le altre vanno di intervallo in intervallo (ad es. per 6h: 0-6,6-12...). Questa cosa va bene per gli output standard, ma per gli output a tiles sarebbe preferibile che le cumulate fossero sempre trascinate. Se è fattibile (cioè se in quel pezzo di codice è possibile sapere se il flavour usato ha il campo tile) la cosa più semplice sarebbe rendere condizionale la cosa.

Nel caso non fosse possibile, c'è da pensare a come esternalizzare quella logica (aggiungere un parametro nel type: decumulate?)

brancomat commented 1 year ago

A seguito di confronto con salop la situazione pare andare bene così (cumulata trascinata solo a 24h) anche per l'output a tiles. In generale potrebbe fare comodo una configurabilità esterna di questo parametro, lascio aperta la issue.

brancomat commented 1 year ago

In maniera analoga a quanto suggerito qui: https://github.com/ARPA-SIMC/arkimaps/issues/112#issuecomment-1087656215

per risolvere la cosa si potrebbe esternalizzare il settaggio di ---comp-full-steps nel parametro args di Decumulate in modo che sia la ricetta a pilotare la cosa. A quel punto si potrebbero creare prodotti derivati separati (es.: cumulate a 3h a passi interi o orari) e fare riferimento direttamente a quelli nel contouring.

spanezz commented 1 year ago

Ho messo possibile specificare comp_full_steps nella definizione degli input, come booleano, con default a step != 24.

Suesta è una minuzia ignorabile, però se trovate un nome migliore per questa feature possiamo usarlo invece di comp_full_steps, cosí non inchiavardiamo i parametri di vg6d_transform nell'API degli input, metti che un giorno decumuliamo in modo diverso.

brancomat commented 1 year ago

Ottimo! Temo comunque che il parametro di libsim abbia avuto la stessa difficoltà che stiamo avendo noi nel trovare un termine chiaro per la cosa. Faccio qualche ricerchina sul tema.