dballe
dballe copied to clipboard
ARPA-SIMC
Significato del missing value ("-") nella query
Con riferimento a https://github.com/ARPA-SIMC/dballe/issues/200#issuecomment-562511945, io mi sono dell'opinione che una query fatta con un missing value esplicito (e.g. l1=-) dovrebbe voler dire "dammi tutti i record che hanno l1 missing" e non "ignora il filtro su l1" (significato che è già disponibile non settando nessun valore nella query per l1). Al momento dballe si comporta secondo la seconda interpretazione.
Chiedo un parere interno al SIMC.
Occhio a distinguere bene l'effettiva necessità della cosa: se serve si può implementare, ma è un lavoro non banale
L'uso principale e generale per tutte le mie applicazioni è poter specificare il livello che voglio, ossia: 103.2000.-.- fino ad ora per me è stato inteso per dammi i dati a due metri dal suolo e non dammi tutti i dati a due metri dal suolo più tutti gli eventuali strati possibile con un estremo a due metri dal suolo.
Se si è inteso sempre la seconda questo comporta molti ma molti problemi con cui ci siamo scontrati raramente fino ad ora per la rara presenza di strati.
Quindi per me l'uso principale del "-" in leveltype2 L2 è per specificare che NON voglio uno strato. L'opzione leveltype2 L2 = "*" invece anche se potrebbe venir utile al momento non mi preoccupa.
Come dicevo, è un lavoro non banale. Se siamo tutti d'accordo mi ci metto: ci vorrà del tempo.
Se a voi va bene, riservo MISSING_INT - 1 come valore 'mancante ma voluto mancante' a differenza di 'mancante e basta'
Se a voi va bene, riservo MISSING_INT - 1
stiamo parlando solo di levetype2 e P2 ?
se si per me non ci sono problemi in quanto entrambi possono essere solo interi senza segno.
Rimango solo perplesso perchè dovrebbe essere UINT_MAX
Ditemi voi di cosa stiamo parlando: per me possiamo andare da solo leveltype2 e p2, a tutti e 4+3 i valori di livelli e timerange
I 3 valori dei timerange ci devono sempre essere, così come leveltype1. Quindi, il - deve essere implementato solo per l1, leveltype2, l2.
Benissimo anche MISSING_INT - 1: se anche ci mangiamo un altro valore (oltre a MISSING_INT) su 2^32 disponibili, non mi sembra un grosso problema.
e' possibile che il tutto nasca dalla confusione nell'uso di leveltype2 e P2 opzionali. Una possibilità è quella di non prevedere mai dati "missing" e introdurre leveltype2 = 0 per la codifica del singolo strato Bisogna valutare le incompatibilità Necessita confronto
introdurre leveltype2 = 0
leveltype2 = 0 è "reserved" (per dballe e per WMO), non mi sembra una scelta ottimale, se proprio non vogliamo introdurre un valore speciale "lo voglio missing", allora meglio 255 che per il WMO si chiama proprio "missing" e noi lo abbiamo opportunamente saltato in dballe.
Da una riunione in corridoio, relativamente ai timerange:
- in fase di inserimento,
p1ep2devono sempre essere obbligatori per i timerange
p1 e p2 non sono mai mancanti e hanno significati precisi. Nel caso di pindicator=254, p2 non ha senso ed è documentato da lasciare a 0.
In fase di query, non c'è ambiguità tra - e *
Da una riunione in corridoio, relativamente ai livelli:
- in fase di inserimento,
l1,leveltype2,l2, sono sempre obbligatori per i livelli
Per leveltype2 possiamo usare 255 per indicare "livello e non layer".
Per i valori l1 e l2, quando non hanno senso, cosa mettiamo in inserimento?
Al momento, il database ha MISSING_INT per i valori di leveltype2, l1 e l2 non espressi in fase di inserimento. Paolo diceva che lui li setta sempre: a cosa setti leveltype2 e l2 per i livelli, e a cosa setti l1 quando non ha senso, come per esempio quando leveltype1 è 1 (Ground or water surface) ?
A seconda di cosa viene inserito nel database, possiamo:
- se sono valori diversi da
MISSING_INT, usare quei valori quando in query c'è- - se c'è
MISSING_INT, possiamo decidere di inserire invece altri valori, e usare quelli quando in query c'è- - se decidiamo di avere
MISSING_INTperl1el2(e forseleveltype2) nel database, devo scrivere parecchio codice per salvare nella struttura query la distinzione tra "tutto" (*) eMISSING_INT" (-`)
Fatemi sapere
Bump della issue, che dobbiamo riprendere in mano entro la fine dell'anno.
Riprovo con un bump, ricordando che questa issue parte delle attività 2023. Visto che è passato un po' di tempo, assegno la issue a @pat1 (che dalla documentazione interna vedo essere il referente per questa tematica) e a @spanezz in qualità di sviluppatore.
In inserimento e rappresentazione nel DB, tutto rimane invariato.
In query con valori di leveltype2 non specificati, tutto rimane invariato.
Viene aggiunta la possibilità di specificare leveltype2=MISSING_INT-1 o leveltype2="-", per significare "il valore nel database deve essere "mancante" invece di "qualunque"