Lines

The product feature lines allows a service to use lines, which is an object that belongs to a product.

The basic functionality is an additional restriction of the station-based matching, which is itself a restriction to the default address-based matching.

The idea of lines is that a vehicle, which is connected to a line via the vehicle planning, only allows pickup and dropoff tasks at stations that are predefined along the line in a given order and at predefined times.

However, a line only visits stations with existing prebookings and skips those stations without. In contrast to classical bus or tram lines there is no predefined route from Station to Station for a line. Stations which are not prebooked are not visited, the route is directly redirected to the next prebooked Station. This can reduce significantly the travel time for a single passenger, but also enforces well-timed prebookings. Furthermore, a Vehicle does not start the line service, when there are no existing prebookings and ends the service at the last station with a prebooking.

This demands the prebooking to be at least before the line start.

Another functionality is the possibility to provide parallel stations along the line. That means, there can be two or more stations defined at the same place in the line schedule (stations with the same tier and the exact same relative time, see below). These stations are checked for prebookings. If there is one prebooking, the corresponding Station is added to the Vehicle Planning. In the unlikely event that there are bookings for two or more of these Stops, the matching algorithm checks if there are options to fulfill all requests in the given time windows and then handles them accordingly.

1. Pick up, drop off, and pass through
2. Time matching modes and “skip time window check”
   1. First booking fixates times along the line direction / “Floating” line
   2. Use scheduled time of pickup station
   3. Use scheduled time of dropoff station
   4. Use scheduled time of either pickup or dropoff station
   5. Strictly use the stations scheduled times
   6. Skip time window check
3. Fixed-schedule line stop tasks
4. Activate this feature

Pick up, drop off, and pass through

On the line it’s required to define for each line stop if passengers can get picked up, dropped off or if they are allowed to “pass through”.

Pass through means that a passenger is allowed to travel along the line “passing through” a station. This does not mean that the station is really visited. The routing will still always only go to stations with a booking on it and the restriction will also hold if there is no booking.

On a line A → B → C → D → E, on all stations, except for station “C” it’s allowed to pass through and on all stations pick up and drop off are allowed. Now, it’s possible for a user to book a ride from A → C, since B allows to pass through. It’s not possible for a user to book a ride from A → D, because inbetween the stop C does not allow to pass through. However, it’s again possible to book a ride from C → E. This behavior is independent of any other booking and a restriction of the line itself.

Time matching modes and “skip time window check”

The time matching mode defines how pick up and drop off times of rides are deduced from the relative times defined on the line. These time matching modes do not affect the routing.

The relative times are the times of the pre-planned line stops in relation to the start of the Vehicle Planning and are defined on the line.

In total, there are five different time matching modes available which are explained in more detail below.

The example below provides an overview of the different behavior expected for the different matching modes.

First booking fixates times along the line direction / “Floating” line

The first ride booked into the vehicle planning is the determining factor for the line. This means: the relative times of the line stops do not have an impact on the offer. The tiers of the line stops are checked to ensure that the requested pick up and drop off stations appear in ascending order on the line.

As boundary conditions for the offered times only the quality of service parameters defined in the matching configuration are used. The resulting negotiated pick up and drop off times for the ride are the time windows just like known in other cases: the standard five minutes time window at the pick up is used and the time window at the drop off is calculated by the driving time and the maximum allowed detour time.

All rides booked into the vehicle planning after there has already been a booking are matched accordingly and under consideration to keep the negotiated times of the other rides. This is why it’s recommended to set a (relatively) high allowed detour in matching configurations of lines.

Skip time window check should not be activated for floating lines.

Use scheduled time of pickup station

If the time matching mode “Use scheduled time of pickup station” is chosen, as negotiated time window for the pick up of a ride request the relative time of the corresponding line stop plus the common five minute slack is offered to the passenger. Of course only if this fits into the quality of service parameters of the matching configuration, especially the time deviation to request. The drop off however remains floating: it’s calculated by the standard travel time and maximum allowed detour.

All rides booked after into the vehicle planning after there has already been a booking are matched accordingly and under consideration to keep the negotiated times of the other rides. This is why it’s recommended to set a (relatively) high allowed detour in matching configurations of lines.

Use scheduled time of dropoff station

For the time matching mode “Use scheduled time of dropoff station” the negotiated drop off time is set fix to the relative time of the drop off station. No time window is communicated in this case.

The corresponding pick up time is calculated by the travel time between pick up and drop off and independent of the relative time of the line stop.

All rides booked into the vehicle planning after there has already been a booking are matched accordingly and under consideration to keep the negotiated times of the other rides. This is why it’s recommended to set a (relatively) high allowed detour in matching configurations of lines.

