Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Significato del missing value ("-") nella query #201

Open
edigiacomo opened this issue Dec 6, 2019 · 16 comments
Open

Significato del missing value ("-") nella query #201

edigiacomo opened this issue Dec 6, 2019 · 16 comments

Comments

@edigiacomo
Copy link
Member

Con riferimento a #200 (comment), 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.

@spanezz
Copy link
Contributor

spanezz commented Dec 6, 2019

Occhio a distinguere bene l'effettiva necessità della cosa: se serve si può implementare, ma è un lavoro non banale

@pat1
Copy link
Contributor

pat1 commented Dec 6, 2019

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.

@pat1 pat1 removed their assignment Jan 7, 2020
@pat1
Copy link
Contributor

pat1 commented Jan 7, 2020

Questa non è una cosa da poco ...
Nessuna novità ?

@spanezz
Copy link
Contributor

spanezz commented Jan 10, 2020

Come dicevo, è un lavoro non banale. Se siamo tutti d'accordo mi ci metto: ci vorrà del tempo.

@spanezz
Copy link
Contributor

spanezz commented Jan 10, 2020

Se a voi va bene, riservo MISSING_INT - 1 come valore 'mancante ma voluto mancante' a differenza di 'mancante e basta'

@pat1
Copy link
Contributor

pat1 commented Jan 10, 2020

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

@spanezz
Copy link
Contributor

spanezz commented Jan 10, 2020

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

@edigiacomo
Copy link
Member Author

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.

@pat1
Copy link
Contributor

pat1 commented Jan 10, 2020

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

@spanezz
Copy link
Contributor

spanezz commented Jan 10, 2020

Ok, allora per ora mi fermo su questo fronte. Fatemi sapere.

@dcesari
Copy link
Member

dcesari commented Jan 10, 2020

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.

@spanezz
Copy link
Contributor

spanezz commented Feb 5, 2020

Da una riunione in corridoio, relativamente ai timerange:

  • in fase di inserimento, p1 e p2 devono 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 *

@spanezz
Copy link
Contributor

spanezz commented Feb 5, 2020

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_INT per l1 e l2 (e forse leveltype2) nel database, devo scrivere parecchio codice per salvare nella struttura query la distinzione tra "tutto" (*) e MISSING_INT" (-`)

Fatemi sapere

spanezz added a commit that referenced this issue Feb 8, 2020
@edigiacomo
Copy link
Member Author

Bump della issue, che dobbiamo riprendere in mano entro la fine dell'anno.

@edigiacomo
Copy link
Member Author

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.

@edigiacomo edigiacomo assigned spanezz and unassigned dcesari and edigiacomo Nov 28, 2023
@spanezz
Copy link
Contributor

spanezz commented Jan 23, 2024

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"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants