Skip to main content
The Solvice Maps Distance Matrix service is specifically made for products that use route optimization to power scheduling operations. The /cube endpoint provides access to Solvice’s high-performance travel time prediction system. This endpoint is designed to support route optimization at scale, handling millions of requests in parallel with exceptional performance characteristics.

Traffic Profile Processing

TomTom provides us with 1000 distinct traffic profiles. Each traffic profile represents a curve that measures travel time variations throughout the day in 288 time blocks (one block per 5 minutes). In our graph representation, each way (road segment) is assigned a specific traffic profile pattern for different days of the week:
8|3|3|3|5|12|12
M T W T F S  S
This notation indicates that way segments use profile #8 on Mondays, profile #3 on Tuesday through Thursday, profile #5 on Fridays, and profile #12 on weekends.

Optimal Time Slices

Before fitting polynomials, we first identify the optimal time segments to model separately using the Pruned Exact Linear Time (PELT) changepoint detection algorithm. PELT is particularly well-suited for this task because:
  1. It efficiently identifies significant changes in the pattern of travel times
  2. It runs in linear time (O(n)) making it suitable for processing large datasets
  3. It automatically determines the optimal number of changepoints
The PELT algorithm identifies critical transition points in the traffic profiles, such as:
  • Morning rush hour start/end times
  • Evening congestion periods
  • Transitions between weekend and weekday patterns
Based on this analysis, we use 6 time slices per day type. A typical weekday uses:
  • (19:30-6:30) - Night / free flow
  • (6:30-9:30) - Morning rush hour
  • (9:30-12:00) - Late morning
  • (12:00-14:30) - Midday
  • (14:30-16:30) - Afternoon
  • (16:30-19:30) - Evening rush hour
Weekend days use a similar 6-slice structure with adjusted boundaries. This approach allows us to:
  1. Model each segment with a tailored polynomial fit
  2. Reduce the complexity of each polynomial (fewer coefficients needed per slice)
  3. Improve overall accuracy by focusing on homogeneous time periods
The changepoint detection results are visualized in our traffic profiles as red horizontal lines, showing where PELT has identified significant transitions in traffic patterns.

Travel Time Curve Processing

The raw TomTom data shows how travel times fluctuate throughout the day, with characteristic patterns like:
  • Morning rush hour peaks
  • Midday plateaus
  • Evening rush hour peaks
  • Overnight free flow
Rather than storing 288 individual time values per profile per road segment (which would be inefficient), we apply polynomial fitting techniques to represent these curves mathematically.

Implementation with Time Slices

Polynomial Fitting Approach

We transform the raw time series data into polynomial coefficients using least squares regression. For a given route:
  1. The original travel time data might look like: (25, 28, 26, 30, 28, 25) measured at 6 time slices throughout the day
  2. We transform this into a polynomial equation: Y = c_0 t^5 + c_1 t^4 + c_2 t^3 + c_3 t^2 + c_4 t + c_5
  3. This polynomial can then be evaluated for any time value t (where t is the time of day in hours, 0–24)

Benefits of the Coefficient Method

This approach provides several key advantages:
  • Storage efficiency: Instead of storing travel times for each time slice per source-destination pair, we store just 6 polynomial coefficients
  • Continuous representation: We can calculate travel time for any arbitrary time of day, not just at the sampled time slices
  • Smoothed interpolation: The polynomial curves filter out noise while preserving important patterns
  • Computational efficiency: Evaluating a polynomial is extremely fast

The /cube Endpoint

The /cube endpoint provides access to a 3D matrix (cube) of travel coefficients for route planning. This is our solution for efficiently handling time-dependent routing at massive scale.

Available Endpoints

POST /cube                    Create a cube request
GET  /cube/{id}               Get cube status
GET  /cube/{id}/progress      Check processing progress (for polling)
GET  /cube/{id}/response      Fetch the cube response
GET  /cube/{id}/response/url  Get a signed URL for the response

Usage Pattern

When you need to calculate travel time for a specific departure time:
  1. Request a cube using POST /cube with a date (YYYY-MM-DD). The system selects 6 time slices based on the day of week (midweek or weekend).
  2. Poll GET /cube/{id}/progress until processing is complete
  3. Retrieve the data via GET /cube/{id}/response
  4. With the default responseType='coefficients', use the polynomial to calculate travel times: Y = c_0 t^5 + c_1 t^4 + c_2 t^3 + c_3 t^2 + c_4 t + c_5 where t is the time of day in hours (0–24).
Alternatively, set responseType='matrix' to receive the raw travel time matrix for each of the 6 time slices.

Request Format

The cube request follows the same format as the table endpoint, with an additional responseType parameter ('coefficients' or 'matrix').

Response Format

With responseType='coefficients' (default), the response contains a 3D array where each element is a length-6 array of polynomial coefficients for calculating travel time between source-destination pairs at any time of day. With responseType='matrix', the response contains the raw duration matrices for each of the 6 time slices.

Integration with Solvice Maps Platform

The /cube endpoint is part of our broader high-performance routing solution that includes:
  • Multiple vehicle profiles (CAR, BIKE, TRUCK, ELECTRIC_CAR, ELECTRIC_BIKE)
  • Traffic profile integration from TomTom
  • Directional routing capability
  • Synchronized distance matrix computation
All of these components leverage our advanced routing technology based on contraction hierarchies, which can be 10,000× faster than traditional Dijkstra’s algorithm on continental-scale road networks.