VRP Changelog

​

Resource Ranking

Express preferences for specific resources to handle jobs with a flexible 1-100 ranking system.

{
  "jobs": [{
    "name": "Premium-Service",
    "rankings": [
      {"name": "Senior-Tech-1", "ranking": 10},
      {"name": "Junior-Tech-1", "ranking": 70}
    ]
  }],
  "options": {
    "weights": {"rankingWeight": 10}
  }
}

Benefits:

• Implement customer preferences without hard constraints
• Balance skill levels across assignments
• Optimize for service quality alongside efficiency

​

Location Inheritance

Jobs without explicit locations now inherit them from related jobs, perfect for multi-stop visits.

{
  "jobs": [
    {
      "id": "pickup",
      "location": {"lat": 51.1279, "lon": 17.0485}
    },
    {
      "id": "delivery",
      // No location specified - inherits from pickup
      "relations": [{
        "type": "same_vehicle",
        "jobs": ["pickup", "delivery"]
      }]
    }
  ]
}

Benefits:

• Simplified modeling for pickup-delivery scenarios
• Zero travel time between co-located tasks
• Automatic location management for dependent jobs

​

Unassigned Reasons

Get detailed explanations when jobs cannot be assigned to any resource.

{
  "options": {
    "explanation": {
      "enabled": true,
      "onlyUnassigned": true
    }
  }
}

Response includes:

{
  "unservedReasons": {
    "job1": ["DATE_TIME_WINDOW_CONFLICT", "SHIFT_TIME_CONFLICT"]
  }
}

Benefits:

• Quickly identify scheduling bottlenecks
• Improve capacity planning decisions
• Provide clear explanations to customers

​

Job Complexity and Complexity Fairness

Define job difficulty independent of duration and distribute complex work fairly.

{
  "jobs": [{
    "name": "Technical-Installation",
    "duration": 3600,
    "complexity": 80  // High complexity despite moderate duration
  }],
  "options": {
    "complexityFairness": true,
    "weights": {"complexityWeight": 15}
  }
}

Benefits:

• Balance mental/physical workload, not just time
• Prevent burnout by distributing challenging tasks
• Account for task difficulty in resource planning

​

Full TOMTOM Integration

Enhanced traffic-aware routing with complete TOMTOM API integration.

{
  "options": {
    "routingEngine": "TOMTOM",
    "tomtomConfig": {
      "trafficMode": "live",
      "departureTimeOptimization": true,
      "historicalTrafficData": true
    }
  }
}

Benefits:

• Real-time traffic updates during optimization
• Historical traffic patterns for better planning
• Departure time optimization to avoid congestion
• Up to 15% reduction in actual travel times

​

Resource Hourly Wage Cost

Optimize routes considering different hourly rates for resources.

{
  "resources": [{
    "name": "Senior-Tech",
    "hourlyWage": 75.00
  }, {
    "name": "Junior-Tech", 
    "hourlyWage": 45.00
  }],
  "options": {
    "weights": {"wageWeight": 20}
  }
}

Benefits:

• Balance service quality with labor costs
• Automatic cost-optimized resource selection
• Better profitability analysis per route

​

Unavailability Break

Model resource unavailability periods within shifts for meetings, training, or personal time.

{
  "resources": [{
    "name": "Tech-1",
    "shifts": [{
      "from": "2025-01-01T08:00:00",
      "to": "2025-01-01T17:00:00"
    }],
    "breaks": [{
      "type": "unavailability",
      "start": "2025-01-01T12:00:00",
      "end": "2025-01-01T13:30:00",
      "location": {"latitude": 51.1079, "longitude": 17.0385}
    }]
  }]
}

Benefits:

• Accurate modeling of real-world schedules
• Automatic routing around unavailable periods
• Support for location-specific breaks (return to office)
• Better work-life balance for field resources

​

Job relation: First job

This means that all jobs with tag group1 should be scheduled before all tobs with tag group2. Then on the first topic: you could model this as a time window early in the day or as a job.plannedArrival also early in the day. But these constraints will not natively force it. That is why we would suggest this model:

    {
        "type": "SEQUENCE",
        "jobs": ["that_first_job_id"],
    }

The solver will check that that_first_job_id is a single element and will assign it first.

​

Job relation: Relation Group

The proposed change is:

{
    "type": "GROUP_SEQUENCE",
    "tags": ["group1", "group2"],
    "min": 0
}

​

TSP improvements

We have implemented several optimizations for handling large-scale TSP instances:

• Enhanced initial solution construction using nearest neighbor heuristic
• Implemented advanced local search with 2-opt and 3-opt moves
• Added memory optimization for large distance matrices
• Introduced parallel processing for route segments
• Improved solution quality with real-world constraints consideration

These improvements have resulted in:

• Faster processing times for instances with 100+ jobs
• Better solution quality with average improvement of route efficiency
• Reduced memory footprint for large-scale problems

​

Improving for large instances

We can now handle requests that have a huge number of jobs (10000+) through:

• Implemented chunking strategy and dynamic partitioning for better memory management
• Added batch processing and parallel execution capabilities
• Optimized caching mechanisms and data structures for large-scale operations
• Achieved ~60% faster processing time while maintaining solution quality
• Improved solution quality while maintaining performance
• Better memory utilization for extended operations

These improvements ensure stable performance even with significantly larger datasets while maintaining solution quality.

​

Integrating TomTom Traffic

Set it through:

{
    "options": {
        "routingEngine": "TOMTOM"
    }
}

​

Solver Enhancements

• Switched from static distance matrix to time-dependent distance cube
• Routes now account for traffic patterns at specific times of day
• Solver optimizes departure times to avoid peak traffic hours

​

Key Benefits

• (up to) 15% reduction in actual travel times
• Improved ETA accuracy
• More reliable delivery windows
• Better resource utilization through traffic-aware scheduling

​

Multi day jobs

Multi-day jobs are supported through date windows and shifts that span multiple days. Define shifts with start and end dates across different days, and set job time windows accordingly.

For example, now you can define a 20-hour job that will be executed over 3 days of 8 hour shifts.

{
    "duration": 72000
}

​

New Synchronous Endpoints for Real-time Applications

​

Added /sync/ Endpoints

• New synchronous API endpoints for immediate responses:

• /sync/solve - Direct route optimization
• /sync/evaluate - Instant solution evaluation
• /sync/suggest - Real-time suggestions

​

Key Features

• Response times under 2 seconds
• Optimized for UI integration
• Perfect for interactive applications
• No webhook configuration needed
• Automatic timeout handling

​

Use Cases

• Interactive route planning tools
• Real-time route modifications
• Live what-if scenarios
• Instant cost calculations
• Dynamic UI updates

​

Technical Notes

• Best suited for small to medium problem sizes
• Automatic fallback to async for larger requests
• Enhanced error handling for timeouts
• Built-in request size validation
• Consistent with async endpoint response format

​

Launching VRP API v2

The v2 of our VRP API has been in the works for almost 2 years. It is a complete rewrite of the architecture going away from a Kubernetes cluster to a very simple and fully serverless approach on GCP using Cloud Run, PubSub and Cloud Storage. Additionally, we have implemented several performance improvements such as:

• capable of handling higher volume of jobs
• improved handling of very large list of time windows per job
• optimized constraint checking

As well as following API improvements:

• Enhanced request/response format
• Better validation and error messages
• Improved rate limiting
• More detailed solution statistics
• Extended configuration options