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.