Amsterdam ANPR
Blaise Kelly
18/01/2022
Introduction
This document discusses a reproducible method for analysis of Auto Number Plate Recognition (ANPR) cameras.
Data from the ANPR cameras in Amsterdam was provided by the City of Amsterdam for the full day of 2019-02-14. An analysis was carried out on the data to demonstrate how it can be used to provide traffic count, speed and ultimately emissions data for a road network.
To preserve privacy, the data was provided with the vehicle number plates ‘hashed’ with a unique ID that stayed with the vehicle for the full period of data. Additional data can be provided with the ID, such engine data characteristics.
Two data sets were provided, camera information, including location, which will be called ‘camera data’ and a dataset which shows the ID and timestamp of vehicles that were sighted by each camera, which will be called ‘vehicle data’.
The camera data locations are plotted below.
Generating route data
The ‘vehicle data’ is simply a time stamp, defined to the nearest second, for each vehicle observation that took place. An example for vehicle ID 5a97ecd9-75b8-416f-af70-9c65c9957768, sorted from earliest sighting to last, with seconds since 1900-01-01 is shown in the table below.
| date | Cameranummer | id | seconds |
|---|---|---|---|
| 2019-02-14 00:02:27 | 10001 | 5a97ecd9-75b8-416f-af70-9c65c9957768 | 1550102547 |
| 2019-02-14 00:12:41 | 3724001 | 5a97ecd9-75b8-416f-af70-9c65c9957768 | 1550103161 |
| 2019-02-14 07:40:30 | 5002 | 5a97ecd9-75b8-416f-af70-9c65c9957768 | 1550130030 |
| 2019-02-14 07:49:31 | 3711001 | 5a97ecd9-75b8-416f-af70-9c65c9957768 | 1550130571 |
| 2019-02-14 16:44:30 | 3410001 | 5a97ecd9-75b8-416f-af70-9c65c9957768 | 1550162670 |
| 2019-02-14 16:53:41 | 3756001 | 5a97ecd9-75b8-416f-af70-9c65c9957768 | 1550163221 |
| 2019-02-14 23:33:43 | 10001 | 5a97ecd9-75b8-416f-af70-9c65c9957768 | 1550187223 |
| 2019-02-14 23:43:51 | 3724001 | 5a97ecd9-75b8-416f-af70-9c65c9957768 | 1550187831 |
Calculating journey time between each sighting.
| from | to | journey_time | hour |
|---|---|---|---|
| 10001 | 3724001 | 614 | 0 |
| 3724001 | 5002 | 26869 | 0 |
| 5002 | 3711001 | 541 | 7 |
| 3711001 | 3410001 | 32099 | 7 |
| 3410001 | 3756001 | 551 | 16 |
| 3756001 | 10001 | 24002 | 16 |
| 10001 | 3724001 | 608 | 23 |
The time difference between some sightings is very large. It is likely these sightings represent the time between a journey ending and another starting or a trip that left the network and rejoined. Journey times of trips where a vehicle was parked up are not representative of traffic conditions for journeys that left the network estimating the route a vehicle took is difficult. Therefore, a token time limit of 30 minutes (1800 seconds) has been chosen to remove any journey that is longer than this in order to only include continuous journeys. Applying this to the example vehicle gives the following journey data.
| from | to | journey_time | hour |
|---|---|---|---|
| 10001 | 3724001 | 614 | 0 |
| 5002 | 3711001 | 541 | 7 |
| 3410001 | 3756001 | 551 | 16 |
| 10001 | 3724001 | 608 | 23 |
Origin Destination
Once the journeys in the data have been defined for each vehicle an origin destination (OD) matrix can be created to summarise the trips. One way of representing this is to use desire lines, which essentially is a straight line between nodes (cameras).
The desire lines for all the unique origin destination (OD) journeys undertaken during the full day are shown below. Average speed is represented by colour and flow represented by line width.
An animated loop showing how these vary for each hour of the day is shown below.
Creating routes
To define flows and speeds for the roads in the network it is neccesary to determine which roads the vehicles travelled down between their OD points. This has been estimated using the osrm R package which takes a start and end point and returns a linestring representing the route.
However, location of the cameras provided in the dataset is somewhat ambiguous. An example of this is point 1002, shown in red below:
The site is almost equidistant to the road to the north and the south. The street name in the data more closely matches the road to the south, however visual inspection with Google Street View shows the camera is on the carriageway to the north of the camera:
To ensure osrm uses the best start and end point locations an attempt has been made to ‘snap’ the points to the road that best matches the location of the camera and the direction of flow it is measuring.
The outcome of this process is shown below:
Once a route has been assigned to each OD pair we have a full data
For OD points that are close together there can be a good degree of certainty as to the route, however for some OD points, particularly those that are far apart, the routes might not represent reality. In addition even the when a most likely route has been defined, human choice/error/road conditions might mean a vehicle did not go that way.
An example of a route that has a high degree of certainty and one with less is shown below. The route in orange is only a short stretch with little choice of route, where as the route highlighted in pink potentially has a number of alternative options, depending on the local road network.
Combining data
Generating routes for each OD grouping and matching with the hourly data results in many overlapping routes. In order to use this data to provide data for individual sections of road in the network this data needs to be combined in a way that gives weight to the geometry of the road.
The function ‘overline’ from the stplanr R package https://rdrr.io/cran/stplanr/man/overline.html does just that. The overlapping lines representing OD routes can are combined into a single route network. Below is the same OD plot shown earlier but with each OD grouping routed via the Open Street Maps algorithm and combined. For each road segment that overlaps, the flows from each journey are summed together.
The overline function also creates a spatial lines network, which enables it to be used for routing analysis https://cran.r-project.org/web/packages/stplanr/vignettes/stplanr-route-nets.html.
Daily aggregated flows are shown in the figure below
Daily OD with estimated routes
A summary of 4 hours of hourly aggregated data is shown in the figures below.
plot showing 4 selected hours
Next steps
Validation with other datasets
The daily and hourly flows estimated for each link can be matched to other datasets to see how the values compare. A dataset that would be suitable for this is the NDW loop data for the motorway segments that are included in this study area.
Emissions
Matching the vehicle ID to an instananeous emissions dataset/model for each vehicle would allow accurate emissions for each road segment and for each stage of driving to be established.
Improved route estimation
Even if the most probable routes vehicles take between sightings are established there will always be some uncertainty as drivers make wrong turns, take unconventional routes. A visual analysis of the linestrings returned for some of the routes shows there is significant ambiguity for some of the longer routes. This data analysis of 2019 data was based on 221 cameras. 2021 camera data contains 800+ cameras, reducing the distance between vehicle sightings and potentially removing some uncertainty over the route a vehicle takes between cameras.
Modelling movements
One way of getting a better understanding of vehicle movements through a network is to use a microsimulation model. Having origin destination and route data makes this process a lot easier and quicker to setup.