Decision Support for a Smart City: Combining algorithmic and human decision making to explore spatial inequality in smart cities

Turing funded project Spatial Inequality and the Smart City aimed to consider approaches to creating a ‘fair’ distribution of sensors across a city. The project resulted in a thinking tool to aid decision-makers in weighing up the gains and losses of different sensor placements for their communities. This post will focus on key features and technology decisions.

Project background

At a time when our urban population is increasingly unequal, we are collecting more and more data about inhabitants. When considering who is being monitored, we encounter issues of surveillance, inequality and ‘sensor deserts’ (Robinson and Franklin, 2021). This project focused on air quality sensors as an accessible and relatively non-controversial sensor through which to explore sensor placement.

Some assumptions were made in this initial pilot. Two local authorities (LA), Newcastle upon Tyne and Gateshead, are implemented. The lowest level of granularity for consistently available data was an output area (approximately 1000 people) (OA). It was assumed that each OA should have a maximum of one sensor and that the OA was considered fully covered by that sensor. Levels of coverage deteriorated across surrounding OAs according to the user-determined value of satisfaction coverage. This is the perceived satisfaction of a population inhabiting or working in the vicinity of a sensor. Crucially, this is the experience of being included in a sensor network rather than the actual ability of an individual sensor to monitor a particular area of space. In this sense, we are concerned with people’s own perception of being included in the smart city.

The tool has a base map of the LA and two core functionalities:

1. Data layers: overlay density of particular population groups, space syntax, schools and Index of Multiple Deprivation onto the base map. Data is presented in a standard format where possible, using ‘density’ to describe the percentage of people belonging to a group in that particular OA out of those belonging to the group across the whole Local Authority, per km². This was motivated by the desire to give an overview perspective of relative distribution across the whole LA.
2. Sensor network optimisation: the project involved the development of an algorithm to suggest possible sensor networks focused on selected population characteristics (place of work, place of residents, young people, and older people). Decision makers submit their priority objectives, number of sensors, and satisfaction coverage to the algorithm. A scatter graph plots the coverage of 200 possible networks onto a graph. The decision maker can select a network to view on the base map and view changes to coverage created by adding, deleting and moving sensors within the network.

Technology

Data was stored in an Azure Database for PostgreSQL with a PostGIS extension and served using Geoserver. The website is built using Angular 9, making use of components to handle individual features to reduce complexity.

Mapping functionality is built using this Angular Leaflet.js library by Asymmetrik. Although some integration of Leaflet.js with Angular is not always completely straightforward, the only time using Leaflet actually limited functionality was preventing a PDF export feature as markers with custom images and cluster markers were not transferred into the PDF. Angular Material was used to style the site.

Key features

• Walkthrough: ways the user can interact with the site are introduced in turn using a text modal with a coloured border to highlight the item in focus, as seen below.

• Base map: Leaflet.js is used to create a base map and handle all other map features. The map can be zoomed and panned, and uses Stamen’s ‘toner’ black and white map tiles to allow the data and sensor networks to stand out.
• Data layers: the user can toggle data layers on and off to explore population characteristics. Most are served as PNG image tiles by Geoserver (for example, workplace location, as shown in the image below). Others are served as GeoJSON and plotted as points using Leaflet.js (for example, school locations, also shown below).

Screenshot showing choropleth of density of workplace locations across Newcastle

Screenshot showing school locations

• Possible sensor networks: 200 possible sensor networks are generated by a genetic algorithm and plotted on a scatter graph according to how well they serve each of the user’s priority areas. The user creates a query using this form:

Query Builder

Highcharts.js was used to implement the graph and features such as clickable points, which change icon and colour to a green triangle to show which network is currently displayed on the base map. As the user interacts with the network, the adjusted coverage is plotted by dynamically adding another point (yellow diamond). The graph highlights gains and losses; for example, the green triangle in the image below shows a network that performs very highly for workers, but poorly for where people who are over 65 live.

Screenshot of query results showing possible networks plotted on graph and options to filter, view, and interact with the networks

• Viewing a sensor network: a single network can be displayed on the map at a time, with a shading per OA according to how well-covered it is by sensors. The darker green indicates a higher coverage.

Screenshot of sensor locations plotted in purple, possible additional locations in blue, and coverage per OA in green shading

• Interacting with the sensor network: Leaflet.js features and plugins are used to offer the user draggable sensors which snap to the nearest of set sensor locations (shown by blue dots in the image above). Users can click on a blue dot to add a new sensor and click on an existing sensor to delete it. Each adjustment causes the coverage to be recalculated and the graph and OA shading to be updated.

Algorithm + Human

By offering decision-makers data about their area’s inhabitants and infrastructure, they can make better decisions about how smart cities can be organised in a fair way. Users can explore how different sensor placements have gains and losses for inhabitants. The tool suggests a way to consider what is happening across the whole city (where people live and work, how they get between these places and where the most vulnerable are), along with the user’s knowledge of particular areas (modifying the algorithm’s sensor placements). Decision-makers can think through the impact of their choices in an accessible and visual manner.