Feature Requests

When multiple visits share the same location, it would be valuable to have the route optimizer assign them consecutively within a vehicle's itinerary — so the vehicle doesn't have to travel away and return to the same spot unnecessarily.

This is a request to make validation errors returned by the FSR model structured and machine-readable. Currently, error messages are text descriptions that vary in format depending on the error type, making them hard to parse programmatically. Customers would like identifiers (e.g. the IDs of the objects causing the error) and other relevant details to be available as separate fields in the error object, instead of being embedded in human-readable strings.

Currently, travelTimeAdjustment can only be configured at the global dataset level, which applies the same adjustment to all vehicles and shifts in a planning problem. In some scenarios, it would be useful to define a travel time adjustment at the vehicle shift level. This would allow modeling known, static differences between vehicle shifts, for example: A vehicle shift that uses a slower vehicle A shift with operational constraints that systematically increase travel time Simulating predictable conditions (e.g. consistently slower shifts) without applying a global adjustment This would be intended to model pre-defined differences between vehicle shifts that are known at planning time.

This is a request to extend the existing dependency rules by allowing a maximum delay ( maxDelayTo ) between visits, in addition to the current minimum delay ( minDelayTo ). This would make it possible to define flexible but time-bounded visit patterns, such as “three visits per week with at least one day and at most two days between them,” or “two visits on the same day with no more than four hours in between.”

This is a request to introduce a constraint that minimizes idle waiting time when hard time windows are used. When a vehicle arrives early, it may need to wait until the time window opens, resulting in unproductive idle time. The current model does not attempt to reduce this waiting. Adding a constraint to penalize unnecessary waiting would encourage the solver to create more productive schedules with less idle time whenever feasible.

I've identified two issues in the OpenAPI schema that cause problems when generating client code with openapi-generator-maven-plugin: Issue 1: Missing allOf in Child Schema Definitions Child schemas that inherit from parent schemas are missing the allOf property to properly define inheritance relationships. Issue 2: Incorrect Mixing of allOf and oneOf in Vehicle.requiredArea The requiredArea property in the Vehicle schema incorrectly combines both allOf and oneOf, which causes ambiguous type definitions. Since Polygon and MultiPolygon already extend/implement GeoJsonGeometry, the allOf reference is redundant and creates conflicts. Only oneOf should be used here to indicate that the field accepts either type. Screenshots: in the screenshots you can find a possible solution and the location of the issues. Screenshot 1: Missing allOf in BreakPlan Screenshot 2: Incorrect allOf + oneOf mixing in Vehicle.requiredArea Screenshot 3: Missing allOf in VisitPlan Impact: These issues prevent proper code generation and cause the OpenAPI generator to create incorrect or incomplete model classes. Thanks for your support

This is a request to add a way to express a preference (not just a hard constraint) for performing a visit within a certain time window. This would allow the optimizer to favor, but not strictly enforce, visits occurring at preferred times, helping balance schedule flexibility with patient or staff preferences.

This is a request to make it possible to fix certain visits so they must occur at a specific time and be assigned to a specific employee (or vehicle). Some operations manually schedule part of their work in advance and want to ensure these fixed visits remain unchanged during optimization. Currently, the workaround is to model such visits as fixed breaks with locations, but this approach causes issues - especially with technician cost calculations, metrics accuracy, and visit groups. The requested feature would allow users to mark a visit as fixed (with its assigned resource and start time).

This is a request to add a soft-constraint version of the current requiredArea rule. Today, required areas are enforced strictly, but some planning scenarios would benefit from treating them as preferences (for example, preferring that visits stay within a nurse’s area but still allowing exceptions when needed).

This is a request to enhance preferredVehicles by allowing weighted preferences or affinities. Instead of treating all preferences equally, users could assign higher or lower preference levels to vehicles or employees, letting the solver choose more accurately based on ranked suitability or historical patterns.