Skip to main content

What is a Session?

A Session is the fundamental data container in tif1, representing a single Formula 1 track session. Each session corresponds to one on-track activity during a Grand Prix weekend. Examples are Practice 1, Qualifying, Sprint, or the Race. The Session object is the primary interface for access to all F1 data associated with that particular session. It provides a unified, high-performance API for data retrieval.
  • Driver information - Complete roster of participating drivers with team affiliations, driver numbers, names, and metadata
  • Lap data - Comprehensive lap-by-lap information for all drivers including lap times, sectors, tire compounds, track status, and more
  • Telemetry data - High-frequency sensor data capturing speed, throttle, brake, RPM, gear, DRS, and 3D position coordinates
  • Weather conditions - Time-series weather data including air temperature, track temperature, humidity, wind, and rainfall
  • Race control messages - Official FIA communications including flags, penalties, safety car periods, and track status changes
  • Session results - Final classification, grid positions, and driver standings
  • Circuit information - Track layout data including corner positions, angles, and circuit rotation
The Session object uses lazy loading and intelligent caching for maximum performance. Data is fetched from the CDN only on explicit access. Subsequent accesses are served instantly from cache. This architecture enables efficient work with large datasets and keeps the API simple and intuitive.

Session Data Hierarchy

The Session data hierarchy supports efficient navigation and access to the required information.

Data Organization

The Session object organizes data in a logical hierarchy:
  1. Session Level - Top-level metadata, configuration, and session-wide data (weather, race control messages)
  2. Driver Level - Individual driver information, complete lap history for each driver
  3. Lap Level - Single lap data including lap time, sectors, tire compound, track status
  4. Telemetry Level - High-frequency sensor data for a specific lap (typically 100-300 Hz sampling rate)

Creating a Session

The primary way to create a Session object is through the get_session() function. This function accepts flexible parameters that identify the exact session for analysis.

Basic Session Creation

Performance Optimization with Polars

For maximum performance, tif1 supports Polars as an alternative DataFrame backend. Polars provides 2-3x faster data processing compared to pandas, especially for large datasets.
Polars must be installed separately: pip install polars>=1.40.1. If Polars is not available, tif1 automatically falls back to pandas with a warning.

Cache Control

By default, tif1 caches all fetched data to disk for instant subsequent access. Control the caching behavior for each session:
Disabling cache is useful when:
  • Data pipeline changes are under test
  • Cached data is possibly stale or corrupted
  • A fresh fetch from the CDN is required
  • Live or recent sessions may have updated data

Global Configuration

Set default values for lib and enable_cache globally with the config system:

Session Properties

Session properties provide read-only access to various data types. All properties use lazy loading. Data is fetched only on first access to the property.

drivers

Returns a list of driver numbers as strings. This property provides FastF1 API compatibility.
Returns: list[str] - List of driver numbers as strings

driver_list

Alias for drivers property. Returns the same list of driver numbers.
Returns: list[str] - List of driver numbers as strings

drivers_df

Returns comprehensive driver information as a DataFrame. This is the most detailed driver data available, including names, teams, colors, and headshot URLs.
Returns: pandas.DataFrame - DataFrame with 7 columns (Driver, Team, DriverNumber, FirstName, LastName, TeamColor, HeadshotUrl)

laps

Returns all laps for all drivers in the session. This is one of the most important properties, containing comprehensive lap-by-lap data. Key Features:
  • Automatically includes weather data merged with each lap
  • Contains sector times, lap times, tire compounds, track status
  • Includes position data, pit stop information, and more
  • Returns pandas or Polars DataFrame depending on session configuration
Returns: DataFrame (pandas or Polars) - All laps with weather data merged
The laps property triggers a network fetch on first access if data is not cached. For sessions with many laps, such as race sessions, this may take a few seconds.

weather

Returns time-series weather data recorded throughout the session. Weather data is sampled at regular intervals (typically every 1-2 minutes).
Returns: DataFrame (pandas or Polars) - Weather data time series
Weather data is automatically merged into the laps DataFrame, so each lap has associated weather conditions. Direct access to session.weather is necessary only for independent analysis of weather trends.

weather_data

Alias for the weather property. Provides FastF1 API compatibility.
Returns: DataFrame (pandas or Polars) - Weather data time series

