Anna Weeks
email: anna.weeks@depi.vic.gov.au

Malcolm Mccaskill
email: malcolm.mccaskill@depi.vic.gov.au

Matthew Cox
email: matthew.cox@depi.vic.gov.au

Subhash Sharma
email: subhash.sharma@depi.vic.gov.au

An SMS and Email Weather Warning System for Sheep Producers

Keywords: Sheep, forecast skill, evaluation, chill index

Sheep are vulnerable to hypothermia shortly after birth and shearing. Since the 1970's sheep weather alerts have been reported at a regional scale by the media up to 24 hours prior to a chill event. The SMS and email weather warning system was designed as an enhanced service to provide sheep producers with advanced warnings of forth-coming chill events, based on local weather forecasts, with personalized chill warnings delivered by SMS and email. A trial was conducted with 30 sheep producers who selected one or more local weather stations and a low, medium or high sensitivity threshold to control the frequency at which messages were sent. Sensitivity thresholds were calculated for each weather station from historical data. Numerical forecast data were sourced from the Bureau of Meteorology, and an email and SMS sent each morning whenever forecast chill exceeded the warning threshold within the 7day forecast period. Participants were interviewed by telephone after a 2-month trial. The alerts were found to be clear and reasonably accurate, but produced an unexpected high number of false warnings at some sites. The SMS format was well received, and farmers were generally happy to continue the trial. False warnings were attributed to over-prediction of wind speeds at some sites relative to on-ground weather stations, most of which were in northern Victoria.

Introduction

Sheep in southern Australia are at risk of death through hypothermia shortly after shearing and in the first 3 days after birth. Since the early 1970's the Australian Bureau of Meteorology (BoM) has issued "Sheep Weather Alerts", based on an algorithm that incorporates the effects of wind speed, temperature and rainfall on heat loss from the sheep [START_REF] Wf | The forecasting of chill risk ratings for new born lambs and offshears sheep by the use of a cooling factor derived from synoptic data[END_REF]. These have been broadcast through the mass media up to 24 hours prior to a chill event, but until recently were not issued in Victoria during winter, to avoid "warning fatigue". More recently, the availability of the BoM numerical forecast data has enabled the Department of Environment and Primary Industries (DEPI) to provide seven-day, site-specific forecasts of sheep wind-chill on its website. However, a limitation of a web service is that users are unlikely to check at times when a stress is not expected. Surprise chill events can occur in summer, such as the chillevent reported by Bird and Cayley [START_REF] Bird | Bad weather, shelter and stock losses[END_REF] where 100,000 off-shears sheep died in southwest Victoria in December 1987. To utilize the new weather forecast dissemination capabilities, DEPI has developed and trialed a subscription service that provides advance warning of extreme chill events to sheep producers in Victoria via SMS and email notifications. This paper describes development of the system, the accuracy of forecasts, and user feedback.

Methodology

System Architecture

The SMS and email weather warning system ran daily as an automated service on the Victorian Resources Online server [START_REF]Internet Based Agricultural Warnings[END_REF] (Fig. 1). Through a subscription web-page, subscribers selected from 56 weather stations and specified the sensitivity threshold at which warnings were sent (low, medium or high). The thresholds were based on a statistical analysis of historical weather station data, with relationships derived for each station describing the expected number of warnings per threshold. Universal Time (UTC), wind speed (m/s), hourly rainfall (mm/hr) and temperature (°C ). Accumulated 3-hourly rainfall was downscaled to an hourly basis and missing data in-filled by linear interpolation.

The service ran a series of scheduled tasks early each morning. Historical and seven-day forecast data were first copied from the BoM server then chill-indices calculated for each weather station. Forecasts of wind-chill were made available on the corporate website through an interactive graphical display then a sub-routine compared the forecast to the subscriber threshold. An email and/or SMS was issued based on the first occurrence and length (hours) of the first forecast event that exceeded the specified threshold.

Period

Chill Modelling and Calculation of Thresholds

Sheep wind chill was calculated using the chill index of Nixon-Smith [START_REF] Wf | The forecasting of chill risk ratings for new born lambs and offshears sheep by the use of a cooling factor derived from synoptic data[END_REF], which estimates the potential hourly heat loss from new-born lambs (𝐶𝐶 ℎ𝑟𝑟 , 𝑘𝑘𝑘𝑘/𝑚𝑚 2 . ℎ𝑟𝑟) from air temperature (𝑇𝑇, °𝐶𝐶), wind speed at a 0.4m height (𝑣𝑣 0.4 , 𝑚𝑚/𝑠𝑠) and rainfall (𝑅𝑅, 𝑚𝑚𝑚𝑚/ 24ℎ𝑟𝑟) accumulated over the previous 24 hours:

