Implementation of a webGIS service platform for high mountain climate research: the SHARE GeoNetwork project

Authors


Abstract

The implementation of a webGIS service platform dedicated to the management and sharing of climatological data acquired by high elevation stations is the core of the Station at High Altitude for Research on the Environment (SHARE) GeoNetwork project, promoted by the Ev-K2 CNR Committee. The web platform basically will provide three types of services: structured metadata archive, data and results from high-altitude environments research and projects; access to high-altitude Ev-K2 CNR stations and creation of a network of existing stations; dedicated webGIS for geo-referenced data collected during the research. High elevation environmental and territorial data and metadata are catalogued in a single integrated platform to get access to the information heritage of the SHARE project, using open-source tools: Geonetwork for the metadata catalogue and webGIS resources, and the open-source Weather and Water Database (WDB), developed by the Norwegian Meteorological Institute, for the database information system implementation. The information system is designed to have a main node, with the possibility to install relocated subsystems based on the same technology, named focal point of SHARE, which will contain metadata and data connected to the main node. In this study, a new structure of metadata for the description of the climatological stations is proposed and WDB adaptation and data preprocessing are described in detail, giving code and script samples.

Dataset

Introduction

Mountain areas are an important factor in the climatic system, and they are one of the trigger mechanisms of cyclogenesis in mid latitudes, through their perturbations of large-scale atmospheric flow patterns. They also have an influence on the formation of clouds and precipitation in their vicinity, which are in turn indirect mechanisms of heat and moisture transfer in the vertical. Consequently, the influence of orography on climate needs to be taken into account in a physically meaningful manner. (Beniston et al., 1997). Hence, high mountains provide information that tells us about climatic changes such as melting glaciers and rainfall pattern changes (UNEP, 2009). Monitoring, collecting information and data elaboration from high mountain sites is fundamental to the preservation of mountain ecosystems.

The development of a high mountain meteorological and atmospheric network is essential to monitor the climate change impact on its ecosystem and the resulting feedback on the cryosphere (Grabherr et al., 2000).

Nevertheless, many networks which study climate changes do not include strategic high-altitude locations around the world due to the difficulties in the management of such sites and the only recent understanding of their scientific importance. Pursuing the purpose of safeguarding the environment, since 1987 the Ev-K2 CNR Committee, an autonomous nonprofit association, promotes scientific and technological research in mountain areas accepting the challenge to fill the scarcity of data collected in mountain regions, in spite of the extreme topography and harsh climate conditions that are the main reason for this data gap. Nowadays, the most important monitoring networks, operating around the world that collect climate, atmospheric and terrestrial data, are developed and maintained in the context of international project such as: atmospheric brown clouds (ABC), Aerosol RObotic NETwork (AERONET), coordinated enhanced observing period (CEOP), global atmosphere watch (GAW), International Long-term Ecological Research Network (ILTER), Global Land Ice Measurement from Space (GLIMS), Global Seismographic Network (GSN), and International GNSS (Global Navigation Satellite Systems) Service (IGS). Some of the Ev-K2 CNR network sites (Pyramid Laboratory–Observatory in the Khumbu Valley, and Italian Climate Observatory ‘Ottavio Vittori’ at Mount Cimone) are included in these international projects: ABC, AERONET, CEOP, and GAW.

Since 2005, the Ev-K2 CNR Committee has promoted an integrated environmental project named SHARE (Station at High Altitude for Research on the Environment) focused on the mountain regions as primary indicators of climate change. Originally launched as a system of measurements in environmental and earth sciences in the Himalaya-Karakorum region, SHARE has later expanded its network to Europe (Apennines and Alps), Africa (Rwenzori), and more recently to South America (Andes).

The specific aim of SHARE is improving scientific knowledge on climate variability in mountain regions, ensuring the availability of long-term and high-quality data concerning atmospheric composition, meteorology, glaciology, hydrology, water resources, biodiversity, and human health. SHARE activities also plan to include the design of mitigation and adaptation strategies to oppose the effects of climate change.

The SHARE project is divided in four work packages (WP) and includes the following sectors: scientific research and climate, technological research and climate, information system, and capacity building.

