arpa-simc / adriaclim-geoportal Goto Github PK

Ciao Emanuele,

il nuovo collega si è scaricato l’ultima versione del progetto ma, quando ha provato a lanciarlo, ha incontrato tutta una serie di errori legati ai file nella cartella static e si trattava, per ogni file in questa cartella, di un errore di tipo MIME e cioè:

Django refused to apply style because its MIME Type (‘text/html’) is not a supported stylesheet MIME type.

Abbiamo provato in vari modi a risolvere questo problema (usando la libreria mimetype, installando whitenoise ecc.) ma purtroppo il problema non è stato risolto ma lo è stato, solo momentaneamente ovviamente, mettendo DEBUG = True che in fase di produzione ovviamente non va fatto.

Che tipo di problema può esserci? Qualcosa legato al file settings.py e in particolare a questa parte di codice?

STATIC_URL = '/static/'
STATIC_ROOT=os.path.join(BASE_DIR,'static_root/')

STATICFILES_DIRS=[
    BASE_DIR / 'static',
]

GPLv3.

Il metodo listAllDatasets scrive il template AdriaProject/templates/allDatasets.html (https://github.com/ARPA-SIMC/adriaclim-geoportal/blob/main/adriaclim-master/AdriaApp1/code/AdriaProject/myFunctions/allFunctions.py#L437). Stessa cosa mi pare succeda per AdriaProject/templates/getData.html (https://github.com/ARPA-SIMC/adriaclim-geoportal/blob/main/adriaclim-master/AdriaApp1/code/AdriaProject/myFunctions/allFunctions.py#L461).

Questo potrebbe creare due problemi:

1. Il codice potrebbe essere in un'area readonly e quindi non scrivibile.
2. Il metodo è invocato in una view (

   adriaclim-geoportal/adriaclim-master/AdriaApp1/code/AdriaProject/Dataset/views.py

   Line 97 in 6571b00

   allFunctions.listAllDatasets()

   ) e quindi ci potrebbero essere scritture contemporanee.

Probabilmente, conviene rendere l'output della chiamata al server ERDDAP un parametro da passare al rendering insieme al template.

L'URL del server ERDDAP è hardcoded nel codice.

The datasets in the geoportal menu could be structured in the following tree view, based on the corresponding metadata:

|_Observations[adriaclim_dataset == 'observation']
|      |_?
|
|_Numerical models[adriaclim_dataset == 'model']
|      |_Large scale[adriaclim_scale == 'large']
|      |_Pilot scale[adriaclim_scale == 'pilot']
|      |_...(possibly other scales)
|
|_Indicators[adriaclim_dataset == 'indicator']
|      |_Large scale[adriaclim_scale == 'large']
|      |_Pilot scale[adriaclim_scale == 'pilot']
|      |_...(possibly other scales)
|
|_all datasets(in a flat list as now)

a zoom e.g. on Indicators-Large scale (the same would be valid for all the other branches at the same level):

 |_model1[adriaclim_model='model1']
 |_model2[adriaclim_model='model2']
 |_...(dynamic list based on the possible values of adriaclim_model when adriaclim_dataset == 'indicator' && adriaclim_scale == 'large'

Further levels or branching could be based on adriaclim_timeperiod (for observations, models and indicators) and on adriaclim_type (for indicators only), but this has to be decided in a special meeting with the users or their representors.

adriaclim_timeperiod may also influence the operations available when the user selects data on a point or area, e.g. yearly cycle month by month does not make sense with seasonal or yearly data, etc.

Also adriaclim_scale rather than being a level of the tree structure may be a selector based on the size of the areas currently selected by the user.

The metadata key and value names may also change in the future.

manage.py runserver is a development web server and should not be used in production. See https://docs.djangoproject.com/en/4.1/howto/deployment/ for alternatives (ASGI o WSGI).

See docker-compose.yml.

An indicator with yearly data has been uploaded to Erddap, it is a "table" dataset "TEST Indicator wsdi, MedCordex (LMDZ), yearly, 2021-2050, Puglia". The geoportal sees it, but nothing happens if I select it. Although not definitive (e.g. the dates should point to 01/01 not 07/01) we can start working on it.

See https://docs.djangoproject.com/en/4.1/howto/deployment/checklist/#debug

Now we have a button on the left that, if selected, allows to choose data belonging to an area (#9) or to a single point and opens a plot window (#10).

In order to simplify the use and add flexibility, the button should be turned into a drop-down menu or equivalent, named e.g. "point selection tool", with at least two choices "select a single point on the map", "select all points in one of the areas shown", if possible we could add a third option "select points around the cursor" for selecting a cloud of points, but it's not obvious how to define the area and give feedback to the user, or maybe something allowing to draw a rectangle on the fly, otherwise we just leave the first two choices.

We can eliminate the feature that selects 3 neighbouring points for having a statistics, when we select a single gridded point, it was a temporary measure waiting for the availability of area choice.

La selezione attuale dei dataset per nome, è un inizio ma non è sufficiente.

C'è l'esigenza come minimo di ramificare i dataset nel seguente modo:

• modellistici
  • larga scala (praticamente a 6/2022 abbiamo solo questi)
    • modello x
    • modello y
    • modello z...
  • locali (simulazioni specifiche di Adriaclim)
• osservativi
• indicatori
  • basati su modelli a larga scala
    • trend (senza la dimensione temporale)
    • serie temporali
  • basati su modelli locali
    • trend (senza la dimensione temporale)
    • serie temporali
  • basati su osservazioni (?)

Lo scopo è quello di far sì che i "pianificatori" possano facilmente trovare gli indicatori senza perdersi in molteplici dataset modellistici, ad esempio.
La ramificazione potrebbe avvenire sulla base di metadati che andremo a definire nel progetto ed aggiungere manualmente ai dataset, la cosa pare fattibile, in alternativa si dovrebbe definire un database sul eoportale, ma non sarebbe automaticamente aggiornato alla comparsa di nuovi indicatori.

La prima soluzione è fattibile, riporto mail di CMCC sui metadati

...ha sicuramente senso modificare gli attributi/metadati dei dataset, e aggiungerne di customizzati se serve.
Una volta sistemati i metadati, non credo serva cambiare anche l'id del dataset (che avevo in ogni caso intenzione di sistemare e rendere più omogenei).
Comunque sono disponibile a modificare i metadati attuali, tanto al momento sono praticamente tutti del CMCC. :-)
L'unico problema è che potrebbe volerci un po' di tempo per cambiarli tutti, perché le modifiche non so se e quanto saranno scriptabili.

A questo punto meglio dare anche delle indicazioni ai partner con nodo ERDDAP, in modo da avere lo stesso set minimo di attributi (standard e/o custom) valorizzati.
Saranno poi tutti reperibili, anche machine-to-machine via-REST, come ad esempio riportato in questo dataset in fondo alla pagina:
https://erddap-adriaclim.cmcc-opa.eu/erddap/info/atm_regional_82b0_b7fe_c37d/index.html

A parte le questioni della scala colori, nella mappa del geoportale non riesco a scorrere nel tempo e/o nella coordinata verticale, mi pare che i controlli non facciano niente, se ad esempio scelgo "CMEMS-Reanalysis Concentration of Dissolved Molecular Oxygen in Adriatic Sea from 1999 to 2019", gli estremi delle date e delle profondità coincidono più o meno con quanto indicato su erddap, ma qualunque operazione io faccia cambiando data o posizione verticale, anche quando ridisegna, il grafico non cambia e nella legenda in basso a sinistra c'è sempre scritto 1/1/1999 profondità 1m. Lo stesso grafico visto su Erddap ha come minimo una forte variazione verticale, nel tempo non molta in verità.

Magari sbaglio qualcosa, però se è così, non è intuitivo.

Le tipologie di grafici che si prevedono associare agli indicatori di tipo "serie temporale su punti" quando un utente li richiederà tramite un'area poligonale saranno selezionabili tra:

• spaghetti plot, cioè tutti i punti nell'area sovrapposti, in funzione del tempo (x1(t), x2(t), ... xn(t)),
• media, max, min istante per istante tra tutte le serie temporali dell'area
• min, 10^ percentile, mediana, 90^ percentile, max sulla distribuzione relativa a ciascun istante tra tutte le serie temporali dell'area.

Le serie temporali saranno aggregate, a seconda del dataset, su anni, stagioni o mesi, per cui non sono big data, al max ~500 valori x n. di punti nell'area che potrebbero essere dell'ordine di 100 al max, credo si elaborino senza grossi problemi anche in javascript.

Per fare un esempio (se non sbaglio stiamo già usando d3): https://observablehq.com/@d3/multi-line-chart
È stato inoltre mostrato un box plot tipo questo https://observablehq.com/@d3/box-plot che potrebbe essere una buona alternativa al terzo punto nel caso di serie brevi, tra l'altro lì c'è l'esempio di come si calcolano i percentili in d3.

Rispetto alla grafica attuale della serie su un punto si dovrebbe usare uno stile più sottile e magari introdurre la possibilità di zoomare su un intervallo del periodo temporale.

L'esempio da imitare è l'atlante dell'IPCC; tra l'altro notavo proprio che nell'atlante IPCC c'è anche la possibilità di scelta delle aree (selettore "region set") che è quanto richiesto nella issue #9, si può prendere spunto.

See https://docs.djangoproject.com/en/4.1/howto/deployment/checklist/#secret-key

Come emerso dalla conferenza c'è l'esigenza di avere diverse gerarchie di aree poligonali da mostrare sulla mappa e utilizzare per l'aggregazione spaziale degli indicatori.

Propongo che il geoportale metta a disposizione una vista con una singola area che copre l'Adriatico e la parte di terraferma i cui fiumi scolano nell'Adriatico, diciamo un rettangolo lon 6.5-22.0 lat 38.5-47.0, e una seconda vista, che sarebbe la vista di default all'apertura, con le 8 "pilot areas" del progetto, piò o meno queste:

Mi posso procurare una mappa migliore se è il caso, ma non è fondmantale che le aree siano esatte.
Poi c'è l'esigenza di avere una vista sui comuni, questa la lascerei come opzione all'utente (quando ci sarà autenticazione), cioè di caricare un geojson personale con i poligoni di sua scelta.

Quindi da qualche parte nell'interfaccia ci dovrebbe essere un selettore che commuta tra le viste Adriatico|Pilot|una o più custom area. Le aree visualizzate saranno poi quelle su cui si basa la selezione dei punti per la visualizzazione degli indicatori.

Usare un base template permetterebbe di avere uno stile e una struttura omogenea in tutto il sito e di controllarli da un unico punto.

ADRIACLIM INDICATORS: data format convention

DATA FORMAT: “csv”

INDICATORS’ STRUCTURE:

1. ABSOLUTE VALUES:

1st Column: Time
2nd Column: Latitude
3th Column: Longitude
4th Column: Indicator
The number of rows is N_points x N_timesteps (sorted by ascending time), where:
N_points is the number of gridpoints in the pilot area
N_timesteps is the number of timesteps

TIME CONVENTION:
MONTHLY: YYYY-MM-01
SEASONAL: YYYY-02-16 (WINTER); YYYY-05-16 (SPRING);
YYYY-08-16 (SUMMER); YYYY-11-16 (FALL).
ANNUAL: YYYY-01-01

2. ANOMALIES:
   1st Column: Fictitious Time 2020-01-01 (needed for readability)
   2nd Column: Latitude
   3th Column: Longitude
   4th Column: Indicator
   Number of Rows: N_points

Alcuni template hanno solo il contenuto, senza i tag html, head, body:

• specificDataset.html
• allDatasets.html
• getData.html