Addressing the “minimum parking” problem for on-demand mobility

Parking infrastructure is pervasive and occupies large swaths of land in cities. However, on-demand (OD) mobility has started reducing parking needs in urban areas around the world. This trend is expected to grow significantly with the advent of autonomous driving, which might render on-demand mobility predominant. Recent studies have started looking at expected parking reductions with on-demand mobility, but a systematic framework is still lacking. In this paper, we apply a data-driven methodology based on shareability networks to address what we call the “minimum parking” problem: what is the minimum parking infrastructure needed in a city for given on-demand mobility needs? While solving the problem, we also identify a critical tradeoff between two public policy goals: less parking means increased vehicle travel from deadheading between trips. By applying our methodology to the city of Singapore we discover that parking infrastructure reduction of up to 86% is possible, but at the expense of a 24% increase in traffic measured as vehicle kilometers travelled (VKT). However, a more modest 57% reduction in parking is achievable with only a 1.3% increase in VKT. We find that the tradeoff between parking and traffic obeys an inverse exponential law which is invariant with the size of the vehicle fleet. Finally, we analyze parking requirements due to passenger pick-ups and show that increasing convenience produces a substantial increase in parking for passenger pickup/dropoff. The above findings can inform policy-makers, mobility operators, and society at large on the tradeoffs required in the transition towards pervasive on-demand mobility.


Main methodology
In this section, we give a more detailed description of the methodology used to estimate fleet size and parking requirements for the on-demand vehicle service (OV) based on simulated trip data. The input of the methodology is a list of trips that people currently are assumed to make in private cars; we're assuming every trip will need to be served by OVs in the future. This way, the methodology examines a hypothetical scenario to characterize the maximum potential gains from the adoption of OVs. We note that the methodology does not depend on whether the OVs are autonomous or have a driver. Depending on which variation of the methodology is used, it relies either on the full knowledge of the trips in advance (i.e. knowing all trips made in a day in advance) or at least partial advance knowledge, i.e. knowledge of upcoming trip requests in a given time window (5-30 minutes, depending on the simulation parameters). While the latter case can correspond to a system requiring advance reservation, it is unclear whether such a system would be popular with users, who are now used to near-instantaneous reservations offered by transportation network companies (TNCs) and taxi reservation systems as well. Furthermore, all of our methodologies rely on a central controller to assign vehicles to passengers and parking.
Two variants of the main methodology for assigning vehicles to trips and parking spaces are outlined in Algorithms 1 and 2 (notations used in both cases are further listed in Table S1 and further steps of Algorithm 2 are detailed in Algorithm 3). These can be further combined with the shareability networks approach to work on trip chains representing an ideal dispatching strategy instead of individual trips. Both variants work by assigning (1) trip ends to trip starts (i.e. a vehicle makes a connection among consecutive trips); (2) trip starts to free cars (i.e. vehicles are assigned to trips); (3) trip ends to free parking (free vehicles are assigned parking). This process is illustrated in Fig. S1. In both variants, when a trip start or end cannot be assigned a suitable free car or parking, a new car or parking space is "created". This way, the simulation starts with zero parking spaces and cars and only the minimum amount are added over the course of the simulation. The main difference between the two approaches is the way trips are processed: Algorithm 1 processes trips sequentially, always processing one trip start or end event at a time, assigning the closest available vehicle or parking (this way, we refer to it as a greedy heuristic). On the other hand, Algorithm 2 processes trips in batches by using sliding time window that is progressed over the set of trips, performing optimized bipartite matchings in each step.
To make realistic decisions about vehicle assignment, we calculate the travel times based on real-world data as well. In the case of Singapore, average travel times between a set of road intersections were provided based on real traffic data at different times of the day and week. There are a total of 11,789 intersections, providing good coverage of the area. Table S1 describes the main notations used in both algorithms. In both cases, we start with a set of trips (T ), where each trip (t ∈ T ) is a tuple defined by start location, end location, start timestamp and end timestamp. In this analysis, we represent locations by a set of discrete nodes. Nodes can correspond to intersection, buildings, etc., and are defined by their coordinates and are matched to the road network. In the case of Singapore, we have a total of 4529 nodes. Travel times and distances (shortest path along the road network) among nodes are calculated in advance before running the algorithms described here. Our methodologies could easily accommodate more nodes or other representation of locations (e.g. working directly with coordinates). Start and end timestamps of trips are considered fixed (and known in advance), thus discounting any potential  Figure S1: Left: illustration of the matching processes used to assign vehicles to trips and parking to vehicles. Figure was created with Inkscape, version 0.92.3, available at https://inkscape.org/ variations in traffic. This also means that cars have to be available exactly at the start time of all trips. Each trip is separated into a start and end event, which are stored in two separate lists of events (S and E respectively). Both algorithms then work on these event lists. For a start or end event (s ∈ S or e ∈ E), we then denote their timestamp as t s or t e and their location as n s or n e . Since locations are represented as a discrete set of nodes, these can be directly compared for equality, while travel distances between locations are denoted by d(e, s) and travel times by t(e, s) and these are given by a lookup among the pre-computed values.