In particular, within the SHARE project, main goal of WP3 (information system) is to implement an High Mountain's Data Information System able to respect the international standards and giving to the scientific community a resource in terms of climate change understanding. In this study, we present some of the actions and activities worked out in the WP3 that will converge in the sharing of data and metadata of high mountains sites, by means of a web services platform named the SHARE Geonetwork. The study has been focused on the presentation of a network and sensors mounted in each station, and on the implementation of a weather open-source database for high-altitude automatic weather stations.

1 The SHARE Geonetwork project

The Share Geonetwork platform for web services is based on the architecture of Geonetwork Open Source for the development of the data and metadata catalogue dedicated to the high-altitude research related to the SHARE project.

1.1 Geonetwork Background

A prototype of the Geonetwork catalogue was developed by the Food and Agriculture Organization of the United Nations (FAO) in 2001 to systematically collect and publish the geographic datasets produced within the organization. Moreover, the World Food Programme (WFP) joined the project and with its contribution the first version of the software was released in 2003. Geonetwork has been developed following the principles of Free and Open-Source Software (FOSS) and based on International and Open Standards for services and protocols, like the ISO-TC211 and the Open Geospatial Consortium (OGC) specifications (OCG, 2012). Currently, there is a big community that uses and develops the Geonetwork software. Geonetwork Open Source consists of:

  • advanced search discovery tools,
  • metadata catalogue, descriptive records for dataset,
  • geographic data and map viewer

Improving sharing and access to data and information by the use of this open-source system, it is possible also adopting two international standards: DUBLIN CORE for general documents and ISO19139 for geographic data. The use of these standards ensure that metadata can be interpreted by software and users and make data and information resources easier to find through the World Wide Web.

In terms of Geonetwork competitors, there are a few open-source projects (e.g. CKAN, geOrchestra, Mdweb, pycsw) that provide metadata through the OGC CSW (Catalog Service for the Web) interface. A couple of proprietary metadata catalogues project focus on very specific user communities like earth observation.

The main advantages of Geonetwork over those catalogue applications are as follows: its huge user community; reliability; performance, compliance, and metadata management functions that have all been tested and used in operational systems for years; in addition offers more standard supports.

Also, Geonetwork team programmers developed an extension to Esri ArcGIS Desktop named GeoCat Bridge to transfer your geospatial data from the desktop to a Spatial Data Infrastructure. It will create the required map services on GeoServer and also in MapServer. Data are transferred to the server platform, storing it on disc or loading it into a PostGIS database. Styling is taken from the ArcGIS project, generating the SLD documents. Metadata are also maintained at the source and transformed into valid ISO 19115 metadata that are published in a Geonetwork catalogue. Esri released their Geoportal toolkit as an open-source product in 2010.

1.2 Geonetwork in the framework of the SHARE Project

The first phase of the SHARE project was dedicated to the completion of the cataloguing system of climate observatories and weather stations in high mountain regions included in the program, following guidelines on the use of metadata for WMO Information System (Tandy, 2010).

In the first phase, a metadata catalogue containing all the data collected has been developed and made available because:

  • metadata are primary to developing any digital collection of files,
  • metadata are important for resource discovery and use,
  • several metadata standards or schemes are used to aid authors to assign metadata to their files.

The new SHARE metadata catalogue allows stakeholders to find if a dataset exists, to identify a contact person for data of interest, and to download actual data from the Geonetwork node if ownership rights permit.

The SHARE Geonetwork provides the connection with the high mountain stations of the SHARE network, giving a new category of data resources. Regarding the metadata of the stations, there is an important improvement of the catalogue due to hierarchical organizations that has been proposed and developed. The stations metadata hierarchy can be synthesized by the model in Figure 1.

Figure 1.

Metadata hierarchy.

Each element of the chain depends on the element from which it derives and generates dependency through logical links. In this model, the network of SHARE stations is the upper hierarchical unit, the first series has its own metadata. Each station has own metadata: abstract, purpose, points of contact, geographical location. Each station is equipped with its own sensors generating measures, also described by the metadata in the form of series and dataset level that describes the data.

Metadata are updated whenever new data are loaded or a change on data, on sensors, on instruments, and in information related on data occurs. Also, new metadata scheme are developed whenever new type of environmental data need to be added to the web-service platform.

