Background

In an effort to improve access to financial services to the population in Uganda, HOT has been participating in a project attempting to map a different kind of financial service providers in Uganda. Financial service providers are entities that provide services like deposits, credit, transfers, withdrawals, foreign exchange etc, both in the formal and the informal sectors. In Uganda, examples are banks, ATMs, microfinance institutions, mobile money agents and Savings and credit co-operatives (SACCOs). Mapping them and viewing them through different thematic maps will allow different stakeholders such as the financial service providers themselves, the general public, regulators, donors and others to identify what areas are underserved or where there is potential for rolling out new coverage. The thematic analysis is built into the OSMA framework, and as such also provides an example of how thematic analysis can be added to OSMA.

Overview

HOT chose four thematic views which each answer a specific question that financial service providers might ask. The main goal was to create analysis that can provide a basis for decision-making, mainly for financial service providers to see where there could be a potential market (population density and economic activity), where their competitors are active or where there are areas that do not have existing FSPs. The same approach can be chosen for other thematic analysis; however, it is crucial that the information showed on the maps is already providing a certain degree of analysis when it loads. The analysis can then be refined or adjusted using the controls and parameters available. It was somehow challenging to find a good balance between providing sufficient analysis for the maps to be good decision-making tools, but at the same time not be too complex for the users to understand.

Thematic analysis and context data

There is great potential for thematic analysis using the data from OSM. Our technical proposal outlines how we made improvements in OSMA to allow for easier thematic analysis. In addition, good knowledge of the OSM keys is necessary in order to know what data could be relevant for the given user group. We also chose to introduce some external datasets to provide context, such as Worldpop.

However, there is a trade-off between using external datasets and data available in OSM. Population data can be re-downloaded from Worldpop and updated in case there is newer data.

For economic analysis, we chose to use a composite of data available in OSM in order to avoid the need for updating. After some trial and error, we used the following keys to show economic analysis

• Number of buildings
• Distance from the main road
• Number of mobile money agents
• Number of people (This came from Worldpop)

This is what gave the best result in Uganda, however, note that it might not give the same result in other areas due to the different nature of data available there. Other than that, we encountered the following challenges with the data for financial service providers available in OSM:

• Clear conventions were not followed during data collection: example:
  The operator property on some of the banks was empty while in other cases, some bank names were saved in short form, i.e. DTB was used in many cases instead of Diamond Trust Bank and this means that not all Diamond Trust Bank branches are rendered when you select it since some are saved under DTB.
• Mobile money agents are do not necessarily belong to an operator and the majority have services of up to 3 telecom companies. This made is quite hard to do comparison on mobile operators
• Data for financial service providers in Uganda is predominantly available in Eastern Uganda and Kampala because this is where the data collection exercises have taken place. For now, this, therefore, gives a distorted picture of the reality on the ground. We are hoping that as the data collection efforts continue, this will improve.

Proposed by

Timothy Kasasa (Laboremus), Benjamin Lutaaya (Laboremus)

The Problem

While there are over 5000 Tags in OpenStreetMap, currently, there are only 3 tags configured for analysis in OSMA. There could be several reasons but the major cause is the fact that the process of adding a new Tag is quite complex and fragile. An example is adding waterways here. Moreso, OSMA currently only allows for analysis on two parameters, i.e. User experience and feature count.

The major motivation behind these changes is to:

• Greatly simplify the process of adding new TAGs
• Allow for more complex analysis based on several parameters and a combination of data sources

These changes will enhance the current web-based application to allow advanced analytical features based on a variety of data sources that not only include OSM data but also external data sources such as World pop

Proposal

Code Base here

The user interface renders data that has been processed by the cruncher, thus most of the heavy lifting is done at the server as described by the OSM cruncher proposal.

Generic thematic analysis map

The thematic analysis map reuses the existing logic as much as possible, however, to allow for dynamic configuration of tag, and enable one to simply create complex analysis from configuration files; we restructured some of the moving parts.

Rendering the initial view.