Preliminaries and notations
A main component of both algorithm are the list of available parking spaces and cars, denoted by L P and L C respectively. One parking space or car (p ∈ L P or c ∈ L C ) is represented by its location (n p or n c , from the same set of nodes that were used by the trips) and a timestamp (t p or t c ) which is the time when the parking or car will become available. This is necessary since it will take some time for cars to reach parking or the start of the trips. E.g. if a trip finishes at t e at node n e , but a different node is selected for parking, the car will be only parked at time t c = t e + t(e, c). When selecting the car to serve upcoming trips, this needs to be respected, i.e. it can only serve trip for which t s > t c + t(c, s). Note that, similarly to the notation used for the distances and travel times between trip start and end events, t(c, s) and t(e, p) denote travel time for a car to reach the start of a trip from its current location or a car to reach the parking stop after finishing a trip. Similarly, d(c, s) and d(e, p) denotes the travel distances involved.

Greedy heuristic estimation
Algorithm 1 describes a greedy heuristic to assign cars to trips and parking spaces. It is a simple and efficient way for achieving this and calculating the minimum number of cars and parking spaces required by starting from zero available and recording the ones that were added during the course of processing all trips. The basic functioning is to process trip start and end events in sequence and always assigns the closest available car to a trip start and the closest available parking space to a trip end. Travel time to and from parking spaces is taken into account, i.e. it is recorded when a car reaches an assigned parking space and checked that it is able to reach the start of any new trip considered. A main parameter, r max determines the maximum distance cars are allowed to travel to reach trip starts or parking. E.g. if r max = 1 km then at the start of the trip, a car is only assigned if the closest available car is less than 1 km distance away. If no car or parking is available closer than r max when needed, a new one is added to the system, increasing the count of total number of cars or parking (this happens in lines 41-43 and 54-55 in Algorithm 1). This way, we can start the simulation with zero cars and parking and only the minimum number will be added during the simulation.
A further consideration which is a separate part of Algorithm 1 is creating connections between consecutive trips. This means that instead of assigning a parking space after the end of a trip, a vehicle is assigned to serve an upcoming trip directly. This is an important part, since without this, a vehicle could be redirected to a parking space too far away, making it impossible to connect to an upcoming trip which happens closer or in a different direction. This is especially true for larger r max values, where travel to more distant locations is possible. Connecting trips is faciliated by introducing a "look-ahead" parameter, t max , and assuming that reservations for upcoming trips are made at least this time in advance. The value for this is determined as t max = r max /v, wherev is a lower bound for the average expected travel speed assumed for short relocation trip. In practice, we usev = 20 km/h. Note that since we are assuming that trip start times are fixed (are served without delay), we are essentially requiring reservations in advance of t max even without trip connections, as this a bound on the time needed to reach a trip start from r max distance away. Analysing a system with live Algorithm 1 Greedy heuristic algorithm for determining fleet size and parking demand.
1: T = { list of trips or trip chains } 2: r max = maximum distance that OVs are allowed to travel empty 3: t max = look-ahead time for trip reservations 4: N P = 0 parking spaces required 5: N C = 0 number of cars required 6: D tot = 0 extra travel distance 7: L P = { empty list for free parking spaces (along with timestamps when they become available) } 8: L C = { empty list for available cars (along with timestamps when they become available) } 9: S = { empty event list for start events } 10: E = { empty event list for end events } 11: for all t ∈ T do 12: separate t to start and end "events" 13: add these to S and E respectively 14: end for 15: order S and E by timestamp 16: process events in time order with t max shift between end and start events: 17 if t s < t e + t max then process start event 21: we require that the vehicle should be provided a parking location or assigned to a next trip L P list of available parking spaces (initially empty) p ∈ L P one available parking space; beside location, p also contains a timestamp, which is the time when the parking becomes available (i.e. this can be in the future for an already assigned trip) L C list of available cars (initially empty) c ∈ L C one available car; beside location, c also contains a timestamp, which is the time when the car becomes available t x (for x ∈ S, E, L P or L C ) timestamp of entity (i.e. start or end time of a trip, or timestamp when a parking or car becomes available) n x (for x ∈ S, E, L P or L C ) location of entity (start or end of trip or car or parking); locations are represented by one of discrete "nodes" d(x, y) (for x, y ∈ S, E, L P or L C ) distance between the locations of two entities (e.g. the distance from an available car to the start location of a trip) t(x, y) (for x, y ∈ S, E, L P or L C ) travel time between the locations of two entities (e.g. time it takes for an available car to reach the start location of a trip) reservations, especially with respect to passenger waiting times is beyond the scope of the current work and has been investigated in several different contexts already.
To be able to process connections between trips, we process trip ends and starts separated by a window of t max . This means that we process start events that are t max into the future compared to the end events being processed: selecting the next start and end events s and e from the time ordered lists S and E, we select s to process if t s < t e + t max , and otherwise we select e (this is indicated in line 20 of Algorithm 1: processing of a trip start event happens in lines 21-46 and processing of a trip end event happens in lines 48-57). This way, when processing a trip start event, we not only look for cars which are parked, but also search among trip end events happening in the interval [t s − t max , t s ). If there are any trip end events in this interval which are suitable (meaning that they happen less than r max distance away and the start event in question can be reached from them, i.e. t e + t(e, s) < t s ), we select the one with the shortest travel distance as the match and assign its vehicle to serve the trip start event in question (this is done in lines 24-33 in Algorithm 1). In this case, the trip end event that was selected is not processed in the normal way to assign a parking to it (i.e. it is removed from the event list, so lines 48-57 are not executed for it). Nevertheless, even in this case, temporary parking is reserved at the start of the trip as the vehicle will typically arrive earlier than the start of the trip it is assigned to. For this purpose, only parking available at the start location (start node) of the trip is considered. If no such parking is available, the total number of parking spaces is again increased.
The result of this analysis is the total number of parking spaces needed after processing all trips (N P ), the total number of cars needed (i.e. fleet size, N C ) and the total "extra" distance traveled by the fleet (D tot ; this only includes distance traveled outside of making the trips themselves). Furthermore, the locations in L P and L C at the end of the simulation gives the locations where parking was needed during the simulation, thus our estimate of the spatial distribution of parking demand.
A further modification of Algorithm 1 is that it can be combined with an "ideal" dispatching strategy fonud by the methodology of shareability networks. In this case, first a dispatching strategy is generated by creating a bipartite graph among trip ends and starts and calculating a maximum matching on it; the result of this is a list of trip chains, each chain being a sequence of trips that are served by the same vehicle. In this case, we use these trip chains as the input instead of individual trips. This means that start and end events (S and E) will only include the start and end of whole trip chains instead of individual trips. In addition, since there could be need for temporary parking during a trip chain, we modify Algorithm 1 to process trip connections in the chain (supplied as separate input) in a similar manner to connections among trips found during running it, by reserving temporary parking at the start of trips in a chain (lines 25-33).