1.3 Interactive maps

Geonetwork open source provides Internet access to interactive maps, satellite imagery, and related spatial databases with the possibility of layers management and queries through an integrated WebGIS based on GeoServer software (Pumphrey, 2009). The integration of Google Maps cartographic data in the GeoServer has been developed making available advanced and complete satellite images, street maps, physical maps, and hybrid maps. The system was deeply modified to bring the configurations to the publication of the Google's layers: the main issue is related to the change of the cartographic parameters to make them compatible with the publication in Google. The interface of Geonetwork SHARE was then changed in the configuration files and scripts with their dependencies that concern the segment mapping.

2 The Network and sensors

2.1 Network description

The SHARE monitoring network involves 15 stations (automatic weather stations and laboratories) spread across three continents and four countries (Italy, Nepal, Pakistan, and Uganda, see Table 1).

Table 1. SHARE Network – AMS (Atmospheric monitoring station), AWS (Automatic weather stations).
Installation siteCountryTypeAltitude (m)
Mt. Cimone (Northern Apennines)ItalyAMS2165
Forni glacier (Central Alps, Valtellina)ItalyAWS2669
Dosdè Glacier (Central Alps, Valtellina)ItalyAWS2740
Gigante Glacier (Mt. Bianco, Alps)ItalyAWS3500
Nepal Climate Observatory – Pyramid (Lobuche, Khumbu Valley)NepalAMS5079
Pyramid Laboratory Observatory (Lobuche, Khumbu Valley)NepalAWS5050
Pheriche (Khumbu Valley)NepalAWS4258
Namche Bazaar (Sagarmatha National Park, Khumbu Valley)NepalAWS3560
Lukla (Khumbu Valley)NepalAWS2660
Changri Nup (Changri Nup Glacier)NepalAWS5700
Kala Patthar (Khumbu Valley)NepalAWS5600
Mt Everest South ColNepalAWS8000
Urdukas (Baltoro glacier, Baltistan)PakistanAWS3926
Askole (Baltistan, Pakistan)PakistanAWS3015
Mt. Rwenzori (Elena Glacier)UgandaAWS4700

The majority of installations are in emerging countries where they support local governments in decisions regarding environmental subjects and sustainable development policies.

In Italy, the observation network includes four points: the Italian Climate Observatory ‘O. Vittori’ (ICO-OV) on Mount Cimone; the Forni Glacier AWS; the Dosdè Glacier AWS; and the Gigante Glacier AWS. The installation site at Mount Cimone, the highest peak of the Italian Northern Apennines, is managed by the Institute of Atmospheric Sciences and Climate of the Italian National Research Council (ISAC-CNR), and hosted within the infrastructures of the Italian Air Force Meteorological Service (IAF-MS) Observatory. This station is the 34th global station of GAW and aims to characterize the aerosol properties and the processes that influence the troposphere background conditions. In particular, continuous measurements of particle concentration in the accumulation and coarse mode (since August 2002) and black carbon (BC) concentration (since July 2005) have been conducted at this measurement site (Marinoni et al., 2008). The other three network points, in Forni, Dosdè (in central Alps), and Gigante glaciers (at Mount Bianco) are continuously measuring standard weather parameters such as: air temperature, humidity, wind speed and direction, and solar radiation. Forni is the largest Italian valley glacier (12.5 km2 of surface area) and the AWS analyses the glacier microclimate by collecting surface meteorological data (Citterio et al., 2006). Dosdè is the second Italian permanent station and was installed on 14 August 2007. It is located at 2850 m a.s.l. It permits to collect data on glacial thermal conditions and incoming/outgoing energetic fluxes. This automatic weather station is the highest Lombardy permanent station on glacier and its data are comparable to those collected by AWS Forni to verify the effects of climate change on glacial size and micrometeorological parameters.

