This is the next major release of InaSAFE with a focus on porting to the QGIS 2.0 API.
This tool will allow you to merge the output from two impact assessments covering the same geographic extent and aggregated by the same areas. For example if you run a flood analysis on Kapubaten (districts) in Jakarta for both impact on people and buildings, you can generate a report that combines these two exposures into a single report.
The generated report combines the result of post-processing analysis on each area, for example generating totals for each type of critical building affected, age and gender breakdowns etc.
In InaSAFE 1.2 we introduced the new OSM downloader tool for buildings data. As well as making some improvements to the way that the downloaded buildings are categorised, we have also added a new tool that will allow you to download roads data. When the data is downloaded, it is automatically assigned the correct keywords to be usable in QGIS (see separate changelog entry on impact on roads) and assigned a style.
We have overhauled the options dialog to make it easier to navigate and hide away advanced options into their own panel.
We have been hard at work to improve our documentation on http://inasafe.org. The tutorials section has been overhauled at http://inasafe.org/en/training/index.html. We have also added an archive section which you can use to fetch older versions of our documentation (see http://inasafe.org/pdf/). We have also added a new download section to our web site http://data.inasafe.org/ which contains the sample data used in the training materials. We have made many other improvements to the documentation - we hope you find the information you need to be productive with InaSAFE!
If you find the dock panel too small to show all the report details, or if you want to open it in your browser to quickly print the tabular report, you can now do so by right clicking on the report area of the InaSAFE dock and choose
Open in web browser.
As well as the new report template capabilities, you can now also set your organisation logo in the InaSAFE options dialog. This logo will then be used for any of the built in InaSAFE templates that you use, or anywhere in your own templates if you use the element id
safe-logo. Click image on right to see an example of how the organisation logo is placed in the bottom right of the template.
Another key new feature in InaSAFE 2.0 is the ability to define and use custom print templates (using the built in QGIS composer templating system) for your reports. This new feature means that you can now place your own logos in the report and customise the arrangement of the various report elements on the page. You can also print onto different page sizes (e.g. A3, A2) and in different layouts (portrait, landscape). You can find more details about this functionality at http://inasafe.org/en/user-docs/application-help/reports.htm.
QGIS 2.0 was launched a few months ago and plugins from the QGIS 1.x series of releases are not compatible with QGIS 2.0. In InaSAFE 2.0 we have ported our code base to work with the new version of QGIS. Please note: QGIS 1.x releases will no longer be supported in this and future releases on InaSAFE (starting from 2.0).
You can now use PostGIS vector layers as input data for running impact functions. This means you can host your data (and symbology) in a shared geospatial database and then carry out an impact assessment using the data stored in that database.
Our first demonstrator impact function that uses the native QGIS geoprocessing functionality is included in INaSAFE 2.0. The function takes as input a polygon flood layer (category: hazard, subcategory: flood [wet/dry]) and a roads layer (category: exposure, subcategory: road). It will return a new roads layer where each road segment is classified as inundated or not inundated. You can download suitable roads data using the OSM Downloader tool roads fetcher as mentioned below.
This is a more technical feature but it opens up a new way for creating impact functions. In InaSAFE 2.0 we have made a number of architectural changes to allow impact functions to use standard QGIS geoprocessing functions instead of numpy (which was the primary analysis library in the past). We have also been working to optimise the way that data is passed to impact functions so that they can now be passed a QgsMapLayer (native QGIS layer) which should allow for more efficient processing of input data in the future, and allow for data manipulation using the standard QGIS API. See issue 609 for more details on the implementation of this feature.