Bipartite matching in batches
In contrast to Algorithm 1 which performs local optimization by considering one trip at a time, we present an alternative approach a Algorithm 2 which performs global optimization in batches, i.e. considering trips that fall into time windows a given size. The main idea is that trips (both starts and ends) in a window of T w are considered and bipartite graphs are created from the possible connections (both among the trips themselves and among available cars and trip starts and trip ends and available parking). Then a maximum matching calculated on these bipartite graphs will result in a globally optimal solution for the assignment problem in that time window. Repeating the process with a sliding time window gives the solution for the whole set of trips considered.
In more detail, we create three bipartite graphs: (1) G 1 , where edges connect trip end events to start events of later trips that can be reached from them; (2) G 2 , where edges connect currently parked vehicles to upcoming trip start events that can be reached by them; (3) G 3 , where edges connect trip end events to available parking spaces. Reachability is estimated using a dataset of estimated travel times between 11,789 intersections covering Singapore based on real traffic data including variation over a typical workday. The three graphs are created in three consecutive stages (G 1 , G 2 , G 3 ), each stage only including events that were not matched in the previous one: first, a matching is calculated among trip ends and starts in the time window under consideration (step 1 in Algorithm 2, lines 21-32). The result of this are direct connections among trips that only require temporary parking (handling the requirement for these temporary parking is done in step 6 in lines 85-95). Second, a matching among available cars and trip start events is performed (step 2, lines 34-51). Third, a matching among trip ends and available parking spaces is performed (step 4, lines 60-77). Trip start and end events which are not matched in any of the three stages are then satisfied by adding more cars and parking to the simulation, similarly to previous works [1,2]. This way, processing starts with zero cars and parking, creating only a minimal number of both over the course of processing all trips.
A main parameter in these estimations is r max , the maximum distance cars are allowed to travel without a passenger (i.e. "empty distance"). When creating each G i graph, only connections which include less than r max travel are included; this way, we can limit the extra distance traveled by the fleet of OVs, although at the cost of more missed connections, thus requiring us to add more cars and parking. We repeat the processing with several different values of r max , ranging between 500 m and 10 km.
Further parameters affecting the result are the batch time window T s and the look-out time window T w . Among these, T s is the time window in which trips are processed at a time, while T w (with T w ≥ T s ) is the time window in which trips are considered. This means that matching is performed for all trips in the larger, T w time window to result in a more optimal solution, while the solution is only accepted and processed in the smaller, T s window. Trips which fall outside this smaller time window are processed in the next steps of the algorithm; after each step, time is advanced by T s . A slight exception to this is matching trip start and end in steps 2 and 4. In these cases, matching is performed twice: first for all events in T w with processing the solution for those that fall in the smaller window T s . In the second step, the same matching is performed only for any trips remaining in the smaller T s window; the reason for this is to minimize adding more cars and parking spaces (i.e. prioritize serving events in the present instead of setting aside an excess amount of resources for events in the future). In practice, we ran the algorithm with several options for r max between 500 m and 10 km. We used T w = 15 min, while we explored the choices of 5 min and 10 min for T s . Algorithm 2 relies on several subroutines; among these, the functions for creating the bipartite graphs from a set of events are listed separately as Algorithm 3; furthermore, standard solutions are used for calculating matching on bipartite graphs such as the Hopcroft-Karp algorithm. A potential further addition is calculating weighted bipartite matching (i.e. minimum cost assignment problem) in each of steps 1, 2 and 4, using the connection distances as weights. This way, the solutions will attempt to minimize the extra travel taken by the fleet as well; we note that this version has significantly higher computational requirement, while resulting in somewhat better solutions.

