Area of Operation Planning for Free-Floating Car Sharing Systems

Abstract

Free-floating car sharing systems provide a convenient and flexible mode of transportation, enabling the efficient utilization of vehicles and space within cities. To ensure a high quality of service and customer satisfaction, it is crucial that the system’s operational area is well-covered by vehicles, allowing users to quickly locate a nearby car when needed. However, servicing a large area can be expensive. Therefore, optimizing the operational area is essential to achieve the best possible coverage with the given fleet. A case study of a Viennese electric car sharing system is presented, focusing on the optimization of future expansion strategies. The study utilizes a demand forecast derived from a national mobility survey and taxi trip data, employing a mixed integer linear programming model to plan the operational area. The objective is to effectively cover the expected demand. The results demonstrate that the model is highly efficient and flexible in adapting to different requirements.

1. Introduction

In light of climate change, countries are increasingly looking for ways to reduce their greenhouse gas emissions. The European Union, for example, has set a goal of net carbon neutrality by 2050 in the European Green Deal [1]. In pursuit of this goal, big efforts are being made to increase the modal share of climate-friendly modes of transportation [2]. In an effort to reduce people’s reliance on individual car ownership, various kinds of Mobility as a Service (MaaS) systems are being developed and deployed to supplement these aforementioned modes of transportation.

Free-floating car sharing systems are part of the MaaS concept where instead of owning a car themselves, users can simply rent a vehicle whenever they need one. They can use the car for the required trip, and return it afterwards near their destination. If they want to return to the origin later, they can start a new trip or use alternative transport modes. The operators of such systems always designate some area of operation (AoO) within which rented cars may be picked up or parked and returned. Shared car ownership can reduce the burden on a city’s infrastructure (such as parking spaces). As shown in a study conducted for the city of Bremen, most users of car sharing systems actually forgo private car ownership in favor of car sharing (rather than use both) after becoming used to the concept, thereby reducing the demand for parking infrastructure within the city [3].

The success of a free-floating car sharing system critically depends on the users’ satisfaction with the system’s ability to fulfill their mobility demand. Specifically, whenever a user wishes to undertake a trip, a suitable car should be available near their point of departure. An empirical study using real booking data has shown that the willingness to use car sharing drops significantly as the distance a user has to walk to their rented car increases [4]. Likewise, it is important that users can actually end their rental close to their destination. The system’s area of operation thus needs to be sufficiently large to cover the start and end locations of as many of its prospective users’ trips as possible, and at the same time be compact enough to be reasonably densely covered by a fleet of vehicles that the operator can actually afford to purchase and maintain.

1.1. Outline

In this article, we investigate the problem of designing an optimal AoO for a free-floating car sharing system. Given some large candidate planning area, we choose which of its constituent parts should serve as the system’s AoO. Each part has certain costs associated with including it within the AoO, which counts against a given budget that we assume is available for establishing (or extending) the system. Our overall goal is to select an AoO that best covers the mobility demand within the planning area.

In the remainder of this section, we give a brief overview of the academic literature pertaining to the optimization problem we studied in this article. In Section 2, we formally describe the optimization problem under consideration and present a mixed integer linear programming formulation. Section 3 is dedicated to our case study of the electric car sharing service operated by ELOOP in Vienna, where we used our optimization algorithm to find optimal expansion strategies for the system’s area of operation at a variety of budget levels. The corresponding results are discussed in Section 4. Finally, we provide concluding remarks in Section 5.

1.2. Related Work

Free floating car sharing systems have been gaining increasing attention due to the flexibility and the global trend of reducing private car ownership. So far, research on optimization at the strategic level has mostly focused on the optimal placement of stations within its area of operation. Conversely, the problem of finding an optimal relocation strategy has been the primarily studied optimization problem at the operational level. Brandstätter et al. [5] and Ferrero et al. [6] give an overview of the literature pertaining to the optimal design and operation of electric car sharing systems. In more recent articles, Lu et al. [7] and Yang et al. [8] focus on optimizing charging and relocating aspects, but not the AoO. In terms of location optimization, Cheng et al. [9] use travel demand to optimize the locations of stations. However, they consider a station-based system and not a free-floating one. To the best of our knowledge, the aspects of business model, infrastructure and fleet management are well-covered in existing literature. However, optimizing the area of operation is an under-researched topic.