race_control_messages

Returns official FIA race control messages issued during the session. These messages include flags, penalties, investigations, safety car periods, and other official communications.
Returns: DataFrame (pandas or Polars) - Race control messages

results

Returns session results with final classification and driver information. This property provides a FastF1-compatible SessionResults object.
Returns: SessionResults (pandas DataFrame subclass) - Session results

car_data

Returns complete telemetry data for all drivers across all laps. This is a very large dataset that contains high-frequency sensor data.
Returns: DataFrame (pandas or Polars) - Complete telemetry for all drivers
car_data can be very large (millions of rows for a full race). Access to this property fetches telemetry for ALL laps of ALL drivers, which may take significant time and memory. Consider driver-specific or lap-specific telemetry access methods instead.

pos_data

Alias for car_data. Returns the same complete telemetry dataset.
Returns: DataFrame (pandas or Polars) - Complete telemetry for all drivers

session_info

Returns basic session metadata as a dictionary.
Returns: dict[str, Any] - Session metadata

name

Returns the human-readable session name (URL-decoded).
Returns: str - Session name

date

Returns the session date as a pandas Timestamp.
Returns: pandas.Timestamp or pd.NaT - Session date

event

Returns the Event object for this session’s Grand Prix. The Event object contains schedule information for all sessions in the weekend.
Returns: Event - Event object for the Grand Prix weekend

Session Methods

Session methods provide powerful functionality for data analysis, filtering, and retrieval.

load()

Explicitly load session data with fine-grained control over what gets fetched. This method is useful to pre-fetch data or to control exactly what data is loaded. Signature:
Parameters:
  • laps (bool): If True, fetch laps data. Default: True
  • telemetry (bool): If True, fetch telemetry for all laps. Automatically sets laps=True. Default: True
  • weather (bool): If True, fetch weather data. Default: True
  • messages (bool): If True, fetch race control messages. Default: True
Returns: Session - Returns self for method chaining Examples:
When telemetry=True is requested but laps=False, the method automatically sets laps=True because telemetry requires lap data to function properly.
Loading telemetry for all laps (telemetry=True) can be time-consuming and memory-intensive for race sessions. Such sessions have 20 drivers and 50+ laps each. Consider loading telemetry selectively using driver-specific or lap-specific methods instead.

get_driver()

Get a Driver object for a specific driver. The Driver object provides convenient access to that driver’s laps and telemetry. Signature:
Parameters:
  • driver_code (str): 3-letter driver code (for example, ‘VER’, ‘HAM’, ‘LEC’)
Returns: Driver - Driver object with laps and telemetry access Examples:
The get_driver() method uses intelligent prefetching. On the first call, it fetches the driver list and the requested driver’s lap data in parallel. This significantly improves performance.

get_fastest_laps()

Get the fastest lap(s) from the session. This method can return either the fastest lap per driver or the single overall fastest lap. Signature:
Parameters:
  • by_driver (bool): If True, return fastest lap per driver. If False, return single overall fastest lap. Default: True
  • drivers (list[str] | None): Optional list of driver codes to filter. If None, includes all drivers. Default: None
Returns: DataFrame - Fastest lap(s) with all lap data columns Examples:
This method only considers valid laps (not deleted laps). Deleted laps are automatically filtered out.

get_fastest_lap_tel()

Get telemetry for the overall fastest lap in the session. This is a convenience method that combines finding the fastest lap and fetching its telemetry. Signature:
Returns: DataFrame - Telemetry data for the fastest lap Examples:
This method uses ultra-cold start optimization. On a brand-new session, before any other data access, it uses a highly optimized fetch path. This path bypasses normal caching and validation for maximum speed.

get_fastest_laps_tels()

Fetch telemetry for multiple drivers’ fastest laps in parallel. This is significantly faster than fetching telemetry sequentially. Signature:
Parameters:
  • by_driver (bool): If True, fetch telemetry for each driver’s fastest lap. If False, fetch only the overall fastest lap. Default: True
  • drivers (list[str] | None): Optional list of driver codes to filter. If None, includes all drivers. Default: None
Returns: dict[str, DataFrame] - Dictionary mapping driver codes to their fastest lap telemetry Examples:
This method uses asynchronous parallel fetching internally, which makes it much faster than calling get_driver(driver).laps.fastest().telemetry for each driver sequentially.