𝐶𝐶 ℎ𝑟𝑟 = (11.7 + 3.1�𝑣𝑣 0.4 (40 -𝑇𝑇) + 481 + 418(1 -𝑒𝑒 -0.04𝑅𝑅 ) (1)
The BoM wind speed at 10m (𝑣𝑣 10 ) was down-scaled to a lamb height of 0.4m using the empirical relationship developed by McCaskill et. al (unpublished).

𝑣𝑣 0.4 = � 0.104 + 0.0667𝑣𝑣 10 𝑣𝑣 10 < 2.682 -0.863 + 0.427𝑣𝑣 10 𝑣𝑣 10 ≥ 2.682 (2)
Three thresholds were calculated for each weather station from historical data to give subscribers the option to control the sensitivity of the warning service. The low, medium and high thresholds were set so that approximately 10, 15 and 20 events would be triggered each year, noting that with a seven-day forecast, subscribers could potentially receive up to seven warnings for each event. The annual chill events for a given threshold value was found to be well approximated by the upper incomplete gamma function (𝑝𝑝(𝛼𝛼, 𝑥𝑥, 𝑃𝑃)); shown in Fig. 2 for the Rutherglen weather station.

𝑝𝑝(𝛼𝛼, 𝑥𝑥, 𝑃𝑃) = 𝑃𝑃 Г(𝛼𝛼) ∫ 𝑒𝑒 -𝑡𝑡 𝑡𝑡 𝛼𝛼-1 ∞ 𝑥𝑥 𝑑𝑑𝑡𝑡 𝑤𝑤ℎ𝑒𝑒𝑟𝑟𝑒𝑒 Г(𝛼𝛼) = ∫ 𝑒𝑒 -𝑡𝑡 𝑡𝑡 𝛼𝛼-1 𝑑𝑑𝑡𝑡 𝑎𝑎𝑎𝑎𝑑𝑑 𝑥𝑥 = 𝑘𝑘-1000 𝜃𝜃 ∞ 0 (3)
Here α, θ and P are fitted constants and the threshold value (k) has a lower limit of 1000 kJ/m 2 /h. The chill relationship of eqn. 1 is presented in Fig. 3 illustrating the wind, rainfall and temperature conditions required to trigger a warning under the low, medium or high threshold values derived for the Rutherglen weather station. Values of α, θ P and k for this and other representative weather stations are presented later in the paper (see Table 3).

Forecast Skill

The forecast skill of each weather station was assessed for forecasts 1 to 7 days ahead over the 77 days between the 20 th July to the 4 th October 2014. Consistent with the approach used to quantify forecast skill for dichotomous forecasts by the BoM [START_REF] Stanski | Survey of common verification methods in meteorology[END_REF], skill was evaluated by means of a contingency table (Table 2) and calculations of bias and Equitable Threat Score (ETS). Bias compared the frequency of forecast chill-events to observed events indicating whether the system tended to under-forecast (Bias<0) or over-forecast (Bias>1).

𝐵𝐵𝐵𝐵𝑎𝑎𝑠𝑠 = ℎ𝑖𝑖𝑡𝑡𝑖𝑖+𝑓𝑓𝑓𝑓𝑓𝑓𝑖𝑖𝑓𝑓 𝑓𝑓𝑓𝑓𝑓𝑓𝑟𝑟𝑎𝑎𝑖𝑖 ℎ𝑖𝑖𝑡𝑡𝑖𝑖+𝑎𝑎𝑖𝑖𝑖𝑖𝑖𝑖𝑓𝑓𝑖𝑖 0 < 𝐵𝐵𝐵𝐵𝑎𝑎𝑠𝑠 < ∞, 𝑃𝑃𝑒𝑒𝑟𝑟𝑃𝑃𝑒𝑒𝑃𝑃𝑡𝑡 𝑠𝑠𝑃𝑃𝑠𝑠𝑟𝑟𝑒𝑒 = 1 (4)
The Equitable Threat Score (ETS) compared the forecast occurrence of events to the observed, adjusting for hits associated with random chance (h r ) to reduce the effect of different climatic conditions (eg. wet or dry) . The predictive skill of the hourly forecast data was assessed using the Nash-Sutcliff Coefficient of Efficiency (CoE) which ascertains whether the forecast is a better predictor of observed data than the observed mean. The CoE was calculated as

𝐶𝐶𝑠𝑠𝐸𝐸 = 1 - ∑ �𝑄𝑄 𝑜𝑜 𝑡𝑡 -𝑄𝑄 𝑓𝑓 𝑡𝑡 � 2 𝑇𝑇 𝑡𝑡=1 ∑ (𝑄𝑄 𝑜𝑜 𝑡𝑡 -𝑄𝑄 𝑜𝑜 ���� ) 2 𝑇𝑇 𝑡𝑡=1 𝑁𝑁𝑠𝑠 𝑠𝑠𝑘𝑘𝐵𝐵𝑠𝑠𝑠𝑠 ≤ 0, 𝑃𝑃𝑒𝑒𝑟𝑟𝑃𝑃𝑒𝑒𝑃𝑃𝑡𝑡 = 1 (6)
where 𝑄𝑄 𝑜𝑜 is the observed data, 𝑄𝑄 𝑜𝑜 ���� the mean observed data, and 𝑄𝑄 𝑓𝑓 the forecast data

The mean bias ( 𝑄𝑄 𝑓𝑓 ���� -𝑄𝑄 𝑜𝑜 ���� ) between forecast and observed data was also calculated.

Trial Evaluation

Victorian Sheep producers were recruited for an initial trial of the system at the 'Best Wool/Best Lamb' Conference in Bendigo in late June 2014. The trial evaluation was conducted by an independent reviewer [START_REF] Revium | Department of Environment and Primary Industries Systems for Enhanced Farm Services Program. Spatial Discovery & Visualisation -SDV1: IBAW Trial Participants Survey[END_REF] included both open and closed questions. Findings were organized to answer each of the overarching questions (i) "Were clear, accurate and timely alerts received?", (ii) "Did alerts lead to reduced lamb losses?", and (iii) "Did farmers value the alerts?"

3 Results

Trial Results

In general, the alerts were found to be clear and reasonably accurate although there were some timing issues possibly attributable to technical glitches. The SMS format was well received. Farmers were generally happy to continue the trial and would potentially be happy to pay a small amount for a commercial service. The evaluation found that the alerts did not lead to farm responses that saved lives during lambing except for small-scale farming where sheep could be managed individually. This was primarily due to the fact that due to the risks involved in moving ewes during lambing most farmers had already taken the precaution of providing as much protection for their birthing ewes as possible.

However, almost all farmers saw significant potential value in the alerts for shearing when surprise cold can cause significant losses amongst newly shorn sheep. Participants cited greater flexibility to respond using a range of options such as moving sheep into shelter or rescheduling shearing.

The independent reviewer recommended that the trial be continued through shearing with the scope expanded to include sudden changes in weather that might be experienced during the summer months that are potentially dangerous to newly shorn sheep, generally between November and May.

Forecast Skill

The forecast skill of each weather station was assessed for forecast days one to seven, under the low, medium and high thresholds over the 77 days between the 20 th July to the 4 th October 2014. Key determinants of skill included calculations of bias and ETS which have been presented in Table 3 along with other results for a subset of weather stations.

During the trial period the ETS measure of forecast skill varied with weather station, forecast day and the threshold, ranging from a perfect score of 1.0 at Horsham to 0.2 at Wangaratta (Table 3) for the day-one forecast. Stations with a lower ETS generally predicted actual chill events well however their score was reduced by the frequent occurrence of 'false alarms'; represented by a bias>1 in Table 3. Across the 56 weather stations there was a significant (P < 0.05) decline in forecast skill from day one to day seven (Fig. 4a). In contrast, there was less differentiation in the forecast skill between the low, medium and high thresholds (Fig. 4b). The Coefficient of Efficiency (CoE) was used to evaluate the forecast skill of the hourly sheep-chill-index and underlying temperature, rainfall and wind-speed forecast data. Overall the sheep-chill-index forecast skill was 'good' with over 75% of stations achieving a CoE>0.6 for forecast days one to four (Fig. 5). This could be attributed to forecast skill of temperature which far exceeded that of rainfall and windspeed. The accumulated rainfall saw a sharp decline in CoE between days one and two which coincided with the transition between the 3km grid ADFD forecast to the 40 km grid Access-G rainfall forecast. The Wind-speed forecast showed less skill with only 25% of stations achieving a CoE>0.6 by day four. Forecast bias across the 56 stations showed little change with increasing forecast length (Fig. 6), apart from a greater divergence in bias at longer forecast lengths. In general the forecast wind-speed exceeded the observed with over 75% of stations showing a positive mean-bias. This followed through to the calculation of chill-index where the mean forecast chill-index exceeded the observed by more than 10 kJ.m 2 .hr for over 75% of stations. For example at Rutherglen, wind speed was overestimated by 1.1 m/s from the one-day forecast and chill by 22 kJ/m 2 .hr. Overall there was a strong correlation between over-prediction of mean wind-speed and the number of false alarms triggered.

Discussion

The forecast skill varied widely from station to station and this was reflected in the mixed comments received through the project evaluation. In general, although there was a decline in performance over successive forecast days, weather stations that had a high forecast skill on day-1 maintained that performance over the seven day forecast. Of the 56 weather stations, 33% performed well with a day-1 forecast skill as measured by the ETS of > 0.6. A further 46% of stations performed moderately-well with a day-1 ETS of between 0.2 and 0.6. Chill events were generally well forecast for these stations but the forecast score was brought down by a high number of false alarms. Significantly, many of the stations that triggered multiple false alarms were located across the Northern region of Victoria (eg. Rutherglen, Wangaratta), where severe frosts often bring hourly temperatures to below zero. Subscribers to these stations commented on the fact that occasionally alerts were "clearly just for frost" rather than the "holy trinity of wind rain and cold" [START_REF] Revium | Department of Environment and Primary Industries Systems for Enhanced Farm Services Program. Spatial Discovery & Visualisation -SDV1: IBAW Trial Participants Survey[END_REF]. It was found that at low tem-peratures the wind-chill algorithm is highly sensitive to small changes in wind-speed (Fig. 3) and that the cold temperatures combined with an over-prediction of windspeed across these locations was enough to trigger a series of false-alarms. Enforcing a precipitation requirement was found to effectively reduce false-alarms for these stations as simply increasing the threshold made little improvement to the ETS. The difference between the forecast wind and that observed at the weather station highlights not only the difficulty of accurately predicting wind speed but also one of the fundamental assumptions made by this system that the 3 km gridded ADFD data and the 40 km gridded Access-G rainfall provide an adequate representation of the climate at the point of the weather station. Options to correct this include (i) empirical relationships between the station and the numerical forecast, (ii) calculating warning thresholds from historical records of the gridded forecast data, and (iii) improvements to the forecast models that increase their accuracy close to the ground surface.

Conclusion

The SMS and email weather warning service for sheep producers accurately predicted sheep-wind-chill events, but at some stations generated a high number of false alarms due to the sensitivity of the sheep chill algorithm to wind-speed at low temperatures, and the consistent over-prediction of wind speed in the forecast data. The forecast skill varied widely from station to station and this was reflected in the mixed comments received through the project evaluation. However in general the alerts were found to be clear and reasonably accurate with most farmers happy to continue with the trial.

Fig. 1 .

 1 Fig. 1. System architecture of SMS and email weather warning systemWeather data (Table1) were downloaded from the BoM Server via an ftp link and comprised; historical weather station data, seven days of the ~3km resolution Australian Digital Forecast Data (ADFD) and seven days of the ~40km resolution Access-G Forecast. The Access-G precipitation forecast was required because the ADFD only provided a one-day forecast. Inputs were converted to standard units of Co-ordinated

Fig. 2 .

 2 Fig. 2. The expected annual number of sheep-wind-chill events for wind-chill threshold (k), calculated from historical hourly data (1998-2013) for the Rutherglen weather station.

Fig. 3 .

 3 Fig. 3. Illustration of the sheep-wind-chill relationship of eqn. 1, showing the combination of wind speed, temperature and rainfall required to trigger thresholds for the Rutherglen station.

3 <

 3 𝐸𝐸𝑇𝑇𝐸𝐸 < 1, 𝑁𝑁𝑠𝑠 𝑠𝑠𝑘𝑘𝐵𝐵𝑠𝑠𝑠𝑠 = 0, 𝑃𝑃𝑒𝑒𝑟𝑟𝑃𝑃𝑒𝑒𝑃𝑃𝑡𝑡 = 1 (5) 𝑤𝑤ℎ𝑒𝑒𝑟𝑟𝑒𝑒 ℎ 𝑟𝑟 = (ℎ𝐵𝐵𝑡𝑡𝑠𝑠 + 𝑚𝑚𝐵𝐵𝑠𝑠𝑠𝑠𝑒𝑒𝑠𝑠)(ℎ𝐵𝐵𝑡𝑡𝑠𝑠 + 𝑃𝑃𝑎𝑎𝑠𝑠𝑠𝑠𝑒𝑒 𝑎𝑎𝑠𝑠𝑎𝑎𝑟𝑟𝑚𝑚) 𝑡𝑡𝑠𝑠𝑡𝑡𝑎𝑎𝑠𝑠

Fig. 4 .

 4 Fig. 4. The ETS range over 56 stations where box-plot represents [99,75,50,25,1] percentile, (*=mean) for (a) forecast day one to day seven, (b) low, med and high threshold

Fig. 5 .

 5 Fig. 5. Range of CoE over 56 stations for chill-index, accumulated rain, wind speed and temperature showing decline in predictive skill over seven days. Example response given for Hamilton and Rutherglen stations.

Fig. 6 .

 6 Fig. 6. Range of mean-bias (∆) over 56 stations for chill-index, accumulated rain, wind speed and temperature. Example mean-bias given for Hamilton and Rutherglen stations.

Table 1 .

 1 BoM

		Source	Time units Element	Units	Frequency
	3-weeks	BoM Aus-	[Year,	Wind speed	m/s	hourly
	historical	tralian	month,	Rainfall since	mm	hourly
	data	Weather	day, hour]	9am
		Station Feed	local time	Temp	°C	hourly
	Forecast	Australian	Co-	Wind speed	knots	hourly
	day 1-7 (except for rain)	Digital Fore-cast Grid (ADFD) ~3km grid	ordinated Universal Time UTC	3-hr expected rainfall Temp	mm/3hr 3-hourly °C hourly
	Forecast	Access-G	Seconds	Accum. rain-	mm/3hr 3-hourly
	day 2-7	(IDY25001)	since start	fall over mod-
		~40km grid	date UTC	el assimilation

Weather data used for sheep-wind-chill calculations

Table 2 .

 2 Contingency table to assess the types of errors being made

			Forecast
		Yes	No
	Observed	Yes Hits No False alarm	Misses Correct negative Observed no Observed yes
		forecast yes	forecast no	Total

adfa, p. 1, 2011. © Springer-Verlag Berlin Heidelberg 2011

adfa, p. 2, 2011. © Springer-Verlag Berlin Heidelberg 2011

adfa, p. 3, 2011. © Springer-Verlag Berlin Heidelberg 2011

adfa, p. 4, 2011. © Springer-Verlag Berlin Heidelberg 2011

adfa, p. 6, 2011. © Springer-Verlag Berlin Heidelberg 2011 adfa, p. 7, 2011. © Springer-Verlag Berlin Heidelberg 2011

adfa, p. 8, 2011. © Springer-Verlag Berlin Heidelberg 2011

adfa, p. 9, 2011. © Springer-Verlag Berlin Heidelberg 2011

adfa, p. 10, 2011. © Springer-Verlag Berlin Heidelberg 2011


Robert Power
email: robert.power@csiro.au

Bella Robinson
email: bella.robinson@csiro.au

Catherine Wise
email: catherine.wise@csiro.au

David Ratcliffe
email: david.ratcliffe@csiro.au

Geoffrey Squire
email: geoffrey.squire@csiro.au

Michael Compton
email: michael.compton@csiro.au

The Emergency Response Intelligence Capability Tool

Keywords: Disaster Management, Situation Awareness, Situation Reporting, System Architectures, Web Feeds. adfa, p. 1, 2011

de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

The Emergency Management team within the Australian Government Department of Human Services (the department) is responsible for the coordination of the department's response to emergencies, with a focus on delivery of departmental services and disaster assistance on behalf of the Australian Government to the affected community. The Australian disaster season is from early October through to late March and often involves bushfires, floods and cyclones with many events often occurring at the same time across State and Territory borders. ERIC allows the Emergency Management team to easily monitor events occurring around the country and provides fast and intuitive access to a wide collection of in-formation. The aim was to provide software support to help the Emergency Management team perform their tasks more efficiently and effectively, allowing them to better utilise their time in the analysis of information.

During large scale emergency events, the Emergency Management team creates a Situation Report as a Microsoft Word document. The information recorded includes specific event details (the event type, its location, impact to the community) and the tasks undertaken by the department (the number of staff mobilised, the impact on business as usual activities, statistics about the number of phone calls received and claims made by members of the community for Commonwealth Disaster Assistance). This information is tracked and reported on during the course of the emergency events and may continue well after the initial emergency response. The Situation Report is used by senior managers in the department to make informed decisions.

Dynamic data is sourced from public 'live' web feeds that provide content to the existing State and Territory emergency services web sites. See for example the Rural Fire Service websites for New South Wales1 and Queensland2 . A web feed is a web accessible resource that is updated frequently as new information becomes available from the content provider. This information is produced in many formats, for example RSS, GeoRSS, ATOM, JSON, GeoJSON, KML, HTML, XML, GML, XLS and plain text.

ERIC integrates information from numerous other sources such as statistical data from the ABS including population demographics; 'departmental demographics' such as the number of people receiving different payment types; the 'live' web feeds noted above; a repository of historical data collected via these 'live' web feeds; and an archive of previous situation reports. The integrated information can be focused to a specific region under investigation where an emergency is underway and collated semi-automatically to generate a pre-populated Situation Report as a web form that is then completed by the user. This may include content from a previous Situation Report with updates to the current situation automatically highlighted.

The example screen shot of Fig. 1 shows the status of the New South Wales (NSW) State Mine Fire. It highlights how overlaying information from two different agencies (the NSW Rural Fire Service and Geoscience Australia) provides more insight into events. This figure demonstrates some of the important features of ERIC: the recorded information remains available for review and the map provides an easy and intuitive interface for users to navigate the information available from different sources.

A public version of ERIC is available at http://eric.csiro.au/. This version does not include any of the department's data (for privacy reasons), and the situation report function is not available. Some web feeds are also excluded for copyright reasons. Notably, the state of Victoria does not allow republication of their emergency web site content.

Related Work

There are existing web feed aggregators that provide some of the ERIC features to combine content from the 'live' web feeds3 , however they do not support the diverse range of formats currently managed by ERIC. Similarly, some of the ERIC mapping and geospatial features are provided by Geospatial Information Infrastructures and Web 2.0 'mashups'4 , however, they require the data to be available in specific formats and do not support the identified Situation Report features. The central task of the Emergency Management team is to maintain situational awareness throughout the response and recovery phases of disaster events. The Situation Report embodies this knowledge. A number of Situation Awareness models exist to help characterise this process. For example, Endsley [START_REF] Endsley | Toward a theory of situation awareness in dynamic systems: Situation awareness[END_REF] defines three levels: perception (sensing the environment), comprehension (combining sensory data to discover information) and projection (using the information to predict possible futures). ERIC helps with the first two levels, perception and comprehension, by assembling information from various sources into a single coherent picture. Predicting possible consequences remains the task of the user, although this could be an area of future work.

Harmonising Emergency Event Information

Web Feed Aggregation

A summary of the different web feeds used by ERIC is shown in Table 1 indicating the content, word count and formats used for each. Note that some agencies maintain multiple feeds of varying types. As shown in

Common Web Feed Model

The dynamic 'live' web feed data is polled regularly with the results stored in a database. These web sources are heterogeneous in many ways and a common model has been defined which is the basis of the database schema. The variety of data formats and information content used by the various agencies around Australia can be seen in Table 1. In general however, the web feed content is similar for each: a web feed has a URL endpoint which provides regular information updates. These updates consist of one or more posts describing the individual events. Each post contains: an identifier that uniquely identifies the event described; a timestamp for the individual post; the description of the event; the event category; a link to further information from the source; and the location as either a point or region. This model is shown in Fig. 2, from [START_REF] Power | Harmonising Web Feeds for Emergency Management[END_REF]. The process of harmonising the various web feeds into the common structure of Fig. 2 is one of the tasks performed by the ERIC web server: each web feed is regularly checked for updates (currently every 10 minutes, which is configurable) with new information recorded in a database. Note that only new information is recorded in the database -new content consists of a collection of posts where some posts contain updated information while others remain unchanged. Identifying differences between subsequent posts about the same event is part of the user alerting process.

Harmonising Examples

Further examination of the web feed contents is focused on the seven web feeds indicated by the 'dagger' † in Table 1. These fire feeds were targeted since they provide coverage for the whole country, are representative of the diverse formats used and include geospatial content. The target feeds are mostly rural fire services from around the country, except for the Australian Capital Territory Emergency Services and West Australian Fire which includes posts about other event types as well. There were 21 different categories of events derived from the content of these feeds recorded for the period 1 October 2012 -1 May 2014, ranging from hazard reduction, permitted burns, car incidents, false alarms, electrical fires and so on. Of these, the information of interest is the fire 'alert level': the fire warnings to the community.

In general, the progression of alert levels for fires are 'Advice': an indication that a fire has started and there is no immediate danger; 'Watch and Act': a heightened level of threat where preparatory action by the community is required; and 'Fire Emergency': the highest alert level where there is immediate threat to the community.

The different agencies report this information in different ways. Of the seven target web feeds † in Table 1, four produce fire warnings in the three alert level categories noted above. One has an indication in the event title that can be used to derive the alert level. The remaining two do not directly state the alert level, but instead provide detailed descriptions of the type of fire, such as 'grass fire'. In these two cases, the alert levels are mapped as an Advice for all reported fires. Fig. 3 shows the distribution of fire events showing the different reporting styles of the agencies: across the Eastern Seaboard, and into Tasmania, the agencies report very frequently. By comparison, Western Australia has far fewer reports, and the Northern Territory has none. Reports are widespread in Victoria, and Tasmania, but in the other eastern states they cluster along the coast with the population.

Fig. 3. Map of reports

The agencies describe events with a sequence of key-value pairs, for example the 'Type' and 'Status'. Of the seven sources investigated, all but one show a strong indi-cation of a few standard ways of reporting fires. This was measured by counting the number of fields; approximated by the number of colons (:) in the description of the posts and illustrated in Fig. 4. West Australian Fire was the exception, with a highly prosaic format and long reports, as shown by the mean description length in Table 1. As such, they have been excluded from Fig. 4 because they do not use the key-value pairs and their data obscures the other results. We can compare Fig. 3 and Fig. 4 to tease out some of the diversity of reporting present in these feeds. In Queensland, the reports are concentrated towards the south and the east, however the reporting format is very static. In fact, it is quite brief, and despite the large number of reports many of them are almost indistinguishable. This is even more extreme in South Australia. Here the reports concentrate heavily around Adelaide and the Eyre Peninsula, and are very rigidly formatted. This is in part due to the Victorian Country Fire's choice of using KML as the reporting format, which is highly structured.

In contrast are Victoria and Tasmania. Both have a spread of reports covering the majority of the state, and both have a fluctuating reporting format, although unlike Western Australia the format is still structured. This structure is not because of the format, since Queensland and Western Australia also use GeoRSS.

Different agencies have informally extended the file formats with structured text formats, such as the use of colon-seperated fields and values. In some cases, such as Queensland, this new format is strictly adhered to; however other agencies are not so strict, changing their customisations as they feel the need. The GeoRSS format is particularly amenable to this extension, with the main 'post' tag allowed to contain arbitrary XML, although most commonly HTML or plain text is used.

4

Discussion and Future Work

Architectural Improvements

All ERIC data is managed as a data warehouse. While this is necessary for the web feed content to provide an historical archive, some of the other data layers could be provided using services provided by the data custodians. These services are currently not universally available, but it is expected they will be established over time.

Another benefit of a service based approach is the ability of users to include spatial data layers of their choosing. This is best achieved using a standards based approach to service integration, such as adopting relevant Open Geospatial Consortium service standards, such as the Web Feature Service and the Web Mapping Service.

Such integration currently requires a skill set beyond the average user. In order to empower users to integrate their own data, a new generation of supporting tools are needed. We have investigated the use of a web-based user interface to allow nonprogrammers to easily upload newly available data.

Using the web-based upload/update tool, users may upload their data in a number of file formats (currently ESRI Shapefiles and CSV, with nested data formats like XML/JSON to follow, for example: KML, RSS and RDF). The tool then presents the schema of the uploaded files against an ontology (a conceptual schema), terms from which are then used to describe the semantics of the uploaded data. The user's description of their data in ontology terms describes a 'mapping', which is automatically interpreted and executed by the tool to extract data from the uploaded file, transform it to the relevant data structure and load it into the system, completely automating the manual Extract/Transform/Load process.

This process was aimed at allowing the user to update the data warehouse with new versions of data without the need of a system administrator. This tool could be adapted to semantically integrate new data sources from service end points. Instead of simply providing a new dataset as a visual layer in ERIC, the content could optionally be merged with existing data layers.

Common Alerting Protocol

The Common Alerting Protocol (CAP) 5 is an international XML standard to facilitate the construction and exchange of emergency alert and warning messages. The Australian Government has created an Australian Profile of the standard 6 and are encour-aging all Australian emergency agencies to adopt it. This is a significant undertaking with only one agency listed in Table 1 doing so to date7 .

Since ERIC harmonises web feed data from various emergency related agencies, initial work has been carried out to evaluate the difficulty for ERIC to produce CAP compliant messages. The most challenging task to date has been determining the mapping between each agency's category of events to the standard CAP event categories. For example some agencies describe an incident as a 'scrub fire' to which there is no direct CAP mapping. The options in this case are: fire, bushfire, forest fire, grass fire, structure fire and industrial fire.

Data integration would be simplified if the agencies published information using CAP. This is an area of further work requiring liaison with key agencies to demonstrate how this can be done using the CAP messages produced by ERIC.

Social Media Integration

The tasks achievable using ERIC can be extended by including crowd sourced social media. Some progress has been made in ERIC by linking to the CSIRO Emergency Situational Awareness (ESA) platform [START_REF] Power | Emergency Situation Awareness: Twitter Case Studies[END_REF] which continuously retrieves and analyses new Twitter posts originating from Australia and New Zealand. It is able to detect high frequency words and alerts the user to these using a tag cloud. ESA also uses machine learning methods to classify Tweets containing earthquake and fire related keywords, to see if they relate to current or new emergency events. ESA provides a search interface allowing the user to search for Tweets matching specific criteria. ERIC includes a hyperlink in an event's popup to the ESA search interface for every fire event. The search terms are preset so that ESA will search for Tweets from the region surrounding the selected event that have been classified as positive fire related Tweets. Tweets from official agencies and the general public often contain extra information that is not available via the official web feeds. This extra information may include pictures or videos of the event and detailed impact information.

In future we plan to explore a more comprehensive integration of web feed and social media content. Instead of simply linking ERIC and ESA, we would like to present the social media data within the ERIC tool. An identified issue to be resolved is the trustworthiness of this information source [START_REF] Hiltz | Use of Social Media by US Public Sector Emergency Managers: Barriers and Wish Lists[END_REF][START_REF] Thomson | Trusting Tweets: The Fukushima Disaster and Information Source Credibility on Twitter[END_REF]. This is especially important for emergency managers who are mainly concerned with verifiable information.

Conclusions

CSIRO has developed the ERIC web based tool that demonstrates the usefulness of data integration for emergency managers. ERIC improves the situational awareness of the Emergency Management team in the Australian Government Department of Human Services by integrating information from authoritative public real time web feeds with demographics data to provide a national picture that is available for historical review. ERIC also identifies when the current situation changes and informs the user, reducing the need for the operator to do so. ERIC was developed to support the intelligence gathering and situation reporting activities performed by the department's Emergency Management team. This has been successful, reducing the time taken to produce a Situation Report from approximately two hours to about 20 minutes. This is one of the main activities of the team during emergency events and their aftermath. It is critical that this information be reported in a timely manner. There have been other benefits also: the workflow of creating a Situation Report has been revised and improved; a standard Situation Report template defined and a method of naming events established.

A public version of ERIC is available at http://eric.csiro.au/ demonstrating the utility of data integration for the purposes of emergency management. All departmental information has been removed from the public version for privacy reasons and the situation reporting features disabled. While ERIC was developed for the department's Emergency Management team, we are actively promoting it for use by other agencies, the not for profit sector and the general public.

Fig. 1 .

 1 Fig. 1. State Mine Fire, near Lithgow NSW on 21 October, 2013

Fig. 2 .

 2 Fig. 2. Common Web Feed Model.

Fig. 4 .

 4 Fig. 4. Colon ':' count per event per day.

Table 1 ,

 1 ERIC tracks nine RSS feeds, eight GeoRSS feeds, two KML sources, 10 GeoJSON sources, and 13 GML files. The providers indicated by a 'dagger' † are discussed in more detail below.

	Provider			Content		Word count	Format
		Traffic	Fires	Weather	Other	Mean	Std
		details		warnings	incidents		Dev
	Australian Capital					1,694	1,548 GeoRSS
	Territory Emergency
	Services †
	Bureau of						13 GML, 8
	Meteorology						RSS, text,
							XML
	Geoscience						GeoRSS
	Australia
	Queensland Traffic						GeoJSON
	Queensland						GeoJSON
	Community Safety
	NSW Roads						6 GeoJSON
	NSW Rural Fire †					5,186	4,993 GeoRSS
	Rural Fire					4,053	2,906 GeoRSS,
	Queensland †						XLS
	South Australian					852	773 KML
	Country Fire †
	Tasmanian Fire †					9,833 10,979 GeoRSS,
							KML
	Victorian Country					3,024	2,765 2 GeoRSS,
	Fire †						RSS
	Victorian						2 GeoJSON
	Environment
	Victorian Roads						JSON
	West Australian					17,948 10,822 GeoRSS
	Fire †

Table 1 .

 1 Web Feed Summary.

http://www.rfs.nsw.gov.au/dsp_content.cfm?cat_id=683

https://ruralfire.qld.gov.au/map.html

See http://www.rss-readers.org/list-of-rs-feed-reader/.

For example, see GeoCommons: http://geocommons.com/.

http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2.html

http://www.em.gov.au/CapAuStd

http://www.rfs.nsw.gov.au/feeds/majorIncidentsCAP.xml

Acknowledgements

ERIC was funded under the Human Services Delivery Research Alliance between the CSIRO and the Australian Government Department of Human Services. The ESA project was originally financially supported through the National Security Science and Technology Branch within the Department of the Prime Minister and Cabinet.


Bradley Lane
email: bradley.lane@csiro.au

Nicholas Car

Justin Leonard

Felix Lipkin

Anders Siggins

Mobile Field Data Collection for Post Bushfire Analysis and African Farmers

Keywords: DroidFarmer, CSIRO Surveyor, AusAID, Bushfire, Africa, Farmer, GIS, Questionnaire, Android, MongoDB, SQL Server

In recent years CSIRO has been trialling field data collection using mobile devices such as phones and tablets. Two recent tools that have been developed by CSIRO are the CSIRO Surveyor (Post Bushfire House Surveyor) and DroidFarmer. Challenges tackled include mapping field documents to mobile data through QR (Quick Response) codes, rapid input of survey data, accurate capture of GPS locations and offline operation. Throughout this paper we detail the design choices made for these systems. We give details of how well field data collection was performed and discuss our planned future developments in this space.

Introduction

CSIRO Surveyor and Droid Farmer applications (apps) were designed to fulfil a need to easily and efficiently collect field data. Each tool faced different challenges due to differing design requirements. The key issues for Droid Farmer were linking field documents to app-collected data, getting accurate GPS readings and enabling offline data recording (i.e. local phone storage) for areas with poor network coverage. CSIRO Surveyor had to handle issues of efficiency in GIS and survey data entry, map caching for offline use and the possibility of communications infrastructure breakdown. Throughout this paper we explain how we attempted to resolve these issues through mobile application system design and software architectures.

CSIRO Surveyor

CSIRO Surveyor was initially developed for the New South Wales Rural Fire Service (RFS) to enable detailed data capture in areas recently affected by bushfire. After a bushfire front passes an area and it is deemed safe, trained survey teams with tablets carrying the Surveyor application are sent into the field. The app delivers two primary functions: firstly, the detailed marking of houses, trees, water tanks and other types of objects using a Graphical Information System (GIS) user interface (see Fig. 2) and secondly, a novel Survey Questionnaire Response System (SQRS, see Fig. 3). Along with the main app a cut-down version was developed for Rapid Impact Assessment, which provided a means to easily visually track bushfire-affected houses via a central desktop GIS dashboard.

The data collected was used for public reporting of statistics and then post bushfire analysis. Analysis of the affected areas gives information on how to reduce the impact of bushfires in the future.

Basic System Design

The basic system design for CSIRO Surveyor is displayed in Fig 1. [4] discusses a similar Android data collection system and points to the importance of ease of input, consideration of the availability of internet connectivity and data visualisation. We address these considerations below.

GPS Touch Input

The GIS interface (see Fig. 2) was developed using Android and ESRI [START_REF]ArcGIS Runtime SDK for Android. Software Application[END_REF] APIs. Maps are loaded before travelling to a site. Once on location, the user marks houses, trees, water tanks and other entities of interest regarding bushfires by first touching the entity type on the right and then marking its location on the screen. After marking the entity locations the questionnaire activity starts. There were three different methods of marking entity locations on the screen depending on the type of entity. To record a polygon entity such as a house the user marked each point and then pressed the starting point again to complete the shape. For a single point entity the user just marked the desired location once. Finally for multipoint entities like trees the user marked each position with a screen tap for each point and then completed the entry process by tapping the final point a second time.

Questionnaires

The tablet-optimized Survey Quick Response System (SQRS) was developed using the standard Android API. Questionnaires were structured in a hierarchical fashion using a separate web tool and then uploaded to a central MongoDB cloud-base store [START_REF]MongoDB-as-a-Service[END_REF] on creation; editors were also able to update the cloud store questionnaires. Tablets then communicated with the cloud store allowing them to automatically update their local copies of the questionnaires. Questions could be 'removed' by disabling/hiding them. No questions were deleted from the cloud store to prevent older responses being orphaned (no question left to link to an answer).

Questionnaire Construction

Questionnaires were built by creating questions with appropriate responses and adding them to a hierarchy which ensured only necessary information was collected when certain question's answer invalidated other questions. Questions responses could be either multiple choice or numeric, with individual responses being linked to any number of further questions in the hierarchy.

Multiple choice responses were the simplest to implement as new questions could be easily linked to individual responses. Linking numeric responses to new questions was achieved using value ranges, for example, when a user enters value in range of 0 to 20 we could ask questions x, y and z.

Questionnaire Input

Due to the hierarchical structure of the questionnaires users could complete input actions very quickly. For multiple choice questions, a single tap on a response immediately moved one to the next appropriate question. For numeric answers, the user had to enter a value before tapping a button to continue.

When a mistake was made, the user could press a 'Back' button to backtrack through the questions. The questions followed a specific track, with questions being asked until the end of a branch with hierarchy recursion used to find the next relevant question. A summary of questions and responses is given on the right side of the SQRS interface in Fig. 3. Some questions required the user to enter information regarding a specific face or side of a building. To make this process easier for the user we dynamically labeled them for the user as A, B, C and D (see Fig. 3) then referred to these specific labels in the questionnaires.

Consideration of Infrastructure Breakdown

To cater for mobile phone network infrastructure breakdown, the CSIRO Surveyor and RIA tools incorporated offline capabilities. This was implemented using a SQLite database to cache data that had not been sent to the cloud store. When the user of a tablet caching data later moved into network connectivity, the cached data could then be transmitted. Since data could be cached, phone network infrastructure state does not affect the effectiveness of the app. Results could not be displayed on the desktop GIS dashboard until successful data upload.

Data Integrity and Cross Checking

For comparison and data integrity purposes, two copies of the questionnaire results were transmitted; one to the ESRI Database and one to MongoDB. This was very helpful in both ensuring that results were successfully transmitted to both systems and that the results matched. Data was transmitted with a globally unique identifier (GUID) and a time stamp for quick matching.

Usage Statistics

Between October 20th and 30th 2013, 4,715 questionnaires were submitted from one bushfire. These included 24 different types of questionnaires plus separate storage of other types of data such as photos. To collect the data from all affected houses approximately 12 teams with 2 people in each team were deployed into the field.

Planned Improvements

The current system is designed for use with bushfires but could easily be modified to support other disasters. To accomplish this, we intend to make certain sections of the system more generic. For example, the interface for selecting the type of entity to record (see Fig. 2) is partially hard coded. By making the screen layout and entities configurable, the application could easily support different disaster types.

DroidFarmer

DroidFarmer is an Android mobile phone application built to collect crop and spatial data for farm surveys in Africa. The app was designed using standard Android tools and built for compatibility with early Android devices. It was also designed to be very simple to operate in order to cater for users not familiar with Smartphones. It used offline storage with online sync to handle poor cellular/wireless internet availability in farm areas. GPS readings were taken for spatial objects such as trees and field areas and with users walking to locations and tapping a single screen button to record position. After transmission to a central server, recordings were displayed as map points and polygons on a web map interface. This app is essentially a 'mapping app' as described by [START_REF] Aitkenhead | E-SMART: Environmental Sensing for Monitoring and Advising in Real-Time Environmental Software Systems. Fostering Information Sharing[END_REF] however, unlike the proposition in that paper that such apps require potentially costly and time-consuming post-collection data analysis, such steps are not required where app users are the beneficiaries of the field data collection (e.g. farmers using the app to measure their field areas and results can be related on screen). Where scientists are the beneficiaries of aggregated field data, normal results processing is required.

The data collected had numerous uses. One example was the collection of soil moisture data from field instruments to assist farmers in choosing appropriate crops.

Another example was the recording of field size and position, which enabled farmers to order goods and services without being overcharged.

Basic System Design

The basic system design for DroidFarmer is shown in Fig 4.

Document Linking

One novel aspect of DroidFarmer was its linking of paper field records, readings from field equipment and phone gathered data through interpreting Quick Response (QR) codes and its function reuse.

QR codes were printed on paper survey sheets and affixed to field instruments via stickers. This was designed to prevent data confusion and loss when data was recorded in multiple forms. The approach worked well with many thousands of complete bundles of field data being recorded and incomplete bundles instantly identifiable after data upload. This rapid understanding of data gathering completeness saved much time in deciding which fields to resurvey. Extensive input validation of phone input data and QR recording sequences was implemented which reduced data entry errors compared with paperbased recording. Several data gathering workflows were implemented that utilized the same GPS recording, QR code handling and form entry functions which are able to be used still further. The code scanning was done using a 3rd party tool called "Barcode Scanner" developed by ZXing Project [3]. Data visualisation was done via a website (see Fig. 6), where recorded data was marked on a map with pins; additional data and images could then be accessed by clicking on a pin.

Improving the accuracy of GPS readings

To aim for the best accuracy, we deployed multiple strategies based on observations from testing. Two key things we observed in testing were that GPS tracking took time to initiate and that accuracy improved the longer a user stayed in one spot.

To take advantage of this we started tracking locations as soon as the user entered the activity. Once started we continually polled for new readings with each new reading being added to a short stack. When a user requested a location be marked we would first look at the top reading, if it met our accuracy requirements it was used, if not we would check the stack for one that does, if none was found we took the average position.

Because the user needed to spend time entering data before taking a reading (not a coincidence), the device was normally in a good position to take the first reading. In either case the process was fast because the stack was continually updated the moment the activity was started.

Our goal was to have readings accurate to 10m or less. Using the above mentioned approaches we were generally able to achieve this target.

Dealing With a Low Tech Community

The overall level of smart phone technology was low in Africa. Due to this we needed to design the software to run on the lowest possible version of Android while taking into consideration our design needs.

Data Validation and Statistics

Most spatial data could be easily validated visually (GIS view) from the website upon the users return. At the time of writing there were several thousand submitted recordings across the various categories.

Controlling the User Experience

Use of the CSIRO Surveyor app was a controlled user experience as it was manually loaded onto tablets which were then handed to individuals and small groups after receiving training. DroidFarmer on the other hand was delivered to phones using the Google Play online app store meaning access to it was available to all. Scientists familiar with Smartphones wanting to capture data could do so easily, but farmers not familiar needed to be guided through the process.

Platform Specific vs Platform Independent

After considering various platform-specific vs platform-independent designs, we decided to go for a hybrid model. We utilised RESTful technologies whenever possible; but for devices we chose to be dependent on Android. This decision was made after careful consideration of the level of control we needed over device hardware.

Conclusions

Both DroidFarmer and CSIRO Surveyor were received well by their intended audience. Users appreciated the effort that was taken to meet their specific needs which we were able to achieve while retaining a large amount of application code reuse. DroidFarmer enabled, and continues to enable, farmers and researchers to collect data in Africa and have it instantly available for study world-wide. CSIRO Surveyor is continuing to enable the rapid collection of post disaster survey data. These systems met their intended design use and are continuing to be developed and enhanced for future use.

Fig. 1 .

 1 Fig. 1. The main technologies used were ESRI GIS Servers, SQL Databases (for ESRI data and Questionnaires), Android Devices, ASP.NET Web Sites and MongoDB Cloud Services.

Fig. 2 .

 2 Fig. 2. The above image shows the GIS input interface.

Fig. 3 .

 3 Fig. 3. The above image shows the SQRS input interface.

Fig. 4 .

 4 Fig. 4. Main technologies used were Android Devices, MongoDB RESTful Web Services and a Web Site.

Fig 5 .

 5 Fig 5. The DroidFarmer logo and a QR Code

Fig. 6 .

 6 Fig. 6. A screenshot of a large number of DroidFarmer-reported survey locations in East Africa. Four different types of icons are shown for four different data types: the locations of survey sheet completions (in the field), the centres of stands of crops, photos of stands of crops and photos of insect traps.

Lane et. al.. Mobile Field Data Collection for Post Bushfire Analysis and African Farmers, p. 1, 2015. © Springer-Verlag Berlin Heidelberg 2015


Markus Stocker
email: markus.stocker@uef.fi

Mauno Rönkkö
email: mauno.ronkko@uef.fi

Mikko Kolehmainen
email: mikko.kolehmainen@uef.fi

Provenance in Systems for Situation Awareness in Environmental Monitoring

Keywords: Situation awareness, situation theory, provenance, environmental monitoring, Wavellite

As environmental monitoring systems increasingly automate the collection and processing of environmental sensor network data, the technical components of such systems can automatically obtain and maintain higher levels of situation awareness-awareness of the monitored part of reality. In order to increase confidence in the correctness of situation awareness maintained by such systems it is important to explicitly model provenance. We present an alignment of the PROV ontology with ontologies used in a software framework for situation awareness in environmental monitoring, called Wavellite. The extended vocabulary enables the explicit representation of provenance in Wavellite applications. We demonstrate the implementation for a concrete scenario.

Introduction

Endsley defined situation awareness as the "perception of the elements in the environment within a volume of time and space, the comprehension of their meaning, and the projection of their status in the near future" [START_REF] Endsley | Toward a theory of situation awareness in dynamic systems[END_REF]. Over decades, situation awareness has been receiving considerable attention in various communities, e.g. human factors and ergonomics [START_REF] Salmon | What Really Is Going on? Review, Critique and Extension of Situation Awareness Theory[END_REF][START_REF] Smith | Situation Awareness Is Adaptive, Externally Directed Consciousness[END_REF][START_REF] Bedny | Theory of Activity and Situation Awareness[END_REF][START_REF] Stanton | Distributed situation awareness in dynamic systems: theoretical development and application of an ergonomics methodology[END_REF]. Whether situation awareness is purely an "individual psychological phenomenon" [START_REF] Stanton | Is situation awareness all in the mind?[END_REF] or is distributed between human and technical agents continues to be debated [START_REF] Salmon | What Really Is Going on? Review, Critique and Extension of Situation Awareness Theory[END_REF][START_REF] Stanton | Distributed situation awareness in dynamic systems: theoretical development and application of an ergonomics methodology[END_REF][START_REF] Stanton | Is situation awareness all in the mind?[END_REF][START_REF] Endsley | Automation and Situation Awareness[END_REF]. However, applications of situation awareness theory and systems have been largely limited to military and security domains [START_REF] Salmon | What Really Is Going on? Review, Critique and Extension of Situation Awareness Theory[END_REF][START_REF] Salfinger | Maintaining Situation Awareness Over Time -A Survey on the Evolution Support of Situation Awareness Systems[END_REF].

Recently, Stocker et al. [START_REF] Stocker | Representing situational knowledge acquired from sensor data for atmospheric phenomena[END_REF][START_REF] Stocker | Situational knowledge representation for traffic observed by a pavement vibration sensor network[END_REF][START_REF] Stocker | Disease pressure situation modelling in agriculture[END_REF]] have adopted Situation Theory [START_REF] Barwise | Situations and Attitudes[END_REF][START_REF] Devlin | Logic and Information[END_REF] and technologies [START_REF] Kokar | Ontology-based situation awareness[END_REF] for situation awareness in environmental monitoring. Today, environmental monitoring systems often rely on environmental sensor networks [START_REF] Hart | Environmental Sensor Networks: A revolution in the earth system science?[END_REF] to implement the measurement [START_REF] Finkelstein | Theory and Philosophy of Measurement[END_REF] of properties of physical phenomena over time and space. Data resulting from measurement is collected, processed, and analyzed in order to obtain information about the monitored environment. Environmental monitoring systems are arguably not just technical systems. In fact, on one hand the monitored entities are often organisms or entire ecosystems. On the other hand, people are part of environmental monitoring systems, in roles such as technicians, scientists, or citi-zens. Thus, environmental monitoring systems may perhaps be described as (enviro-)sociotechnical systems [START_REF] Walker | A review of sociotechnical systems theory: a classic concept for new command and control paradigms[END_REF].