Boyacı et al. [10] describe a combined integer linear programming (ILP) formulation for the placement of charging stations and the relocation of vehicles within a station-based electric car sharing system and apply the resulting algorithm to a system in Nice, France. More recently, Brandstätter et al. [11] provide multiple exact (ILP-based) and heuristic algorithms for placing charging stations in a station-based one-way electric car sharing system. The authors evaluate their algorithms on both artificial and real-world instances from Vienna, Austria, and give insights into their performance characteristics, as well as the structure and quality of the resulting solutions.

Optimization problems related to the optimal design of an area by selecting its constituent parts are, of course, also common in other domains. For example, Alvarez-Miranda et al. [12] describe an ILP-based algorithm for determining the optimal layout of wildlife reserves with optional connectivity and buffer zone requirements and evaluate it on a variety of artificial and real-world instances.

2. Methodology

The formal problem for designing an optimal AoO can be described as follows. An undirected, connected graph $G=(V,E)$ is given that represents the entire planning area. Each vertex $i\in V$ represents a subdivision of the planning area, and edges indicate geographically adjacent subdivisions. Figure 1a shows an example where subdivision (white) are represented by vertices (blue). We are further given some revenues $p_{ij}$ (scaled mobility demands) for each pair of vertices $i,j\in V$, costs $c_i$ for each vertex $i\in V$ (costs for expanding the car sharing business to the area), and a budget B.

Our goal is to select a connected vertex subset $S\subseteq V$ (the area of operation) that maximizes the overall revenue between all pairs of selected vertices while ensuring that the set of selected vertices does not contain “holes” (i.e., it does not enclose any non-selected vertices) and the total costs of S do not exceed budget B.

MILP Formulation

We formulate a Mixed-Integer Linear Program (MILP) to describe the problem, which uses two single-commodity flows (SCF) to ensure

• The connectedness of the selected AoO;
• The avoidance of enclosing non-selected vertices.

The latter can be enforced by ensuring that each non-selected vertex is connected to the so-called boundary $W\subseteq V$, which is defined as the set of outermost sub-districts, see Figure 1b for an example. We refer to the flow ensuring connectedness of S (i.e., the selected AoO) as “f-flow”, whereas the flow used to ensure connectedness of the non-selected area is called “g-flow”.

As both flows operate on directed edges, we create an auxiliary graph $G^{\prime }=(V^{\prime },A^{\prime })$ to work with. The extended vertex set $V^{\prime }=V\cup \left\{s\right\}$ includes the additional vertex s that acts as the source of the g-flow. The extended arc set $A^{\prime }$ consists of two parts: the set of directed copies of the original graph’s edges, which we refer to as A, and arcs $(s,i)$ connecting the source vertex s to each vertex $i\in W$ on the boundary. Formally, $A^{\prime }=A\cup \left\{(s,i)\right|i\in W\}$, where $A=\left\{\right(i,j),(j,i)\mid \{i,j\}\in E\}$. The former arcs are required to allow for multiple, pairwise disconnected non-selected areas, as long as they are individually connected to the boundary.

We introduce the following variables:

• Binary variable $x_{ij}$ indicates whether both vertices i and j are included in the solution (and thus, their associated revenue can be collected).
• Binary variable $y_i$ indicates that vertex i is part of the solution, i.e, $i\in S$.
• Binary variable $r_i$ indicates that $i\in S$ is the source (“root-vertex”) of the f-flow.
• Fractional variable $f_{ij}$ is the amount of f-flow on arc $(i,j)\in A$.
• Fractional variable $g_{ij}$ is the amount of g-flow on arc $(i,j)\in A^{\prime }$.

