Skip to content

Commit 7ee004b

Browse files
authored
Merge pull request #277075 from stevemunk/NVIDIA-updates
Updates per NVIDIA feedback.
2 parents 12bdb4e + 6bff522 commit 7ee004b

File tree

2 files changed

+87
-51
lines changed

2 files changed

+87
-51
lines changed

articles/azure-maps/itinerary-optimization-service.md

Lines changed: 87 additions & 51 deletions
Original file line numberDiff line numberDiff line change
@@ -12,7 +12,7 @@ services: azure-maps
1212

1313
# Create multi-itinerary optimization service
1414

15-
This guide describes how to use [Azure Maps] and [NVIDIA cuOpt] to build an itinerary optimization service that automates the process of building itineraries for multiple agents and mixed fleets, and optimizes their route across multiple destinations.
15+
​​​This guide explains how to use [Azure Maps] and [NVIDIA cuOpt] to create an itinerary optimization service. This service automates the process of building itineraries for multiple agents and mixed fleets, utilizing the NVIDIA cuOpt route optimization engine to optimize routes across multiple destinations.​​
1616

1717
This is a two-step process that requires a cost matrix for the travel time and a solver to optimize the problem and generate an outcome. A cost matrix represents the cost of traveling between every two sets of locations in the problem, which includes the travel time cost and other costs of travel.
1818

@@ -54,25 +54,26 @@ This service can support the following features and constraints.
5454

5555
For the full list of supported capabilities, see [cuOpt Supported Features].
5656

57-
## Get started with Nvidia cuOpt on Azure Marketplace
57+
## Get started with NVIDIA cuOpt on Azure Marketplace
5858

59-
Nvidia cuOpt uses GPU accelerated logistics solver and optimizations to calculate complex vehicle routing problems with a wide range of constraints. For more information, see the [List of cuOpt supported features].
59+
NVIDIA cuOpt uses GPU accelerated logistics solver and optimizations to calculate complex vehicle routing problems with a wide range of constraints. For more information, see the [List of cuOpt supported features].
6060

61-
cuOpt is included with Nvidia AI Enterprise. Visit [Azure Marketplace] to get started.
61+
cuOpt is included with NVIDIA AI Enterprise. Visit [Azure Marketplace] to get started.
6262

6363
## Get the travel cost
6464

65-
Itinerary optimization requires a square matrix of some travel metric that is passed to the cuOpt solver. This could include travel time or distance cost. A cost matrix is a square matrix that represents the cost of traveling between each two pairs of locations in the problem.
65+
Itinerary optimization requires a square matrix of some travel metric that is passed to the cuOpt solver. This could include travel time or distance cost. A cost matrix is a square matrix that represents the cost of traveling between every pair of locations in the problem.
6666

6767
The Azure Maps [Route Matrix] API calculates the time and distance cost of routing from origin to every destination. The set of origins and the set of destinations can be thought of as the column and row headers of a table and each cell in the table contains the costs of routing from the origin to the destination for that cell.
6868

69-
For example, a restaurant has two drivers that need to deliver food to four locations. To solve this case, you'll first call the Route Matrix API to get the travel times between all locations. This example assumes that the drivers’ start, and end location is the restaurant. If the start and end locations are different from the depot, they must be included in the cost matrices.
69+
For example, a restaurant has two drivers that need to deliver food to four locations. To solve this case, call the Route Matrix API to get the travel times between all locations. This example assumes that the drivers’ start, and end location is the restaurant. If the start and end locations are different from the depot, they must be included in the cost matrices.
7070

7171
Number of origins = Number of destinations = 1 (restaurant also known as _depot_) + 4 (deliveries)
7272

7373
Matrix size = 5 origins x 5 destinations = 25
7474

75-
Note: Azure Maps Route Matrix can support up to 700 matrix cells which approximate to a square matrix of 26x26. You can use it to plan the itinerary for 26 locations including depots and deliveries.
75+
> [!NOTE]
76+
> Azure Maps Route Matrix can support up to 700 matrix cells which approximate to a square matrix of 26x26. You can use it to plan the itinerary for 26 locations including depots and deliveries.
7677
7778
The Route Matrix POST request:
7879