Situations are structured parts of reality [START_REF] Devlin | Logic and Information[END_REF]. The concept of situation is interesting in environmental monitoring for at least three reasons. First, the monitored entity is a part of reality. For instance, in urban air pollution monitoring the particular volume of urban ambient air is the monitored entity and is a part of reality. Second, the entity is structured. In our example, the structure of the particular volume of urban ambient air is defined by the relations among the objects that are constituents of the entity, such as particulates and gases. It is properties of such objects that are typically measured. Third, environmental monitoring is concerned with gaining information about the monitored part of reality, i.e. information about situations.

In environmental monitoring, situation awareness is, traditionally, in the mind of people, typically experts. Here, Endsley's model is particularly suitable. However, as the technical components of environmental monitoring systems become increasingly more "intelligent," distributed situation awareness models [START_REF] Stanton | Distributed situation awareness in dynamic systems: theoretical development and application of an ergonomics methodology[END_REF] are of interest as well. Indeed, as the technical components increasingly implement data collection and processing, as well as knowledge extraction and representation, the technical parts can arguably hold higher levels of situation awareness-shared with people, such as scientists.

With increasing automation of data collection, data processing, knowledge extraction, and knowledge representation, it becomes important to automatically model (data) provenance. Provenance enables tracing the processes involved in producing data and knowledge. It can increase confidence in the correctness of situation awareness obtained and maintained by environmental monitoring systems, in particular that of their technical parts. Our aim in this paper is to extend an alignment of ontologies [START_REF] Stocker | Towards an Ontology for Situation Assessment in Environmental Monitoring[END_REF] used in a software framework for situation awareness in environmental monitoring, called Wavellite, with the PROV Ontology (PROV-O) [START_REF] Lebo | PROV-O: The PROV Ontology[END_REF]. As our main contribution, we present the alignment and discuss its application for a concrete example.

