arpa-simc / cosudo Goto Github PK

Integrazione continua
Lo sviluppo del software dovrà essere corredato da unit tests.
Quando sia possibile ogni issue aperta su github dovrà essere accompagnata da test automatici.
Ad ogni commit dovranno essere eseguiti, sulla piattaforma che ospita il codice, i test automatici.
Se i test automatici passano, il file spec del pacchetto dovrà essere inviato a Copr per la
pacchettizzazione automatica dell'ultima release.
I test dovranno essere verificati per:
● Python: 3.6
● Django: 2.2, 3.0
● Database: postgres, sqlite
● Distribuzioni: centos8, fedora 30 e successive versioni rilasciate fino alla consegna
Sarà possibile utilizzare la piattaforma Travis e le configurazioni già utilizzate da ARPAE-SIMC

Salve, stiamo cercando di visualizzare "correttamente" il dem, ma questo risulta spostato sulla mappa,cambiando i valori delle x e delle y nel file hdr riusciamo a posizionarlo nel punto giusto sulla mappa ed anche la dimensione sembra esatta, dato che nemmeno gdal riesce a dirci l'esatta proiezione di riferimento, avete idee o consigli? o potrebbe essere che il file hdr è stato modificato? Grazie

Attivare la barra di ricerca nella visualizzazione dei grafici

Visualizzazione layer quando barra temporale su *

nei grafici per una rappresentazione ottimale nella maggioranza dei casi è meglio connettere i punti con segmenti lineari e non tramite spline

Segnalo che in RMAP si fa uso di:
python3-django-cors-headers

A Django App that adds Cross-Origin Resource Sharing (CORS) headers to
responses. This allows in-browser requests to your Django application from
other origins.

Terminare documentazione

Nel capitolato è indicato di far visualizzare su mappa gli attributi di confidenza generati dal controllo automatico, che dovrebbero essere i seguenti :B33192, B33193, B33194.
Sul db di test non sembrano presenti questi flag, il seguente script non restituisce nulla:

db = get_db()

for rec in db.query_data({"var": "B33194"}):
    print(rec)  

Come posso simulare le etichettature automatiche ?
Mentre per l'invalidazione manuale quale è il flag che va inserito ?

Le date non sembrano essere corrette, bisogna rivedere i timerange e se il problema è relativo la versione forkata di skinnywms o da una nostra gestione errata (esempio parametro utilizzato errato)

Ho caricato su Gdrive un tar derivato da dati estratti da http://viewfinderpanoramas.org/dem3.html a 3" d'arco (~100m) e rielaborati da me per creare i relativi file descrittori ESRI bil/hdr, swappare i dati (script conv.sh) e creare il dataset virtual gdal associato.

https://drive.google.com/file/d/1LA-njY5vMDe0xELJJ_Bk3uavWBsAMR2B/view?usp=sharing

Originally posted by @dcesari in #47 (comment)

Ci risulta impossibile riscaricare i dati qui presenti.
Abbiamo dato per sconto che anche il file FLT vada "swappato" usando lo script passato con i file bil, in caso contrario, che proiezione possiamo usare per ricavare i punti x e y dipartenza?

• dbajson : json puro, immediatmente leggibile da js
• jsonline : non json puro, in alcuni casi fa risparmiare memoria
• geojson : json puro, immediatamente utilizzabile con alcune API js quali leaflet, ma al momento non include gli attributi e risulta più voluminoso

Bisogna decidere quale formato utilizzare e valutare se includere gli attributi in geojson.

Provando a caricare gli attributi per dei test, ho notato che una volta caricati borinud comunque non li restituiva, invece facendo una query da python gli attributi erano presenti. Guardando nel codice di borinud, credo di aver individuato il problema.
Nella classe DballeDB di borinud la funzione fill_data_db è la seguente:

   def fill_data_db(self, rec, memdb):

        db = self.__open_db()

        with db.transaction() as tr:
            with memdb.transaction() as memtr:
                for cur in tr.query_data(rec):
                    memtr.insert_data(cur.data, True, True)

Mentre credo debba essere modificata in questo mod:

    def fill_data_db(self, rec, memdb):

        db = self.__open_db()
        #aggiunta
        if (self.attr):
            rec["query"] = "attrs"
        with db.transaction() as tr:
            with memdb.transaction() as memtr:
                for cur in tr.query_data(rec):
                    memtr.insert_data(cur.data, True, True)

Non so se è esatto ma così facendo borinud restituisce gli attributi correttamente