laps_async()

Asynchronously load all laps for maximum performance. This method is useful for integration of tif1 into an async application. It also gives the absolute fastest lap loading. Signature:
Returns: DataFrame - All laps (same as session.laps property) Examples:
When the work is not in an async context, use the session.laps property instead. The performance difference is minimal for most use cases.

get_circuit_info()

Get circuit layout information including corner positions, angles, and track rotation. Signature:
Returns: CircuitInfo - Dataclass with circuit information CircuitInfo Attributes:
  • corners (DataFrame): Corner data with columns X, Y, Number, Letter, Angle, Distance
  • marshal_lights (DataFrame): Marshal light positions (always empty - not in source data)
  • marshal_sectors (DataFrame): Marshal sector boundaries (always empty - not in source data)
  • rotation (float): Circuit rotation in degrees
Examples:
Circuit information is cached after the first call, so subsequent calls are instant.

fetch_all_laps_telemetry()

Fetch telemetry for all laps of all drivers. This is equivalent to accessing session.car_data but provides explicit control. Signature:
Returns: DataFrame - Complete telemetry for all drivers and laps Examples:
This method fetches telemetry for ALL laps, which can be very slow and memory-intensive. Use sparingly and consider driver-specific or lap-specific methods instead.

Session Types and Formats

tif1 supports all official Formula 1 session types across different weekend formats.

Standard Race Weekend

A typical F1 race weekend consists of:
  1. Practice 1 (FP1) - Friday morning, 60 minutes
  2. Practice 2 (FP2) - Friday afternoon, 60 minutes
  3. Practice 3 (FP3) - Saturday morning, 60 minutes
  4. Qualifying (Q) - Saturday afternoon, ~60 minutes (Q1, Q2, Q3)
  5. Race (R) - Sunday, ~2 hours

Sprint Weekend

Sprint weekends have a modified format:
  1. Practice 1 (FP1) - Friday, 60 minutes
  2. Sprint Qualifying (SQ) - Friday, ~60 minutes (SQ1, SQ2, SQ3)
  3. Sprint (S) - Saturday, ~30 minutes (~100km race)
  4. Qualifying (Q) - Saturday, ~60 minutes (Q1, Q2, Q3)
  5. Race (R) - Sunday, ~2 hours

Session Name Variations

tif1 accepts multiple variations of session names for convenience:

Data Loading Architecture

Knowledge of the tif1 data loading process helps with performance optimization and troubleshooting.

Lazy Loading

Sessions use lazy loading for optimal performance. When a Session object is created, no data is fetched immediately. Data is retrieved only on explicit access.
Benefits of Lazy Loading:
  • Fast initialization - Session objects are created instantly
  • Efficient memory usage - Only requested data is loaded
  • Flexible workflows - Load only the data that the analysis requires
  • Reduced network traffic - Avoid fetching unused data

Caching Strategy

tif1 implements a multi-tier caching system for maximum performance:

1. Memory Cache (L1)

  • In-memory storage of fetched data within the Session object
  • Fastest access (nanoseconds)
  • Cleared when Session object is destroyed
  • Automatic and transparent

2. Persistent Cache (L2)

  • SQLite-based disk cache in the tif1 OS-dependent cache directory (configurable via TIF1_CACHE_DIR)
  • Survives across Python sessions
  • Shared between all tif1 sessions
  • Configurable via enable_cache parameter

3. CDN (L3)

  • Three-source CDN chain (jsDelivr, Hugging Face buckets, StaticDelivr) serving TracingInsights data repositories
  • Fetched only on cache miss
  • Automatic retry with exponential backoff
  • Multiple CDN sources for redundancy

Session Loading Flow

Ultra-Cold Start Optimization

For specific use cases, tif1 provides ultra-cold start mode. This aggressive optimization bypasses normal caching and validation for maximum speed.
When to Use Ultra-Cold Start:
  • Real-time applications requiring minimum latency
  • One-off queries where caching is not beneficial
  • Benchmarking and performance testing
  • Live timing applications
Trade-offs:
  • Skips data validation (assumes CDN data is correct)
  • Bypasses retry logic (one try only)
  • No persistent caching (unless background fill is enabled)

Parallel Fetching