Discrete and continuous space simulation
In the results displayed in the main text (Figs. 1 and 6), the above calculations were performed using a set of 4529 discreted locations ("nodes") as potential origins and destinations of trips. To better understand the relevance of this discretization, we also ran a modified simulation where each trip start and end event was assigned a random location independently in the neighborhood of the corresponding node (by adding a displacement to each coordinate, selected in a uniformly random way within [−167 m, 167 m]). Contrary to the main results, in this case, we assumed a simple Euclidean geometry, and a fixed average travel speed for OV operations that we varied between 10 km/h and 50 km/h. We were mainly interested in extending the simulation to smaller values of the r max parameter, where the discretization can become especially relevant. While r max < 500 m is less Algorithm 2 Stepwise matching algorithm for estimating fleet size and parking demand 1: T = { list of trips or trip chains } 2: r max = maximum distance that OVs are allowed to travel empty 3: T s = time window for trips to process at a time 4: T w = time window for trips to consider when performing matching (T w ≥ T s ) 5: N P = 0 parking spaces required 6: N C = 0 number of cars required 7: D tot = 0 extra travel distance 8: L P = { empty list for free parking spaces (along with timestamps when they become available) } 9: L C = { empty list for available cars (along with timestamps when they become available) } 10: S = { empty event list for start events } 11: E = { empty event list for end events } 12: for all t ∈ T do 13: separate t to start and end "events" 14: add these to S and E respectively 15: end for 16: order S and E by timestamp mark e and s as reserved (will be used in next iteration again, but not in the following steps)    Table S2: Results for fleet size, parking requirements and the ratio of the two for the bipartite matching methodology (main results in the main text, i.e. Fig. 1). for all x ∈ X s.t. t x ∈ [t 1 , t 2 ) and x was not reserved in step #1 of Algorithm 2 do 4: for all y ∈ Y s.t. t y ∈ [t 1 , t 2 ) and y was not reserved in step #2 of Algorithm 2 do 5: if t x + t(x, y) < t y then 6: add (x, y) edge to G 7: end if 8: end for 9: end for 10: return G 11: end function 12: function CreateGraphEnd(X, Y, t 1 , t 2 ) 13: G = empty bipartite graph 14: for all x ∈ X s.t. t x ∈ [t 1 , t 2 ) and x was not reserved in step #1 of Algorithm 2 do 15: for all y ∈ Y s.t. t y ∈ [t 1 , t 2 ) and y was not reserved in step #2 of Algorithm 2 do 16: if t x + t(x, y) > t y then 17: add (x, y) edge to G In Fig. S2, we compare results of this modified simulation using continuous geometry with the original results presented in the main text (as Fig. 1 -note that here the axes are reversed). We display the original simulation results as the "discrete" case (red points), along with the modified simulation results (for an assumed average speed of 50 km/h) as the "continuous" case (blue points). Furthermore, we display results with weighted matching in both cases as well (yellow and purple points). We also display an exponential fit to the results of the continuous simulation as black lines. This exponential form fits the results for the continuous space simulation quite well for the most of the range of results. It also fits the results of the discrete case nicely for r max ≥ 500 m. We speculate that the deviation of the discrete case results for smaller r max (larger fleet size and smaller extra VKT) is an effect of discretization: for small r max values, the only possible connection will be between trips ending and starting at the same node for an increasing share of cases.
In Fig. S3, we compare results for different values of the assumed average travel speed in the continuous space case. We see that these results are very similar, with a "saturation" effect present for small fleet sizes (large r max ).

Vehicle shareability networks
The vehicle shareability network provides a computationally efficient way to calculate an optimal dispatching strategy for a given list of trips, resulting in minimum fleet size or minimum total connection distances between trips [3]. In this approach, a network is constructed from the trips where each trip is a node, and two trips are connected by a (directed) edge if the start of the later trip can be reached from the end of the earlier one. This way, each edge represents a trip pair that can be served consecutively by the same vehicle. Each trip can have several incoming and outgoing edges as there can be several different options of which connections to choose at the end of a trip. Notably, trips separated by large time intervals can always be connected by an edge; this way, the shareability network can be huge, scaling with the square of the number of trips. We limit the network size and computational complexity by setting a maximum threshold on the connection time as well. Since we expect that a good dispatching strategy will prefer short connections, reasonable values of maximum connection time will only slightly affect the solution. Having constructed this shareability network, we can find an optimal dispatching strategy by finding a minimum path cover on it. Since the shareability network is a directed acyclic graph, finding a minimum path cover can be achieved efficiently (in polynomial time) by converting the problem into finding a maximum matching in a bipartite graph [4,5,3]. This minimum path cover can then be used as a dispatching strategy where each path is interpreted as a chain of consecutive trips   to be served by the same vehicle. Thus, the number of vehicles needed is at most the number of paths found. We note that constructing the shareability network is equivalent to considering the G 1 graph in the previous method, but including all trips during the day (instead of only those in a limited time window T w ) and further limiting connection time instead of connection distance; this will result in some variation during the day due to variations in traffic speed.
Having identified trip chains in an ideal dispatching strategy, we still need to assign parking to vehicles at the start and end of chains and inbetween consecutive trips. Furthermore, since demand fluctuates during the day, some trip chains can be distinct in time, thus possible to serve with the same vehicle (if separated by more than the minimum connection time). For these reasons, we continue by using the trip chains as the input of any of the previously described methods ("bipartite matching" or "greedy heuristic", i.e. Algorithm 2 or 1) to arrive at a final dispatching strategy that includes assignment of parking as well.
While the result of this computation will be optimal in terms of fleet size, it can result in excessive extra travel as connection distance between consecutive trips in a chain is not part of the optimization. This problem is slightly mitigated by allowing only relatively short connection times, thus limiting connection distances as well. Furthermore, we can set an explicit limit on connection distances as well. An other approach that we implemented is again performing a weighted maximum matching after converting on the trip shareability network, giving a solution which minimized total connection distance as well.
Looking at the results in Fig. 6 in the main text, we see that the results of this approach are mostly comparable with the previous ones; nevertheless, the combination of weighted shareability networks with the bipartite matching approach is able to significantly outperform all the other methods, resulting in 85% reduction in fleet size and parking demand at a cost of only 15% extra VKT as opposed to the results obtained by performing only unweighted bipartite matching, which achieves similar reductions at the cost of 25% extra VKT. This outlines that performance in realistic conditions will be limited by operational constraints, i.e. the fact that trip requests are generally not known in advance as required to construct shareability networks for the whole day and perform a global optimization.