The larger number of AWS installed in the middle of Himalaya region are present in Nepal. In fact, Himalaya is very sensitive to climate change due to the high variation in altitudes and Nepal is ranked as the fourth most vulnerable country in the world based on 2010 vulnerability assessment and mapping of climate change vulnerable countries (Ueno et al., 1996, 2001; Tartari et al., 1998 1998; Bertolani et al., 2000; Bollasina et al., 2002; Ueno & Pokhrel, 2002; Bonasoni et al., 2010a; Siddiqui et al., 2012). The Nepal network allows to have meteorological and atmospheric measurements varying in altitude from about 2500–8000 m above the sea level. In particular, automatic weather station has been installed in Khumbu Valley, in Changri Nup Glacier, and in the Everest South Col to measure meteorological parameters (see Figure 2)

Figure 2.

Nepal monitoring network. Map extracted from SHARE Geonetwork.

Particularly important is the Nepal Climate Observatory–Pyramid composed by an atmospheric monitor station (ABC-Pyramid at 5079 m a.s.l.) and an automatic weather station (5050 m a.s.l.). These installations were deemed to be essential to obtain information on the atmospheric background conditions of this region (Bollasina et al., 2002).

The atmospheric monitor station has been equipped to perform continuous measurements of chemical (organic and inorganic, soluble and insoluble), physical (mass and number size distribution), and optical (absorption and scattering coefficients) properties of aerosol. Surface ozone and climate altering halocarbon concentrations are also measured at ABC-Pyramid. Within the AERONET program Aerosol sun photometry studies are carried out as well (Bonasoni et al., 2007).

The so-called Pakistan Karakorum Network includes two stations, Askole and Urdukas, and has been installed with the objective to obtain, by measurements of atmospheric and hydrological parameters, a complete meteo-climatic characterization of the Upper Indus Basin and the understanding of the interaction between western weather patterns and monsoon circulation in the Northern Pakistan region (Bonasoni et al., 2010b).

In Uganda, there is only a single SHARE station installed on the Rwenzori range. This is one of the most important glacial systems on the African continent. An AWS on the foot of the Elena glacier, in the western part of the Stanley Plateau at 4700 m above the sea level, has been installed.

This tropical alpine glacier is an important reservoirs of fresh water that stores seasonal inputs of precipitation, linked to the movement of the Intertropical Convergence Zone (ITCZ), and sustains meltwater discharges during drier periods (Taylor et al., 2009). Despite the adverse environmental and logistic conditions of the site, the Ruwenzori AWS has allowed a satisfactory analysis of the meteorological conditions, covering data since July 2006 (Lentini et al., 2011).

In Appendix are summarized the sensors mounted in each station and laboratories.

2.2 Data validation

The meteorological data collected were validated in two different ways, from 2002 to 2009 the validation followed the guidelines defined within the CEOP criteria (Coordinated Energy and Water Observation Project) (CEOP-HE), whereas, from 2010 to 2011, the validation process took place under WMO recommendations on quality control and data validations, as per WMO reference document (Zahumensky, 2004).

The CEOP criteria are based on a visual check, looking for extremely and unusual low/high values and/or periods with constant values. Nocturnal radiation data have been checked for nonzero values, wind speed, and direction for sensor freezing and/or unusual high values. Where possible, cross-checking among the variation of different measured parameters (e.g. precipitation with relative humidity) was also performed to assure the consistency among the variations of different variables under the same conditions. The quality control flags follow the CEOP data flag definition document and defines the data as ‘bad’, ‘dubious’, ‘good’, ‘inconsistent’, and ‘interpolated’ Dew Point Temperature, Specific Humidity, and U and V Wind components and are computed using ‘CEOP Derived Parameter Equations’.

Data collected from 2009 up to now are validated following the WMO recommendation (Zahumensky, 2004). WMO defines the data recorded by the AWS loggers in their original format according to the original sampling interval and before any averaging as Raw Data.

For the SHARE-AWS, raw data storage is managed by the AWS manufacturer, and any direct intervention on the acquisition procedures is related to manufacturer interventions. For most of the SHARE-AWS, due to memory storage and data transmission limitations, only automatically processed data (averaged, cumulated, or instantaneous values on 1-h or 30-min basis) are stored by data loggers. Processed data are automatically calculated by applying gross automatic data validity checking (basic quality control procedures) on original raw data. Automated quality checks are based on rough plausibility checks designed to remove erroneous sensor information (i.e. recorded values should not exceed the instrumental range). Processed data represent the SHARE-AWS Level-0 data and are defined as data that derive from valid raw data reduction or averaging. According to this definition, for the SHARE-AWS, processed data are represented by the Level-0 data, i.e. 1-h or 30-min averaged/cumulated/instantaneous data which are calculated by the data logger from valid raw data.

