A web processing service for validating interpolation

An interoperable web processing service (WPS) for the automatic interpolation of environmental data has been developed in the frame of the INTAMAP project. In order to assess the performance of the interpolation method implemented, a validation WPS has also been developed. This validation WPS can be used to perform leave one out and K-fold cross validation: a full dataset is submitted and a range of validation statistics and diagnostic plots (e.g. histograms, variogram of residuals, mean errors) is received in return. This paper presents the architecture of the validation WPS and a case study is used to briefly illustrate its use in practice. We conclude with a discussion on the current limitations of the system and make proposals for further developments

Modifications To Web Processing Service Standard For Client-Side Geoprocessing

Nowadays we see the rapid growth of solutions number for geospatial data processing in the Web (i.e. geoprocessing). One of the main trends of Web geotechnologies evolution is the transition from Web map applications to the Web GIS applications, which are supplement the maps delivery with the analytic tools providing to the end user through Web interface. In fact, the only general open standard describes implementation rules for Web geoprocessing services. This is the Open Geospatial Consortium Web Processing Service standard, which is fully server-oriented. Moreover, the vast majority of currently used solutions (both open source and proprietary) are server-oriented, i.e. assume the server resources only as the computational resource. However, some researchers underline that it is possible way to transmit the executable code to the client for client-side computations and geoprocessing. Also, some general Web architecture concepts assume the effectiveness of client-side computations, e.g. Fog Computing concept. Our practical experience also shows that in some cases it is useful to have ability of client-side geoprocessing, which is not opposite but complement technology to the server-side processing technologies. In addition, we believe that it is more useful to have the ability to run the same processing tool by choice on server or client side. We name such double-sided services as Hybrid Geoprocessing Web Services. We study and discuss the approaches to gap filling in client-side geoprocessing general schema. For this purpose, we implemented previously the getProcess request as addition to the WPS protocol. Additionally at the previous steps of our study, we proposed a possible structure of getProcess request and draft XML file structure for its response, which describes the list of executable resources and their dependencies. Currently we working on detailed methodology of processing tools implementation and testing. We use the Python programming language as primary development tool, because of its applicability to build both server- and client-side crossplatform processing tools using single core program code. We use Python also for implementation of needed infrastructure components, such as HGWS server that supports the getProcess request/response performing, and client-side Runtime Environment that provides executable code orchestration on the client. Achieved results need to be discussed widely and carefully. However, main conclusion of our current work is that client-side geoprocessing schema in general could be relatively simple and compatible backward with current standards. The HGWS concept is applicable when implementing client-side geoprocessing Web services in small-scale projects and could be the entering point for study of distributed geoprocessing systems implementation

eHabitat, a multi-purpose Web Processing Service for ecological modeling

The number of interoperable research infrastructures has increased significantly with the growing awareness of the efforts made by the Global Earth Observation System of Systems (GEOSS). One of the Societal Benefit Areas (SBA) that is benefiting most from GEOSS is biodiversity, given the costs of monitoring the environment and managing complex information, from space observations to species records including their genetic characteristics. But GEOSS goes beyond simple data sharing to encourage the publishing and combination of models, an approach which can ease the handling of complex multi-disciplinary questions. It is the purpose of this paper to illustrate these concepts by presenting eHabitat, a basic Web Processing Service (WPS) for computing the likelihood of finding ecosystems with equal properties to those specified by a user. When chained with other services providing data on climate change, eHabitat can be used for ecological forecasting and becomes a useful tool for decision-makers assessing different strategies when selecting new areas to protect. eHabitat can use virtually any kind of thematic data that can be considered as useful when defining ecosystems and their future persistence under different climatic or development scenarios. The paper will present the architecture and illustrate the concepts through case studies which forecast the impact of climate change on protected areas or on the ecological niche of an African bird

UncertWeb processing service:making models easer to access on the web

Models are central tools for modern scientists and decision makers, and there are many existing frameworks to support their creation, execution and composition. Many frameworks are based on proprietary interfaces, and do not lend themselves to the integration of models from diverse disciplines. Web based systems, or systems based on web services, such as Taverna and Kepler, allow composition of models based on standard web service technologies. At the same time the Open Geospatial Consortium has been developing their own service stack, which includes the Web Processing Service, designed to facilitate the executing of geospatial processing - including complex environmental models. The current Open Geospatial Consortium service stack employs Extensible Markup Language as a default data exchange standard, and widely-used encodings such as JavaScript Object Notation can often only be used when incorporated with Extensible Markup Language. Similarly, no successful engagement of the Web Processing Service standard with the well-supported technologies of Simple Object Access Protocol and Web Services Description Language has been seen. In this paper we propose a pure Simple Object Access Protocol/Web Services Description Language processing service which addresses some of the issues with the Web Processing Service specication and brings us closer to achieving a degree of interoperability between geospatial models, and thus realising the vision of a useful 'model web'

An OGC Web Processing Service for assessing the quality of solar radiation measurements

International audienceA service is presented that assesses the quality of measurements of daily global irradiation or means of global irradi-ance acquired by a ground station. Measurements are checked against models resulting in a measure of plausibility. This on-line service obeys the WPS (Web Processing Service) standard of the Open Geospatial Consortium. It is free of use and can be integrated into routine operations and Web portals thanks due its interoperability capability

Deriving Hydrological Response Units (HRUs) using a Web Processing Service implementation based on GRASS GIS

QGIS releases equal to or newer than 0.7 can easily connected to GRASS GIS by means of a toolbox that provides a wide range of standard GRASS modules you can launch – albeit only on data coming from GRASS. This QGIS plugin is expandable through XML configurations describing the assignment of options and inputs for a certain module. But how about embedding a precise workflow where the several processes don’t consist of a single GRASS module by force? Especially for a sequence of dependent tasks it makes sense to merge relevant GRASS functionality into an own and encapsulated QGIS extension. Its architecture and development is tested and combined with the Web Processing Service (WPS) for remote execution using the concept of hydrological response units (HRUs) as an example. The results of this assay may be suitable for discussing and planning other wizard-like geoprocessing plugins in QGIS that also should make use of an additional GRASS server

PROJECTS BASED ON THE WEB PROCESSING SERVICE FRAMEWORK BIRDHOUSE

Birdhouse is a collaborative project open for the community to participate. It is a software framework containing a collection of Web Processing Services (WPS). The deployed algorithms are focusing on Earth Systems and environmental data processing with the philosophy of streamlining the software development and deployment. By supporting climate, earth observation and biodiversity data and processes, Birdhouse can be used in a wide array of Earth sciences projects and workflows. The core benefit of this project is to allow the seamless use of climate services developed by a diverse network of national meteorological offices, regional climate service providers, academics, not-for-profit research centers and private industry. As governments move toward open-data policies, there will be a need for analytical services that extract value out of the deluge of information. Using an interoperable software architecture, institutions can provide both data and services allowing users to process the data remotely from a laptop, instead of having to acquire and maintain large storage infrastructures

Geoprocessing Web Services

Since 2003, Critech has performed research on web based geoprocessing. This was before OGC started work on the Web Processing Service standards. While continuously evaluating the benefits and drawbacks of existing (open-source and commercial) GIS software packages, the operational benefits of an ESRI site license drove the development in this area. Early work focused on scripting technologies. In 2007, Critech exploited the Application Program Interfaces (APIs) of ESRI software, in particular ESRI SDE. With the (stable) release of ESRI ArcGIS Server, web geoprocessing becomes an integral part of the software. This new technology will be used by Critech in 2008. This document reports on the status of the work.JRC.G.2-Support to external securit