It is with great excitement that I announce with ArcGIS Pro 2.6, we have added full ribbon and layer support for the Vehicle Routing Problem. This experience should match workflows similar to the other Network Analyst solvers. We also added a few new tricks to help make things easier to access across all the solvers.

The first step is to make a new VRP layer. On the Analysis tab, look for the Network Analysis icon and click on the drop-down. Here you choose one of the Network Analyst solvers and it now includes the Vehicle Routing Problem. At the bottom of this dropdown menu is the network data source that will be used to create the layer. Make sure this points to the correct local network data source or portal location before choosing Vehicle Routing Problem.

Looking in the Contents Pane, you should now see the newly created VRP layer. We have made some changes to the VRP feature classes, tables, and fields within the tables compared to what is historically used in ArcMap and our Services. This ArcGIS Pro help page explains the different fields within the tables and feature classes of a VRP layer. If you are used to the schema from these other platforms this help page describes the differences.

Let’s, now, look at the new VRP ribbon. In the TOC, select any part of the VRP layer and the VRP contextual tab should appear. Select that VRP tab and you should see the ribbon.

Analysis

There are a lot of options on this ribbon so let’s break it down by section. Going from left to right, let’s start with the Analysis section. Here you will find a single button called Run. The run button is what actually starts the solve with the layer data and all the parameter settings. If the layer is pointing to ArcGIS Online as its network dataset, then running the solver will consume credits.

Input Data

The next section of the VRP ribbon is Input Data. This section is devoted to getting data into the sub-layers and -tables for the VRP layer. There are a lot of sub-layers and -tables. So, we have made prominent importing the four main layers: Orders, Depots, Routes and Breaks. At a minimum every VRP layer must define the Orders, Depots, and Routes. These buttons open the Add Locations GP tool, which allows data to be added from a feature class or table. The other sub-layers and -tables are accessed from the two groupings buttons with a dropdown arrow.

The last button in this section is the Create Features button. This opens the Create Features Pane used to manually digitize locations on the map. This can also be accessed from the Edit Ribbon. However, when using the button on the VRP ribbon it filters the feature classes that display in the Create Features Pane to those associated with the current layer. The create features button was added to all the Network Analyst solver ribbons.

The last thing of note for the Input Data section is that Import Routes and Import Breaks both have a dropdown arrow. Clicking on these dropdowns shows the option of either importing or adding. We have added two new GP tools: Add Vehicle Routing Problem Routes and Add Vehicle Routing Problem Breaks. These two tools help create Routes or Breaks from business constraints by walking through the different parameters. Both will also allow for making multiple copies of the same parameters with one run of the tool.

Travel Settings

Next in the VRP ribbon is Travel Settings. Here you set the travel mode to be used by the solver. Only time-based impedance travel modes can be used with the VRP solver. Therefore, they are the only options displayed in the Mode dropdown. If you need to tweak the travel mode settings for your model, the small launcher button at the bottom of the Travel Settings group opens the layer property pages to the Travel Mode page. Also, in this section you set the units used for the time and distance-based fields for the whole problem. The units used for these settings do not need to match the units used by the travel mode.

Default Date

The next section of the ribbon is Default Date. In this group, you indicate what day the problem should use for solving. This is used when only times are given in time window fields. Also, in this group, is a parameter setting new to the ArcGIS Pro Ribbon for all solvers, the Reference Time Zone. This allows you to indicate if the time windows are based on UTC or the time zone at the location. This setting is very important when the locations within a single model span multiple time zones.

Output Geometry

Next in the VRP ribbon is Output Geometry. This allows you to determine how the route shapes will be drawn. The options include along the road network following the actual path the vehicle will take, straight lines just connecting one location to the next, or no lines at all. This affects only the geometry displayed for the routes. It does not change the actual calculations for how that route will be traversed.

Advanced

The settings in the Advanced section allow you to influence the solution of the solver. There is extra help to understand each of these in the dropdown. So, if you decide to change these values from the defaults, please take the extra time to read them to understand how the parameters work.