Actual length of connecting trips
While r max limits the length of connecting trips (either between consecutive trips or between trip start or end points and parking), this is only the maximum possible value; actual distances traveled for individual trips will likely be shorter. We display statistics about these in more detail in Table S3.

Incorporating ride sharing
A potential way to compensate for the extra travel of an AV fleet is to encourage people to share rides. We use the methodology of Santi et al. [6] to estimate the potential for shared rides under the assumption that x percentage of people would be willing participate, with x varying between 0% and 100%. Not surprisingly, we find that a large percentage of trips are shareable. We display the shareability ratio as a function of people willing to share (similarly to Ref. [7]) in Fig. S4. We see that if everyone was willing to share, over 97% of all trips could be actually shared. Even if only 10% of trips passengers are willing to share, the shareability ratio is still above 70%. For each case, we then produce merged trips that represent serving two original trips wherever sharing is possible. We then repeat our analysis for this set of combined trips (i.e. merged trips and original trips that cannot be shared or passengers are unwilling to share) and display the results as a function of x and r max in Figure S5. We see that as r max gets larger (and dispatching gets more efficient in general), a larger x share of shared rides are required to compensate for added VKT of a shared fleet.  Figure S4: Shareability potential of trips. Ratio of trips actually shareable as a function of the ratio of trips where passengers would be willing to share their ride. Shareability ratio is relative to the trips available for sharing. Figure was created with Gnuplot, version 5.2, available at http://gnuplot.info.

Estimating short-term parking requirements
Beside a change in the total number of parking, a further important consideration is a change in the use of parking on a local level. If people are willing to change from using private cars to OVs, actual parking facilities will be less important from the users' point of view (i.e. they will not need to be easily accessible for average users), while the provision and design of adequate pick-up, drop-off and waiting locations will become increasingly important. Furthermore, in a future scenario with autonomous vehicles (AVs) we expect users' expectations to change regarding the start of their trips: since the cost of waiting can decrease significantly as it no longer includes a driver's salary, users might prefer to order a vehicle in advance and have the vehicle wait for them instead of having to wait themselves. While this increases convenience for passengers, booking trips some time in advance can be beneficial for operators as well, since this will allow the use of a dispatching algorithm that aggregates requests in time, allowing more efficient solutions. This way, operators might change their pricing structure to incentivize this behavior as well. Vehicles waiting for passengers in pick-up locations could add a non-negligible amount of demand for temporary parking spaces.
In the following, we use the general term waiting area for parking spaces that need to be in locations easily accessed by passengers. We envision that these locations will include cars waiting for passengers who have not arrived yet, and also facilitate actual pick-ups and drop-offs. The actual spatial layout of such areas is an important research question by itself, a detailed investigation of which is beyond the scope of the current work. E.g. in the case of dense downtown locations, each building might provide such an area at its entrance (as is often typical for hotels or some office buildings nowadays), or the city could provide these in a manner similar to taxi stands. Some of these waiting areas could also be provided in parking garages, in locations that are most conveniently accessible on foot. In areas with less traffic, a waiting area might serve multiple buildings together, or waiting areas might be curbside, either in place of current curb parking or part of a traffic lane. Nevertheless, in the following, we assume that waiting areas are made up of discrete "parking spaces" as well, and need to be counted in totality. Also, in line with the rest of the analysis, we note that trips can start and end at a set of discrete "nodes"; we then assume that each node has a certain number of waiting spots that can only be used for trips that start at that specific node.
To estimate of the number of waiting spots needed, we then consider that vehicles have to arrive exactly T W time before the start of each trip. We vary the T W parameter between 1 s and 10 min. Low values of T W then show the absolute minimum needed to handle pick-ups, while larger values account for presumed uncertainity in trip start times.