All the configuration for thematic analysis is placed in the general settings folder app/settings/fspSettings.js. This configuration is dynamically loaded during the rendering of the map to render the respective data from the server(using id field) and to render the respective controls (using controls field) onto the UI.
This is sample configuration for loading mobile money agent data.

 {
 	  id:'mobilemoney'
      title: 'Mobile money agents in relation to population and economic activity',
      tooltip: {
        title: '',
        body:'Tool tip body'
      },
      legend: 'Number of Agents',
      controls: [
        {
          id: 'peoplePerAgent',
          type: 'range',
          field: '_peoplePerAgent',
          title: 'People per agent',
          label: 'people',
          range: {max: 12000, min: 0, selection: [0, 12000]}
        },
        {
          id: 'population',
          type: 'range',
          field: '_populationDensity',
          fieldMin: '_populationDensity',
          title: 'Population density',
          label: 'people/cell (,000)',
          range: {max: 15000, min: 0, selection: [0, 15000]}
        },
        {
          id: 'economic',
          type: 'range',
          field: '_economicActivity',
          title: 'Economic activity',
          label: '(1 : Low , 10 : High)',
          range: {max: 10, min: 0, selection: [0, 10]}
        }
      ]
    },
   

How this works

The diagram below shows an overview of the thematic analysis UI layout

Mbtiles path.

With this configuration, mbtiles are loaded from the server in the form of pbf files using the URL format {{server}}/{{id}}/{z}/{x}/{y}.pbf. these are then used as the initial rendering of the thematic analysis.

Client Controls

The UI controls are also created dynamically from this configuration, and for now, there are two type on controls rendered

Range controls

These controls create a range filter on a specified property in the feature collection and render only those that fall within the selected range. For example, you can show features with a population density of 1000 to 30000 people. This gives the user a lot of analytical power.

Scroll items

These controls allow further refining of data as they allow a user to show only features with a particular value. This comes in handy when comparing operators of different features. For example, one can choose a particular bank from list of banks

Point display

In case of point display, there are scenarios where many points are clogged up in a small area. This makes it very hard to make sense of such data. Therefore we made use of Leaflet markercluster. to aggregate point into groups for better rendering and analysis.

Case Studies

With these configurations, we implemented 4 case studies as an example of how thematic analysis can be done using OSMA. All the case studies are directed towards Financial service providers, but the level of flexibility shows how one can reuse these configurations to perform an even much more complex analysis.

Map 1 Show coverage of mobile money agents in relation to [population density, economic activity]

As a financial service provider, I can then decide to or not set up a mobile money agent within that radius. This decision will, of course, be based on how many people are found in that radius as well as the type of economic activity. This map visualizes how mobile money agents are distributed relative to population and economic activity. The map initially renders grid cells with people per mobile money agents.

A light colour means either low population density and hence few mobile money agents, or it means a high density of agents relative to population. Zooming in gives a more detailed view per cell. The grey areas do not have colour because there are no mobile money agents there.

A user will be able to drill down using filters (range bars):

• Persons per mobile money agent
• Economic activity
• Population count

Map 2 Show mobile money agents that are (at least) [--distance in km--] away from a [bank/ATM of a certain provider]

As a financial service provider, I can then decide to or not set up a bank branch closer to the mobile money agents for them to be able to deposit the money that they collect from the mobile money users.
Users can filter to identify areas with the number of MM agents at specified distances from a bank, no. within < 1km, 1-5, 5-10 km, and 10km+ (in addition to free-form input for distance)
This map visualises the overall distance from mobile money agents to a specific (operator) bank. Both the presence within [distance] is important, but also underserved mobile money agents; who are outside of [distance] of any/specific operator bank.

A user will be able to drill down using filters (range bars):

• Distance to [FSP type] (range bars)
• All banks by default. Narrow down (select) to specific operator

Map 3 Where are the [--ATM/Branches--] of [--Financial Service Provider--] (in relation to population density and economic activity)

As a financial service provider, I can then decide to or not set up an atm or bank branch based on the presence of my competitor financial service providers. Users can select the type of service (ATM/Bank branch) and the map grid will show all grid cells with the services for the selected FSP.
This visualizes competition between different FSPs (relative to population), giving an initial view of persons per FSP Type. This can then be split according to Persons per Operator (select/dropdown)

Map 4 I want to compare the presence of different (types of) [-Financial service Providers--]

As a financial service provider, I can evaluate the areas with few competitors. Users can filter a gridded map to display areas with a specific number of people per FSP. This can be further split according to operator/network.

Adding a new Tag

OpenStreetMap uses tags to add meaning to geographic objects. There is no fixed list of those tags. New tags can be invented and used as needed. Everybody can come up with a new tag and add it to new or existing objects. This makes OpenStreetMap enormously flexible, but sometimes also a bit hard to work with. Read More

Currently

in the existing implementation, to add a new Tag, you need 4 steps where you edit 7 files. The most complex step is to generate the styles file (step 2).
As seen here

