P-004 · 2026 · Team project · Industry partner

Lüneburg Public Bus Routing with HVV Timetable Data

School bus routing for KVG Lüneburg: GTFS timetable processing, passenger assignment and an evaluation comparing existing services with optimised routes.

PythonGTFSData engineeringRoute assignmentBenchmarking

One passenger demand, three routing scenarios

Morning school journeys: stops, arrival windows and capacities
Existing servicesGTFS timetable, filtered and checked against official schedules
Optimisation routesSimulated annealing and linear programming (team)
Evolutionary routesGenetic algorithms (team)

Same passenger assignment: departure, transfer and duration checks

Coverage, journey-time compliance and resource use
My work covered the timetable baseline, the assignment logic and the shared evaluation; the optimisation algorithms were a team effort.

The planning problem

Bus routes for school journeys must meet arrival windows, capacity limits and limits on journey duration and transfers. Our team of over 20 students, working with KVG in Leuphana’s Machine Learning Lab, compared the existing public timetable in two regions of Landkreis Lüneburg with dedicated school-bus routes designed by three algorithms: linear programming, a genetic algorithm and simulated annealing.

Building the timetable baseline

The baseline answers a simple question: how well does the existing public timetable already serve these pupils? I built a pipeline that filters the HVV GTFS feed to school-day trips between 04:30 and 08:30. I checked the result against official PDF schedules, found four bus lines missing from the feed and added them, verified by hand, to a consolidated schedule.

Assigning pupils to services

For each pupil, the assignment logic searches transit stops within 1 km of home, finds trips that reach the school in time and allows at most two transfers. Better transfer indexing and spatial search raised the share of matched pupils from 85% to 98.9% in development. I added configurable preferences for fewer transfers, shorter journeys or later departures, and compliance reports that explain every violation or failed match.

Comparing routing approaches

I built the evaluation workflow that puts the baseline and the three algorithms on the same footing. It loads every scenario’s routes, assigns pupils with the same logic, and reports coverage, commute efficiency, equity, bus count and utilisation. Along the way I fixed identifier mismatches between schedules, a time-conversion bug and a misleading detour metric, which I replaced with an efficiency ratio of actual to allowed commute.

Results

Across 1,007 pupils, the existing timetable and the simulated annealing routes served everyone, while linear programming and the genetic algorithm left 94 and 183 pupils unassigned. Commutes stayed well within the limits in every scenario, but linear programming produced much longer journeys in the southern region. No algorithm was best on every measure: dedicated routes beat the baseline on several criteria, at the cost of extra buses.

My role and limits

My part was the baseline and the evaluation, including the methodology and comparison slides for the team presentation; the routing algorithms were built by other team members. Passenger records, precise locations and detailed schedules are not published here. The figures below are aggregate results from the team’s final presentation.

Pupils assigned to a feasible route

02505007501,000Baseline (HVV timetable): 1,007 of 1,007Baseline (HVV timetable)1,007 · 100%Simulated annealing: 1,007 of 1,007Simulated annealing1,007 · 100%Linear programming: 913 of 1,007Linear programming913 · 90.7%Genetic algorithm: 824 of 1,007Genetic algorithm824 · 81.8%
All 1,007 pupils in the study regions (423 north, 584 south). The existing timetable and the simulated annealing routes served every pupil; linear programming left 94 and the genetic algorithm 183 unassigned.

Commute time used, as a share of the allowed time

NorthSouth
020406080Baseline, North: 23%23%Baseline, South: 24%24%BaselineLP, North: 26%26%LP, South: 73%73%LPSA, North: 33%33%SA, South: 23%23%SAGA, North: 34%34%GA, South: 30%30%GAShare of allowed commute (%)
Efficiency ratio: actual commute divided by the allowed commute time. Lower means shorter journeys; all scenarios stay well within the limit. Linear programming produced much longer southern commutes.

← Back to all projects

Timur Salakhetdinov ·