@@ -147,7 +148,7 @@ Parse the Azure Maps Route Matrix API response to get the travel time between lo
147148
}}}
148149
```
149150

150-
Multiple cost matrices can optionally be provided depending on the types of vehicles. Some vehicles can travel faster while others might incur additional costs when traveling through certain areas. This can be modeled using additional cost matrices one for each vehicle type. The next example has two matrices, “0” represents first vehicle, which could be a car and “1” represents second vehicle, which could be a truck. Note, if your fleet has vehicles with similar profiles you need to specify the cost matrix only once.
151+
Multiple cost matrices can optionally be provided depending on the types of vehicles. Some vehicles can travel faster while others might incur more costs when traveling through certain areas. This can be modeled using more cost matrices one for each vehicle type. The next example has two matrices, “0” represents first vehicle, which could be a car and “1” represents second vehicle, which could be a truck. Note, if your fleet has vehicles with similar profiles you need to specify the cost matrix only once.
151152

152153
```json
153154
"data": {" cost_matrix_data ": {
@@ -171,7 +172,7 @@ Multiple cost matrices can optionally be provided depending on the types of vehi
171172

172173
### Set Fleet Data
173174

174-
Fleet data could describe the fleet description like the number of vehicles, their start and end location, vehicle capacity, etc. that is used by the solver to determine which vehicles are available to carry out the task within the constraints.
175+
Fleet data could describe the fleet description such as the number of vehicles, their start/end location, and vehicle capacity that are used by the solver to determine which vehicles are available to carry out the task within the constraints.
175176

176177
```json
177178
{
@@ -196,8 +197,7 @@ Fleet data could describe the fleet description like the number of vehicles, the
196197
```
197198

198199
- **Vehicle locations**: In the above example, fleet data indicates two vehicles, one array for each vehicle. Both vehicles start at location 0 and end trip at location 1. In the context of a cost matrix description of the environment, these vehicle locations correspond to row (or column) indices in the cost matrix.
199-
- **Capacities**: The capacity array indicates the vehicle capacity; the first vehicle has a capacity of two and second vehicle has a capacity of three. Capacity could represent various things, for example package weight, service skills and their amounts transported by each vehicle. In the next section, you'll create a task json that will require a demand dimension for each task location and the count of demand dimension will correspond to the number of capacity dimensions in the fleet data.
200-
For example, if there are two vehicles in the fleet with a capacity of two and three that indicates the number of people it can accommodate on a single trip and the demand is three for a delivery location, the solver would use the vehicle with a capacity of three to carry out the task.
200+
- **Capacities**: The capacity array indicates the vehicle capacity; the first vehicle has a capacity of two and second vehicle has a capacity of three. Capacity could represent various things, for example package weight, service skills and their amounts transported by each vehicle. In the next section, you'll create a task json that will require a demand dimension for each task location and the count of demand dimension will correspond to the number of capacity dimensions in the fleet data. ​​​For example, if a truck is delivering goods, the capacity would be how much weight in total each vehicle can carry, and the demand would be the weight of each order. Make sure the same unit is used for both (such as pounds or kilograms).​
201201
- **Vehicle time windows**: Time windows specify the operating time of the vehicle to complete the tasks. This could be the agent’s shift start and end time. Raw data can include Universal Time Stamp (UTC) date/time format or string format that must be converted to floating value. (Example: 9:00 am - 6:00 pm converted to minutes in a 24-hour period starting at 12:00 am, would be [540, 1080]). All time/cost units provided to the cuOpt solver should be in the same unit.
202202
- **Vehicle breaks**: Vehicle break windows and duration can also be specified. This could represent the agent’s lunch break, or other breaks as needed. The break window format would be same as the vehicle time window format. All time/cost units provided to the cuOpt solver should be in the same unit.
203203

@@ -216,7 +216,7 @@ Tasks define the objective that must be fulfilled within the constraints. In the
216216

217217
- **Task location**: In the above example, task_locations indicate the delivery location located at positions 1, 2, 3 and 4. These locations correspond to row (or column) indices in the cost matrix.
218218
- **Demand**: The demand array indicates the demand quantity at each location; the first location has a demand of 3, second and third location has 4 and the last location has 3. The count of demand dimensions should correspond to the number of capacity dimensions for each vehicle.
219-
- **Task time window**: Time windows constraints specifies when a task should be completed. Each task is assigned a start and end time window, and the task must be completed within that. Raw data can include Universal Time Stamp (UTC) date/time format or string format that must be converted to floating value. (Example: 9:00 am - 6:00 pm converted to minutes in a 24-hour period starting at 12:00 am, would be [540, 1080]). All time/cost units provided to the cuOpt solver should be in the same unit.
219+
- **Task time window**: Time window constraints specify when a task should be completed. Each task is assigned a start and end time window, and the task must be completed within that. Raw data can include Universal Time Stamp (UTC) date/time format or string format that must be converted to floating value. (Example: 9:00 am - 6:00 pm converted to minutes in a 24-hour period starting at 12:00 am, would be [540, 1080]). All time/cost units provided to the cuOpt solver should be in the same unit.
220220
- **Service times**: This represents the duration required to complete the tasks. The service_times array specifies the time duration for each task location. All time/cost units provided to the cuOpt solver should be in the same unit.
221221

222222
### Set Solver config (optional)
@@ -247,14 +247,14 @@ Sample request data
247247
"vehicle_ids": ["Car-A", "Car-B"],
248248
"vehicle_types": [1, 1],
249249
"capacities": [[75, 75]],
250-
"vehicle_time_windows": [[8, 17], [8, 17]],
250+
"vehicle_time_windows": [[8, 18], [8, 17]],
251251
"vehicle_break_time_windows": [[[12, 14], [12, 14]]],
252252
"vehicle_break_durations": [[0, 0]]
253253
},
254254
"task_data": {
255255
"task_locations": [1, 2, 3, 4],
256256
"demand": [[30, 40, 40, 30]],
257-
"task_time_windows": [[8, 17], [8, 17], [8, 17], [17, 20]],
257+
"task_time_windows": [[8, 17], [8, 17], [8, 17], [17, 15]],
258258
"service_times": [0, 0, 0, 0]
259259
},
260260
"solver_config": {
@@ -268,45 +268,81 @@ Sample request data
268268
Sample response
269269

270270
```json
271-
{
272-
"reqId": "5a96b531-bacf-44db-9170-87585eeffc3e",
273-
"status": "fulfilled",
274-
"percentComplete": 100,
271+
"reqId": "4bdc2610-d821-48dc-b53f-57698015bb2e",
272+
"status": "fulfilled",
273+
"percentComplete": 100,
274+
"response": {
275275
"response": {
276-
"response": {
277-
"solver_infeasible_response": {
278-
"status": 1,
279-
"num_vehicles": 2,
280-
"solution_cost": 19.0,
281-
"vehicle_data": {
282-
"Car-A": {
283-
"task_id": ["Depot", "0", "Break", "2", "Depot"],
284-
"arrival_stamp": [8.0, 11.0, 12.0, 14.0, 16.0]
285-
],
286-
"route": [0, 1, 1, 3, 0],
287-
"type": ["Depot", "Delivery", "Break", "Delivery", "Depot”]
288-
},
289-
"Car-B": {
290-
"task_id": [
291-
"Depot",
292-
"Break",
293-
"1",
294-
"3",
295-
"Depot"
296-
],
297-
"arrival_stamp": [8.0, 12.0, 12.0, 17.0, 18.0],
298-
"route": [0, 2, 2, 4, 0],
299-
"type": ["Depot", "Break", "Delivery", "Delivery", "Depot"]
300-
}
301-
},
302-
"dropped_tasks": {
303-
"task_id": [],
304-
"task_index": []
305-
},
306-
"msg": ""
307-
}
308-
}
276+
"solver_response": {
277+
"status": 0,
278+
"num_vehicles": 2,
279+
"solution_cost": 19.0,
280+
"vehicle_data": {
281+
"Car-A": {
282+
"task_id": [
283+
"Depot",
284+
"Break",
285+
"0",
286+
"2",
287+
"Depot"
288+
],
289+
"arrival_stamp": [
290+
8.0,
291+
13.0,
292+
13.0,
293+
17.0,
294+
18.0
295+
],
296+
"route": [
297+
0,
298+
1,
299+
1,
300+
3,
301+
0
302+
],
303+
"type": [
304+
"Depot",
305+
"Break",
306+
"Delivery",
307+
"Delivery",
308+
"Depot"
309+
]
310+
},
311+
"Car-B": {
312+
"task_id": [
313+
"Depot",
314+
"Break",
315+
"1",
316+
"3",
317+
"Depot"
318+
],
319+
"arrival_stamp": [
320+
8.0,
321+
12.0,
322+
12.0,
323+
14.0,
324+
17.0
325+
],
326+
"route": [
327+
0,
328+
2,
329+
2,
330+
4,
331+
0
332+
],
333+
"type": [
334+
"Depot",
335+
"Break",
336+
"Delivery",
337+
"Delivery",
338+
"Depot"
339+
]
340+
}
341+
},
342+
"msg": ""
343+
}
309344
}
345+
}
310346
}
311347
```
312348

-703 Bytes
Loading

0 commit comments

Comments
 (0)