Inherited Location

Overview

Some jobs may not have explicit locations but need to inherit them from related jobs. This is useful for scenarios like:

Pickup and delivery where delivery inherits pickup location
Multi-stop visits where subsequent stops inherit the previous location
Tasks that must be performed at the same location as another job

Example Request

This example demonstrates jobs with inherited locations where Job 2 will inherit its location from Job 1.

{
  "resources": [
    {
      "name": "Vehicle 1",
      "shifts": [
        {
          "from": "2024-01-01T08:00:00Z",
          "to": "2024-01-01T18:00:00Z",
          "start": {"latitude": 51.1079, "longitude": 17.0385},
          "end": {"latitude": 51.1079, "longitude": 17.0385}
        }
      ],
      "capacity": [100]
    }
  ],
  "jobs": [
    {
      "name": "job1",
      "location": {"latitude": 51.1279, "longitude": 17.0485},
      "duration": 900,
      "windows": [
        {"from": "2024-01-01T09:00:00Z", "to": "2024-01-01T17:00:00Z"}
      ],
      "load": [10]
    },
    {
      "name": "job2",
      "duration": 600,
      "windows": [
        {"from": "2024-01-01T09:00:00Z", "to": "2024-01-01T17:00:00Z"}
      ],
      "load": [5]
    }
  ],
  "relations": [
    {
      "type": "SAME_TRIP",
      "jobs": ["job1", "job2"]
    }
  ]
}

Resources have no id field — only name, which is also how jobs are referenced elsewhere (e.g. in relations). relations is a top-level array on the request, not a per-job field. capacity lives on the resource itself, not on an individual shift.

Key Points

No Location Specified: job2 has no location field
Relation Constraint: The SAME_TRIP relation ensures both jobs are served by the same resource (and hence the same trip)
Inherited Behavior: When job2 is scheduled after job1, it inherits job1’s location
Travel Time: No travel time is calculated between jobs at the same inherited location
Capacity: The resource’s capacity and each job’s load arrays must have matching dimensions

Response Example

{
  "score": {
    "hardScore": 0,
    "mediumScore": 0,
    "softScore": -1200,
    "feasible": true
  },
  "trips": [
    {
      "resource": "Vehicle 1",
      "date": "2024-01-01T00:00:00Z",
      "departureTime": "2024-01-01T08:00:00Z",
      "visits": [
        {
          "job": "job1",
          "arrival": "2024-01-01T08:10:00Z",
          "serviceTime": 900,
          "travelTime": 600,
          "distance": 2500,
          "location": {"latitude": 51.1279, "longitude": 17.0485},
          "waitTime": 0
        },
        {
          "job": "job2",
          "arrival": "2024-01-01T08:25:00Z",
          "serviceTime": 600,
          "travelTime": 0,
          "distance": 0,
          "location": {"latitude": 51.1279, "longitude": 17.0485},
          "waitTime": 0
        }
      ],
      "waitTime": 0,
      "travelTime": 600,
      "distance": 2500,
      "workTime": 2100,
      "serviceTime": 1500
    }
  ],
  "totalTravelTimeInSeconds": 600,
  "totalTravelDistanceInMeters": 2500,
  "totalServiceTimeInSeconds": 1500,
  "unserved": []
}

Note how the job2 visit shows the same location as the job1 visit and has zero travelTime/distance from the previous visit.

Use Cases

Service Continuity: Multiple services at the same customer location
Grouped Tasks: Tasks that must be performed together at one location
Dynamic Locations: Jobs where the location depends on the execution order

Platform

VRP API

Fill API

Overview

Example Request

Key Points

Response Example

Use Cases

​Overview

​Example Request

​Key Points

​Response Example

​Use Cases

Overview

Example Request

Key Points

Response Example

Use Cases