Quality control and validation procedures on processed data are undergone at the Ev-K2-CNR Data Processing Center, internal consistency (plausible value check, time consistency check) and intervariable consistency are checked. After quality checks and visual inspection by operators at the Ev-K2-CNR Data Processing Center, processed data are reduced to the Level 1 (data with quality flags: ‘bad’, ‘dubious’, ‘good’, ‘inconsistent’) and Level 2 (only data flagged as ‘Good’).

In the validation of rain data, there are problems in terms of continuity, and in that case, the null value's validation criterion (essentially the choice of flag Good or Dubious) of precipitation is different. Modification in validation process is in progress to overcome this gap.

3 Database implementation

As mentioned above, data acquired from high elevation sites allow researchers to improve their understanding of how mountain climate affect global climate. Following this challenge, Ev-K2-CNR Committee has built up a data network that is currently unique, as certified in the partnership with international research programs (see 'Introduction') and the increasing interest of researchers. The huge quantity of data collected by the Ev-K2-CNR Committee needs to be ordered, stored, and maintained in a coherent form. To handle this task, we have constructed a data information system built around a database management system (DBMS). In the future, this information system will be extended to collect data also from other data providers (not only from the Ev-K2-CNR Committee) to further facilitate the in-depth study of mountain ecosystems in general.

The project required a database system that was efficient, proven, standard complaints, easy to maintain, adaptable, and based on open-source principles. Consequently, the project oriented towards the use of the Weather and Water Database (WDB) system, developed by the Norwegian Meteorological Institute (Institute, 2012). WDB is a database system designed to store meteorological, hydrological, and oceanographic data. The system is capable of handling field data (meteorological forecasts and analysis, oceanographic wave, and circulation models) as well as observations and point forecasts.

WDB is an open-source system, its core is a list of SQL function that built the database schema and form the Command Interface (WCI). WDB is developed using PostgreSQL extended with PostGIS, and other open-source components: GRIB API, and GNU tools (e.g. g++, libtool, etc.). It runs on Linux and is released under GPL (GNU General Public License). The licence means that it may be used, modified, and distributed by anyone free of charge for any purpose, be it private, commercial, or academic.

WDB is a proven and reliable system, and it has been a critical component in the Norwegian Meteorological Institute's information infrastructure since 2009. Among other uses at the institute, it is the central data storage component in the yr.no weather service, the most popular Scandinavian weather service with more than five million unique users each week (as of 2012). The system remains in active development, and continues to be modified to make it easier to use, deploy, and maintain and to adapt it to new usage areas within meteorology.

The main features of the WDB system are as follows:

  • to support high availability production services (as a data storage solution for real-time and archive data)
  • to support most types of meteorological, hydrological, and oceanographic data
  • to provide a flexible system that can easily be extended with new data types and data formats
  • to be easy (and cheap) to maintain and operate
  • to provide a simple and consistent interface to all the different kinds of data

3.1 Material and methods

WDB version 1.2.0 (currently 1.5.0 is released) was installed on a Linux machine running Debian version 6.0 (i386) (codename ‘squeeze’). Some adjustments had to be made in the installation process, as the documentation was found to be not always up to date. There were also a number of issues caused by version discrepancies between the libraries used in Debian and Ubuntu (the system used at the Norwegian Meteorological Institute). To support the execution of SQL statement pgAdmin3 has been installed, an open-source programme to administrate and to develop platform for PostgreSQL. The WDB system itself offers an API (the WDB Call Interface or WCI), based on function calls executed through SQL that can be used to both read and write data to the database. The benefit of this layer of abstraction is that it allows the underlying tables and views to be modified easily, without requiring changes in the client programmes.

Data from AWS, whether raw or validated, must be loaded in the database whenever it is necessary, and made it available to the researchers' community via web queries. The process from data harvesting to web queries is sketched in Figure 3.

Figure 3.

Data flow: from harvesting to web queries.

