DMInnovation provide (amongst other things) in-country support to Indonesia in the area of Disaster Planning and risk management. They contracted Kartoza to co-develop the InaSAFE tool, which is a plugin for QGIS. The plugin is used to perform scenario assessments in the case of a disaster such as a flood, fire, volcano, tsunami, earthquake etc. The tool produces a pdf report with a map showing the areas likely to be impacted by an event and tabular data detailing remediation actions and numbers of expected fatalities, injuries etc. We are still actively involved in the development of InaSAFE.

We built the preliminary version of the InaSAFE QGIS plugin, created much of the current project infrastructure such as the web site, documentation system etc.

The requirements were as follows:

2.1 The Contractor shall perform the following Services in accordance with the terms and conditions of this
Contract:
(a) will develop InaSAFE to enable the Indonesian national and subnational disaster management process
under the direction of the Spatial Data Analyst at AIFDR.
(b) will be the lead InaSAFE software engineer on behalf of Australia-Indonesia Facility for Disaster
Reduction (AIFDR) and will:
(i) mentor AIFDR software engineers;
(ii) represent AIFDR interests in the governance of InaSAFE; and
(iii) manage other software engineers as required.
(c) InaSAFE maintenance:
(i) provide ongoing maintenance and improvements to the InaSAFE system architecture;
(ii) develop and maintain open source InaSAFE code (write code, write user manuals, write developer
manuals, maintain training manuals, write tests, run tests);
(iii) develop and manage the InaSAFE web properties;
(iv) establish protocols for management of all InaSAFE Github repositories (inasafe, inasafe-doc, insafe-data);
(v) support InaSAFE users and developers (IRC chat, mailing list, in person site visits); and
(vi) manage InaSAFE software releases.

(d) Coding standards: manage InaSAFE software development and ensure that InaSAFE code meets the

following standards:
(i) tested by a quality regression test suite (unit test, system tests & integration tests) covering at least 80% of
the code lines;
(ii) compliant with the Python Enhancement Proposal 8 (PEP8) style guide for the Python programming
language;
(iii) each software component must be documented according to the Python Enhancement Proposal 257
(PEP257) Python guide;
(iv) all code must be under Github revision control;
(v) issues encountered must be tracked, tested and linked to revisions that address them (Github issue tracker);
(vi) each release must have installation packages and be deployed in the QGIS plug-in repository;
(vii) all features must have supporting documentation (user and developer materials on the InaSAFE website);
(viii) internationalisation support for all documentation and application text (currently InaSAFE is using
transifex)
(ix) ensure that InaSAFE can be used across platforms (Windows, Unix and OS X);
(x) ensure that InaSAFE core development supports online and QGIS versions; and
(xi) work to get all non-compliant code into compliance with the coding standards defined at:
http://inasafe.org/en/developer-docs/coding_standards.html.

(e) InaSAFE release management: manage InaSAFE software releases and ensure that the code is tested and
adheres to the following stringent quality measures:
(i) Testing: At least 80% of all lines of code must be successfully exercised by a regression test suite (unit
tests, system tests, integration tests) which is distributed alongside the software itself.
(ii) Clarity: The software complies with the appropriate development standards for the language used, i.e. the
coding style guide (http://www.python.org/dev/peps/pep-0008) and has been peer reviewed.
(iii) Disclaimer: The software includes a clear Disclaimer of Warranty and appropriate Limitation of Liability
clause. In this case this is achieved by using the GNU General Public Use v3 License
(http://www.gnu.org/copyleft/gpl.html).
(iv) History: The software is maintained in a source control system which allows full visibility of its history,
tracking of issue resolution and potential reversal of past changes.
(v) Authenticity: Source control system codes uniquely identify each individual version of the software
making it possible to verify its origin.
(f) InaSAFE outreach:
(i) undertake outreach activities on behalf of AIFDR (assist in the creation of promotional materials, make
presentations to conferences and potential partners, assist in the formulation of training curriculum, produce
developer training materials);
(ii) attend with nominated Linfinit staff a cross organisational workshop / ‘code sprint’ for technical staff; and
(iii) engage with and work closely with partners on behalf of AIFDR (BNPB, The World Bank GFDRR,
BMKG, Indonesian Universities, Humanitarian OpenStreetMap Team).
(g) Other as needed:
(i) advise AIFDR of software engineering and open source solutions; and
(ii) advise on other issues as needed and as negotiated between Linfiniti and AIFDR.

Inputs
2.2 The inputs shall be:
(a) Up to 4192 contract hours
(b) At least five short term missions to include in-country work with AIFDR staff and Indonesian stakeholders
and to represent InaSAFE interests at conferences.
Outputs
2.3 The outputs shall be:
(a) At least six software releases from the month of July 2014 through to June 2015.
(i) Oversee the transition to a SCRUM based (does not need to strictly follow SCRUM) project management
approach.
(ii) Enhancements according to priorities identified by AIFDR staff & arising from user feedback, including
but not limited to:
a) Impact function review – standardise metadata representation for all impact functions addressing
constrains, descriptive data, parameters, actions and impact reporting so that they are represented in a standard
format;
b) Soft coding of attribute selection from exposure and hazard data;