tif1 automatically uses parallel fetching for operations that require multiple network requests:
Parallel Fetching Benefits:
  • 10-20x faster for multi-driver operations
  • Efficient use of network bandwidth
  • Automatic connection pooling
  • Configurable concurrency limits

Prefetching Strategies

tif1 implements intelligent prefetching to reduce latency:

Session Table Prefetching

Driver Lap Prefetching

Background Telemetry Prefetching

Data Enrichment and Transformations

tif1 automatically enriches and transforms raw F1 data to make it more useful for analysis.

Automatic Weather Merging

Weather data is automatically merged into every lap, eliminating the need for manual joins:

Computed Columns

tif1 adds computed columns for convenience:

LapTimeSeconds

Numeric representation of lap time for easier calculations:

DriverAhead and DistanceToDriverAhead

Telemetry includes relative position data:

Column Renaming and Standardization

tif1 renames columns from the raw CDN format to more intuitive names:

Type Conversions

tif1 automatically converts data types for optimal performance and usability:

Data Validation

tif1 validates data integrity and handles edge cases:
  • Missing data - Replaced with appropriate null values (NaN, NaT, None)
  • Invalid lap times - Filtered out or marked as deleted
  • Malformed telemetry - Logged and skipped
  • Inconsistent driver codes - Normalized to 3-letter format
  • Out-of-range values - Clamped or marked as invalid

Performance Optimization Tips

Maximize tif1 performance with these best practices:

1. Use Polars for Large Datasets

Polars provides 2-3x faster data processing:

2. Load Only the Required Data

Use the load() method to control data fetching:

3. Use Driver-Specific Access

Avoid loading all laps when only one driver is needed:

4. Use Parallel Fetching

Use methods that fetch in parallel:

5. Enable Caching

Always use caching unless there is a specific reason not to:

6. Reuse Session Objects

Create session objects once and reuse them:

7. Filter Early

Filter DataFrames as early as possible:

8. Use Ultra-Cold Start for One-Off Queries

For single-use queries, enable ultra-cold start:

9. Avoid Repeated Telemetry Fetches

Cache telemetry results when analyzing multiple laps:

10. Monitor Cache Size

Periodically clear cache if disk space is a concern:

Common Patterns and Examples

Pattern: Compare Fastest Laps

Pattern: Analyze Tire Degradation

Pattern: Weather Impact Analysis

Pattern: Sector Analysis

Pattern: Overtaking Analysis

Pattern: Telemetry Heatmap

Troubleshooting

Issue: Slow Data Loading

Symptoms: First access to session.laps takes a long time Solutions:
  1. Check the internet connection
  2. Verify CDN is accessible: tif1.cdn.test_connection()
  3. Enable ultra-cold start for faster initial fetch
  4. Use Polars backend for faster parsing

Issue: Cache Not Working

Symptoms: Data is fetched from CDN every time Solutions:
  1. Verify caching is enabled: session.enable_cache
  2. Check that the platform-specific cache directory exists
  3. Verify disk space is available
  4. Clear corrupted cache: tif1.cache.clear()

Issue: Missing Data

Symptoms: Empty DataFrames or missing columns Solutions:
  1. Verify session exists: Check F1 calendar
  2. Check for typos in event/session names
  3. Some sessions may not have all data types (for example, no telemetry for old seasons)
  4. Use session.drivers to verify drivers are present

Issue: Memory Usage

Symptoms: High memory consumption Solutions:
  1. Use Polars backend (more memory efficient)
  2. Load only required data with session.load()
  3. Access driver-specific data instead of all laps
  4. Avoid loading session.car_data (very large)
  5. Process data in chunks

Issue: Telemetry Not Available

Symptoms: Empty telemetry DataFrames Solutions:
  1. Verify telemetry exists for that session/driver
  2. Check for deleted laps (no telemetry for deleted laps)
  3. Some drivers may not have telemetry for all laps
  4. Check logs for telemetry fetch failures

Core API

Complete Session class API reference.

Getting Started

Quick start guide and installation.

Data Flow

The tif1 data pipeline.

Caching Strategy

Details of the caching architecture.

Backends

Pandas vs Polars comparison.

Race Analysis Tutorial

Step-by-step race analysis guide.
Last modified on September 8, 2026