NS3 Solve RequestSolve Request
Overview
The solve request gives an instruction to the API to solve a particular model (nested in the request). The solve request is serialised into the problem schema content and shipped to the API. If you’re looking for examples on how to do this, there are examples in R, Python, C# and Java available in the examples repo.
Applicable models
- NS3
ns3-tbfvuwtge2iq
Endpoint
Solve Request
The solve request contains a model and a solve instruction. In the current schema there is only one operation type (Optimise) but it is anticipated that a future version will support advanced functionality such as evaluate or reoptimise.
Schema definition
message SolveRequest {
enum SolveType {
Optimise = 0;
}
enum GeometryOutput{
None = 0;
Aggregate = 1;
}
optional Model model = 1; // either model or modelID should be specified
optional string modelID = 2;
optional SolveType solveType = 4 [default = Optimise];
optional GeometryOutput geometryOutput = 5 [default = None];
}
Fields
- model
- A model object containing the instance description to be solved. This field is generally populated but if a
modelID
is provided (for a cached model) then this can be omitted. - modelID
- A modelID can be provided if a previously uploaded model is referenced by this solve request. It is unusual to use this functionality at the moment as there are limited
SolveTypes
available for this particular model type. However, in the interests of consistency across solve requests definitions and with the potential of anEvaluate
-style solve request in the future, we have retained this structure. - solveType
- Currently only an
Optimise
solve request type is permitted for a given model. - geometryOutput
- Supports either a
None
orAggregate
GeometryOutput setting. When set toNone
, the solver will simply return the assignments and will not return any road network pathing for lane rates or cost models used in the solution. We suggest that theNone
setting is used when doing basic tests. When thegeometryOutput
field is set toAggregate
, the solver will populate all the geometries for assigned origin-destination pairs (i.e. all used lane rates or cost models). The results are returned in a heirarchical format which typically results in much smaller solution response sizes, but still allows the user to reconstruct the complete set of paths used by all lane rates. For information see the Route object on the Solution Response (which contains references to the sequences of pathing used by each Source-Destination assignment). Depending on the size of the model, it may take a while to populate a complete solution response with theAggregate
setting.
Examples
This example illustrates a typical solve request where the model description is provided as part of the payload (the model is truncated in this example). The solver will return a complete set of routing geometries for the solution found with this request.
model {
... trucated ...
}
solveType: Optimise
geometryOutput: Aggregate
The following example illustrates how to configure a reference to a previously uploaded model where the cached data API can be used to send the model separately from the solve request (if required). The modelID is returned as a result of a successful POST request made to the data endpoint.
modelID: "ac353efd-564a-4190-b32d-757f2c35832c"
solveType: Optimise
geometryOutput: None