It could be worse, it could be raining: reliable automatic meteorological forecasting

TL;DR

This paper introduces MeteoLOG, a logic-based framework combining fuzzy, temporal, and probabilistic logics to automate meteorological forecasting, especially useful for handling large data sets and underpopulated areas.

Contribution

It presents MeteoLOG, a novel logic framework for automated weather prediction, and the Tournament algorithm for translating rules into defeasible theories.

Findings

MeteoLOG effectively models forecasting reasoning processes.

The Tournament algorithm enables automatic rule-based reasoning.

Application example demonstrates real-world forecasting scenario.

Abstract

Meteorological forecasting provides reliable prediction about the future weather within a given interval of time. Meteorological forecasting can be viewed as a form of hybrid diagnostic reasoning and can be mapped onto an integrated conceptual framework. The automation of the forecasting process would be helpful in a number of contexts, in particular: when the amount of data is too wide to be dealt with manually; to support forecasters education; when forecasting about underpopulated geographic areas is not interesting for everyday life (and then is out from human forecasters' tasks) but is central for tourism sponsorship. We present logic MeteoLOG, a framework that models the main steps of the reasoner the forecaster adopts to provide a bulletin. MeteoLOG rests on several traditions, mainly on fuzzy, temporal and probabilistic logics. On this basis, we also introduce the algorithm Tournament, that transforms a set of MeteoLOG rules into a defeasible theory, that can be implemented into an automatic reasoner. We finally propose an example that models a real world forecasting scenario.

Figures

Full text

1 Introduction

In the last ten years or so, meteorological forecasting has become a commonly required web service and meteorological forecasting websites are nowadays one of the most expensive websites for advertisement. Producing a meteorological forecast is, however, an expert task to perform. It is a human activity that is typically provided as a partially automated pipeline in which a first step consists in generating models of the evolution of the weather in a given geographic area. These models are often not directly accessible online because of their sizes, so the forecaster relies on the execution of a sophisticated reasoning on the data, comparing the models and evaluating the confidence degree in a range of possibilities compatible with the models themselves.

Although this process is an expert one, and it is driven by heuristic knowledge of the domain, there exist some traits of the reasoning method that are systematic, and used in force of the nature of the domain itself. In other words, there exists a specific form of meteorological reasoning consisting in the pipeline described above, and possibly in other collateral steps including cmpaison with real world data against models, and local methods used to provide the inference as terms of comparison in the range itself.

The computer technologies currently available don’t satisfy the requirements of quality in general application configurations. In this paper, we investigate how to simulate the behavior of a meteorologist in this processes, in an extended way with respect to what has been done in various previous studies, and specifically inspired by the approach followed by Ramos-Soto et al. [27].

In particular the current technologies suffer from a number of severe drawbacks: (i) They are based on the crisp interpretation of one single model so that the reliability depends on that model; (ii) They refer to vast areas and tend to infer forecasting of smaller areas without considerations of the local effects; (iii) They sometimes include extreme simplifications of the forecast itself, providing information in graphical terms and thus unifying complex judgments into single ones.

It therefore make senses to envision an automated expert technology able to support or even substitute the forecaster in many use cases, including: (i)  As a learning tool: when an expert forecaster helps students, or newbies at the workplace, to become experts of the pipeline mentioned above, it would be beneficial to provide a learning environment simulating reasonably correct forecasts. (ii)  As a decision support system: comparing human decisions where the level of confidence is not particularly high with decisions made by an AI tool would help the forecaster in providing a better forecast. (iii)  When forecasting is not sustainable: an AI tool may substitute entirely humans when the requested forecasting is too finely associated with territory portions. The latter is the main motivation behind our research.

We aim at defining an AI tool for meteorological forecasting that could be applied to real-world situations in which the tourism flow is not intense enough to make the employment of human forecasters acceptable from a business viewpoint, whilst an automated tool, which provides the forecasting, albeit possibly in a not particularly accurate way, would be beneficial.

We use non monotonic reasoning and make thus possible to accommodate conflicting rules in the system, so that the process of decision making not only results fuzzy, but is also subject to revisions and constrained by confidence; To better explain what we focus upon, consider the following example of a specific situation managed by the framework that we devise here.

Example 1

Let us consider a remote area, such as a small island in the middle of the Pacific Ocean. This island has a limited tourism flow and it is thus unlikely that forecasting by authorities on the island itself would be provided. Hence, the level of forecasting is derived by mid-scale models on the Ocean that are very unreliable for this and other small islands. In this island, however, there is a satellite high-speed Internet connection and thus a web server can be installed. Moreover, on the island’s coasts and its sole mountain, there exist a group of wind and rain sensors connected to the server through a network. It is therefore possible to install a sophisticated technology that makes a forecast available through a web service to the tourists interested in visiting the island.

We proceed as follows. In Section 2 we introduce the architecture of our framework. In Section 3 we describe the logic and the algorithm we use to produce input rules for a reasoner that will derive a weather scenario; we also describe the steps behind the release of the final weather bulletin. Section 4 is devoted to a real-world example. In Section 6 we discuss related work, and in Section 7 we draw conclusions.

2 System architecture

The system aim is to produce a better weather forecast, given meteorological models and data gathered from the field, as summarized in Figure 1. Figure 2 shows the logic model of the system architecture, which comprises several modules, each one with a single responsibility as described below.

Source Forecast Map:

this module aims at the retrieval of raw informations form a specific source (i.e., Temperature, Humidity, …) connecting to a sensor network or a data source. To add a new source to the system (e.g., Sea Status) one will need to extend only the implementation of this module. The output of this module is a “source forecast map”

Tournament:

this module takes as input source forecast maps and their accuracy and fragility data, and gives forecast rules to be examined by the Reasoner; see Section 0..0.1 for an informal description of the algorithm.

Decision Maker:

this module decides which model will give best performances and is thus the actual core of the system.

Reasoner:

this module is the “brain” of the system as it applies our deduction system to make decisions about which forecast draft is the “best one”.

Knowledge base:

this is where the knowledge base is stored; the Reasoner will access it for reasoning and the Decision Maker will increment it after the evaluation of the results of the reasoner.

Sharp Forecast:

this module provides a mapping from quantitative forecasting (numerical) to qualitative forecasting (words); see Section 3.3.1 for details.

Smooth Forecast:

this module transforms the forecasting expressed in words into natural language sentences suitable to be delivered to the public; see Section 3.3.2 for details.

Bulletin generator:

this module provides visualization of all data, building the output of the system as a “pdf” file or a hypertext.

3 A defeasible reasoner for meteorological forecasting

What is commonly intended as “weather forecasting” can be logically model as a conclusion the forecaster derives from a set of premises, by the application of some (both deductive and empirical) rules.

3.1 The logic $\mathsf{MeteoLOG}$

The reasoning process of the weather forecaster is formally built upon technical steps implementing the workflow described in Section 2. In this section, we develop a logical framework called $\mathsf{MeteoLOG}$, that formalizes the hybrid reasoning at the basis of meteorological forecasting. $\mathsf{MeteoLOG}$, informally introduced in [6], benefits from three standard logical approaches: defeasible logic [15], labeled deduction systems [22, 29, 30, 7] and fuzzy/non-deterministic/probabilistic frameworks [10, 2].

We introduce the syntax of formulae and of labels, along with a notion of prevalence, which imports a defeasible flavour into the system. We also provide an intuitive description of the label-elimination algorithm Tournament, which represents the basis of the reasoning process that we develop below.

In this paper, we only deal with ground formulas modeling meteorological forecasting values, which we will call Assertional Maps (AMs). AMs provide quantitative information and they represent the basic piece of knowledge used for forecasting. In the real world, they are collected worldwide, from different forecasting sites and through a number of different technologies. The internationally accepted set of numerical weather conditions revealed in AMs concerns: Temperature, Pressure, Humidity, Snowfalls, Wind, Precipitations, Visibility.

From an abstract viewpoint, AMs express rough assertions about weather to be processed and evaluated. They are simply represented by suitable predicates on space-time coordinates pointing out a numerical weather condition, expressed in a suitable measuring system. In particular, the temperature is expressed in graders, pressure is expressed in HPa, humidity in percentage, rains are expressed in millimetres, snowfalls in centimetres, visibility is expressed in metres, Wind in Knots, Cloudiness (C) in percentage .

Formally, an AM is a five-ary predicate $Q(x,y,z,\tau^{r},q)$, where Q is a numerical weather condition, $x$, $y$ and $z$ represent geographic coordinates, $\tau^{r}$ represents the forecasting time (the interval of the validity of the assertion) and $q$ is the effective revealed value, represented by a 2-dimensional vector $(v,d)$, where $v$ is the numerical value and $d$ is the direction. For instance, $\mathit{Rain}(45.43,11.80,06/04/2018,\mbox{14:05:00}\mathit{CET},5\mathit{mm})$ represents that the assertion $\mathit{Rain}$ on ground level, point of measure $(45.43,11.80)$ on GPS coordinates, on $06/04/2018$ at 14:05:00 $\mathit{CET}$ was 5 millimetres.

Since we are interested in the reasoning process behind the forecasting, we now focus on models experts apply to derive information from AM. We formalize such methods and related notions by means of labels, and import into the formulas additional information such as the precision of the method and the detection time (the instant in which the method has been applied to generate the map). This information is crucial for the forecaster’s work, since the choice of the (as much as possible) correct maps is mainly based on methodological information.

Labeled Assertional Maps (LAMs) are obtained by labelling AMs. This formally models the additional information the forecaster have to evaluate and decide if a rough AM expressing a prediction is admissible for forecasting or not.

Labels represent contextualised methods, i.e., a forecasting method applied to a data gathering sample, performed in a given instant of time, weighted with an some accuracy information; they are pairs of the kind $\langle\lambda,\tau^{t}\rangle$, where $\lambda$ represents a model and $\tau$ represents the instant in which the map has been generated.

Each method can be associated with an accuracy value $\lambda.a$, a function that extracts the accuracy information from the method $\lambda$.

An LAM is then a labeled formula $\langle\lambda,\tau^{t}\rangle:Q(x,y,z,\tau^{r},q)$.

Labeled ground formulas that express numerical weather conditions  permits to compare different formulas expressing the same forecasting concept on the basis of different methods and time. Some priority rules allow us to decide what set of sources is the more reliable one. As explained in the following, we will use some priority rules to order AMs, in order to eliminate the ones that do not overcome a given threshold of reliability.

We introduce now some relation between labels. This step also imports a defeasible behaviour in the system.There are two main kind of priority relation. The first one, called here quantitative or algorithmic priority, simply automatically check and compare labeled assertions on the basis of their quantitative information (accuracy and time). $\langle\lambda_{1},\tau_{1}\rangle:Q_{1}(x,y,z,\tau^{r},q_{1})\succ\langle\lambda_{2},\tau_{2}\rangle:Q_{2}(x,y,z,\tau^{r},q_{2})$, with $Q_{1}=Q_{2}$ holds in one of the following cases:

$\lambda_{1}.a>\lambda_{2}.a$; 2. 2.

$\lambda_{1}.a=\lambda_{2}.a$ and $\tau_{1}<\tau_{2}$

Notice that more accurate model-based assertions always (quantitatively) prevails, and, up to equal accuracy, prevails the most recent LAM.

Given a set of LAM, each assertional maps is weighted according to the relations described above and the whole set is ordered as a consequence.

The second kind of priority relation is called experience-based or specific, and models the empirical knowledge of the expert of the domain.

Following the real world setting, we state that a specific priority always prevails on an algorithmic one (w.r.t. the same assertion).

Having defined the syntax of $\mathsf{MeteoLOG}$, we are currently working at the definition of a suitable semantics and a natural deduction system [26, 3] for $\mathsf{MeteoLOG}$.

3.2 The Tournament algorithm

Tournament is an algorithm whose aim is to return a a defeasible theory, given an ordered set of Metarules, a set of accuracies and actual time. Informally, the algorithm maps $assertions$ into defeasible rules and facts; when it finds possible conflicts it generates a set of defeasible conflicting rules and then, using the accuracy information, it generates the priority rules to solve the conflict so that the method with best accuracy prevails; in case of even accuracy, the latest LAM prevails.

Once a set of LAMs has been collected and an accuracy set has been acknowledged, our Tournament algorithm starts with a sifting action on the set of labeled assertions. First, it discharges LAMs that are out of date. Second, it orders LAMs on the basis of priorities, obtaining some AM for each numerical weather condition we are interested in. This operation corresponds to a label-elimination: once priorities have been derived, the majority of information about the forecasting method became useless. As an output of this step, we obtain a set of defeasible rules to be given as input to the Reasoner, which will derive a set of numerical weather condition also called a weather scenario. Priorities of these generated defeasible conflicting rules are given by a function (named “supremacy”) that takes into account two conflicting rules so that, depending on this function definition, the resulting output can differ from both source rules. The pseudocode of the Tournament algorithm is in Appendix 0..0.1

3.3 Weather Forecasting Reasoning

Forecasting reasoning can be divided into three steps: (i) the quantitative forecasting (invisible to the final user) the reasoner generates; (ii) the qualitative forecasting (also invisible to the final user) called in the following sharp forecasting; i(ii) the qualitative, natural language based forecasting destined to the final user, called in the following smoothed forecasting. Between the first two phases, a mapping between data and a suitable forecasting lexicon occurs.

3.3.1 From data to pre-bulletin: Sharp Forecasting

Once the final set of reliable assertional maps has been collected, the forecaster can proceed with data analysis and the releasing of the weather bulletin. Meteorological conditions represent a crucial step of the forecasting reasoning. The internationally accepted ranges for meteorological conditions are shown in Figure 3. To each value of the range a precise interval in a suitable measure scale can be associated.

3.3.2 The weather forecasting lexicon: smoothed forecasting

Every one has a wide experience in weather forecasting as a final user. It is well known that weather bulletins are offered in a friendly form. For example, if the forecaster deduces that the probability that tomorrow it will rain is very small, she doesn’t release the assertion “$\mathit{Rain}(45.43,11.80,06/04/2018,\mbox{14:05:00}\mathit{CET},5\mathit{mm})$ with probability $15\%$” but the understandable natural language sentence “partially cloudy, possible scattered rains”. This final step provides a “smoothing” phase to the output of the previous one in which some adjectives can be added to give evidence to the uncertainty of the event. We don’t fully model this final step of weather forecasting; nonetheless, in our reference implementation we propose an example of a possible automatisation of the human task, leaving the full development for future work (see Section 7).

4 Reference Implementation

To illustrate concretely how our approach can fit a real-life scenario, let us consider a weather forecast considering the seaside part of Veneto, our region, which is located in the north-east of Italy and albeit being not a remote area it exploits several neighbor small touristic places.

For the sake of space, but without loss of generality, we limit the weather forecast to cloud, wind and sea conditions and to only three points; we label these points North, South and Center, the latter representing roughly the position of the famous city of Venice (see Figure 4). Sea Conditions have only one point, representing the sea in the area. We use only two forecasting maps and we limit the time-frame to only two values, representing two and one days after the present: respectively $t_{2},t_{1},t_{0}$ We have as input two forecasting sources, coming from different forecasting models such as IFS (also known as ECMWF for European Center Medium Weather Forecast) and GFS (Global Forecast System), plus the map of observations.

The first source obtained with the GFS prevision model asserts, using $N$ for $form~{}North$ and $E$ for $form~{}East$,at time $t_{0}$

$North:\{cloudiness:90\%,Wind:18knots~{}N\}$

$Center:\{cloudiness:90\%,Wind:18knots~{}N\}$

$South:\{cloudiness:90\%,Wind:10knots~{}N,\}Sea:190cm~{}wave$

at time $t_{1}$

$North:\{cloudiness:90\%,Wind:8knots~{}N\}$

$Center:\{cloudiness:90\%,Wind:8knots~{}E\}$

$South:\{cloudiness:90\%,Wind:5knots~{}E,\}Sea:100cm~{}wave$

at time $t_{2}$

$North:\{cloudiness:90\%,Wind:8knots~{}N\}$

$Center:\{cloudiness:90\%,Wind:8knots~{}E\}$

$South:\{cloudiness:90\%,Wind:5knots~{}E,\}Sea:100cm~{}wave$

The second source obtained with ECMWF asserts, at time $t_{0}$

$North:\{cloudiness:90\%,Wind:15knots~{}NE\}$

$Center:\{cloudiness:90\%,Wind:15knots~{}NE\}$

$South:\{cloudiness:90\%,Wind:15knots~{}NE,\}Sea:160cm~{}wave$

at time $t_{1}$

$North:\{cloudiness:75\%,Wind:5knots~{}NE\}$

$Center:\{cloudiness:75\%,Wind:5knots~{}NE\}$

$South:\{cloudiness:75\%,Wind:5knots~{}N,\}Sea:90cm~{}wave$

at time $t_{2}$

$North:\{cloudiness:30\%,Wind:5knots~{}N\}$

$Center:\{cloudiness:30\%,Wind:5knots~{}N\}$

$South:\{cloudiness:30\%,Wind:5knots~{}N,\}Sea:50~{}wave$

The observation map, which only relates data at $t_{0}$ states that

$North:\{cloudiness:90\%,Wind:15knots~{}NE\}$

$Center:\{cloudiness:90\%,Wind:15knots~{}NE\}$

$South:\{cloudiness:90\%,Wind:15knots~{}NE,\}Sea:190cm~{}wave$

We know from knowledge experts that ECMWF has a better accuracy than GFS: numerically $a(ECMWF,t_{1})=0.85$, $a(ECMWF,t_{2})=0.80$ , $a(GFS,t_{1})=0.45$, $a(GFS,t_{2})=0.40$. These assertions, using “E” for ECMWF, “G” for GFS, “O” for observation and “C” for “cloudiness”, “W” for “wind” and “S” for “sea conditions” can be represented in our formalism as

[TABLE]

This is therefore our set of metarules, so after the Translator has done its elaboration using algorithm described in 0..0.1 we can have:

[TABLE]

Given this theory, the Reasoner concludes $+\partial CN{t_{1}}78$, $+\partial CC{t_{1}}78$, $+\partial CS{t_{1}}78$, $+\partial WN{t_{1}}NE6$, $+\partial WC{t_{1}}NE6$, $+\partial WS{t_{1}}N5$, $+\partial Sea_{t_{1}}65$,$+\partial CN{t_{2}}38$, $+\partial CC{t_{2}}38$, $+\partial CS{t_{2}}38$, $+\partial WN{t_{2}}N6$, $+\partial WC{t_{2}}N6$, $+\partial WS{t_{2}}N5$, $+\partial Sea_{t_{2}}20$.

Therefore, translating numerical value into words, we have at at time $t_{1}$

[TABLE]

and at time $t_{2}$

[TABLE]

which can be expressed iconographically as in Figure 5.

5 SPINdle

One the Tournament algorithm described in the paper produced a defeasible theory, we can process the theory by means of well-established reasoning technologies, such as Spindle. SPINdle is a logic reasoner that can be used to compute the consequence of defeasible logic theories in an efficient and it can be downloaded at http://spindle.data61.csiro.au/spindle/.

5.1 Spindle conclusions for rules of the reference implementation

---

• SPINdle (version 2.2.4) *
• Copyright (C) 2009-2014 NICTA Ltd. *
• This software and its documentation is distributed under the terms of the *
• FSF Lesser GNU Public License (LGPL). *

•                                                                       *
  

• This program comes with ABSOLUTELY NO WARRANTY; This is a free software *
• and you are welcome to redistribute it under certain conditions; for *
• details type: *
• java -jar spindle-<version>.jar --app.license *

---

========================= == application start!! ==

Initialize application context - start load application configuration - start app.showProgress=false app.showStatistics=false reasoner.version=2 load application configuration - end configurating I/O classes - start generating outputter [spindle.io.outputter.DflTheoryOutputter]...success, type=[dfl] generating outputter [spindle.io.outputter.XmlTheoryOutputter2]...success, type=[xml] generating parser [spindle.io.parser.DflTheoryParser2]...success, type=[dfl] generating parser [spindle.io.parser.XmlTheoryParser2]...success, type=[xml] configurating I/O classes - end Initialize application context - end === System info: Load theory from url: file:/temp/Meteo_SPINDLE_RULES === System info: Theory loaded successfully, theory type: SDL. === System info: Theory contains no literal variable or boolean function. === System info: transform theory to regular form === System info: Generate conclusions. === System info: Conclusions. +D CEt090(X) +D CNt090(X) +D CSt090(X) +D Seaot0190(X) +D WCt0NE15(X) +D WNt0NE15(X) +D WSt0NE15(X) +D Wo_t0_5(X) -D CCet175(X) -D CCet190(X) -D CCet230(X) -D CCgt090(X) -D CCgt190(X) -D CCgt290(X) -D CCt178(X) -D -CCt178(X) -D CCt188(X) -D -CCt188(X) -D CCt238(X) -D -CCt238(X) -D CCt268(X) -D -CCt268(X) -D CNet175(X) -D CNet190(X) -D CNet230(X) -D CNgt090(X) -D CNgt190(X) -D CNgt290(X) -D CNt178(X) -D -CNt178(X) -D CNt188(X) -D -CNt188(X) -D CNt238(X) -D -CNt238(X) -D CNt268(X) -D -CNt268(X) -D CSet175(X) -D CSet190(X) -D CSet230(X) -D CSgt090(X) -D CSgt190(X) -D CSgt290(X) -D CSt178(X) -D -CSt178(X) -D CSt188(X) -D -CSt188(X) -D CSt238(X) -D -CSt238(X) -D CSt268(X) -D -CSt268(X) -D Seaet0160(X) -D Seaet150(X) -D Seaet210(X) -D Seagt0190(X) -D Seagt1100(X) -D Seagt2100(X) -D Seat165(X) -D -Seat165(X) -D Seat195(X) -D -Seat195(X) -D Seat220(X) -D -Seat220(X) -D Seat280(X) -D -Seat280(X) -D WCet1NE5(X) -D WCet2N5(X) -D WCgt0N18(X) -D WCgt1E8(X) -D WCgt2E8(X) -D WCt1E7(X) -D -WCt1E7(X) -D WCt1NE6(X) -D -WCt1NE6(X) -D WCt2N6(X) -D -WCt2N6(X) -D WCt2NE7(X) -D -WCt2NE7(X) -D WNet1NE15(X) -D WNet1NE5(X) -D WNet2N5(X) -D WNgt0N18(X) -D WNgt1N8(X) -D WNgt2N8(X) -D WNt1N7(X) -D -WNt1N7(X) -D WNt1NE6(X) -D -WNt1NE6(X) -D WNt2N6(X) -D -WNt2N6(X) -D WNt2NE7(X) -D -WNt2NE7(X) -D WSet1N5(X) -D WSet1NE5(X) -D WSet2N5(X) -D WSgt0N10(X) -D WSgt1E5(X) -D WSgt2E5(X) -D WSt1E5(X) -D -WSt1E5(X) -D WSt1N5(X) -D -WSt1N5(X) -D WSt2N5(X) -D -WSt2N5(X) -D WSt2NE5(X) -D -WSt2NE5(X) +d CCet175(X) +d CCet190(X) +d CCet230(X) +d CCgt090(X) +d CCgt190(X) +d CCgt290(X) +d CCt178(X) +d -CCt188(X) +d CCt238(X) +d -CCt268(X) +d CEt090(X) +d CNet175(X) +d CNet190(X) +d CNet230(X) +d CNgt090(X) +d CNgt190(X) +d CNt090(X) +d CNt178(X) +d -CNt188(X) +d CSet175(X) +d CSet190(X) +d CSet230(X) +d CSgt090(X) +d CSgt190(X) +d CSgt290(X) +d CSt090(X) +d CSt178(X) +d -CSt188(X) +d CSt238(X) +d -CSt268(X) +d Seaet0160(X) +d Seaet150(X) +d Seaet210(X) +d Seagt0190(X) +d Seagt1100(X) +d Seagt2100(X) +d Seaot0190(X) +d Seat165(X) +d -Seat195(X) +d Seat220(X) +d -Seat280(X) +d WCet1NE5(X) +d WCet2N5(X) +d WCgt0N18(X) +d WCgt1E8(X) +d WCgt2E8(X) +d WCt0NE15(X) +d -WCt1E7(X) +d WCt1NE6(X) +d WCt2N6(X) +d -WCt2NE7(X) +d WNet1NE15(X) +d WNet1NE5(X) +d WNet2N5(X) +d WNgt0N18(X) +d WNgt1N8(X) +d WNgt2N8(X) +d WNt0NE15(X) +d -WNt1N7(X) +d WNt1NE6(X) +d WNt2N6(X) +d -WNt2NE7(X) +d WSet1N5(X) +d WSet1NE5(X) +d WSet2N5(X) +d WSgt0N10(X) +d WSgt1E5(X) +d WSgt2E5(X) +d WSt0NE15(X) +d -WSt1E5(X) +d WSt1N5(X) +d WSt2N5(X) +d -WSt2NE5(X) +d Wo_t0_5(X) -d -CCt178(X) -d CCt188(X) -d -CCt238(X) -d CCt268(X) -d CNgt290(X) -d -CNt178(X) -d CNt188(X) -d CNt238(X) -d -CNt238(X) -d CNt268(X) -d -CNt268(X) -d -CSt178(X) -d CSt188(X) -d -CSt238(X) -d CSt268(X) -d -Seat165(X) -d Seat195(X) -d -Seat220(X) -d Seat280(X) -d WCt1E7(X) -d -WCt1NE6(X) -d -WCt2N6(X) -d WCt2NE7(X) -d WNt1N7(X) -d -WNt1NE6(X) -d -WNt2N6(X) -d WNt2NE7(X) -d WSt1E5(X) -d -WSt1N5(X) -d -WSt2N5(X) -d WSt2NE5(X)

==================================== == Performance statistics summary ==

== I/O classes configuration time used: 32 ms == No. of record(s) found: 1 == --- start

+------------+------------+-----------------+-----------------+-----------------+-----------------+-----------------+-------------+----- | No. of | No. of | Time used on | Time used on | Time used on | Time used on | Total time | Max. Memory | | Rules | Literals | loading theory | transform theory| remove defeater | reasoning | used | used | filename +------------+------------+-----------------+-----------------+-----------------+-----------------+-----------------+-------------+----- | 105 | 105 | 0,069 sec | 0,006 sec | 0,000 sec | 0,035 sec | 0,110 sec | 9,63 MB | file:/temp/Meteo_SPINDLE_RULES +------------+------------+-----------------+-----------------+-----------------+-----------------+-----------------+-------------+----- == --- end

Calling the shutdown routine... Terminate application context - start Terminate application context - end

=== Application shutdown completed! ===

6 Related work

Since the pioneering studies [5, 9, 23] and further engineering investigations on the commercial solutions [24], a first attempt going in the same direction that we following in this paper appeared in the 1990s [13] and inspired many specialized studies [19, 21, 17, 12, 4, 20, 10, 11]. The ontological approach and the usage of the Internet of Things have been applied to forecasting quite recently [1, 18] and we acknowledge that the main technical inspirations of our framework trace back these works, whereas the main influences come from the usage of non-monotonic deduction systems for sensor-based applications (clearly related to the initial part of the forecasting process) [28, 8], and non-monotonic reasoning[16, 25, 14, 15].

7 Conclusions

In this paper, we proposes an architecture to support meteoroligists in producing weather forecasts. The basic work is a reasoning framework able to simulate in a quite refined way the decision process made by the forecasters in producing weather bulletins. There are several ways of extending this study. The research team includes a forecaster of the ARPA Veneto weather forecasting service, one of the most valuable forecasting service in Italy, who will lead the development of both the definition of the supremacy function and the Tournament algorithm.

We are currently working at the full formal definition the logical framework $\mathsf{MeteoLOG}$. We plan to include more specific features in order to improve the precision of the automatic bulletin, aiming to a completely automatic and (potentially) unsupervised bulletin generator.

0..0.1 The Tournament algorithm

A certain rule is a candidate for rewriting, only if the synchroniser acknowledged that its clock time falls within the validity interval of the rule (if the rule has a validity interval) or at the exact instant of the rule if the rule is simply instantaneous.

Appendix 0.A Another example

We would like make an example of a weather forecast considering our region, located in the north eastern part of Italy, to give a better evidence of how our model can fit a real life scenario. For the sake of space we will make some limitations: we limit the weather forecast to rain conditions and to only four points; we will label these points North, East ,South, West. We will use only two forecasting maps and we we will limit the time frame to only two values, representing two and one day after the present: respectively $t_{2},t_{1},t_{0}$

We have as input two forecasting sources, coming from different forecasting models such as IFS (also known as ECMWF for European Center Medium Weather Forecast) and GFS (Global Forecast System), plus the map of observations. The first source obtained with the GFS prevision model asserts, at time $t_{0}$ $\{North=5mm,East=4mm,South=4mm,West=4mm\}$, at time $t_{1}$ $\{North=4mm,East=4mm,South=4mm,West=5mm\}$, at time $t_{2}$ $\{North=6mm,East=6mm,South=6mm,West=6mm\}$. The second source obtained with the ECMWF prevision model asserts, at time $t_{0}$ $\{North=5mm,East=5mm,South=5mm,West=5mm\}$, at time $t_{1}$ $\{North=24mm,East=14mm,South=24mm,West=24mm\}$, at time $t_{2}$ $\{North=16mm,East=16mm,South=16mm,West=16mm\}$. The observation map, which only relates data at $t_{0}$ states that $\{North=5mm,East=5mm,South=5mm,West=5mm\}$.

We know from knowledge experts that ECMWF has a better accuracy than GFS: numerically $a(ECMWF,t_{1})=0.85$, $a(ECMWF,t_{2})=0.80$ , $a(GFS,t_{1})=0.45$, $a(GFS,t_{2})=0.40$

These assertions, using “E” for ECMWF, “G” for GFS, “O” for observation and “R” for “rain” can be represented as

[TABLE]

This is therefore our set of metarules, so after the Translator has done its elaboration using algorithm described in 0..0.1 we can have:

[TABLE]

[TABLE]

[TABLE]

[TABLE]

Given that theory, the Reasoner concludes $+\partial N{t_{1}}21$, $+\partial E{t_{1}}21$, $+\partial S{t_{1}}21$, $+\partial W{t_{1}}21$, $+\partial~{}\neg N{t_{1}}7$, $+\partial~{}\neg E{t_{1}}7$, $+\partial~{}\neg S{t_{1}}7$, $+\partial~{}\neg W{t_{1}}7$, $+\partial N{t_{2}}14$, $+\partial E{t_{2}}14$, $+\partial S{t_{2}}14$, $+\partial W{t_{2}}14$, $+\partial~{}\neg N{t_{2}}8$, $+\partial~{}\neg E{t_{2}}8$, $+\partial~{}\neg S{t_{2}}8$, $+\partial~{}\neg W{t_{2}}8$.

Given that, translating numerical value into words, we have at $t_{1}$ that $\{$ North=Heavy Rain, East=Rain,South=Heavy Rain, West=Heavy Rain $\}$ while at time $t_{2}$ $\{$ North=Strong Rain, East=Strong Rain,South=Possible Showers, West=Possible Showers $\}$ which translates in the following figures.

[TABLE]

0.A.1 Spindle conclusions for rules of the reference implementation

---

• SPINdle (version 2.2.4)
• Copyright (C) 2009-2013 NICTA Ltd. ......
• java -jar spindle-<version>.jar --app.license

---

========================= == application start!! ==

Initialize application context - start .....

...... +d E_t0_5(X) +d E_t1_14(X) +d E_t1_21(X) +d -E_t1_7(X) +d E_t1_8(X) +d Ee_t0_5(X) +d Ee_t1_24(X) +d Ee_t2_16(X) +d Eg_t0_4(X) +d Eg_t1_4(X) +d Eg_t2_6(X) +d N_t0_5(X) +d N_t1_14(X) +d N_t1_21(X) +d -N_t1_7(X) +d N_t1_8(X) +d Ne_t0_5(X) +d Ne_t1_24(X) +d Ne_t2_16(X) +d Ng_t0_4(X) +d Ng_t1_4(X) +d Ng_t2_6(X) +d S_t0_5(X) +d S_t1_14(X) +d S_t1_21(X) +d -S_t1_7(X) +d S_t1_8(X) +d Se_t0_5(X) +d Se_t1_24(X) +d Se_t2_16(X) +d Sg_t0_4(X) +d Sg_t1_4(X) +d Sg_t2_6(X) +d W_t0_5(X) +d W_t1_14(X) +d W_t1_21(X) +d -W_t1_7(X) +d W_t1_8(X) +d We_t0_5(X) +d We_t1_24(X) +d We_t2_16(X) +d Wg_t0_4(X) +d Wg_t1_4(X) +d Wg_t2_6(X) -d -E_t1_14(X) -d -E_t1_21(X) -d E_t1_7(X) -d -E_t1_8(X) -d E_t2_14(X) -d E_t2_8(X) -d -N_t1_14(X) -d -N_t1_21(X) -d N_t1_7(X) -d -N_t1_8(X) -d N_t2_14(X) -d N_t2_8(X) -d -S_t1_14(X) -d -S_t1_21(X) -d S_t1_7(X) -d -S_t1_8(X) -d S_t2_14(X) -d S_t2_8(X) -d -W_t1_14(X) -d -W_t1_21(X) -d W_t1_7(X) -d -W_t1_8(X) -d W_t2_14(X) -d W_t2_8(X)

Calling the shutdown routine... Terminate application context - start Terminate application context - end

=== Application shutdown completed! ===