Integration with petajakarta.org

[lucernae]

Issue Draft of Floodmap integration

What

We want to integrate flood map from PetaJakarta to InaSAFE Realtime.
What do we possibly want?

Showing the map

• Showing Pump, Flood Gate, and Waterways, preferably toggleable
• Showing live aggregate count of flood report (toggleable for past 1,3, or 6 hours
• Aggregate the map for RW (and preferabbly RT boundaries)

Calculating the report

• How do we use flood data? Aggregated from the last 24 hours? only mark inundated area?
• Calculate inundated area on building? From where we can get the building data?
• Calculate inundated area on population? Maybe we can use population map from Earthquake
• What is the extent of the report? Only Jakarta?
• What IF to use?

Where

Flood map data is available from PetaJakarta API

[timlinux]

Overview

Ok here is a more detailed description of the implementation plan. The aim is to produce a new landing page at http://realtime.inasafe.org/flood that looks like this:

• On loading the page, the impact map from the most recent event will be overlaid over the MapQuest OSM render in the map.
• A simple filter widget will let you filter the reports table to show only reports within a certain date range.
• Each row in the table represents a single event report. By default the system will be set up to generate a new report every 6 hours at RW boundary level for Jakarta
• Clicking on any row will cause the impact map to be loaded onto the map widget
• Clicking an impacted polygon will pop up details about the event (specific info to be confirmed, but at minimum the date/time of aggregation extract from PetaJakarta, the hour period for the event (e.g. 6 hours))

What is an event?

In our context an event would be either:

• one polling event - so if we are polling on a 6 hour interval that polling request and the subsequent impact map generated would be an 'event'
• a second case in which an event could occur is if a staff user triggers a new impact map creation using an admin form

Data model and workflow

Addressing the top part of the diagram first:

1. When an event occurs, we receive an API push from the inasafe-realtime-processor. That will pass the following content to inasafe-django's FloodEvent table:
   • the map report as a pdf
   • the tabular report as a pdf
   • the impact layer along with its metadata, in a zip file
   • the date and time of the event
   • the metadata (extracted from the zip file) and stored in a text field
2. The impact layer is extracted and any polygon that contains data is read and added to the event boundaries table (using the 'pkey' to cross match the boundary.upstream_id). This architecture allows us to store the boundaries only once. One reason to perhaps not use this approach is that boundaries may change, invalidating old reports when they are updated. We need to discuss to see if this is a risk.
3. Polygons that have no impact data are ignored and will not be displayed on the map

This architecture will let us produce interesting reports like a chart for an RW showing its historical flood incidence.

Addressing the bottom part of the diagram

There are two key activities:

1. Regular polling events which retrieve the 6 hourly (or other depending on configuration settings) intervals and perform an InaSAFE analysis using the hazard layer. To start with we will use only raster population data. In future we may include other exposure data like vector population, buildings and roads.
2. On an ad hoc basis we will use a management command to query the PetaJakarta API for a current boundaries list. We will then import those boundaries using the following logic:
   • if there is an upstream_id that matches the JSON record pkey, we will replace the existing record
   • otherwise we will import as a new record.

[Charlotte-Morgan]

Data

• hazard data will be RW / RT polygons with attributes for water depth and duration
• exposure data will be raster worldpop (for now) but expect this to be replaced with RW / RT boundaries with real data (we get to choose the attributes we want - i'm waiting to get a sample of these data) soon. This will behave like an aggregation layer and should have identical polygons to the flood data :)
• aggregation data - either RW or a higher level of admin boundary - polygon data - should be topologically correct with other admin boundaries

analysis extent

extent will be the extent of Jakarta Districts

IF

use the flood polygon on people IF

Impact analysis --> impact report

• the number of people affected for the
• the whole event / time stamp
• by aggregation area
• by RW (with limits on reporting small numbers)
• by aggregation boundaries
• minimum needs by entire area and aggregation (again need to manage small numbers)

Impact analysis --> impact map

• the flood hazard data - full stop
• interactive affected people attributes

Impact analysis --> impact data

• yes

Context data

roads, buildings, evacuation centers, drainage lines
there is no need to duplicate the PJ map with flood infrastructure
if necessary - we give back the impact map for the PJ site rather than reproduce their map

[timlinux]

Here is an updated diagram which includes some ideas we discussed yesterday for designing the platform from the outset to cater to different regions.

[gubuntu]

Can we close this since it's implemented, with Petabencana?