search

ARPA-SIMC / dballe

Fast on-disk database for meteorological observed and forecast data.
Other
19 stars 6 forks source link

Intepretation of AIREP/AMDAR #251

Open dcesari opened 3 years ago

dcesari commented 3 years ago

Più una domanda filosofica che altro.

Notavo guardando il dump degli AIREP e compagnia che questi messaggi non vengono interpretati quando l'altezza del volo supera i 12707m che è il massimo per la variabile B07030 HEIGHT OF STATION GROUND ABOVE MEAN SEA LEVEL. Non è un problema pratico perché per l'assimilazione in Cosmo usiamo bufr2netcdf che non passa da dballe per l'interpretazione e al momento non mi pare ci siano altri usi di questi dati, ma mi viene il dubbio che non abbia senso, nell'interpretazione, codificare l'altezza di una cosa che è una stazione mobile in un contesto in cui l'altezza è già stata specificata, v. ad es. l'estratto dell'intepretazione di un messaggio registrato a 9750m:

005001 LATITUDE (HIGH ACCURACY)(DEGREE): 27.95000
           033007 PER CENT CONFIDENCE(%): 70
006001 LONGITUDE (HIGH ACCURACY)(DEGREE): -125.45000
           033007 PER CENT CONFIDENCE(%): 70
Level 102,9750000,-,-, tr 254,0,0
007030 HEIGHT OF STATION GROUND ABOVE MEAN SEA LEVEL (SEE NOTE 3)(M): 9750.0
           033007 PER CENT CONFIDENCE(%): 79
011001 WIND DIRECTION(DEGREE TRUE): 227
           033007 PER CENT CONFIDENCE(%): 70

Allego un esempio con 2 messaggi uno interpretabile e uno no. airep.zip

spanezz commented 3 years ago

Se ho capito bene la questione, l'altezza viene ripetuta esplicita anche se c'è già nel livello, per poter salvare l'attributo con intervallo di confidenza.

Al momento B07002 viene normalizzato in B07030 seguendo l'intenzione iniziale di avere in dballe dati uniformi.

Per me non è un problema ragionare di fare distinzioni piú nette tra stazioni fisse e mobili (seguendo la direazione di #150), e usare B07030 per uniformare l'altezza delle fisse e un'altra variabile (B07002?) per uniformare l'altezza delle mobili.

Il codice coinvolto al momento è https://github.com/ARPA-SIMC/dballe/blob/master/dballe/msg/wr_importers/flight.cc#L159

dcesari commented 3 years ago

Se ho capito bene la questione, l'altezza viene ripetuta esplicita anche se c'è già nel livello, per poter salvare l'attributo con intervallo di confidenza. Non sono certo che dipenda dalla presenza dell'attributo, ma non credo che questo cambi il senso della questione.

Sì, possiamo considerare di differenziare tra fisse e mobili, non so quali eventuali effetti collaterali potrebbero sorgere @pat1 cosa ne pensi? B07002 ha secondo me il problema di avere la precisione di 10m, c'è in alternativa la B07007 (non so la differenza di sfumatura tra HEIGHT e ALTITUDE) che ha la precisione del metro (però B07030 ha il decimetro) ed arriva comunque sufficientemente in alto per gli aerei. Alternativamente, non sarebbe possibile usare i modificatori C per forzare un maggior numero di bit in caso di overflow o diventa troppo sporca?

spanezz commented 3 years ago

Per i dati che girano in DB-All.e non abbiamo modo di usare modificatori C: quelli sono gestiti solo al momento di importazione ed esportazione, e spariscono in tutte le altre fasi di lavoro (come inserimento, query, rappresentazione nel DB).

Piuttosto di un modificatore C, uno può creare un nuovo B nella B locale che è il risultato del B modificato col C, e usare quello