Absolute demand for short-term parking
Formally, for a trip t that start at node n s at time t s , we require the car serving it to be parked at the waiting area at n s in the interval [t s − T W ; t s ]. Based only on this consideration, we can calculate the number of waiting baseline r max = 500m r max = 1km r max = 2km r max = 5km r max = 10km r max = unlimited Figure S7: Pick-up demand (i.e. parking spaces used for short-term waiting) relative to the parking demand estimated previously as a function of the assumed extra wait time (T W ). Absolute numbers are the same for each curve, reaching about 80,000 parking spaces for T W = 10 min, but these correspond to larger and larger relative share. The curves start from T W = 1 s, where the pick-up demand is the sum of the maximum number of trips starting at the same time at each discrete location, i.e. about 8,000 parking spaces. Figure  cars at each node at any time as where the summation in s includes all trip start events (refer to Table S1 for notations), δ 1 is a 1-width Dirac-delta function, while δ ns,n is the usual Kronecker delta symbol, defined as: Using these, we can formally calculate the total demand for waiting areas as where the summation is done over all discrete nodes in the simulation. The result of this calculation is displayed in Fig. 3 (left panel) in the main text.
Since we calculate the maximum number of waiting cars per nodes (i.e. discrete locations), the discretization of space can affect the results for N total W . Clearly, if all trips started in distinct locations, the number of parking places for waiting cars would equal to the number of trips (1.44 million in our case). Having multiple trips start at the same discrete locations (nodes) allows them to share the same waiting area if their waiting times do not overlap. This way, using only 4529 discrete nodes as trip start and end locations can underestimate pick-up demand. To overcome this limitation, we repeated the previous estimation after splitting each node into N s virtual locations and assigning trips to start at any of these at uniformly random. In Fig. S6 we display pick-up demand (N total W ) estimated in these scenarios as a function of the total number of discrete nodes with at least one trip starting there (we note that the number of actual nodes is not necessarily N s × 4529 since some nodes have only a few trips starting there, so they do not generate N s separate nodes). While it is unclear how many discrete pick-up locations will be needed in the future, a reasonable upper bound is the total number of buildings in Singapore. Exploiting the fact that in Singapore, every building is assigned a unique postal code, we can estimate the total number of buildings based on a database of postal codes. We downloaded the list of unique post codes from the API of OneMap.sg [8] using the scripts published at [9], finding a total of 121,363 unique postal codes. This way, we estimate that the upper end of the results presented in Fig. S6 show a realistic upper bound on the pick-up demand.

Combined estimate of total parking demand
While our previous analysis gives an estimate of pick-up demand by itself, we are also interested what is the combined effect on parking demand in our estimate based on trips. To do this estimation, we run a modified version of the main estimation (Algorithm 2) that takes into account the requirement for vehicles to wait for passengers before the start of trips. We evaluate two distinct scenarios regarding the use of waiting areas: 1. Each location has a separate waiting area (i.e. pick-up locations) beside a normal facility for long-term parking (e.g. a parking garage). All vehicles that are waiting to pick up a passenger are required to park in the waiting area, while vehicles are not allowed to park there long-term. The size of this area is determined over the course of the simulation, i.e. we do not constrain it, but record the highest number of vehicles in the waiting area of each node at any time.
2. Instead of reserving a separate area only for vehicles waiting for a passenger, waiting areas can be used for long-term parking as well. We further assume that all vehicles are essentially interchangeable, thus passengers need not be assigned any specific vehicle, but will be able to start their trip in any of the vehicles available in the waiting area. This way, we do not have to explicitly divide parking into shortterm and long-term facilities during the course of the simulation, but assume that vehicles always occupy the waiting area first and only park in the long-term facilities if the waiting area is full. For each discrete location, we record the maximum number of cars simultaneously waiting for passengers as the estimated demand for short-term parking. In this case, we can expect more optimal solutions in terms of combined (short-term and long-term) parking demand.
We note that the actual pick-up demand (parking spaces needed to accommodate waiting vehicles) will be the same in both scenarios, as the number of vehicles waiting at each node is only determined by the sequence of trips starting there and the T W parameter, as estimated before. In the first scenario, this is added to the long-term parking demand, while in the second scenario, there can be an overlap, thus the total increase will be potentially less than the total need for short-term parking. In both cases, there is a potential increase in fleet size since vehicles need to spend some of their time waiting; in turn, this can add to long-term parking requirements as well.
Again, we vary T W between 0 and 10 minutes, with T W = 0 representing the original analysis without pick-up demand. Here in Fig. S8 we present the comparison among the two scenarios, while in Fig. S9, we show the relative share of short-term parking in scenario and the absolute number of short-term parking spaces. In Fig. S10, we display the change in fleet size in these cases.
Not surprisingly, scenario #1 results in higher increases in total parking needs as there parking designated as short-term cannot be reused for long-term parking purposes. In either case, our results emphasize the importance of designing pick-up and short-term waiting areas in an efficient way.