The MILP formulation for our problem is as follows:

$$\begin{array}{cc}\hfill max& \sum _{i\in V}\sum _{j\in V}{p}_{ij}{x}_{ij}\hfill \end{array}$$

(1)

$$\begin{array}{ccc}\hfill \mathrm{s}.\mathrm{t}.& x_{ij}\le y_i\hfill & \hfill \forall i,j\in V\end{array}$$

(2)

$$\begin{array}{ccc}\hfill & x_{ij}\le y_j\hfill & \hfill \forall i,j\in V\end{array}$$

(3)

$$\begin{array}{cc}\hfill & \sum _{i\in V}{c}_i{y}_i\le B\hfill \end{array}$$

(4)

$$\begin{array}{cc}\hfill & \sum _{i\in V}{r}_i=1\hfill \end{array}$$

(5)

$$\begin{array}{ccc}\hfill & r_i\le y_i\hfill & \hfill \forall i\in V\end{array}$$

(6)

$$\begin{array}{ccc}\hfill & B·r_i-c_i·y_i+\sum _{(h,i)\in A}{f}_{hi}\ge \sum _{(i,j)\in A}{f}_{ij}\hfill & \hfill \forall i\in V\end{array}$$

(7)

$$\begin{array}{ccc}\hfill & \sum _{(i,j)\in A}{f}_{ij}\le B·y_i\hfill & \hfill \forall i\in V\end{array}$$

(8)

$$\begin{array}{ccc}\hfill & \sum _{j\in W}{g}_{sj}=\left|V\right|-\sum _{i\in V}{y}_i\hfill & \hfill \end{array}$$

(9)

$$\begin{array}{ccc}\hfill & \sum _{(h,i)\in A^{\prime }}{g}_{hi}=1-y_i+\sum _{(i,j)\in A}{g}_{ij}\hfill & \hfill \forall i\in V\end{array}$$

(10)

$$\begin{array}{ccc}\hfill & g_{ij}\le \left|V\right|·\left(1-y_i\right)\hfill & \hfill \forall (i,j)\in A\end{array}$$

(11)

$$\begin{array}{ccc}\hfill & x_{ij}\in \{0,1\}\hfill & \hfill \forall i,j\in V\end{array}$$

(12)

$$\begin{array}{ccc}\hfill & y_i\in \{0,1\}\hfill & \hfill \forall i\in V\end{array}$$

(13)

$$\begin{array}{ccc}\hfill & r_i\in \{0,1\}\hfill & \hfill \forall i\in V\end{array}$$

(14)

$$\begin{array}{ccc}\hfill & 0\le f_{ij}\hfill & \hfill \forall (i,j)\in A\end{array}$$

(15)

$$\begin{array}{ccc}\hfill & 0\le g_{ij}\hfill & \hfill \forall (i,j)\in A^{\prime }\end{array}$$

(16)

The objective function (1) maximizes the revenue collected from all trips between pairs of selected vertices. Constraints (2) and (3) ensure that the revenue $p_{ij}$ for trips from i to j can only be collected ($x_{ij}=1$) if both vertices i and j are selected to be in S ($y_i=y_j=1$). The budget Constraint (4) ensures that the accumulated costs $c_i$ of all selected vertices do not exceed the available budget B.

Constraints (5)–(8) ensure the connectivity of the selected AoO by means of a SCF formulation. Constraint (5) ensures that exactly one root vertex is selected, while (6) ensures that it is also contained in the solution. Constraint (7) ensures that each selected vertex i consumes at least $c_i$ units of f-flow, while also ensuring that if i is the selected root vertex (i.e., $r_i=1$), it instead sends out up to $B-c_i$ units of f-flow. Constraint (8) ensures that non-selected vertices never send out any f-flow, thereby preventing them from being used as bridges between otherwise disconnected components. Note that Constraint (4) can be omitted as the f-flow already ensures that the budget B is not exceeded, but for performance reasons it remains in the formulation.

