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

e-Report Generator Supporting Communications and Fieldwork: A Practical Case of Electrical Network Expansion Projects

In this piece of work we present a simple way to incorporate Geographical Information System tools that have been developed using open source software in order to help the different processes in the expansion of the electrical network. This is accomplished by developing a novel fieldwork tool that provides the user with automatically generated enriched e-reports that include information about every one of the involved private real estates in a specific project. These reports are an eco-friendly alternative to paper format, and can be accessed by clients using any kind of personal device with a minimal set of technical requirements

Geo-processing in cyberinfrastructure: making the web an easy to use geospatial computational platform

International audienceAccess to data on the web has become routine based upon open standards from IETF and W3C. Access to explicitly geospatial data is routinely done using data access standards from the OGC. Geoprocessing services on the web are now being developed. Processing of data must be done to apply or fuse the data to meet specific applications. Standards and implementations for processing of data on the web are just now becoming established. For geospatial data, the OGC has defined the Web Processing Service (WPS) interface standard. Now is a critical time to bring convergence to WPS profiles that make the web an easy to use geospatial computational service. Access to network accessible processing services is bringing geoprocessing to the cyberinfrastructure

Design of the shared Environmental Information System (SEIS) and development of a web-based GIS interface

Chapter 5The Shared Environmental Information System (SEIS) is a collaborative initiative of the European Commission (EC) and the European Environment Agency (EEA) aimed to establish an integrated and shared EU-wide environmental information system together with the Member States. SEIS presents the European vision on environmental information interoperability. It is a set of high-level principles & workflow-processes that organize the collection, exchange, and use of environmental data & information aimed to: • Modernise the way in which information required by environmental legislation is made available to member states or EC instruments; • Streamline reporting processes and repeal overlaps or obsolete reporting obligations; • Stimulate similar developments at international conventions; • Standardise according to INSPIRE when possible; and • Introduce the SDI (spatial database infrastructure) principle EU-wide. SEIS is a system and workflow of operations that offers technical capabilities geared to meet concept expectations. In that respect, SEIS shows the way and sets up the workflow effectively in a standardise way (e.g, INSPIRE) to: • Collect Data from Spatial Databases, in situ sensors, statistical databases, earth observation readings (e.g., EOS, GMES), marine observation using standard data transfer protocols (ODBC, SOS, ft p, etc). • Harmonise collected data (including data check/data integrity) according to best practices proven to perform well, according to the INSPIRE Directive 2007/2/EC (1) Annexes I: II: III: plus INSPIRE Implementation Rules for data not specified in above mentioned Annexes. • Harmonise collected data according to WISE (Water Information System from Europe) or Ozone-web. • Process, aggregate harmonise data so to extract information in a format understandable by wider audiences (e.g., Eurostat, enviro-indicators). • Document information to fulfi l national reporting obligations towards EU bodies (e.g., the JRC, EEA, DGENV, Eurostat) • Store and publish information for authorised end-users (e.g., citizens, institutions). This paper presents the development and integration of the SEIS-Malta Geoportal. The first section outlines EU Regulations on INSPIRE and Aarhus Directives. The second covers the architecture and the implementation of SEIS-Malta Geoportal. The third discusses the results and successful implementation of the Geoportal.peer-reviewe

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

EcoGIS – GIS tools for ecosystem approaches to fisheries management

