Docs
  • Solver
  • Models
    • Field Service Routing
    • Employee Shift Scheduling
    • Pick-up and Delivery Routing
    • Task Scheduling
  • 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.

Adapt this approach to your 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.

To account for ferry schedules, you need to adapt how you use the model.

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 20 minutes, which allows for the boarding and unboarding times of the ferry. By adding time windows to these artificial visits, you can model the ferry schedules and ensure the solution respects them.

Mainland and island ferry terminal visits

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"
        }
      ]
    }
  ]
}

You can now schedule visits 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.

Model the ferry trip back to the mainland similarly to the example above; 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 you need multiple technicians to service customers on the island, the approach becomes more complex and you need to adapt it.

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.

Depending on the amount of work on the island, you might need 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 you solve the planning problem for the mainland, you can analyze the resulting schedule to determine how many technicians will take the ferry to the island and when they are expected to arrive at the island terminal.

You can then use this information 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 technicians servicing the ferry terminal on the mainland are considered 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. You need to handle the split into subproblems and the integration of the results 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