Introduction

About

Trip sender is a tool to generate trips for random agents using the Gothenburg travel survey and the SCB demographic dataset.

What is a trip?

Travel in this survey means all transfers that are made to carry out a case at the goal. Even things that are not normally called trips, such as a walk to a lunch restaurant or a bike ride to the kiosk to buy a newspaper, counts here as travel. Exercise rounds or walking to walk the dog, for example, is not included. Professional traffic, as to example taxi drivers or police do in the service, are also not covered by the survey. If a person carries out two cases in a row, for example leaving children at preschool before traveling on to work, it counts as two trips. The journey home is counted as another journey.

The mode of travel

In cases where several modes of transport have been used for one and the same journey, one of the modes of transport has become the main mode of transport and this is the mode of transport that is then shown in the report. To determine which is the main mode of transport a ranking between modes of transport has been made. In this way, the mode of transport that is used the longest usually is the main mode of transport.

This report presents the main modes of transport On foot, Bicycle, Public transport, Car and Other. Public transport includes railway (train, commuter train, tram and local train), boat line and bus. Other modes of transport includes transport service, taxi, moped / motorcycle, flight and more.

IPF for creating a synthetic population

Iterative proportional fitting is used to create a synthetic population of a neighbourhood using neighbourhood specific demographic data from SCB. We perform the IPF in three dimensions. Age Group, Gender and Household type. Since a low number of dimensions are used, the accuracy of the fitting is quite good. Demographic profiles are independent of population size, this allows apply the neighbourhood characteristics of one to another and get the right population count. In the next steps, we will also generate tools to allow the user to make their own unique blend of demographics to test their designs in.

Home origins

Home origins are based on Lantmateriet data. Buildings have a land use code that can be used to filter out all homes. The centroid of these geometries are used to assign home origins.

Building heights are determined using the median z-coordinate from the Lantmateriet LiDar data. This allows us to calculate an estimate GFA of the building. The GFA is then used to allocate the population to each home.

Destinations

Destinations can be obtained using two methods. OSM and Google Earth. A concern with both these methods is the completeness of amenity data. Another caveat with the destination data is matching the trip purpose with a destination. Right now, a destination class is assigned at random. (Discussion here)

Visiting relatives/friends (other homes) is another problem. We know roughly the range that they would travel. But calculating unique travel distances might be challenging

Returning home is another challenge. The data needs to be investigated to identify the purpose code that identifies trips back to origin # Right now, the (n-1)th trip is forced home

OD Matrix assignment

There are many methods that can be used to assign the destinations. In the Toy Model we use a simple beeline closest distance per Origin – Destination pair. The nodes are first vectorized using the SciPy library for faster calculation of nearest neighbors.

We use cKD trees (Maneewongvatana and Mount 1999) to perform a binary search for the closest node rather than visit every destination for every origin. Alternate methods (cost, amenity rating, random of closest n destinations) could include a destination choice with custom weights to be used in a cost function.

Routing methods

The routing algorithm used is Dijkstra shortest path with edge weights as length. This is again not the fastest or the smartest algorithms (relative to google maps) but it will do the job. There are more algorithms that could be explored (djikstra variants for driving, bellman-ford etc.)

First, PostGIS based PG_Routing was used to perform the routing. This was easy to use, NetworkX was tried next and performance improved. This was further improved with iGraph. The documentation for the iGraph Python binding is sparse and the graph convention is not as user friendly as the previous libraries but saving in computation time is significant.

The network uses the Lantmateriet street and path network. Again, OSM is easier and has more informal paths, but for completeness and scalability, we pick Lantmateriet.