Before the loading process to the database, two operations are required: (1) database adaptation; (2) data preprocessing. The first operation includes WDB settings and parameters addition according to physical quantity and elaborations from AWS. The second operation is writing or coding data from AWS in a compatible way with the WDB metadata scheme for point data. Finally, a PHP page is the core of the connection between the database and the web queries.

3.2 WDB adaptation

WDB is a general database for storage weather/water data and at the time, this project started, was primarily optimized for storing gridded data (version 1.5 added significant new functionality and optimizations directed at point data storage). In this section, we discuss the adaptations and customizations carried out in the Share Geonetwork project to adapt and customize WDB for storing point data from AWSs at high altitude.

A data item in WDB is either a number or a grid, and could be either an observation, a forecast, or an analysis. Each data value is uniquely identified and described by a set of dimensions. These dimensions are as follows: data provider; place; reference time; valid time; value parameter; level; and data version (Table 2). These dimensions are the entry point into the database, and are used for the purpose of searching for and retrieving data.

Table 2. Data dimensions.
DimensionDescription
Data provideridentifies the source of the data; or literally, the entity that provides the data
Place (geographic location)the position of the item on the Earth in a 2D space. In WDB, the geographic location is specified using longitude and latitude in a WGS84 coordinate system by default (though this can be changed when database is set up). It is possible to search for data using coordinates, as well as place names defined in the metadata referring to coordinates. Searches can be prefixed with a spatial interpolation option such as ‘nearest’ or ‘bilinear’
Reference timeis the moment when the data item is referenced from. For forecast data, this would typically be the reference time of the data values the forecast is based upon; for observation data, it would typically be the time when the observation data was recorded
Valid timeis the time period for which the data item is valid. The valid time is always stored in the database as a time interval (in the case of a time point, the interval would simply have a distance of 0)
Value parametereach data value can be described using a ‘value parameter’. The value parameter is a name that describes the physical or code table basis of the parameter value. The value parameter concept in WCI is broadly similar to the concept of meteorological parameter used in, e.g. GRIB files and is based on the CF metadata standard
Levelis normally used to designate the altitude or depth of the data value. Level is designated using a level interval (height from and to) and a level parameter (e.g. height above sea level, pressure)
Data versionthere can be several different versions of the same data value that is valid for the same time, position, etc. This can happen with probability forecast calculations or when a data value is edited

Before we explain the dimensions, it is necessary to understand the concept of a namespace, as it is used in the WDB system. WDB defines three namespaces: a data provider namespace, a place namespace, and a parameter namespace. The namespace is essentially a mapping from a set of names to a set of metadata. This allows for a great deal of flexibility in handling the complexities of real-life metadata. For instance, a meteorological station may be identified by several different indicators or index numbers; each of these indicators may be defined within their own namespace. Similarly, a place will often have different names in different languages; namespaces allow each language to be separated out so that one can have one namespace containing the English names, and another containing Italian names. The only restriction, in this context, is that each metadata item is unique within a namespace to facilitate effective search and data retrieval.

Namespaces are identified using a numerical ID. The default namespace ID is 0, which contains metadata automatically generated from the base metadata in the database. The namespaces from 1 to 254 are reserved for usage by WMO centres; all other numbers can be freely used to define project/institute-specific namespaces.

Before any other WCI function call, wci.begin(‘user’) initializes the WDB Call Interface for a specific user, with the users default namespace.

The default installation of WDB contains only a limited subset of basic metadata; for instance, it contains only 62 of the most common meteorological parameters. Thus, it is usually recommended to define a new namespace and add metadata as required by the application. It is possible to define a new namespace using the WCI function: wci.addNamespace(). The next script (Figure 4) is used to configure the WDB system setting the new namespace, the data provider and organization, new persons involved in the use of the database and adding new high mountain sites.

Figure 4.

WDB setting script: new namespace, organization, and new persons adding.

The next step to set up the system giving whole metadata information is the addition of the new data providers and station points (see Figure 5).

Figure 5.

WDB setting script: data provider and new high mountain sites adding.

