Most route optimizers treat territories as static labels. Resource A is in Zone 1. Resource B is in Zone 2. Fixed. If territories change on Monday, you rebuild the model.
JOpt.TourOptimizer handles territories dynamically. Zones are assigned to individual WorkingHours (shifts), not to resources. A resource can cover the north side on Monday and the south side on Tuesday. Nodes near borders can belong to multiple zones simultaneously. And when a route crosses a zone boundary, the penalty can differ by direction.
Per-shift zone switching with multi-zone nodes and asymmetric directional crossing penalties. To our best knowledge, this combination is not available in any other route optimization engine.
In field service, logistics, and home care, territories are not permanent. On-call rotations shift weekly. Coverage plans change when a colleague is sick. A driver serves the city center during morning rush and the suburbs in the afternoon. Territorial flexibility is not a nice-to-have. It is operational reality.
JOpt models this by attaching ZoneCode constraints to individual WorkingHours entries, not to the resource. Each shift can carry a different set of allowed zones. A resource with two shifts can cover completely different territories on consecutive days. Changing the territory assignment is a data update in the WorkingHours definition. No model rebuild. No code change.
Nodes near territory borders carry multiple zone qualifications. A customer located between two districts belongs to both zones. The optimizer decides which resource serves it most efficiently. This eliminates arbitrary boundary decisions and produces better plans at territory edges.
Hard or soft. Your choice. Hard ZoneCodes prohibit out-of-zone visits architecturally. Soft ZoneCodes penalize them through cost, allowing exceptions when no better option exists.
“Territories change daily becomes a data update, not a model change. This is the key scaling feature of the ZoneCode system.”
JOpt.TourOptimizer DocumentationWhen a route crosses from one zone to another, an additional cost applies. The optimizer responds by clustering work within zones and crossing boundaries only when the global benefit outweighs the penalty. Crossings drop from many per day to one or two.
The penalty is controlled by a configurable multiplier. A multiplier of 3.0 makes a crossing edge 4x as expensive as the same edge without a crossing. The optimizer discourages unnecessary transitions but allows them when truly beneficial.
For specific zone pairs, you can override the global multiplier with per-direction ZoneConnection objects. Crossing from Manhattan to Jersey City can carry a toll penalty of 5.0. Crossing back can be free (multiplier 0.0). This asymmetric model captures real toll structures, congestion patterns, and infrastructure constraints.
Standard VRP solvers have no concept of zone-to-zone transition costs. You can approximate the effect by inflating specific entries in the distance matrix, but this is static, undirected, and breaks when zones or routes change. JOpt's approach is native, directional, and composable with the rest of the constraint system.
Territory enforcement (which zones are allowed) and crossing penalization (how often to cross) are independent features that compose naturally. Enforce territories with hard ZoneCodes. Then add crossing penalties for transitions between allowed adjacent zones. Feasibility and efficiency in two clean layers.
JOpt provides dynamic, per-shift, multi-zone territory management with asymmetric directional crossing penalties as built-in features. Other engines require static zone assignments, uniform crossing costs, or custom constraint implementations.
| Standard VRP engines | JOpt ZoneCodes + Crossing |
|---|---|
| × Zones fixed per resource | ✓ Zones per shift, change daily |
| × Nodes belong to one zone | ✓ Multi-zone membership |
| × No crossing penalty concept | ✓ Native crossing penalization |
| × Uniform distance inflation | ✓ Asymmetric per-direction costs |
| × Hard or nothing | ✓ Hard or soft per constraint |
Urban last-mile delivery across river bridges. Field service in cities with congestion zones. Logistics networks with toll infrastructure. Healthcare routing across district boundaries. Any operation where crossing a boundary has a real cost that distance matrices alone cannot capture.
Resources without zone constraints can visit all nodes. You can introduce zones incrementally: start with nodes only, then add constraints to specific resources and shifts. Keep floating resources for emergency coverage. No all-or-nothing migration.
Run the BridgeTunnelCrossingZoneNumberConstraintExample. Toggle penalization on and off. Compare the KML exports in Google Earth. Watch the routes stop zig-zagging across the bridge.