Press image (NL)

Municipality of Amsterdam

Busy Image is a web app, which gives a picture of the current busyness in the city by bringing together different sources of information.

Last change on 4th of December 2024, at 9:32 (CET) | Publication Standard 1.0

• Publication category: Other algorithms
• Impact assessment: DPIA
• Status: In use

General information

Theme

• Space and Infrastructure
• Economy

Begin date

Field not filled in.

Contact information

[e-mail]

Responsible use

Goal and impact

Crowding in public spaces has been a problem in Amsterdam for years. Since the corona pandemic, it has only become more important to have a good picture of how busy the city is. Druktebeeld is a web app, which gives a picture of the current busyness in the city by bringing together different sources of information. It shows, for example, how many visitors are at a location or which parking spaces are in use. To get this picture, we use visitors' location data via, for example, the Weatheronline web app.

Busy image is intended to inform the public about how busy public spaces are. People can see how busy it is somewhere, and then choose to go there at a quieter time, or take a different route. Moreover, Druktebeeld helps the municipality manage crowds when necessary.

Equity and justice

Druktebeeld's models deal only with numbers of people and cars, not personal characteristics.

We examined the input data for the transient model (CMSA counts). This showed no bias based on race or gender. The algorithm is trained with a variety of images without considering the race or gender of the people in those images. The algorithm only counts the number of heads.

The input data of the display model (Resono counts) are based on GPS locations of an app user group. Thus, only locations of people present are used. This will give a bias in the counts, especially by country of origin, but possibly also, for example, by gender or age. As these person characteristics are not collected by Resono, we cannot say exactly how big an effect this has. MAC addresses are not used.

When we started developing the web app, we asked stakeholders (members of the public and municipal employees) about their needs. Stakeholders can also participate by indicating in the webapp whether the crowding indication reflects their own experience/interpretation of crowding. We also developed a separate channel for the municipality's crowd management team to send us more extensive feedback.

The results of the models can be viewed in the Pressure Image web app. This app is not yet fully suitable for disabilities such as colour blindness and illiteracy, and is only available in Dutch.

Considerations

Field not filled in.

Human intervention

Human-in-command.

No automated decisions are made based on Druktebeeld's models. Every decision based on crowding is made by humans, which can be either officials or citizens, with support from the Druktebeeld data and web app.

From the 'pass-by' and 'impression' models come mass indications. These are monitored by issuing a report every few weeks. This report evaluates the input data, user feedback on the crowd indications and feedback from the crowd management team on the crowd indications. The report includes tables and graphs with data and results that appear unexpected/irregular. Following the results of the report, the models are adjusted as necessary.

Risk management

The risks identified are:

1.Decision is taken on incorrect indication of crowds.

There may be differences between presented (modelled) and observed (actual) crowds. As a result, someone may:

• avoided a location/route because it was (too) crowded, when it was not;
• use a location/route assuming it was not (too) busy, when it was.

Thresholds are continuously evaluated to ensure that users have the best possible indication of crowding. In this evaluation, we also take users' feedback into account.

2.Residents/visitors feel they are being watched by the municipality.

When using the web app, people may feel that they are being watched, because of all the data on crowding that is apparently available.

By using the app, people may also feel they are being followed. But their location is collected and stored only if they want to give feedback and consent to share their location data. This location data is linked to an id, not personal information.

There is a clear opt-in that appears only when you yourself click the option to share your location or give feedback. It is not forced on you by a push-notification or pop-up and does not appear automatically, as with many other websites.

All data we receive for the Print Image models are aggregate counts. There are privacy measures in place by the parties providing the data. They also do not receive personal data such as gender, age and residential address.

3.Unintended use of the information.

We show crowds, including actual numbers of pedestrians. This can be used in ways the developers did not intend. For example, people might look for crowded places instead of avoiding them. Pickpockets could use the app to look up crowded locations.

By not showing actual numbers, we can mitigate these risks. This is still under discussion.

4.The municipality has not independently verified that the data obtained by Resono is fully anonymised. ICT has commissioned an independent investigation and has issued a certificate for this, see risk 'data obtained'. Link: https://blog.reso.no/privacy-verified-certificering-toegekend-aan-resono-2/.

Impact assessment

Data Protection Impact Assessment (DPIA)

Operations

Data

CMSA

The Crowd Monitoring System Amsterdam (CMSA) provides information on the number of passers-by at a number of busy spots in the city. These are pedestrians. The data is anonymous. Mainly 2D and 3D sensors are used in CMSA. With these, we measure how busy somewhere is. "By collecting data on numbers, densities and flows of pedestrians, it is possible to take smarter measures to manage crowds properly." See link https://www.amsterdam.nl/privacy/specifieke/privacyverklaring-parkeren-verkeer-bouw/crowdmanagement/) https://api.data.amsterdam.nl/v1/crowdmonitor/passanten/?format=api

Resono