Time Window Importance determines how much emphasis the solver places on meeting the time windows vs having the least cost (total time, total distance, etc.) solution. Transit Time Importance is only a useful parameter if Order Pairs are in the problem. If so, it then influences allowing an order to be on the vehicle for longer before it is dropped off to save time or distance (mostly used for transporting packages) vs taking the order more directly to its drop off location (mostly used for transporting people). The last parameter is Spatial Clustering. This allows you to decide if you would prefer a solution that clusters orders onto routes in the same geographic area (such as all in the same neighborhood) or if you would prefer the lowest cost solution allowing routes to cross geographic regions.

Directions and Share As

The last two sections of the VRP ribbon, Directions and Share As, are all about getting the route direction information to the drivers. The Directions section will allow you to print turn by turn directions for the routes. While, The Share As section creates route layers for ArcGIS Online and used in Navigator.

Hopefully this has helped orient you to the new VRP Layer and Ribbon. Checkout our help page for more information. Please reach out if you have any questions.

Sometimes modeling a single capacity constraint just isn’t good enough for your needs, but the VRP solver only offers one capacity field.  We will look at how to model multiple capacities.  So you can model both volume and weight, or number of seats and number of wheel chair positions, or what other capacity combinations you have.

Modeling Steps

Modeling multiple capacities is actually pretty simple.  Capacities and quantities are modeled within the DeliveryQuantities and PickupQuantities field in the Orders feature class and the Capacity field in the Route feature class.  In these fields, you simply put the multiple capacities’ values in the same field separated by a space.  For example, you are tracking volume and weight with a delivery at an order location that is 90 cubic feet and 500 pounds.  In the Delivery Quantities field you enter 90 500.  It is critical that you are consistent in the sequencing of these measurements and use consistent units throughout the problem.  Sequencing and units are not tracked for you. If they are switched in sequence or switch units from one field to another the problem will be solved with the input as input.  This will lead to results that you are not expecting.

For the GP tools in both ArcMap and ArcGIS Pro and the Rest Request system this is all that is needed.  When using the ArcMap UI for VRP layers there is an additional step.  You will also need to go into the Layer Properties Analysis Settings and set the parameter Capacity Count to the correct number according to how many capacities you want to model. 

Solver’s Interpretation of differing number of specified capacities

When modeling multiple capacities, it is important to double check the entries to make sure they are accurate.  In correct entries can have unintended consequences that are sometimes hard to identify.  We will look at the effects of having too few or too many values in a field.

Too Few Inputs in a Quantity/Capacity Field

An empty string or null value in a quantity or capacity field is treated as being all zeros.  Null values are often intentional.  However, if it was unintentional and in a quantity field for an order, the order should still be routed.  Since there is now quantity associated with the order, it might overload a route.  if a capacity field on a route is unintentionally left blank, that route would only be able to accommodate orders without a delivery or pickup quantity.

When the field value has fewer dimensions then what is being tracked, the remaining not designated ones will be treated as zeros.  If it is the last number in the sequence is omitted, then this does not matter.  However, if it is in the middle of the sequence of capacities, then all the following ones are pushed forward.  This leaves the last one as zero instead of the intended middle capacity value.  It is recommended to always place a zero in the appropriate location of a capacity that is not needed.  By always including all dimensions it takes out the guess work.

To Many Inputs in a Quantity/Capacity Field

When extra capacity values are included in the ArcMap VRP layer UI it gives a solver error.  This error indicates that the order or route has a string containing too many values and will not solve.  This is because in the ArcMap VRP layer UI the Capacity Count value is set.  This indicates the number of values to be tracked and will not accept extras.

When using the GP tools or Rest Request system a Capacity Count is not set.  Instead the solver will use the maximum number of values for the problem as a Capacity Count.  If an extra value is included in a quantity field for an order, that order will not be routed.  The ViolatedConstraints for that order in the output will indicate Capacities exceeded.  This is because the order has a quantity value for a tracked dimension, but all of the routes will have a zero for that dimension at the end of its sequence. 

