Introduction

Climate information is important for scientific research and decision making in order to make climate-sensitive decisions, to develop and evaluate adaptation strategies and to respond and improve resilience to climate change in agriculture, water, health, tourism, environmental protection and other sectors.

The study of climate changes and their impacts requires a multi-dimensional approach which is possible only by using the abilities offered by Geographical Information Systems (GIS). GIS are powerful tools combining all necessary procedures for storage, analysis, integration, modeling and visualization of spatial information for different datasets. As the fields of meteorology and climatology deal with spatial data, the use of GIS has been recognized as very suitable for geospatial analysis, spatial interpolation and visualization of climate data. Although GIS are already widely used in the geo-sciences, their extra value for climatological and especially meteorological applications is still underexploited (Tveito et al. 2008). The potential of GIS in the fields of climatology and meteorology has thoroughly investigated in the frame of the COST Action 719 project (Tveito et al. 2008).

Nowadays, spatial databases are operating in synergy with GIS, as they provide data integrity and consistency checks, concurrent access, backup and recovery procedures, data querying and viewing methods, authorization control, as well as high-performance manipulation operations for spatial data (Elmasri and Navathe 1994; Rigaux et al. 2002). Spatial databases have been utilized by GIS (e.g., Carrera-Hernández and Gaskin 2008) or web-GIS (e.g., Souza Jr. et al. 2009; Bao et al. 2011) environmental applications and for climate data in particular (e.g., Hongjie et al. 2005).

The importance of visualization tools in climate and climate impact research, as well as in communicating results beyond the scientific community, has been already pointed out (Nocke et al. 2008). In the last two decades, climate data visualization services have begun to be provided by web-based platforms of different functionality, spatial/temporal scope and target groups. Most of them are simple but efficient interactive application tools, capable of presenting spatial climate datasets at multiple spatial/temporal resolutions, based on a variety of mapping modeling techniques (e.g. Daly et al. 2004). A critical analysis of 20 selected web-based geo-visualization tools in the field of climate change adaptation, based on their content and functionality, was made by Neset et al. (2016). According to their content, they were characterized as climate-related (managing data about climate variables) or impact-related (managing data about risk and vulnerability). According to their functionality they were characterized as simple data viewers or more sophisticated data explorers. Most of them present moderate or high amount of data and mainly target expert users.

Web-based climate services for historical time periods were developed by the PRISM Climate Group of the Oregon State University for USA and CanadaFootnote 1 (Daly et al. 2008, 2015), the WestMap initiative for the western USA,Footnote 2 the Met Office for United KingdomFootnote 3 (Perry and Hollis 2005) and the Bureau of Meteorology of the Australian Government for Australia.Footnote 4 The University of New HampshireFootnote 5 have developed the Global Rapid Indicator Mapping System (Global-RIMS), which is a fully integrated multi-functional system for online analysis of heterogeneous climate, hydrology and remote sensing data. Climate maps for both historic periods and future projections are produced by the Climate Wizard systemFootnote 6 (Girvetz et al. 2009). The system enable users to specify climatic variables and spatial extent of interest and submit their requests for batch processing. Some other systems, like the ClimateWNA/NA/BC developed by the University of British ColumbiaFootnote 7 (Wang et al. 2012), focus on the generation of climate data for historical time periods and future projections, and not on the cartographic visualization. The cartographic interactivity of the applications presented above is limited, providing gridded climate data at multiple spatial/temporal resolutions as simple digital maps along with downloading services, without tools for analysis.

More recently, advanced cartographic operations are provided for climate data by web-GIS platforms. Production of digital climate atlases is one such implementation paradigm, e.g. the Digital Climatic Atlas of MexicoFootnote 8 (Eguiarte et al. 2010) and the digital climate atlas of the Carpathian regionFootnote 9 (Antolović et al. 2013). Another paradigm is the development of systems for educational purposes, like the Climate web-GIS platform for processing and visualization of meteorological and climate data by the Institute of Monitoring of Climatic and Ecological Systems SB RAS (Gordova et al. 2014). However, web-GIS platforms have been mainly evolved for monitoring the climate and the climate change, providing relevant information to scientists, stake-holders and the general public at different spatial extents.