c) Wizard tools for data driven and impact function driven analysis;
d) Support for people in buildings impact functions;
e) Support for land cover impact functions;
f) Support for user input to minimum needs, post processors and aggregation layers;
g) Support for bounding boxes to define analysis windows;
h) Support for generic impact functions;
i) Raster resampling tool; and
j) Support for network analysis with OSM data.
(iii) Enhancements according to priorities identified by AIFDR staff & arising from UGM report.
(iv) Enhancements according to priorities identified by AIFDR staff & arising from InaSAFE review.
(v) Enhancements according to priorities identified by AIFDR staff & arising from collaborative work with
new partners e.g.,
a) PDC - consume data from InAWARE, realtime processing of event data alerts through InAWARE; and
b) PDC - InaSAFE products (data, maps, reports +/- contingency plans) are uploaded to InAWARE.
(b) InaSAFE code development as outlined in 2.1(a);
(c) InaSAFE software engineering as outlined in 2.1(b);
(d) InaSAFE maintenance as outlined in 2.1(c)
(e) InaSAFE coding standards as outlined in 2.1(d)
(f) InaSAFE release management as outlined in 2.1(e)
(g) InaSAFE outreach as outlined in 2.1(f)
(h) Other ongoing activities:
(i) Project management;
(ii) Bug fixes and general improvements to the code base;
(iii) Maintenance of clipping, resampling, aggregation and post processing;
(iv) Enhancement to dataset handling including working with remote datasets;
(v) Enhancement to templates for maps and reports according to priorities identified by AIFDR staff (in
collaboration with stakeholders) to support changing user requirements;
(vi) Addition of new tests and improvements to testing framework;
(vii) Update of QGIS training manual including python programming reference;
(viii) Support bugfix releases of QGIS as needed;
(ix) Maintenance of server infrastructure including website, download site, email delivery, Jenkins etc; and
(x) Update media (tutorial videos etc) to keep them current with InaSAFE releases.

During the contract we have been building out new functionality for InaSAFE and doing day to day project
management including but not limited to:
• Developing new features such as user configurable minimum needs, new impact functions
• Maintenance of the core system architecture
• Maintaining public web servers and other public resources
• Liasing closely with AIFDR staff to accommodate new requirements as they arise
• Overseeing extensions and improvements to the realtime earthwa

Work done for initial QGIS plugin: 

 (a) Version 0.2 of Risk-in-a-Box
 (b) Version 0.2.1 (bug fixes and developer’s documentation)
 (c) Version 0.3 of Risk-in-a-Box
 (d) Version 0.3.1 (bug fixes and user’s documentation)
 (e) Version 0.4 of Risk-in-a-Box
 (f) Cross platform installation procedure (Ubuntu, Windows, OSX) in developer and user mode for
versions 0.3
 (g) Version 1.0 of InaSAFE (for launch at AMCDRR): 15 October 2012
 (h) Version 1.1 February 2013
 (i) Version 1.2 October 2013(functionality identified by training in Dec 2012)
 (i) Aggregation support for vector data sources,
 (ii) A batch running facility,
 (iii) Internationalisation support for all documentation and application text.
 (j) Version 2.0: November 2013
 (i) Enable InaSAFE to work with QGIS 2.0
 (ii) Native QGIS data access within impact functions. Produce initial impact functions based on
roads (line)
 (iii) Utilising the new functionality in QGIS 2.0, custom templates will be implemented
 (iv) Remove legacy support for QGIS 1.x releases to make the migration to QGIS 2.0 complete.
 (k) Version 2.1 February 2013
 (i) InaSAFE impact functions will support polygon exposure i.e. landuse
 (ii) Wizard tools developed for both data driven and impact function InaSAFE analysis
 (iii) InaSAFE impact functions will support people inside building exposure
 (iv) Landslide impact function
 (v) Each impact function will be accompanied with a short instructional video embedded on the
web site.
 (vi) Enhancements to dataset handling will be added including for working with remote datasets.
 (vii) Maintenance release with bug fixes, improvements to error handling and usability based on
feedback.