As noted above, “holes” in the AoO are prevented by ensuring that all non-selected vertices are connected to the boundary, which is enforced by the following constraints. By Constraint (9), the artificial source vertex s (which is connected to all boundary vertices in W) sends out exactly $\left|V\right|-\left|S\right|$ units of g-flow (i.e., one unit for each non-selected vertex). Constraint (10) ensures that all non-selected vertices (where $y_i=0$) consume exactly one unit of g-flow, whereas strict flow conservation is enforced for selected vertices (where $y_i=1$). In conjunction with Constraint (11), which prevents selected vertices from sending out any g-flow, this ensures that only non-selected vertices may be part of the corresponding flow system. Thus, all non-selected vertices are guaranteed to be connected to the boundary W, either directly or via other non-selected vertices.

Finally, Constraints (12)–(16) define the domains of our variables.

3. Case Study for Vienna

In our computational study, we used the optimization algorithm described in the previous section to optimize the AoO of the Vienna-based electric car sharing provider ELOOP [13] for a variety of future expansion strategies. In their free-floating car sharing system, customers are allowed to drop off their rented cars anywhere within this area, which is also referred to as home zone by the company. Trips to locations outside of the home zone are possible, but customers need to return the car to the home zone to end the rental.

3.1. Subdivision Graph

All benchmark instances share the same subdivision graph $G=(V,E)$, which is based on the official geographical subdivision of Vienna into 250 sub-districts (officially called “Zählbezirke”, i.e., counting districts). Each sub-district i is given as a polygon $P_i$ describing its perimeter as a sequence of latitude–longitude pairs [14].

The graph G contains one vertex for each sub-district. An edge $\{i,j\}\in E$ exists between any two vertices $i,j\in V$ whose corresponding polygons $P_i$ and $P_j$ touch, i.e., if the minimum distance between them is zero. The cost $c_i$ of each vertex $i\in V$ is the area of its corresponding sub-district’s polygon $P_i$ in square meters. This allows us to use the budget B to specify the maximum area of the AoO that we want to find. The revenue parameter $p_{ij}$ of edge $\{i,j\}\in E$ represents the expected travel demand from sub-district i to j. The derivation of these parameters from various data sets is described in detail in Section 3.2.

3.2. Mobility Demand Forecast

We use two different mobility demand forecasts in our computational experiments. The first is based on an Austrian mobility behavior survey (OEU), whereas the second is based on live taxi traffic data within Vienna. Each demand forecast consists of a set of trips that we assume the customers of ELOOP would like to make. A trip consists of an origin sub-district in which it starts, a destination sub-district in which it ends, and a duration.

First, we analyzed historic trips made by customers of ELOOP within their current area of operation between July and October 2019. While these data could not be used for the planning of expansion strategies (since they do not contain any data outside the current AoO and the time was pre-COVID and therefore with other mobility behavior), it proved useful during data analysis as a benchmark to compare the other two data sets against. We refer to this as the ELOOP data set.

3.2.1. The OEU Data Set

The OEU data set is based on the large-scale mobility survey “Österreich Unterwegs” that took place in 2013/2014 and contains data on the Austrian population’s mobility behavior. The daily schedule of each participant was recorded, representing that person’s mobility behavior for a single day. Each of these daily schedules consist of an alternating sequence of trips and activities. Each trip and activity includes data on their location and duration. Trips include information on the mode of transportation that was used, which can be walking, biking, driving, or using public transport. An activity is classified by its type, representing a person either being at home, working, shopping, running errands, educating themselves, or doing some kind of leisure activity.

For the purpose of optimization, we used resampled data from the original data set only containing trips (and activities) in or near Vienna, resulting in over 1.6 million potential trips.

We performed the following operations to obtain the final data:

• Trips separated by an activity taking less than 30 min were merged. The underlying assumption is that customers would not end their rental of a shared car for such a short activity, because they would not risk another person taking the car they just used.
• Trips separated by an errand or shopping activity were merged. Similar to the reasoning above, users would usually continue their trip after interrupting it with such an activity without their rented car being taken by another person.
• Trip sequences interrupted by activities outside of Vienna were merged, since it is not possible to end their rental if they are outside the AoO. Any trips before a person’s first daily arrival in (or after their final departure from) Vienna (e.g., commuting trips by people living outside but working within the city) were dropped.
• Trips made on foot or by bike were dropped, as we expect that these trips would most likely not be replaced by trips with a shared car. The reason is that walking and biking do not cause additional costs, while car sharing is rather expensive. We assume that people using public transport might instead consider car sharing due to the added convenience factor.

Only consecutive trips made by the same person were merged. The resulting trip set consists of approximately 800,000 trips that start and end in Vienna. Only trips originally made by car or public transport are included, as we assume that those would most likely be replaced by car sharing trips (in the latter case, e.g., to improve travel times or comfort). It places a higher emphasis on longer-duration trips, which are preferred by ELOOP’s business strategy (and pricing model) for ecological reasons.

3.2.2. The Taxi Data Set

This data set consists of over 400,000 taxi trips within Vienna, which are based on actual trips that took place within four different weeks of the year 2014.

Although taxi and car sharing services do not necessarily share the same customer base and trip characteristics—round trips are, for instance, less common among taxi rides—taxi trips have already been successfully used to derive car sharing demand forecasts in other studies on the topic (see, e.g., [11]). Car sharing can be regarded as a competitor since the client base is similar. While the taxi covers a wider serviced area and comes with a driver, car sharing is a cheaper self-service alternative.

3.2.3. Comparison of Data Sets

We analyzed different properties of the data sets and identified trip durations as the most important one for comparing them, as these can be used directly as the trips’ revenues within our optimization algorithm due to ELOOP’s duration-based pricing model [15].

Both the ELOOP and the OEU data set exhibit a wide variety of mobility behaviors that are typical for urban areas. Most trips take up to one hour, including a large number of regularly recurring trips for, e.g., commuting and shopping purposes. In contrast, longer trips, which gradually decrease in frequency as their duration increases, often represent those trips that do not recur on a regular daily or weekly schedule. Figure 2, Figure 3 and Figure 4 show the absolute frequency of trips of different durations (up to three hours) for the three data sets.

While the ELOOP data set contains more trips under 10 min than the OEU data set, the latter contains more trips with durations between 35 and 60 min due to the inclusion of public transport trips that could be replaced by comparatively shorter car sharing trips. Conversely, the taxi data set contains notably fewer trips of longer duration, most likely since taxi trips are more expensive and thus, mostly considered only for shorter trips. Like the ELOOP data set, both the OEU and taxi data set skew heavily towards shorter trips with 95 percent of their trips taking at most three or one hours, respectively.

Although the ELOOP data set does contain a few exceptionally long trips with a duration of multiple weeks, over 95 percent of all ELOOP trips have a duration that is smaller than four hours. Trips of such long durations (spanning multiple days) are not present in the OEU and taxi data sets (on which our computational results are based). However, the absence of such extreme outliers is unlikely to significantly affect the design of the optimal area of operation.

3.2.4. OD Matrix Generation

To derive the actual revenue coefficients $p_{ij}$ for each pair of sub-districts $i,j\in V$, we compute two different Origin–Destination (OD) matrices $\mathbf{N},\mathbf{D}:\left|V\right|\times \left|V\right|\mapsto \mathbb{R}$ for each of the data sets. The ntrips matrix $\mathbf{N}$ contains the number of trips from sub-district i to j at $N_{ij}$, whereas the duration matrix $\mathbf{D}$ contains the total duration of all these trips as $D_{ij}$ instead.