Alder and Hostetler (2015) have developed the USGS National Climate Change Viewer, which is an easy-to-use web application, able to display future climate and water balance projections over the USA at the local level. They have preprocessed and stored a large amount of files (datasets and reports) in order to generate maps and address user requests, using caching techniques to reduce response time. Another work in the field is the Global Climate Monitor web viewer (Camarillo-Naranjo et al. 2018), comprising a database model and a data geo-visualization web-tool that permits easy access to historic climatic variables and indicators at the global scale. The system is based on open source software, offering besides maps, charts and data downloading services.

In the frame of the project GeoclimaFootnote 10 (Feidas et al. 2012a), a spatial database capable to store, manage and manipulate data directly or indirectly related to climate and its future projections in Greece was developed, along with an interactive web-GIS platform that allows the user to search, analyze and visualize all this information. Geoclima is the first integrated web-mapping system for the climate in Greece. This paper describes in detail the design, implementation and operation of the spatial database and the web-GIS, focusing on the decisions made to fulfill the requirements set.

Requirements analysis and system architecture

This section describes the source data and their processing, the final data produced, the requirements set by users, developers and the operational framework of the system, as well as the overall system architecture.

Data sources and processing

The data processed to produce the final information provided by the web-GIS are based on:

  • Data from 87 weather stations of the Hellenic National Meteorological Service (28 climatic variables, period 1955–2010),

  • Satellite data (precipitation, land surface temperature, vegetation index, cloudiness, instability, period 1998–2010),

  • Projections of future climate change based on existing Regional Climate Model (RCM) simulations for Europe and a supplementary transient high resolution (10 km × 10 km) simulation for Greece over the period 1971–2100 using RegCM3 (Mystakidis et al. 2012),

  • Geographical and topographical data derived by a Digital Elevation Model (DEM), and

  • Socioeconomic data related to climate change (15 parameters, period 1951–2001).

Weather station data were first processed to ensure good data quality, fill missing values and assess their homogeneity (Alexandersson 1986). Then, a statistical and trend analysis was applied on data time series to compute climate normals as average values for a 30-years period (1975–2004) at monthly, seasonal and annual time scales, and to find positive or negative trends for the period 1955–2010 (Marougianni et al. 2012). Finally, station climate normals were interpolated to produce thematic maps by taking into account topographical and geographical parameters (Feidas et al. 2012a, 2012b; Feidas et al. 2014).

Output data categories

The categories of the data that are finally managed by the system are as follows:

  1. a.

    Climatic data for each weather station, for 28 climatic variables (Table 1), at monthly, seasonal and annual time scales:

  • Data series of monthly, seasonal and annual values (period 1955–2010),

  • Trends and statistical significance of the data series (periods 1955–2004 and 1955–2010),

  • Climate normals expressed as three-decade averages (1975–2004).

  1. b.

    Gridded data of interpolated climate normals for the 28 climatic variables, at monthly, seasonal and annual time scales.

  2. c.

    Simulations from regional climate models (PRUDENCE database, ENSEMBLES database and RegCM3 model) for the future changes of seasonal and annual climate variables (Table 2).

  3. d.

    Raster data for the area of Greece:

  • Geographical and topographical data parameters derived by a DEM (Table 3).

  • Land cover (Corine 2000 and GlobeCorine datasets).

  • Satellite-based products provided at the global scale (Table 4).

  1. e.

    Socioeconomic data at the prefecture level, for the period 1951–2011 (Table 5).

  2. f.

    Base maps (Digital Elevation Model, rivers, country boundaries, coastline, settlements, prefecture boundaries, and region boundaries).

Table 1 Climatic variables for each weather station
Full size table
Table 2 Climate variables, spatial resolution and period of simulations from PRUDENCE and ENSEMBLES databases, and RegCM3 model
Full size table
Table 3 Topographical and geographical parameters provided at 0.5 × 0.5 km horizontal spatial resolution
Full size table
Table 4 Satellite-based products
Full size table
Table 5 Socioeconomic data (at the prefecture administrative level)
Full size table

User needs

