Skip to content
/ healthcare-access-idai Public
forked from GIScience/healthcare-access-idai

Material on an analysis of healthcare access in Mozambique with the impact of cyclone Idai

License

GPL-3.0 license
0 stars 2 forks Branches Tags Activity
Star
Notifications You must be signed in to change notification settings

PPatty666/healthcare-access-idai

BranchesTags
 
 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

3 Commits
docs
docs
 
 
local-ors
local-ors
 
 
src
src
 
 
.gitignore
.gitignore
 
 
LICENSE.md
LICENSE.md
 
 
README.md
README.md
 
 
healthcare_access_idai.Rproj
healthcare_access_idai.Rproj
 
 

Repository files navigation

Healthcare accessibility and road criticality during floods disaster

Analysis of the impact of disasters on accessing health facilities by population and assessment of the road criticality in delivering the access. This analysis was done using the case study of floods induced by the cyclone Idai in Mozambique in march-april 2019.

The analysis was developped by Sami Petricola with the support of Marcel Reinmuth and used for a scientific publication.

Content



System requirements

Scripts have been tested on the following systems

Versions Linux MacOS
OS Ubuntu 20.04.2 11.3
R 4.0.5 4.0.5
GDAL 3.2.1 3.3.0
GEOS 3.9.0 3.9.1
PROJ 7.2.1 8.0.1

WARNING: Make sure to use a version of GEOS > 3.9

Some issues on geometry operations (st_difference) were detected with the use of older libraries which don't include OverlayNG in JTS. It was implemented in JTS version 1.18.


Performance

An estimation of the time performance can be found here

Installation

Clone git repository:

git clone https://gitlab.gistools.geog.uni-heidelberg.de/giscience/disaster-tools/health_access/local_ors_accessibility.git

Directory structure

Running the scripts will create automatically the required folders

local_ors_accessibility: working directory

  • docs: several documentations about the requirements and running time estimation
  • src: contains subfolders with the R script to be used according to the process steps
  • data : folder automatically created to store the data files
    • download: store all the input files downloaded by the script
    • results: store all the output of the scripts
      • profile1 (ie. driving-car): store the results of the analysis of the defined profile
        • isochrones: output of the vector-based accessibility analysis
        • raster: output of the raster-based accessibility analysis
        • centrality: output of the centrality analysis
      • profile2: .....
  • local-ors: directory to be used by the ORS docker container
    • ors-impact: directory of the ORS instance with the osm network impacted by the floods
      • conf: configuration of the ORS instance
      • data: data used by the ORS. Including the osm.pbf file with the network to be used.
    • ors-normal : directory of the ORS instance with the normal osm network
      • same structure as ors-impact

R

  • Start R in the local_ors_accessibility working directory
cd local_ors_accessibility

Packages

Install the R packages with the script install.packages.R:

rgeoboundaries, tidyverse, sf, httr, geojsonsf, openrouteservice, rjson, jsonlite, raster, osmextract , rmapshaper, sfheaders, stars, exactextractr, tictoc, OpenStreetMap, tmap, tmaptools, grid, gridExtra, polylabelr, tidygraph, sfnetworks, doParallel

Other dependencies

Install the dependency:


Docker

Install docker.

More information can be encountered here

I. Data preparation


1. Data download

1.1 Main datasets

Objective:

Download and process all the input datasets required for the analysis.

Note: the flood data requires more processing and therefore is presented in the following section


Boundaries

The Mozambique boundaries are downloaded from geoboundary and will be used by different scripts to get a bounding box, to retrieve OSM data, etc.

OSM Health facilities

We use the Ohsome API to download the health facilities from OSM. We defined 3 scopes of healthcare level:

  • primary
  • non_primary (secondary)
  • all

World population

We download the population constrained estimation done by worldpop


Parameters:

Some parameters MUST be set manually.

Open the scripts and adjust the 2.1 section accordingly:

  • country: the country of the area of interest, it must be introduced as the ISO code alpha 3. By default it is set to MOZ for the Mozambique cyclone Idai simulation.
  • scope: level of healthcare facilities, choose between primary, non_primary and all

Script:

  • 1.1_datapreparation.R : all datasets downloaded and processed will be stored in the appropriate folders

Sub-script:



1.2 Preparation of the flood data

Disaster event images