Materials and Methods

Wavellite1 [START_REF] Stocker | Representing situational knowledge acquired from sensor data for atmospheric phenomena[END_REF][START_REF] Stocker | Situational knowledge representation for traffic observed by a pavement vibration sensor network[END_REF][START_REF] Stocker | A software framework for situation awareness in environmental monitoring[END_REF] is designed to support the implementation of data collection, data processing, knowledge extraction, and knowledge representation. Collection is, often, for data resulting in measurement implemented by environmental sensor networks. Such data are sensor observations, which are aligned with the term Observation of the Semantic Sensor Network (SSN) ontology [START_REF] Compton | The SSN ontology of the W3C semantic sensor network incubator group[END_REF]. Processing is for dataset observations, which are aligned with the term Observation of the RDF Data Cube Vocabulary (QB) [START_REF] Cyganiak | The RDF Data Cube Vocabulary[END_REF]. Knowledge is for situations and is, specifically, situational knowledge. Situational knowledge is extracted from dataset observations and is represented as Situation, a term of the Situation Theory Ontology (STO) [START_REF] Kokar | Ontology-based situation awareness[END_REF]. An alignment of these three ontologies, plus OWL-Time [START_REF] Hobbs | Time Ontology in OWL[END_REF] and GeoSPARQL [START_REF] Perry | OGC GeoSPARQL -A Geographic Query Language for RDF Data[END_REF] for the representation of time and space, respectively, has been proposed in [START_REF] Stocker | Towards an Ontology for Situation Assessment in Environmental Monitoring[END_REF]. This alignment forms the Wavellite Core Ontology (WCO) which we extended with Wavellite terms (e.g. SensorObservation) to form the Wavellite Entity Ontology (WEO).