Three categories of potential users of the system were identified: data providers, cartographers and end-users. Data providers are the scientists from the associated university laboratories that collect and produce the data to be imported into the database. Cartographers are the professionals preparing the thematic maps (web services) provided by the web-GIS. The end-users are the scientists, professionals or the general public that are interested in retrieving and displaying the data from the database. Certain needs were specified from each category.

  1. a.

    Data providers manipulate data in files of different formats. Each file usually corresponds to a specific variable, for a specific area and temporality, at a specific resolution. The main requirement set by data providers was the establishment of an easy, convenient and integrity preserving procedure to import and replace data into the database in the form of whole files, not individual values. No technical knowledge should be necessary.

  2. b.

    Cartographers analyze spatial and alphanumerical data to produce thematic maps. They were asking for a convenient and powerful software tool for database access, cartographic methodologies application (including data classification methods, selection of color palettes, etc.) and web services publication.

  1. c.

    End-users. A survey was performed in order to find out the end-user requirements for searching, displaying and acquiring data. The main result was that a double searching method should be offered. On the one hand, the end-user should be able to select the desired variable and display the corresponding thematic map. Two operations were recognized as important: the identify operation, displaying the value of the variable for a specific point on the map selected by the user, and the selection operation, highlighting the areas on the map that have values in a certain range specified by the user. On the other hand, the end-user should be able to specify a certain point on the Greece extent and display the values for one of the variables, or even all of them, for all seasonal units, in the form of a matrix. Besides the above, we took into account that data should be accessed by end-users easily, in consistent, harmonized and common formats (Parsons 2011).

Maintenance limitations

Another critical requirement was the minimization of the maintenance costs of the system, since the funding of the project was for a certain period of time and future influx of money was unsure. Thus, it was decided to establish an almost fixed relational database schema, able to incorporate with no (or tiny) modifications any new variables, periods, or resolution levels. In addition, all data manipulation procedures were decided to be automated.

Availability and interoperability

In order to make the system available to all users without the need for software downloading and installation, it was decided to adopt the form of a web application. In this way, only a web browser is needed at the client side, along with one auto-installed plug-in. In order to have the data available to other systems (e.g. ArcGIS online, Google Earth), it was decided to deliver data through geographic web services.

Software tools

A common practice for many environmental web mapping applications is the adoption of open source software solutions (e.g., Song et al. 2005; Souza Jr. et al. 2009; Singh et al. 2012; Golhani et al. 2015). Open source approaches benefit from: (a) the reduced or no software purchase costs and (b) the liberty for modifications on source code that allows the development of tailor-made environments. However, as mentioned in (Song et al. 2005), the deployment of an open source system architecture does not mean zero costs. It requires the installation, configuration, development and orchestration of the selected software. These tasks are time consuming, especially for non-technical users or users unfamiliar with these software.

For the Geoclima project, partners had already purchased licenses of the Microsoft SQL Server database management system and the ESRI ArcGIS suite, which provide a unified platform for spatial data management and web-based application orchestration (MacDonald 2001; ESRI 2004; Lobel et al. 2008). Moreover, the developers of the project had already significant development experience on these products. Therefore, the Microsoft SQL Server database management system and the ESRI ArcGIS suite of GIS software were selected as the development tools of the system.

System architecture

The system follows a three-tier architecture, as depicted in Fig. 1. At the data level, the Microsoft SQL Server database management system hosts a relational database incorporating all data that are related to the Geoclima project, as described at the requirements analysis section.

Fig. 1
figure 1

The architecture of the system

Full size image

The application level consists of two main subsystems: the map server (ESRI ArcGIS Server) that delivers the data in the form of geographic web services, and the web-GIS application (based on Microsoft Silverlight platform) that offers an integrated graphical user interface to end-users to perform all operations described at the user requirements analysis subsection. In addition, a separate web application (based on PHP) was implemented to support data providers for their task to import data into the database. A web browser is the only requisite software at the client side (for data providers and end-users), in order to gain the functionality of the system.

Database development

In this section we describe the main database design decisions made in order to fulfill the requirements established in the previous section. In addition, we describe the software tools and procedures used to facilitate data entry into the spatial database by data providers, as well as data transfer and visualization in the web-GIS application.

The vector-raster dilemma

