How do I set up demand forecasting software for service planning with historical ridership and GTFS data?

Setting up demand forecasting software for service planning using historical ridership and GTFS usually means building a pipeline that:

1. combines ridership, schedule, and geographic context
2. creates features the model can learn from
3. trains a forecasting model
4. generates service recommendations like headways, vehicle needs, or route-level demand

Here’s a practical setup path.

---

1) Define the planning question first

Be specific about what you want to forecast.

Common outputs:

• Boardings per route/trip/stop/time period
• Passenger loads by segment
• Peak demand by corridor
• Revenue hours or vehicle requirements
• Ridership under proposed service changes

Typical planning grain:

• Route-day
• Trip-level
• Stop-level by time bucket
• Segment-level between stops

If you want service planning, a good starting target is:

• forecast ridership by route / trip / stop in 15-, 30-, or 60-minute intervals

---

2) Gather the needed data

A. Historical ridership

You’ll want one or more of:

• APC data
• Farebox/tap data
• Automated passenger counts
• Manual counts
• Survey estimates
• Boarding/alighting logs

Minimum useful fields:

• date
• route_id / trip_id / stop_id
• boardings
• alightings
• time of day
• direction
• load, if available

B. GTFS static

Use:

• routes.txt
• trips.txt
• stop_times.txt
• stops.txt
• calendar.txt / calendar_dates.txt
• shapes.txt if available

This gives:

• service frequency
• trip patterns
• stop sequence
• schedule times
• route geometry
• service calendars

C. Optional but very valuable

• Weather
• Holidays
• School calendars
• Land use / population / employment near stops
• Traffic or congestion indicators
• Special events
• Service changes / detours

---

3) Clean and standardize the data

Historical ridership

• Remove duplicates
• Handle missing counts
• Normalize route/stop/trip IDs to match GTFS
• Aggregate to the same time grain you’ll model

GTFS

• Validate feed using a GTFS validator
• Check for:
  • missing stop sequences
  • invalid times
  • duplicate trip IDs
  • calendar inconsistencies

Time alignment

Make sure ridership timestamps align with GTFS scheduled service dates/times. For example:

• count on 2025-03-04 08:15 should be matched to the relevant trip(s) operating then

---

4) Join ridership to GTFS

This is the key step.

You typically map each ridership record to:

• route
• direction
• stop
• trip
• service date
• time bucket
• stop sequence position

Useful GTFS-derived features:

• scheduled departure time
• service frequency in the time window
• trip duration
• stop spacing
• number of stops on route
• headway
• peak/off-peak indicator
• day type: weekday/weekend/holiday

If you only have stop-level counts and not trip IDs, you can still match by:

• route
• stop
• time window
• direction
• service day

---

5) Engineer forecasting features

These are usually what make the model useful.

Time features

• hour of day
• day of week
• month
• school day / holiday
• season
• peak period flag

Service features from GTFS

• scheduled headway
• trips per hour
• vehicle capacity
• route length
• travel time
• stop order
• direction
• transfer opportunities nearby

Demand history features

• lagged ridership: previous day/week/same period last year
• rolling averages
• trend indicators
• moving max/min

External features

• weather: temperature, rain, snow
• events: concerts, sports, parades
• land use / demographics near stops

---

6) Choose a modeling approach

Simple baseline models

Start here first:

• seasonal averages
• moving average
• linear regression
• Poisson regression
• negative binomial regression

These are good for:

• interpretability
• quick setup
• low data volume

Stronger ML models

Common choices:

• Random Forest
• XGBoost / LightGBM / CatBoost
• Prophet for aggregate time series
• SARIMA / ARIMA for simpler time series
• LSTM/Temporal Fusion Transformer if you have lots of data

For transit service planning, gradient-boosted trees are often a very good balance of accuracy and explainability.

If you need scenario forecasting

If you want “what happens if we add service?”:

• use a demand model with service frequency/headway as an input
• run scenario simulations with changed GTFS schedules

---

7) Set up the forecasting pipeline

A typical workflow:

Step 1: Load and validate GTFS

• Parse GTFS with Python tools like:
  • gtfs-kit
  • partridge
  • transitfeed
  • gtfs-realtime-bindings if using realtime

Step 2: Build a service table

Create a table with one row per:

• route
• trip
• stop
• service date
• time bucket

Include GTFS attributes and derived metrics.

Step 3: Merge ridership counts

Join counts to the service table.

Step 4: Train/test split by time

Do not random-split transit time series. Use:

• earlier dates for training
• later dates for testing

Step 5: Train model

Predict:

• boardings
• alightings
• load
• passenger miles
• etc.

Step 6: Evaluate

Use:

• MAE
• RMSE
• MAPE or sMAPE
• Poisson deviance if count data
• calibration for uncertainty intervals

Step 7: Deploy

Run forecasts on a schedule:

• daily
• weekly
• monthly
• planning cycle

---

8) Turn forecasts into service planning outputs

Forecasts become actionable when translated into operations.

Examples:

• If projected load exceeds seated capacity, increase frequency.
• If demand falls below threshold, consider lower frequency or shorter vehicles.
• If AM peak demand grows, shift service to peak span.
• If a corridor is underperforming, adjust timing, stop spacing, or route alignment.

Useful planning metrics:

• load factor
• passengers per revenue hour
• passengers per trip
• boardings per stop
• capacity utilization
• crowding probability

---

9) Recommended software stack

Data processing

• Python
• pandas / polars
• geopandas
• SQL / Postgres

GTFS handling

• partridge
• gtfs-kit
• r5py or R5 for accessibility/network analysis
• OpenTripPlanner for routing/accessibility context

Modeling

• scikit-learn
• xgboost / lightgbm
• statsmodels
• prophet

Visualization / dashboards

• Power BI / Tableau / Superset
• Plotly Dash / Streamlit

Geospatial support

• PostGIS
• QGIS for mapping

---

10) Common pitfalls

• Joining counts to GTFS too coarsely
• Ignoring calendar exceptions and holidays
• Training on random splits instead of time-based splits
• Not accounting for service changes over time
• Using schedule data without actual service data when reliability matters
• Forecasting at too granular a level before having enough data

---

11) A good first implementation plan

If you want a practical MVP:

1. Pick one corridor or route
2. Use 1–2 years of historical ridership
3. Parse GTFS and extract route/trip/stop features
4. Build a route-day or stop-hour dataset
5. Train a baseline model
6. Compare against a seasonal average
7. Add weather and holiday features
8. Expand to scenario planning using modified GTFS feeds

---

12) Example architecture

Inputs

• Historical ridership CSV/DB
• GTFS feed
• Weather and calendar data

Processing

• GTFS parser
• ridership-GTFS matching
• feature engineering

Model

• XGBoost regression or negative binomial model

Outputs

• forecast table by route/trip/stop/time
• dashboard for planners
• scenarios for service changes

---

If you want, I can also give you:

1. a sample database schema for this setup,
2. a Python workflow to join ridership to GTFS, or
3. a modeling template for route-level demand forecasting.