There are 3 different datasets with open access showing the extent of the flooded areas of Idai Cyclon:

  • Copernicus Emergency Management Service:

    The vector files of the delineation of flooded area can be downloaded here.

    This dataset presents 2 limitations: the impossibility to include the download into a script and the limited extent of the region included

  • ARC - African Risk Capacity / WFP:

    The raster file of the flooded area has been published in HDX by WFP (World Food Program) and can be downloaded here.

    This dataset has been provided by the African Risk Capacity which publish some information about the dataset here.

    Dataset published : 21 March 2019

    Data detection: 12-20 March 2019 (to be confirmed)

    Technology used : natural microwave radiation, details here

    Resolution: 90 m

  • UNOSAT - UN Operational Satellite Applications Programme (website) :

    The vector files of the flooded area has been published in HDX and can be downloaded here or here.

    Dataset published : 26 March 2019

    Data detection: 13-14-19-20-26 March 2019

    Technology used : Sentinel-1 Imagery

    Resolution: 10 m

After visual analysis, we decided to use UNOSAT and ARC/WFP dataset due to the larger geographical coverage. Moreover, both datasets can be downloaded within a script.


Scripts:

  • 1.2_floods_data_preparation.R : run the script to download the datasets of the floods. The script will also combine them and write an ouptut geopackage file.


2. Create a .osm.pbf file

OpenRouteService is based on a osm.pbf file which stores the road network from OpenStreetMap. We need to retrieve it from OpenStreetMap as well to alter a version to cut out the flooded area


Scripts:

  • 2._create_impacted_pbf.R :

    • downloading of the osm.pbf and save it to be used in the ors-normal instance (../local-ors/ors-normal/data)
    • use the flooded area retrieved in step 1.1 to create a .poly file that will be used by osmosis to cut out the flooded area of osm.pbf. The flooded area is processed (crop, simplify, remove holes) to ensure a better performance of the osmium process. The output will used by the ors-impact instance (../local-ors/ors-impact/data)

    To know more on .poly files, read here

    To know more on Osmosis tool, read here

    Tip 1 : to check the processed flooded area created: you can visualise the layer "simpl_impact_area" created in the geopackage impact_area.gpkg

    Tip 2 : to check the poly file created: transform to geojson with python package polygon2osm, script polygon2geojson.py

    Tip 3 : to have an acceptable performance of the script, the .poly file created should not be bigger than 1 or 2Mb



II. Healthcare accessibility analysis

Vector-based analysis

Objective:

Isochrones of time to the closest health facility are calculated by the OpenRouteService API and then processed to retrieved the population included in each time range

1. Launch ORS instances

Objective:

OpenRouteService API needs to be set up locally to run the analysis. Two instances will be set:

  1. "Normal" instance: considering the road network of OpenStreetMap
  2. "Impact" instance: considering the road network of OpenStreetMap cutted out of the roads flooded by the cyclone

1.1 "normal" ORS instance

The launch of the ORS instance must be done in command line opened in local_ors_accessibility working directory:

cd local-ors/ors-normal

docker-compose up

1.2 "impact" ORS instance

The launch of the ORS instance must be done in command line opened in local_ors_accessibility working directory:

cd local-ors/ors-impact

docker-compose up

2. Isochrone processing

Objective:

  • This analysis will retrieve and process the isochrones from the ORS API endpoint.
  • It will also compare the loss of accessibility to health facilities between flooded the situation and the normal situation
  • Lastly, it will create the visualisations of the analysis results as .png images.

Parameters:

Some parameters MUST be set manually.

Open the scripts and adjust the 2.1 section accordingly:

  • country: the country of the area of interest, it must be introduced as the ISO code alpha 3. By default it is set to MOZ for the Mozambique cyclone Idai simulation.
  • scope: level of healthcare facilities, choose between primary, non_primary and all
  • profile: refers to the transportation mean, choose between foot-walking and driving-car

Scripts:

  • isochrones_main.R : the main script will call the functions from the sub scripts described below for an integrated process.

Sub-Scripts:

  • 1.1_isochrones_local.R : retrieve the isochrones from your local ORS instance according to your scope and profile.

  • 1.2_dissolve_isochrones.R : dissolve together (union) all the isochrones of a same time range. If an area has access to 2 (or more) health facilities with conflicting different time range, the lower range will be considered.

  • 1.3_difference_isochrones.R : differentiate the isochrones to avoird overlap between isochrones of different time range

  • 1.4_population_estimates.R: calculate (sum and proportion) of the population which is included in the iscohrones of each time range.

  • 2.1_loss_analysis.R :

    The difference between the 2 situations generates many virtual polygons which only represent the approximation of the edges of the isochrones created by the ORS API. To reduce this effect, we crop the loss_analysis to the bounding box of the floods and we use the "pole of inaccessibility" algorithm (bigger circle inscribed within the polygon) to filter out these polygons. The threshold to filter is set to 0.0005 degress (approx. 50 meters at the Mozambique latitudes)

  • 2.2_loss_population_mask.R :

    Crop the population dataset to the extent of the polygon where loss of access was highlighted to be able to visualise it



