How to build an efficient demand-responsive transport? the service design 2/3

The success of a DRT service rely on several pillars. In this second article, we will discuss the importance of service design when designing Demand-Responsive Transport. Even if dynamic DRT works with algorithms that make route decisions autonomously, the logic of building the offer (different from the scheduling / dressing used for fixed lines) requires a few choices to be made.

Designing Demand-Responsive Transport: the right questions

What is to be served?

We recommand to rely on demand and to define the areas (origin-destinations) that you would like to serve with DRT. Answering this question is not always easy, however, there is some data you can use:

• Data from an existing service
• Historical data on fixed lines
• Travel surveys
• Data from your national statistics bureau
• Data from telephone operators, etc.

Which service for which purpose?

The aim here is to define the quality of service you want to achieve. These goals vary according to the context. For example, in a dense area, it may be interesting to offer a reservation at the latest 5 or 10 minutes before departure, or even in real time. In a less densely populated area, the focus may be more on the frequency of daily trips or the guarantee of interconnection with other modes of transport. For a company, one might even think about a guaranteed arrival time at the company’s location.

Which service model should be implemented?

Once the DRT’s goals are identified, the service model must be set. Several models exist, here are some of them:

• The zonal model: this is the simplest and most applied model. It is also called “freefloating”. It involves defining a specific area in which vehicles will operate. Pick-up and drop-off within this zone is directly managed by the algorithm according to demand, with or without additional constraints. In Melun, the service model allows to take the DRT from and to any point of the area.

In Clamart, DRT vehicles ride without restrictions throughout the entire perimeter of the service, with a few stops at mandatory times.

• The feeder model: it is based on the zonal model, with additional constraint. This model allows users to be picked up in a delimited zone and impose the vehicle to go to a given point at a specific time, even if the vehicle’s route is flexible. For example, a stop at the train station may be mandatory at 8.00 a.m. because a train stops there at 8.10 a.m. This model is used in the context of intermodality (interfacing with other ways of transport). It’s one of the biggest challenges of DRT, which is not intended to replace the existing network, but to complete the mobility offer. In Strasbourg, zonal DRT for journeys within the metropolitan area is added to DRT for journeys to reach tramways and bus stations.

• The virtual line: the historical model which respects the classical lines, but which stops only when there is a request.

How to optimize the grouping rate ?

There is no exact answer to this question because it depends on the context of implementation and use cases. Supply and demand will greatly contribute to providing a solution. For a given demand, the consequences will not be the same according to the number of vehicles available. Moreover, technical optimisation will impact the rate of groupage: frequency of journeys, authorised detours, etc…

Almost all of today’s dynamic Demand-Responsive Transport solutions offer simulations that allow the comparison of different scenarios by playing with various parameters to find a solution with the optimal estimated grouping rate.

Is the DRT service understandable to the user?

It’s always tempting to embark on a highly technical approach to achieve a highly optimized and intelligent service configuration. However, this configuration may in fact be too complex to be understood by users who will not want to use it. In order to design an efficient Demand-responsive Transport, it is better to design a service that is slightly less optimised from a technical point of view, but which is widely used because understood by the public.