An interactive web-GIS tool for risk analysis: a case study in the Fella River Basin, Italy

Z. C. Aye, M. Jaboyedoff, M. H. Derron, C. J. van Westen, H. Y. Hussin, R. L. Ciurean, S. Frigerio, and A. Pasuto Institute of Earth Sciences, University of Lausanne, Lausanne, Switzerland Faculty of Geo-Information Science and Earth Observation, University of Twente, Enschede, the Netherlands Department of Geography and Regional Research, University of Vienna, Vienna, Austria CNR-IRPI, National Research Council of Italy, Research Institute for Geo-Hydrological Protection, Padova, Italy


General comments:
The paper presents a prototype of interactive web-GIS for risk analysis of natural hazards. The architecture of the prototype is based on open-source geospatial software and its functionality is demonstrated on a simple risk analysis calculating loss and total risk in a region affected by a natural hazard. Authors propose an interactive web-GIS tool to aid risk evaluation of natural hazards in the scientific domain where desktop solutions dominated. As authors argue, use of interactive web-GIS tools aid decision analysts in addressing the consequences of a natural hazard in a more efficient way. Such benefit makes the author's contribution useful for the community targeted by the scope of the NHESS journal. The overall quality of the paper is good, the paper is academically sound, it reads well and contains minimum of inconsistencies (see below C1434 in the review).
Specific comments (following the NHESS manuscript evaluation criteria): 1. Does the paper address relevant scientific and/or technical questions within the scope of NHESS? Yes.
1. Does the paper present new data and/or novel concepts, ideas, tools, methods or results?
The paper presents new tool for interactive natural hazard risk analysis evaluation. The solution is not novel, it is based on existing, open-source geospatial software architecture. The presented prototype is the result of an initial phase of the full-fledged solution under development with sufficient results for publication in a discussion paper.
However, I would appreciate more detail on choices of the system architecture. Authors used a package of tools offered by Boundless and as they do not evaluate the selection of tools, it seems they used it because it was available in a package. I'm not suggesting that authors need to re-write or extend the paper, but in a paper about a web-GIS architecture used in such a specific context as natural hazard risk analysis, I would prefer seeing more discussion on a system analysis based on use requirements and its implication to a system design.
1. Are these up to international standards? Yes.
1. Are the scientific methods and assumptions valid and outlined clearly? C1435 Yes.
1. Are the results sufficient to support the interpretations and the conclusions? Yes.
1. Does the author reach substantial conclusions? Yes.
1. Is the description of the data used, the methods used, the experiments and calculations made, and the results obtained sufficiently complete and accurate to allow their reproduction by fellow scientists (traceability of results)?
Partly: description of schema architecture (section 2.3.1) seems incomplete: • p. 4016, line 18-19: "supporting data management module" is not illustrated on 1. Does the title clearly and unambiguously reflect the contents of the paper? Yes.

C1436
1. Does the abstract provide a concise, complete and unambiguous summary of the work done and the results obtained? Yes.
1. Are the title and the abstract pertinent, and easy to understand to a wide and diversified audience? Yes.
1. Are mathematical formulae, symbols, abbreviations and units correctly defined and used? Yes.
1. Is the size, quality and readability of each figure adequate to the type and quantity of data presented? Yes.
1. Does the author give proper credit to previous and/or related work, and does he/she indicate clearly his/her own contribution? Yes.
1. Are the number and quality of the references appropriate?
1. Are the references accessible by fellow scientists? Yes.
1. Is the overall presentation well structured, clear and easy to understand by a wide and general audience? Yes.
1. Is the length of the paper adequate, too long or too short?
The length of the paper is adequate.
1. Is there any part of the paper (title, abstract, main text, formulae, symbols, figures and their captions, tables, list of references, appendixes) that needs to be clarified, reduced, added, combined, or eliminated?
No, except of discussion related to Fig. 7 -see above.
1. s the technical language precise and understandable by fellow scientists? Yes.
1. Is the English language of good quality, fluent, simple and easy to read and understand by a wide and diversified audience? C1438 Yes.

Is the amount and quality of supplementary material (if any) appropriate?
Not applicable. • p. 4015, lines 9-11: "The batch processing. . .is possible to include in future versions of the platform" -such sentence would be better placed in Section 4 Discussion and conclusion.
• p. 4015, line 23: "In this prototype version. . ." would sound better as "In the current version of the prototype. . ." • p. 4017, line 1: the correct spelling of the GeoServer iis GeoServer -please check the whole paper for correct spelling of the tool.
• p. 4017, lines 21-25: check the proper terminology used for describing geospatial web tools and interfaces. For instance in the sentence: "With the use of GeoServer's import configuration. . ." is unclear. What is the 'GeoServer's import configuration'? With GeoServer, we do not 'import', but 'publish' layers through C1439 standard interfaces to the web. We certainly do not 'import layers directly to the database' with the GeoServer -the layers are already in the database (in spatial tables) and can be published with the GeoServer to the web. In case of an interactive tools, GeoServer may allow (through a dedicated interface, such as WFS-T) updating a database. Next in this paragraph, authors emphasize that for importing raster data to a PostgreSQL/PostGIS database an additional application (raster2pgsql) is necessary and suggest that for vector data an import is automatic. However, although it is now obscured from current users of the PostgreSQL/PostGIS database, vector data in a shapefile format is imported to a PostGIS database also through an application (shp2pgsql) additional to Post-greSQL/PostGIS.
• p. 4017-4019: In the description of the processing steps it is unclear when authors refer to in-built functions of the database management system (e.g. ST_Intersects) and when to other parts of the prototype developed especially for the presented interactive web-GIS (e.g. steps for filling attributes of the loss • p. 4024, line 3: the sentence "if a building was touched to multiple pixels. . .' is confusing. Please rephrase -check the proper terminology (e.g. 'a building was touched to multiple pixels'??) or verify the content.
• p. 4026, lines 23-25: "Moreover, this prototype is as an initial step towards a more complex system as it plays an important role in obtaining feedback and suggestions. . ." -An initial step plays an important role??? Please review and revise the sentence.