Figure 5 shows plots for each of the six different OD matrices, which reveal that they broadly exhibit similar structural characteristics. The sub-district indices correspond roughly to the centrality of the respective sub-district, with lower indices indicating more central ones. All matrices show a higher number of trips (or longer total trip durations) along their main diagonal. These entries correspond to round trips that start and end within the same sub-district. Off the main diagonal, trips (and their total durations) are more evenly spread among the various sub-district pairs, albeit with some sparser areas clearly visible in any case. For the ELOOP data set, most of these empty areas correspond to those parts of Vienna that are not covered by ELOOP’s current AoO. In the taxi data set, sparser areas are mostly found in the rows and columns representing outer districts. Such trips from inner to outer districts (or between outer districts lying on opposite sides of the city) appear to be too long (and thus, expensive) to be frequently made by taxi. Conversely, the density of trips and their total durations increase towards the inner districts with lower indices. The OEU data set’s matrices demonstrate the most uniform distribution of trips (and their overall durations) among sub-district pairs. Despite these differences, the individual matrices $\mathbf{N}$ and $\mathbf{D}$ of the three data sets are structurally very similar.

3.3. Experimental Setup

In our computational experiments, we applied our optimization algorithm to a set of 396 benchmark instances. For both the OEU and the taxi data set, we generated two different demand forecasts by using their respective $N_{ij}$ and $D_{ij}$ matrix entries as the revenue forecasts $p_{ij}$ between each pair of sub-districts. As previously noted, the cost for including each sub-district in the area of operation corresponds to its size in square meters. For each of these four demand forecasts, we then generated nine different original instances with varying budgets. Since we wanted to investigate different expansion strategies for ELOOP, we chose budget values $B=\beta ·H$, where H is the size of the current AoO. The budget factor $\beta$ is chosen from $\{1,1.1,1.25,1.33,1.5,1.75,2,2.5,3\}$. In comparison, the entirety of Vienna has an area of approximately $9.55·H$.

For each of these 36 original instances, we then created ten further bootstrapped instances for stability analysis by sampling $10\%$ of the original data set’s trips, yielding a total of 396 instances (original and bootstrapped).

We implemented our optimization algorithm in Java and used the CPLEX Studio 12.6.2 framework as our MILP solver. All benchmark runs were performed on a single core of an Intel^® Xeon^® CPU E3-1220 V2 with 3.10 GHz (Intel Corporation, Santa Clara, CA, USA).

4. Results and Discussion

All instances were solved to proven optimality using default CPLEX settings within four hours. The fastest instance required 19 s for termination, and all except three instances terminated in under 22 min. The average runtime across all instances was approximately 21 min and the median runtime was approximately 5 min.

4.1. Solution Similarity

In our first set of analyses, conducted solely on the 36 original instances, we investigated the degree to which the optimal solutions to the four different instances (corresponding to the four different revenue forecasts) for each budget factor $\beta$ agree on the composition of the optimal area of operation. Specifically, we looked at the size of the overlaps of the different areas of operation given by the four (potentially) different optimal solutions.

Figure 6a,b illustrate this by showing the solutions of both instances from the OEU data set with budget factor $\beta =1$ (with revenues proportional to the number of trips and their total duration, respectively) side by side. Clearly, many sub-districts are selected as part of the optimal area of operation in either both or none of the two solutions, while only a few are selected in exactly one of them.

While the solution shown in Figure 6b prefers some sub-districts in the west and south, the one shown in Figure 6a instead selects ones in the south-west and the north preferentially. Still, the AoOs of the two solutions have an overlap of $84.4\%$, which shows that they largely agree on which sub-districts to include in the AoO.

Figure 7 contains an overview of the overlapping areas of the solutions relative to the respective $\beta$, e.g., “$\mathrm{dur}\bigcap$” shows the overlaps of the solutions produced by the OEU and taxi data set with regard to $\mathbf{D}$.

