JOpt.TourOptimizer feature list
This page lists the features of JOpt.TourOptimizer in one table per topic. Each row gives the level at which the examples introduce the feature (basic, advanced, expert or REST), what the feature enables and when to use it. It is written for developers and planners who check whether a requirement is covered; the elements that the rows refer to, such as nodes and resources, are explained in Basic elements. The feature atlas describes the same features in prose.
The REST API of JOpt.TourOptimizer uses the same snapshot schema as the Java library. The features that are part of the published API schema can be used from any client: Java, TypeScript, Python, C#, or any language with an OpenAPI code generator. The API reference shows the schema.
Getting started, fundamentals and interoperability
| Feature | Level | What it enables | When to use it |
|---|---|---|---|
| First optimization pipeline | Basic | Minimal working optimization (nodes, resources, run, result) | Always the first validation step in any project |
| Core modeling primitives (nodes, resources, time windows, durations) | Basic | Standard routing and scheduling building blocks | Any operational scenario |
| Read out results (routes, timing, KPIs) | Basic | Extract the order, arrivals and departures, totals | Integration, reporting, UI, audits |
| Result output formatting (headers, structured export) | Basic | Consistent downstream consumption | When several systems consume results |
| Export to KML | Basic | GIS visualization for stakeholders | "Show it on a map" demos and acceptance |
| ExtraInfo payloads (node and resource metadata) | Advanced | Attach domain-specific data without breaking the model | When a UI or ERP needs extra data per stop or vehicle |
| REST API (the features of the published API schema) | REST | The features of the published API schema from any client, with the snapshot schema of the Java library | Language-agnostic integrations, platform services |
Time modeling and schedule realism
| Feature | Level | What it enables | When to use it |
|---|---|---|---|
| Include visit duration | Advanced | The arrival must fall within the time window; the visit may end after it | When the time window limits the arrival, not the whole visit |
| Joint visit duration | Advanced | Less total service time for nodes at the same location that are visited one after the other | When tasks at one place share setup or overhead |
| Wait on early arrival (first node) | Advanced | Waiting for the time window at the first node of a route; work starts at once on early arrival at later nodes | When a route must not start before the shift, but later stops may start early |
| First and last node | Advanced | Soft steering, by importance, of the node that starts or ends a route | Start the day with a key customer, end at a handover location |
| Overnight stay | Advanced | Multi-day continuity across routes | Field service, multi-day delivery, overnight planning |
| FlexTime and StartReductionTime | Expert | Flexible start-time shifts | When shifting the start improves feasibility or acceptance |
| Event nodes | Basic | Tasks without a location that take time within a time window but need no travel | Customer calls, administrative tasks |
Route structure and feasibility by architecture
Hard constraints are fulfilled by architecture, not by a very high cost. Costs optimize within the feasible space; feasibility is modeled structurally.
| Feature | Level | What it enables | When to use it |
|---|---|---|---|
| Open vs closed route | Advanced | End at the last node or return home | Choose based on operational reality |
| Return to start | Advanced | Returns to the start location between visits, with an optional dwell time | Reloading at the depot between visits |
| Pillar / captured nodes | Basic | Time windows (SLAs) as hard constraints; other nodes flow around the pillar | When an appointment must not be late |
| Relations (same or different route or visitor, relative time windows) | Advanced | Cross-node coupling constraints | When tasks must be together or separate, or spaced in time |
| Optional nodes (general) | Expert | Nodes may be visited or skipped | When stopovers are optional but useful |
| AutoFilter | Advanced | Takes nodes that are very likely infeasible out of the run, so that the other nodes get a feasible plan | Over-constrained instances in which a few nodes cannot be served |
Locations, territories and zones
| Feature | Level | What it enables | When to use it |
|---|---|---|---|
| Open Location Code (Plus Codes) | Advanced | Location identifiers without raw latitude and longitude | When interfaces use plus codes |
| Territories via zone codes | Advanced | Territory modeling via postal or zone codes, hard or soft, per working hours | Sales and service territories, compliance regions |
| Zone number constraints | Advanced | Territories as numbered zones instead of postal codes | When the zones are simple numbered areas |
| Zone crossing penalization (bridge and tunnel crossings) | Advanced | An extra cost when a route crosses from one zone into another | Toll bridges, tunnels, river crossings |
| UK post codes / zone examples | Advanced | Concrete territory modeling patterns | When zones are postal-code driven |
Travel times, routing data and network integration
| Feature | Level | What it enables | When to use it |
|---|---|---|---|
| External node connections | Basic | Inject travel times and distances externally | When you have authoritative routing data |
| BackupConnector (fallback distance and time) | Basic | Calculated distance and driving time where no connection is given | When travel data is partial |
| ConnectionStore (time-dependent) | Expert | Rush hour, weekend and time-of-day dependent travel | When realism depends on the time of day |
| Custom backup connector strategies | Expert | Domain-specific fallback computation | When the default fallback is not enough |
Resource capabilities, skills and assignment logic
| Feature | Level | What it enables | When to use it |
|---|---|---|---|
| Binding vs excluding resource conditions | Advanced | Mandatory and preferred, banned and unpreferred assignment | When assignment rules must be explicit |
| Resource types with expertise | Advanced | Skill and level matching | Technician and skill-based dispatch |
| BitSet accelerated matching (BitType) | Advanced | Skill eligibility checks on bitsets, for many skills and frequent checks | Large skill matrices where runtime matters |
| Resource constraint alias ID | Advanced | One logical ID for a team or pool of resources, used in constraints | When a rule names a team, not one resource |
| Resource connection efficiency | Advanced | Travel time depends on the resource | Vehicle differences (speed, access) |
| Resource visit duration efficiency | Advanced | Service time depends on the resource | Experience and tooling differences |
Pickup and delivery, capacity and stateful logistics
| Feature | Level | What it enables | When to use it |
|---|---|---|---|
| Pickup and delivery (PND) framework | Advanced | Precedence, capacity, flexible and timed loads, reporting | Logistics, manufacturing, field supply chain |
| Optional nodes as reload or unload bases | Expert | The optimizer inserts stopovers when they lower the cost or are needed | Waste management, replenishment, intermediate hubs |
unloadAll behavior | Expert | Full reset of the current load at stopovers | Depots, transfer stations, emptying workflows |
| PND report extraction | Advanced | Audit-friendly flow reporting | When traceability matters |
Scalability, acceleration and algorithm control
| Feature | Level | What it enables | When to use it |
|---|---|---|---|
| Clustering construction | Advanced | A starting solution built from clusters (city to city, inner city), optionally kept during the optimization | Large instances; operationally coherent routes |
| Performance mode | Advanced | A shorter runtime through a smaller population and fewer genetic operators, at a possible cost in quality | Large instances with few constraints |
| Optimization scheme: algorithm selection pipeline | Expert | Explicit construction and ordered heuristic phases | When you need reproducible pipelines and tuning clarity |
| Optimization scheme: custom default properties | Expert | Central defaults with safe per-run overrides | System-wide defaults across many jobs and services |
| Read out default properties | Expert | The full property catalog with its defaults | Configuration audits, release comparisons, debugging |
| Custom cost convergence | Expert | Stop when your KPI stabilizes | Predictable "good enough" runtime |
| CO2 emission optimization | Advanced | Optimize emissions as an objective component | Sustainability-focused planning |
Continuity, persistence and operational lifecycle
| Feature | Level | What it enables | When to use it |
|---|---|---|---|
| Save optimization to JSON (file or string) | Basic | Persist a full snapshot | Reproducibility, audits, handoff |
| Save during run | Basic | Intermediate snapshots | Long runs; recovery points |
| Load optimization from JSON (file or string) | Basic | Resume or replay optimizations | Debugging, continuity, rollback |
| Load into a fresh run | Basic | A new run from a saved model, without its old solution | Rollover planning, what-if scenarios |
| Create custom solution (warm start) | Expert | Inject an existing plan as start | Respect ongoing plans and human decisions |
| Create custom solution from JSON | Expert | Build a warm start from a stored snapshot | "Continue where we left off" workflows |
| Run optimization in a loop | Advanced | Stop a solver stage after a chosen number of loops | Own stop criteria; checking results between loops |
Observability, explainability and end-user acceptance
| Feature | Level | What it enables | When to use it |
|---|---|---|---|
| Optimization progress streaming | Advanced | Events and frequency control | UI progress, monitoring, SLAs |
| Full progress readout and parsing | Advanced | Deep telemetry and diagnostics | Tuning, root-cause analysis |
| Request result (intermediate result) | Advanced | The best result so far while the run continues | Interactive systems, early insights |
| Compare results tool | Expert | Debug deltas and acceptance reporting | "Why did the plan change?" discussions |
| Read out results with structured headers | Basic | Reliable downstream analytics | When results flow into BI or reporting |
Extensibility: customer-specific logic without forking
| Feature | Level | What it enables | When to use it |
|---|---|---|---|
| Open Assessor (route level) | Expert | Custom route-level rules, costs, explainability | Business policies at route scope |
| Open Assessor (node level) | Expert | Custom node-in-route rules, costs, explainability | Priority, ordering, deadline-like policies |
| Custom post-steps and finalization patterns | Expert | Final actions when a cost converger stops the run, such as a final post-step or a snapshot export | When a run needs a defined last step |
Robustness and production safety
| Feature | Level | What it enables | When to use it |
|---|---|---|---|
| Uncaught exception handling | Expert | Deterministic failure propagation (async threads) | Production safety; avoids silent failures |
| RxJava event integration patterns | Expert | Reactive pipelines with error consumers | Streaming UIs, event-based architectures |
| Build info extraction | Expert | Provenance ("what build produced this?") | Support workflows and reproducibility |
| License setup | Basic | The license as a JSON string or from a file | When a run has more elements than JOpt allows without a license: License guide: element limits |
Related pages
- Feature atlas: the same features in prose, by the planning problem they solve, with links to their documentation
- Feature guides: one guide per feature
- Basic examples: the examples of the basic level
- Advanced examples: the examples of the advanced level
- Expert examples: the examples of the expert level
- REST server: JOpt.TourOptimizer as a REST service in a container
Added: 2026-02-27 (JOpt core 7.5.3-j17) | Last updated: 2026-10-23