TL;DR: Transit planners need to connect a service budget to the hours, trips, and choices it can support across the week. While working on the Living Region coding project, I needed to connect an existing fixed-route budget to evening and weekend on-demand service. From July through November, the calculator grew through a mobility planner, phased bus costs, on-demand windows, selectable service modes, window-level ride targets, and a shared annual target for comparing buses with rideshare.
The Living Region transit calculator grew through several distinct planning questions. Its history shows how a model can move from a budget baseline to time-specific scenarios, then make demand and service type adjustable. The repository keeps the calculations, interface, generated data, and tests together.
A phased bus budget created the starting model
The wider Living Region project first added an integrated mobility planner on July 24. On September 2, the Owen Sound transit cost model added a transit-specific budget view, with a sourced city baseline and service phases.
The first phase described weekday evening bus service across four routes: roughly hourly service until 10 p.m., five days a week. A vehicle-hour is one vehicle operating for one hour; CAD means Canadian dollars. One passenger boarding counts one person getting onto a bus. The model also carried equivalent Mobility Transit availability, with its vehicle-hours left for local operating data. For its Phase 1 scenario, the calculator assigned 2,080 annual conventional vehicle-hours, gross operating costs of CAD $300,000–$375,000, and a target of eight passenger boardings per vehicle-hour. Its fare assumption was CAD $1.50–$2 per boarding. After modeled fare revenue, the net annual estimate came to CAD $266,720–$350,040. These figures are planning inputs and calculated outcomes; comparing hours with a local timetable and costs with operator quotes makes the scenario more useful for a real budget.
The phase structure gave the calculator a starting question: what schedule is being proposed, how many vehicle-hours does it require, and how do fares affect the budget? The original build and deployment checks both passed in the deployment workflow.
On-demand scenarios added service windows
On October 20, the first on-demand scenario change added evening and weekend windows to the cost model. Demand-responsive, or on-demand, service sends a vehicle after a rider requests a trip. A service window is a defined time period, such as Sunday daytime or weekday evenings. This let the model describe lower-demand periods alongside the scheduled daytime bus network.
The session verification reported two useful pilot views. Sunday daytime plus weekday evenings came to 3,224 vehicle-hours and a modeled net cost of CAD $205,000–$230,000. Selecting all four windows—Sunday daytime, weekday evenings, Saturday daytime, and Saturday evenings—came to 3,999 hours and CAD $236,000–$265,000 net. Each figure tied a budget range to the hours of service selected.
The same change also included a separate full-network comparison. That view started with a 13,500-hour annual network and let planners compare paid core buses with demand-responsive service. With two core vehicles, the model assigned 4,160 hours to buses and 9,340 hours to on-demand service. At zero core buses, this full-network scenario estimated CAD $880,000–$1,264,000 net per year under its planning allowances. This network replacement view describes a different scope from a small evening-and-weekend pilot, so the calculator kept the two questions distinct.
The first on-demand release recorded 11 passing transit tests, 207 carrying-capacity tests, type and contract validation, a production build, browser checks, and a successful deployment. GitHub’s build and deploy jobs provide the public delivery record.
Service choices turned scenarios into plans
The next October 20 commits added independently selectable scheduled buses and on-demand rideshare, then preserved a zero-core-bus choice in shared links. The calculator could label a plan Bus only, Rideshare only, or Combined service. The network view could also represent a fully demand-responsive option with zero core buses and 13,500 on-demand hours.
For the selected-window pilot, the recorded mode comparison showed CAD $266,720–$350,040 net for bus-only service, CAD $205,000–$230,000 for rideshare-only windows, and CAD $471,720–$580,040 for the combined default. The combined figure added the two selected components from that model stage. The full-network comparison used its own 13,500-hour scope and cost allowances.
That distinction matters when reading the model’s growth. A selected-window pilot describes evening or weekend additions. A full-network comparison reallocates the annual network. Naming those scopes lets a planner choose the question before reading the estimate. The mode-selection update recorded 16 focused transit tests, type and contract checks, mobile browser checks, a production build, and deployment. GitHub Actions records successful builds for the service-mix choices and the zero-core URL state.
Ride targets made each window adjustable
Later that day, the demand-led update let a planner set an annual ride target for each on-demand window. The model then scaled vehicle-hours, operating costs, and fare revenue from those targets. Its starting rideshare assumption was four completed rides per vehicle-hour.
This step changed the input from a fixed service-hours estimate to a demand estimate a reader could adjust. A weekend-only plan could be modeled by selecting the weekend windows and setting their ride counts; weekday evening service could be adjusted independently. The session reported 12 on-demand model tests, passing type and contract checks, a successful production build and deployment, and a mobile layout check. The final GitHub build and deploy checks passed.
The Transportation Research Board’s Transit Cooperative Research Program (TCRP) Report 98 is a useful technical reference: it describes simulating trip patterns, scheduling trips among vehicles, and modeling service results. Living Region answers an earlier budget question with a simpler proportional model. It turns a selected ride target into vehicle-hours, costs, and fares using stated local assumptions.
A shared target tied the service mix together
By November 2, the model had separate mode choices and editable window targets. The shared-demand update added one default annual target of 16,640 and a slider that allocates that target between buses and rideshare. The merge commit 4628321 passed its build and deployment checks.
The code splits the target according to the slider position, then scales each service component’s starting hours, cost, and fares by its allocated share:
on-demand allocation = annual target × selected share bus allocation = annual target − on-demand allocation component scale = allocated demand ÷ component baseline demand hours and costs = component baseline values × component scale Here, a component baseline means the starting ride count, hours, costs, and fares assigned to one service type.
At the default Phase 1 target, the recorded endpoint comparison is:
| Scheduled buses | On-demand rideshare | Annual target | Modeled hours/year | Modeled net annual cost (CAD) |
|---|---|---|---|---|
| 100% | 0% | 16,640 | 2,080 | $266,720–$350,040 |
| 50% | 50% | 16,640 | about 3,120 | about $265,618–$323,407 |
| 0% | 100% | 16,640 | 4,160 | $264,516–$296,774 |
The midpoint applies half of each service component’s starting values. The ranges overlap, so the scenario supports discussion of coverage, operating needs, and budget together. The 16,640 target is a planning scenario that readers can replace with local records.
The two components count demand differently: buses use projected passenger boardings (people getting on), while rideshare uses modeled completed trips. A single trip can carry several people, so matching local records to an agreed unit is the key step before interpreting the combined estimate.
The latest endpoint-label change makes the direction clear: 100% scheduled buses at the left, 100% on-demand rideshare at the right. Its GitHub build and deploy checks passed. The full service-mix calculation is in the transit model source.
A sequence other planners can reuse
The Federal Transit Administration (FTA) publishes service and cost definitions through the National Transit Database (NTD). Its glossary explains demand-response service, passenger trips, and vehicle revenue-hours. Those definitions help a planner align the model’s inputs with an agency’s records.
The project’s progression offers a practical sequence for another transit analysis: establish the existing service and budget baseline; add distinct service windows; separate a pilot from a whole-network scenario; let readers choose modes; then set a shared demand target for direct comparisons. Each stage adds one decision while keeping its assumptions and output visible. Local ridership counts, operator quotes, and an agreed definition of a trip turn the model into a stronger basis for planning.