In this project, the field dataProviderName in the function wci.adddataprovider() is set to be ‘Ev-k2-CNR Committee’. Each dataProviderName is the unique ID of the data provider within its namespace. A data provider is qualified by its type (e.g. computer system, names observation site, person, ship) and domain delivery (point, grid, or any). The latter information helps the database to optimize queries. Before data can be loaded, the database needs to be seeded with the appropriate value parameters. Using the wci.addparameter() function, we have added about 600 new parameters to fit with the search and retrieval patterns required by our data retrieval service (see Figure 6). Once the system has been set up with appropriate metadata, it is possible to load data into the database system.

Figure 6.

WDB setting script: new parameters adding.

3.3 Data loading

The function wci.write() is used to load data: it executes an SQL statement and loads data point in the database (see Figure 7).

Figure 7.

WDB loading script: wci.write().

Before starting any loading operation the verification that all the metadata information is properly set in the database is required. ‘data provider’ and ‘placename’ has been set in adaptation step, whereas ‘value’, ‘referencetime’, ‘validtimefrom’, ‘validtimeto’, ‘levelparameter’, ‘levelfrom’, and ‘levelto’ are picked up directly from AWS files. Using a script developed at met.no (wdb-fastload utility) it is possible to load a large amount of data that take a text data format from standard input and copy it into the database.

Data from the stations, raw or validated, have a well-defined format; hence, before starting loading data preprocessing is required. The preprocessing core is a Python script that takes the raw or validated file as input and converts it in a wdb-fastload format (see Figure 8). To make the loading operations simple and fast, we have developed a Python GUI using the programme Glade (see Figure 9). With this loading tool is possible adding new data provider in the database (only for administrator users), convert files into wdb-fastload format (now for 15 data format corresponding to the AWS data logger) and then load the selected and converted file in the database.

Figure 8.

Python conversion format script.

Figure 9.

Python GUI for loading data and metadata into the database.

Via this graphical tool it is possible also for unskilled users to load AWS data without having to launch command in a text shell (see Figure 9).

Web queries from SHARE Geonetwork website

Data access is now possible with the new version of SHARE Geonetwork platform (published in November 2013) visiting the address http://www.geonetwork.evk2cnr.org/index.php (see Figure 10).

Figure 10.

Homepage SHARE Geonetwork website.

In the section: ‘SEARCH IN HIGH ALTITUDE AND ENVIRONMENTAL DATA’, choosing the radio button ‘dataset’, the user can query the high-altitude dataset, both raw (only for authorized users) and validated data. Validated data are quickly available after a registration process, by clicking on ‘Register now!’ (see Figure 11). The .csv is the unique data download format at the moment. In the future, netCDF data format will be implemented for download.

Figure 11.

Login as registered member form.

After login, the user will be capable to download validated data after a simple query process (see Figure 12). The query process is quite simple, it comprises four selection steps: the data provider selection, the AWS selection, the date and the interval of time selection, and the physical parameter selection. The core of this page is the connection with WDB and the use of the function wci.read() (see Figure 13).

Figure 12.

Query form example.

Figure 13.

PHP connection script to WDB and the use of the function wci.read().

Pressing the search button icon the user obtain the result in a tabular or graphical form, if ‘Table’ or ‘Graph’ button is pressed (mutually exclusive radio buttons) see Figures 14 and 15.

Figure 14.

Tabular query result.

Figure 15.

Graphical query result.

Raw data are available after formal request to the EvK2 CNR Committee via ‘Contact us’ section, in the web-site header, or using the ‘data request form’ (see Figure. 16).

Figure 16.

Reserved access area warning.

4 Discussion

This work has focused its efforts on the need for cataloguing high elevation environmental and territorial data and metadata in a single integrated platform to get access to the information heritage of the SHARE project.

The SHARE Geonetwork web platform will provide basically three types of services:

  • structured metadata archive, data and results from high-altitude environments researches and projects
  • access to high-altitude Ev K2 CNR stations and creation of a network of existing stations
  • dedicated WEBGIS for geo-referenced data collected during the research.

The huge amount of information available in this web platform is organized by themes and macrocategories of reference, corresponding to the scientific disciplines of interest (see Figure 17):

  • Stations at High Altitude
  • Atmosphere and Climate
  • Ecosystems and Biodiversity
  • Geology and Geophysics
  • Glaciers
  • Ground data
  • Health
