ISR Solve RequestSolve Request

Overview

Different actions can be performed against a model and the solve request object provides a mechanism to communicate the action to the solver.

Applicable models

• ISR isr-z4foi53qznrv

Endpoint

• POST: https://api.icepack.ai/vehicle-router/solve/

Solve Request

The solve request indicates what type of solve should be performed against a specified model.

Schema definition

message SolveRequest {
  optional Model model = 1;
  optional string modelID = 2;
  repeated VisitSequence routes = 3;
  optional SolveType solveType = 4 [default = Optimise];
}

Fields

model

The target model which should be solved (commonly specified). If not specified, the modelID field should be provided with a valid reference to an existing model.

modelId

A GUID which refers to a valid model which has been uploaded via the ivr-data end point. If a modelId references a model which no longer exists on the server, an error is returned indicating that the target model could not be found.

routes

An optional list of routes which specify the collection sequence, typically used in conjunction with the modelId and the solve types Evaluate and ReOptimise. The collection sequence is also available as a field within the model definition where the collection sequence specified in the SolveRequest will override any collection sequence specified in the encapsulating model. This allows one to run multiple evaluate requests without having to redefine a model for each evaluate request. This is a desireable design pattern when implementing user interfaces (UIs) where a drag-and-drop functionality is desired.

solveType

An enumerator which defines the target solver behaviour required for the specified model.

Solve Request Type

Schema definition

enum SolveType {
  Optimise = 0;         // Ignores provided routes. Solves using internal seed mechanisms.
  Evaluate = 1;         // Evaluates the provided route sequence. Single solution response.
  ReOptimise = 2;       // Uses routes as starting solution and continues to optimise.
  NetworkMatchings = 3; // No solve. Returns the matchings only.
}

Fields

Optimise

Issues an Optimise request which aims to find a feasible solution to the provided model (either a provided model, or reference to an existing model).

Evaluate

Issues an Evaluate request which is used in conjunction with a defined set of routes. The feasibility status of the prescribed routes is returned in the solution response.

ReOptimise

Issues a ReOptimise request which is used in conjunction with a defined set of routes. If the routes provided are feasible with respect to the model referenced, this is used as a candidate starting solution in the search algorithm. If the solution is feasible, the solution returned by the engine is guaranteed to be better than or equal in cost to the provided collection sequence. There are several use cases for type of solve request. Small modifications may be made to a model which perhaps change the context of a given solution slightly. By providing a high quality starting solution to the solver, the solve time may be reduced. Another use case is that on much larger models, a heuristic design is employed by the solver. By providing a starting solution, additional search time may be given to the solve around the neighborhood specified.

NetworkMatchings

In the context of an ISR model, each collection is attached to a road segment by identifying the closest perpendicular road segment. It may be that when configuring a model, several adjustments are required to the input geocodes in order to get the correct matchings to road segments for routing. In such instances, a complete solve is not required but rather simply the matchings determined via the road network analysis. These matchings determined for an optimise, evaluate or reoptimise solve request are always returned.