1. Add tag configuration to filters in app/settings/options.js
2. Generating a style file based on the Mapbox Style Specification
3. Add the Tag to exclusion in app/settings/options.js
4. Add the Tag to exclusions in app/components/Stats/index.js
5. Import the style file in app/components/Map/glstyles/index.js and add it to the filters
6. Finally, create custom CSS for the legend in app/components/Legend/style.css

Add-Tag Script

OSMA front-end is packaged using npm scripts and webpack build tool. This creates a good platform for automating tasks. We thus leveraged this and created an npm script to automate the process of adding a new TAG to OSMA ui. See Code Here.

This simple but very powerful script provides a console based interface where a user is asked a couple of questions and then generates all the boilerplate required (including the mapbox.js style) to add a new tag.

The npm script, however, does not edit the code but guides the user on where to place the generated code

npm run add-tag

References

• OSM Tag Info https://taginfo.openstreetmap.org/about
• World Pop http://www.worldpopdata.org/

Background

In an effort to improve access to financial services to the population in Uganda, HOT has been participating in a project attempting to map a different kind of financial service providers in Uganda. Financial service providers are entities that provide services like deposits, credit, transfers, withdrawals, foreign exchange etc, both in the formal and the informal sectors. In Uganda, examples are banks, ATMs, microfinance institutions, mobile money agents and Savings and credit co-operatives (SACCOs). Mapping them and viewing them through different thematic maps will allow different stakeholders such as the financial service providers themselves, the general public, regulators, donors and others to identify what areas are underserved or where there is potential for rolling out new coverage. The thematic analysis is built into the OSMA framework, and as such also provides an example of how thematic analysis can be added to OSMA.

Overview

HOT chose four thematic views which each answer a specific question that financial service providers might ask. The main goal was to create an analysis tool that can provide a basis for decision-making, mainly for financial service providers to see where there could be a potential market (population density and economic activity), where their competitors are active or where there are areas that do not have existing FSPs. The same approach can be chosen for other thematic analysis; however, it is crucial that the information showed on the maps is already providing a certain degree of analysis when it loads. The analysis can then be refined or adjusted using the controls and parameters available. It was somehow challenging to find a good balance between providing sufficient analysis for the maps to be good decision-making tools, but at the same time not be too complex for the users to understand.

Thematic analysis and context data

There is great potential for thematic analysis using the data from OSM. Our technical proposal outlines how we made improvements in OSMA to allow for easier thematic analysis. In addition, good knowledge of the OSM keys is necessary in order to know what data could be relevant for the given user group. We also chose to introduce some external datasets to provide context, such as Worldpop.

However, there is a trade-off between using external datasets and data available in OSM. Population data can be re-downloaded from Worldpop and updated in case there is newer data.

For economic analysis, we chose to use a composite of data available in OSM in order to avoid the need for updating. After some trial and error, we used the following keys to show economic analysis

• Number of buildings
• Distance from the main road
• Number of people (This came from Worldpop)

This is what gave the best result in Uganda, however, note that it might not give the same result in other areas due to the different nature of data available there. Other than that, we encountered the following challenges with the data for financial service providers available in OSM:

• Clear conventions were not followed during data collection: example:
  The operator property on some of the banks was empty while in other cases, some bank names were saved in short form, i.e. DTB was used in many cases instead of Diamond Trust Bank and this means that not all Diamond Trust Bank branches are rendered when you select it since some are saved under DTB.
• Mobile money agents are do not necessarily belong to an operator and the majority have services of up to 3 telecom companies. This made it quite hard to do comparison on mobile operators
• Data for financial service providers in Uganda is predominantly available in Eastern Uganda and Kampala because this is where the data collection exercises have taken place. For now, this, therefore, gives a distorted picture of the reality on the ground. We are hoping that as the data collection efforts continue, this will improve.

Proposed by

Timothy Kasasa (Laboremus), Benjamin Lutaaya (Laboremus)

The Problem

While there are over 5000 Tags in OpenStreetMap, currently, there are only 3 tags configured for analysis in OSMA. There could be several reasons but the major cause is the fact that the process of adding a new Tag is quite complex and fragile. One would have to go through 5 step and edit 4 files just to have a new tag. An example is adding waterways here

• Create a filter configuration for the Tag
• Add Code to the run.sh script to enable crunching
• Edit oqt-user-experience/map.js file to add static experience initial value
• Edit oqt-user-experience/index.js file to add static experience initial value

Furthermore, in order for the cruncher to support thematic analysis, there is a need to make the code highly dynamic and configurable such that it allows for easier and more scalable addition of features to the backend, reducing the amount of code and configuration needed to change exposed features. these datasets should also be easy to integrate with an API.

The solution