Effect of short-term parking policy of parking ratio
As illustrated in Fig. S1, the processes used to assign vehicles to trips and parking (Algorithm 2) has three steps where maximum matching is performed to optimize utilization of vehicles and parking. First, the end of trips are matched directly to start of trips (#1); this step will ensure maximum utilization for existing vehicles. Since a vehicle assigned to a new trip might arrive too early, parking is always reserved at the start node of the new trip, even if we are not counting short-term parking separately. After this step, the remaining trip end  and start events are matched to available parking and idle vehicles and respectively (#2 and #3). Remaining trip end and start events are then satisfied by creating new vehicles and parking. Including the first step (trip matching) can help in finding more optimal solutions, since after finishing a trip, vehicles need not travel to parking in potentially distant locations, but can serve any new trip request close by. We explored multiple options regarding how parking is accounted for. In the original estimation, parking is not differentiated between the first process (trip matching, which results in essentially short-term parking demand) and the second and third one (which matched trips to long-term parking). Thus, the first process will result in parking created at nodes where trips typically start (and are matched to previous trips ending in the neighborhood). These parking spaces can then be used for long-term parking as well in later steps of the estimation. Results from this option are presented as "original results" in Figs. S11 and S12 and have a fairly constant ratio of parking to vehicles regardless of r max .
The orignal method (Algorithm 2) can be easily modified to not include the possibility for trip connections (case #1). In this case, whenever a trip is finished, the car serving it needs to find (long-term) parking, while new trip can only be served by cars that are idle (parked). This removes the requirement that parking is available at the trip start nodes. At the same time, this can result in unrealistic dispatching, especially if cars travel to far away parking lots instead of serving passengers closer by. Also, this case has the potential of underestimating parking, since all short-term parking requirements are neglected. This case is presented in Figs. S11 and S12 as the solution "without trip connections". In this case, the ratio of parking and cars starts out as constant as well and then starts to decline above r max = 2 km, reaching almost one parking per car already at r max = 10 km. This comes at the expense of further increase in VKT (between 10%-15% more than in the previous case). The tradeoff between parking and VKT however stays on the same trend as in the previous case (see Fig. S12).
An alternate way to manage parking demand is to explicitely separate parking into short-term and long-term categories as we did in the analysis considering extra wait times at the start of trips (T W > 0 cases). Here, we set T W = 0 (i.e. cars normally do not have to wait), but require that parking that happens when connecting trips is accounted as short-term parking and is completely separted from long-term parking (i.e. cannot be used for long-term parking). This is presented as the "T W = 0" case in Figs. S11 and S12, with separate plots showing only the demand for long-term parking and the combined parking demand. If we only consider long-term parking, the ratio of parking to cars again approaches 1 (but only in the r max = unlimited case). If we consider combined parking demand, the ratio stays above 2 up to r max = 5 km and starts to decrease after. Even for r max = 10 km, it is still just around 1.7, indicating that decreasing the ratio of parking to cars below 2 while realistically accounting for parking can only happen with high r max search radius, i.e. at the expense of large increases in VKT.
We emphasize that in all cases, despite the further decrease in parking demand and increase in VKT, the relationship between these two quantities is still well explained by the exponential form found in the main text of the paper (shown as a black line in Fig. S12).

Estimating current parking supply
We base the estimation of the current parking supply on minimum parking requirements and the need to find parking for each trip in the trip dataset we use. In more details, we arrived at this estimate of current parking supply with the following procedure: for housing constructed by the Housing Development Board of Singapore (HDB), we distribute the total number of parking reported officially evenly among all such apartments in Singapore. The aggregate number available from the government source [10] is 640,188, while the SimMobility database includes 1,188,649 HDB housing units in total, giving on average 0.5386 parking spaces per unit. We note that parking managed by the HDB is often used for multiple purposes, especially for retail as some of these are strategically positioned in local town centers and offer access to the general public. For other types of development, we use the minimum parking requirements published by the Land Transport Authority (LTA) that was valid for the period before February 2019 [11]. We note that LTA imposed significant changes from February 2019, lowering minimum requirements and establishing limits on maximum allowed parking for new developments [12]. Since the buildings considered in this work were completed before this date, we used the older standard. Based on this, for private housing (i.e. housing not constructed by the HDB), we assume one parking space per unit, giving a total of 321,974. Beside housing, we have four use categories for buildings in the SimMobility database: office, retail, factory and other with aggregate floor areas of 7.2, 5.2, 34.9 and 23.6 million square meters respectively. For these, we use minimum parking requirements that are most appropriate, resulting in a total of 22,458 parking spaces related to office use, 24,737 parking spaces related to retail, 77,577 parking spaces related to factory use and 78,829 parking spaces for other uses. Furthermore, we have 25,740 parking spaces managed by the Urban Redevelopment Authority (URA), mostly on-street parking and some parking lots [13]. Adding these up, we have a total of 1,191,503 parking spaces, giving a ratio of 1.762 parking spaces per person for our simulated population. We display a summary of different types of parking Table S4. Among the cases presented here, "original results" refers to the bipartite graph approach presented as the main results in the paper ( Fig. 1 and "bipartite matching" in Fig. 4); "without trip connections" refers to the same methodology, but omitting direct matching between consecutive trips (cars always have to return to parking at the end of a trip, new trips can only be matched to cars that are already parked); the "T W = 0" cases refer to the estimation that has a strict separation of short-term parking, but with zero extra wait time; in this case, short term parking is only used by cars that are directly matched between the end and start of consecutive trips. In this case, "only LT" includes the count of only long-term parking demand, while "ST and LT" includes the sum of long-term and short-term parking demand. Figures were created with Gnuplot, version 5.2, available at http://gnuplot.info. The analysis above provides an approximate lower bound on parking provision, since the number of spaces for many uses is estimated based on minimum parking requirements; limits on maximum parking in Singapore were established since February 2019, and thus do not apply to the buildings considered in our study yet [12]. In accordance with the goverment's aim to be "car-lite", minimum parking requirements in Singapore are quite low, up to 5 to 10 times lower than those in use in the USA [14] for certain commercial uses. However, some developers may have voluntarily provided parking in excess of these minimums. Therefore, we adjust the distribution of parking spaces upwards based on trip data from SimMobility. We do this by performing a simplified estimate for the current trips made in private cars, where we require everyone to be able to park at the start and end location of their trips exactly (similarly to Algorithm 1 in our previous work [1], but with zero search radius). We note the trip start and end locations were aggregated to a set of 4,529 discrete locations, which can be interpreted as potential locations for car parks. To combine these results with the previous estimation, we map the building locations to all possible trip start locations in a 250 m radius around them, and distribute the estimated parking in a way that minimizes the discrepancy between the two results. After this, for each location, we take the larger value from the two estimates as our final estimate on parking there. The main idea behind this is to adjust estimates in locations where basing them only on minimum parking requirements gives unrealistically low values; this is the case especially for office buildings in the CBD area, which is the target of a significantly high number of commuting trips. After these adjustments, we arrive at a number of 1,369,576 parking places, or 2.02 per person in our simulation. We note that this is still a relatively low number, thus we can assume that this is a lower bound on the real number of parking in Singapore. We display the spatial distribution of parking spaces obtained with this method in Fig. S13.

Spatial distribution of parking demand
Our analysis allows us to investigate not only fleet size and aggregate parking needs, but also the spatial distribution of current parking supply and future demand if OVs are adopted. We display these distributions in Fig. S13 (estimation of current supply) and S14 (estimation parking dmenad of OVs). Furthermore, we display the difference between the two (i.e. the possible savings due to adoption of OVs) in Fig. S15. The main difference is that while the current distribution of parking spaces is quite spread out over the dense areas of Singapore, with significant parking provisions for residential areas, the parking demand of the OV fleet is highly concentrated in the CBD, especially for low values of r max with a few smaller peaks in residential centers in Punggol, Woodlands, and Pasir Ris.
A main contributing factor to this spatial asymmetry is the high concentration of jobs in the CBD, thus the imbalance of commuting flows going there. Increasing r max results in a significant decrease in the parking demand in the city center in our estimation; this is understandable, since a higher r max allows OVs bringing workers to the centre to choose a parking location during the day in a much larger area. On the other hand, in residential areas, there is a potential oversupply of parking even in the current situation, with a total of 962 thousand parking spaces currently supplied for primarily residential use, or 1.42 residential parking spaces per private car user. We note that many of these parking spaces are actually usable by the general public,  Office and retail uses have different parking requirements in three city zones. Zone 1 is defined as the central business district and its vicinity, zone 2 is defined as the area within 400 m distance from any rapid transit station, while zone 3 is the rest of the city. We used the "retail" category for any commercial establishment, while the minimum parking requirement for the "factory" and "other" categories were determined as the average of multiple relevant categories.  Figure S13: Spatial distribution of parking spaces as estimated from the SimMobility building and trip database. The total number of parking spaces is 1.37 million. Resolution of the grid displayed is 1 km × 1 km similarly to Fig. S14, i.e. the numbers given are parking per square kilometer. Note that the color scale is the same as in Fig. S14. Map data by OpenStreetMap contributors, available under the ODbL License [15]. Map tiles by Stamen design, available under CC BY 3.0 [16]. Figure generated by using the ggmap [17], and colorspace [18] R packages. Note that the color scale on all panels is the same, along with the colors used in Fig. S13. All grid cells have less than 10,000 parking spaces with the exception of one outlier in the central business district that has 24,723, 24,313, 21,326 and 11,577 parking spaces for r max = 500 m, 1 km, 2 km and 5 km respectively. Map data by OpenStreetMap contributors, available under the ODbL License [15]. Map tiles by Stamen design, available under CC BY 3.0 [16].  Figure S15: Spatial distribution of savings in parking demand, i.e. the difference between the spatial distributions displayed in Figs. S14 and S13. Map data by OpenStreetMap contributors, available under the ODbL License [15]. Map tiles by Stamen design, available under CC BY 3.0 [16]. Figure generated by using the ggmap [17], and colorspace [18] R packages.
i.e. parking managed by the Housing Development Board (HDB) of Singapore. Looking at the differences in Fig. S15, we see that most areas can be expected to experience a significant decrease of parking demand; this is most prominent in dense residential areas such as Bedok, Toa Payoh, Ang Mo Kio or Clementi, where the decrease in demand is already significant for low r max values. A significant amount of parking in these settings is provided by the HDB as surface parking lots and separate parking garages, thus repurposing the land area taken up by these could be more easily achieved than underground parking facilities found with many commercial and private residential buildings. This is even more evident when looking at actual parking use during the night and day (see Fig. S16 and the Supplementary Videos provided displaying the utilization of parking during the day), showing a significant difference in the use of parking , with night usage spread in residential neighborhoods across Singapore and day usage concentrated in the CBD and a few areas with a high number of workplaces such as the Nanyang Technological University Campus, Tuas or Changi. : Spatial distribution of actual parking usage at night (4 AM, in the left column) and midday (2 PM, in the right column) for r max = 500 m, 2 km and unlimited in the top, middle and bottom rows respectively. It is clear that parking usage shows a large difference during night and day, in accordance with the imbalance of commuting flows. In theory, cars could go back to park in residential neighborhoods during the day, at the cost of even more empty miles traveled (see Section 3.3 and Fig. S11 for a discussion of this in more detail). Map data by OpenStreetMap contributors, available under the ODbL License [15]. Map tiles by Stamen design, available under CC BY 3.0 [16]. Figure generated by using the ggmap [17], and colorspace [18] R packages.