creazione di uno stile di sistema "simc" con alcuni prodotti a variabile singola

[brancomat]

un primo test potrebbe essere creare i json per temperatura a 2 metri, altezza dello zero termico, total cloud cover (contouring recuperabili da: https://github.com/ARPA-SIMC/magics-maps/blob/master/json_fields/mm_fields.json) con i criteri di match a cui accennavano nella issue skinnywms (ecmwf/skinnywms#37), piazzarle in una dir tipo /usr/local/share/magics/style/simc e vedere se si riesce a farle saltare fuori con uno script python che usi palette predefinite.

[brancomat]

Query per recuperare i dati:

T2M:
arki-query --data 'reftime:=today 0:00;product:GRIB1,80,2,11;level:GRIB1,105,2' http://arkiope.metarpa:8090/dataset/cosmo_5M_ita > t2m_cosmo.grib
arki-query --data 'reftime:=today 0:00;product:GRIB1,98,128,167;level:GRIB1,1' http://arkiope.metarpa:8090/dataset/ifs_ita010 > t2m_ifs.grib

Total cloud cover:
arki-query --data 'reftime:=today 0:00;product:GRIB1,80,2,71' http://arkiope.metarpa:8090/dataset/cosmo_5M_ita > tcc_cosmo.grib
arki-query --data 'reftime:=today 0:00;product:GRIB1,98,128,164' http://arkiope.metarpa:8090/dataset/ifs_ita010 > tcc_ifs.grib

Altezza zero termico:
arki-query --data 'reftime:=today 0:00;product:GRIB1,80,201,84;level:GRIB1,4' http://arkiope.metarpa:8090/dataset/cosmo_5M_ita > hzero_cosmo.grib

caveat: ci sono alcune modifiche ai dati da fare pre-plot:

• le temperature Kelvin vanno passate a Celsius
• le precipitazioni in metri vanno passate a millimetri
• la cloud cover da percentuale (cosmo) e 0-1 (ecmwf) va convertita ad ottale

Nei precedenti approcci la cosa era stata affrontata in questo modo:
https://github.com/ARPA-SIMC/magics-maps/blob/master/json_fields/plot_grib.py#L63

Però visto che l'analisi completa dei prodotti è ancora in corso e al momento si mirava a capire come strutturare i json aggiuntivi possiamo anche partire dalla t2m e dalla sola conversione °K/°C

[dcesari]

Non so se può servire, la butto lì:

grib_set -w indicatorOfParameter=11 -s offsetValuesBy=-273.15 t.grib tc.grib
grib_set -w indicatorOfParameter=29 -s scaleValuesBy=0.08 clc.grib clc8.grib

[spanezz]

Ho aggiunto uno script test-render che renderizza contouring con gli stili json dell'ecmwf. Prende come parametri dei file .grib e per ogni .grib fa un .png renderizzato. Per esempio:

./arkimaps < test.arkimet
./test-render workdir/+2/t-*.grib

Ho poi visto che contour_automatic_setting="ecmwf" deve sempre avere il valore ecmwf per attivare il matching automatico. È possibile fare rendering con settaggi diversi settando MAGICS_STYLE_PATH:

cp -a /usr/share/magics/styles/ecmwf prova
MAGICS_STYLE_PATH=`pwd`/prova ./test-render workdir/+2/t-*.grib

[brancomat]

Ok, alcuni pareri a caldo:
lo script di test-render mi pare ok, quindi se capisco bene per i contouring custom sostanzialmente esistono tre strade:

• creare una dir di json alternativa a /usr/share/magics/styles/ecmwf e usare la variabile MAGICS_STYLE_PATH
• integrare le sole palette in quelle di sistema e usare la variabile contour_shade_palette_name
• definire per intero tutto in mcont, old style

e test-render va nella prima direzione, che è quella che tutto sommato preferisco, quindi va benissimo.

Mi è meno chiara (o meglio: sicuramente me l'hai già spiegata e me la sono scordata) la scelta di usare la query --inline da dare in pasto ad arkimaps (in alternativa a: un grib secco senza metadati, che potrebbe essere un approccio più generalista).

[spanezz]

L'uso di arki-query --inline è per simulare il lavoro come postprocessatore di arkimet, che ho capito fosse uno dei requisiti: arkimet ai postprocessatori non passa solo i dati grib secchi, ma ogni elemento viene mandato preceduto dai suoi metadati.

Se rimane il requisito di lavorare come postprocessatore arkimet, dovremmo essere anche piú efficienti in fase di smistamento, perché avendo i metadati arkimet a disposizione, eviteremmo di parsare i grib una volta per capire cosa sono e metterli nel posto giusto, e una seconda poi per l'elaborazione.

Se invece serve che lo script lavori sia come postprocessatore che su grib secchi arbitrari, lo chiariamo tra i requisiti e posso poi rendere modulare la parte di smistamento iniziale, in modo che gestisca entrambi i casi.

[brancomat]

L'uso di arki-query --inline è per simulare il lavoro come postprocessatore di arkimet,

Mea culpa, sì, va benissimo, restiamo così. La possibilità di postprocessare grib secchi per ora la lasciamo nel cassetto (anche perché come diceva in altra sede @edigiacomo si simula agevolmente con un arki-query --inline "" $GRIB | arkimaps)

Riporto anche un ok di @edigiacomo all'impianto generale. L'idea adesso sarebbe di iniziare a creare da zero una dir da dare in pasto a MAGICS_STYLE_PATH iniziando a popolarla con le nostre regole di match e i nostri contouring.

[spanezz]

Per una cosa piú graduale, MAGICS_STYLE_PATH può prendere piú valori separati da :, col valore emcwf che punta a quello di sistema. Per esempio, questo funziona con una directory vuota:

mkdir prova
MAGICS_STYLE_PATH=`pwd`/prova:ecmwf ./test-render workdir/+1/*.grib

Propongo di muoverci con una nostra directori di stili vuota, tenendo cosí ECMWF come default, e cambiando le cose man mano che vediamo il bisogno di farlo.

[brancomat]

La perplessità che ho su questo approccio è che i prodotti (o meglio, alcuni prodotti) diventano dipendenti dagli stili di default di ECMWF, su cui non abbiamo controllo e per quanto sia una possibilità remota potrebbero variare con futuri aggiornamenti di Magics.

Avere una cartella isolata permetterebbe di avere il controllo completo degli stili.

[spanezz]

Ho aggiunto al repository una copia degli stili di magics e cambiato il codice per usarla per default. Non dovremmo piú dipendere dagli stili di magics, al netto di nuove versioni che potranno introdurre qualche tipo di cambio di formato alla directory degli stili.