This proposal is heavily supported by the front-end proposal and all the changes and context are highly dependant on the front end implementation.

OSM-Cruncher architecture

A proper understanding of the generic architectural flow of the OSM cruncher is vital in appreciating the refactoring required to implement thematic analysis within the existing system. This process can be broken down into three major steps.

Filtering phase

At this point the entire world dataset from OSM if filtered to obtain the required TAG. The output is a minimal .mbtiles file

Binning and aggregation

AT this stage, OSM features are grouped into geocells for analysis.

Downscaling

At this stage, the geocells are aggregated to generate tiles at a lower zoom level, for example, zoom level 12 mbtiles are aggregated to obtain zoom level 11 tiles

A more detailed cruncher architecture can be found here

Code Base

Adding a new Tag

As described above, this process is very cumbersome, however, with the new implementation; we made a couple of additions and refactorings to greatly improve this process. A user only needs to edit one place and the rest of the process is automated, i.e. Compared to the fomer 4 steps, current to add a new tag for example power;

• Create the config file, and place it in fsp-config folder with the format below:

{
    "name":"power",
    "geometry": "Point",
    "tag": "power",
    "factor": 32,
    "experience": {
        "file": "./experiences.json",
        "field": "power"
    }
}

And that's all, during the crunching process, the cruncher automatically picks up this configuration file and creates a .mbtiles file in the results folder. This will also be automatically be picked up by the tile server and made available for the client to consume.

Thematic analysis

WIth the new dynamic configuration, we are able to create even more complex filters and consequently do very detailed analysis on OSM data. For example, we wanted to be able to find out the economic activity of given areas in Uganda. For this, we needed a couple of datasets.

• Number of buildings
• Number of roads
• Number of mobile money agents
• Population density

To this end, we created two filter files.
A json configuration that is passed to the filter phase (as described above) of the cruncher

{
    "geometry": "Point",
    "id": "popnbankatm",
    "composite": true,
    "tags": [
        "building",
        "highway"
    ],
    "amenities": [
        "mobile_money_agent"
    ],
    "fsp": "qn3"
}

Filter script, which is passed to the aggregation and downscale phases

const config = {
    aggregate: {
        sum: [
            { name: '_buildingCount', prop: '_buildingCount' },
            { name: '_noOfMMAgents', prop: '_mobile_money_agentCount' },
            { name: '_highwayCount', prop: '_highwayCount' },
        ],
        population: true,
        economic: true,
        divisors: [
            { name: '_peoplePerAgent', divident: '_noOfMMAgents', divisor: '_population' }
        ]
    },
    downscale: {
        max: ['_noOfMMAgents', '_population','_economicActivity','_peoplePerAgent'],
    }
}

During the crunching process, these file is picked dynamically and processed. the output tile data is then consumed by the client side OSMA to render this map. As a financial service provider, I can then decide to or not set up a mobile money agent within that radius. This decision will, of course, be based on how many people are found in that radius as well as the type of economic activity. This map visualizes how mobile money agents are distributed relative to population and economic activity. The map initially renders grid cells with people per mobile money agents.

Serving tile data to the front end

All the generated tiles and geojson files are stored in the results folder. We modified the server script to dynamically picked up any .mbtile file in this folder and make it available for the client as pbf with the URL format {{server}}/tag/{z}/{x}/{y}.pbf

The server also statically exposes JSON Files int the results/json directory which can be used for point analysis.

API

To demonstrate the ease with which this data can be used with an API, we developed a simple API, to compute the number of mobile money agent in a given distance from a bank or atm

{{server}}/distance/${from}/${to} 
where from = Minimum distance, to= Maximum distance

This simple API is used by Map2 which visualises the overall distance from mobile money agents to a specific (operator) bank. Both the presence within [distance] is important, but also underserved mobile money agents; who are outside of [distance] of any/specific operator bank.

Updating data

All the data generated can be updated whenever HOT has mapped out more features to give a more current analysis to the user of this tool. See x-run.sh for an example invocation of the scripts above and integration with the example server.

Finacial service providers

The list below shows the list of OSM amenities that we chose for our analysis

Challenges and open issues

• The major issue that is still open is Zoom levels and feature aggregation
• Data for financial service providers in Uganda is predominantly available in Eastern Uganda and Kampala because this is where the data collection exercises have taken place. For now, this, therefore, gives a distorted picture of the reality on the ground. We are hoping that as the data collection efforts continue, this will improve.

References

• OSM Tag Info https://taginfo.openstreetmap.org/about
• World Pop http://www.worldpopdata.org/