Use scheduled time of either pickup or dropoff station

This time matching mode differs between departure based ride requests and arrival based ride requests.

For departure based ride requests the negotiated time for the pick up is strictly set to the relative time of the pick up line stop. The drop off negotiation window is then calculated by the driving time but also it’s bound from above by the line stop time of the drop off station.

For arrival based ride requests, the negotiated time of the drop off is set strictly to the relative time of the line stop. The pick up time is also set to the line stop time of the pick up station (plus five minutes leeway).

Strictly use the stations scheduled times

As the name suggests, a ride request on a line with this time matching mode returns the relative times of the line stops as the negotiated times. This imitates the behavior of a “normal” bus line. Independent of the requested times and delays due to live traffic, the ride is clamped to the relative times.

In this case it makes sense to activate “Skip time window check” since the time windows of the vehicle plannings will most likely collapse due to live traffic, boarding times, and similar factors. This can be suppressed by skipping this health check, which simulates the behavior of a static bus line that also has no information about live traffic in the timetable.

However: In case the classic time window check is disabled the algorithm at least ensures that the solutions tasks are in ascending planned order compared to another.

Skip time window check

Usually, when a ride request is matched into a task list, the algorithm checks whether all already existing rides can still be served within their negotiated times. For this, we check whether the earliest time of a task is still before the latest time a task has to be done.

Example of a collapsed time window: The calculated pick up for a ride is (earliest) 8:15, however to reach the next task in time, the vehicle would have leave the corresponding station already at 8:05. Then we say that the time window [8:15, 8:05] is collapsed by 10 minutes.

When the option Skip time window check is enabled, this check is omitted and the algorithm simply assumes that the vehicle can arrive in time. This simulates the behavior of a static bus line, which also does not have any information about live traffic in the timetable, and should therefore be used only if the times shown to the user are the fixed relative times of the line.

Still, in case the classic time window check is disabled the algorithm at least ensures that the solutions tasks are in ascending planned order compared to another. This might lead to problems especially if line stops are close together (within the 5 minutes threshold we usually use to calculate the pick up time).

Enabling Skip time window check also lifts the shift-end feasibility guarantee. Matching can offer plans that finish after shift end, and a pause can slide past it. The end-of-shift task still stays last in the task list, but the plan is no longer guaranteed to complete before it.

Suppose we have the following line:

Station	Tier	Relative Time	Calculated driving time at ride request time
A	1	0 sec	0 sec
B	2	10 min	7 min
C	3	20 min	17 min
D	4	35 min	26 min
E	5	45 min	38 min

and a vehicle planning starting at 9:00 AM. The matching configuration allows a maximum detour of 150% with a 10-minute minimum, a 30-minute maximum, and a maximum time deviation to request of 1 hour.

Then a departure-based ride request for 9:30 AM from A → D would lead to the following offer if there is no other booking on the vehicle planning yet.

Time matching mode	Negotiated pickup time	Negotiated drop-off time
Floating	9:30 AM - 9:35 AM	9:56 AM - 10:09 AM
Fixed on pickup	9:00 AM - 9:05 AM	9:26 AM - 9:39 AM
Fixed on dropoff	9:09 AM - 9:14 AM	9:35 AM - 9:35 AM
Fixed on either pickup or dropoff	9:00 AM - 9:05 AM	9:26 AM - 9:35 AM
Strict	9:00 AM - 9:05 AM	9:35 AM - 9:35 AM

Fixed-schedule line stop tasks

By default, a line only visits stations that have a booking and skips the rest. A line can instead run on a fixed schedule, where the vehicle must visit every scheduled line stop regardless of whether anyone booked a ride. A passenger may get on or off, or not, but the vehicle still stops there.

When this is turned on for a line, each vehicle planning that serves the line gains a line stop task for every scheduled line stop. The driver drives to the stop and marks the task completed, similar to a repositioning task, but a line stop task is a scheduled public-service commitment tied to a station on the timetable rather than an operational move.

Line stop tasks are created only after a line is explicitly opted in. Existing lines are unaffected and keep visiting only booked stations.

You turn a line into a fixed-schedule line and manage its line stop tasks in Lines in Control Center. Product-wide behavior for these tasks—completion timing, cancellation, and automatic completion—is configured in driver-related settings.

Activate this feature

Roles: Super Admin

1. Navigate to the management settings of the product.
2. Within the Product features section, select the checkbox Lines.
3. Select Save.

The admin procedure for this feature is documented in Lines in ioki Operator or Lines in Control Center.