#VizRisk — Flooding in Marikina City: A Case Study

https://comet.dlsu.edu.ph/riesgo-vis

Hello from the Philippines!

When we found out about the #VizRisk challenge, we decided to focus on our home country. So here we are, a month later with our visualization on the flood hazards of Marikina City.

Background

The idea stemmed from a research project called Riesgo with the aim of identifying suitable areas for evacuation centers for floods in Marikina City. Due to the rainy season and the location of Marikina City, it was considered to be one of the most devastated areas during Typhoon Ketsana back in September 2009.

Our goal now is to be able to share this research through an interactive storytelling visualization tool.

Data

From the previous work done, we already had the following preprocessed data extracted from publicly available data:

• Flood Hazard Maps from LiPAD
• Land Elevation Maps from PhilGIS
• Evacuation Centers from OpenStreetMap (extracted based on the Philippine mapping conventions)

We also needed additional data which was not readily available from the previous project to build our narrative.

• Population estimates using the High Resolution Settlement Layer from CIESIN — Columbia University
• Critical building structures such as residential areas, schools and healthcare from OpenStreetMap
• Road network for accessibility measurement from OpenStreetMap

Processing the existing data

We wanted to use the preprocessed data to be our base choropleth maps on the visualization but they were raster files in XYZ text format where X and Y represent the coordinates and Z represents the value at that specific cell.

We needed to convert the existing files to any of the Mapbox usable formats. Using shapely and geopandas, the files were converted to GeoJSON Points. However, since the data provided was at a resolution of 10 meters, the file size went up to ~60MB each.

To minimize the file size, data was aggregated to a resolution of 100 meters instead. We used turf.js to generate a 100 x 100 square grid easily given a bounding box.

We merged the different files to a single GeoJSON and used tippecanoe to create the MBTiles which can be uploaded to Mapbox Studio as a Tileset, ready for use!

Understanding the Population

The High Resolution Settlement Layer (HRSL) for the Philippines is a useful open dataset for population estimate. However, for our purposes, we needed to convert the GeoTIFF to GeoJSON for:

1. Converting to MBTiles for visualization
2. Feature engineering with the evacuation center data

To convert the GeoTIFF, we used QGIS to filter out Marikina City only through masking (tutorial) and saved the output as an XYZ file. After, we used the same method to convert the XYZ to 40 m square grids.

For the feature engineering task, we wanted to know how many people are within a 400 meter radius of the existing evacuation centers and how many evacuation centers can these people go to.

Looking for an ideal coverage

After looking at the population, we were curious how many people living near the evacuation centers can be sheltered. Following the practice of transport planners when deciding bus stop locations, we assumed that people are comfortable to walk 400 meters before they decide to take any wheeled transport mode. We drew a 400m radius around each evacuation center and counted the total population covered. We also looked into the number of people that live near two or more evacuation centers.

Will they fit?

Of course, we’ve only calculated for the expected number of people that can flock to these evacuation centers when the worst flooding happens. But how many people can actually fit there? Since there are only 28 locations, we manually collected their floor area and # of floors from Google Maps. For this, we had to switch between normal map view and StreetView many times to confirm the number of floors! Finally, we estimated the total capacity by dividing their floor area by 5 sq. m. which is the required area per person inside buildings.

Calculating walkability

We also wanted to show the walking accessibility of each evacuation center. For this, we used the OpenRoute Service plugin of QGIS to generate isochrones for 5, 10, 15, 20, 25 and 30 minutes of walking by foot. This was then exported as a GeoJSON and loaded as a Mapbox Dataset.

Designing the Map

Prior to actually developing the interactive map, we wanted to explore which Mapbox style would suit our needs the best. We started with the Dark base map but eventually adjusted the base colors so we can highlight the waterways, which play a vital role in our story.

Our light base map with blue waterway accents

How to Present Everything?

We have at least 9 data layers going into our map. (Phew!)

With that in mind, we thought of having a scrollytelling panel to act as a guide on how to explore the data on the map. As the users read through the story, data relevant to the chapter of the story will be shown on the map. There will also be controls on the map to allow user to freely explore the available data through layer toggles and filters.

This framework gives us full control on what is shown on the screen and what we want the users to explore.

Building the App

Based on experience with building interactive tools with Mapbox GL JS, we decided to build our visualization using ReactJS as our front end framework. The main reason for using ReactJS is to maximize the concept of reusable components.

Reusable components with different values through ReactJS

Given that our data layers are on different scales using different color schemes, the legend should update based on what layer is shown but the design of the component would be the same. Here’s the template of our Legend component. (See GitHub repository for full implementation.)

On top of having reusable components, React also provides an easy way for different components to communicate with each other and share data. To illustrate, the Filter component dictates what data layer to show on the Map component.

• In the parent component App, we have a variable called layer in the state and a function to update the value called updateLayer.
• The value of layer is passed both to Filter and Map as props so that they can use it. The function updateLayer is also passed to Filter as props since that component is in charge of changing the value.
• Once the updateLayer function is triggered in Filter, it will update the state in App and React’s lifecycle will automatically pass the updated value to all the child components so they can use the new value.

To explore more about how we built the app, feel free to dive into the code on GitHub.

Conclusion

Building the visualization proved to be a real challenge! From getting the data to processing it and converting it to formats that can be easily ingested by Mapbox, there was a lot to consider in designing and actually coding. For us, Mapbox has proved to be very useful in visualizing multiple layers of geospatial data and it also provides you full control on how to manage it as you see fit.

On the flip side, other than just coding and processing the data, writing up the story and making sure everything is well researched is also just as important.

What’s Next?

The end of the #VizRisk challenge does not mean the end for this project. We hope to further improve on not only the tool but also the underlying analysis behind the risks involved and possible suggestions on policy and disaster preparedness and management in the future.