The storage format of the data had been determined before importing the data into the database, based on their nature and their specific characteristics. Data series of meteorological stations, socio-economic variables and some of the base data (rivers, coastline, settlements and boundaries) were in vector format. All other data (climatic normals, climate model simulations, satellite data, topographical and geographical parameters) were in raster format. However, the preservation of the initial raster format into the database would have caused significant difficulties for the desirable querying operations. Although it is rather simple and time-efficient to store a raster file in a raster database table and display it as a raster layer through a web service, it is quite complex to perform searching and combination operations among different raster tables. For example, the construction of a chart for a given point of the Greek area, for all the 28 climatic variables and the 17 seasonal terms (12 months, 4 seasons, annual), would involve 476 raster tables. This kind of operations was not offered by the database management system, neither by the web map server.

The limitations of raster manipulations imposed by the software, along with the requirement to keep database schema modifications at a low rate, have directed the primary design decision to separate variable values from their corresponding geospatial extent. More precisely, all values for all variables were stored to a single non-spatial database table, while each different geospatial grid was stored in a separate vector database table. To recompose the original variable spatial datasets, a number of database views were created, joining together each variable value to the corresponding geospatial cell.

In the following subsection, the conceptual design of the database is presented.

Conceptual design

Figure 2 depicts the UML class diagram representing a simplified version of the conceptual design of the database (Naiburg and Maksimchuk 2001). A description for the classes and associations follows.

Fig. 2
figure 2

The UML class diagram representing a simplified version of the conceptual design of the database

Full size image

Class variable represents the various variables incorporated to the system (e.g. mean air temperature, temperature change at 2 m, data series for total precipitation amount, population etc.). Class season comprises the 17 seasonal terms (12 months, 4 seasons, annual). Class period represents the different reference temporal periods for each variable dataset (e.g. 1975–2004 for the climate normals, 2071–2100 for model simulations, 1991 for population, etc.).

The association class variable list represents the combinations of a variable, a season and a period that corresponds to a variable dataset. For each object of the variable list association class, a number of value triplets (mean, min, max value) are associated from the class group of values. Each such values group is associated with a geographic area from the class geospatial extent. This class is an abstract one, representing all geospatial objects, organized in different subclasses (e.g. the class climatic grid represents the grid cells for the climatic variables, while the class prefecture represents the boundaries of the prefectures of Greece to be associated with the population variable). The name of each subclass is stored in the variable list class (attribute geo extend name). The other two attributes of this class (layer name and service) correspond to the service name (at the map server) and the layer name (displayed in the web-GIS application) that are associated with the variable dataset.

For simplicity reasons, we haven’t include in Fig. 2 the classes for variable categories, variable calculation methods and some other subclasses of the geospatial extend class.

Relational schema

Figure 3 depicts the relational schema of the database. Each class of the UML diagram, with the exception of geospatial extend which is an abstract one, corresponds to a relational table, while associations were implemented as foreign keys. The geo_code field in table group_of_values holds the key of the appropriate spatial extent that the values triplet is related. The appropriate spatial extent is determined by the field geo_extent_name in table variable_list.

Fig. 3
figure 3

The relational schema of the database (simplified version)

Full size image

The presented relation schema implements the main design decision to separate the values from their spatial extent for every spatial dataset to be available thought the web-GIS. To reconstruct the original datasets for presentation and querying, database views were implemented, executing on demand the appropriate join operations, as explained in the next subsection.

Views

Views were created in order to adapt the data contained into the database, to the demands of the web-GIS application. Views are stored queries that do not change the data. They are used to compose and format stored data into dynamic virtual spatial tables that correspond to map layers.

Each view groups the data for one variable and period of time, and joins them with the corresponding spatial information (72 views in total). In this way, distinct layers for each seasonal term of the variable data are created (Fig. 4). More specifically, given a selected variable and period of time, the tables varialble_list, group_of_values and the corresponding spatial one (climatic_grid, predictions_grid, met_station or prefecture) are jointed. The result is a virtual table containing spatial and alphanumeric data for the 17 layers of the selected variable (one for each seasonal term).

Fig. 4
figure 4

Representation of the views’ function

Full size image

Indexes

Indexes in databases are used to speed up the querying process when tables contain several millions of rows. The table group_of_values contains approximately 70 million rows. Moreover, this table is the most frequent queried table of the database, since it is the basic table for view creation. As noted above, views join the group_of_values and the corresponding spatial table on their geo_code column, setting the additional restriction of the desired variable. Therefore, a unique non-clustered index was created on geo_code and variable_list_code columns of the group_of_values table. Another type of indexes that are used in the database is spatial indexes. Spatial indexes were created for all spatial tables on their column which holds the geo-spatial information. This index configuration resulted in a significant reduction of query times.