If an extra capacity dimension is added to a Route Capacity value, the solver will simply track an extra capacity.  The problem should still solve as intended because all the orders will have zeros in that additional capacity dimension.  The orders can, then, still fit on the vehicles. 

More and more companies need to incorporate appointment times or time windows into their routing solutions.  The 30-minute guarantee isn’t just for pizza delivery anymore.  We will discuss the basics of time windows in the VRP solver and how to prioritize their importance.

The Basics

Time windows are a way to indicate when the route/driver should arrive at that order location.  The VRP Solver supports two time windows per order.  If the beginning time for a time window is left null, then it will correspond with starting at the earliest start time of the earliest route.  Similarly, if the ending time for a time window is left blank, then it will correspond with the latest ending of the last route.

Unless using the Rest Request system, the time window fields are set up to accept either just time or time and date.  If it is just the time then it is assumed to be on the default date.  If using both date and time be sure to use both date and time in all time fields in Orders, Depots, Routes, and Breaks.  The Rest Request system requires that all times are in milliseconds since epoch (which is January 1^st 1970).  It, therefore, will inherently have both date and time.

.

Note: Time windows do not include when the drivers should be done at that location, ready to go to the next location.  It is only when they should arrive at the location.  If you need to model it so that the driver leaves within a certain time, then for your time windows subtract the service time from the TimeWindowEnd value. This allows for if the driver was to show up right at the end of this modified time window they would be completed with the service time and leaving right at the end of the original time window.

Hard vs. Soft Time Windows

Hard time windows mean that the route/driver must show up during the designated time frame of the time windows.  A soft time window, on the other hand, allows the route/driver to show up late but the violation is penalized in the solver so that violation times are minimized.  To indicate that the time window is hard set the corresponding MaxViolationTime to zero.  Leaving this value as null makes it a soft time window.  Giving a positive value for MaxViolationTime makes it a soft time window within a hard time window.  This means the route/driver can be late to that location, incurring the violation penalty, but only up to the MaxViolationTime.  At that point it is a hard time constraint.

Prioritizing Time Window Violations or Total Cost

When setting up a problem with soft time windows you have the option to identify how much priority you want to place on minimizing the time window violation time vs minimizing the total cost of the routes (which includes the total time and total distance for all of the routes).  These two priorities are usually working against each other.  Minimizing or eliminating time window violations usually requires higher costs because.  This is because the shortest tour amongst all of the stops will likely not satisfy the time windows.  To indicate the preference for the VRP problem use the parameter Time Window Violation Importance.  There are three options for this parameter: Low, Medium, and High.

• Low - Prioritizes minimizing the total cost over the time window violations
• Medium - Tries to find a balance between the time window violations and added cost
• High - Minimizes the time window violations at the expense of added cost

Geo-Local or UTC Time

When using the UI in ArcMap for VRP layers or the GP tools in either ArcMap or ArcGIS Pro it is natural to type in the time fields using the local time for that location (Geo-Local).  However, when switching to the rest request method those times need to be converted to milliseconds since epoch.  This UNIX way of representing time has a strong convention of referencing time based on UTC. Therefore, most conversion methods convert those times using UTC instead of Geo-Local.

The VRP Solver allows for some flexibility in specifying time.  It allows the option of having that input as a Geo-Local time as well as UTC. You, therefore, need to specify which format is being used.  This is done with the parameter time_zone_usage_for_time_fields with the two parameter options of GEO_LOCAL or UTC.  Setting this parameter is only available in the GP tools or the rest request and it defaults to Geo-Local.  When using the VRP layers in ArcMap there is no way to switch it to using UTC.

Get Involved

When using soft time windows and a violation is needed, would you prefer to see one order with a larger violation or several orders with smaller violations?  Click here to answer.

How many time windows do you want to model?  Click here to answer.