In general, the solutions for instances derived from the same trip data set (but using different revenue matrices $\mathbf{N}$ and $\mathbf{D}$) tend to agree on the AoO more than those derived from different trip data sets that use the same revenue metrics. Even when comparing the overlap of all four solutions for a single $\beta$, the overlap always exceeds 60 percent.

4.2. Solution Structure

When looking at individual optimal solutions instead of only analyzing the relative overlap between multiple solutions, we can gain additional insights into how they structurally differ between the different trip data sets.

Figure 8 shows the solutions for six different instances, each using the revenue matrix $\mathbf{N}$ (number of trips), with the first row showing the ones for “OEU”-derived instances, and the second row showing those for the corresponding “taxi”-derived ones. These figures show that, as the available budget grows larger, the optimal solutions for the “taxi” instances tend to select an area of operation that stays closer to the city center (resulting in a more compact shape), whereas the AoOs for “OEU” instances grow towards the city boundary.

We also observe that instances for a given trip data set and revenue metric tend to generally grow mostly monotonically as the available budget is increased (i.e., those sub-districts that are included in the optimal solution for a certain budget factor ${\beta }_0$ are, in most cases, also included in the optimal solutions for the corresponding instances with a higher budget factor ${\beta }^{\prime }>{\beta }_0$). This suggests that a slow and steady incremental growth strategy can work very well for electric car sharing companies in practice, as previously made choices on where to expand frequently still turn out to be good choices during subsequent expansions. For space reasons, the plots of the optimal solutions for all 36 original instances are included in Appendix A in

Table A1. Solutions (highlighted in teal) of all instances and configurations ($\beta$, data set, revenue metric). The semi-transparent area shaded in red denotes ELOOP’s current AoO.

$\mathit{\beta }$	OEU ntrips	OEU dur	Taxi ntrips	Taxi dur
$1.00$
$1.10$
$1.25$
$1.33$
$1.50$
$1.75$
$2.00$
$2.50$
$3.00$

.

4.3. Solution Stability

To investigate the dependence of an optimal solution’s structure on the specific set of trips included from a given trip data set (like “OEU” or “trip”), we also performed computational experiments on the ten bootstrapped instances that we created for each original instance (see Section 3.3).

As in Section 4.1, we focus our analysis on the relative agreement (i.e., overlap) between solutions. However, in contrast to our previous experiments, we now compare those ten bootstrapped instances derived from the same trip data set, using the same revenue metric and the same budget factor $\beta$.

The first four lines in Figure 9 show the overlap between the optimal solutions for all bootstrapped instances pertaining to a certain configuration (trip data set and revenue metric). These results indicate strong agreement between their corresponding solutions on the composition of the optimal area of operation within a given configuration. Both configurations based on the taxi trip data set, as well as the “OEU” configuration with revenue coefficients $N_{ij}$, consistently show solution overlaps in excess of $90\%$. While the “OEU” configuration with duration-based trip revenues does lag notably behind the other three in terms of inter-solution agreement for instances with budget factors $\beta \le 1.75$, it does (mostly) catch up to the others for higher values of $\beta$. These consistently strong to very strong agreements between solutions for a configuration are especially noteworthy when considering the fact that we are now looking at the intersection of ten individual areas of operation, where even small differences between the individual pairs of solutions can lead to large disagreement when all are considered at once.

The situation does, however, change when looking at the agreement between solutions across instance configurations for the same budget factor $\beta$: The overlap between the solutions hovers around $60\%$, unsurprisingly even worse than the agreement between only the original instances with a given $\beta$.

When considering the ten solutions of each configuration and budget value $\beta$ simultaneously, familiar patterns emerge. Figure 10 shows that solutions for instances based on the taxi data set tend to remain more compact and closer to the city center, whereas ones based on “OEU” trips branch out more towards the outer sub-districts. We also observe the aforementioned strong agreement between solutions within a configuration. A large majority of sub-districts is colored solidly blue, indicating that they were selected by all candidate solutions. Moreover, the ones with more reddish hues, which indicates that they were selected less frequently, tend to be selected more often as the available budget grows, again hinting at a monotonic growth pattern.