Data entry application

A separate web application was created in order to facilitate data entry into the spatial database from data providers. The application has two parts: (a) the front-end, which is run on the local computer of each user and (b) the back-end, which is run on the server.

The front-end has a simple user interface (Fig. 5), through which the user can select the function he wants to execute (insert new data or delete already existing data). For the first case, user has to select the category of the data, the text file containing the data and then press the button entitled “Run command”. If the data have already been imported in the database, they are replaced by the new data contained in the text file. The text file used for data import should be formatted according to the category of its data, otherwise error messages are displayed. For the second case (deletion), the user has to select the category of the data and corresponding period, and then press the button entitled “Run command”.

Fig. 5
figure 5

The front-end interface of the data entry application

Full size image

For time optimization, database indexes are automatically dropped and re-created before and after data entry or deletion operations, respectively. In addition, after such a successful operation, appropriate views are created or dropped.

The technologies used for the frond-end was the HTML markup language and the Javascript programming language. There was extended usage of AJAX technology and jQuery libraries for the visualization of the graphic environment and for the programming of the functionality. For the back-end, the PHP programming language was used for the interaction of the web application with the database.

Total datasets

A total number of 18,118 datasets that were incorporated into the database during the Geoclima project, were distributed to the following categories:

  • 16,535 datasets of climatic variables series from the weather stations

  • 153 datasets for trends and statistical significance of climatic variables time series

  • 459 datasets for climate normals of climatic variables series

  • 476 datasets for interpolated climate normals, each consisting of 137,389 cells with a cell size of 0.01o×0.01o

  • 130 datasets for simulations from regional climate models:

  • 40 datasets consisting of 425 cells with a cell size of 0.5o×0.5o

  • 40 datasets consisting of 1617 cells with a cell size of 0.25o×0.25o

  • 50 datasets consisting of 477,607 cells with a cell size of 0.05o×0.05o

  • 153 datasets for satellite-based products:

  • 51 datasets consisting of 96 cells with a cell size of 1o×1o

  • 17 datasets consisting of 1536 cells with a cell size of 0.25o×0.25o

  • 85 datasets consisting of 38,400 cells with a cell size of 0.05o×0.05o

  • 192 datasets for socioeconomic variables

  • 20 datasets for base data (DEM, boundaries, etc.)

Approximately 35 GB of disk space are required for the storage of the above datasets, including indexes.

Geographic web services

Geographic web services are the mechanism through which the data stored in the database are transferred and visualized in the web-GIS application. To create a geographic web service one needs to define the data source and the symbology of each dataset. In the Geoclima system 68 geographic web services were created, one for each view in the database (with the exception of four climatic variables which were excluded from presentation due to low mapping accuracy, e.g. number of days of fog and showers).

The geographic web services were created using ESRI ArcMap software and are published on an ArcGIS for Server installation (Fig. 6).

Fig. 6
figure 6

The geographic web services development process

Full size image

Each geographic web service contains as many layers as the season terms of the respective variable. While visualizing a service, our goal was to enable seasonal comparison by creating common legends for its layers. This was accomplished for most variables by using the equal interval classification method (Robinson et al. 1995). In cases of variables with great seasonal variability (e.g., temperatures, rainfall), we tried to create similar legends for the layers of each service using modified equal interval methods.

The geographic web services derived from the spatial interpolation of climatic data were cached. A cached service is a regular service that has been enhanced to serve maps very quickly using a cache of static images. The map cache is a directory that contains image tiles of a map extent at specific scale levels, pre-populated during service creation. Returning a tile from the cache takes the server much less time than drawing the map image on demand.

Web-GIS implementation and operation

End-users can retrieve information on climate of Greece through the web-GIS application, available on geoclima.aegean.gr. The application mainly consists of an interactive map and provides functionality such as data selection, visualization and querying, map utilities (navigation, overlay, base map selection, etc.), measurement tools, reporting and printing.

Fig. 7
figure 7

Reporting menu

Full size image

The layers displayed by the application are based on the geographic web services already developed and published into the map server. In order to fulfill the requirement of maintainability, all selection parameters in the user-interface (including service names) are dynamically retrieved from the database, without being “hardcoded” to the application. The database schema that we adopted permits the automatic update of these parameters when new datasets are added, without the need to adjust the web-GIS application code.

