Docs
  • Solver
  • Models
    • Field Service Routing
    • Employee Shift Scheduling
    • Pick-up and Delivery Routing
  • Platform
Try models
  • Field Service Routing
  • Scenarios
  • Ferry Connections

Field Service Routing

    • Introduction
    • Getting started: Hello world
    • User guide
      • Terminology
      • Use case guide
      • Scheduling API concepts
      • Integration
      • Constraints
      • Using the API
        • Using the OpenAPI spec
        • API tooling
      • Demo datasets
      • Input datasets
        • Model configuration
        • Model input
        • Planning window
        • Time zones and daylight-saving time (DST)
      • Routing with Timefold’s maps service
      • Input validation
      • Model response
      • Output datasets
        • Metadata
        • Model output
        • Input metrics
        • Key performance indicators (KPIs)
      • Key performance indicators (KPIs)
      • Metrics and optimization goals
      • Score analysis
      • Visualizations
    • Vehicle resource constraints
      • Shift hours and overtime
      • Lunch breaks and personal appointments
      • Fairness
      • Route optimization
      • Technician costs
      • Technician ratings
      • Coverage area
    • Visit service constraints
      • Time windows and opening hours
      • Skills
      • Visit dependencies
      • Multi-vehicle visits
      • Multi-day schedules and movable visits
      • Priority visits and optional visits
      • Visit service level agreement (SLA)
      • Duration added for first visit on location
      • Visit profit
      • Visit requirements and tags
        • Visit requirements
        • Tags
    • Manual intervention
    • Recommendations
      • Visit time window recommendations
      • Visit group time window recommendations
      • Bulk time window recommendations
    • Real-time planning
      • Real-time planning: extended visit
      • Real-time planning: reassignment
      • Real-time planning: emergency visit
      • Real-time planning: no show
      • Real-time planning: technician ill
      • Real-time planning: pinning visits
      • Real-time planning: actual arrival and departure times
    • Real-time planning with patches
      • Real-time planning: extended visit (using patches)
      • Real-time planning: reassignment (using patches)
      • Real-time planning: emergency visit (using patches)
      • Real-time planning: no show (using patches)
      • Real-time planning: technician ill (using patches)
      • Real-time planning: pinning visits (using patches)
    • Scenarios
      • Configuring labor law compliance
      • Ferry Connections
      • Long-running visits
    • Changelog
    • Upgrade to the latest version
    • Feature requests

Ferry Connections

Sometimes, the area of operations is divided by a body of water and the only way to get from one side to the other is by ferry. In such cases, it is important to ensure that the routing solution accounts for the ferry connections when planning routes. The following guide will explain a possible approach to modeling ferry connections.

Please be advised that this approach needs to be adapted to the specific scenario.

1. The challenge with ferry connections

A ferry connection connects two locations across a body of water. While the OSRM profiles used by the FSR model know about ferry connections and can calculate routes that include ferry rides, it does not account for the ferry schedules. By just using the default FSR model as is, the solution will include ferry rides across the body of water, but will most likely not consider the ferry schedules, rendering the solution impractical.

In order to account for ferry schedules, the way the model is used needs to be adapted.

2. Modeling ferry connections

To bring the ferry schedules into the model, create visits for the mainland terminal and the island terminal. The service duration of these visits is twenty minutes, which allows for the boarding and unboarding times of the ferry. By adding time windows to these artificial visits, it is possible to model the ferry schedules and ensure that the solution respects them.

ferry terminals

These terminal visits (and the visits on the other side of the body of water) need to include dependencies to make sure they occur in the correct order.

{
  "visits": [
    {
      "id": "Mainland terminal",
      "timeWindows": [
        {
          "minStartTime": "2027-02-01T09:00:00Z",
          "maxEndTime": "2027-02-01T09:20:00Z"
        }
      ]
    },
    {
      "id": "Island terminal",
      "timeWindows": [
        {
          "minStartTime": "2027-02-01T10:40:00Z",
          "maxEndTime": "2027-02-01T11:00:00Z"
        }
      ],
      "visitDependencies": [
        {
          "id": "Island terminal depends on mainland terminal",
          "precedingVisit": "Mainland terminal"
        }
      ]
    }
  ]
}

Visits can now be scheduled on the island, however, they must occur during the time between the technician leaving the island terminal in the morning and returning later in the day to make the ferry trip back to the mainland.

The ferry trip back to the mainland must be modeled similarly to the above example, however, this time, the mainland terminal visit must depend on the Island terminal visit to make sure they occur in the correct order.

3. Complex planning scenario with multiple technicians

When multiple technicians are needed to service customers on the island, the approach becomes more complex and needs to be adapted.

One approach is to split the area of operations into two separate planning problems, one for the mainland and one for the island.

As a first step, the planning problem for the mainland is solved.

This planning problem includes the depot, the customers on the mainland as well as the terminal on the mainland. The terminal on the mainland should have time windows that reflect the departure times of the ferry. In order to model the necessary work on the island, the terminal visit on the mainland should have a service duration that reflects the expected work time on the island plus the ferry ride duration and an additional buffer to account for waiting times at the terminal on the island.

Dependent on the amount of work that needs to be done on the island, it might be necessary to create multiple terminal visits on the mainland to ensure that enough technicians are planned for a trip to the island.

This also needs to ensure that the technicians have enough time to complete their work on the island and return to the mainland within their shift duration.

Once the planning problem for the mainland is solved, the resulting schedule can be analyzed to determine how many technicians are planned to take the ferry to the island and at what times they are expected to arrive at the terminal on the island.

This information can then be used to set up the planning problem for the island. For the planning problem on the island, the depot would be the terminal on the island. All the technicians that are servicing the ferry terminal on the mainland would be considered as technicians in the planning problem on the island.

4. Integration of this approach

This approach for a step-wise planning process with two separate planning problems needs to be integrated into the overall planning process. The FSR model doesn’t automatically split the planning problem into two separate problems, solve it step-wise and then combine the results into a single schedule. The split into sub problems and the integration of the results needs to be handled externally.

This approach potentially also needs additional analysis of historical data in order to determine buffer times around the ferry rides to account for waiting times at the terminal on the island.

  • © 2026 Timefold BV
  • Timefold.ai
  • Documentation
  • Changelog
  • Send feedback
  • Privacy
  • Legal
    • Light mode
    • Dark mode
    • System default