Here we modify WCO to include PROV-O, and propose an alignment between PROV-O and WEO. As a result, PROV-O joins the WCO family of upper ontologies used in Wavellite to represent data, knowledge, metadata, and now provenance. We used Protégé2 to create the alignment. Note that such alignment is independent of concrete software implementations, such as Wavellite.

PROV-O is a specification for provenance designed for the representation of the origins of digital objects in form of descriptions "of the entities and activities involved in producing and delivering or otherwise influencing a given object" [START_REF] Gil | PROV Model Primer[END_REF]. In PROV-O, provenance is, generally, of entities, which can be physical, digital, or conceptual. Entities can be derived from other entities and they are generated by activities. Activities are the processes through which entities come into existence. Associated with activities are agents, e.g., persons or, of most interest here, software.

In addition to the ontology alignment, we also extend Wavellite such that the software framework supports the representation of provenance in concrete applications. Thus, provenance records can be persisted and retrieved in a similar manner as sensor observations, dataset observations, and situations are persisted and retrieved in Wavellite.

Results

In this section, we briefly describe the main elements of the alignment. Sensor observation, dataset observation, and situation are digital objects and, thus, PROV-O entities. Aligning sensor observations with PROV-O is extensively addressed in [START_REF] Compton | Sensor Data Provenance: SSNO and PROV-O Together At Last[END_REF]. The authors propose an alignment that aims at reconciling different aspects of modelling sensor observations in the SSN ontology (constrained by its alignment to the DOLCE Ultralite ontology [START_REF] Masolo | WonderWeb Deliverable D17. The WonderWeb Library of Foundational Ontologies and the DOLCE ontology[END_REF]), OGC Observations and Measurements [28], and PROV-O. As a consequence, the resulting alignment relies on the introduction of several additional classes.

