DNA //evolutions

JOpt.TourOptimizer Feature Atlas

A customer-inspired toolkit for solving real-world routing, scheduling, and dispatch problems at scale.

This document is designed as a high-impact overview you can share to communicate the breadth of JOpt.TourOptimizer capabilities. It organizes features by the types of real operational problems customers face: feasibility under complex constraints, speed and scalability, explainability and acceptance, incremental re-optimization, and extensibility.

References are included as plain links to documentation and the examples repository so this file remains portable across environments.

Basic_Advandced_Expert Examples

At-a-glance: what JOpt is built for

JOpt.TourOptimizer targets planning problems where “shortest path” is only the beginning—real deployments must handle:

  • heterogeneous fleets and skill matrices,
  • time windows, service times, and multi-day operations,
  • pickup-and-delivery, reloading, and load-dependent feasibility,
  • customer-specific policies that must be explainable and stable,
  • incremental changes while the plan is already in motion,
  • and performance constraints ranging from “interactive UI” to “nightly batch”.


1) Core modeling primitives

Nodes: the “work” to be scheduled

  • Geo nodes (latitude/longitude) and time-window aware nodes
  • Event nodes (special-purpose events in the sequence)
  • Optional nodes (the optimizer decides whether to visit them)
  • Pillar / captured nodes (architectural constructs for hard sequence behaviors)

Docs:

Resources: the “actors” performing work

  • Working hours, multi-day / multi-shift planning
  • Per-resource capabilities and constraints
  • Route start / termination concepts (open/closed route modeling)

Docs:


2) Time modeling and schedule realism

Time windows, arrival logic, and timeline control

  • First/last node constructs (control where work must begin/end)
  • Wait-on-early-arrival behavior for realistic scheduling (including first node variants)
  • Include visit duration and joint visit duration (fine-grained service-time modeling)
  • Overnight stay modeling (multi-day continuity)

Docs:

FlexTime: flexible start time (positive and negative)

  • Positive FlexTime: shift start can be delayed to avoid idle time
  • Negative FlexTime: shift start can be moved earlier (often driving-only) to hit early openings

Docs:


3) Constraints and feasibility: hard rules by architecture

A core design philosophy:
Hard constraints are fulfilled by architecture, not by “very high cost”.
Costs are for optimization within feasible space; feasibility is modeled structurally.

Hard constraint patterns

  • Pillar / captured nodes (sequence structure that must hold)
  • Relations (same route, different route, same visitor, time-window relations)
  • Territory / zone constraints (zone codes, zone number constraints, controlled crossings)
  • Resource qualification constraints (types/skills, expertise levels)

Docs:


4) Cost models and optimization objectives

JOpt supports sophisticated objective construction, including:

  • weighted cost components (distance, time, lateness, overtime, etc.)
  • CO₂ emission optimization as a first-class objective
  • custom cost convergence (stop when your KPI stabilizes)

Docs:


5) Skills, qualifications, and resource matching

Type/skill constraints (with and without expertise)

  • Mandatory vs preferred assignments (binding resources)
  • Banned vs unpreferred assignments (excluding resources)
  • Skill types with expertise levels
  • High-performance BitSet-based matching for very large skill matrices

Docs:


6) Pickup & Delivery (PND) and stateful routing

PND is one of the most operationally important feature groups. It enables:

  • pickup-and-delivery pairing and precedence logic
  • capacity and load factors (including flexible loads)
  • timed loads and time-dependent requirements
  • reporting and audit extraction for PND flows
  • manufacturing/logistics patterns (request/supply, bakery chain patterns, mixed load/unload)
  • optional reload/unload nodes integrated into feasibility and objective shaping

Docs:


7) Clustering construction and large-scale problem decomposition

Clustering is a pragmatic answer to a real customer problem:
“How do we make large instances solvable fast while keeping routes operationally coherent?”

Capabilities include:

  • city-to-city clustering
  • inner-city clustering
  • preserving clusters for optimization (keep cohesion while improving order)

Docs:


8) AutoFilter: a flagship feature for scale and quality

AutoFilter is designed for scale and quality under real constraints:

  • it reduces ineffective move evaluations,
  • focuses the solver on impactful neighborhood changes,
  • and accelerates convergence in large, constrained problems.

Docs:


9) Performance Mode and compute controls

Performance is not one feature; it is an operational contract.
JOpt includes:

  • performance mode presets and behaviors for large instances
  • CPU core controls and parallelism settings
  • algorithm selection pipelines via optimization schemes

Docs:


10) Optimization schemes: choose algorithms, order, and defaults

Optimization schemes are the “execution architecture” layer:

  • select construction algorithm explicitly,
  • select heuristic algorithms and their order,
  • override per-phase parameters,
  • enable/disable AutoFilter per phase,
  • provide custom default properties with safe local overrides.