Raster-based analysis

Objective:

  • This analysis will perform the accessibility analysis based on a friction layer and raster-based approach.
  • It will also compare the loss of accessibility to health facilities between flooded the situation and the normal situation.
  • Moreover, it will perform a comparison of the results between the raster-based approach and the ORS-isochrones approach.
  • Lastly, it will create the visualisations of the analysis results as .png images.

Parameters:

Some parameters MUST be set manually.

Open the scripts and adjust the 2.1 section accordingly:

  • country: the country of the area of interest, it must be introduced as the ISO code alpha 3. By default it is set to MOZ for the Mozambique cyclone Idai simulation.
  • scope: level of healthcare facilities, choose between primary, non_primary and all
  • profile: refers to the transportation mean, choose between foot-walking and driving-car
  • threshold: refers to the accessibility time, it will be used to compare the extent accessibility between raster-based and Isochrones-based methos. Choose an integer between 1 and 6

Scripts:



III. Centrality analysis

Objective:

Evaluate the resilience of the road network by calculating a targeted edge centrality indicators:

  • Targeted centrality : count the occurence of a segment of the network in the shortest paths from a grid of population nucleus to some destinations points (healthcare facilities by default)

The analysis is based on OpenRouteService Centrality and ExportAPI endpoints. Please refer to part II.1. Launch ORS instances to get started with ORS.


Notes:

  • The calculation is based on ORS API export endpoint and post-processed in R.

  • The targeted centrality uses the population grid aggregated to a 1km2 grid to define the sources of the paths to calculate and will use the health facilities set in the scope parameter as destination.

  • The size of the bounding box of the area of interest would impact the computation time. The bigger the bbox, the more paths will be calculated and, thus, increasing the computation time.

  • The script generates several outputs:

    • unidirectional vs. bidirectional network, considering whether the network edges are unidrectional or bidirectional. With bidirectional the centrality score will not take into account the direction of the path on the segment. With unidirectional the centrality score does take into account the direction, thus, if a segement is used by paths in both direction, the segment will be considered as 2 different segments with 2 differnet scores.
    • targeted centrality vs. populated centrality: the targeted centrality is an indicator inspired from the betweenness centrality by counting the occurence of the segment in the shortest paths between sources and destinations points. On the other hand, the populated centrality indicator sum the population that would potentially pass through the segment in the shortest paths between sources and destinations.

Parameters:

Some parameters MUST be set manually.

Open the scripts and adjust the 2.1 section accordingly:

  • profile: refers to the transportation mean, choose between foot-walking and driving-car
  • scope: level of healthcare facilities, choose between primary, non_primary and all
  • focus_area: refers to the transportation mean, choose between Dondo, Tica, Quelimane, Mocuba and Makambine.
  • directionality: can be bi or uni
  • indicator: can be tc or pc
  • tc_cluster: in km, refers to the maximum distance to be considered between a population nucleus and the health facilities (it is set to 20km by deafult)

Script:

Sub-scripts:

3. Centrality difference

Objective: Compare the targeted score of the road segment before the floods and after the floods.

Parameters:

Some parameters MUST be set manually.

Open the scripts and adjust the 2.1 section accordingly:

  • profile: refers to the transportation mean, choose between foot-walking and driving-car
  • scope: level of healthcare facilities, choose between primary, non_primary and all
  • focus_area: refers to the transportation mean, choose between Dondo, Tica, Quelimane, Mocuba and Makambine.
  • directionality: can be bi or uni
  • indicator: can be tc or pc
  • tc_cluster: in km, refers to the maximum distance to be considered between a population nucleus and the health facilities (it is set to 20km by deafult)

Script:



V. OSM data completeness analysis

1. Aggregation at country level

Objective:

Using Ohsome API, analysis of the the contribution of entities in OSM:

  1. roads length
  2. Health facilties
  3. User activity

Scripts:



2. Disaggregation between flooded and non flooded regions

Objective:

Using Ohsome API, analysis of the the contribution of entities in OSM:

  1. roads length
  2. Health facilties
  3. User activity

Scripts:

About

Material on an analysis of healthcare access in Mozambique with the impact of cyclone Idai

Resources

Readme

License

GPL-3.0 license
Activity

Stars

0 stars

Watchers

0 watching

Forks

0 forks
Report repository

Releases

No releases published

Packages

No packages published

Languages

  • R 100.0%