We follow [START_REF] Compton | Sensor Data Provenance: SSNO and PROV-O Together At Last[END_REF] by adopting a lightweight subset of the alignment axioms. Specifically, SSN Observation is a sub class of PROV-O Entity; SSN Stimulus is a sub class of PROV-O Activity; and SSN Sensor is a sub class of PROV-O Agent. Sensor observations are generated by stimuli, are attributed to sensors, and stimuli are associated with sensors. Thus, the SSN object property observedBy, used to relate observations and sensors, is a sub property of PROV-O wasAt-tributedTo. In Wavellite, sensor observations are not derived from entities.

Wavellite implements operators that translate sensor observations into dataset observations [START_REF] Stocker | A software framework for situation awareness in environmental monitoring[END_REF]. Translation is an operation. Operators are software and thus PROV-O agents. Operations are PROV-O activities. Operations are associated with operators. Dataset observations may be derived from sensor observations, are attributed to operators, and are generated by operations. Wavellite also implements operators that pro-cess a source set of dataset observations into a target set of dataset observations. Thus, dataset observations may also be derived from dataset observations. Such operators are associates for the processing operation, which uses and generates dataset observations. For instance, the Aggregate operator with function mean and time period hour is a PROV-O agent and associate for the aggregation activity that uses source sets of dataset observations within one hour window and generates a singleton target set with hourly mean dataset observations. Finally, QB DataSet is a PROV-O Entity and datasets can thus be derived from datasets.

STO objects, notably situations, elementary infons, relations, individuals, attributes, and values are PROV-O entities. Any of these objects may be derived from dataset observations. In this case, extraction (or acquisition) operations (PROV-O activities) that are associated with extractors, the operators (PROV-O agents), use dataset observations, and generate STO objects. For instance, a classification operation may be associated with a machine learning operator and classify (use) dataset observations to generate (information about) an individual involved in a situations. However, any STO object may also be derived from STO objects. For instance, given information for storms and the location of drivers, a system may infer information for situations in which drivers are at higher risk due to storms [START_REF] Stocker | A Software System for the Discovery of Situations Involving Drivers in Storms[END_REF].

In Wavellite, PROV-O enables the explicit representation of metadata describing the origin of sensor observations, dataset observations, and situations. This is particularly interesting at the derivation layer of the Wavellite architecture, where applications can implement arbitrary complex chains of dataset processing. By modelling datasets and dataset observations as PROV-O entities, we can explicitly model the derivation of datasets and dataset observations from other datasets and dataset observations, respectively, as well as the responsible processes (activities) and involved software (agents). However, provenance is interesting also at the situation layer of the Wavellite architecture, where applications implement the representation of situational knowledge acquired (extracted) from dataset observations. Here provenance enables Wavellite to relate situational knowledge to the dataset observations from which it is derived and with the agents, e.g. data-driven or physically-based models, and activities involved in knowledge acquisition.

Discussion

This section discusses a concrete example. The scenario builds on related work [START_REF] Stocker | Situational knowledge representation for traffic observed by a pavement vibration sensor network[END_REF][START_REF] Stocker | Making Sense of Sensor Data Using Ontology: A Discussion for Road Vehicle Classification[END_REF] and can be summarized as follows. The pavement of a road section is measured for vibration by a sensor network consisting of accelerometers installed into the ground at one side of the road. Occasionally, vehicles travel the road section and modify the vibration pattern measured by sensors. Using a trained artificial neural network, such patterns can be classified in order to detect and characterize vehicles, for instance as 'light' or 'heavy'. Figure 1 is an example sensor observation in this scenario. As expected, the example relies on the SSN ontology to model (meta-)data about the observation, and on OWL-Time for temporal data. Sensor observations are translated to dataset observations. Figure 3 shows the result of such translation for our example sensor observation. Dataset observation ex:3bc relates to dataset ex:d1 as well as to time and the acceleration value via two component properties. The graph includes provenance information. It states that the dataset observation was generated by the ex:so2do (sensor observation to dataset observation) translation activity associated with the ex:dse (dataset engine) agent. The graph also states that the dataset observation ex:3bc was derived from the sensor observation ex:44b. In the discussed scenario, for a specified time window length and at regular time intervals, dataset observations in time domain are processed to vibration patterns in frequency domain [START_REF] Stocker | Situational knowledge representation for traffic observed by a pavement vibration sensor network[END_REF]. Vibration patterns are dataset observations with component property for time and one component property for each represented frequency component. Vibration patterns are then classified using trained Multi-Layer Perceptron artificial neural networks in order to detect and characterize vehicles travelling on the road section. Characterization determines whether the observed vehicle is light or heavy. Detected vehicles are individuals in situations. We can model such situations as supporting an infon with vehicle-at-relation and two objects, one for the individual vehicle and the other for the temporal location. Figure 4 is an example. The situation supports an infon which states that a vehicle (ex:640) travelling on the road section was detected at 20:05:36 and was characterized as being light. The example also includes provenance information for the vehicle individual. It states that the individual was derived from the ex:aa3 PROV-O Entity (which an expanded graph would additionally type as dataset observation) and that it was generated in the ex:classification PROV-O Activity associated with the ex:se (situation engine) PROV-O Agent.