Docs:


11) Extensibility: Open Assessor (node-level and route-level)

Open Assessor is how customer-specific rules become first-class—without forking the solver.

You can inject:

  • custom costs and preferences,
  • custom violations and explainability payloads,
  • domain-specific scoring and acceptance shaping,
  • and special finalization steps (e.g., “run an extra post-step when converged”).

Docs:


12) Realistic connections: distance/time strategies

External node connections (explicit distance/time)

  • provide connections externally (e.g., from a routing engine)
  • optional “location id” patterns for shared coordinates
  • avoids repeated computation and supports deterministic travel time use

Docs:

BackupConnector (fallback distance/time)

When external travel data is incomplete, a backup connector defines:

  • fallback distances/times,
  • policy for missing links,
  • deterministic behavior under partial data.

Docs:

Connection Store (dynamic, time-dependent travel)

For rush-hour, weekend patterns, or any time-dependent travel model:

  • store time-dependent connections,
  • apply them consistently across the run,
  • preserve realism and acceptance.

13) Continuity and incremental re-optimization

Modern planning is rarely “one-shot”. JOpt supports:

  • saving an optimization result to JSON (file or string),
  • loading it back and continuing,
  • rebuilding a custom warm-start solution from JSON snapshots,
  • reassigning nodes/resources as new work arrives.

This enables:

  • “continue yesterday’s plan”
  • “insert late jobs”
  • “add/remove resources”
  • “re-optimize under disruption”

Docs:


14) Progress streaming, analytics, and reporting

A solver is only production-ready if it is observable.

Capabilities include:

  • optimization progress events and structured updates,
  • frequency control and external time-based polling,
  • full progress readout and parsing utilities,
  • request-result mechanisms for incremental progress consumption,
  • stable extraction for reporting (including PND report extraction patterns)

15) Debugging, comparison, and end-user acceptance

Comparison Tool (make improvements explainable)

The comparison tool is useful for:

  • debugging (“why did the route change?”),
  • “before vs after” acceptance reporting,
  • planner trust and adoption (“here is what improved and what stayed stable”).

Docs:


16) Robustness and operational safety

Uncaught exception handling

In real deployments, exceptions often happen in:

  • background solver threads,
  • custom injected logic,
  • or reactive subscriptions.

JOpt supports deterministic error propagation and graceful termination patterns—crucial for reliability.

Reactive background reading:


17) Geographic and territory modeling

Open Location Code (Plus Codes)

  • convert lat/lon ↔ plus codes
  • run optimization with plus code inputs

Zone codes and zone crossing constraints

  • define territories via zone codes (e.g., postal code logic)
  • apply zone-number constraints
  • enforce controlled crossings (bridges/tunnels) via zone crossing features

Docs:


18) Practical export and integration utilities

  • Export to KML for GIS visualization and stakeholder communication
  • Build info extraction for support/debug (“what version produced this?”)
  • License setup and safe initialization patterns

Docs:


19) “Everything is explainable”: the acceptance layer

Across features, there is a consistent theme:

  • Architectural constructs enforce feasibility.
  • Properties tune behavior.
  • Open Assessor makes customer rules expressible and reportable.
  • Comparison tools and progress streams make outcomes explainable.

This combination is what makes real deployments work:

  • not just getting a solution,
  • but getting a solution the organization can trust.

Suggested “impress in 5 minutes” demo flow

If you want to present the platform in a tight narrative, use this sequence:

  1. Start with a realistic first optimization (basic tutorial)
    https://www.dna-evolutions.com/docs/getting-started/tutorials/first-optimization
  2. Show a major flagship feature
    AutoFilter: https://www.dna-evolutions.com/docs/learn-and-explore/special/special_features#autofilter
  3. Show a real-world stateful feature
    PND: https://www.dna-evolutions.com/docs/learn-and-explore/feature-guides/pickup_and_delivery
  4. Show customer-specific extensibility
    Open Assessor: https://www.dna-evolutions.com/docs/learn-and-explore/special/special_features#open-assessor
  5. Show operational robustness
    Uncaught exception handling + progress streaming + comparison tool
  6. Close with continuity
    Save/load JSON + custom warm-start (“no planning reset required”)

Closing statement

JOpt.TourOptimizer is not a “single algorithm” product. It is a feature-complete optimization platform shaped by customer scenarios across logistics, field service, manufacturing, and dispatch operations.

If you can define your constraints and objectives precisely, JOpt provides multiple architectural layers to implement them:

  • modeling primitives,
  • hard constraints and structural constructs,
  • cost modeling and weighted objectives,
  • performance and algorithm pipelines,
  • custom assessors,
  • continuity and robust integration.

That is why customers can move from “toy routing” to real deployment without rewriting the core system.