Skip to content

Version 2.2
Compare
Choose a tag to compare
@timlinux timlinux released this 05 Jan 09:37
· 7672 commits to develop since this release
version-2_2_0
7503d45

We are pleased to announce the availability of InaSAFE 2.2. This is a feature release, adding a number of new features and tools to make the process of contingency planning more efficient and configurable. For more information on how to participate in the InaSAFE project, please contact us at info@inasafe.org - and visit our home page at inasafe.org. We would like to thank all the developers, funders, stakeholders and interested people for the great contributions they have made to InaSAFE thus far! The image on the right (click for a larger view) features participants at the InaSAFE workshop held in Jakarta over the period 22 September - 30 September 2014.

Important note: InaSAFE 2.2 does not support QGIS 2.6. Please ensure you have QGIS 2.4 in order to be able to download and use this plugin. This is addressed in the 2.2.3 Bugfix release above.

Preliminary support for ISO19115 metadata

Until version 2.2 of InaSAFE, our (keywords system)[http://inasafe.org/en/user-docs/application-help/keywords.html] has relied on a simple text file format for representing the various properties about GIS layers - for example whether they are hazard, exposure or impact layers. As of InaSAFE 2.2 we will be shifting towards using the industry standard ISO19115 file format in order to facilitate data interchange with other GIS users.

For technical users, note that keywords will be represented in the gmd:supplementalInformation element of the ISO19115 document and still adhere to our key : value pair format within the CDATA block as per the example below.

<gmd:supplementalInformation> <inasafe_keywords> <![CDATA[

And then in the nested CDATA block:

category: exposure
source: OpenStreetMap
subcategory: structure
title: Essential buildings
datatype: osm

And then the supplemental information block is closed:

]]> </inasafe_keywords> </gmd:supplementalInformation>

In future versions the keywords will be represented as JSON within the CDATA block.

Improvements to the clipping logic for rasters

In many cases, previous versions of InaSAFE were clipping raster layers sub-optimally. The resulting layers were not aligned with either the hazard or exposure layers. This affected the interpolation routines that are used during pixel lookups, resulting in less accurate analysis results. Here is a typical example of what you would see in the impact layer when extents were poorly aligned:

In version 2.2 of InaSAFE we have improved the algorithm used for clipping so that the clipping area will expand / contract as needed to the nearest pixel edge as per the diagram shown here. We also improved the numerical precision for clipping operations in order to ensure that edges are aligned as closely as possible.

Remaining Problem: Please note there is one remaining problem with clipping that we hope to address in a future version - it relates to raster datasets that have non-square pixels. In these cases currently only one edge is currently used for calculating clipping boundaries. See issue #1301 for more details. As a work around in the interim, we advise our users to try to use square pixel raster datasets whenever possible.

New volcano OpenStreetMap buildings impact function

InaSAFE 2.2 introduces the ability to assess buildings affected by volcano hazard zones. The buildings should be obtained using the OpenStreetMap downloader tool in InaSAFE. The impact report will break down the number of buildings per hazard zone, as shown in the screenshot here.

Raster flood on OSM buildings

As of InaSAFE 2.2 you can now produce an impact scenario assessment for a raster flood layer on OSM buildings. The impact function will break down the number of inundated (considered flooded), wet (may be flooded) and dry buildings. The building summaries are done by usage classes: Clinic/doctor, Commercial, Government, Office and so on.

Generic / categorical impact function

InaSAFE 2.2 introduces a new class of Impact Function: Generic Impact Functions. Generic impact functions treat exposure as a series of categories representing level of risk. This is extremely useful for developing scenarios based on a wide range of risks from flooding to fire to chemical hazard etc. Basically anything that can be quantified into three risk categories can now be used as the hazard for an impact assessment. These categories are defined according to the following classes in your hazard data raster layer:

1 : low risk
2 : medium risk
3 : high risk

Furthermore, the hazard layer should have these keywords:

  • Category: hazard
  • Subcategory: generic
  • Unit: categorised

Currently categorised impacts can be calculated for population and OSM building exposure layers.

Extent selector tool

The new extent selector tool lets you define where the analysis extent should be explicitly. In previous versions, the determination of the analysis area was either the intersection of:

  • the current viewport display area in QGIS
  • the hazard layer extent
  • the exposure layer extent

or (when 'clip datasets to visible extents' option is disabled in InaSAFE settings):

  • the hazard layer extent
  • the exposure layer extent

In 2.2 a new permutation allows you to define (by dragging a rectangle or by entering coordinates manually) the maximum analysis extent explicitly. The effective analysis area in this mode then becomes the intersection of:

  • the user defined analysis maximal extent
  • the hazard layer extent
  • the exposure layer extent

To disable this behaviour simply open the new tool dialog and press the 'Clear' button, then close the window.

A new marquee / rubber band on the canvas display indicates where the user defined extent is by means of a blue rectangle.
As in previous versions, the effective analysis extent is defined by means of a green rectangle.
When an analysis is completed a red rectangle indicates the last completed analysis.

New minimum needs manager

This release adds a new minimum needs manager with support for regional minimum needs profiles. Minimum needs is a critical component of InaSAFE that is used to calculate the requirements (e.g., food & shelter) of displaced or affected people after a disaster. Up until now the values used to determine minimum needs in InaSAFE have been based on Indonesian national guidelines. This made it somewhat cumbersome to deal with regional variations in requirements, or to deploy InaSAFE into other regions which use substantially different guidelines for human needs in the event of a disaster.

With the new minimum needs manager in InaSAFE 2.2, you can define a 'profile' (e.g. Jakarta Needs) and then use specific defaults for e.g. daily rice requirements for that profile. By default we ship with standard profiles for Indonesia and the Philippines, and more profiles can easily be defined using the needs manager tool (pictured here).

Assets 2