4.4. Extending ELOOP’s Current Area of Operation

The overall goal of our study was the design of optimal expansion strategies for the electric car sharing company ELOOP. However, our previous algorithmic approaches never considered the layout of ELOOP’s existing area of operation, which they also refer to as home zone.

While starting from a blank slate certainly allows an operator more flexibility in the design of their system, existing customers would likely prefer a strict expansion of the AoO. We therefore present a variant of our algorithm that ensures that the current system’s AoO is necessarily included in any feasible solution.

4.4.1. Approximating ELOOP’s Current Area of Operation

Since our optimization approach operates on the basis of sub-districts, but the ELOOP’s current home zone also contains partial sub-districts along its boundary, we have to approximate the AoO before extending it. For this purpose, we define a parameterized set ${\mathcal{H}}_{\theta }$ for any $\theta \in [0,1]$ as containing all those sub-districts that both touch the current AoO and share at least $\theta$ of its area with it. Choosing $\theta =1$ results in an under-approximation of the current AoO (with a size of approximately $0.64·H$) consisting only of those sub-districts that are entirely contained within it, whereas $\theta =0$ results in an over-approximation (of size $\approx 1.58·H$) containing any sub-district sharing even the slightest sliver with it.

For our experiments, we chose $\theta =0.5$, which results in an approximation that is visually quite close to the current AoO and includes approximately $93.5\%$ of its original area. Figure 11 shows these approximations for the three previously mentioned values of $\theta$.

4.4.2. Strictly Extending the AoO

Since the policy of strict extension imposes additional restrictions on the composition of the optimal AoO, we expect their enforcement to entail some opportunity cost. This cost can be quantified by comparing the improvement of the unrestricted instance’s objective value with the one where a strict extension is enforced:

$$\begin{array}{c}\hfill obj\mathrm{improvement}[\%]=\left(\frac{ob{j}_{f=0}}{ob{j}_{f=1}}-1\right)·100\end{array}$$

Here, $ob{j}_{f=0}$ and $ob{j}_{f=1}$ denote the objective values for the corresponding unrestricted and restricted variants, respectively.

In our computational experiments, the objective improvement of the unrestricted variant is rather small, starting out at values of around $4\%$ at a budget factor of $\beta =1.1$ and steadily decreases as $\beta$ grows. This suggests that the extension of the current AoO using a strict extension quickly outweighs the opportunity cost, especially for larger expansions. We conclude that the original AoO by ELOOP is already well-chosen, since the difference to the solutions of the optimization algorithm in terms of profitability is minimal. Figure 12 compares the unrestricted and restricted extension of the AoO, showing that the unrestricted solution favors the inclusion of sub-districts towards the southwest if the budget is increased by 10 percent.

5. Conclusions and Future Work

In this article, we proposed an analytical, data-driven approach for planning the area of operation (AoO) for a free-floating car sharing system with respect to a certain expected mobility demand. Given a limited budget, our algorithm finds a selection of subdivisions of the planning area that allows the operator to serve the most profitable regions, where profitability is calculated based on the mobility demand forecast between pairs of these subdivisions.

We used our algorithm to compute various expansion strategies for the Vienna-based electric car sharing company ELOOP. In the case study, we used two different mobility demand forecasts, one based on a mobility survey, and one based on urban taxi traffic data. We observe that although the basic structure of the optimized AoO are similar, the extension of the AoO can be very different. With the help of our analytical approach, the operator can obtain valuable decision support in which area he wants to expand and which type of potential customers he wants to attract.

As future work, we want to apply our model to other car sharing operators and/or other cities, as we believe that it is both simple and flexible. From the methodological point of view, the aspect of demand uncertainty could be addressed with stochastic programming. This is a different way of modeling that accounts for the uncertainty of the input data in a more sophisticated way.