differentiate satellite GRIB2 products

[brancomat]

Risolta la #264 si apre altro tema: al momento mi pare che non ci sia modo di distinguere in un filter di un dataset (o in una query arkimet) i diversi canali dei dati satellitari.

Al momento mi sembra che l'unica differenza fra i grib di canali diversi sia il parametro scaledValueOfCentralWaveNumber

Se questo è formalmente corretto (e mi pare di sì, in caso contrario tocca rimettere mano a https://github.com/ARPA-SIMC/meteosatlib/issues/2), per gestire la cosa la chiave suppongo dovrebbe finire rappresentata in qualche modo nel proddef o product dei GRIB2.

Se non sbaglio però è una chiave dipendente dal parametro "Number of contributing spectral bands (NB)" (https://apps.ecmwf.int/codes/grib/format/grib2/templates/4/32) quindi quando entrano in gioco più bande (ma non è il caso dei dati che gestiamo al momento) c'è da capire come gestire la cosa.

Al momento non mi vengono proposte intelligenti, ma ho tanta fiducia in @spanezz e @dcesari

(issue collegata: https://github.com/ARPA-SIMC/cosudo/issues/108)

[dcesari]

Non mi ero accorto che questa è un chiave "vettoriale" e quindi credo esuli dal data model dei nostri metadati. Non saprei come fare, se non sperare che abbiano una sola banda. Per far le cose fatte bene, credo dovremmo anche includere nei metadati satelliteSeries, satelliteNumber e instrumentType oltre che considerare lo scaleFactorOfCentralWaveNumber o in quest'ultimo caso rinormalizzare lo scaledValue con uno scaleFactor predefinito, es. 0 con il rischio di avere numeri molto grandi (usare intero a 64 bit?). Purtroppo non sono un gran esperto di dati satellitari, ma temo che i colleghi che sono esperti li abbiano visti raramente in grib.

P.S. il template 32 è per dati satellitari simulati da modelli (in teoria potremmo avere anche quelli), quello per i dati osservati è il 31, ma il succo non cambia.

[spanezz]

Se ho capito bene, un grib satellitare può avere un valore di lunghezza d'onda, o essere un prodotto calcolato a partire da piú lunghezze d'onda (tipo la riflettanza), per cui è sempre un prodotto unico, ma calcolato a partire da N lunghezze d'onda e un algoritmo.

Se stiamo parlando specificatamente di meteosat, il set di possibili lunghezze d'onda è specifico al SERVIRI e ogni lunghezza d'onda ha un nome descrittivo, per cui ci potremmo salvare in proddef il nome del canale ed eventualmente dei nomi di possibili elaborazioni come la riflettanza. In questo modo uno può chiedere, tipo, "IR_016" per la tal data/ora.

Se stiamo parlando di altri tipi di prodotti, a parte descrivere come sono rappresentati, chiedo di ragionare anche di quali esigenze ci sono in fase di estrazione: cioè, sia in base a quali parametri serve distinguere i GRIB perché non conflittino, che in base a quali parametri serva effettivamente tirarli fuori

[brancomat]

Per le nostre attuali esigenze il nome del canale in proddef sarebbe perfetto. La riflettanza non è un problema nel senso che per meteosatlib è un canale virtuale che ricava dinamicamente a partire dai canali disponibili (che siano in HRIT o GRIB2) e quindi non dovrebbe essere necessario archiviarla.

Sulle esigenze in fase di estrazione da quel che capisco io il tutto si limita a reftime e canale.

L'unico tema che resta scoperto è il satellite: l'informazione MSG4/MSG3... è ricavabile? Ignoro se serva in fase di estrazione (mi informo) ma temo serva per alcuni tipi di processing.

[spanezz]

Scartabellando dentro meteosatlib (gdal/grib.cc) vedo che Il tipo di satellite viene salvato nella chiave satelliteNumber, che dovreste riuscire a vedere con un grib_dump.

Quindi sí, anche l'informazione sul tipo di MSG è ricavabile dal GRIB, e possiamo infilarla nel proddef

[brancomat]

Provando a tirare le somme: da quel che riesco a capire un proddef con nome del canale + nome del satellite sarebbe sufficiente a coprire i nostri attuali usi, voterei per procedere in questo senso.

[spanezz]

Certo. Avete qualche GRIB di esempio?

[brancomat]

Certo. Avete qualche GRIB di esempio?

https://github.com/ARPA-SIMC/qc_sample_data/tree/master/satellite/grib

[spanezz]

Nota: se ci sono dataset con scansionati dati post #264, il valore proddef cambierà con l'aggiunta dei dati del meteosat

[spanezz]

Ho usato questi nomi per i satelliti:

METEOSAT_NAMES = {
    55: "MSG1",
    56: "MSG2",
    57: "MSG3",
    70: "MSG4",
}

E questi nomi per i canali:

METEOSAT_CHAN_NAMES = {
    6:   "VIS006",
    8:   "VIS008",
    16:  "IR016",
    39:  "IR039",
    62:  "WV062",
    73:  "WV073",
    87:  "IR087",
    97:  "IR907",
    108: "IR108",
    120: "IR120",
    134: "IR134",
    7:   "HRV",
}

Meteosatlib mette un underscore per avere un nome canale sempre di 3 lettere (tipo IR_016 e VIS007). Mi sembra superfluo nei metadati, ma se preferite possiamo mantenerlo.

Ho usato sat e ch come chiavi in proddef: proddef: GRIB(ch=WV062, sat=MSG4, tod=0). Se preferite possiamo usare c e s, o altre chiavi: non so come preferite che sia organizzato il namespace di proddef

[spanezz]

È in master. Lo lascio aperto come proposta implementativa in attesa di review

[brancomat]

Va benissimo, grazie.

L'unico dubbio è sul mantenere 1:1 gli stessi nomi dei canali (underscore incluso) perché è la denominazione con cui arrivano i file HRIT dal software di acquisizione e pare una convenzione de facto su vari software derivati che manipolano dati meteosat/seviri, ma quella è una modifica che posso fare io al volo su conf/scan/grib2.py una volta decisa la cosa internamente.