Figure 17.

SHARE Geonetwork selectable resources.

A system of hierarchical privileges, roles, and user groups to manage users and permissions to access, modification, and data downloading have been designed. For the access to public information, there are no restrictions, while in order to have access to specific information or functionality, an account that will be provided by the system administrator will be required. Also, it will be possible to read the information about a resource, download, or browse interactively data for that resource depending on the role of an authenticated user and privileges set for the metadata record. Authenticated users (and depending on privileges) can create, import, and edit metadata records. They can also upload and configure data links for interactive map. Each authenticated user is assigned to a particular working group and it is able to view the data within that group (Figure 18). The core of the information system is installed in a server located at the Ev-K2 CNR Committee Centre in Bergamo (main node), but there is the possibility to install relocated subsystems based on the same technology, named focal point of SHARE, which will contain metadata and data connected to the main node. Each focal point has its own region of interest and the system will be able to make a search on all nodes simultaneously. This distributed system enhances the efficiency in terms of speed of access to resources.

Figure 18.

SHARE Geonetwork user hierarchy.

In Geonetwork open source, this feature is called harvesting: with this function it is possible to find specific information residing on different nodes installed worldwide and periodically copy and store this information locally.

In this way, an user from a single point of access may also obtain information from distributed catalogues. Through the technology of harvesting could be scheduled periodically the reading of information from databases located in different parts of the world and as a result selection of data obtained from a survey distributed in a single Web page return.

To extend the network with the partnership of other data provider, the Database system is implemented taking into account the input of new metadata sets and new data formats. In fact, for each new high-altitude weather station it is possible to translate the native data format in accord with the metadata set required in WDB. We plan to develop a graphical query client for data retrieval and statistical queries, as well as the option to download data from queries in netCDF format.

5 Conclusions

The SHARE project and the SHARE Geonetwork in particular were born from the necessity to improve the knowledge of mountains ecosystem and sharing data and metadata with the scientific community. These data are collected by direct observations from climatic and meteorological high mountain stations. The salient features of this project are access to and collection of high mountains research data in sensitive and remote areas (such as Africa and Asia, Alps, and Ande), carried out in collaboration with local and governmental institution for the aim of preserving these fragile ecosystems (Salerno et al., 2010). The SHARE Geonetwork project provides: a further impetus to high mountains research, complementing other projects such as GLORIA (Global Observation Research Initiative in Alpine Environments) (Grabherr et al., 2000), and the recent creation of a database for storing, processing, and sharing glaciological data in Italy (Nigrelli & Marino, 2012); a methodology to implement a climatological/geographical information system using open-source tools.

Future activities include the use of information tools developed in this work to integrate them into the NextData project, promoted by the Italian Ministry for Education, University and Research, coordinated by the CNR Department of Earth and Environment. The aim of this project was the measurement, interpretation and provision of environmental and climatic data of high-altitude areas. It is designed to obtain information on natural climate variability over the last thousand years, to quantify changes underway, and to develop future scenarios for mountain regions. Finally, the next planned activity within the Geonetwork SHARE will be to integrate the portal I-AMICA, a project coordinated by CNR and developed under the Convergence Objective, cofunded by the European Regional Development Fund (ERDF) and the Italian Ministry of Education, University and Research, and the Italian Ministry of Economy and Finance. Through the implementation of the Geonetwork infrastructure, I-AMICA aims to encourage the development of specific Italian regions of the Mediterranean, also through a platform that facilitates the convergence of information gathered, necessary to achieve strategic objectives and harmonize policies for access and use of data, useful to strategies for technological adaptation and innovation.

Acknowledgements

This work has been carried out in the framework of SHARE and Next Data projects funded by the Italian Ministry of University and Research.

Appendix

Measuring sensors

The following Figures A1 and A2 summarize the sensors mounted in each station and laboratories, installation date, and time interval of records parameters. In particular, Figure A1 lists the meteorological parameters and Figure A2 the atmospheric parameters. Each station starts keeping a record of observations from the ‘Installment Date’ until the present. The raw data keep track of whole data since the ‘Installation data’.

Figure A1.

List of meteorological parameters for each station.

Figure A2.

List of atmospheric parameters for each station.

Ancillary