## 5 Discussion of the Integration Approach
### Generalizability of the Overall Approach  
We have shown the approach for the specific case of forest fire events, but the approach is generic and can be easily transpose in other domains. For CONAVI, the parameters for every module can be changed easily. Of course, domain expertise is a prerequisite to determine an initial set of keywords and useful ancillary information for other crisis events. Below, we briefly describe two other cases to show how easily the approach can be extended. The first case is an oil spill scenario, such as the one occurred in Mexican gulf in 2010. As for other disasters, the satellite images were used to detect oil spill surface, but also multi modal (_i.e._, microwave) data from RADARSAT-1 SAR satellite were analyzed [45]. On the citizen observation side, several types of data were produced. This included geo-located photos and text messages through CrisisCommons web site [46], but also more structured observations using mobile phone applications, such as oilreporter [47]. The application produces semi-structured data: date, coordinates, oil (value from 0 to 10), wetlands (value from 0 to 10), description (free text) and wildlife (free text), with the first two being generated by the phone's sensors, and the remaining three being the actual observations of the user. It is straightforward to define data and type for this, following the forest fire case. Once ADTs for core data types, e.g., oil spill would have been defined, the phone sensors could be described similar to the earth observation satellite in Section 4.2 and its instantiations in Section 4.3. The message-based information is already captured as part of the VGI sensor contracts. Any further processing would then use both sources as input, facilitate the common access operators as given by DUL and the SSN ontology. The subsequent processing steps and according observation results could then re-apply the mechanisms for instantiation as detailed in Section 4.3: **instance** OBSERVATIONS OilSpill OilReporter OilReporter and so on. As second example, we describe a snow map scenario with weather stations and citizen observations shared via a website. Contrary to remote sensing with satellites, weather stations are _in situ_ sensors. Weather stations are equipped with traditional sensors and the measurements taken include temperature, barometric pressure, humidity, wind speed, wind direction, and precipitation amounts. Snow observation is derived as a function of these measurements. Citizen observation for snow is very popular in UK. The application of the UK snow map project [48], for example, searches Twitter for real-time snow reports and displays them on the map. Citizens tweet their observation using the hash tag \(\#\)uksnow, including location (postcode, town name or geo-tagged tweet), and rating the snow that is falling out of ten (0/10 for nothing to 10/10 for a blizzard). It is also possible to include the depth of snow (cm or inches), attach a photo and add a description to the tweet. It is easy to see the correspondences with the forest fire case. Again, weather stations and required core ADTs could be described similar to the satellite case. We do not expect major differences between remote sensing--as done by satellites or other air born sensor platforms--and _in situ_ measurements as it is the case for many of the weather data sets. Instantiations of these with the reference frame of DUL and SSN will again look similar to the instantiations provided in Section 4.3. The Twitter encapsulation as a VGI sensor is already incorporated in this work. What has to be added is the filtering step using specific keywords. This could be done as an internal state change of the sensor using an instantiation such as **instance** OBSERVATIONS Interest VGISensorSnow VGISensorSnow. Once instantiations are available, all other processing steps would be encapsulated with the patterns discussed before.