A Web-based spatial decision supporting system for land management and soil conservation

Today it is evident that there are many contrasting demands on our landscape (e.g. food security, more sustainable agriculture, higher income in rural areas, etc.) as well as many land degradation problems. It has been proved that providing operational answers to these demands and problems is extremely difficult. Here we aim to demonstrate that a spatial decision support system based on geospatial cyberinfrastructure (GCI) can address all of the above, so producing a smart system for supporting decision making for agriculture, forestry, and urban planning with respect to the landscape. In this paper, we discuss methods and results of a special kind of GCI architecture, one that is highly focused on land management and soil conservation. The system allows us to obtain dynamic, multidisciplinary, multiscale, and multifunctional answers to agriculture, forestry, and urban planning issues through the Web. The system has been applied to and tested in an area of about 20 000 ha in the south of Italy, within the framework of a European LIFE+ project (SOILCONSWEB). The paper reports – as a case study – results from two different applications dealing with agriculture (olive growth tool) and environmental protection (soil capability to protect groundwater). Developed with the help of end users, the system is starting to be adopted by local communities. The system indirectly explores a change of paradigm for soil and landscape scientists. Indeed, the potential benefit is shown of overcoming current disciplinary fragmentation over landscape issues by offering – through a smart Web-based system – truly integrated geospatial knowledge that may be directly and freely used by any end user (www.landconsultingweb.eu). This may help bridge the last very important divide between scientists working on the landscape and end users.


The land management and soil conservation problem
Land management and soil conservation issues are closely connected to the complexity of our societies.It is evident today that many of the following contrasting pressures coevolve upon our landscape: increasing pressure from the human population, increasing demand for a better environment, increasing demand for more sustainable agriculture, increasing demand for food security, increasing demand for higher income in rural areas, etc.On the other hand, there are many problems affecting our landscape, such as the evident land and soil degradation processes that are unevenly spread across the landscapes of many countries, as well as the very limited awareness of the importance of landscape and soil to our societies.
Published by Copernicus Publications on behalf of the European Geosciences Union.

F. Terribile et al.: A Web-based spatial decision supporting system
Moreover, many strategic high-level policy expectations recall these concepts, for instance by emphasizing the need to combine productivity with more sustainable landscape management, such as in (i) FAO new Strategic Objectives, (ii) Horizon 2020, and (iii) the United Nations' Sustainable Development Goals.
However, this general agreement on the part of policy makers does not always correspond to tools being made available to render this policy goal feasible.
Indeed, there are many problems in making these concepts truly operational since providing an answer to all the above demands together with suitable landscape/farm planning and managing can be very complex.Some examples of these difficulties are as follows: i. difficulties of farmers, farmer associations, municipalities, province, regions or countries in dealing with the multifunctional role of soil and landscape; ii. the need to provide answers to multi-user/multistakeholder communities; iii. limitation of classic top-down approaches to carrying out soil and landscape management and the subsequent high expectation in supposedly integrated governance approaches (including bottom-up contributions by a large spectrum of landscape users and stakeholders); iv.cultural and technical problems due to the great complexity of many agricultural, forestry, and environmental challenges (e.g.nitrate leaching); v. technical problems regarding the lack of both suitable geospatial databases and technical/scientific support to render these databases useful for decision making, including also data quantity/quality variance in space, which leads to heterogeneous geodatabases that are difficult to update; vi. difficulties in quantifying the functions and ecosystem services of soils (e.g.food and other biomass production; storing, filtering, and transformation; habitat and gene pool; physical and cultural environment for humankind; and source of raw materials); vii.difficulties in quantifying soil threats (erosion, landslides, floods, soil sealing, diminishing organic matter, etc.); viii.last, but not least, many agriculture and environmental issues require, as a "must", dynamic answers which vary in time and space (over the landscape).This case is clearly shown in Table 1, which analyses soil and landscape policy requirements, such as those reported in some important EU regulations/directives, together with their dynamic requirements.
In real life, there is an additional problem.Scientific communities which are supposed to address and, eventually, solve many of the above problems are not always predisposed to developing their work within an integrated operational approach.Therefore we claim here that it is essential to do something different.

The spatial decision support approach to addressing the land management and soil conservation problem
We suggest that advanced "spatial decision support systems" (SDSSs) may be of great help in facing these problems.We also claim that well-diffused visualization tools -such as the standard Web-GIS system -are simply not able to address the above challenges well enough.SDSSs already have their own short history (Geertmanand Stillwell, 2009), with successes but also many failures, often relating to the development of very complex systems which are both difficult to operate and difficult to modify.Therefore, it is important here to refer to some examples which appear to be best cases for SDSSs operating in the field of agriculture and environment.
In fact, SDSSs (or differently named but very similar systems) have been developed for many different issues, including (i) accessing forest resource data on a variety of scales (McInerney et al., 2012), (ii) a system for the sustainability of agriculture in a pilot study in Tanzania (Fegraus et al., 2012), (iii) Web service for exploring geospatial cropland data in United States (Han et al., 2012), (iv) supporting fertilization for farmers in the northeast of China (Xie et al., 2012), (v) land use planning and local forestry development under different scenarios of the carbon credit market (Wang et al., 2010), (vi) scheduling deficit irrigation by using the CropSyst model (Marsaland Stockle, 2012), (vii) simulating stream water quality conditions (nitrate and phosphorous) in different scenarios (Booth et al., 2011), and (viii) regional risk assessment (including socioeconomic data) for contaminated sites (Agostini et al., 2012).
It is also very important that there are some cases where SDSSs have been produced by incorporating scalable approaches (Stewart and Purucker, 2011;McInerney et al., 2012) and an integrated crop and soil database system (Y.Yang et al., 2011) to enable efficient modelling and the use of multicriteria SDSS analysis (Agostini et al., 2012;Bottero et al., 2013).In other cases, DSS-integrated systems have been developed to assess climate change over land use (Wenkel et al., 2013), but these are not as yet operational for the Web.
In SDSSs, the Web interactive thematic cartography method for public participation is more often found in urban planning (Zeng et al., 2013).
Only in rare cases -namely outside the area of agriculture and environment -do we find reported the use of fully operational "what-if modelling" engines in SDSSs (Santos et variables or parameters as an input and estimate its impact on performance. These papers applying SDSSs in agriculture and environment clearly show the importance and the rapid, positive progress of this research topic.On the other hand, we must emphasize here that most of the above contributions are somehow sectorial since they focus on a specific topic and, moreover, they do not incorporate the crucial dynamic nature of some environmental data.For instance, this is the case for their climate models, in which the daily climate variationwhich is indeed a key issue in many agriculture environmental applications -is simply missing!Therefore -considering the actual complexity of many current agricultural and environmental challenges -we claim here that there is the need for a very different, much more integrated and operational approach (through the Web) which will hopefully incorporate all of the features reported in Fig. 1.Is this system feasible however?A proper answer requires addressing those features reported in Fig. 1.It is rather evident that some of them are already available in many standard Web-GIS systems (Web-GIS in Fig. 1) -such as user-friendly interface, multiscale, and easy updating of databases -while other features require adding specific new components (then codes) to standard Web-GIS (e.g.multi-functionality, multi-user, bottom-up contributions); this may be a problem in terms of factual implementation.But the real issue relies on the evidence that the above-claimed operational and integrated approach requires some extra key features, which are well above the domain of Web-GIS systems (No Web-GIS in Fig. 1).Most importantly, they relate to the need for dynamic databases (e.g.daily/hourly update of climate maps) and the need for on-the-fly simulation modelling as required by most dynamic applications in agriculture and environment domains (e.g.crop growth or nitrate leaching).Moreover, the required approach requires an easy update of computing codes; this is a key issue to ensure the needed system modularity and flexibility, but again this is rather difficult to be implemented in standard Web-GIS systems.).
Despite these difficulties, here we claim that recent scientific and technological progress, the great improvement in databases, and most importantly new perspective about the role of soil scientists (Bouma, 2015) as well as the awareness about soil multidisciplinarity (Keesstra et al., 2012;Brevik et al., 2015) make it possible to move down a new road.This progress refers to (i) current developments in the availability of spatial data (complex, multiscale, long term, etc.); (ii) progress in soil science, including digital soil mapping engines (e.g.Holleran et al., 2015;Desprats et al., 2013;Jafari and Bakhshandehmehr, 2013;Xu et al., 2015), simula-tion modelling of the SPA (soil-plant-atmosphere) system, and progress in land management studies (García-Orenes et al., 2009;Gao et al., 2014;Leh et al., 2013;Zornoza et al., 2015); (iii) open-source Web-GIS; and (iv) highperformance computing and, especially, GPU processing.Moreover, (v) recent developments in Web-based "geospatial cyberinfrastructure" (GCI) platforms promise to produce efficient and high-performing SDSSs.Indeed, the GCI platform can support the acquisition, storage management, and integration of both advanced and dynamic data (e.g.pedological, daily climatic, and land use), data mining and data visualization, and computer on-the-fly applications in order to perform simulation modelling (e.g.soil-water balance and crop growth), all potentially accessible via the Web, and (vi) new understanding about the key issues of trandisciplinarity and the role of multiple stakeholders (Thomson Klein et al., 2001).