To indicate crowds in parks, squares and shopping areas in the city, we use data from the company Resono. "Resono measures crowds at any location with a mobile panel of more than a million people. With this, we make an accurate estimate of crowds within a given time frame. Locations can vary in area and type. Think, for example, of a shop, shopping area, car park, neighbourhood or city. With Resono, customers have integral insight into visitor behaviour." (translated from reso.no) The municipality decides for which areas Resono collects the data. The dataset contains an estimate of the number of moving people within those areas, per quarter of an hour. Thus, the municipality does not receive information on individuals, only aggregated data. Resono complies with Dutch and European privacy laws. They have no personal information about people (such as age, gender), only anonymous location data. Resono's privacy policy can be found here: https://reso.no/privacy-policy/

Car park occupancy

This source provides near real-time availability of parking locations in Amsterdam, including some P+R locations. These are public parking garages and lots, with a focus on large locations (200+ spots) in the city centre. This therefore does not include on-street parking. The data comes from multiple parking management systems, which count cars entering and exiting. The data are collected and unified by the company Vialis.

National Data Portal Road Traffic

Floating car data from the National Data Portal Road Traffic. These are open data, based on aggregated and anonymous data from navigation systems. The data are anonymised.

GVB

Anonymised overview of number of check-ins and check-outs at GVB to predict crowds at major metro stations.

Links to data sources

• CMSA: https://api.data.amsterdam.nl/v1/crowdmonitor/passanten/?format=api
• Resono: https://reso.no/
• Parkeergaragebezetting: https://open.data.amsterdam.nl/uploads/actuele_beschikbaarheid_parkeergarages/Beschrijving%20Dataset%20-%20Actuele%20beschikbaarheid%20Parkeergarages%20v2.pdf
• Parkeergaragebezetting: opd.it-t.nl/data/amsterdam/GuidanceSign.json

Technical design

Model architecture

*For the visualisations in Pressure View, we used three models, one for each data source. The purpose of the models is to translate a value into a crowding indicator:

*not busy: easy to keep 1.5m distance/sufficient parking spaces (colour green)

*pressure: possible to keep 1.5m distance / few available parking spaces (colour orange)

*too busy: difficult/not possible to keep 1.5m distance / (almost) no available parking spaces (colour red)

*Pressure is somewhat subjective. The aim is to show the average crowding of app users via the colours in Busy Image. When the 1.5m measure was abolished, we adjusted the definitions of the colours. We use user feedback when setting pressure thresholds (not directly when users provide feedback). The models create two threshold values per location: low-pressure threshold and high-pressure threshold. These values are calculated and stored every few weeks (Resono) or months (CMSA & parking). If the count at a location, at a given time is:

*Under pressure threshold low, a location will be marked 'not busy'.

*Between pressure threshold low and pressure threshold high, it gets the indication 'busy'.

*Over crowd threshold high, it gets the indication 'too busy'.

*These pressure indications are calculated every 15 minutes for each location (from each source) and displayed in the Pressure Image web app.

Passer-by model (CMSA)

The purpose of this model is to create thresholds for the number of people passing a sensor. Pressure thresholds are calculated directly based on the width of the street where the sensor is located. For some locations, the municipality's crowd management team can adjust the values based on visitor feedback.

Impression model (Resono)

*The purpose of this model is to calculate thresholds to estimate how many people are in a given area. The model is a decision tree with the following inputs:

*historical Resono data;

*type of location (park/square/shopping street);

*area (square metres of the park/square/shopping street);

*length of paths within the area (collected using OpenStreetMap);

*feedback from web app users; and

*feedback from the municipality's crowd management team.

*The resulting pressure thresholds obviously vary by location.

Parking model

Using past pressure data, we can give an indication of how likely a location is to become full at the time the user checks Pressure View. The pressure data also gives an indication of whether there is sufficient time between the moment a user checks Pressure Image and the moment he arrives at the parking location and finds a spot. The occupancy rate is determined on the basis of:

*the available spaces;

*The total capacity per garage as the difference between the total number of available spaces; and

*the available spaces of the past 5 quarters.

*At present, we only use information on short-stay parking. Thresholds are determined for each location by analysing historical data. For most locations, the pressure threshold 'low' is set at 90 per cent occupancy. Below this percentage, there are sufficient spaces. For these locations, the pressure threshold 'high' is set at 95 per cent. Between 90 per cent and 95 per cent, there are sufficient places available, but they are likely to be full within 30 minutes. For some locations, spaces may fill up faster. At those locations, the 'low' and 'high' thresholds are 80 per cent and 90 per cent respectively.

Crowding expectations for metro stops

We make a crowd forecast for the coming week at metro stops. To do this, we use past check-in and check-out data, weather data and the weather forecast. The threshold values are set for each stop depending on their surface area. The crowding forecast is determined based on:

*Number of check-ins and check-outs last year

*Surface area of the metro stop

*Weather data last week

*Weather forecast next week

External provider

Internally developed