Per il servizio WMS i dati in formato GRIB saranno gestiti mediante Arkimet, come da capitolato si richiede che:
"L’accesso ai dati dovrà essere realizzato tramite API python del pacchetto python descritte a https://arpa-simc.github.io/arkimet/python/index.html".
Nella descrizione della funzione "query_data" (https://arpa-simc.github.io/arkimet/python/arkimet.dataset.html#) vi è un modo per scaricare il grib risultante dalla query come nelle api web (es. http://127.0.0.1:8080/query?query=reftime:%3E=2005&style=data)?

I colori dei dati della mappa e dei wms devono essere armonizzati per tipi (temperature con temperature, vento con vento ecc... )

Salve, dove posso trovare qualche vostro file DEM in formato ESRI FLT così da poterli testare?

Uncaught ReferenceError: showAllGraph is not defined
onclick https://test.rmap.cc/dynamic/map/:1

Per la visualizzazione sommaria dei flag di qualità sui cluster ho pensato che per le invalidazioni posso mostrare il numero di dati invalidati sul numero dei totali (es. 25 of 300), mentre per gli altri flag di qualità è importante visualizzare il minimo o il massimo dei valori, oppure una media ?

E' possibile testare il lavoro fatto finora? In particolare mi riferisco alla visualizzazione delle invalidazioni. Inoltre è possibile testarlo su un set di dati recente (ultimi giorni, la rete RMAP, temperatura e precipitazioni) ?

Permettere le invalidazioni mentre si visualizzano i grafici

Per l'aggiunta ad rmap dopo aver eseguito l'installazione del rpm, bisogna modificare i file di settings e di url, in quanto non credo si possa automatizzare tale operazione, giusto?
In caso di conferma procedo alla pubblicazione della nuova versione su copr

I vecchi file grib non vengono cancellati dalla cartella di skinnywms prima diunanuova estrazione.

Per la creazione degli allarmi devo effettuare una richiesta a borinud con due periodi differenti, uno storico e uno che vogliamo analizzare, come posso richiedere queste due summary a borinud; perché effettuando le seguenti richieste ovvero con anno e mese differente il risultato è uguale:
https://rmap.cc/borinud/api/v1/dbajson/*/*/*/254,0,0/103,2000,-,-/B12101/summaries/2019/11/26
https://rmap.cc/borinud/api/v1/dbajson/*/*/*/254,0,0/103,2000,-,-/B12101/summaries/2020/11/26

Abbiamo trovato le "descrizioni" delle feature B, livello, trange ecc in diversi file javascript, vorremmo evitare di utilizzarli come mappe poiché ogni variazione/aggiunta di feature porterebbe inevitabilmente a modificare questi file.
Qualora questi risultino "immutabili" potremmo procedere come avete già fatto, in caso contrario vorremmo sapere se vi sono api o librerie che restituiscono tali descrizioni in alternativa?

Per la visualizzazione dei dati di borinud su mappa abbiamo optato (come da capitolato) per i cluster con la rappresentazione dei dati (per esempio temperatura)

Mentre per quanto riguarda il vento è indicato di rappresentarli con la rosa dei venti, si intende una cosa del genere?

Son riuscito a risolvere il problema dell'import (dando nel comando di import anche --wipe-first ha funzionato).
Ora i dati costanti di stazione vengono correttamente visualizzati.
Mentre il problema che si presentava utilizzando rmap.cc per borinud era causato dalla mancanza degli attributi nella risposta ai dati, infatti con test.rmap.cc funziona tranquillamente.
Nei prossimi gg pubblicherò la release

Ho creato una una pull request (#50) con le nuove modifiche, ma fallisce per fedora 30. Perché non riesce ad abilitare il repository copr simc/stable necessario per la dipendenza a dballe. Avete suggerimenti ?

Ho visto che è stato effettuato un fork di tutto il progetto rmap che comprende firmware per microcontrollori etc.
Forse non specificata nel capitolato perchè sottointesa e a noi evidente, lo sviluppo era richiesto per una APP django eventualmente da integrare in rmap o in altri web server.
E' possibile che l'app cosudo richieda alcune app del pacchetto RMAP per sfruttare se necessario alcune funzionalità fornite da queste app (quali alcune tabelle di showdata), ma la cosa è del tutto opzionale.
L'app showdata di rmap dovrà rimanere così come è magari decidendo se integrare alcune funzionalità di cosudo.
La distribuzione di cosudo dovrebbe essere una cosa di questo genere:
https://realpython.com/installable-django-app/

e a titolo di esempio dovrebbe presentarsi similmente a:
https://github.com/mozilla/django-csp/

Ossia una app da integrare in un progetto e il nome della app non dovrà essere showdata (suggerisco cosudo).

Suggerisco anche di utilizzare un directory del repository cosudo in quanto dovranno essere sviluppate altre componenti oltre alla app django

L'unica interazione necessaria tra cosudo e rmap sono i web service forniti dall'app borinud contenuta in rmap.

Ilsetup.py NON crea l'eseguibile in bin.

molti dati su mappa vengono rappresentati come NaN.
pare corrisponda a valori non rappresentabili nel formato prestabilito

ad esempio:
selezionare rete "fidu" e var "Pressure"

Come potete vedere nell'immagine ho trovato questo parametro timeRangeIndicator, nell'esploarazione (fatta nei giorni scorsi) dei tool di conversione in fortran, avevo trovato che nel caso di GRIB1 il valore da impostare fosse 4, nel vostro file trovo impostato 13, non so se sia un problema di tavole di conversione dovuto al sistema, cosa facciamo, impotiamo13?
nell'mmagine sotto potete ossevare a sinistra un file generato da noi, a destra uno degli esempi creati da voi, il file netcdf da cui sono stati generati i GRIB dovrebbe essere il medesimo.

https://test.rmap.cc/dynamic/map/

seleziona la variabile PRESSURE
SEARCH
la risposta è
nessun risultato

questo non dovrebbe essere possibile visto che il summary dovrebbe presentare solo dati realmente presenti: almeno un dato deve esserci altrimenti non deve esserci quella varibile nel summary ...

Rimaniamo in attesa come deciso in riunione delle api per le tabelle vm2 di conversione e quelle che forniscono le stazioni, livelli, timerange, network e variabili non presenti nel db, necessari per l'ultimazione della parte di invalidazione.

mi sembrerbbe più intuitovo diminuire con la freccia in basso e aumentare con la freccia in alto

Ho notato dopo un test che le summary non forniscono tutti gli orari disponibili, è un effetto voluto?
Per esempio nell'immagine che segue potete notare che nello slider del tempo in basso a sinistra l'unica combinazione è con l'orario 00:00:00, ma in realtà il dato aperto con il popup mostra che l'orario del dato è 14:45:00.
Controllando anche, manualmente nella risposta del summary effettivamente la combinazione non esiste.

Necessitiamo dell'acccesso con poteri magori per poter aggiungere i secrets sugit nel repository cosudo

Correggere priozione inserendo una utilizzabile da leaflet e pacchettizzare l'installazione

Creare un menù in cui sono disponibili le nuove funzionalità sviluppate.

Le vars e i timerange vanno sostituiti con le loro descrizioni nella tabella degli allarmi

Nel capitolato ci scrivete:

Gestione allarmi
Per lo sviluppo di questa sezione della web app dovrà essere utilizzato il framework
GeoDjango https://docs.djangoproject.com/en/3.0/ref/contrib/gis/

Nella prima riunione, rileggendo gli appunti presi, ci avete chiesto di non utilizzare PostGis.
Dato che GeoDjango necessita di un DB Geospaziale, ci chiedevamo se per il salvataggio degli allarmi, dobbiamo tener conto di quanto dettoci nella prima riunione o seguire il capitolato.Incascontrario possiamo tranquillamente continuare a gestire le coordinate mediante semplici numeri e non con le utils di GeoDjango.

Ho trasformato il file lua estrapolando le variabili e ho notato che hanno il seguente formato (con ripetute le variabili per ogni time-range o livello diverso):
{"bcode": "B13011", "tr": 1, "p1": 0, "p2": 43200, "lt1": 1, "l1": "nil", "lt2": "nil", "l2": "nil", "unit": "mm"}
Per come è strutturato la piattaforma di invalidazione invece, avrei bisogno di time-range e livelli scorporati, in modo tale da permettere la combinazione all'utente. Potrei effettuare l'estrapolazione a runtime ma aggiungerebbe un ulteriore calcolo abbastanza oneroso. Come procedo ?

Arpae deve fornire l'elenco dei parametri da mettere a disposizione per la visualizzazione. Per ogni prodotto, verrà fornita una query arkimet per identificare ed estrarre quei dati.

ci sono i dati (netcdf) per fare i test di conversione avanti e indietro ...

Inserire file licenze

Mediante flask, skinnywms e magics abbiamo realizzato un wms, abbiamo eseguito diversi test di visualizzazione con diversi grib, resta da capire ora in base alla tipologia di feature da mostrare quale specifico stile grafico applicare.

Ho proceduto a pubblicare il pacchetto rpm su copr, ma ho riscontrato un problema che non mi si era presentato prima. Praticamente la creazione del rpm fallisce per fedora (qui il log ), mentre per centos funziona perfettamente. Avete idee sul perché? ho provato a fare un pò di ricerche (dato che ho meno esperienza con fedora rispetto ad ubuntu) ma non sono riuscito a venirne a capo.

Vorrei avere più informazioni sulla struttura del grib repository, in dettaglio vorrei sapere se ci verrà fornito un grib per ogni giorno (e per tipo di dato), o ci verrà fornito un grib per fascia oraria (come il seguente repository)?

Rimuovere il bug di richiesta della cartella nel file di output in radar_grib2netcdf

la temperatura su mappa viene visualizzata in °C , nel grafico in K.

oltre a questa schizzofrenia mi chiedo come venga fatta la conversione tra unità di misura come sia gestibile nel backend

Correggere la richiesta che si effettua nella pagina map, effettuando la richiesta ogni volta che si sceglie una nuova data