The aim of this research
Thus, the general aim of this contribution is to demonstrate that GCI-SDSSs -strongly rooted in soil -can produce smart, multidisciplinary integrated geospatial knowledge system (as depicted in Fig. 1) to support decision making in many different domains, including agriculture, forestry, and urban planning.All of this is potentially adaptable to any other geographical region; thus this paper seek to promote interest at an international scale.
In order to show the system in operation, this paper also aims to illustrate -as case studies -two very different specific applications, namely olive growth and groundwater protection.
All the above has been achieved within the framework of the EU LIFE+ SOILCONSWEB project.

Materials and methods
In this section, we report -along with study site information -also methodological/technological details about GCI architecture, data, models, and graphical interface (dashboard) behind our GCI system.This choice has been made to enable the reader to easily separate (and then find) details and technicalities about data (e.g.resolution), computing libraries (JavaScript), open-source software, etc. from the main result, which is the actual implementation of the CGI system -and then how all the above data, libraries, models, etc. are implemented together (sometimes writing new codes, new procedures, etc.) to produce the required applications.

The study site
The work was performed in the "Valle Telesina" site in southern Italy (Fig. 2).The area is of about 20 000 ha; it is close to the city of Benevento and encompasses 13 municipalities.It is a very complex landscape with a high soil and climate spatial variability.

Bottom
Valle Telesina has a composite geomorphology and an east-west elongated graben where the Calore River lies.Five different landscape systems are present (Fig. 2): (i) limestone mountains, with volcanic ash deposits at the surface; (ii) hills, comprised of marl arenaceous flysch; (iii) pediment plain, comprised of colluvium material from the slope fan of the limestone reliefs; (iv) ancient alluvial terraces; and (v) the actual alluvial plain.Such complexity is echoed in the 60 soil typological units, aggregated into 47 soil mapping units.
The study area is traditionally suited to the production of high-quality wine (Bonfante et al., 2011) and olive oil in the hilly areas, while beech and chestnut forests are present in the mountain system, where there is a natural park.It is also important to emphasize the fact that, over the last decade, Valle Telesina has experienced a large amount of soil consumption as a result of land use change due to new urbanization.These changes in land use have caused conflicting interests -between agriculture, forestry, and urbanization -and ideas of how the land should be used.

Methodological and technological issues behind the architecture design of the SOILCONSWEB-GCI
The basic architecture of the SOILCONSWEB-GCI was developed by using free, open-source geospatial libraries and programs.Here we describe the main methodological and technological issues relating to both the open-source approach and its capacity to allow users to interact with the environmental and agricultural data on the map directly via the Web.As to "how" these methodological and technological components work together to implement a coherent operational GCI system is described in the Results section.

Solid
The chosen logical architecture has three tiers.It is a client-server architecture in which the presentation, the application processing, and the data management are logically separate processes.The presentation tier displays information relating to the services; the business logic tier controls the application's functionality by performing detailed processing; and, finally, the data tier consists of a database where information is stored and retrieved in such a way as to keep data neutral and independent of application servers or business logic.The main advantages in the use of the three-tier architecture are that (i) complex rules are easy to implement in application servers; (ii) business logic is off-loaded from database servers and clients, which improves performance; (iii) changes to business logic are enforced automatically by servers -changes only require new application server software to be installed; and (iv) application server logic is portable to other database server platforms by virtue of the application software.
Technological details are shown in Fig. 3 (further explanations are given in the Results section).Fundamentally, clientserver communication is based on AJAX (asynchronous JavaScript and XML) technology, and most of the data are transferred from the server to the client in JSON format.The graphs are presented in the user interface using YAHOO Charts as a part of the ExtJS library.AJAX can deliver effective results in terms of user experience and opens up opportunities for further developments.
According to three-tier architecture and AJAX technologies, the presentation tier and a fraction of the business logic tier developed using the JavaScript library have been implemented in the Web clients.The main frameworks used to display and inquire into the geodata were Open Layers and Ex-tJsandGeoExt.OpenLayers is an open-source (provided under a modified BSD license) JavaScript library for displaying map data on Web browsers which provides APIs (application program interfaces) for building rich Web-based geographic applications.SenchaExtJs is one of the fastest JavaScript libraries that allows Web-building applications with a rich set of user widget and data structures.GeoExtis is an extension of ExtJs and links ExtJs and OpenLayers, adding new widgets.In addition, a layer of custom code, which uses the listed frameworks and implements the user interface and a part of the business logic, has been written in JavaScript.
On the server side, the system uses the following extensive technologies: PHP, Apache Web Server, PostgreSQL + PostGIS, and GeoServer, as well as some more specialized technologies such as FPDF (PHP class which allows the generation of PDF files with pure PHP).In order to meet project and user demands, the development of the system required the implementation of new functionalities.In particular, on the basis of the current state of art of the vector data elaboration, PostGISfunctions was used to conduct the innovative vector analysis.Indeed, PostGIS shows interesting characteristics for data extraction from one or more vector layers (such as intersections and overlaps) and massive processing of statistical raster data.Besides PostGIS, a very new approach was used to process raster data by combining original C++ code raster algebra and PostGIS functionality.Accessing raster data (reading and writing) was carried out by GDAL library, which abstracted the access data in various formats, while accessing vector data was carried out by the pqxx (a C++ library for accessing PostgreSQL databases).A notable example is a massive, fast zonal attribute operation on a large layer stack of raster data (mean statistical values extraction/variance/minimum/maximum/pixel count).This allows the analysis of a large number of a raster files with a polygon shape file masking (both optional), where the pixel positioning (inside or outside the polygon) is carried out by PostGIS functions.In other words, via PostGIS, the system decides what the segments (and thus the pixels) of a raster line which belongs to a selected polygon are.The zonal attribute is a recurrent algorithm which is used to extract statistical data from raster data in order to run many tools within our system.Another unique characteristic is a module that uses a port of the SWAP software (Soil -Water -Atmosphere -Plant, originally written by Alterra and Wageningen University; Kroes et al., 2008) for Linux to perform real-time simulations on water balance in the soil-plant-atmosphere continuum.
A key technical issue in the SOILCONSWEB-GCI is the browser-based JavaScript framework OpenLayers, which provides the capacities to view, query, and render thematic layers and related information that is served from WMS and WFS layers (within one map widget) as images.Indeed, a specific functionality of the map viewer is its ability to connect to a wide range of WMS servers by using a WMS end point (either a single layer or entire service).In SOILCONSWEB-GCI, we use a GeoServer server to provide WMS and WFS services to the client application.

