Identificazione dei parametri in input

[spanezz]

Ho aggiunto uno script arkimaps che per il momento prende in input dati da arkimet e li smista in una directory di lavoro, sotto una directory per step, con il cfVarName del prodotto.

Per eseguirlo, gli si può dare in stdin l'output di un arki-query --inline, che è lo stesso che viene passato ai postprocessatori:

arki-query --inline … > file.arkimet
arkimaps < file.arkimet

Apro l'issue per discutere del risultato

[spanezz]

Produce al momento un warning sui dati che non riesce a mappare che non mi è chiaro:

2020-05-20 16:49:07,167 WARNING Unrecognized data,
prod={'type': 'product', 'style': 'GRIB1', 'origin': 80, 'table': 2, 'product': 61},
lev={'type': 'level', 'style': 'GRIB1', 'level_type': 1}

cfVarName.def ha:

#Total Precipitation
'tp' = {
         table2Version = 3 ;
         indicatorOfParameter = 61 ;
         indicatorOfTypeOfLevel = 1 ;
         level = 0 ;
        }

e grib_dump sembra fatch match di quella regola, perché su quel GRIB mi dà cfVarName = tp, ma arkimet vede table=2, grib_dump ha table2Version = 2, ma quella regola ha table2Version = 3.

[spanezz]

In tutti i casi, possiamo mettere un set di regole hardcoded nel codice che fanno match prima di quelle caricate da eccodes, cosí possiamo fare workaround delle cose che non ci spieghiamo di eccodes, e gestire cose che non sono state aggiunte in cfVarName.def

[edigiacomo]

Produce al momento un warning sui dati che non riesce a mappare che non mi è chiaro:

Il tipo del livello è level_type, la chiave type si riferisce al tipo del metadato (cioè "level"), ho corretto nella commit 5279966.

Tuttavia, adesso lancia un KeyError perché il livello superficiale in Arkimet non ha la chiave l1. Nella direzione opposta (da GRIB a metadati Arkimet) la chiave l1 è impostata:

• https://github.com/ARPA-SIMC/arkimet/blob/master/conf/scan/grib1.py#L59-L61
• https://github.com/ARPA-SIMC/arkimet/blob/master/arki/types/level.cc#L118-L120

però non è presente nel metadato. Credo che il problema sia in GRIB1::getValType, che quando restituisce 0 (come nel caso del livello superficiale) fa ignorare l1 a tutti gli altri metodi (vedere i vari case nello stesso file).

Immagino che cambiare i valori dei metadati sarebbe un bagno di sangue quindi, partendo dal presupposto che non avremo una corrispondenza 1:1, direi che avere i parametri hardcoded è una buona soluzione.

e grib_dump sembra fatch match di quella regola, perché su quel GRIB mi dà cfVarName = tp, ma arkimet vede table=2, grib_dump ha table2Version = 2, ma quella regola ha table2Version = 3.

Nel mio cfVarName.def ci sono 3 definizioni di tp, che differiscono solo per table2Version

$ grep "'tp'" -A 5 /usr/share/eccodes/definitions/grib1/cfVarName.def 
'tp' = {
     table2Version = 3 ;
     indicatorOfParameter = 61 ;
     indicatorOfTypeOfLevel = 1 ;
     level = 0 ;
    }
--
'tp' = {
     table2Version = 2 ;
     indicatorOfParameter = 61 ;
     indicatorOfTypeOfLevel = 1 ;
     level = 0 ;
    }
--
'tp' = {
     table2Version = 1 ;
     indicatorOfParameter = 61 ;
     indicatorOfTypeOfLevel = 1 ;
     level = 0 ;$ rpm -qi 
}

$ rpm -qi eccodes | grep Version
Version     : 2.14.1

[spanezz]

Alcune voci hanno shortName settato ma non cfVarName. Ora uso shortName perché mi sembra piú completo, ma non conosco la differenza

[spanezz]

Chiudo questo issue, che ormai mi sembra obsoleto