The main technologies used for the implementation of the application were: HTML, JavaScript, ESRI ArcGIS Server API, REST services and Microsoft Silverlight. Next, the most important functions of the application are presented.

Display of layers

The main objective of the Geoclima system is the display of the spatial distribution of climate variables, such as number of days with rain, wind speed, precipitation and so on. Each variable belongs to one of the following categories: (a) Climatic Data, (b) Climate Models, (c) Satellite Data and (d) Socioeconomic Data. End-user gets access to a sub-menu for selecting a specific variable. For example, clicking on “Climatic Data” tab, an end-user can select though the available lists (combo boxes): a parameter (e.g., Mean Air Temperature), a calculation method (e.g., Spatial Interpolation), a season category (e.g., Month), a month (e.g., January) and a period (e.g., 1975–2004). The specified variable appears in the map as a layer, along with the corresponding legend (Fig. 8a, b, in Appendix).

End-users can interact further with the selected layer by performing queries to it using one of the following options from the “Search” tab:

  • Identification utility (for a point of interest): Clicking on “Identify” button and then on a point on map, end-user gets the value of the variable at the selected point. In Fig. 9 (in Appendix) the Mean Air Temperature for January for the period 1975–2004 at the selected point is 10.29 °C.

  • Select utility (criteria for variable values): End-users can select cells of a layer that meet certain conditions, by issuing queries directly to that layer. This functionality is available by clicking on “Advanced Search” button. By entering the condition (criteria) in an SQL-like format (e.g., value>11) and clicking on “Find” button, the selected cells are highlighted on map. In Fig. 10 (in Appendix) for example, cells where the Mean Air Temperature is above 11 °C for January are highlighted.

Reports

Reporting services operate by allowing the end-user to select specific points of interest interactively on the map. Then, according to the report type requested by the end-user, a wealth of information is retrieved from the database regarding the adjacent area of the point clicked. This information is presented in an easy to read tabular format with appropriate graphical charts (generated automatically), when these are applicable. The reports can be saved in pdf or csv files, for further data analysis procedures.

There are available two general types of reports (Climatic data and Climate model). End-users get access to reporting functionality by clicking on the “Reports” tab, and select the kind of report that they are interested in from the reporting menu (Fig. 7). Each kind of report offers a variety of choices:

  1. a.

    Climatic data: These reports provide information on the climate normals expressed as average values for a 30-years period (1975–2004) at monthly, seasonal and annual time scales for the area of interest. They are further divided into four categories:

  • Station reports for a weather station. The generated report contains the mean seasonal and annual values of all available climatic variables for the selected weather station. To create a station report, a layer with all the available weather stations must first be loaded. Then end-users can generate a station report by clicking on the left icon of the reporting menu (Fig. 7) and on the weather station on the map they are interested in. The reporting service generates a table presenting the seasonal and annual normals as average values for the selected period of all climatic variables at the selected weather station (Fig. 11, in Appendix). Also, a set of graphs depicting the time evolution and trend line of four climatic variables (mean temperature, mean maximum and minimum temperature and precipitation total) for the selected season (winter, spring, summer, autumn or annual) is produced when appropriate (Fig. 12, in Appendix).

  • Simple reports for a variable of interest. The generated report comprises all the values for each month, season and year for the selected point. To generate a simple report end-user must click on the second (from the left) button of the reporting menu (Fig. 7) and select the specific grid cell for which the report will be delivered. In the new screen, the end-user selects a climatic variable and then all monthly, seasonal and annual climate normals are displayed in the report along with automatically generated graphs. For example, a simple report for mean air temperature is shown in Fig. 13 (in Appendix).

  • Multi data reports for a time scale (monthly, seasonal or annual) of interest. The generated report contains the values of all available climatic variables for the selected time scale and point. Multi data reports are similar to simple reports with the difference that the user filters the data by the time scale, instead of filtering by variable. While in the case of simple reports the data of a single variable for all time scales is returned, in the case of multi data reports the data of all variables is returned for one time scale (Fig. 14, in Appendix).

  • User reports: These reports are the more general ones, containing the values of all climatic variables for a given cell, grouped by month, season and year. The user report returns the complete data set for a selected point in the map, namely the normals of all climatic variables over all possible time scales (monthly, seasonal, annual) for the selected period (Fig. 15, in Appendix).

  1. b.

    Climate model: This menu provides reports for the climate model projections of future climate change for the selected area. The end-user can choose between the climate models used for the simulation (PRUDENCE and ENSEBLES database and RegCM3 model simulation). To generate a climate model report, the end-user should click on the icon representing the appropriate model in the reporting menu (Fig. 7), then click on a map point and select a specific grid cell from the popup menu. In the new screen, the user selects a future period (2021–2050 and 2071–2100 are currently available). The report contains the seasonal and annual values of the climate variable changes between the future and control period (1961–1990) at the specified point (Fig. 16, in Appendix)