Data set
The data set included data and metadata from many different sources -given in Table 2. Data are an essential component of the system, and some data are parameters for feeding many GCI models.The main types of georeferenced data include the following: (i) static data (e.g.thematic databases) dealing with agriculture and environment, (ii) static data obtained from measurements obtained by field-specific survey activities (e.g.soil hydrology), (iii) dynamic data obtained by automated climate stations, and (iv) measurements obtained by remote sensing (e.g.forestry ground biomass stock).
Mapping data (fulfilling the INSPIRE directive) varied in many technical features, and this required a special effort in data harmonization in order to make the whole GSI-SDSS work.The main problems encountered were the following: (i) data resolution of different thematic layers varying greatly in both spatial and temporal domains; (ii) large heterogeneity of data type (for geology, population, soil, water storage, biodiversity, etc.), (iii) data quality heterogeneity (gaps in data were rather common in thematic information), (iv) legal restrictions regarding data to be displayed on the Web (e.g.variations between different data), and (v) structure of data varying greatly (text files, .shp,.grid,qualitative information, etc.); In general terms, the following preprocessing was required to incorporate data into our SOILCONSWEB-GCI.All of the spatial data, namely vector and raster layers (i.e.preexisting thematic maps, remote-sensing data, etc.), at landscape level were re-projected into the local UTM zone 33, datum WGS84.They were checked for anomalies and subjected to up-scaling procedures where required (for instance this was required for high-resolution data for specific applications).Vector data were verified for the information they contained, and redundant data were eliminated (i.e.landscape system maps may have contained information about soils which was already present in the soil maps).Land use maps which referred to different projects or different periods were harmonized if required for specific applications (e.g.land cover; Touring 1954 and Corine 2006 had different classification structures).
Point data, such as those from soil sampling campaigns and forest stand surveys, were checked for anomalies (i.e.spatial coordinates, missing data, etc.).A unique ID was assigned for each type of data (i.e. the codes of soil horizons had to match those of corresponding hydraulic properties).
All data except for those subsequently used for the spatial interpolation procedures (see later) were clipped within the study area.
As regards remote-sensing data, the wet-season data for the 18 December 2008 to 6 March 2009 time span were obtained by SPOT and Landsat platforms, and the dry season, 18 June 2009 to 6 September 2009, data came from the RapidEye, IKONOS, and GeoEye platforms.DEIMOS time series data covered the wet and dry seasons of 2012.Training data were collected from WorldView-2 scenes, and the MODIS time series was classified by using a decision tree.
The architecture provides a service that relies on metadata which are specific to the shared resources.It is an essential component that helps in both resource dissemination and resource locating.One of the advantages of such a service is undoubtedly its ability to link the need to highlight these inherent data to the producers and the final users, who access system resources at their location.According to this vision, all metadata comply with INSPIRE (Commission Regulation Primary and derived data were loaded into the geospatial database (i.e.PostgreSQL plus PostGIS in the database tier of Fig. 3).The geospatial database allows location queries (run in SQL), thereby adding support for geographic objects.This required database harmonization in order to account for differences between data.Some data sets turned out to be significantly richer and more complex (e.g.soil mapping) than others and required additional data processing.Qual-

F. Terribile et al.: A Web-based spatial decision supporting system
ity control assessments were required in order to ensure that database accurately reflected data types, field survey data, etc.This was done to ensure that data contained as few coherency, integrity, and quality issues as possible.Lastly, georeferenced photographs and associated metadata, from field surveys, were also stored on the file system according to the sampling location and associated field description (e.g.site and soil profile morphology).

Models: basic methodological issues
The complexity of the SOILCONSWEB-GCI system is due to the need to assess and analyse the multifunctional role of soils and landscape.This requires the use of a set of models that is capable of evaluating ecosystem services and functions; thus, we had to use different models depending on the type of issue to be tackled, state of the art, data availability, calculating and processing capacity, degree of testing (and acceptance) by the scientific community, and availability of source code.
Consequently, it should be no surprise that, in the SOILCONSWEB-GCI system, we employed all the following: physically based models, empirical models, and other in-between models.
The implementation of models in the GCI sometimes consisted of writing a few lines of program code (e.g Table 3).On the other hand, in other cases it consisted of writing large programs ex novo (such as WeatherProg and cvSISE) or struggling to recompile pre-existing programs on different platforms from those which they were built and tested for (e.g.SWAP).
In general terms, models in the SOILCONSWEB-GSI system were selected bearing in mind future development in new areas.This meant the formulating of problems with a high level of generalization while keeping local empirical approaches as low as possible.In this framework, we selected models which use the following criteria: (i) where possible, attempting to privilege physically based core engines; (ii) coherence with available databases (Terribile et al., 2011); (iii) coherence with the modular structure; (iv) easily interchangeable routines at own convenience (e.g.evapotranspiration, water balance); (v) propensity to include new routines; (vi) possibility to switch the different modules on or off, in accordance with the requirements of the wrapping application; (vii) potential facilities for extensive validation (on the ground or through remote sensing) and potential assimilation of new remote-sensing data; (viii) ease of creating/managing different scenarios (what-if modelling); (ix) real-time or quasi-real-time spatial inference modelling; and (x) compliancy with the Open Geospatial Consortium (OGC) specifications.

Dashboards: basic methodological issues
The need to address a number of online applications required the development of a decision support dashboard for every type of user because each user has different knowledge.This is a very important methodological issue allowing engagement of stakeholders.
Indeed, a single dashboard for all users with many very different tools would create confusion.
The dashboard design had to include graphical tools, procedures to combine spatial data (analysis and visualization), and the production of tables and maps.Moreover, the dashboard also had to enable the activation of algorithms based on different programming languages, databases, graphics packages, architectures, etc.However, all this diversity and complexity of information and processing, even though well documented for the user (full documentation is supplied), had to be hidden in its practical use (transparent to the user).Indeed, the dashboard had to enable easy and intuitive navigation, and, above all, it had to make the user happy to operate it and, possibly, had to remind the user of something that he already knew (visualization, procedures, etc.).The importance of this caution in dashboard planning was a real must and should not be minimized.Indeed, it is evident that this specific feature traces the border between a system that has potential success and a similar one with definite failure.
In the scientific literature, there are many examples of dashboards in different contexts which have been implemented for a very large number of different areas (Sjobergh and Tanaka, 2014;Kijewski-Correa et al., 2014), including sustainable development, tourism, public health, hospital management, etc.Their analysis can be very useful, but any dedicated dashboard has to be calibrated and adapted to a certain type of user (and his own level of knowledge).
Our final result had to be a unique, intuitive, easy-tounderstand/follow dashboard which allowed the user to obtain support for his decisions about the landscape, soil, and environment.To achieve this objective, specific meetings were organized for each type of end user/stakeholder (twothree meetings/groups); they included farmers associations (e.g.Confagricoltura, Coldiretti), Assoenologi, 4 Cantine sociali, ordini Professionali, uff.Regionali SIRCA, etc.These meetings aimed to identify which modules and sub-modules might be the most important and which would be the best for outlining and architecture menu.

Results
The criteria for developing the specific geospatial cyberinfrastructure (SOILCONSWEB-GCI) were indicated above.Therefore, the general objective is to generate solutions for supporting decision making in terms of agriculture, forestry, urban planning, and landscape awareness by developing integrated algorithmic approaches for the analysis of the phys- ical landscape.We aimed to achieve this general objective through approaches which are transparent to the end user.
The system is freely accessible at www.landconsultingweb.eu.
We report the main findings of the SOILCONSWEB-GCI in two separate sections.The first section describes the implementation of the complex GCI architecture that allows the multifunctional applications of the system; the second section describes the application of the system for (i) olive grow-ing in an agriculture/forestry context and (ii) soil capability to protect groundwater pollution in an environmental protection context.

Implementation logic
The end-to-end GCI architecture and operating mode of SOILCONSWEB project is presented in Fig. 3 (CGI core workflow).Here the interaction between the three tiers and the workflow between system components can be observed.A core workflow is where different types of databases (project data) feed the application server by activating different server functions (e.g.models).This in turn produces a set of applied and basic server services (e.g.output of models) that lastly can be accessed by the end user dashboard (GUI).
One key and interesting point is the spatial selection of database (in the database box) which is performed by the AOI (area of interest) drawing tool by which the user (e.g.farmer) can delimit the region of interest (e.g. the farm) within which he can run any implemented tool.In the system, there is a menu enabling the user to explore several possibilities of AOI data input.Indeed, applications typically activate algorithm processing for the polygon (closed arc), which is free-drawn online by the users (by clicking on geographical points) or selected by using pre-existing polygons (e.g.municipalities, cadastral registry land inventory).The AOI may also consist of a number of polygons.Moreover, the AOI might be (i) reedited/deleted, (ii) stored in a personal space, or (iii) made public for general use.All of this is visualized by automatically displaying the arc defined by users on a map.Once drawn, the AOI represents key data stored in a database and linked to the user.
In order to perform the highly complex multifunctional applications on the AOI, it is mandatory that SOILCONSWEB-GCI integrates raw data, data management, data analysis capabilities, and graphical display capacities into a system that is perceived as "easy to use".All of these issues, along with the spatial nature of the data, led us to develop the SOILCONSWEB-GCI platform by using Google Maps as a basic background visualization layer, because of its large use by local communities.On this basis, SOILCONSWEB-GCI incorporated the state-of-the-art optimization algorithms.

Functions
The complex multifunctional and multi-stakeholder tasks required by the SOILCONSWEB-GCI system demanded the use of a set of functions (Fig. 3 -Functions) and, especially, models that are capable of evaluating ecosystem services over the AOI.In accordance with the specific questions to be answered, these multifunctional models range from the physically based to merely empirical similarly to the range of models identified by Bouma (1999) varying from mechanistic holistic (level K4) to qualitative expressions of expert knowledge (level K2).
In general terms, implemented models consist of custom processing routines that have been developed within GeoServer, custom low-level programming language codes (such as C, C++ or FORTRAN), and processing scripts in the R statistical language or MATLAB.These analytical efforts were required to address answers to the ecosystem services/function given in Table 1.
All the models used in the SOILCONSWEB system are part of a modelling chain, and the principle features of each of the main models are given in Table 3.The modelling chain includes -first-level models referring to basic geospatial functions such as spatial inference and zonal statistics of basic environmental variables (e.g.soil, climate); -second-level models, which require first-level models as an input and refer to the basic functioning of the soil-plant-atmosphere system such as soil-water balance models; -third-level models which refer to applications.These typically require first-and/or second-level models as inputs.
The main components of first-, second-, and third-level models were tested and validated as part of different projects (e.g.Basile and Terribile, 2008;Manna et al., 2009;Bonfante et al., 2010).
Below a brief overview of selected implemented models is given in order to clarify how SOILCONSWEB functions.

First-level models (basic geospatial models)
These include core engines, newly written programs, for the spatial inference of basic environmental attributes, in this case climatic variables and soil properties.These fully customized programs provide the spatial and dynamic components to our GCI and populate the second and third modelling levels.

Digital climatic mapping
Climatic data are some of the most important basic information within our GCI.WeatherProg was developed on the basis of previous work (Langella et al., 2010) and is the baseline asynchronous engine for handling the raw weather records within our project (Langella, 2014).The automatic managing of data spans from the raw signals registered by the sensors to the making of digital maps on both hourly and daily timescales.The key objective is to make spatial predictions and build basic informative layers for the various diverse requirements of the GCI.However to make this operation feasible, preliminary treatments are needed.At first, climatic raw data measured at about 30 stations are redirected from the responsible regional agency server to our server.Data are processed according to the following steps: 1. Retrieve.At every event t in time, a secure file transfer protocol (SFTP) synchronization retrieves the current report of climatic data to be processed.

2.
Split.This report is split to create a table for each climatic parameter.
3. Decode.Each record is placed in the database according to its climatic parameter and to its space-time position (i.e.precipitation at day t for station s).

4.
Check.Time series checking to demarcate measured from missing and anomalous data.Anomalies are abnormal measured data and are detected by using a set of differently combined checks, including logical, climatological, spatial, temporal, and persistence checks.

5.
Infill.Gaps due to missing and anomalous data -already flagged as missing -are infilled by using two (or more) competitive interpolation techniques: (i) a deterministic method (e.g.simple moving average with growing kernel and average value for that station and that Julian day) or (ii) statistical method (e.g.multilinear regression using data from other gauges after an optimization procedure).
6. Map.Spatial inference and delivery of digital maps.The output is a multitemporal stack of spatial maps of one or more required climatic parameter.The spatial inference is based on alternative/competitive methods from amongst inverse distance weighting, (multivariate) kriging, and a daily-adapted PRISM-like approach (Daly et al., 2008).
Each step represents a programming node, which can be turned on or off according to the kind of WeatherProg run that is performed.The most commonly used runs can process the daily records and produce the digital climatic maps for that day (the so-called "daily call") or process past missing data that were not available before, for instance due to connection problems (the so-called "integration call").The result of performing a set of automatic runs of WeatherProg is the availability of a complete set of records for point stations and a complete temporal stack of digital maps of all the required climatic variables (such as minimum and maximum air temperature, precipitation, relative humidity, reference evapotranspiration, and solar radiation).

Digital soil mapping
This engine -called cvSISE, Spatial Inference Selector Engine with Cross Validation -performs the spatial inference of pedological properties (Langella et al., 2012).cvSISE was designed, implemented, and deployed to support the routine query by users about the GCI which needs digital soil maps to be available to run attribute space inference systems and give an exhaustive Web-integrated response.In or-der to accomplish this goal, a set of models of spatial inference should be calibrated periodically (within 1-year intervals) to make up-to-date prediction maps.More specifically, at any scheduled time step, the cvSISE engine will only start if modifications of sample points and/or of covariates have occurred.Otherwise the most accurate digital map for any soil attribute which was accounted during the previous step is retained.This checking node enables the detection of new soil records or new/better-defined auxiliary covariates and their automatic inclusion in the spatial modelling of soil properties.When a novel feature becomes available, cvSISE runs and calibrates different types of spatial models, each of which uses a jackknife leave-one-out cross-validation procedure.Finally, the model making the least-noisy proxy for the soil attribute of interest is selected to build the digital map.Different models of spatial interpolation are developed, including the representations given by the reference soil mapping units, inverse distance weighting, ordinary least-squares regression, and different kinds of kriging.
Second-level models: (basic soil-plant-atmosphere models) Among these are physically based SPA hydrological models (Richards based), empirical hydrological models (bucket), and models to obtain bioclimatic indicators (e.g.Winkler).Some of these models can be very complex, and processing can be demanding.One of these cases is the SWAP model, which is applied to find the soil-water balance in the SPA continuum on a daily basis.In this case the model belongs to the physically based family.In the SOILCONSWEB-GCI, the model is applied in both "offline" and on-the-fly mode (see later).SWAP is designed to simulate the soil-water-atmosphere-plant processes with a highly detailed structure for the soil-water module.It is actually a 1-D hydrologic model in which the soil-water balances are based on the Richards equation (Kroes et al., 2006).
This model is usually applied after calibration procedures (see above) that require the monitoring of upper-and lowerboundary conditions (e.g.climate, water table depth) and soil-water status (e.g.soil-water content, soil pressure head).To run, it needs such data inputs as (i) soil data (thickness, horizon sequences, physical and chemical characteristics, soil hydraulic properties, etc.); (ii) climate data with daily time step (rain, temperatures); (iii) plant data (roots depth, LAI, etc.); and (iv) lower-boundary conditions (e.g.dynamics of water table depth, impeding layer, etc.).In SOILCONSWEB-GCI, SWAP runs thanks to the georeferenced data input stored in the project database; this allows the application of the model throughout the study area.
As output, SWAP produces simulated data of soil-plant water balances with a daily time step.These dynamic data may be combined in order to obtain derived functional information or indices (i.e.water stress index: Monaco et al., 2014;Bonfante et al., 2015a, b).In some applications, the

Third-level models (models of applications)
Among these are models for the estimation of erosion (RUSLE); statistical models for the production of reports (mean, max, min, standard deviation, etc.); empirical models to obtain indicators of urban planning (sprawl index) and environmental, agricultural interests; or more complex models such as those for spatiotemporal simulation of the risk of infection by the Plasmopara viticola grapevine fungus.
The complexity in the actual implementation of the modelling engines in the SOILCONSWEB-GCI system varies enormously in accordance with the need to implement onthe-fly simulations and "what-if" modelling engines.
As shown in Table 3, all models employed into the SOILCONSWEB-GCI can be further classified into (i) models not enabling on-the-fly simulation and (ii) models enabling on-the-fly simulation.This classification is important because some models may be used with an offline procedure; in this case pre-processing is required and the output is uploaded onto the server.This applies for many non-dynamic applications (e.g.maps of annual bioclimatic indices) or dynamic applications with a long timescale (e.g.maps of land use change over 2 years).
On the other hand, the need to deliver feedback to daily land and soil management and planning requires SOILCONSWEB-GCI to provide dynamic responses, for instance by taking into account the specific climatic conditions of the current crop year and, therefore, of daily, or even hourly, trends too.This requires the implementation of dynamic models; in other words models "must" operate in real time, so permitting on-the-fly processing over the Internet.
To make the modelling challenges even more complex, we must recall here that real life application in the field of agriculture and environment often requires the inclusion -for some models -of the so-called "what-if" modelling engines.It is evident that the SOILCONSWEB-GCI system cannot include very local scale data/information in its platform, such as those dependent on a specific farmer's management (crop of that year, fertilization, date of sowing, etc.).Thus, we had to develop models which enabled the end user to apply -on the fly -his own parameters, which would then be used in model processing and produce output adapted to specific local conditions.
These what-if models implemented within the SOILCONSWEB-GCI system refer, for instance, to (i) the "soil-water balance" under a specific crop; (ii) "protective capacity of the soil-crop system in terms of groundwater protection", and (iii) the "urban planning options" in terms of their impact on soil ecosystem services.In all these examples, it is essential that the end user inserts some local parameters (crop, sowing date, areas of new urbanization, etc.) in order to make the SOILCONSWEB-GCI models run properly.
Table 3 shows the main models employed by the SOILCONSWEB-GCI and where on-the-fly and what-if modelling engines were implemented.
In most applications, basic statistics of the model output (e.g.mean, min, max, standard deviation) were produced by specific modelling engines.

Server services
The server provides a set of services (some examples are in Fig. 3 -Services) which are implemented by using various technologies and standard formats for data exchange.These services achieve not only technical interoperability but also contextual interoperability, as it mediates between the scripting environment and various client applications.In short, on the basis of data set, models, and modelling output, the system provides services which are accessed by users using various dashboards.These are the following (grouped in the services box in Fig. 3): Map service: the implemented map services are the Web Map Service (WMS) and the Web Feature Service (WFS) both provided by an "instance of" GeoServer.
Model service: this is implemented with a mix of PHP scripts and C/C++/Fortran programs.PHP scripts oversee and control all the mechanisms for exchanging information between different modelling scripts (written in C/C++/Fortran), their operations, and execution.They, also, format the responses and send the results to the client, following the standard interchange protocol.Spatial statistic service: based on the same architecture as model service, this specializes in performing statistical calculations on multiple data sets, such as calculating means and variances in multiple layer stacks.The service summarizes the values of a raster within the zones of another data set (either raster or vector) and presents the results as a table.
Reporting service: based on the server-side PHP library "FPDF", which is expanded with an ad hoc code for data extraction and builds PDF documents from texts, tabular data, and photos under program control.

Dashboards
Due to their nature of being the interface between the SOILCONSWEB-GCI and the end users, dashboards are a key component of the system and may eventually determine its success or failure.Most importantly, they represent a powerful and effective means of engaging stakeholders to design what they expect to be valuable practical results (as highlighted by Bouma et al., 2015).
Hence, the planning, management and update of dashboards are an essential result of the system (Fig. 3 -Dashboards).Moreover, dashboards must be perceived as "very useful" to be successfully employed, and, therefore, they must incorporate tools and processes that are chosen by end users and which help them with their specific soil/land management problems.
On the other hand, dashboards should also be perceived as easy to use.This was obtained by involving end users (e.g.farmer associations as mentioned in the Materials and methods section) in dashboard planning and incorporating in the menu some items that may recall something that a user already knows (images, his farm, etc.).The design (and, therefore, attached functionalities) of these dashboards were the result of a series of interactions with communities of end users/stakeholders.Indeed, some users required the incorporation of complex system facilities such as the following: Remote Internet GIS processing: e.g. to overcome administrative limitations in using GIS desktop software (request by public offices of land planners at PTCP Benevento and forest managers at Regione Campania); On-the-fly graphics: e.g.visual analysis of rainfall and temperature over the last few days in a freely selected area (request by viticulture experts and farmers); On-the-fly simulations: e.g.soil-plant-water stress evaluation to estimate the growing season (request by viticulture experts); What-if algorithm: Evaluation of potential pollution by nitrate towards groundwater (request by regional offices dealing with nitrate directive).
Basically, regardless of the contexts, all dashboards allow land planning and land management through Web-mapping applications, simulation modelling, spatial data reporting, data graphing, photos, etc. Basically, all of these features allow the user to access/explore/visualize both the existing spatial data (geology, soils, etc.) and new data (e.g.plant water stress) obtained by offline and online processing for the whole Valle Telesina landscape.
All dashboards have the same core and multiple adaptations in accordance with specific applications, so the user explores applications, on the basis of his needs, by activating sequential pop-ups which populate all of the dashboard components.
Figure 4 shows the general outline of the dashboard design.Fundamentally, all dashboards have a basic core made up of five different sections (red boxes in Fig. 4) and one section dealing with the required application.From right to left around the central display of Google Maps, there are (i) a user area, where all of the processing/information/data/graphs/maps/statistics requested by the user are recorded and activated upon new request; (ii) Web-GIS facilities, which enable the user to navigate between spa-tial data layers (geology, soil, land use, etc.) for the whole Valle Telesina; (iii) Internet GIS facilities, which enable queries, map services, and other requests to be made by the user as typically occurs in a desktop GIS (without any user need for a software license); (iv) drawing/selection of the area of interest, where the user can interact with the system by drawing his AOI or by selecting pre-existing AOI (e.g.municipalities, land registry inventory ID, etc.); and (v) application dashboards.This last section refers to the specific application chosen by the user, and, therefore, it changes in accordance with the type of user.
During the login, the user is able to activate (click) all or just one of the applications according to his personal interests.In general terms, the dashboard allows navigation that is adapted to multiple geographical levels, and this reflects the need for the user to make decisions on different spatial scales.
The complex user interface of the presentation layer goes far beyond the concept of a lightweight client; it was developed writing a lot of custom codes on the client side on the top of the huge frameworks used.

Applications of SOILCONSWEB-GCI
The GCI system has two broad areas of application: agriculture and forestry, and environmental protection (which include landscape and urban planning).Each of these two applications (and sub-applications) is explored through specific dashboards.Below, we provide a schematic description of two examples of applications.It must be clear from the beginning that these applications represent practical support towards decision making as they cannot and do not intend to substitute technical experts (e.g.soil scientists, olive grove experts,), but they can support these experts to better perform their job.These systems are therefore not in competition with experts since -for instance -many practical issues (e.g.plant disease, water stress, soil local variability, nitrate soil-water content) indeed require very local analysis which can only be performed -for instance -at the scale of a single plant or set of plants.This indicates that the SOILCONSWEG GCI acts as a modern intermediary tool between users of soil information and experts, requiring action by both groups to create synergy.Modern users, particularly the young ones, have grown up with computer games, and this tool is therefore quite suitable to engage them.

Agriculture and forestry (agriculture and forestry Dashboard)
Agriculture and forestry applications allow multiscale, multidisciplinary, multi-stakeholder land planning and land management.The user can either have full access to the whole dashboard (all applications are active) or he can access just a specific application dashboard (then only one application is active).Overall, there are the following five different appli- Here we do not aim to describe all these tools and functionalities; rather we aim to show some operational aspect in using the SOILCONSWEB system in order to provide an insight into the potentiality of the system.This will be performed by showing selected examples of the "olive growing" for a couple of practical applications.Still, the reader can have a broad overview of all functionalities for diverse end users of the olive growing tool in the Supplement.

Application for olive growing: the background and the problem
Olive tree cultivation in Valle Telesina has a very long tradition.In the 1950s it was the dominant agriculture land use (e.g. in 1954 olive groves: 11.1 %; vineyards: 6.7 %), while in last decades it has been overwhelmed by vineyards (e.g. in 2009 olive groves: 15.9 %; vineyards: 33.2 %).Part of this vineyard performance relies on the evidence that wines (and indirectly vineyards) of Valle Telesina are protected by specific designation of origin (DOC, DOCG such as Solopaca, Guardiense), while olive oil is not yet protected.Thus, olive grove farmers are seeking support in their effort to obtain a proper designation of origin labels for their olive oil.
This appears feasible considering that there is a specific ministry decree (D.M. 350/99) aiming to preserve highquality oil (Olio extravergine di Oliva Sannio Caudino Telesino; further info (in Italian) at http://www.agricoltura.regione.campania.it/Tipici/prodotti_tradizionali.htm) and the attested high quality of local oil production (e.g.national prizes have been received by local producers Ercole Olivario and Orciolo D'oro).An additional difficulty -for olive growing farmers -is the evidence that local farmers receive very limited -if any -technical assistance to proper olive growing planning (e.g.choice of varieties) and management (e.g.pest control).In fact, due to severe budget cuts, the Department of Regione Campania for Assistance in Agriculture (SeSIRCA) is no longer in the position to provide the required standard technical assistance to olive growing farmers.
In this specific scenario, we address the following two specific issues to show SOILCONSWEB in operation: Issue A: farmers aiming to evaluate whether their farm is suitable to grow the olive tree variety "Ortolana", which is required to produce the desired high-quality oil "Olio extravergine di Oliva Sannio Caudino Telesino" (as designed by Ministry Decree D.M. 350/99; see above).
This issue is of interest also for the agriculture department of Regione Campania, which aims to evaluate the length of the olive growing season in order to plan and control specific measures related to the Rural Development Plan (RDP) Issue B: farmers seeking help for pest management control and more especially in evaluating the potential rate of olive fly (Bactrocera oleae) attack.In fact this pest has caused huge problems for olive groves in recent years (especially 2013 and 2014).

AOI suitable Draw your Area of Interest
The user draws an area of interest Step 3

Support to the management of your olive-growing farm
The analysis of current climatic trend: Are the climatic conditions favourable to the fly attack?

Issue A Issue B Intrinsic soil protective capability
The user gets a classification of intrinsic soil protective capability based on soil water balances estimated over several years.

Interactive soil protective capability
The user gets a classification of current soil protective capability based on soil water balances estimated over userdefined period.

Draw your Area of Interest
Step 3

Issue C Issue D
The user draws an area of interest

The case study of issue-A farmers
Farmer 1.On the basis of issue A, farmer 1 aims to know if his farm is suitable to grow the olive tree variety Ortolana.
The farmer applies the SOILCONSWEB-CGI dashboard and uses the steps depicted in Fig. 5.He starts selecting (or drawing directly through the Web) the boundaries of his farm (step 1), then considers the general environmental and landscape features of his farm (step 2), and then evaluates bioclimatic indexes of his farm (step 3).Using this procedure, farmer 1 obtained data and maps of his farm as respectively given in Table 4 and Fig. 6 (farm1).Basically, farm 1 yielded good results in both step 2 (suitable soils and suitable environment) and in step 3 (bioclimatic indexes).In fact, the visual examination of Fig. 6 (top) shows an adequate growing season for farm 1 with rather limited spatial variation ranging from 239 to 244 growing days.The mean growing day value of 242 is coherent with the suggested minimum level for olive growing in southern Italy (www.sias.regione.sicilia.it/pdf/manuale_agrofenologia.pdf) of about 242 growing days.As complementary information, spatial variability of soils and solar radiation for farmer 1 is provided in the Supplement.Thus, as a final result, farm 1 may be considered suitable for high-quality olive growing conditions as required by the Ortolana variety.
Farmer 2. On the basis of issue A, farmer 2 also aims to know if his farm is suitable to grow the olive tree variety Ortolana.For the sake of this example, farm 2 has the same shape and the same extension (about 34 ha) of farm 1 but it is located in a different part of the landscape.Farmer 2 follows the same three steps of Fig. 5, obtaining data and maps respectively given in Table 4 and Fig. 6 (farm 2).
Moreover, farm 2 also performs poorly in step 3, defining bioclimatic indexes.In fact, Fig. 6 (bottom) shows a nonadequate growing season for farm 2, with a mean of 190 growing days, which is well below the suggested minimum level for olive growing in southern Italy (about 242 growing days).These results show that farmer 2 has land that is not suitable for olive growth in general and certainly not for producing the high-quality Ortolana variety.

Case study of issue B: farmers
Farmer 1 and 2 seek data to avoid the potential attack of the olive fly (Bactrocera oleae), which causes extensive damage.This can be done indirectly by monitoring the daily temperature at the farm scale.In fact the biology of this insect is strongly related to the temperature gradient (9 • C is the biological baseline); thus when a specific location reaches a critical thermal sum (accumulation of specific amount of thermal units), the insect can complete its biological cycle and the fly attack begin.This critical thermal sum for olive fly is about 379 • (http://www.agrometeorologia.it/documenti/Aiam2000/21_DiLena.pdf).
In Fig. 7 we report a composite figure showing how farm 1 and farm 2 can be monitored by their farmers to know "in real time through the Web" and in any to-be-investigated periods the min and max daily temperatures (daily rainfall is also supplied as a Supplement).
Each farmer can thus evaluate whether his farm reaches a critical threshold for fly attack and can act accordingly.

Environmental protection (environmental dashboard)
Applications for environmental protection allow multidisciplinary, multi-stakeholder land planning and land management for a series of issues relevant to Valle Telesina.In comparison with the agriculture tool, the potential multiscale component of the system is less important here because of the specific type of user.To explain this issue, here we must highlight that in Italy the theme of environmental protection (with the exception of floods and landslides) is typically addressed by (i) one specific category of end user, namely public regional bodies (e.g.Campania region, river basin authority, Comunità Montana), and (ii) by analysing rather coarse spatial scales (often from 1 : 50 000 to coarser).This is because they typically try to produce aggregated planning and management solutions.
In this dashboard (as before) the user can either have full access to the whole dashboard (all applications are active) or he can access just a specific application dashboard (then only one application is active).Overall, there are the follow- As for the case of agriculture, here we do not aim to describe all these tools and functionalities; rather we aim to show selected operational aspect in using the SOILCON-SWEB system in order to provide an insight into the environmental potentiality of the system.This will be performed showing selected examples by using the "soil protective capability towards groundwater pollution" tool.A broad overview of all functionalities is reported in the Supplement.

The background and the problem
The need to protect groundwater from pollution is a worldwide issue; today there is a general consensus about the importance of soils acting as a source of pollutants when specific management is applied to soil (pesticides, nitrates, animal sludge) and most importantly acting as a filter of pollutants.This last soil function is extremely important, and it is well recognized in science and even in laws.With respect to this last issue it is essential here to recall that the following European regulations -directly or indirectly -take on board this soil filter function: Nitrates Directive (Dir.91/676), Water Framework Directive (Dir.60/00), Soil Thematic Strategy (COM 2006/231), groundwater against pollution directive (Dir.80/68), sewage sludge directive (Dir.86/276), and compliance system in agriculture (Reg.(EC) 1782/031783/05ACP).But despite this general consensus and the large number of regulations there are still many problems in achieving an amelioration of groundwater pollution.This issue has been clearly highlighted many times by the European Commission (e.g.COM2015/120; COM2013/683).
In this general scenario, here we focus on two specific issues: Issue C: support to new designation of nitrate-vulnerable zones (also named ZVNs).Regione Campania (as other European regions) for implementing the Water Framework Directive and Nitrate Directive has the obligation to update every 4 years the designation of ZVNs where Action Plans have to be applied.Current designation (Delibera GR no. 700 -18 February 2003;BURC no. 15 -11 March 2013; http: //burc.regione.campania.it)when dealing with soil is rather simple and aggregated being based on soil empirical rules (based on permeability, soil depth, CEC, pH, stones) applied on benchmark soils.Currently, attempting to avoid Nitrate Directive infringement procedures by the European Commission, the Campania region is looking for a more robust zoning procedure to be proposed to the EU (DG-ENV) to ameliorate ZVN designation (also as other pollutants are to be considered).
In this respect SOILCONSWEB can provide a substantial help, offering the use of models (see Table 3a and b) based on the real physical behaviour of the soil.In fact, it is already well established in the scientific literature (Littleboy et al., 1996;De la Rosa and van Diepen, 2002;Rossiter, 2003;FAO, 2007;Manna et al., 2009;Bonfante et al., 2015) that the application of this type of models -even if more complexis by far more robust and better performing than empirical models.Thus, if these models are used, a robust attempt can be made by Regione Campania to avoid or limit all the outcomes from Nitrate Directive infringement procedures.More specifically the applied model produces an index which is a ratio of the incoming yearly water fluxes to that one leaving the bottom of the soil profile IP = 1−flux_OUT / flux_IN).The closer IP is to 1, the higher is the protective capability of the soil towards groundwater pollution.
Issue D: support to farmers to apply for derogation from the prohibition of sewage sludge distribution.In the Campania region (as well as in many other European regions) it is very important to address the critical issue of agronomic use of sewage sludge and protection of water against pollution by nitrates from agricultural sources (regulated by DRD no.160 of 22 April 2013 published in BURC Campania no.22 of 29 April 2013; Technical Appendix at http://www.agricoltura.regione.campania.it/reflui/pdf/DRD_160-22-04-13.pdf).Here the criteria for the derogation from the prohibition of sewage sludge spreading time (typically occurring between 1 December and mid-February) are based on a regional bulletin that takes into account previous and expected rainfall and types of soils.The Campania region is evaluating whether it would be feasible to update and ameliorate the technical procedures (mostly based on rainfall) employed in this bulletin.This issue is a rather hot topic in both policy and agriculture (in Italy and in many EU countries) because farmers have to stock a very large amount of sewage in their farms even if actual soil conditions are prone to sewage distribution.

The SOILCONSWEB solution
The case study of issue C -Regione Campania.This region aims to use a better procedure to designated ZVNs comparing the performance of the standard old empirical approach (actually applied) against the SOILCONSWEB approach to be possibly proposed to the EU.
In order to prove this potential, Regione Campania applies the steps depicted in Fig. 5.They start selecting (or drawing directly through the Web) the boundaries of two AOIhaving the same shape and spatial extent (about 56 ha) -and located (groundwater protection: area 1 and area 2) in different parts of the landscape (step 1); then they evaluate the intrinsic soil protective capability (step 2) as classified in the following four classes: low, moderate, high, and very high  protection capability.In Fig. 8 and Table 4 we report these results, comparing old and new approaches.Using the old system (Table 4), area 1 is classified as "moderate" protection capability class, while using the more robust modelling approach area 1 is classified as a "very high" protection capability class (Table 4).
Then if we examine the spatial variability of the soil protection response between the two approaches (Fig. 8 top), we observe that the old system exhibit no variability between soil mapping units (all soils are classified as moderate), while the new system shows an inner variability between soil mapping units.
Area 2 -classified by the old system -displays a moderate protection class, while the more robust modelling approach classifies area 2 as a "low" protection capability class (Table 4).
Then, in terms of spatial variability, we observe that the old system results in limited variability of the output (all mapping units but one are classified as having moderate protection capability).Unlike before, the new modelling approach shows that the same area 2 has a high variability of output (high CV) between the different soil mapping units (also in Fig. 8 bottom).
In summary, it can be observed that (i) the old empirical system always produces large inaccuracies with respect to the new, better-performing modelling system; (ii) the old system overestimates the moderate class and does not catch the larger range of variability of outputs; (iii) moreover it seems that the old system, due to its rather coarse resolution and analysis, produces rather homogeneous spatial results (homogeneous mapping units), not catching the important differences between soil types (as given in Table 4).To highlight this soil issue, large differences in soil distribution can be observed -by the visual comparison of the 2 AOI.More specifically area 2 (see Table 4) has a volcanic soil with vitric features (Ustivitrand), and this in turn produces -in comparison to area 1 -land which is much less able to protect groundwater.
Thus by using the SOILCONSWEB system, Regione Campania can show to EU Commission that it is possible to substantially ameliorate the designation of vulnerable zones (which of course incorporates also climate, hydrogeology, animal farms, etc.) by ameliorating soil information.
Moreover the evidence that the SOILCONSWEB system produces larger variability between soil mapping units in terms of "protection capability classes" can be beneficial.In fact this may enables better addressing "where" to apply the Action Plans as requested by the Nitrate Directive and possibly better adapting to local conditions.
The case study of issue D: farmers.Here farmers can use the system to support their application to apply for derogation rules from the prohibition of sewage sludge distribution to the Campania region.
End users can use the "interactive soil protection capability towards groundwater pollution" tool at a specific date and for a specific crop in their farm; this in order to evaluate whether to apply or not for derogation.
Farmers apply the steps depicted in Fig. 5.They start selecting (or drawing directly through the Web) the AOI (step 1); then farmers -by an interactive process (e.g.choice of crop) -evaluate the current soil protective capability (step 3) of their farm.Here the SOILCONSWEB system supplies the current soil protection class capability of their farms -which considers the actual variation of soil-water balance and daily climate at the date of this evaluation (in the example: 1 January 2014).
Following the steps reported in Fig. 5, the farmer of area 1 discovers (Table 4 and Fig. 9 top) that his farm has a current very high protection (71 % protection index) towards groundwater; then he can apply for derogation rules and use the SOILCONSWEB system to support his application.In fact a 70 % protection index can be (hypothetically) assumed as a threshold boundary to apply for derogation.In order to test the eligibility to sewage spreading of farmer (area 1), the Regione Campania office can use the same system.Eventually, if the farmer of area 1 gets the derogation from Regione Campania, he can freely distribute the sewage sludge (unless a new rainfall occurs).
Another farmer for area 2 (Fig. 9 bottom) can follow the same procedure to apply for derogation.Differently from the previous farmer, the farmer of area 2 has a farm with only moderate current soil protection capability, having an IP index of about 52 % (last two rows in Table 4).Thus, he will not even apply to derogation.This simple example shows the potentiality of the system also with respect to the transparency and clearness of the information for application, avoiding complex technical interpretation of the applicants, often producing legal conflicts.
The case study of issue D: Regione Campania.Above we have compared two different AOI producing very different soil protection results.Of course this comparison can be replicated between many different sites over the entire landscape.This is very important for Regione Campania, which needs to evaluate the derogation issue over a large region.Thus here we report the variability of current soil protection towards groundwater pollution changing environmental and crop condition.We have analysed our model output -namely the index of soil protection towards groundwater pollutionkeeping constant the shape and surface of the AOI (about 57 ha) and moving the AOI randomly around the main agricultural areas and then over different combinations of soils.Moreover we also simulated the presence of different crops, taking as a reference the main crops of concern in the Valle Telesina area (maize, olive groves, vineyards).
Here we have to recall that -at this stage -the SOILCONSWEB-GCI system does not take on board the key issue of crop management (which depends on local farmers).Thus our index -related to groundwater protection but independent of local management (pesticides, nitrogen, etc.) -is better suited to emphasize issues related to the soil filter capability (e.g.designation vulnerable zones) rather than actual farm management.
The main results of this kind of sensitivity analysis are shown in Fig. 10, where on the abscissa are reported the numbers identifying the spatial location of the AOI and on the ordinate the IP values indicating the percentage of protec-tion capability.For the sake of clarity the AOI were ranked from the lower to the higher IP.Moreover, vertical bars for each AOI represent the variability of the IP with respect to the crop variation.
In general terms the spatial variability of the protection capability -which depend mainly on the soils but also on the different climate -accounts for about 37 % (d s in Fig. 10), while crop variability accounts on average for about 10 %.Only in four-five cases does the soil protection index seem to be not very much affected by the type of crop.Most importantly, in the most vulnerable sites (e.g. for instance those below 70 % threshold soil protection index crop) crop type greatly affects the soil protection index.
Hence, such an analysis, taking into account both environment (soil and climate) and crops, allows Regione Campania to adopt more conservative land management options for designing Action Plans (as required by European directives), differentiating among area at the resolution where real processes (and management) apply.

Discussion
In this paper, we have attempted to prove that geospatial cyberinfrastructure might be the way ahead for soil science applications, given the many diverse landscape issues.In fact, GCI can provide evidence of the central role that soil has in landscape planning and managing operational.In this way, the important, but sometimes vague, concept of soil and landscape multifunctionality can become truly operational.
In addition, SOILCONSWEB-GCI has shown the importance of embodying a multidisciplinary, multi-user, multiscale approach for the construction of a performing SDSS which is able to address the dynamic complexity of many current agricultural and environmental challenges.
In particular, the multi-user feature of the SOILCONSWEB-GCI is evident when navigating between the different types of users provided for by the system, while its multidisciplinary approach is based on the evidence that many of the applications in the fields of agriculture, forestry, land use planning, and environmental protection require close integration between data and models of different natures (geology, soils, vegetation, climate, population, etc.).
The multiscale approach to SOILCONSWEB-GCI is also marked by the fact that some applications need to provide answers on a very local scale, as in the case of the "viticulture for high-quality wine" application or that for forestry, while other applications, such as the one for "spatial planning", require answers on spatially more aggregate scales.Thus SOILCONSWEB-CGI requires an adaptive framework (also in terms of data resolution) for best interaction between data and modelling.
In any case, the system architecture has to be considered flexible and proactive.Indeed, it is designed to be open to further future implementations.
We believe that the great effort involved in implementing SOILCONSWEB-GCI may be useful for future experiments and development of soil-based SDSSs.This motivates us to discuss some key points of this approach and some of the lessons learned.Amongst these, we cite the following: i.It is very important to have procedures which enable automatic or semiautomatic data acquisition, processing, and recording of analytical data in the GCI.Indeed, in facing many current agriculture and environmental problems, these automatic systems are a must.For instance, without such automation, it would be impossible to give dynamic answers (e.g.what-if modelling) to support the daily management/planning of the rural landscape (which may depend, for example, on how much it rained yesterday), and it would be difficult to update -at a sustainable cost -databases (climate, soil, etc.).All this alleviates the need for constant updates and loading of data sets.
In this context, it would also be useful to be able to provide automatic data generation from very different platforms (remote sensing, data, Web, etc.) within a single, robust, and fully integrated analytical infrastructure.
ii.Standard metadata: the project integrates information from many different disciplines.The integration of these data and their scalability requires a much larger effort than for those embedded in the actual specifications of OGC international standards for data exchange.Indeed, these standards are certainly useful in the first phase of database exploration but are not very useful for more detailed analysis or in integrating data from many different platforms, such as remote sensing; socio-economic, residential, and hydrological data obtained from on-the-ground sensors; etc.In order to organize these GCI-based approaches, it would be very important to build/insert an engine capable of integrating different data and metadata, with an appropriate services catalogue.
iii.Flexibility/interoperability: the existing infrastructure must be easily extended to include data/models from different sources (and in very different formats).In fact during the interaction with stakeholders, often new models and new data are demanded, and then they must be incorporated in the system at costs as low as possible.
iv.It is very interesting to note that, in the course of this 5 year project, there has been a rapid evolution in information technology (e.g.GPU processing) and software tools (open-access Web-GIS).This has provided new opportunities for SOILCONWEB-GCI, such as the improvement of on-the-fly simulation modelling procedures.On the other hand, these developments have required computing engineers to be continuously active in adapting the system to new hardware platforms as well as in upgrading to new versions of operating systems.These updates are not always trouble-free, and, in some cases, they can make the whole complex CGI platform risk collapse.Therefore, in this respect, the lesson is to duplicate the CGI platforms in order to have a first platform -not updated but fully operational through the Web and a second platform -on which full updates (e.g.update of operating system, codes) and new developments are made.Only when the second platform is considered stable can it replace the first platform and the two platforms can be switched.
v. The system of dashboards for different applications shows that it is possible to combine many complex interactions within a user-friendly and flexible interface potentially adaptable to the needs of each end user (action at local scale); vi.The contributions and feedback by end users/stakeholders are fundamental for the development and management of these dashboards.This activity, obtained through direct meetings, should also be made possible by means of flexible interactions via the Web, which would facilitate continuous improvement of the system and interface.vii.User community: it is very important to widen as much as possible the group of potential users of these tools and therefore their dashboards too.It would be helpful if some privileged categories of users could design their dashboards themselves.
viii.The openness and integration of the system encourages an increase in local communities' awareness of soil/landscape conservation/sustainable management issues; ix.The system facilitates the incorporation of the key issue of bottom-up contributions to governance.
x.It may be important to seek integration of dashboards into the system of social media and mobile tools to disseminate the results and information better.These technologies offer great opportunities for the future, especially in developing countries, where the use of smartphones is growing exponentially.

Conclusions
Today's society increasingly requires access to information on critical issues such as agriculture, forestry, environment, and urban planning.The access to these data is obviously of primary importance, but if these data are not simply available but rather included in an integrated SDSS GCI (enabling geoprocessing, simulation modelling, etc.), then it is indeed possible to support best decisions/practices which lead to the implementation of sustainable soil/landscape conservation and development.This in turn may be the way to reconcile multifunctional landscape productivity with sustainable landscape management and conservation, while also considering climate change resilience and challenges.In this respect, the SOILCONSWEB-CGI system -freely accessible through Internet browsers and embodying a dynamic SDSS -has proved that this approach is feasible (a gentle introduction to all this issue is available at https: //youtu.be/Of0kzsc6m5w).But this does not mean that the system provides best "solutions", but rather -through modelling -it can provide "options" for the user to choose from.
Moreover this is achieved at a rather low cost of implementation (not considering data acquisition and models testing) when applying the system in new areas.In this respect, the SOILCONSWEB-CGI system -shown here for the Valle Telesina site -has actually been applied/tested (for specific modules) in four other areas (the Etna Volcano area, southern Italy, for viticulture; Lodi plain, northern Italy, for soil sealing; Aversa plain, southern Italy, for groundwater protection; Wachau area, eastern Austria, for viticulture).However, these GCI systems -on a different facet -have a very high cost: scientists, technical assistants, landscape planners and managers, stakeholders, and farmers must abandon some of their certainties and reschedule their work in terms of GCI implementation.Moreover -very importantly -a great effort is required from scientific communities to make GCI perform better in dealing with the following domains: (i) scientific effort to find the most suitable and robust approaches for each application/problem dealing with soil/landscape multifunctionality, (ii) scientific flexibility to develop new procedures/models to be adapted for Web implementation, and (iii) technical effort in order to make fully operational tools.
Here we must conclude by emphasizing that the system -developed with the help of end users -is slowly being adopted by local communities.What is more, the systemindirectly -is also exploring a change of paradigm for soil and landscape scientists.This shows that it is possible to overcome current disciplinary fragmentation over landscape issues and to offer -through a smart Web-based system -a truly integrated geospatial knowledge archive which can be used directly and freely by any end user.This may help span the divide which, for years, has separated scientists working on the landscape from end users.
The Supplement related to this article is available online at doi:10.5194/se-6-903-2015-supplement.

Figure 1 .
Figure 1.Features to be expected of a spatial DSS system in order to address current complexity of agriculture and environmental challenges.

Figure 3 .
Figure 3. Simplified diagram describing SOILCONSWEB geospatial cyberinfrastructure architecture and its main technological components.Abbreviation: GUI -graphical user interface.

(
EC) No. 1205/2008 of 3 December 2008 implementing Directive 2007/2/EC of the European Parliament and of the European Council as regards metadata).

Figure 4 .
Figure 4. Dashboard design.The user can navigate -in accordance with his needs -by using the five different sections (in red).The individual dashboard tools are written in Italian since the system is, for the moment, aimed toward local Italian communities of users.

Figure 5 .
Figure 5. Flow diagram illustrating the steps to be undertaken for addressing issues A-D.

Figure 6 .
Figure 6.Output examples from the support for the olive growth tool: length of the growing season.

Figure 7 .
Figure 7. Output examples from the support for olive growth tool: climate trend.

Figure 8 .
Figure 8.Output examples from the "Soil protective capability towards groundwater pollution" tool: intrinsic soil protective capability.

Figure 9 .
Figure 9. Output examples from the "Soil protective capability towards groundwater pollution" tool: interactive estimate of soil protection capability.

Table 2 .
Main databases employed in SOILCONSWEB-GCI: description of data type and examples of their use/importance in modelling.

www.solid-earth.net/6/903/2015/ Solid Earth, 6, 903-928, 2015 924 F. Terribile et al.: A Web-based spatial decision supporting system
Sensitivity of SOILCONSWEB-GCI with respect to the index (d s ) of soil protection towards groundwater pollution (% of protection on y axes).On the x axes we gave 20 different locations of the AOI (positioned randomly in the main agricultural areas of Valle Telesina).The AOI was kept constant in terms of its the shape and surface (57 ha).Data were plotted ranked on the base of the mean index of soil protection towards groundwater.