Differenze tra le versioni di "Gruppo Meteo/RFC-rmap obsolete"

Da raspibo.
Jump to navigation Jump to search
Riga 521: Riga 521:
  
 
Il payload è in formato JSON: '''{ “v”: VALUE, “t”: TIME, “a”: { “BXXYYY”: VALUE, … } }'''
 
Il payload è in formato JSON: '''{ “v”: VALUE, “t”: TIME, “a”: { “BXXYYY”: VALUE, … } }'''
* '''VALUE''': valore in formato CREX
+
* '''VALUE''': valore in formato [https://www.wmo.int/pages/prog/gcos/documents/gruanmanuals/ECMWF/crex_user_guide.pdf CREX]
 
* '''TIME''': formato YYYY-mm-ddTHH:MM:SS.MSC (secondi e millisecondi opzionali)  
 
* '''TIME''': formato YYYY-mm-ddTHH:MM:SS.MSC (secondi e millisecondi opzionali)  
 
Gli attributi (“a”) solitamente per controllo di qualità sono opzionali
 
Gli attributi (“a”) solitamente per controllo di qualità sono opzionali

Versione delle 21:05, 12 ott 2016

RFC rmap

Definizioni

Campionamento e processo di misurazione

  • Campionamento è il processo per ottenere una discretizzata sequenza di misure di una quantità.
  • Misurazione: processo volto a ottenere sperimentalmente uno o più valori che possono essere ragionevolmente attribuiti a una grandezza (UNI CEI 70099:2008);
  • Valore: elemento di un sistema di misura che è direttamente influenzato dal fenomeno, corpo o sostanza che propongono la grandezza da sottoporre a misurazione (UNI CEI 70099:2008). Una osservazione (valore di una grandezza) è il risultato del processo di campionamento. Nel contesto di analisi di serie, un'osservazione è derivata da un numero di campioni.
  • Risultato di misura: insieme di valori attribuiti a un misurando congiuntamente a ogni altra informazione pertinente disponibile (UNI CEI 70099:2008);
  • Taratura (Calibration): operazione eseguita in condizioni specificate, che in una prima fase stabilisce una relazione tra i valori di una grandezza, con le rispettive incertezze di misura, forniti da campioni di misura, e le corrispondenti indicazioni, comprensive delle incertezze di misura associate, e in una seconda fase usa queste informazioni per stabilire una relazione che consente di ottenere un risultato di misura a partire da un'indicazione (UNI CEI 70099:2008). NOTA: Il termine "calibrazione" non dovrebbe essere usato per designare la taratura.
  • Trasduttore di misura: dispositivo, impiegato in una misurazione, che fornisce una grandezza di uscita avente una relazione specificata con la grandezza di ingresso (UNI CEI 70099:2008). ESEMPI Termocoppia, trasformatore di corrente elettrica, estensimetro, elettrodo per la misurazione del pH, tubo di Bourdon, lama bimetallica.
  • Variabili atmosferiche come la velocità del vento, temperatura, pressione e umidità sono funzioni di quattro dimensioni - due orizzontali, una verticale e una temporale. Esse variano irregolarmente in tutte e quattro, e lo scopo dello studio del campionamento è quello di definire le procedure di misura pratiche per ottenere osservazioni rappresentative con incertezze accettabili nelle stime delle medie e variabilità.

Data Level

  • Dati Level I , sono le letture dirette degli strumenti espresse in appropriate unità fisiche e georeferenziate (campionamenti)
  • Dati Level II, dati riconosciuti come variabili meteorologiche (osservazioni/misurazioni); possono essere ottenuti direttamente da strumenti o derivati dai dati Level I
  • Dati Level III sono quelli contenuti in dataset internamente consistenti, generalmente su grigliato.

I dati scambiati a livello internazionale sono livello II o livello III

Report

Un report è un insieme (sincrono) di osservazioni a livello II completo di metadati o con la possibilità di ricostruire i metadati.

Protocolli per R-map

  • MQTT (Message Queue Telemetry Transport) è un protocollo publish/subscribe particolarmente leggero, adatto per la comunicazione M2M tra dispositivi con poca memoria o potenza di calcolo e server o message broker.
  • AMQP (Advanced Message Queuing Protocol) è protocollo per comunicazioni attraverso code di messaggi. Sono garantite l'interoperabilità, la sicurezza, l'affidabilità, la persistenza. Nella sua implementazione Rabbitmq exporta un broker MQTT e fornisce delle api web

Sistema di misura

Un sistema di misura è costituito da 3 componenti:

  • sensore: trasforma le variazioni di una grandezza misurata in variazioni di una grandezza di tipo elettrico;
  • sistema di controllo deputato a svolgere le seguenti funzioni:
  1. acquisizione ad intervalli prestabiliti dei segnali provenienti dal sensore;
  2. eventuale memorizzazione locale dei dati;
  3. trasmissione dei dati.
  • sistema di alimentazione.

Visione generale

Seguendo un semplice flusso dei dati di una rete rmap compatibile si possono prevedere le seguenti fasi:

  • digitalizzazione dei campionamenti o osservazioni
  • pubblicazione dei campionamenti su broker MQTT al di fuori del path rmap
  • pubblicazione delle osservazioni su broker MQTT nel path rmap
  • eventuale trasformazione dei campionamenti (level I) in osservazioni (level II) e loro ripubblicazione su broker MQTT nell'albero MQTT
  • composizione di un report
  • invio del report ad un accentratore tramite AMQP
  • archiviazione dei dati in modo permanente
  • disponibilità dei dati in archivio tramite web services

Questo è uno schema tra i più semplici; rimane la possibilità di articolarlo replicando i servizi, distribuendoli in rete etc.

Dati e Metadati

Ogni dato è un valore associato a 6 metadati univoci.

  • Time (date time della osservazione o di termine del periodo di osservazione)
  • Longitudine, latitudine ed un identificativo (utilizzabile nel caso di stazioni mobili)
  • Tipo di report o network: definisce stazioni con caratteristiche omogenee (classe degli strumenti)
  • Time range: indica osservazione o tempo della previsione ed eventuale elaborazione “statistica”
  • Livello: le coordinate verticali (eventualmente strato)
  • Variabile: parametro fisico

Ogni dato può essere dotato inoltre di attributi (controolo di qualità) definiti dalla stessa tabella variabili. E' inoltre possibile associare dei dati statici (di anagrafica, ossia invariabili nel tempo, timerange e livello) con i soli metadati longitudine, latitudine, identicativo, report

Tabella time range

Definition of the main concepts related to the description of time range and statistical processing for observed and forecast data:

Validity time is defined as the time at which the data are measured or at which forecast is valid; for statistically processed data, the validity time is the end of the time interval.

Reference time is defined as the nominal time of an observation for observed values, or as the time at which a model forecast starts for forecast values.

The date and time in rmap are always the validity date and time of a value, regardless of the value being an observation or a forecast.

  • P1 is defined as the difference in seconds between validity time and reference time. For forecasts it is the positive forecast time. For observed values, the reference time is usually the same as the validity time, therefore P1 is zero. However P1 < 0 is a valid case for reports containing data in the past with respect to the nominal report time.
  • P2 is defined as the duration of the period over which statistical processing is performed, and is always nonnegative. Note that, for instantaneous values, P2 is always zero.

The following table lists the possible values for pindicator and the interpretation of the corresponding values of P1 and P2 specifying a time range:

0 Average
1 Accumulation
2 Maximum
3 Minimum
4 Difference (value at the end of the time range minus value at the beginning)
5 Root Mean Square
6 Standard Deviation
7 Covariance (temporal variance)
8 Difference (value at the beginning of the time range minus value at the end)
9 Ratio
51 Climatological Mean Value
10-191 Reserved
192-254 Reserved for Local Use
200 Vectorial mean
201 Mode
202 Standard deviation vectorial mean
203 Vectorial maximum
204 Vectorial minimum
205 Product with a valid time ranging inside the given period
254 Istantaneous value

Tabella Livello

Level/layer

This table lists the possible values for leveltype1 or leveltype2 and the interpretation of the corresponding numerical value l1 or l2. Leveltype values in the range 0-255 can be used for defining either a single level (leveltype1) or a surface delimiting a layer (leveltype1 and leveltype2) with any meaningful combination of leveltypes; values of leveltype >255 have a special use for encoding cloud values in SYNOP reports and they do not strictly define physical surfaces.

The idea is borrowed from the GRIB edition 2 fixed surface concept and the values for leveltype coincide with the GRIB standard where possible.

leveltype Meaning unit/contents of l1/l2
0 Reserved
1 Ground or Water Surface
2 Cloud Base Level
3 Level of Cloud Tops
4 Level of 0C Isotherm
5 Level of Adiabatic Condensation Lifted from the Surface
6 Maximum Wind Level
7 Tropopause
8 Nominal Top of the Atmosphere
9 Sea Bottom
10-19 Reserved
20 Isothermal Level K/10
21-99 Reserved
100 Isobaric Surface Pa
101 Mean Sea Level
102 Specific Altitude Above Mean Sea Level mm
103 Specified Height Level Above Ground mm
104 Sigma Level
105 Hybrid Level
106 Depth Below Land Surface mm
107 Isentropic (theta) Level K/10
108 Level at Specified Pressure Difference from Ground to Level Pa
109 Potential Vorticity Surface 10-9 K m2 kg-1 s-1
110 Reserved
111 Eta (NAM) Level (see note below) 1/10000
112 116 Reserved
117 Mixed Layer Depth mm
118-159 Reserved
160 Depth Below Sea Level mm
161-191 Reserved
200 Entire atmosphere (considered as a single layer)
201 Entire ocean (considered as a single layer)
204 Highest tropospheric freezing level
206 Grid scale cloud bottom level
207 Grid scale cloud top level
209 Boundary layer cloud bottom level
210 Boundary layer cloud top level
211 Boundary layer cloud layer
212 Low cloud bottom level
213 Low cloud top level
214 Low cloud layer
215 Cloud ceiling
220 Planetary Boundary Layer
222 Middle cloud bottom level
223 Middle cloud top level
224 Middle cloud layer
232 High cloud bottom level
233 High cloud top level
234 High cloud layer
235 Ocean Isotherm Level K/10
240 Ocean Mixed Layer
241 Ordered Sequence of Data
242 Convective cloud bottom level
243 Convective cloud top level
244 Convective cloud layer
245 Lowest level of the wet bulb zero
246 Maximum equivalent potential temperature level
247 Equilibrium level
248 Shallow convective cloud bottom level
249 Shallow convective cloud top level
251 Deep convective cloud bottom level
252 Deep convective cloud top level
253 Lowest bottom level of supercooled liquid water layer
254 Highest top level of supercooled liquid water layer
256 Clouds
257 Information about the station that generated the data
258 (use when ltype1=256) Cloud Data group, L1 = 1 low clouds, 2 middle clouds, 3 high clouds, 0 others
259 (use when ltype1=256) Individual cloud groups, L1 = group number
260 (use when ltype1=256) Cloud drift, L1 = group number
261 (use when ltype1=256) Cloud elevation, L1 = group number; (use when ltype1=264) L2 = swell wave group number
262 (use when ltype1=256) Direction and elevation of clouds, L1 is ignored
263 (use when ltype1=256) Cloud groups with bases below station level, L1 = group number
264 Waves

Tabella variabile ( B table)

B table contents SAMPLE VALUES ONLY ! (the full table is big !) get it from: https://github.com/ARPA-SIMC/dballe/blob/master/tables/dballe.txt


Code Description Units Format
001001 WMO BLOCK NUMBER Numeric 2 digits
001002 WMO STATION NUMBER Numeric 3 digits
001006 AIRCRAFT FLIGHT NUMBER Character 8 chars
001007 SATELLITE IDENTIFIER CODE TABLE 1007 3 chars
001008 AIRCRAFT REGISTRATION NUMBER OR OTHER IDENTIFICATION Character 8 chars
001011 SHIP OR MOBILE LAND STATION IDENTIFIER Character 9 chars
001012 DIRECTION OF MOTION OF MOVING OBSERVING PLATFORM** DEGREE TRUE 3 digits
001013 SPEED OF MOTION OF MOVING OBSERVING PLATFORM* M/S 3 digits
001019 LONG STATION OR SITE NAME Character 32 chars
001023 OBSERVATION SEQUENCE NUMBER Numeric 3 digits
001033 IDENTIFICATION OF ORIGINATING/GENERATING CENTRE CODE TABLE 001033 3 chars
001034 IDENTIFICATION OF ORIGINATING/GENERATING SUB-CENTRE CODE TABLE 001034 3 chars
001063 ICAO LOCATION INDICATOR Character 8 chars
001192 [SIM] MeteoDB station ID Numeric 8 digits
001193 [SIM] Report code Numeric 5 digits
001194 [SIM] Report mnemonic Character 16 chars
001212 AIR QUALITY OBSERVING STATION LOCAL CODE Character 7 chars
001213 AIRBASE AIR QUALITY OBSERVING STATION CODE Character 7 chars
001214 GEMS AIR QUALITY OBSERVING STATION CODE Character 6 chars

Formati

L'accentramento dei dati della rete viene effettuato tramite due passaggi:

  • composizione di un report composto da una selezione di osservazioni (sincrone) di tipo II
  • invio a un concentratore tramite protocollo AMQP

BUFR

Il formato BUFR è definito dal WMO: http://www.wmo.int/pages/prog/www/WMOCodes.html

Nello specifico sono stati selezionati solo alcuni template ed è possibile usare un template denominato "generic" con il quale è possibile l'invio di tutti i dati pubblicati su bus MQTT secondo lo standard rmap.

generic template

TODO


Json

Ogni oggetto json è un report con tutti i dati di una certa stazione per un certo istante di riferimento.

Il formato è JSON Lines text format, chiamato anche newline-delimited JSON http://jsonlines.org/

La stazione è identificata univocamente dai seguenti campi:

  • `ident`: identificativo opzionale della stazione (necessario solo se la stazione è mobile, generalmente nullo per stazioni fisse).
  • `lon`: longitudine
  • `lat`: latitudine
  • `network`: nome della rete a cui appartiene la stazione (minuscolo).

Le latitudini e longitudini devono essere scritte come coordinate geodetiche espresse in sessadecimale, come numero intero dopo aver moltiplicato per 10^5 (quindi espresso in 10^-5 gradi sessadecimali).

L'istante di riferimento è il campo `datetime` (ISO 8601) che si riferisce all'istante finale della misurazione. Di conseguenza, una precipitazione cumulata su 30 minuti con istante di riferimento "2015-08-05T12:00:00Z" è la precipitazione cumulata tra le 11:30:00Z e le 12:00:00Z del giorno 2015-08-05.

I dati sono nel campo `data` sotto forma di array. Ogni elemento dell'array è un oggetto con i seguenti campi:

  • livello: coordinate verticali. Si veda il capitolo dedicato.
  • timerange: definisce il periodo di tempo e l'eventuale processamento (e.g. dato istantaneo, media oraria, etc). Si veda il capitolo dedicato.
  • vars: oggetto i cui campi sono i codici della tabella B locale, i.e. i parametri misurati (vedi tabella relativa). Ognuno di questi è associato ad un oggetto con i campi `v` (il valore) e `a` (oggetto degli attributi del dato, in cui i campi sono altri codici della tabella B a cui è associato un valore).

Tra questi, un solo elemento non ha i campi `level` e `timerange`. Tali dati sono relativi alla stazione (e.g. il nome, l'altezza, etc.)

Esempio

Stazione fissa (`ident: null`) delle rete (`network`) `rer` posizionata nel punto `(9.15454, 4451485)` (`lon`, `lat`) con i seguenti dati (`data`) statici (l'elemento dell'array che non ha `level` e `timerange`):

  • Nome della stazione (`B01019`): "Torriglia"
  • Altezza della stazione (`B07030`): 769.0m
  • Altezza barometrica della stazione (`B07031`): 769.0m

E per l'istante di riferimento "2015-07-30T15:30:00Z" ha registrato i seguenti dati:

  • Al suolo (`level: [1, null, null, null]`) le seguenti cumulate orarie (`timerange: [1, 0, 3600]`):
    • Precipitazione (`B13011`): 0.0
  • A 2m dal suolo (`level: [103, 2000, null, null]`) i seguenti valori istantanei:
    • Temperatura (`B12101`): 297.15K. Il dato è stato invalidato manualmente (attributo `B33196: 1`).
    • Umidità relativa (`B13003`): 50%


   {
       "ident": null,
       "network": "rer",
       "lon": 915454,
       "date": "2015-07-30T15:30:00Z",
       "lat": 4451485,
       "data": [
           {
               "vars": {
                   "B01019": {
                       "v": "Torriglia"
                   },
                   "B07030": {
                       "v": 769.0
                   },
                   "B07031": {
                       "v": 769.0
                   }
               }
           },
           {
               "timerange": [
                   1,
                   0,
                   3600
               ],
               "vars": {
                   "B13011": {
                       "a": {
                       },
                       "v": 0.0
                   }
               },
               "level": [
                   1,
                   null,
                   null,
                   null
               ]
           },
           {
               "timerange": [
                   254,
                   0,
                   0
               ],
               "vars": {
                   "B12101": {
                       "a": {
                           "B33196": 1
                       },
                       "v": 297.15
                   },
                   "B13003": {
                       "a": {
                       },
                       "v": 50
                   }
               },
               "level": [
                   103,
                   2000,
                   null,
                   null
               ]
           }
       ]
   }

Protocolli

L'accentramento dei dati della rete viene effettuato tramite due passaggi:

  • composizione di un report composto da una selezione di osservazioni (sincrone) di tipo II
  • invio a un concentratore tramite protocollo AMQP

Dati e Metadati su MQTT

  • I dati pubblicati nel root path mqtt rmap/ appartengono solo al level type I
  • I dati pubblicati nel root path mqtt report/ appartengono solo al level type II


Stato della connessione

Alla connessione deve essere inviato dalla stazione una eventuale segnalazione di sconnessione gestita male com will (retained):

rmap/IDENT/COORDS/NETWORK/-,-,-/-,-,-,-/B01213"/ 

payload : {"v": "error01"}

poi questo messaggio viene "ricoperto" con:

rmap/IDENT/COORDS/NETWORK/-,-,-/-,-,-,-/B01213"/

payload : { "v": "conn"}

alla disconnessione allo stesso topic verrà inviato il payload:

payload : { "v": "disconn"}

Data e Constant Data

Data

Ogni topic corrisponde ai metadati univoci, mentre il payload è composto dal valore e dall'instante temporale. Json è il formato per il payload.

Forma simbilica del topic:

rmap/IDENT/COORDS/NETWORK/TRANGE/LEVEL/VAR
  • IDENT: identificativo (per stazioni mobili), “-” per stazioni fisse o etichetta non utilizzata
  • COORDS: nella forma lon,lat. Le coordinate sono espresse nell forma int(valore*10^5) con eventuale segno negativo
  • NETWORK: etichetta massimo 16 caratteri
  • TRANGE: nella forma indicator,p1,p2; Indicator e p2 interi senza segno, p1 intero con eventuale segno negativo. “-” per valori non significativi
  • LEVEL: nella forma type1,l1,type2,l2; Type1, type2 interi con eventuale segno negativo, l1e l2 interi con eventuale segno negativo. “-” per valori non significativi
  • VAR: nella forma BXXYYY (come da codice BUFR WMO)

Il payload è in formato JSON: { “v”: VALUE, “t”: TIME, “a”: { “BXXYYY”: VALUE, … } }

  • VALUE: valore in formato CREX
  • TIME: formato YYYY-mm-ddTHH:MM:SS.MSC (secondi e millisecondi opzionali)

Gli attributi (“a”) solitamente per controllo di qualità sono opzionali

Constant Data

I metadati per i dati costanti (anagrafica) sono caratterizzati da questo path:

rmap/IDENT/COORDS/NETWORK/-,-,-/-,-,-,-/ 

con payload simile a quello dei dati, in particolare viene meno la chiave “t”: { “v”: VALUE, “a”: { “BXXYYY”: VALUE, … } }

HTTP

E' possibile utilizzare il protocollo http con una get per inviare i dati; la get http sarà immediatamente convertita dal server in una "pub" al broker mqtt. Http è molto inefficiente rispetto mqtt e qui è utilizzato solo come "bridge" a mqtt quando dovesse essere necessario.

I parametri della get sono:

  • topic il topic mqtt
  • payload il payload mqtt
  • username username dell'utente
  • password password dell'utente
  • time richiede data e ora nella risposta del server

Ad esempio:

http://rmap.cc/http2mqtt/?user=<myuser>&password=<mypassword>&topic=test/-/945000,4530000/<myuser>/1,0,60/1,-,-,-/B13011&payload={"v":0, "t":"2015-07-30T15:30:00"}

Per dati non differiti è possibile omettere "t":"2015-07-30T15:30:00" nel payload.

Se l'invio dei dati ha successo la risposta sarà "OK".

AMQP

Il report dovrà essere scritto nei formati sopra descritti

BUFR messages over AMQP

Messaggi bufr su AMQP

TODO

JSON messages over AMQP

Messaggi json su AMQP

TODO

RMAP web services

Composizione degli URL per un HTTP GET request

La "base" della richiesta è quella standard, i.e.:

/ident/coords/network/timerange/level/bcode/

Ad esempio:

/-/1207738,4460016/locali/254,0,0/103,2000,-,-/B12101

E' l'URL che identifica la misurazione effettuata dalla stazione fissa (`-`) con longitudine 12,07738 e latitudine 44.60016 (`1207738,4460016`) per la rete `locali`; la grandezza misurata è istantanea (`254,0,0`), è stata presa a 2 metri dal suolo (`103,2000,-,-`) ed è una temperatura (`B12101`).

Lettura dei dati

Formati
Json

Vedi nei formati `Json`

Geojson

questo un esempio di `GeoJSON`:


{
 "type": "FeatureCollection",
 "features": [
   {
     "geometry": {
       "type": "Point",
       "coordinates": [
         10.26667,
         46.81667
       ]
     },
     "type": "Feature",
     "properties": {
       "date": "2011-01-25T00:00:00",
       "level": [103,2000,null,null],
       "ident": null,
       "network": "locali",
       "bcode": "B12101",
       "value": 263.75,
       "trange": [254,0,0]
     }
   },
   ...
}
Serie temporale

Serie temporale mensile, giornaliera e annuale:

/ident/coords/network/timerange/level/bcode/timeseries/year
/ident/coords/network/timerange/level/bcode/timeseries/year/month
/ident/coords/network/timerange/level/bcode/timeseries/year/month/day

Ad esempio:


/-/1207738,4460016/locali/254,0,0/103,2000,-,-/B12101/timeseries/2011
/-/1207738,4460016/locali/254,0,0/103,2000,-,-/B12101/timeseries/2011/01
/-/1207738,4460016/locali/254,0,0/103,2000,-,-/B12101/timeseries/2011/01/13
Serie spaziale

Serie spaziale di una rete, con granularità oraria (± 30 minuti):

/*/*/<network>/<pind>,<p1>,<p2>/<lt1>,<l1>,<lt2>,<l2>/<bcode>/spatialseries/<year>/<month>/<day>/<hour>

Il formato di uscita è il `GeoJSON` usato nella serie temporale.

Riassuntivo

Riassuntivo di tutto il database:

/*/*/*/*/*/*/summaries


Riassuntivo di una stazione (fissa o mobile):

/-/<lon>,<lat>/<network>/*/*/*/summaries
/<ident>/*/<network>/*/*/*/summaries


Riassuntivo di una misurazione in un dato mese:

/*/*/<network>/<pind>,<p1>,<p2>/<lt1>,<l1>,<lt2>,<l2>/<bcode>/summaries/<year>/<month>

Anagrafica

/-/<lon>,<lat>/<network>/-,-,-/-,-,-,-/*/stationdata
/<ident>/*/<network>/-,-,-/-,-,-,-/*/stationdata

La risposta è in `GeoJSON` ed analoga a quella dei dati.

Versioning

Le `API` avranno come prefisso la versione in uso.

Ad esempio, serie temporale mensile usando la versione 0.1:

curl http://api.borinud.arpa.emr.it/v0.1/-/1120000,4450000/generic/254,0,0/103,2000,-,-/B12101/timeseries/2013/09