Evaluation

The evaluation of the Geoclima system has been accomplished in three main directions: validity, performance and usability.

The database design was validated against the requirements set at the beginning of the project one of which was the minimization of the maintenance operations on both database schema and web-GIS application source code. Our decision to separate the spatial and numerical parts of all variable datasets (climatic parameters, satellite products, socioeconomic data, etc.) enables the dynamic addition of any new variable dataset without the need to create new tables. In addition, no modifications are needed at the web-GIS, since both the web service selection user interface and the reporting module are based on a fixed set of database tables.

Spatial gridded data were transformed to vector, rather than raster, tables. Besides the minimization of database schema modifications, this decision also satisfied the requirement of enabling end-users to perform selection and reporting operations on points of the domain, by the execution of SQL queries. Raster tables in ArcSDE, although faster for data visualization, do not permit the execution of these kind of tasks.

In the above context, a number of different database design approaches that are supported by the Microsoft SQL Server database management system have been evaluated for performance issues. The two storage methods for the spatial fields have been tested, i.e. the proprietary SDE_BINARY and the standard GEOMETRY, resulting to the selection of the first one, due to better performance outcomes. The indexing configuration presented at section 3.5 was the result of a number of experiments involving different indexing schemas. Different database views arrangements were also considered. The creation of one view per climatic parameter containing all 17 seasonal terms had performed better than the creation of 17 different views for the same parameter. As MS SQL Server provides indexes instead of pure materialized views, no better results could be obtained at the database level.

Moreover, caching at the map server level has been activated, in order to improve the performance of the geographic web services visualization. Finally, experiments have shown than the execution time for reports tends to stability while the number of records stored at the database increases.

The evaluation of the web-GIS usability was performed by a testing procedure engaging a representative group of end-users. Different use-case scenarios were carried out, each one consisting of a subset of 27 single tasks (Table 6). These tasks were elementary operations to be carried out through the user interface of the web-GIS. All scenarios were completed without any difficulty, while all comments that submitted by end-users, reflected the fulfillment of their needs.

Table 6 Tasks for user-case scenarios
Full size table

Conclusions

This paper described the design, implementation and operation of Geoclima, an integrated spatial database and web-GIS platform for the climate of Greece.

Geoclima is the first web-based mapping system for the climate of Greece. It is an efficient interactive application tool, capable of analyzing, modeling and presenting data for the present and future climate in Greece along with other climate related information (e.g. socioeconomic data). Spatial climate datasets are presented at multiple spatial and temporal resolutions using mapping and analysis tools.

The spatial database ensures the integrity and consistency of the stored data, and provides a set of advantages, such as backup and recovery procedures, data sharing and concurrent access, and authorization control. The design of the database was mainly directed by the requirements of flexible data querying and minimized maintenance cost. The system has a number of automated procedures that ensure its autonomy. Cartographic layers for the variable datasets are dynamically produced through database views and predefined geographic web services. New datasets can be easily added when available, without modifications in database schema and web-GIS application code, thus ensuring system viability.

The web-GIS application utilizes the geographic web services to provide user-friendly cartographic operations for variable datasets, such as thematic maps visualization, display of values for selected areas, and formulation of area selection criteria according to climatic values. In addition, it incorporates a reporting service that provides a rich set of ways for selecting, displaying and downloading climatic values for selected areas.

Geoclima web-GIS application can be operational for a long period of time without update, since it deals with climate data that – by their nature – do not require any frequent update. However, since Microsoft’s Silverlight platform is in the process of trickling out of web technologies (something that could not have been predicted during the development of the system), a new version of the web application is under consideration, based on javascript.