The discussed example demonstrates how the provenance of information for objects observed in real world situations by an environmental monitoring system can be traced through a complex data processing chain down to the original sensor observa-tions. Provenance also tracks the activities and agents involved in transforming entities. Systems can query the RDF data according to whether the interest is for situational knowledge or for the provenance of such knowledge.

Conclusion

We presented an alignment of a suite of ontologies useful to situation-aware environmental monitoring systems with PROV-O, the W3C provenance ontology. Related work on the alignment of the SSN ontology and PROV-O proved useful here. We have presented a basic alignment of PROV-O with entities beyond sensor observations, required in situation-aware environmental monitoring systems, namely dataset observations and situations.

The discussed example for situations involving vehicles travelling a road section demonstrates how systems can annotate, during processing, sensor observations, datasets and their observations, and situations with provenance information. Provenance can thus support making transparent the often complex data processing and knowledge extraction chains implemented in situation-aware environmental monitoring systems.

There exist several directions for future work. On one hand, our alignment consists of only few key axioms. More work can be done to study how to improve the alignment. On the other hand, the ideas and implementation presented here can be developed for a concrete system and application. The data and provenance information resulting in such a system can be used to more concretely study the potential of provenance information in a situation-aware environmental monitoring system.

Figure 2 Fig. 1 .

 21 Fig. 1. Sensor observation ex:44b that resulted in measurement of road pavement vibration by accelerometer sensing device ex:sd1 on October 24, 2014 at 19:36:57.546 with observation value -0.044921875. For the sake of readability, the graph is split into two sub graphs. Figure (a) shows the feature, sensor, stimulus, and property related to the observation. Figure (b) shows the temporal location and measurement value. The two sub graphs can be joined via node ex:44b.

Fig. 2 .

 2 Fig.2. Provenance information for the example sensor observation (Figure1). Modelled are in particular the involved PROV-O entity, activity, agent and relations among them.

Fig. 3 .

 3 Fig. 3. Dataset observation ex:3bc of dataset ex:d1 with component properties for time and acceleration value. The dataset observation was derived from the sensor observation ex:44b and generated in a translation activity associated to a certain agent.

Fig. 4 .

 4 Fig. 4. Situation supporting a vehicle-at-relation infon involving two objects, an individual light vehicle and a temporal location. The graph also includes provenance information for the vehicle individual.

adfa, p. 1, 2011. © Springer-Verlag Berlin Heidelberg 2011

http://uef.fi/envi/projects/wavellite

http://protege.stanford.edu

Acknowledgements

This research is funded by the Academy of Finland project "FResCo: High-quality Measurement Infrastructure for Future Resilient Control Systems" (Grant number 264060).


Jamie Vleeshouwer
email: jamie.vleeshouwer@csiro.au

Nicholas J Car

John Hornbuckle

A Cotton Irrigator's Decision Support System and Benchmarking Tool using National, Regional and Local Data

Keywords: irrigation, satellite data, weather station, mobile phone app, evapotranspiration

We are developing a smart phone application that provides irrigation water management advice using satellite imagery, weather stations and fieldscale farmer provided data.

To provide tailored advice we use high resolution satellite imagery with national coverage provided by Google Earth Engine services to estimate fieldspecific crop growth information -crop coefficients -and we are among the first systems to do so. These coefficients combined with regional scale weather station data for major cotton growing regions and farmer-supplied data means we can run daily water balance calculations for every individual cotton field in Australia and provide irrigation decision support advice.

We are using automated data processing to ensure the latest satellite and weather data is used for advice without manual effort.

We will also deliver benchmarking data to farmers based on their previous seasons as well as peers' farms in order to compare absolute (calculated) and relative (benchmarked) advice.

Background

IrriSAT is a weather based irrigation scheduling service which is used to inform farmers how much water their crop has used and how much how much irrigation they need to apply. Information is produced daily, and can work with different crop types, across large spatial scales. The system is being developed by the Commonwealth and Industrial Research Organisation (CSIRO) for the Cotton Research and Development Corporation (CRDC).

The system uses satellite images to determine the Normalized Difference Vegetation Index (NDVI) for each field, from which the plant canopy size can be determined and a specific crop coefficient (Kc) can be estimated [START_REF] Hornbuckle | IrriSa-tSMS -Irrigation Water Management by Satellite and SMS -A Utilisation Framework[END_REF]. By combining Kc with daily reference Evapotranspiration (ET0) observations from a nearby weather station, the crop water usage can be determined and advice can be provided regarding the amount of irrigation to be applied. adfa, p. 1, 2011. © Springer-Verlag Berlin Heidelberg 2011 Successful trials of the service have previously been undertaken with grape and citrus irrigators, leading to further trials with cotton in the Gwydir, Border Rivers and Lower Namoi valley areas from 2009 -2012. In the final season of these trials, 72 irrigators were using the service, whereby the preferred interface for interacting with the service was via SMS messages. [START_REF] Car | Using a mobile phone Short Messaging Service (SMS) for irrigation scheduling in Australia -Farmers' participation and utility evaluation[END_REF]. The SMS interface allowed an irrigator to enter codes which represented their identity and their fields, along with how much irrigation had been applied to the field (from observed rainfall, or applied by an irrigation system). This information was then used to calculate the daily water balance for their field and provide a response via SMS with the water deficit to aid with managing irrigation schedules.

