Abstract
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.
Highlights
Hydrological Response Units may be considered as spatial entities with the objective of applying them to the process of water modelling
As PyWPS comes with native GRASS support, all hydrological response units (HRUs) relevant computation is done by GRASS, here version 6.2.2
The written plugin profits i.e. from the temporary GRASS sessions in PyWPS since only important main data are swapped out when a HRU task ends – no extra management of GRASS mapsets is needed
Summary
Hydrological Response Units may be considered as spatial entities with the objective of applying them to the process of water modelling The designation of such regions as assumed for the present work operates on physiographical characteristics of the catchment area [2] and aims at its partitioning into zones similar to each other – both topography and dynamic related. To meet the requirements of a client/server system, albeit in this case running all components on just one single machine (including WPS), a user-friendly client enabling the several tasks sequentially would be more than appropriate and has to be developed. In this context QGIS gets the vote. In that case PyWPS serves as a kind of middleware between two GIS, or in other words, it separates processing from visualization in the HRU tool
Published Version (
Free)
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have