Executive Summary: The EcoGIS project was launched in September 2004 to investigate how Geographic Information Systems (GIS), marine data, and custom analysis tools can better enable fisheries scientists and managers to adopt Ecosystem Approaches to Fisheries Management (EAFM). EcoGIS is a collaborative effort between NOAA’s National Ocean Service (NOS) and National Marine Fisheries Service (NMFS), and four regional Fishery Management Councils. The project has focused on four priority areas: Fishing Catch and Effort Analysis, Area Characterization, Bycatch Analysis, and Habitat Interactions. Of these four functional areas, the project team first focused on developing a working prototype for catch and effort analysis: the Fishery Mapper Tool. This ArcGIS extension creates time-and-area summarized maps of fishing catch and effort from logbook, observer, or fishery-independent survey data sets. Source data may come from Oracle, Microsoft Access, or other file formats. Feedback from beta-testers of the Fishery Mapper was used to debug the prototype, enhance performance, and add features. This report describes the four priority functional areas, the development of the Fishery Mapper tool, and several themes that emerged through the parallel evolution of the EcoGIS project, the concept and implementation of the broader field of Ecosystem Approaches to Management (EAM), data management practices, and other EAM toolsets. In addition, a set of six succinct recommendations are proposed on page 29. One major conclusion from this work is that there is no single “super-tool” to enable Ecosystem Approaches to Management; as such, tools should be developed for specific purposes with attention given to interoperability and automation. Future work should be coordinated with other GIS development projects in order to provide “value added” and minimize duplication of efforts. In addition to custom tools, the development of cross-cutting Regional Ecosystem Spatial Databases will enable access to quality data to support the analyses required by EAM. GIS tools will be useful in developing Integrated Ecosystem Assessments (IEAs) and providing pre- and post-processing capabilities for spatially-explicit ecosystem models. Continued funding will enable the EcoGIS project to develop GIS tools that are immediately applicable to today’s needs. These tools will enable simplified and efficient data query, the ability to visualize data over time, and ways to synthesize multidimensional data from diverse sources. These capabilities will provide new information for analyzing issues from an ecosystem perspective, which will ultimately result in better understanding of fisheries and better support for decision-making. (PDF file contains 45 pages.

Internet of things

Manual of Digital Earth / Editors: Huadong Guo, Michael F. Goodchild, Alessandro Annoni .- Springer, 2020 .- ISBN: 978-981-32-9915-3Digital Earth was born with the aim of replicating the real world within the digital world. Many efforts have been made to observe and sense the Earth, both from space (remote sensing) and by using in situ sensors. Focusing on the latter, advances in Digital Earth have established vital bridges to exploit these sensors and their networks by taking location as a key element. The current era of connectivity envisions that everything is connected to everything. The concept of the Internet of Things(IoT)emergedasaholisticproposaltoenableanecosystemofvaried,heterogeneous networked objects and devices to speak to and interact with each other. To make the IoT ecosystem a reality, it is necessary to understand the electronic components, communication protocols, real-time analysis techniques, and the location of the objects and devices. The IoT ecosystem and the Digital Earth (DE) jointly form interrelated infrastructures for addressing today’s pressing issues and complex challenges. In this chapter, we explore the synergies and frictions in establishing an efficient and permanent collaboration between the two infrastructures, in order to adequately address multidisciplinary and increasingly complex real-world problems. Although there are still some pending issues, the identified synergies generate optimism for a true collaboration between the Internet of Things and the Digital Earth

Locating Mineral Exploration Targets using a Geographical Information System

This paper outlines the research and development of a complete open source geographic information system (GIS) that offers real-time geoprocessing over the Internet. The premise of the geoprocessing is to locate mineral exploration targets that have high potential for success based on parameters chosen by the end-user of the system. Components integrated in the system include a spatial database PostGIS, a GIS processing engine GRASS, a GIS server GeoServer, a web server Apache, and front-end technologies OpenLayers and GeoExt. Appropriate data was sourced from the Geological Survey of Ireland to be used for the geoprocessing. With all the components of the GIS integrated, an individual not specialised in the use of a GIS can interact with and interrogate the data through a web browser. The GIS then provides a vital role as a decision support system for locating mineral exploration targets

Evaluation ofWeb Processing Service Frameworks

As geoprocessing on the web has matured in recent years, an increasing number of geoprocessing services and functionality are becoming available in the form of online Web Processing Services (WPS). Consequently, the quality of such geoprocessing services is of importance to ensure that WPS instances fulfill users’ expectations. In this paper, we illustrate, and discuss initial results from a quantitative analysis of the performance of WPS servers. To do so, we used two test scenarios to measure response time, response size, throughput, and failure rate of five WPS servers including 52 Degree North, Deegree, GeoServer, Py- WPS, and Zoo. We also assess each WPS server in terms of qualitative metrics such as software architecture, perceived ease of use, flexibility of deployment, and quality of documentation. A case study addressing accessibility assessment is used to evaluate the relative advantages and disadvantages of each implementation, and point to challenges experienced while working with these WPS servers