Whilst the SMS interface provided an efficient way for irrigators to register their data with the IrriSAT service, it was also subject to data entry errors such as codes / water quantities often being mistyped (either by miskeying, or the mobile phone's autocorrect features modifying the inputs). Recent investments will allow the technology overcome these issues and to be further developed for the next generation of services which include: automated near-real time forecasting; regional crop water use productivity benchmarking, and in season yield production. To better deliver these services to irrigator's, smart phone and tablet applications will be developed, along with the required automated data feeds in standardized exchange formats to drive the next generation IrriSAT applications.

The IrriSAT Concept

Rule-based irrigation advice is generated using data from sources shown in Fig. 1 according to the equation (1). The water balance for a crop is determined by representing the field as a closed-system summing the daily calculated water balance of the field which is determined by equation [START_REF] Allen | Crop Evapotranspiration -Guidelines for Computing Crop Water Requirements[END_REF]. The water balance is calculated by subtracting crop evapotranspiration, calculated by reference evapotranspiration multiplied by a crop coefficient (for cotton), from water inputs (irrigation and rainfall). Whilst irrigation and rainfall simply can be obtained observations with appropriate shaping (reduction) functions to cater for runoff, the crop evapotranspiration (ETc) is determined by a variant of the Penman-Montieth equation according to [START_REF] Allen | Crop Evapotranspiration -Guidelines for Computing Crop Water Requirements[END_REF]. The modification is for 'tall crops' which models cotton better than the standard for 'short crops (grass).

𝑊𝑊𝑊𝑊 𝑑𝑑 = ∑ 𝑊𝑊𝑊𝑊 𝑖𝑖 𝑑𝑑 𝑖𝑖 (1)
𝑑𝑑 (𝑑𝑑𝑑𝑑𝑑𝑑 𝑖𝑖𝑖𝑖 𝑠𝑠𝑠𝑠𝑑𝑑𝑠𝑠𝑠𝑠𝑖𝑖) ∈ [1 -𝑖𝑖] 𝑊𝑊𝑊𝑊𝑑𝑑 = 𝑡𝑡𝑠𝑠𝑡𝑡𝑑𝑑𝑡𝑡 𝑠𝑠𝑠𝑠𝑑𝑑𝑠𝑠𝑠𝑠𝑖𝑖 𝑤𝑤𝑑𝑑𝑡𝑡𝑠𝑠𝑤𝑤𝑏𝑏𝑑𝑑𝑡𝑡𝑑𝑑𝑖𝑖𝑎𝑎𝑠𝑠 𝑡𝑡𝑠𝑠 𝑑𝑑𝑑𝑑𝑑𝑑 𝑑𝑑 𝑊𝑊𝑊𝑊 𝑖𝑖 = 𝑆𝑆ℎ 𝐼𝐼 𝐼𝐼 𝑖𝑖 + 𝑆𝑆ℎ 𝑅𝑅 𝑅𝑅 𝑖𝑖 -(𝐸𝐸𝐸𝐸 0 𝐾𝐾 𝑐𝑐 ) (2)
𝑊𝑊𝑊𝑊 𝑖𝑖 = 𝑑𝑑𝑑𝑑𝑖𝑖𝑡𝑡𝑑𝑑 𝑤𝑤𝑑𝑑𝑡𝑡𝑠𝑠𝑤𝑤𝑏𝑏𝑑𝑑𝑡𝑡𝑑𝑑𝑖𝑖𝑎𝑎𝑠𝑠 𝑆𝑆ℎ 𝐼𝐼 = 𝑠𝑠ℎ𝑑𝑑𝑎𝑎𝑖𝑖𝑖𝑖𝑎𝑎 𝑓𝑓𝑓𝑓𝑖𝑖𝑎𝑎𝑡𝑡𝑖𝑖𝑠𝑠𝑖𝑖 𝑓𝑓𝑠𝑠𝑤𝑤 𝑤𝑤𝑑𝑑𝑖𝑖𝑖𝑖𝑓𝑓𝑑𝑑𝑡𝑡𝑡𝑡 𝑆𝑆ℎ 𝑅𝑅 = 𝑠𝑠ℎ𝑑𝑑𝑎𝑎𝑖𝑖𝑖𝑖𝑎𝑎 𝑓𝑓𝑓𝑓𝑖𝑖𝑎𝑎𝑡𝑡𝑖𝑖𝑠𝑠𝑖𝑖 𝑓𝑓𝑠𝑠𝑤𝑤 𝑤𝑤𝑑𝑑𝑖𝑖𝑖𝑖𝑓𝑓𝑑𝑑𝑡𝑡𝑡𝑡 𝐸𝐸𝐸𝐸 0 = 𝑤𝑤𝑠𝑠𝑓𝑓𝑠𝑠𝑤𝑤𝑠𝑠𝑖𝑖𝑎𝑎𝑠𝑠 𝑠𝑠𝑒𝑒𝑑𝑑𝑎𝑎𝑠𝑠𝑡𝑡𝑤𝑤𝑑𝑑𝑖𝑖𝑠𝑠𝑎𝑎𝑖𝑖𝑤𝑤𝑑𝑑𝑡𝑡𝑖𝑖𝑠𝑠𝑖𝑖 𝐾𝐾 𝑐𝑐 = 𝑎𝑎𝑤𝑤𝑠𝑠𝑎𝑎 𝑎𝑎𝑠𝑠𝑠𝑠𝑓𝑓𝑓𝑓𝑖𝑖𝑎𝑎𝑖𝑖𝑠𝑠𝑖𝑖𝑡𝑡
WB d is translated from millimeters depth into irrigation pump run times by knowing the application rate of the field's irrigation system. This allows a user to program a system to run in order to return WB d to zero (or other desired level) without further calculation.

In addition to this water balance rule-based decision support advice, the next generation of IrriSAT will deliver case-based, benchmarked decision support advice to irrigators via the methods described in Section 3.4.

Establishing the Next Generation IrriSAT

In recent years smartphones and tablets have become very popular, and we now aiming to make IrriSAT services more easily accessible through Android and iOS applications. A key factor to making these services functional are the data feeds which are required as inputs to the decision support system (DSS). These data feeds need to be: made available on demand for near real time decision support; be encoded in standardized data exchange formats; and be easily accessible over the internet via web services. Alternate forms of decision support advice are able to generated by nonrule-based artificial intelligence systems such as Case-Based reasoning. The next generation IrriSAT system will test one such form.

Remotely Sensed Imagery

Within previous trials of the IrriSAT service, Landsat 5 imagery was used which provided a spatial resolution of 30m which was sufficient for capturing the spatial variability of the crop water use across an irrigator's field. An email would be sent to the IrriSAT administrator when new Landsat imagery was made available. The tasks the administrator would then undertake would be:

1. Downloaded the latest imagery 2. Manually screen away the clouds based upon inspection within ERDAS IMAGINE 3. Execute an ERDAS script to produce a CSV file containing field Kc values 4. Upload the CSV to the IrriSAT database for further processing This process was often time-consuming for the administrator, and had to be repeated approximately every 8 days as new imagery became available. However recent advancements in accessing remotely sensed data warehouses and executing scientific algorithms aim to make tasks like these mentioned more efficient. Two services currently in development include: The Australian Geoscience Data Cube (AGDC); and Google Earth Engine (GEE). Both of these services utilize supercomputing to allow users to run custom algorithms upon remotely sensed imagery via API's. Here, we have undertaken a scoping study to assess whether GEE is capable of being used for processing the modeling required for the backend IrriSAT services.

The GEE platform allows users to run algorithms on satellite imagery and earth observation data for scientific analyses and visualisation [START_REF] Gorelick | Google Earth Engine[END_REF]. It contains a petabyte-scale archive of global imagery which spans the past 40 years and uses a distributed computational model using a just-in-time approach, meaning that processing is run in real-time, however won't occur until it is required as an output or as an input to another process. This is achieved by exchanging a description of the processing activities and their sequences with GEE servers through a restful web services. Algorithms can be written using the GEE Application Programming Interface (API) which is available in both Python and Javascript programming languages.

For this study we used a combination of Landsat 8 OLI and Landsat 7 ETM+ imagery since the Landsat 5 program is no longer operational. Similarly to Landsat 5, both Landsat 8/7 exhibits a 30m spatial resolution, takes 16 days to observe Earth, and is made available in 8-day cycles. Given that Landsat 8 is offset by 8 days to Landsat 7 our approach was to combine Landsat 8/7. Whilst differences exist between the OLI and ETM+ sensors, it has been shown that the two sensors are broadly compatible across the Australian landscape with differences of approximately 5% for NDVI [START_REF] Flood | Continuity of Reflectance Data between Landsat-7 ETM+ and Landsat-8 OLI, for Both Top-of-Atmosphere and Surface Reflectance: A Study in the Australian Landscape, remote sensing[END_REF]. The approach of combining the two datasets typically provides near full coverage for Australia every 8 days (Fig. 2), which would provide the most up to date crop water usage information to irrigators in near real time.

It is well known that the influence of cloud cover can cause remotely sensed NDVI to be underestimated [START_REF] Liaw | Comparison of Satellite-Derived and Observer-Based Determinations of Cloud Cover Amount at the Southern Great Plains Cloud and Radiation Testbed Site[END_REF]. In order to address this problem we are using the SimpleCloudScore algorithm which is provided within the GEE Algorithms API (Fig. 3). This algorithm works by determining a cloud-likelihood score in the range [0,100] using a combination of brightness, temperature, and NDSI from the TOA reflectance imagery. The SimpleCloudScore algorithm is not a robust cloud detector, and is intended mainly to compare multiple looks at the same point for relative cloud likelihood, however we have found it to give adequate performance at detecting clouds when a cloudlikelihood score threshold of 17 is set. At present, an implementation of the Fmask v3.2 automated cloud detection algorithm (Z. Zhu and C.E. Woodcock, 2012) is being incorporated into the GEE API. The Fmask algorithm is an object-based cloud detection algorithm which is able to detect clouds, cloud shadows and snow with an average overall accuracy of 96.41%. When the algorithm is made available it would be useful to trial it out as cloud shadows can also lead to NDVI misinterpretations.

By combining a cloud mask with the Landsat NDVI datasets available within GEE we are then able to determine the pixels which represent a valid values. Fig. 4. Landsat 8 NDVI for the same day as is Fig. 3. The cloud mask is used the remove pixels which are determined to be invalid data (left). This image is then used to determine the crop coefficient (Kc) for cotton using a linear scaling (right).

Examining one of these fields over the 2013-2014 cotton growing season (Fig. 5) illustrates how the crop coefficient initially starts with values of ~0.1 (bare soil) and increases to ~1.0 (grown cotton), with harvesting taking place usually at the end of the first quarter of each year.

On-Ground Weather Observations

In order to provide regionalized evapotranspiration observations to irrigators, CSIRO maintains a network of Automatic Weather Stations (AWS). These services are cur-rently tightly-coupled to the current IrriSAT system, however we will be working to expose this data via web services. This allows users or devices to be able to query and retrieve observations over the web which will play an important role for consuming data within a mobile app. To improve the accessibility of this data we are currently implementing the Sensor Observation Service (SOS) which provides a way to query real-time sensor data in a standardized data exchange. Utilising this standardized exchange format will allow us to easily expand upon our current coverage of weather stations, allowing us to query and consume SOS observations from other organisations such as the Bureau of Meteorology and also enables this technology to also work internationally.

Irrigation and Rainfall

The mobile app will provide a way for irrigators to enter how much irrigation they have applied to each field, and also how much rainfall has fallen as it occurs. This information needs to be supplied by the user since most irrigation pumps are not telemeted, and rainfall from a nearby weather station is not local enough to accurately determine how much rainfall was observed on their fields. The new application user interface will provide a richer user experience, and more accurate methods of data entry over the previous SMS message approach. The application being developed will be similar in functionality to the Smartirrigation Cotton app (Vellidis et al, 2014) which has been developed for use in the United States (Fig. 6) Fig. 6. Smartirrigation Cotton application developed for iOS

3.4

Benchmarking-Based Irrigation Decision Support

Unlike the previous generation of IrriSAT system, this next generation will deliver advice to irrigators based initially on the water balance (rule-based) system and then, after a season of operation for baselining, advice from a benchmarking, case-based reasoning system will also be delivered. Time-delimited periods of irrigation practice (weekly or monthly) will be treated as cases in a Case-Based Reasoning (CBR), as described by [START_REF] Aamodt | Case-based reasoning: Foundational issues, methodological variations, and system approaches[END_REF]. The input conditions to these cases (the weather and crop data) will be used with a measure of utility of the case results (the irrigation decision(s) made within the timeframe) according to standard CBR methodology. The utility measure will be gathered from yield data at the end of the first season's operation.

From the start of the second season's operation (2015/2016) onwards, the CBR system will compare a current irrigator's situation (the 'current case' in CBR terminology) with past, similar situations (the 'case base') and provide advice in parallel with the rule-based advice. How this advice will be presented to the irrigators is future work.

Conclusion

Through the GEE case study, we have found the API to be adequate for undertaking the desired processing tasks required for determining paddock scale crop coefficients required by IrriSAT. The work from this case study is currently further being integrated into the next generation IrriSAT DSS which will be capable of: providing more regular Kc estimates than previously by using both Landsat 8 and Landsat 7 imagery; and will also provide a completely automated data processing pipeline. Adopting the GEE platform will allow us to access and run algorithms on the full Earth Engine data archive, all using Google's parallel processing platform in real time, enabling the next generation IrriSAT to easily scale across all of Australia.

Exposing the weather observations via SOS allows our applications and any other applications, to easily query and retrieve information over the web. We have currently migrated all historic weather station data into 52 north's SOS implementation. Further work involves developing automated data ingestion routines to ensure the datasets are kept up to date for near-real time accessibility.

Once the application is developed, irrigation information will be able to be collected from a limited selection of farmers throughout the first cotton growing season. This will enable us to develop the benchmarking products required to compare water usage against other cotton irrigators in nearby regions and also against previous growing seasons.

Our use of new and sophisticated datasets and web services at the national and regional (weather station) levels will enable us to avoid much of the data preparation complexity of previous generation DSS. The DSS core application will be capable of requesting information from the external data services to run a water balance calculation; whilst all of the raw data management and preparation steps generating the required products have already been undertaken by the data providers.

Fig. 1 .

 1 Fig. 1. A basic information flow diagram of the IrriSAT system

Fig. 2 .

 2 Fig. 2. Landsat 8 (left), Landsat 7 (centre) and combined Landsat 8/7 (right) TOA reflectance for 16 October 2014

Fig. 3 .

 3 Fig. 3. Illustration of Landsat 8 TOA reflectance for 16 irrigation fields with visible cloud cover (left). The GEE SimpleCloudScore algorithm used to generate a mask for removing cloud cover from Landsat imagery (right). Detected clouds are shown in magenta.

Fig. 5 .

 5 Fig. 5. Crop coefficient for an irrigators field over the 2013-2014 cotton growing season.