The gap between having racing data and training a useful model is usually not the data volume — it is the feature engineering. Raw race results need to be transformed into numeric representations that capture meaningful relationships: form trends, going preferences, pace profiles, draw effects. This post covers practical approaches to feature construction using a relational racing dataset.
Rolling Form Features
The most commonly used features in racing ML models are rolling aggregates of past performance. For each horse on a given racecard, you might compute: finishing position over last N runs, average winning margin at the same distance, win rate by going condition, and days since last run. All of these are straightforward window function queries on the results table using horse ID and race date as the primary sort keys.
Pace Features from Sectional Data
Sectional time data unlocks a second layer of features beyond finishing position. Rather than knowing a horse finished third, you know whether it led at the two-furlong mark, faded in the final furlong, or ran on late. Pace features constructed from sectional data — speed differential between early and late fractions, variance in sectional times across a career — tend to be stronger predictors than position-only features for distance-suitability models.
Contextual Features
Beyond the horse itself, the race context matters: class rating, field size, draw position, going condition. The HRDB schema encodes all of these as first-class fields. Draw bias is particularly pronounced in HK racing and varies by distance and course — the easiest way to quantify it is to compute historical win rates by draw position at each course-distance combination from the results archive, then join this as a feature on each racecard entry.
Our historical exports are available in CSV and SQL formats compatible with Pandas, R and standard data warehouse environments. Browse available packages or use the API for incremental daily updates.
No responses yet