Risk-Aware Intelligent Dispatching for Ride-Hailing Systems Using Dual-Graph Attention Forecasting and Unbalanced Optimal Transport

Abstract

Ride-hailing dispatching with mixed on-demand and advance requests faces several challenges: platforms must respond to immediate requests, preserve flexibility for upcoming advance requests, and consider how each accepted request changes post-drop-off vehicle positions and subsequent service opportunities. Existing studies usually deal with demand forecasting and dispatching separately. Forecasting models mainly optimize order-count errors, and dispatching models usually focus on pickup distance, revenue, and waiting time, with limited consideration of destination opportunity and risk. To alleviate this prediction–dispatch disconnection, this paper proposes a risk-aware online dispatching method. The method develops a closed-loop context-aware spatio-temporal multi-task network (CC-STMT) using a physical-distance graph, a functional–semantic graph, and en-route supply feedback to estimate demand intensity, low-opportunity risk, and demand dispersion. Then, the demand-prediction-guided optimal transport matching (DP-OTM) method, which embeds destination opportunities and risks into the vehicle–request matching cost to generate an executable one-to-one allocation, is designed. Compared with the best-performing non-CC-STMT baseline for each metric, CC-STMT reduces MAE by 1.38%, 1.65%, and 7.65% and RMSE by 2.70%, 3.92%, and 5.14% in NYC, Chicago-A, and Chicago-B, respectively. Compared with Base-UOT, DP-OTM reduces future low-opportunity drop-offs and improves post-drop-off destination opportunity. These results support destination-aware dispatching in public-data simulations.

1. Introduction

Ride-hailing platforms must assign dynamic passenger requests to a limited and spatially distributed vehicle fleet. Unlike static assignment problems, each ride-hailing decision affects not only the current pickup distance, waiting time, and revenue but also the zone in which the vehicle becomes available after completing the trip. Therefore, online dispatching should account for both immediate service efficiency and the future service opportunity associated with request destinations.

This issue becomes more important when on-demand and advance requests exist together. On-demand requests require rapid responses, and advance requests reveal future pickup demand ahead of time. If advance requests reserve vehicles too early, current service capacity may be reduced; if their future information is ignored, the system may face insufficient supply near the requested pickup time. Moreover, different accepted requests send vehicles to different destination zones, where future demand opportunities and low-opportunity risks can vary substantially.

Existing studies have provided useful foundations for ride-hailing forecasting and dispatching. Demand forecasting studies have modeled temporal dependence, contextual variation, and graph-based spatial relations in taxi and ride-hailing demand [1,2,3,4,5,6,7]. Recent transportation studies also show that predicted mobility states can support downstream scheduling or operational planning [8,9]. In parallel, online matching, relocation, reinforcement learning, and rolling-horizon optimization have been explored for ride-hailing and shared-mobility dispatching [10,11,12]. Prediction-guided dispatching studies further indicate that forecasting information can provide operational value when it is aligned with downstream matching or relocation decisions [13,14]. However, forecasting and dispatching are still often loosely connected: prediction models are usually evaluated by demand-count errors, whereas dispatching models mainly optimize current pickup, revenue, and waiting indicators. Especially when post-drop-off service opportunity and low-opportunity risk need to be considered, the direct conversion from predictive signals to destination-aware matching costs is insufficient.

Motivated by this issue, we design an online dispatching method that considers prediction and matching together rather than treating them as two separate steps. The prediction part, the closed-loop context-aware spatio-temporal multi-task network (CC-STMT), uses both geographic proximity and functional similarity between zones while also considering vehicles that are already carrying passengers and will soon re-enter the system. Based on these inputs, it estimates not only future destination demand but also whether a zone is likely to become a low-opportunity area after drop-off. These estimates are used by the demand-prediction-guided optimal transport matching (DP-OTM) method to adjust the vehicle–request matching cost. In this way, a request is not evaluated only by its current pickup distance or fare but also by the expected service condition at the destination. The final matching problem is solved with unbalanced optimal transport and then converted into feasible one-to-one dispatching decisions.

We evaluate the framework by constructing mixed requests from public ride-hailing trip records in New York City and Chicago. Experiments are conducted in three settings: NYC, Chicago-A, and Chicago-B. The results show that CC-STMT improves forecasting accuracy, and DP-OTM reduces low-opportunity drop-offs while improving post-drop-off destination opportunity in the tested public-data simulation setting.

The main contributions of this paper are as follows:

• A closed-loop prediction–dispatching framework is proposed for mixed on-demand and advance ride-hailing requests. It transforms regional forecasting results into online matching costs. It also feeds vehicle landing states after completed requests back into later forecasting inputs.
• A forecasting model, CC-STMT, is developed. It combines a physical-distance graph, a functional–semantic graph, demand-gated speed denoising, en-route supply feedback, and ZINB-based sparse-count modeling. The model predicts future request demand and provides predictive signals for destination opportunity and low-opportunity risk in dispatching.
• An online dispatching method, DP-OTM, is designed. It considers pickup distance, request revenue, waiting priority, destination opportunity, and destination risk in the vehicle–request matching cost. Executable dispatching results are then generated through an unbalanced optimal-transport prior and a linear assignment step.

The remainder of this paper is organized as follows: Section 2 reviews related studies. Section 3 introduces the proposed prediction–dispatching framework and experimental protocol. Section 4 reports the experimental results. Section 5 discusses the findings, practical implications, and limitations. Section 6 concludes this paper.

2. Related Work

2.1. Demand Forecasting for Ride-Hailing Systems

Travel demand forecasting provides an important basis for capacity allocation, fleet management, and online dispatching in ride-hailing platforms. Rather than being a single time-series modeling task, ride-hailing demand forecasting involves several interrelated requirements, including temporal-dependence modeling, regional interaction representation, contextual feature integration, and the production of outputs that can support downstream operational decisions. Safikhani et al. [1] used generalized space–time autoregressive models to characterize taxi-demand dependence across regions in New York City. Faghih et al. [2] modeled taxi demand with regression and ARMA errors, emphasizing the role of temporal autocorrelation in mobility demand series. Markou et al. [15] further incorporated time-series and textual information for multi-step-ahead taxi-demand prediction. These studies provide explanations of temporal and spatial dependence, although their ability to represent the relations between nonlinear background effects and high-dimensional regions is relatively limited.

Subsequent studies have introduced richer feature representations and neural temporal structures to describe nonlinear demand variation. Luo et al. [3] developed a multi-task deep learning model for short-term taxi-demand forecasting that considers spatio-temporal dependence across regions. Gao et al. [4] proposed a CNN-ATTBiLSTM model for online car-hailing demand forecasting by combining convolutional feature extraction, bidirectional temporal modeling, and attention mechanisms. Hassanzada et al. [16] explored wavelet decomposition for network-wide traffic prediction, showing that multi-resolution temporal representations can help describe traffic fluctuations. Chiang et al. [17] studied short-term traffic-flow prediction using inter-day and intra-day strategies, highlighting the need to distinguish different temporal regularities in traffic series. These studies improve the representation of temporal variation and nonlinear demand patterns, but the resulting predictions are still often evaluated mainly as forecasting targets.

Recent transportation studies further show that forecasting becomes more operationally meaningful when connected to downstream mobility decisions. Ji et al. [8] proposed a GCN-AM-LSTM-based bus passenger-flow prediction and intelligent scheduling framework, in which passenger-flow forecasts support dynamic departure-interval adjustment and stop-skipping decisions. Mkrtchian and Gorodnichev [9] proposed PTSTG, a patch-based transformer–graph framework that combines patch-level temporal encoding with learned spatial coupling for traffic forecasting. Liu et al. [18] also reviewed how machine learning informs ride-hailing services, showing that prediction tasks are closely related to platform-level operational decisions. These studies suggest that prediction outputs can have value beyond accuracy evaluation. For ride-hailing dispatching, however, the predictive information required by the matching process is not limited to future order counts. A dispatching model also needs destination-related information, such as where a vehicle will become available after completing a candidate request and whether that destination is likely to provide subsequent service opportunities.

2.2. Graph-Based Spatio-Temporal Modeling

Ride-hailing demand exhibits clear spatial dependence. Urban service areas are usually represented by irregular spatial units, such as taxi zones, community areas, census tracts, or traffic analysis zones, rather than by regular grids. The relationship between regions is determined not only by geographical proximity but also by road accessibility, land-use structure, functional similarity, and historical mobility patterns. Therefore, spatial modeling for ride-hailing systems needs to represent multiple types of regional relations instead of relying on a single notion of adjacency.

Graph-based models provide a natural way to represent such irregular spatial relations. Jiang and Luo [5] reviewed graph neural networks for traffic forecasting and showed that graph structures are widely used to model non-Euclidean relations among roads, sensors, and urban regions. Bai et al. [6] developed A3T-GCN by combining attention mechanisms with graph convolutions to capture temporal and spatial dependence in traffic sequences. AGCRN learns adaptive graph structures and node-specific patterns from data, reducing the dependence on manually specified adjacency matrices [7]. These studies indicate that graph construction is not only a technical detail but also a modeling assumption about how information propagates across urban regions.

Recent studies have further expanded spatial representation from fixed physical adjacency to adaptive, functional, and hybrid graph relations. Nair et al. [19] used graph-based spatio-temporal networks for traffic-speed prediction over road-network structures. Fang et al. [20] proposed a dual-view recurrent graph convolutional network for metro passenger-flow prediction, in which functional clustering is used to represent different views of station similarity. Cui et al. [21] proposed DG-STMTL, a graph convolutional multi-task spatio-temporal traffic forecasting model that shares representations across related traffic tasks. These works provide useful foundations for representing complex urban spatial relations. Nevertheless, most graph-based forecasting models still use spatial representation primarily to improve prediction accuracy. In destination-aware ride-hailing dispatching, graph-based representations also need to support the evaluation of post-drop-off locations and subsequent service opportunities, because each assignment changes the future spatial distribution of vehicle supply.

2.3. Online Dispatching and Dynamic Vehicle Matching

Vehicle dispatching is the core decision-making process for ride-hailing platforms, and its goal is to form executable matches between dynamic requests and a limited supply of vehicles. The simplest operational strategy is nearest-vehicle matching, which assigns a request to the vehicle with the shortest pickup distance or estimated arrival time. This type of method is computationally efficient and easy to deploy, but it is usually myopic, focusing mainly on current requests and vehicle positions.

Optimization-based studies have attempted to reduce this myopic behavior by considering multiple vehicles, multiple requests, and rolling-decision windows. Gao et al. [10] proposed a model-based modular approach for online relocation and matching in ride-hailing systems, separating the operational process into coordinated modules for real-time service. Chen et al. [12] used rolling-horizon optimization for dynamic fleet management of shared autonomous vehicles, allowing decisions to be repeatedly updated as the system state evolves. Huang and Xu [22] studied adaptive request assignment with large-neighborhood search for shared autonomous mobility services, showing that assignment decisions should be coordinated with operational constraints and future system states. These approaches improve dispatching decisions compared with purely local matching, although their objective functions often remain centered on current pickup, service, or relocation costs.

Learning-based dispatching studies further model ride-hailing dispatching as a sequential decision problem. Liu et al. [11] proposed a deep reinforcement learning approach for vehicle dispatching on online ride-hailing platforms. Cordeiro and Pitombeira-Neto [23] investigated asynchronous dynamic vehicle dispatching using deep reinforcement learning. Si et al. [24] developed a multi-agent hierarchical reinforcement learning framework for vehicle dispatching and routing in on-demand intercity ride-pooling services. Other studies have examined matching timing, matching-radius optimization, cross-region dispatching, sparse-demand scenarios, and dispatching strategies that complement public transport [25,26,27]. Yu et al. [28] investigated electric autonomous ride-hailing operations through asynchronous learning, while Wang et al. [29] studied dispatching optimization under concentrated supply and sparse demand. Tiwari et al. [30] considered ride-hailing dispatching and matching strategies that prioritize and complement public transport use. These studies show that online dispatching can benefit from optimization, learning, and prediction. However, many dispatching models still evaluate candidate assignments mainly from the perspective of current service performance, while the future service opportunity of the request destination after trip completion is not always explicitly represented in the matching objective.

2.4. Mixed On-Demand and Advance Requests

On-demand and advance requests differ mainly in how their timing information enters the dispatching process. An on-demand request usually becomes actionable as soon as it appears, because delaying its assignment directly increases the passenger’s waiting time and may reduce the chance of service. Unlike an on-demand request, an advance request is known before its intended pickup time, but this early visibility does not necessarily mean that a vehicle should be committed immediately. Reserving capacity too early may weaken the system’s ability to serve current demand, whereas activating the request too late may leave insufficient time to arrange a feasible pickup. Therefore, the main issue is not simply whether an advance-request is accepted but when it should be released into the executable matching pool.

Several studies on ride-hailing and shared mobility have considered related timing and rolling-decision issues. Bao et al. [25] studied the timing of matching decisions for ride-hailing and ride-pooling services using deep reinforcement learning, showing that the moment of assignment can significantly affect system performance. Chen et al.’s [12] rolling-horizon fleet management framework also reflects the value of repeatedly revising decisions as future information becomes available. Huang and Xu’s [22] adaptive request-assignment study further indicates that request allocation should be coordinated with future system states rather than being treated as a purely instantaneous decision. These studies support the use of activation or rolling-update mechanisms in dynamic request assignment.

In public-data studies, however, advance-request modeling is constrained by the fields available in released trip records. Many public ride-hailing datasets contain completed pickup and drop-off information, trip duration, distance, and fare but do not include true reservation creation times, lead times, cancellations, driver acceptance, or dynamic pricing. As a result, mixed-request experiments based on public data usually need to construct advance-request streams through transparent rules and clearly define their simulation boundaries. This does not make controlled algorithm comparison invalid, but it means that the results should be interpreted as public-data-based simulations rather than direct reconstructions of a commercial reservation system. It also implies that advance requests should not be simplified as requests that immediately reserve vehicles upon visibility; instead, their early visibility and executable commitment need to be distinguished carefully.

2.5. Prediction-Guided and Risk-Aware Dispatching

Prediction-guided dispatching introduces future demand or supply–demand state information into current dispatching decisions. Unlike a myopic dispatching method that only uses the current vehicle and request states, a prediction-guided dispatching method can also consider the likely service condition after drop-off, such as whether the destination will provide enough subsequent demand for the assigned vehicle. Peng et al. [13] proposed an uncertainty-aware probabilistic travel-demand-prediction method for mobility-on-demand services, showing that demand uncertainty can affect operational planning. Guo et al. [14] used spatio-temporal prediction to support multi-strategy ride-hailing dispatching, demonstrating the operational value of aligning forecasting with dispatching decisions. These studies indicate that forecasts can be useful for dispatching, but the form in which prediction results enter the matching objective remains important.

Many prediction-guided approaches mainly use future demand intensity as an index of regional attractiveness. This is useful but incomplete for destination-aware dispatching. Future demand intensity indicates how many requests a region may generate, but it is not entirely equivalent to the service risk after a vehicle drops off there. Sparse-demand areas, structural-zero demand, demand dispersion, and prediction uncertainty can all affect subsequent service opportunities. Therefore, a dispatching model that uses only mean demand may fail to distinguish stable high-opportunity destinations, volatile high-demand destinations, and regions with persistent low-opportunity risk.

Risk-aware dispatching involves some conflicting operational objectives. Reducing pickup distance may sacrifice destination opportunity, improving current revenue may send a vehicle to a future weak-demand area, and excessively avoiding low-opportunity destinations may increase current matching cost. Zhao et al. [31] studied multi-objective dynamic traffic guidance based on dynamic traffic assignment. Nan et al. [32] considered traffic congestion in cold-chain distribution-route optimization and showed that traffic-aware routing changes both economic and environmental cost components. Wang et al. [33] further coupled traffic forecasting with hybrid optimization-based vehicle route planning for cold-chain logistics, illustrating how predicted road conditions can be translated into routing decisions subject to operational constraints. Jin et al. [34] studied preference-agile multi-objective optimization for real-time vehicle dispatching. These studies demonstrate that traffic prediction, multi-objective optimization, and operational decision making can be integrated. However, in ride-hailing dispatching, it remains necessary to further clarify how probabilistic forecasting outputs, destination opportunity, destination risk, and executable one-to-one assignment can be jointly represented within the same online matching process.

On the whole, existing studies have provided useful foundations for ride-hailing operational decision making. Demand forecasting studies improve the description of future regional travel states, graph-based models strengthen the representation of irregular urban spatial relationships, online dispatching methods support dynamic vehicle–request matching, mixed-request studies highlight the role of matching timing, and prediction-guided dispatching shows the value of using future state information in operational optimization. Despite these advances, these research directions are not yet fully connected from the perspective of closed-loop prediction–dispatching. In many studies, forecasting results are mainly evaluated by prediction errors, rather than being further converted into destination opportunity or risk signals for the matching objective. Graph-based representations have mainly been used to improve spatio-temporal prediction, whereas their role in post-drop-off vehicle placement and subsequent service opportunities has received less direct treatment. Similarly, online matching objectives are commonly formulated around current pickup distance, request revenue, and waiting cost, and the future state of the destination is only weakly incorporated. For mixed-request settings based on public data, the early visibility of advance requests and their executable dispatching windows also need to be distinguished more carefully. Therefore, a remaining issue is how to embed probabilistic forecasting outputs, destination-side opportunity and risk, and executable one-to-one vehicle–request assignment into a unified online dispatching process.

To address this issue, this paper constructs a closed-loop prediction–dispatching framework composed of CC-STMT and DP-OTM. CC-STMT uses a physical-distance graph, a functional–semantic graph, and en-route supply feedback to generate forecasting fields, including demand intensity, low-opportunity risk, and demand dispersion. DP-OTM then maps these forecasting fields into request-level destination opportunity and destination risk, and incorporates them into the online matching cost together with pickup distance, request revenue, and waiting priority. In this way, the proposed framework builds an operational link from regional probabilistic forecasting to destination-aware ride-hailing dispatching.

3. Materials and Methods

This section presents the proposed risk-aware online dispatching method for ride-hailing systems with mixed on-demand and advance requests. The method consists of two coupled modules: a closed-loop context-aware spatio-temporal multi-task network (CC-STMT) for dispatch-oriented forecasting and a demand-prediction-guided optimal transport matching (DP-OTM) method for online vehicle–request assignment. CC-STMT first estimates several regional states needed by the dispatching model, including latent demand intensity, low-opportunity risk derived from zero inflation, demand dispersion, and an auxiliary speed state. These outputs are then used by DP-OTM to adjust the matching cost for each candidate vehicle–request pair, so that the destination condition is considered together with the current matching factors. After a trip is completed, the vehicle’s landing zone is further recorded as part of the en-route supply feedback, which links earlier dispatching decisions with the forecasting input of later decision windows.

The notation distinguishes sets, matrices, vectors, scalars, indices, and descriptive qualifiers through font style, subscripts, and superscripts. Each complete symbol, including its subscripts and superscripts, is used consistently throughout the paper. Calligraphic symbols denote sets or graphs, bold uppercase symbols denote matrices or zone-level fields, bold lowercase symbols denote vectors, and scalar symbols denote individual variables. The index notation is as follows: i and j refer to vehicles and requests, respectively; m and n are used as spatial-zone indices; z denotes a generic zone argument; and a denotes an attention-head index when used as a scalar index. The superscript t denotes the current dispatching epoch, and $t+h$ denotes the future prediction epoch. The superscript p denotes pickup-related quantities, d denotes destination-related quantities, $\mathrm{create}$ denotes request creation time, $\mathrm{pickup}$ denotes target pickup time, $\mathrm{ava}$ denotes vehicle availability time, $\mathrm{drop}$ denotes a vehicle drop-off zone, and $\max$ denotes a maximum acceptable bound. The superscripts $\mathrm{on}$ and $\mathrm{adv}$ identify the on-demand- and advance-request sets, and the subscript $\mathrm{act}$ identifies the activated subset of advance service. Descriptive subscripts such as $\mathrm{dist}$, $\mathrm{sem}$, $\mathrm{ctx}$, $\mathrm{gate}$, $\mathrm{mask}$, $\mathrm{enc}$, $\mathrm{dec}$, $\mathrm{fus}$, $\mathrm{ZINB}$, $\mathrm{spd}$, and $\mathrm{uot}$ are used only for physical-distance, semantic, contextual, gate, masked-state, encoder, decoder, fused-state, ZINB-loss, speed-loss, and UOT-related quantities, respectively. Neural-network parameters are written as ${\mathbf{W}}_{(·)}$, ${\mathbf{w}}_{(·)}$, and ${\mathbf{b}}_{(·)}$, where the subscript identifies the corresponding layer or output head. Under this convention, ${\mathcal{V}}^t$ denotes the set of available vehicles, $v_i^t$ denotes an individual vehicle state, ${\mathbf{V}}^{t,a}$ denotes the value projection in the attention head a, and ${\widehat{\mathbf{S}}}^{t+h}$ denotes the auxiliary speed prediction. Similarly, ${\mathcal{E}}_{\mathrm{dist}}$ and ${\mathcal{E}}_{\mathrm{sem}}$ denote graph edge sets, whereas ${\mathbf{E}}^t$ denotes the en-route supply-feedback field. The request-level destination-risk score ${\zeta }_j^t$ is obtained from the destination-zone component of the predicted zone-level field ${\mathit{\pi }}^{t+h}$ and is not an additional forecasting output.

3.1. Overall Framework of the Proposed Method

As shown in Figure 1, the proposed closed-loop prediction–dispatching framework consists of six components: multi-source urban inputs, dual-graph construction, the CC-STMT forecasting layer, probabilistic predictive fields, the DP-OTM dispatching layer, and mixed-request dispatching outcomes. The multi-source urban inputs include historical demand sequences, traffic-speed states, weather or contextual variables, and en-route vehicle supply feedback. The dual-graph construction module builds two complementary graph structures over urban regions: a physical-distance graph representing road-network accessibility and spatial proximity, and a functional–semantic graph representing similarity in regional functions and historical mobility patterns. These inputs are processed by CC-STMT to generate dispatch-oriented probabilistic fields. The resulting latent demand intensity, low-opportunity risk, and demand dispersion are then used by DP-OTM to construct risk-aware matching costs for online vehicle–request assignment.

The framework operates in a closed-loop manner. First, historical regional states within a fixed temporal window are organized as input sequences. Second, physical and semantic graph structures are constructed to represent different types of inter-zone dependencies. Third, CC-STMT performs demand-gated speed denoising, multi-source feature fusion, and dual-graph constrained spatio-temporal encoding. Fourth, the historical-window decoder outputs zero-inflation probability, latent demand intensity, demand dispersion, and auxiliary speed prediction. Fifth, DP-OTM embeds current service factors and predicted destination states into a composite matching cost. Finally, the executable assignments update vehicle locations, service states, and future available times. The updated vehicle landing states are further transformed into en-route supply feedback for the next forecasting window.

This design enables the forecasting layer to directly inform dispatching decisions. The model not only predicts future order counts for evaluation; it also separates latent demand intensity and low-opportunity risk, enabling the dispatching layer to distinguish destinations with different post-drop-off service potential. At the same time, the en-route feedback variable allows the forecasting process to capture how previous assignments reshape future vehicle supply.

3.2. Problem Definition

This study considers an online ride-hailing dispatching problem under mixed on-demand and advance requests. At each dispatching epoch t, the system observes the current available vehicle set, the active request pool, historical regional states, and urban graph structures. The objective is to generate executable vehicle–request assignments that satisfy operational constraints while balancing current service efficiency and future destination opportunity.

Let

$${\mathcal{V}}^t=\{v_1^t,v_2^t,\dots ,v_{|{\mathcal{V}}^t|}^t\}$$

(1)

denote the set of vehicles available for dispatching at epoch t, and let

$${\mathcal{O}}^t=\{o_j\mid o_j\mathrm{is}\mathrm{active}\mathrm{at}\mathrm{epoch}t\}$$

(2)

denote the active request pool. The historical regional input window is represented as

$${\mathbf{X}}_{t-L+1:t}=\{{\mathbf{X}}^{t-L+1},{\mathbf{X}}^{t-L+2},\dots ,{\mathbf{X}}^t\},$$

(3)

where L is the historical window length. The spatial relations among urban regions are represented by a physical-distance graph ${\mathcal{G}}_{\mathrm{dist}}$ and a functional–semantic graph ${\mathcal{G}}_{\mathrm{sem}}$.

Given ${\mathcal{V}}^t$, ${\mathcal{O}}^t$, ${\mathbf{X}}_{t-L+1:t}$, ${\mathcal{G}}_{\mathrm{dist}}$, and ${\mathcal{G}}_{\mathrm{sem}}$, the forecasting layer first estimates future regional states:

$$({\mathit{\mu }}^{t+h},{\mathit{\pi }}^{t+h},{\mathit{\theta }}^{t+h},{\widehat{\mathbf{S}}}^{t+h})=f_{\mathrm{CC}-\mathrm{STMT}}({\mathbf{X}}_{t-L+1:t},{\mathcal{G}}_{\mathrm{dist}},{\mathcal{G}}_{\mathrm{sem}}),$$

(4)

where h denotes the prediction horizon, ${\mathit{\mu }}^{t+h}$ denotes the latent demand-intensity field, ${\mathit{\pi }}^{t+h}$ denotes the zero-inflation-derived low-opportunity risk field, ${\mathit{\theta }}^{t+h}$ denotes the demand-dispersion field, and ${\widehat{\mathbf{S}}}^{t+h}$ denotes the auxiliary speed prediction field. Among these outputs, ${\mathit{\mu }}^{t+h}$ and ${\mathit{\pi }}^{t+h}$ are further transformed into destination opportunity and destination risk for dispatching, while ${\mathit{\theta }}^{t+h}$ and ${\widehat{\mathbf{S}}}^{t+h}$ support probabilistic demand modeling and shared traffic-state representation. The dispatching layer then generates a binary assignment matrix:

$${\Xi }^t=g_{\mathrm{DP}-\mathrm{OTM}}({\mathcal{V}}^t,{\mathcal{O}}^t,{\mathit{\mu }}^{t+h},{\mathit{\pi }}^{t+h}).$$

(5)

Each element ${\xi }_{ij}^t$ in ${\Xi }^t$ indicates whether vehicle $v_i^t$ is assigned to request $o_j$:

$${\xi }_{ij}^t=\left\{\begin{array}{cc}1,\hfill & \mathrm{if}\mathrm{vehicle}{v}_i^t\mathrm{is}\mathrm{assigned}\mathrm{to}\mathrm{request}{o}_j,\hfill \\ 0,\hfill & \mathrm{otherwise}.\hfill \end{array}\right.$$

(6)

The assignment must satisfy one-to-one matching constraints and request-specific feasibility constraints. Therefore, each available vehicle can serve at most one request, and each request can be served by at most one vehicle during one dispatching epoch.

3.3. Mixed On-Demand- and Advance-Request Formulation

The request pool considered in this study contains both on-demand requests and advance requests:

$$\mathcal{O}={\mathcal{O}}^{\mathrm{on}}\cup {\mathcal{O}}^{\mathrm{adv}},$$

(7)

where ${\mathcal{O}}^{\mathrm{on}}$ denotes the set of on-demand requests and ${\mathcal{O}}^{\mathrm{adv}}$ denotes the set of advance requests. These two types of requests share the same vehicle pool but differ in temporal visibility and dispatching logic.

For each request $o_j$, its state is defined as

$$o_j=\langle l_j^p,z_j^p,z_j^d,r_j,t_j^{\mathrm{create}},t_j^{\mathrm{pickup}},d_j^{\max },{\chi }_j\rangle ,$$

(8)

where $l_j^p$ denotes the pickup location, $z_j^p$ denotes the pickup zone, $z_j^d$ denotes the destination zone, $r_j$ denotes the expected revenue, $t_j^{\mathrm{create}}$ denotes the request creation time, $t_j^{\mathrm{pickup}}$ denotes the target pickup time, $d_j^{\max }$ denotes the maximum acceptable pickup distance, and ${\chi }_j\in \{0,1\}$ denotes the request type. Specifically, ${\chi }_j=0$ indicates an on-demand request, while ${\chi }_j=1$ indicates an advance request.

For an on-demand request, the request is assumed to enter the dispatching pool immediately after it is generated:

$$t_j^{\mathrm{pickup}}\approx t_j^{\mathrm{create}},o_j\in {\mathcal{O}}^{\mathrm{on}}.$$

(9)

For an advance request, the target pickup time is later than the request creation time:

$$t_j^{\mathrm{pickup}}>t_j^{\mathrm{create}},o_j\in {\mathcal{O}}^{\mathrm{adv}}.$$

(10)

Advance requests therefore provide information about future service demand before their executable pickup time, but an advance request should not lock a vehicle immediately after it becomes visible. To separate early visibility from executable commitment, a short dispatchable service window is introduced around the requested pickup time. Let ${\Delta }_a$ denote the early activation length, ${\Delta }_l$ denote the tolerated lateness after the requested pickup time, and ${\Delta }_o$ denote the maximum waiting tolerance of an on-demand request. An advance request is dispatchable only if

$$t_j^{\mathrm{pickup}}-{\Delta }_a\le t\le t_j^{\mathrm{pickup}}+{\Delta }_l.$$

(11)

In the Chicago-B implementation used for the final dispatching experiments, both ${\Delta }_a$ and ${\Delta }_l$ are set to two 5 min dispatch slots. Thus, advance requests may appear earlier based on their creation times, but they are committed to vehicles only within a short executable window around the requested pickup time.

Figure 2 illustrates the activation and dispatching logic of the two request types. On-demand requests enter the dispatching process immediately after creation and remain dispatchable within their waiting tolerance. In contrast, advance requests are first visible as future service information and become executable only when the current time approaches the target pickup time. This mechanism preserves the operational value of advance information while reducing premature vehicle reservation.

At dispatching epoch t, the active request pool is defined as

$${\mathcal{O}}^t={\mathcal{O}}^{\mathrm{on},t}\cup {\mathcal{O}}_{\mathrm{act}}^{\mathrm{adv},t},$$

(12)

where ${\mathcal{O}}^{\mathrm{on},t}$ denotes the set of unserved on-demand requests available at epoch t and ${\mathcal{O}}_{\mathrm{act}}^{\mathrm{adv},t}$ denotes the activated and executable subset of unserved advance requests. These two sets are defined as

$${\mathcal{O}}^{\mathrm{on},t}=\{o_j\in {\mathcal{O}}^{\mathrm{on}}\mid t_j^{\mathrm{create}}\le t\le t_j^{\mathrm{create}}+{\Delta }_o,o_j\mathrm{is}\mathrm{unserved}\},$$

(13)

and

$${\mathcal{O}}_{\mathrm{act}}^{\mathrm{adv},t}=\{o_j\in {\mathcal{O}}^{\mathrm{adv}}\mid t_j^{\mathrm{pickup}}-{\Delta }_a\le t\le t_j^{\mathrm{pickup}}+{\Delta }_l,o_j\mathrm{is}\mathrm{unserved}\}.$$

(14)

The urgency score $U_j^t$ is determined by the request type. For an on-demand request, it increases with the elapsed waiting time after request creation. For an activated advance request, the early lead time before the requested pickup time is not treated as passenger waiting; urgency is measured around the target pickup time:

$$U_j^t=\left\{\begin{array}{cc}\max (0,t-t_j^{\mathrm{create}}),\hfill & o_j\in {\mathcal{O}}^{\mathrm{on},t},\hfill \\ \max (0,t-t_j^{\mathrm{pickup}}),\hfill & o_j\in {\mathcal{O}}_{\mathrm{act}}^{\mathrm{adv},t}.\hfill \end{array}\right.$$

(15)

A larger $U_j^t$ indicates stronger service urgency. This definition preserves the target-pickup-time logic of advance requests while allowing on-demand requests to accumulate waiting priority from their creation time.

3.4. Dual-Graph Urban Representation

The study area is divided into N irregular spatial units:

$$\mathcal{Z}=\{z_1,z_2,\dots ,z_N\},$$

(16)

where $z_m$ denotes the m-th spatial unit. Each pickup and drop-off point is mapped to a single spatial unit, so that ride-hailing trips can be represented as region-level spatio-temporal sequences.

The physical-distance graph is defined as

$${\mathcal{G}}_{\mathrm{dist}}=(\mathcal{Z},{\mathcal{E}}_{\mathrm{dist}},{\mathbf{A}}_{\mathrm{dist}}),$$

(17)

where ${\mathcal{E}}_{\mathrm{dist}}$ denotes the edge set induced by road-network accessibility and ${\mathbf{A}}_{\mathrm{dist}}\in {\mathbb{R}}^{N\times N}$ denotes the corresponding adjacency matrix. The inter-zone driving-distance matrix is computed as

$${\mathbf{D}}_{\mathrm{drive}}={\left[d_{mn}\right]}_{N\times N},$$

(18)

where $d_{mn}$ denotes the shortest driving distance from zone $z_m$ to zone $z_n$. The physical adjacency weight is defined as

$$A_{\mathrm{dist}}^{mn}=\exp \left(-{\displaystyle \frac{d_{mn}^2}{{\sigma }_d^2}}\right),$$

(19)

where ${\sigma }_d$ is the distance-decay coefficient. The normalized physical-distance adjacency matrix used in graph propagation is denoted by ${\widehat{\mathbf{A}}}_{\mathrm{dist}}$.

The functional–semantic graph is defined as

$${\mathcal{G}}_{\mathrm{sem}}=(\mathcal{Z},{\mathcal{E}}_{\mathrm{sem}},{\mathbf{A}}_{\mathrm{sem}}),$$

(20)

where ${\mathcal{E}}_{\mathrm{sem}}$ denotes the edge set induced by functional similarity and ${\mathbf{A}}_{\mathrm{sem}}\in {\mathbb{R}}^{N\times N}$ denotes the semantic adjacency matrix. Let ${\mathbf{s}}_m$ denote the functional feature vector of zone $z_m$. The semantic adjacency between zones $z_m$ and $z_n$ is defined as

$$A_{\mathrm{sem}}^{mn}={\displaystyle \frac{{\mathbf{s}}_m^{\top }{\mathbf{s}}_n}{\parallel {\mathbf{s}}_m{\parallel }_2{\parallel {\mathbf{s}}_n\parallel }_2+{ϵ}_0}},$$

(21)

where ${ϵ}_0$ is a small positive constant used to avoid division by zero. The physical-distance graph emphasizes road accessibility and local spatial propagation, whereas the functional–semantic graph emphasizes similarity in regional function and demand behavior.

3.5. Vehicle State and En-Route Supply Feedback

At dispatching epoch t, each available vehicle is represented by its current spatial state and service availability. The state of vehicle $v_i^t$ is defined as

$$v_i^t=\langle l_i^t,z_i^t,{\alpha }_i^t,T_i^{\mathrm{ava}}\rangle ,$$

(22)

where $l_i^t$ denotes the current vehicle location, $z_i^t$ denotes the current zone, ${\alpha }_i^t$ denotes the availability indicator, and $T_i^{\mathrm{ava}}$ denotes the next available time. A vehicle is dispatchable only when

$${\alpha }_i^t=1,T_i^{\mathrm{ava}}\le t.$$

(23)

Vehicles that are currently serving passengers cannot participate in the current matching round. Nevertheless, their expected drop-off zones and completion times determine future vehicle supply. Therefore, this study converts ongoing service states into en-route supply feedback. For zone z at epoch t, the en-route supply feedback is defined as

$$E_z^t=\sum _{v_i}\mathbb{I}({\widehat{T}}_i^{\mathrm{ava}}=t,{\widehat{z}}_i^{\mathrm{drop}}=z),$$

(24)

where ${\widehat{T}}_i^{\mathrm{ava}}$ denotes the predicted next available time of vehicle $v_i$, ${\widehat{z}}_i^{\mathrm{drop}}$ denotes its predicted drop-off zone, and $\mathbb{I}(·)$ is the indicator function. The vector form of en-route supply feedback is denoted by

$${\mathbf{E}}^t={[E_1^t,E_2^t,\dots ,E_N^t]}^{\top }.$$

(25)

This feedback variable links dispatch outcomes to subsequent forecasting inputs.

3.6. CC-STMT Forecasting Layer

The proposed CC-STMT forecasting layer is designed to generate predictive states that can be directly used by the dispatching layer. Given a historical input window, CC-STMT estimates four outputs: latent demand intensity $\mathit{\mu }$, zero-inflation-derived low-opportunity risk $\mathit{\pi }$, demand dispersion $\mathit{\theta }$, and auxiliary speed prediction $\widehat{\mathbf{S}}$. The first three outputs form a zero-inflated negative binomial demand structure, while the auxiliary speed head regularizes the shared traffic-state representation.

The historical input sequence at epoch t follows Equation (3), where L denotes the historical input-window length, ${\mathbf{X}}^{\tau }\in {\mathbb{R}}^{N\times F}$ denotes the region-level feature matrix at time step $\tau$, and F denotes the feature dimension. At each time step, the multi-source input is represented as

$${\mathbf{X}}^t=\mathrm{Concat}({\mathbf{Y}}^t,{\tilde{\mathbf{S}}}^t,{\mathbf{E}}^t,{\mathbf{X}}_{\mathrm{ctx}}^t),$$

(26)

where $\mathrm{Concat}(·)$ denotes feature concatenation along the feature dimension, ${\mathbf{Y}}^t$ denotes historical demand, ${\tilde{\mathbf{S}}}^t$ denotes the demand-gated and graph-denoised speed state, ${\mathbf{E}}^t$ denotes en-route supply feedback, and ${\mathbf{X}}_{\mathrm{ctx}}^t$ denotes weather or contextual features.

As shown in Figure 3, CC-STMT consists of demand-gated speed denoising, multi-source feature fusion, dual-graph constrained spatio-temporal encoding, and historical-window decoding.

Regional traffic-speed observations can be sparse or noisy, especially in areas with few ride-hailing requests. Therefore, a demand-gated mask is introduced:

$${\mathbf{G}}_{\mathrm{gate}}^t=\sigma ({\mathbf{Y}}^t-\mathbf{1}),$$

(27)

where $\sigma (·)$ denotes the Sigmoid function and $\mathbf{1}$ is a broadcast-compatible all-one field. The masked speed state is computed as

$${\mathbf{S}}_{\mathrm{mask}}^t={\mathbf{G}}_{\mathrm{gate}}^t\odot {\mathbf{S}}^t,$$

(28)

where ⊙ denotes element-wise multiplication. The masked speed state is further reconstructed through the physical-distance graph:

$${\mathbf{H}}_{\mathrm{enc}}^t=\mathrm{ReLU}\left({\widehat{\mathbf{A}}}_{\mathrm{dist}}{\mathbf{S}}_{\mathrm{mask}}^t{\mathbf{W}}_{\mathrm{enc}}+{\mathbf{b}}_{\mathrm{enc}}\right),$$

(29)

$${\tilde{\mathbf{S}}}^t=\sigma \left({\widehat{\mathbf{A}}}_{\mathrm{dist}}{\mathbf{H}}_{\mathrm{enc}}^t{\mathbf{W}}_{\mathrm{dec}}+{\mathbf{b}}_{\mathrm{dec}}\right).$$

(30)

After denoising, the multi-source input is projected into a shared hidden space:

$${\mathbf{H}}_{\mathrm{fus}}^t=\mathrm{ReLU}({\mathbf{X}}^t{\mathbf{W}}_{\mathrm{in}}+{\mathbf{b}}_{\mathrm{in}}).$$

(31)

For the attention head indexed by a, the query, key, and value projections are

$${\mathbf{Q}}^{t,a}={\mathbf{H}}_{\mathrm{fus}}^t{\mathbf{W}}_Q^a,{\mathbf{K}}^{t,a}={\mathbf{H}}_{\mathrm{fus}}^t{\mathbf{W}}_K^a,{\mathbf{V}}^{t,a}={\mathbf{H}}_{\mathrm{fus}}^t{\mathbf{W}}_V^a.$$

(32)

The base attention score matrix is calculated as

$${\mathbf{R}}^{t,a}={\displaystyle \frac{{\mathbf{Q}}^{t,a}{\left({\mathbf{K}}^{t,a}\right)}^{\top }}{\sqrt{{\eta }_h}}}.$$

(33)

Here, ${\eta }_h$ denotes the attention-head dimension. In the physical-distance branch, the base attention scores are masked by the physical-distance adjacency matrix:

$${\mathbf{\Lambda }}_{\mathrm{dist}}^{t,a}={\mathrm{softmax}}_{\mathrm{row}}\left(\mathrm{mask}({\mathbf{R}}^{t,a},{\mathbf{A}}_{\mathrm{dist}})\right),$$

(34)

$${\mathbf{O}}_{\mathrm{dist}}^{t,a}={\mathbf{\Lambda }}_{\mathrm{dist}}^{t,a}{\mathbf{V}}^{t,a}.$$

(35)

In the functional–semantic branch, the attention weights are reweighted by the semantic adjacency matrix:

$${\mathbf{\Lambda }}_{\mathrm{sem}}^{t,a}={\mathrm{Normalize}}_{\mathrm{row}}\left({\mathrm{softmax}}_{\mathrm{row}}\left({\mathbf{R}}^{t,a}\right)\odot {\mathbf{A}}_{\mathrm{sem}}\right),$$

(36)

$${\mathbf{O}}_{\mathrm{sem}}^{t,a}={\mathbf{\Lambda }}_{\mathrm{sem}}^{t,a}{\mathbf{V}}^{t,a}.$$

(37)

Here, $\mathrm{mask}(·)$ suppresses attention scores for physically disconnected zone pairs, and ${\mathrm{Normalize}}_{\mathrm{row}}(·)$ denotes row-wise normalization of the reweighted attention matrix. The two branch outputs are concatenated and projected as

$${\mathbf{O}}^{t,a}=[{\mathbf{O}}_{\mathrm{dist}}^{t,a}\parallel {\mathbf{O}}_{\mathrm{sem}}^{t,a}]{\mathbf{W}}_O^a+{\mathbf{b}}_O^a,$$

(38)

where ∥ denotes feature concatenation.

The outputs of all attention heads are aggregated over the historical window and passed to the historical-window decoder. The decoder forms a shared zone-level representation, and task-specific output heads map this representation to the zero-inflation probability, latent demand intensity, dispersion, and auxiliary speed prediction.

The demand output is modeled by a zero-inflated negative binomial distribution. For a generic zone z, the model outputs the zero-inflation probability ${\pi }_z$, the latent demand intensity ${\mu }_z$, and the dispersion parameter ${\theta }_z$. Let $Y_z$ denote the random demand count in zone z, let $y_z$ denote an observed positive count, let $\mathrm{Pr}(·)$ denote probability, and let $\mathrm{NB}(y_z;{\mu }_z,{\theta }_z)$ denote the negative binomial probability mass function. The ZINB probability is defined as

$$\mathrm{Pr}(Y_z=0)={\pi }_z+(1-{\pi }_z)\mathrm{NB}(0;{\mu }_z,{\theta }_z),$$

(39)

$$\mathrm{Pr}(Y_z=y_z)=(1-{\pi }_z)\mathrm{NB}(y_z;{\mu }_z,{\theta }_z),y_z>0.$$

(40)

The training loss is defined as

$$\mathcal{L}={\mathcal{L}}_{\mathrm{ZINB}}+{\lambda }_{\mathrm{spd}}{\mathcal{L}}_{\mathrm{spd}},$$

(41)

where ${\mathcal{L}}_{\mathrm{ZINB}}$ denotes the ZINB negative log-likelihood loss, ${\mathcal{L}}_{\mathrm{spd}}$ denotes the auxiliary speed prediction loss, and ${\lambda }_{\mathrm{spd}}$ controls the contribution of the auxiliary speed task.

The CC-STMT forecasting procedure is summarized in Algorithm 1. The output fields ${\mathit{\mu }}^{t+h}$ and ${\mathit{\pi }}^{t+h}$ are subsequently used by DP-OTM to compute request-level destination opportunity and destination risk, while ${\mathit{\theta }}^{t+h}$ and ${\widehat{\mathbf{S}}}^{t+h}$ support probabilistic demand modeling and shared traffic-state representation.

Algorithm 1 CC-STMT dispatch-oriented forecasting procedure.

Require:  Historical input window ${\mathbf{X}}_{t-L+1:t}$, physical-distance graph ${\mathcal{G}}_{\mathrm{dist}}$ with adjacency ${\mathbf{A}}_{\mathrm{dist}}$, functional–semantic graph ${\mathcal{G}}_{\mathrm{sem}}$ with adjacency ${\mathbf{A}}_{\mathrm{sem}}$, prediction horizon h Ensure:  Predictive fields ${\mathit{\mu }}^{t+h}$, ${\mathit{\pi }}^{t+h}$, ${\mathit{\theta }}^{t+h}$, and ${\widehat{\mathbf{S}}}^{t+h}$ 1: Extract historical demand ${\mathbf{Y}}^{\tau }$, traffic-speed state ${\mathbf{S}}^{\tau }$, en-route feedback ${\mathbf{E}}^{\tau }$, and contextual features ${\mathbf{X}}_{\mathrm{ctx}}^{\tau }$ for $\tau =t-L+1,\dots ,t$. 2: Compute demand-gated speed masks ${\mathbf{G}}_{\mathrm{gate}}^{\tau }=\sigma ({\mathbf{Y}}^{\tau }-\mathbf{1})$ and masked speed states ${\mathbf{S}}_{\mathrm{mask}}^{\tau }={\mathbf{G}}_{\mathrm{gate}}^{\tau }\odot {\mathbf{S}}^{\tau }$. 3: Reconstruct denoised speed states ${\tilde{\mathbf{S}}}^{\tau }$ through the graph-based encoder–decoder using ${\widehat{\mathbf{A}}}_{\mathrm{dist}}$. 4: Form multi-source inputs ${\mathbf{X}}^{\tau }=\mathrm{Concat}({\mathbf{Y}}^{\tau },{\tilde{\mathbf{S}}}^{\tau },{\mathbf{E}}^{\tau },{\mathbf{X}}_{\mathrm{ctx}}^{\tau })$ and project them into shared hidden states ${\mathbf{H}}_{\mathrm{fus}}^{\tau }$. 5: Apply dual-graph constrained multi-head attention using the physical-distance branch and the functional–semantic branch. 6: Aggregate the encoded representations over the historical window and obtain a shared zone-level decoder representation. 7: Generate ZINB output heads ${\mathit{\pi }}^{t+h}$, ${\mathit{\mu }}^{t+h}$, and ${\mathit{\theta }}^{t+h}$, and generate the auxiliary speed output ${\widehat{\mathbf{S}}}^{t+h}$. 8: return ${\mathit{\mu }}^{t+h}$, ${\mathit{\pi }}^{t+h}$, ${\mathit{\theta }}^{t+h}$, and ${\widehat{\mathbf{S}}}^{t+h}$

3.7. Dispatch-Oriented Probabilistic Predictive Fields

The outputs of CC-STMT are converted into dispatch-oriented predictive fields before entering DP-OTM. For a future horizon h, the latent demand-intensity field is defined as

$${\mathit{\mu }}^{t+h}=\{{\mu }_1^{t+h},{\mu }_2^{t+h},\dots ,{\mu }_N^{t+h}\},$$

(42)

where ${\mu }_z^{t+h}>0$ denotes the latent future demand intensity of zone z. The zero-inflation field is defined as

$${\mathit{\pi }}^{t+h}=\{{\pi }_1^{t+h},{\pi }_2^{t+h},\dots ,{\pi }_N^{t+h}\},$$

(43)

where ${\pi }_z^{t+h}\in [0,1]$ denotes the structural-zero probability of zone z. The dispersion field is defined as

$${\mathit{\theta }}^{t+h}=\{{\theta }_1^{t+h},{\theta }_2^{t+h},\dots ,{\theta }_N^{t+h}\}.$$

(44)

For demand forecasting evaluation, the expected demand is computed as

$${\widehat{y}}_z^{t+h}=(1-{\pi }_z^{t+h}){\mu }_z^{t+h}.$$

(45)

For dispatching, however, $\mathit{\mu }$ and $\mathit{\pi }$ are used separately. The latent demand intensity represents destination opportunity, while the zero-inflation probability serves as a low-opportunity risk signal. The dispersion field ${\mathit{\theta }}^{t+h}$ supports probabilistic demand modeling and training, whereas the dispatching cost uses ${\mathit{\mu }}^{t+h}$ and ${\mathit{\pi }}^{t+h}$ because they directly correspond to destination opportunity and low-opportunity risk.

For a candidate request $o_j$, the destination zone is $z_j^d$. To make the risk-fusion mechanism explicit, the setting-specific coefficients are first bounded to the numerical interval used by the implementation:

$${\overline{\alpha }}_c=\min \{1,\max (0,{\alpha }_c)\},{\overline{\beta }}_c=\min \{1,\max (0,{\beta }_c)\},$$

(46)

where c indexes the operating setting. The risk-adjustment factor for destination opportunity is then defined as

$${\kappa }_j^t=\min \left\{1,\max \left({ϵ}_{\kappa },1-{\overline{\alpha }}_c{\pi }_{z_j^d}^{t+h}\right)\right\},$$

(47)

where ${ϵ}_{\kappa }=0.05$ prevents the opportunity multiplier from collapsing to zero. The destination-opportunity value is

$${\Psi }_j^t=\log \left(1+{\kappa }_j^t{\mu }_{z_j^d}^{t+h}\right).$$

(48)

The zone-level and request-level low-opportunity penalties are defined as

$${\zeta }_z^t={\overline{\beta }}_c{\pi }_z^{t+h},{\zeta }_j^t={\zeta }_{z_j^d}^t={\overline{\beta }}_c{\pi }_{z_j^d}^{t+h}.$$

(49)

Thus, ${\Psi }_j^t$ acts as a destination-opportunity reward, whereas ${\zeta }_j^t$ acts as an explicit destination-side low-opportunity penalty. The numerical values of ${\alpha }_c$ and ${\beta }_c$ are reported in Section 4.1. Figure 4 illustrates the motivation for introducing destination opportunity and low-opportunity risk. A request that is attractive in the short term may move a vehicle to a weak future service region. In contrast, a request with moderate immediate revenue may place the vehicle in a more favorable region for subsequent service.

3.8. DP-OTM Risk-Aware Online Matching

The DP-OTM layer generates executable vehicle–request assignments at each dispatching epoch. Its inputs include the available vehicle set, the active request pool, operational feasibility constraints, and the predictive opportunity-risk fields produced by CC-STMT. Its output is a binary vehicle–request-assignment matrix.

For a candidate vehicle–request pair $(v_i^t,o_j)$, $d_{ij}^p$ denotes the pickup distance from the current vehicle zone to the request pickup zone, ${\widehat{t}}_{ij}^{\mathrm{arr}}$ denotes the estimated pickup arrival time, and $d_j^{\max }$ denotes the maximum acceptable pickup distance for request $o_j$. The normalized components ${\widehat{d}}_{ij}^p$, ${\widehat{r}}_j$, ${\widehat{U}}_j^t$, ${\widehat{\Psi }}_j^t$, and ${\widehat{\zeta }}_j^t$ are obtained from their corresponding raw quantities and are used only inside the matching-cost function. For a nonnegative component x with reference scale $s_x$, the implementation uses $\widehat{x}=\min \{1,\max (0,x/(s_x+{10}^{-8}))\}$. The setting-specific scales used for pickup distance, revenue, urgency, and destination opportunity are reported in Section 4.1; the destination-risk component is already bounded by construction.

For a feasible vehicle–request pair $(v_i^t,o_j)$, the composite matching cost is defined as

$$C_{ij}^t={\omega }_1{\widehat{d}}_{ij}^p-{\omega }_2{\widehat{r}}_j-{\omega }_3{\widehat{U}}_j^t-{\omega }_4{\widehat{\Psi }}_j^t+{\omega }_5{\widehat{\zeta }}_j^t,$$

(50)

where ${\omega }_1,\dots ,{\omega }_5$ are matching-cost weights, and ${\widehat{d}}_{ij}^p$, ${\widehat{r}}_j$, ${\widehat{U}}_j^t$, ${\widehat{\Psi }}_j^t$, and ${\widehat{\zeta }}_j^t$ denote normalized pickup distance, revenue, urgency, destination opportunity, and destination risk, respectively. Pickup distance and destination risk increase cost, whereas revenue, urgency, and destination opportunity reduce it.

A candidate pair is feasible only if it satisfies vehicle availability, pickup-distance, and time-window constraints. The feasible set is written as

$$\begin{array}{cc}\hfill {\mathcal{F}}^t=\{(v_i^t,o_j)\mid & d_{ij}^p\le d_j^{\max },v_i^t\mathrm{is}\mathrm{available},\hfill \\ \hfill & {\widehat{t}}_{ij}^{\mathrm{arr}}\mathrm{satisfies}\mathrm{the}\mathrm{request}\mathrm{time}\mathrm{window}\}.\hfill \end{array}$$

(51)

The corresponding binary assignment problem can be formulated as

$$\begin{array}{cc}\hfill \underset{{\Xi }^t}{\min }& \sum _{v_i^t\in {\mathcal{V}}^t}\sum _{o_j\in {\mathcal{O}}^t}{C}_{ij}^t{\xi }_{ij}^t\hfill \\ \hfill \mathrm{s}.\mathrm{t}.& \sum _{o_j\in {\mathcal{O}}^t}{\xi }_{ij}^t\le 1,\forall v_i^t\in {\mathcal{V}}^t,\hfill \\ \hfill & \sum _{v_i^t\in {\mathcal{V}}^t}{\xi }_{ij}^t\le 1,\forall o_j\in {\mathcal{O}}^t,\hfill \\ \hfill & {\xi }_{ij}^t=0,\forall (v_i^t,o_j)\notin {\mathcal{F}}^t,\hfill \\ \hfill & {\xi }_{ij}^t\in \{0,1\}.\hfill \end{array}$$

(52)

As shown in Figure 5, DP-OTM first observes the current system state, activates advance requests, builds the active request pool, and constructs feasible candidate edges. It then computes the composite matching cost and builds an unbalanced optimal transport prior. The prior is used to calibrate the pair-wise cost matrix, after which a linear assignment step produces executable matches. Finally, vehicle states and en-route feedback are updated.

Let $n_v^t$ denote the number of available vehicles and $n_o^t$ denote the number of active requests. Let ${\mathbf{C}}^t=\left[C_{ij}^t\right]$ denote the composite cost matrix. Because the vehicle and request set sizes may differ and unmatched mass is allowed, DP-OTM uses uniform vehicle-side and request-side mass vectors,

$${\mathbf{a}}^t={\displaystyle \frac{1}{n_v^t}}{\mathbf{1}}_{n_v^t},{\mathbf{b}}^t={\displaystyle \frac{1}{n_o^t}}{\mathbf{1}}_{n_o^t}.$$

(53)

The feasible cost entries are normalized before constructing the UOT kernel:

$${\overline{C}}_{ij}^t={\displaystyle \frac{C_{ij}^t-C_{\min }^t}{C_{\max }^t-C_{\min }^t+{ϵ}_C}},(v_i^t,o_j)\in {\mathcal{F}}^t,$$

(54)

where $C_{\min }^t$ and $C_{\max }^t$ are computed over ${\mathcal{F}}^t$ only and ${ϵ}_C$ is a numerical stability constant. Infeasible pairs remain masked and are excluded from cost normalization. The Gibbs kernel is

$${\mathbf{M}}^t=\exp \left(-{\displaystyle \frac{{\overline{\mathbf{C}}}^t}{{\epsilon }_{\mathrm{uot}}}}\right).$$

(55)

Starting from all-one scaling vectors, the relaxed Sinkhorn updates are

$$\begin{array}{cc}\hfill {\mathbf{u}}^{(k+1)}& ={\left({\displaystyle \frac{{\mathbf{a}}^t}{{\mathbf{M}}^t{\mathbf{q}}^{\left(k\right)}+{ϵ}_{\mathrm{sk}}}}\right)}^{{\displaystyle \frac{{\tau }_v}{{\tau }_v+{\epsilon }_{\mathrm{uot}}}}},\hfill \end{array}$$

(56)

$$\begin{array}{cc}\hfill {\mathbf{q}}^{(k+1)}& ={\left({\displaystyle \frac{{\mathbf{b}}^t}{{\left({\mathbf{M}}^t\right)}^{\top }{\mathbf{u}}^{(k+1)}+{ϵ}_{\mathrm{sk}}}}\right)}^{{\displaystyle \frac{{\tau }_o}{{\tau }_o+{\epsilon }_{\mathrm{uot}}}}},\hfill \end{array}$$

(57)

where ${\tau }_v$ and ${\tau }_o$ control the relaxation of the vehicle-side and request-side marginal constraints. After the fixed number of iterations, the soft transport prior is

$${\mathbf{P}}^t=\mathrm{diag}\left(\mathbf{u}\right){\mathbf{M}}^t\mathrm{diag}\left(\mathbf{q}\right).$$

(58)

Because the scale of ${\mathbf{P}}^t$ varies across epochs, its feasible entries are min–max-normalized before cost calibration:

$${\overline{P}}_{ij}^t={\displaystyle \frac{P_{ij}^t-P_{\min }^t}{P_{\max }^t-P_{\min }^t+{ϵ}_s}},(v_i^t,o_j)\in {\mathcal{F}}^t,$$

(59)

where $P_{\min }^t$ and $P_{\max }^t$ are the minimum and maximum values of $P_{ij}^t$ over feasible vehicle–request pairs, and ${ϵ}_s$ is a numerical stability constant. Infeasible pairs remain masked and are excluded from this normalization. The normalized prior calibrates the original matching cost as

$${\tilde{C}}_{ij}^t=C_{ij}^t-\gamma {\overline{P}}_{ij}^t.$$

(60)

A linear assignment algorithm is then applied to ${\tilde{\mathbf{C}}}^t$ to produce the executable one-to-one matching ${\mathcal{A}}^t$. The numerical values of ${\epsilon }_{\mathrm{uot}}$, ${\tau }_v$, ${\tau }_o$, $\gamma$, the iteration count, and the numerical stability constants are reported in Section 4.1. The complete online procedure is summarized in Algorithm 2.

Algorithm 2 DP-OTM online dispatching procedure.

Require:  Current epoch t, available vehicles ${\mathcal{V}}^t$, on-demand requests ${\mathcal{O}}^{\mathrm{on},t}$, advance requests ${\mathcal{O}}^{\mathrm{adv}}$, predictive fields ${\mathit{\mu }}^{t+h}$ and ${\mathit{\pi }}^{t+h}$ from Algorithm 1 Ensure:  Executable assignment set ${\mathcal{A}}^t$ and updated vehicle feedback ${\mathbf{E}}^{t+1}$ 1: Activate advance requests satisfying $t_j^{\mathrm{pickup}}-{\Delta }_a\le t\le t_j^{\mathrm{pickup}}+{\Delta }_l$. 2: Build the active request pool ${\mathcal{O}}^t={\mathcal{O}}^{\mathrm{on},t}\cup {\mathcal{O}}_{\mathrm{act}}^{\mathrm{adv},t}$. 3: Construct feasible candidate edges ${\mathcal{F}}^t$ using vehicle availability, pickup-distance, and time-window constraints. 4: Compute the composite matching cost $C_{ij}^t$ for each feasible pair $(v_i^t,o_j)\in {\mathcal{F}}^t$. 5: Normalize the feasible cost entries, keep infeasible pairs masked, and compute the UOT Gibbs kernel ${\mathbf{M}}^t$. 6: Run Sinkhorn iterations on ${\mathbf{M}}^t$ to obtain the UOT soft matching prior ${\mathbf{P}}^t$. 7: Min–max normalize the feasible entries of ${\mathbf{P}}^t$ and calibrate the cost matrix using ${\tilde{C}}_{ij}^t=C_{ij}^t-\gamma {\overline{P}}_{ij}^t$. 8: Apply linear assignment to ${\tilde{\mathbf{C}}}^t$ and obtain ${\mathcal{A}}^t$. 9: Execute assignments, update vehicle locations and next available times, and refresh en-route supply feedback. 10: return ${\mathcal{A}}^t$ and updated feedback.

3.9. Method Execution Protocol

The proposed framework is executed sequentially over dispatching epochs. At each epoch, the system first updates the vehicle states according to previously assigned requests and completed trips. Vehicles whose service completion times are no later than the current epoch are added back to the available vehicle pool. Ongoing trips that have not yet been completed are used to update the en-route supply feedback for future epochs.

The forecasting layer receives the latest historical regional window and produces predictive fields for the future dispatching horizon. These outputs are transformed into request-level destination opportunity and destination risk according to each candidate request’s destination zone. The dispatching layer then builds the active request pool according to the on-demand waiting tolerance and the advance-request executable window, filters feasible candidate edges, computes composite matching costs, constructs the unbalanced transport prior, normalizes this prior over feasible pairs, and generates final one-to-one assignments. After assignments are executed, each matched vehicle is updated according to the assigned request’s pickup travel time, service duration, destination zone, and next available time. Unmatched requests remain in the pool until they exceed the allowed waiting or time-window constraints.

4. Results

This section evaluates the proposed closed-loop prediction–dispatching framework from two connected perspectives. The forecasting experiments examine whether CC-STMT can describe future regional demand states under different spatial systems and provide demand-opportunity and low-opportunity-risk signals for downstream dispatching. The dispatching experiments then examine how DP-OTM uses these predictive signals in mixed on-demand- and advance-request matching and whether the resulting vehicle landing locations are associated with better subsequent service opportunities.

The section proceeds as follows: Section 4.1 introduces the datasets, spatial partitions, advance-request construction, reproducibility settings, evaluation metrics, and baselines. Section 4.2 compares forecasting accuracy and analyzes the role of closed-loop feedback and dual-graph modeling. Section 4.3 reports the revenue–risk relationship and normalized multi-indicator dispatching results. Section 4.4 further examines ablation behavior, risk-signal diagnostics, post-drop-off mechanisms, and hourly traces. Section 4.5 evaluates the sensitivity and robustness of the dispatching results under variations in matching weights, advance-request generation, passenger and driver behavior, and evaluation-window length. Section 4.6 reports the complete dispatch benchmark values.

4.1. Experimental Settings

The experiments use data from two real-world ride-hailing systems, NYC and Chicago, and are organized into three operating settings. The NYC setting uses high-volume for-hire vehicle trip records and the full taxi-zone system released by the New York City Taxi and Limousine Commission [35]. Both Chicago settings use Transportation Network Provider trip records released through the City of Chicago Data Portal [36]. Chicago-A uses a core region constructed from the official 2010 census-tract boundaries [37], whereas Chicago-B uses the official citywide community-area boundaries [38]. Road-network and POI data for both cities are obtained from OpenStreetMap [39] and processed using OSMnx [40]; hourly temperature and precipitation records are obtained from the Open-Meteo Weather API [41]. This design allows the evaluation to cover not only different cities but also different spatial resolutions and operating-region definitions.

Table 1. Experimental datasets and spatial systems. Bold text is used for column headings and setting labels only; it does not indicate statistical significance.

Setting	Raw Trip Data	Spatial Unit	Units	Evaluation Window
NYC	TLC HVFHV trips	Taxi zone	263	24 h
Chicago-A	Chicago TNP trips	Census tract	231	72 h
Chicago-B	Chicago TNP trips	Community area	77	72 h

summarizes the raw trip data, spatial units, and evaluation windows. Figure 6 shows the spatial extent of the three settings: NYC covers the full taxi-zone region, Chicago-A retains selected core census tracts, and Chicago-B covers the citywide community areas. Because the Chicago-A region directly affects demand density, road connectivity, and spatial sparsity, a detailed view of the retained census tracts and the corresponding road-network structure is provided in Figure 7.

Public NYC and Chicago trip records do not contain platform-side reservation fields such as booking creation time, advance lead time, cancellation behavior, driver acceptance behavior, or dynamic pricing. To obtain a reproducible mixed-request dispatching stream, the experiments construct on-demand and advance requests from observed completed trips. Each trip keeps its original pickup zone, drop-off zone, pickup time, trip duration, trip distance, and fare. For a trip marked as an advance request, the observed pickup time is treated as the requested pickup time, and the creation time is shifted earlier by a sampled number of dispatch slots. For an on-demand request, the observed pickup time is used as both the creation time and the requested pickup time. In the mixed-request setting, advance-type requests are generated using a stochastic assignment probability of 0.30, while long-distance trips longer than 8.0 miles are additionally treated as advance-type requests. For each advance-type request, the lead time is sampled from 6–23 dispatch slots; the request is visible from its shifted creation time but is committed to a vehicle only within the short executable service window defined in Section 3.3. For the dispatching experiments, five fixed seeds, namely, $0,1,2,3,4$, are used for request-type assignment, vehicle initialization, and other stochastic simulation components. Within the same city–fleet–seed setting, all dispatching algorithms use the same request stream, vehicle initialization, dispatching clock, and feasibility rules, so the comparison is made under the same simulation conditions. For forecasting experiments, all time-ordered samples are split chronologically into training, validation, and test periods in a ratio of 70%, 10%, and 20%, respectively. The first 70% of samples are used for model training, the following 10% are used for validation and model selection, and the remaining 20% are used for independent testing. Normalization statistics are computed only from the training period and then applied to the validation and test periods. The forecasting experiments are repeated using six random seeds, namely, $0,1,2,3,4,5$, and the reported forecasting results are summarized across the six runs. The online dispatching evaluation starts from the 80% temporal boundary of the processed time axis, which is consistent with the beginning of the forecasting test period.

Table 2. Simulation and preprocessing settings used for reproducibility. Bold text is used for column headings and item labels only; it does not indicate statistical significance.

Item	Setting
Temporal split	Chronological split with 70% training, 10% validation, and 20% testing; normalization statistics are computed only from the training period.
Input window	The historical input length of the forecasting model is set to 12 time steps.
Time granularity	Demand, speed, en-route supply, and context tensors are aligned to dispatch/prediction slots before sliding-window construction.
Road network	OpenStreetMap road graphs are processed with OSMnx; shortest-path distances are computed and mapped to the selected spatial units.
Speed state	Regional speed is derived from observed trip distance and duration and denoised through the demand-gated graph module.
Weather/context	Hourly temperature and precipitation records from Open-Meteo are aligned to the mobility timeline and expanded to the spatial units.
Vehicle initialization	Initial vehicle locations are sampled from recent pre-evaluation trip activity using the same seed for all policies.
Random seeds	Forecasting experiments use six random seeds, $0,1,2,3,4,5$, and dispatching experiments use five fixed seeds, $0,1,2,3,4$, for request-type assignment, vehicle initialization, and other stochastic simulation components.
Advance requests	Stochastic advance-type assignment probability of 0.30, with trips longer than 8.0 miles being additionally treated as advance-type requests; lead time of 6–23 dispatch slots; observed pickup time is treated as requested pickup time; the executable window covers two 5 min slots before and two 5 min slots after the requested pickup time.
Fleet sizes	NYC: 500/1000/1500/2000; Chicago-A: 300/400/500/650; Chicago-B: 900/1200/1500.
Sampling rule	When the raw evaluation stream is too large, a fixed-seed sample cap is applied consistently across policies, and prediction-side demand fields are scaled by the sampling ratio.
Dispatching evaluation	The dispatching evaluation starts from the 80% temporal boundary of the processed time axis, consistent with the forecasting test period.

reports the temporal split, random-seed settings, time granularity, road-network source, speed state, vehicle initialization, sampling rule, advance-request generation, and fleet-size settings used for reproducibility.

The experiments are implemented in Python 3.12.3 using PyTorch under Ubuntu Linux. The computing platform includes a single NVIDIA GeForce RTX 5090 GPU, 25 CPU cores, and 90 GB of memory. This environment is used for forecasting-model training, model inference, and online dispatching simulation. The main software libraries include PyTorch 2.8.0 for neural-network training and inference; NumPy 2.3.2, pandas 3.0.3, SciPy 1.17.1, and scikit-learn 1.8.0 for numerical processing, optimization, and evaluation; GeoPandas 1.1.3, NetworkX 3.6.1, OSMnx 2.1.0, Shapely 2.1.2, and PyProj 3.7.2 for spatial and road-network processing; and XGBoost 3.2.0, LightGBM 4.6.0, and CatBoost 1.2.10 for machine learning baselines. Matplotlib 3.10.9 is used for result visualization.

Table 3. Setting-specific DP-OTM matching-cost and risk-fusion parameters. The final column gives the configured/effective ${\beta }_c$, where the effective value is clipped to $[0,1]$.

Setting	${\mathit{\omega }}_1$ Distance	${\mathit{\omega }}_2$ Revenue	${\mathit{\omega }}_3$ Urgency	${\mathit{\omega }}_4$ Opportunity	${\mathit{\omega }}_5$ Risk	${\mathit{\alpha }}_{\mathit{c}}$	${\mathit{\beta }}_{\mathit{c}}$ Configured/Effective
NYC	1.05	0.78	0.95	0.78	0.92	1.00	1.00/1.00
Chicago-A	1.05	0.78	0.95	0.78	0.92	0.50	0.50/0.50
Chicago-B	2.35	0.88	1.65	0.30	0.56	0.10	1.20/1.00

reports the setting-specific matching-cost and risk-fusion parameters used in the mixed-request experiments. The five matching components are normalized before weighting, and one fixed parameter profile is used across all evaluated fleet sizes and all five dispatching seeds within each operating setting.

The shared UOT settings are

$${\epsilon }_{\mathrm{uot}}=0.05,{\tau }_v={\tau }_o=1.0,K_{\mathrm{sk}}=40,\gamma =0.10,$$

(61)

where $K_{\mathrm{sk}}$ is the fixed number of Sinkhorn iterations. Infeasible vehicle–request pairs are assigned a numerical sentinel cost of ${10}^6$, but this sentinel is excluded from feasible-entry cost normalization. The numerical constants are ${ϵ}_C={10}^{-9}$ for UOT cost normalization, ${ϵ}_{\mathrm{sk}}={10}^{-12}$ for the Sinkhorn denominators, and ${ϵ}_s={10}^{-8}$ for prior min–max normalization. The opportunity multiplier uses ${ϵ}_{\kappa }=0.05$.

The component scales are computed separately for each operating setting. Revenue is divided by the 95th percentile of the evaluated order fares, positive finite road-network distances are divided by their 75th percentile, and request urgency is divided by the 10 min executable waiting tolerance. The destination-opportunity scale is the 95th percentile of model-predicted opportunity values obtained from 24 evenly spaced prediction snapshots within the evaluation window. This offline prediction-only scale uses no realized future demand labels and is fixed before the corresponding policy simulations are compared. For strictly causal deployment, the same scale can instead be estimated from a preceding calibration window or updated from past prediction snapshots only. Each normalized component is clipped to $[0,1]$. The post-drop-off evaluation horizon is fixed at $H=30$ min, corresponding to six 5 min prediction steps in NYC and two 15 min prediction steps in Chicago-A and Chicago-B.

The parameter-selection procedure follows three stages. First, the component normalization rules and shared UOT settings are fixed. Second, preliminary setting-specific calibration runs screen matching-cost and risk-fusion profiles by jointly examining service feasibility, rejection, revenue, empty mileage, wait time, risk, DERLow20, and PDO_H, rather than optimizing a single indicator. Third, one profile is retained for each operating setting and fixed across all evaluated fleet sizes and five random seeds; no seed-specific retuning is performed. The procedure is an engineering screening rather than an exhaustive global search. The selected profiles are fixed operating points for the reported experiments, and their local sensitivity is evaluated through the one-at-a-time matching-weight analysis in Section 4.5.1.

The forecasting and dispatching layers are evaluated with different but connected metrics. The forecasting layer mainly uses MAE and RMSE to measure future regional demand errors, together with aggregate time-series and distributional comparisons to check whether the predicted demand follows the temporal evolution of the observed demand. The dispatching layer reports reject rate, revenue, empty miles, wait time, post-drop-off risk, DERLow20, and PDO_H. Reject rate and wait time describe service quality, revenue reflects completed-trip income, and empty miles measure the pickup distance before service. The post-drop-off metrics describe the future service environment of the vehicle landing zones after completed trips.

Table 4. Dispatching and mechanism-analysis metrics. Bold text is used for column headings and metric labels only; it does not indicate statistical significance.

Metric	Definition	Preferred Direction	Used in
Reject rate	Percentage of all requests that are not served within the feasible dispatching process.	Lower	Main comparison, ablation
Revenue	Total realized revenue from completed requests.	Higher	Main comparison, ablation
Empty miles	Vehicle deadheading distance before serving assigned requests.	Lower	Main comparison
Wait time	Average passenger service delay, including the request-side waiting delay and the vehicle-to-pickup travel time. The pre-activation lead time of advance requests is excluded.	Lower	Main comparison
Risk	Post-drop-off low-opportunity risk derived from realized future demand opportunity over horizon H; higher values indicate weaker subsequent service opportunity around selected drop-off zones. This metric does not represent road-safety or infrastructure risk.	Lower	Main comparison, ablation
DERLow20	Share of completed drop-offs whose future demand belongs to the low-opportunity bottom-20% group.	Lower	Risk mechanism analysis
PDOH	Average realized future demand opportunity around the drop-off zone within horizon H.	Higher	Risk mechanism analysis
AUC	Area under the ROC curve for identifying future low-opportunity zones using the predicted risk signal.	Higher	Risk diagnostics

defines these metrics and their preferred directions. The evaluation metric $\mathrm{Wait}$ is distinct from the request-urgency score $U_j^t$ used in the matching cost. Let ${\mathrm{Wait}}^{\mathrm{request}}$ denote the mean nonnegative slot-level delay, expressed in minutes, between a request’s first eligible dispatch interval and its successful assignment interval. At the city–seed–scenario–policy level, $\mathrm{Wait}$ is calculated as

$$\mathrm{Wait}={\mathrm{Wait}}^{\mathrm{request}}+{\displaystyle \frac{\mathrm{EmptyMiles}/\mathrm{Dispatched}}{v_c}}\times 60$$

(62)

where $\mathrm{EmptyMiles}/\mathrm{Dispatched}$ is the average vehicle-to-pickup distance of completed assignments and $v_c$ is the representative observed speed for operating setting c. The values of $v_c$ are 12.891 mph for NYC, 12.197 mph for Chicago-A, and 14.667 mph for Chicago-B. Thus, $\mathrm{Wait}$ combines the cross-interval request delay with the pickup-travel time implied by the executed assignments. For advance requests, the time before the request enters its executable activation window is not counted as passenger waiting time.

Because these indicators have different units and operational meanings, the dispatching analysis uses raw values, revenue–risk plots, normalized multi-indicator heatmaps, and post-drop-off mechanism plots together.

For forecasting comparison, this study includes three groups of baseline models. The first group consists of conventional statistical and machine learning methods, i.e., HA, LR, XGBoost, LightGBM, and CatBoost. The second group contains temporal deep learning models, i.e., CNN-ATTBiLSTM [4], Wavelet-MLP [16], and ID-DLA-CNNLSTM [17]. The third group contains graph-based and spatio-temporal neural networks, i.e., STGCN-VAE [13], A3T-GCN [6], AGCRN [7], ST-GIncep [19], DG-STMTL [21], GST-Former [42], and DVRGCN [20]. To ensure a consistent comparison, all forecasting models use the same chronological data split, historical input window, prediction target, and normalization protocol. For models requiring graph inputs, the common physical-distance graph is used when it is compatible with the model architecture; otherwise, the closest graph structure consistent with the original architectural requirements is adopted.

For dispatching comparison, Greedy-Nearest and Fixed-Interval Batch are used as generic operational baselines. The literature-based dispatching baselines include ADP-VFA [28], ClusterHopper-RH [27], and MMA [10], while DTA-Guidance [31], MO-IGA-lite [32], and ST-Batch [12] are additionally reported in the Chicago-B setting. To ensure a fair comparison across dispatching strategies, all methods are implemented under the same vehicle-state representation, request stream, dispatching clock, feasibility constraints, and evaluation interface while retaining their core decision mechanisms. To examine the role of the predictive signals in dispatching, four ablation variants are further considered: Base-UOT, $\mathit{\mu }$ only, $\mathit{\pi }$ only, and $\mathit{\mu }+\mathit{\pi }$. Base-UOT uses neither predicted destination opportunity nor low-opportunity risk; $\mathit{\mu }$ only uses the destination demand-opportunity signal; $\mathit{\pi }$ only uses the low-opportunity-risk signal; and $\mathit{\mu }+\mathit{\pi }$ combines both signals.

4.2. Forecasting Performance and Multi-Seed Stability

Table 5. Complete MAE/RMSE comparison across the three operating settings, reported as mean ± standard deviation over six random seeds. Lower values are better.

Model	NYC		Chicago-A		Chicago-B
	MAE	RMSE	MAE	RMSE	MAE	RMSE
HA	$2.2539\pm 0.0000$	$3.4363\pm 0.0000$	$1.8385\pm 0.0000$	$4.3229\pm 0.0000$	$8.0322\pm 0.0000$	$19.0748\pm 0.0000$
LR	$2.1945\pm 0.0079$	$3.2514\pm 0.0053$	$1.4305\pm 0.0089$	$2.8194\pm 0.0022$	$4.8421\pm 0.0146$	$8.7046\pm 0.0124$
XGBoost	$2.1634\pm 0.0006$	$3.2143\pm 0.0009$	$1.3929\pm 0.0011$	$2.7031\pm 0.0048$	$4.6939\pm 0.0000$	$9.2497\pm 0.0000$
CatBoost	$2.1774\pm 0.0008$	$3.2314\pm 0.0015$	$1.4135\pm 0.0023$	$2.7309\pm 0.0017$	$4.6944\pm 0.0000$	$8.5216\pm 0.0000$
LightGBM	$2.1669\pm 0.0003$	$3.2159\pm 0.0005$	$1.3967\pm 0.0018$	$2.7004\pm 0.0025$	$4.5863\pm 0.0000$	$8.3267\pm 0.0000$
Wavelet-MLP	$2.1562\pm 0.0039$	$3.2118\pm 0.0064$	$1.3608\pm 0.0047$	$2.6923\pm 0.0102$	$4.7043\pm 0.0315$	$8.5609\pm 0.0944$
CNN-ATTBiLSTM	$2.1616\pm 0.0031$	$3.2256\pm 0.0047$	$1.3457\pm 0.0104$	$2.7326\pm 0.0320$	$4.7298\pm 0.0287$	$8.6764\pm 0.1280$
ID-DLA-CNNLSTM	$2.1496\pm 0.0024$	$3.1993\pm 0.0049$	$1.3493\pm 0.0074$	$2.6999\pm 0.0249$	$4.5749\pm 0.0183$	$8.1675\pm 0.0418$
STGCN-VAE	$2.1452\pm 0.0042$	$3.2032\pm 0.0059$	$1.3364\pm 0.0092$	$2.6877\pm 0.0216$	$4.5755\pm 0.0157$	$8.2895\pm 0.0375$
A3T-GCN	$2.2741\pm 0.0776$	$3.4150\pm 0.1161$	$1.4039\pm 0.0259$	$3.0467\pm 0.1330$	$5.5743\pm 0.7424$	$10.5673\pm 1.3517$
AGCRN	$2.2818\pm 0.0375$	$3.4518\pm 0.0682$	$1.3385\pm 0.0106$	$2.6994\pm 0.0396$	$5.2605\pm 0.2595$	$10.0251\pm 0.6539$
ST-GIncep	$2.3248\pm 0.0382$	$3.4596\pm 0.0641$	$1.4219\pm 0.0072$	$2.8412\pm 0.0351$	$4.6219\pm 0.0510$	$7.9990\pm 0.0805$
DG-STMTL	$2.7861\pm 0.0385$	$4.2745\pm 0.0763$	$2.3794\pm 0.0754$	$6.4881\pm 0.4993$	$5.3299\pm 0.2216$	$9.7948\pm 0.6178$
GST-Former	$3.1894\pm 0.0069$	$4.9461\pm 0.0131$	$2.4868\pm 0.0392$	$6.8285\pm 0.1559$	$6.5996\pm 0.0648$	$12.6418\pm 0.0710$
DVRGCN	$3.2326\pm 0.0420$	$5.0058\pm 0.0559$	$2.0837\pm 0.0362$	$4.9383\pm 0.1582$	$6.5112\pm 0.0649$	$12.2139\pm 0.1939$
CC-STMT	$2.1156\pm 0.0059$	$3.1129\pm 0.0013$	$1.3143\pm 0.0034$	$2.5823\pm 0.0157$	$4.2249\pm 0.0084$	$7.5883\pm 0.0126$

reports the mean and standard deviation of MAE and RMSE over six random seeds for all forecasting models under the three operating settings. CC-STMT obtains MAE/RMSE values of $2.1156\pm 0.0059$/$3.1129\pm 0.0013$ in NYC, $1.3143\pm 0.0034$/ $2.5823\pm 0.0157$ in Chicago-A, and $4.2249\pm 0.0084$/$7.5883\pm 0.0126$ in Chicago-B, which remain in a lower error range within the compared models. Compared with the best-performing non-CC-STMT baseline for each metric in each setting, these results correspond to MAE reductions of 1.38%, 1.65%, and 7.65% and RMSE reductions of 2.70%, 3.92%, and 5.14% in NYC, Chicago-A, and Chicago-B, respectively. In NYC, methods such as STGCN-VAE, Wavelet-MLP, XGBoost, and LightGBM produce values close to CC-STMT, indicating that the full taxi-zone setting contains temporal patterns that can be captured by several model families. The separation among models becomes larger in Chicago-A and Chicago-B. In particular, the citywide community-area setting of Chicago-B has stronger demand fluctuations, coarser spatial aggregation, and more complex spatial correlations; under this setting, CC-STMT records the lowest MAE and RMSE among the compared models. The reduction direction relative to the best-performing non-CC-STMT baseline is consistent across all six seeds for each city–metric comparison. Exact two-sided paired Wilcoxon tests across the six seeds yield $p=0.03125$ for these comparisons.

Figure 8 visualizes the six-seed mean MAE and RMSE values reported in Table 5, with error bars denoting one standard deviation. The figure shows that CC-STMT remains in a lower error range across the three settings, while several baseline models remain close in NYC. This comparison summarizes cross-setting point-forecasting performance; the ranking quality of the low-opportunity-risk signal is evaluated separately in Section 4.4.

Numerical errors alone do not fully indicate whether the forecasts are suitable for dispatching. Figure 9 therefore examines aggregate temporal tracking across the three settings. The predicted aggregate demand follows the main rises and falls of the observed demand, including repeated increases and decreases in Chicago-A and Chicago-B. A complementary distributional comparison is provided in Figure 10. Together, these analyses assess aggregate temporal tracking and marginal distributional agreement; they do not by themselves evaluate regional risk-ranking performance, which is examined separately below.

Figure 11 and Figure 12 further examine the structure of CC-STMT. Figure 11 compares the full model with variants that remove closed-loop feedback. In NYC and Chicago-A, removing en-route supply feedback increases WMAPE, showing that the en-route supply state contributes information beyond the remaining input variables in these two settings. The increase is smaller in Chicago-B. Figure 12 compares the dual-graph setting with spatial-only, semantic-only, and self-loop-only variants. The complete dual-graph design keeps a stable error profile across the three settings, suggesting that physical distance and functional similarity provide complementary spatial information. The physical graph reflects road-network accessibility, while the semantic graph adds demand correlations among functionally similar regions.

Taken together, Table 5 and Figure 8, Figure 9, Figure 10, Figure 11 and Figure 12 characterize the demand forecasting performance and component sensitivity of CC-STMT. The following dispatching experiments use $\mu$ and $\pi$ as the destination-opportunity and low-opportunity-risk inputs of DP-OTM, while the ranking quality of $\pi$ is evaluated separately in the risk-diagnostic analysis.

4.3. Mixed-Request Dispatching Performance

The dispatching experiments are conducted on mixed on-demand and advance-request streams. On-demand requests enter the service process after creation, whereas advance requests are visible earlier but become dispatchable only near their requested pickup times. Both request types share the same vehicle pool. A current assignment therefore affects not only whether the current passenger is served, but also where the vehicle will become available after completing the trip. A trip with higher immediate revenue may still leave the vehicle in an area with weak future demand, while a moderate-revenue trip can be operationally useful if its destination has stronger subsequent request opportunities. DP-OTM incorporates this destination opportunity and risk information into the online matching process instead of relying only on pickup distance and current trip revenue.

The revenue–risk analysis compares dispatching algorithms in the revenue–risk plane, where the horizontal axis is post-drop-off low-opportunity risk and the vertical axis is revenue. The results show that revenue and future landing risk do not always improve together: some strategies obtain higher revenue with higher risk, whereas others reduce risk with a loss in revenue or service capacity. Across the evaluated fleet sizes in NYC, Chicago-A, and Chicago-B, DP-OTM is generally positioned on the lower-risk side of the comparison while retaining comparable revenue in many city–fleet combinations, although its relative position varies by operating setting and fleet size. The revenue–risk comparison is reported in Figure 13; the specific contribution of the predicted opportunity and risk fields is examined through the ablation analysis below.

Figure 14 extends the comparison to rejection, revenue, empty miles, wait time, and risk. Since these indicators have different units, the figure applies direction-aligned min–max normalization within each city–fleet panel and reports the mean normalized score as a compact summary. The heatmap shows that DP-OTM often achieves lower rejection and destination-side risk, although these reductions can be accompanied by higher empty mileage or waiting time in some city–fleet combinations. Some baselines perform well on individual indicators such as empty miles or wait time but lose ground on revenue or risk. The magnitude and direction of these operational trade-offs vary across cities and fleet sizes. This agrees with the detailed revenue–risk pattern reported in Figure 13: mixed-request dispatching is mainly about coordinating current service quality and future vehicle spatial states, rather than improving one isolated indicator. The corresponding unnormalized values for rejection, revenue, empty miles, wait time, and risk are reported in the detailed dispatch benchmark subsection (Section 4.6).

4.4. Ablation and Risk-Mechanism Analysis

To understand how destination opportunity and low-opportunity risk affect dispatching, the experiments compare Base-UOT, $\mu$ only, $\pi$ only, $\mu +\pi$, and DP-OTM. Figure 15 reports the ablation results on the risk metric. Compared with Base-UOT, introducing $\pi$ or $\mu +\pi$ lowers low-opportunity exposure in all three settings. DP-OTM achieves a low-risk outcome in NYC and Chicago-B and remains close to $\mu +\pi$ in Chicago-A. This result shows that the predicted destination-opportunity and low-opportunity-risk signals enter the assignment decisions and change the vehicle landing regions, rather than remaining only as forecasting outputs.

The usefulness of $\pi$ for dispatching depends on whether it is related to future low-opportunity regions.

Table 6. Risk-signal diagnostic summary for future low-opportunity zones. Bold text is used for column headings and setting labels only; it does not indicate statistical significance.

Setting	Target Event	AUC
NYC	Low20FutureDemand	0.902
Chicago-A	Low20FutureDemand	0.918
Chicago-B	Low20FutureDemand	0.916

reports AUC values of 0.902 for NYC, 0.918 for Chicago-A, and 0.916 for Chicago-B, showing that $\pi$ provides an effective ranking signal for future low-opportunity zones. The shared-coordinate ROC comparison and corresponding group-wise risk distributions are reported in Figure 16 and Figure 17.

The post-drop-off mechanism is further evaluated by DERLow20 and PDO_H. DERLow20 measures the proportion of completed trips whose drop-off zones fall into the future bottom-20% opportunity group, and PDO_H measures the realized future demand opportunity around the drop-off zones within horizon H.

Table 7. Representative post-drop-off mechanism metrics under mixed-request ablation. Bold text is used for column headings, setting labels, and metric labels only; it does not indicate statistical significance. Downward and upward arrows indicate that lower and higher values are preferred, respectively.

Setting	Metric	Base-UOT	$\mathit{\mu }$ Only	$\mathit{\pi }$ Only	$\mathit{\mu }+\mathit{\pi }$	DP-OTM
NYC	DERLow20 (%) ↓	10.58	8.81	3.08	2.89	2.59
	PDOH ↑	78.4	88.1	88.4	97.5	98.8
Chicago-A	DERLow20 (%) ↓	4.47	3.90	3.58	3.37	3.53
	PDOH ↑	49.1	53.7	51.8	55.0	54.7
Chicago-B	DERLow20 (%) ↓	2.91	2.64	1.44	1.33	1.32
	PDOH ↑	283.2	305.4	320.6	336.0	336.3

reports the complete aggregate values. Compared with Base-UOT, DP-OTM reduces DERLow20 from 10.58% to 2.59% in NYC, from 4.47% to 3.53% in Chicago-A, and from 2.91% to 1.32% in Chicago-B. At the same time, PDO_H increases from 78.4 to 98.8, from 49.1 to 54.7, and from 283.2 to 336.3 in the three settings, respectively. These changes indicate that after destination opportunity and risk are introduced, completed trips are less likely to leave vehicles in future low-opportunity zones and more likely to end in areas with stronger subsequent request opportunities. In Chicago-A, $\mu +\pi$ is slightly better than DP-OTM on DERLow20 and PDO_H, while the broader normalized indicators in Figure 14 show that DP-OTM retains a competitive multi-indicator profile in this setting. The corresponding visual comparison is provided in Figure 18.

Figure 19 reports hourly served and rejected requests together with realized dispatch risk, while Figure 20 reports hourly deadzone exposure and post-drop-off opportunity. The hourly patterns are broadly consistent with the aggregate post-drop-off results across periods of higher and lower demand.

4.5. Robustness and Sensitivity Analysis

The robustness and sensitivity analysis considers four factors: the matching-weight configuration, the constructed advance-request rules, simulated passenger-cancellation and driver-rejection behavior, and the length of the evaluation window. The analyses use the same three operating settings and five random seeds as the main dispatching evaluation.

4.5.1. Matching-Weight Sensitivity

A one-at-a-time sensitivity analysis varies the pickup-distance, destination-opportunity, and low-opportunity-risk coefficients using multipliers of 0, $0.5$, $1.5$, and $2.0$ relative to their default values. Together with the default profile, 13 configurations are evaluated for each operating setting. Across the tested multiplier sequence, increasing either the destination-opportunity coefficient or the low-opportunity-risk coefficient consistently reduces risk and DERLow20 while increasing PDO_H in all three settings. The numerical default profiles and shared UOT settings are reported in Table 3 and Equation (61).

Table 8. Representative matching-weight sensitivity results. Entries report percentage changes relative to the default weight profile.

Setting	Opportunity Weight $\times 2$			Risk Weight $\times 2$			$\mathbf{\Delta }$ Empty Miles, Distance $\times 0$
	$\mathbf{\Delta }$ Risk	$\mathbf{\Delta }$ DERLow20	$\mathbf{\Delta }$ PDOH	$\mathbf{\Delta }$ Risk	$\mathbf{\Delta }$ DERLow20	$\mathbf{\Delta }$ PDOH
NYC	$-12.75\%$	$-8.96\%$	$+7.15\%$	$-4.38\%$	$-7.18\%$	$+1.54\%$	$+240.39\%$
Chicago-A	$-5.91\%$	$-6.73\%$	$+3.80\%$	$-1.87\%$	$-5.68\%$	$+0.64\%$	$+238.71\%$
Chicago-B	$-5.91\%$	$-6.14\%$	$+4.07\%$	$-5.42\%$	$-23.58\%$	$+3.36\%$	$+276.28\%$

reports representative results for doubling the destination-side coefficients and removing the pickup-distance coefficient. Stronger destination-side guidance improves the post-drop-off indicators, while the associated immediate operational effects remain city-dependent. Removing the pickup-distance term increases empty mileage by 240.39% in NYC, 238.71% in Chicago-A, and 276.28% in Chicago-B. The default coefficients are therefore retained as a fixed operating point rather than interpreted as globally optimal or directly transferable parameters.

4.5.2. Advance-Request Generation Sensitivity

The advance-request sensitivity experiment evaluates nine profiles: the default profile, two alternative advance-request proportions, two activation-window settings, two lead-time settings, and two long-trip thresholds. Base-UOT and DP-OTM are compared under every profile using the same five seeds. As summarized in

Table 9. Number of advance-request generation profiles in which DP-OTM is favorable relative to Base-UOT, based on the five-seed mean results.

Setting	Lower Reject	Lower Risk	Lower DERLow20	Higher ${\mathbf{PDO}}_{\mathit{H}}$	Lower Wait
NYC	$9/9$	$9/9$	$9/9$	$9/9$	$9/9$
Chicago-A	$9/9$	$9/9$	$9/9$	$9/9$	$7/9$
Chicago-B	$9/9$	$9/9$	$9/9$	$9/9$	$7/9$

, DP-OTM obtains lower total rejection, lower destination-side low-opportunity risk, lower DERLow20, and higher PDO_H under all nine profiles in each operating setting. These four directions also hold across all five seeds.

Table 10. Exact configurations used in the advance-request generation sensitivity experiment.

Profile	Advance Probability	Activation Window (Slots per Side)	Lead-Time Range (Slots)	Long-Trip Threshold (Miles)
BASE	0.30	2	6–23	8.0
ADV_RATIO_0.15	0.15	2	6–23	8.0
ADV_RATIO_0.45	0.45	2	6–23	8.0
WINDOW_1	0.30	1	6–23	8.0
WINDOW_3	0.30	3	6–23	8.0
LEAD_SHORT	0.30	2	3–11	8.0
LEAD_LONG	0.30	2	12–35	8.0
LONGTRIP_6	0.30	2	6–23	6.0
LONGTRIP_10	0.30	2	6–23	10.0

lists the exact profile definitions. The activation-window entry gives the number of 5 min dispatch slots on each side of the requested pickup time, and the upper lead-time bound is exclusive; therefore, the sampled integer ranges are 6–23, 3–11, and 12–35 slots. Only the factor named by each alternative profile is changed from BASE.

The activation-window setting produces the clearest operational response. A wider window allows advance requests to enter executable matching earlier, which can improve destination-side opportunity indicators but can also reserve current capacity prematurely and increase rejection. By contrast, changing the announcement lead time beyond the executable activation horizon has limited influence on most dispatching indicators. DP-OTM obtains lower five-seed mean wait time in all nine NYC profiles and in seven of the nine profiles in both Chicago-A and Chicago-B.

4.5.3. Passenger-Cancellation and Driver-Rejection Robustness

A scenario-based behavioral robustness experiment introduces four passenger-cancellation and driver-rejection stress levels: NONE, LOW, MEDIUM, and HIGH. The experiment uses explicit probability functions evaluated at each allocation attempt and is intended as a controlled stress analysis rather than as a behavioral model calibrated from proprietary platform observations.

Let ${\Delta }_{\mathrm{slot}}=5$ min, and let ${\delta }_j^t$ denote the nonnegative service-delay slots used by the passenger-cancellation model:

$${\delta }_j^t=\left\{\begin{array}{cc}\max \left(0,{\displaystyle \frac{t-t_j^{\mathrm{create}}}{{\Delta }_{\mathrm{slot}}}}\right),\hfill & o_j\in {\mathcal{O}}^{\mathrm{on}},\hfill \\ \max \left(0,{\displaystyle \frac{t-t_j^{\mathrm{pickup}}}{{\Delta }_{\mathrm{slot}}}}\right),\hfill & o_j\in {\mathcal{O}}^{\mathrm{adv}}.\hfill \end{array}\right.$$

(63)

For stress profile ℓ, the passenger-cancellation probability evaluated at an allocation attempt is

$$p_{j,\ell }^{\mathrm{can}}\left(t\right)=\min \left\{p_{\max ,\ell }^{\mathrm{can}},p_{0,\ell }^{\mathrm{can}}+p_{\mathrm{delay},\ell }^{\mathrm{can}}{\delta }_j^t\right\}.$$

(64)

Thus, the pre-activation lead time of an advance request is not treated as passenger waiting. For a proposed feasible pair, the normalized pickup distance is

$${\tilde{d}}_{ij}^p=\min \left\{1,\max \left(0,{\displaystyle \frac{d_{ij}^p}{d_j^{\max }}}\right)\right\},$$

(65)

and the driver-rejection probability is

$$p_{ij,\ell }^{\mathrm{drv}}\left(t\right)=\min \left\{p_{\max ,\ell }^{\mathrm{drv}},r_{0,\ell }+r_{d,\ell }{\tilde{d}}_{ij}^p+r_{\pi ,\ell }{\pi }_{z_j^d}^{t+h}\right\}.$$

(66)

Independent Bernoulli draws are generated with fixed city–seed–profile random streams. A passenger-canceled request is removed from the active pool and reported separately while remaining part of final unserved demand. If a driver rejects a proposed allocation, the match is not executed; the vehicle remains available, and the request remains in the pool, subject to its original expiration and cancellation rules, so that it may be offered again.

Table 11. Passenger-cancellation and driver-rejection stress parameters. The passenger parameters are the base probability, per-delay-slot increment, and probability cap; the driver parameters are the intercept, normalized-distance coefficient, destination-risk coefficient, and probability cap.

Profile	${\mathit{p}}_0^{\mathbf{can}}$	${\mathit{p}}_{\mathbf{delay}}^{\mathbf{can}}$	${\mathit{p}}_{\max }^{\mathbf{can}}$	${\mathit{r}}_0$	${\mathit{r}}_{\mathit{d}}$	${\mathit{r}}_{\mathit{\pi }}$	${\mathit{p}}_{\max }^{\mathbf{drv}}$
NONE	0	0	0	0	0	0	0
LOW	0.002	0.010	0.08	0.005	0.035	0.02	0.10
MEDIUM	0.005	0.025	0.20	0.010	0.080	0.05	0.25
HIGH	0.010	0.050	0.40	0.020	0.150	0.10	0.45

reports all stress parameters.

Across all three settings, all four stress levels, and all five seeds, DP-OTM retains lower total rejection, lower destination-side low-opportunity risk, lower DERLow20, and higher PDO_H than Base-UOT. DP-OTM obtains lower five-seed mean wait time in all four NYC profiles, three of the four Chicago-A profiles, and all four Chicago-B profiles.

Table 12. Behavioral robustness in the HIGH passenger-cancellation and driver-rejection scenario. Cancellation and driver offer rejection rates are DP-OTM five-seed means; the remaining entries are changes of DP-OTM relative to Base-UOT.

Setting	Cancellation (%)	Driver Offer Rejection (%)	$\mathbf{\Delta }$ Reject (pp)	$\mathbf{\Delta }$ Risk (%)	$\mathbf{\Delta }$ DERLow20 (%)	$\mathbf{\Delta }$${\mathbf{PDO}}_{\mathit{H}}$ (%)	$\mathbf{\Delta }$ Empty Miles (%)	$\mathbf{\Delta }$ Wait (%)
NYC	11.90	6.35	$-17.66$	$-39.91$	$-75.08$	$+24.48$	$+36.71$	$-8.63$
Chicago-A	5.94	5.68	$-0.67$	$-14.74$	$-21.24$	$+10.89$	$-2.43$	$-0.29$
Chicago-B	7.99	4.74	$-2.17$	$-19.06$	$-53.06$	$+18.07$	$+12.39$	$-1.89$

reports the HIGH-stress results. The destination-side directions remain stable, while the immediate operational effects differ by setting. In the HIGH-stress scenario, NYC shows higher empty mileage but lower wait time, Chicago-A shows slightly lower empty mileage and an almost unchanged but slightly lower wait time, and Chicago-B shows higher empty mileage but lower wait time.

4.5.4. Extended Seven-Day Evaluation

The original 24 h NYC window and 72 h Chicago windows are extended to continuous seven-day evaluation periods. Each setting is evaluated using Base-UOT and DP-OTM over five seeds. The same destination-side result directions are observed over the seven-day evaluation periods: DP-OTM retains lower destination-side low-opportunity risk and DERLow20 and higher PDO_H in all three operating settings.

Table 13. DP-OTM changes relative to Base-UOT over the continuous seven-day evaluation. Reject changes are reported in percentage points, and the remaining entries are percentage changes.

Setting	$\mathbf{\Delta }$ Reject	$\mathbf{\Delta }$ Revenue	$\mathbf{\Delta }$ Empty Miles	$\mathbf{\Delta }$ Risk	$\mathbf{\Delta }$ Wait	$\mathbf{\Delta }$ DERLow20	$\mathbf{\Delta }$${\mathbf{PDO}}_{\mathit{H}}$
NYC	$-27.36$ pp	$+166.89\%$	$+149.49\%$	$-48.34\%$	$-18.11\%$	$-83.61\%$	$+47.02\%$
Chicago-A	$-0.64$ pp	$-0.60\%$	$-0.54\%$	$-14.16\%$	$+1.57\%$	$-20.33\%$	$+11.23\%$
Chicago-B	$-7.71$ pp	$+9.76\%$	$+17.71\%$	$-24.39\%$	$-3.16\%$	$-57.81\%$	$+25.69\%$

shows that the associated operational effects remain city-dependent. NYC obtains substantial reductions in rejection and destination-side exposure, together with higher empty mileage but lower wait time. Chicago-A shows smaller destination-side improvements, a modest revenue decrease, nearly unchanged empty mileage, and a slight increase in wait time. Chicago-B retains lower rejection and wait time while increasing empty mileage. The experiment extends the temporal coverage to one continuous week, but it does not represent cross-season or long-term platform deployment.

Taken together, these analyses show that the destination-side risk and opportunity results remain consistent across the tested matching-weight profiles, constructed advance-request rules, behavioral stress levels, and evaluation-window lengths. The associated rejection, revenue, empty-mileage, and wait-time effects remain dependent on the operating setting. The default matching coefficients therefore represent a fixed operating point within the tested simulation design rather than universally optimal parameters.

4.6. Detailed Dispatch Benchmark Values

Table 14. Mixed advance-request dispatching performance across the three operating settings. Results are reported as the mean ± standard deviation over five random seeds. Bold text is used for column headings and setting labels only; it does not indicate statistical significance. Here, “k” denotes thousand.

Fleet	Algorithm	Reject (%)	Revenue ($)	Empty Miles	Risk	Wait (min)	Time (s)
NYC
500	Greedy Nearest	66.95 ± 0.84	445.5k ± 11.3k	5061.7 ± 313.0	0.4786 ± 0.0011	3.92 ± 0.07	4.86 ± 0.14
500	Fixed-Interval Batch	71.62 ± 0.93	453.0k ± 12.6k	5003.4 ± 178.3	0.4856 ± 0.0009	5.49 ± 0.06	0.88 ± 0.01
500	ADP-VFA Dispatch	73.82 ± 0.77	437.2k ± 11.6k	4847.0 ± 233.0	0.4608 ± 0.0028	4.28 ± 0.06	1.00 ± 0.01
500	ClusterHopper-RH	76.04 ± 0.79	435.6k ± 12.9k	6185.0 ± 205.0	0.4923 ± 0.0017	3.41 ± 0.07	1.02 ± 0.02
500	MMA without Relocation	65.90 ± 0.36	512.2k ± 4.6k	5863.7 ± 166.8	0.4681 ± 0.0006	5.12 ± 0.04	0.95 ± 0.01
500	DP-OTM	58.76 ± 0.93	576.1k ± 10.5k	8069.3 ± 337.6	0.4592 ± 0.0039	7.05 ± 0.03	1.92 ± 0.07
1000	Greedy Nearest	43.73 ± 0.91	723.8k ± 12.4k	10,106.7 ± 295.2	0.4692 ± 0.0009	3.58 ± 0.03	8.79 ± 0.15
1000	Fixed-Interval Batch	46.62 ± 1.34	755.8k ± 15.9k	11,715.3 ± 548.1	0.4708 ± 0.0009	4.85 ± 0.05	1.55 ± 0.03
1000	ADP-VFA Dispatch	49.63 ± 1.49	735.6k ± 17.8k	10,720.2 ± 551.3	0.4556 ± 0.0006	4.01 ± 0.04	1.75 ± 0.05
1000	ClusterHopper-RH	50.62 ± 1.88	748.1k ± 20.8k	13,475.2 ± 745.1	0.4721 ± 0.0009	3.33 ± 0.04	1.74 ± 0.06
1000	MMA without Relocation	39.32 ± 0.61	812.2k ± 8.0k	13,128.9 ± 537.3	0.4594 ± 0.0004	4.58 ± 0.05	1.71 ± 0.03
1000	DP-OTM	36.34 ± 1.36	834.3k ± 14.6k	14,883.0 ± 359.1	0.4491 ± 0.0009	6.10 ± 0.05	4.08 ± 0.09
1500	Greedy Nearest	27.67 ± 1.15	907.7k ± 13.0k	14,046.6 ± 640.5	0.4654 ± 0.0010	3.27 ± 0.04	11.89 ± 0.29
1500	Fixed-Interval Batch	25.88 ± 1.78	964.7k ± 17.5k	20,204.8 ± 1089.4	0.4646 ± 0.0010	4.41 ± 0.04	2.26 ± 0.05
1500	ADP-VFA Dispatch	26.51 ± 1.78	965.4k ± 16.2k	19,709.8 ± 954.1	0.4556 ± 0.0011	3.89 ± 0.04	2.42 ± 0.06
1500	ClusterHopper-RH	28.29 ± 1.67	962.8k ± 15.6k	22,159.0 ± 775.0	0.4650 ± 0.0010	3.44 ± 0.05	2.36 ± 0.04
1500	MMA without Relocation	22.35 ± 1.17	991.1k ± 12.4k	21,221.4 ± 683.8	0.4588 ± 0.0006	4.23 ± 0.04	2.55 ± 0.04
1500	DP-OTM	19.51 ± 1.23	1008.7k ± 12.1k	21,818.4 ± 722.5	0.4532 ± 0.0007	5.25 ± 0.05	5.60 ± 0.10
2000	Greedy Nearest	16.19 ± 0.61	1031.7k ± 4.6k	16,631.7 ± 480.4	0.4631 ± 0.0006	2.92 ± 0.03	14.22 ± 0.25
2000	Fixed-Interval Batch	13.44 ± 0.61	1083.4k ± 4.1k	24,426.6 ± 507.6	0.4619 ± 0.0007	3.79 ± 0.06	2.57 ± 0.04
2000	ADP-VFA Dispatch	13.88 ± 0.64	1081.7k ± 4.6k	24,173.9 ± 412.2	0.4575 ± 0.0009	3.50 ± 0.04	2.76 ± 0.06
2000	ClusterHopper-RH	15.79 ± 0.51	1074.4k ± 3.9k	25,468.8 ± 340.0	0.4624 ± 0.0006	3.20 ± 0.06	2.73 ± 0.04
2000	MMA without Relocation	11.57 ± 0.14	1096.2k ± 2.4k	25,183.5 ± 224.1	0.4593 ± 0.0007	3.72 ± 0.06	2.96 ± 0.05
2000	DP-OTM	9.98 ± 0.45	1104.8k ± 4.2k	25,509.9 ± 452.6	0.4566 ± 0.0008	4.27 ± 0.11	6.14 ± 0.13
Chicago-A
300	Greedy Nearest	22.12 ± 0.29	426.6k ± 2.0k	23,564.8 ± 216.6	0.3757 ± 0.0006	2.98 ± 0.02	3.50 ± 0.02
300	Fixed-Interval Batch	18.17 ± 0.13	469.8k ± 0.2k	33,424.4 ± 308.1	0.3825 ± 0.0009	4.02 ± 0.03	0.98 ± 0.01
300	ADP-VFA Dispatch	17.70 ± 0.12	468.9k ± 0.3k	32,854.3 ± 342.9	0.3705 ± 0.0012	3.93 ± 0.04	1.10 ± 0.01
300	ClusterHopper-RH	18.32 ± 0.11	475.2k ± 0.3k	34,027.0 ± 347.1	0.3763 ± 0.0011	4.10 ± 0.04	1.17 ± 0.01
300	MMA without Relocation	17.42 ± 0.08	464.6k ± 0.4k	33,462.8 ± 213.0	0.3733 ± 0.0012	3.99 ± 0.02	1.14 ± 0.01
300	DP-OTM	17.23 ± 0.10	466.0k ± 0.3k	33,409.0 ± 294.5	0.3643 ± 0.0011	3.97 ± 0.03	1.78 ± 0.02
400	Greedy Nearest	13.52 ± 0.23	478.0k ± 1.8k	26,226.1 ± 195.7	0.3675 ± 0.0016	2.98 ± 0.01	4.61 ± 0.01
400	Fixed-Interval Batch	9.35 ± 0.22	515.8k ± 0.6k	35,912.5 ± 297.5	0.3711 ± 0.0012	3.90 ± 0.03	1.16 ± 0.02
400	ADP-VFA Dispatch	9.10 ± 0.20	514.4k ± 0.7k	35,491.3 ± 344.2	0.3645 ± 0.0016	3.84 ± 0.03	1.28 ± 0.01
400	ClusterHopper-RH	9.42 ± 0.19	518.2k ± 0.4k	36,192.7 ± 366.2	0.3675 ± 0.0013	3.93 ± 0.04	1.35 ± 0.02
400	MMA without Relocation	8.90 ± 0.17	512.1k ± 0.5k	35,570.9 ± 317.7	0.3657 ± 0.0013	3.84 ± 0.03	1.32 ± 0.01
400	DP-OTM	8.84 ± 0.21	512.5k ± 0.7k	35,754.8 ± 328.7	0.3606 ± 0.0013	3.86 ± 0.03	2.09 ± 0.04
500	Greedy Nearest	8.09 ± 0.29	511.2k ± 2.2k	27,731.0 ± 216.2	0.3634 ± 0.0015	2.97 ± 0.01	5.63 ± 0.05
500	Fixed-Interval Batch	4.22 ± 0.13	540.9k ± 0.9k	36,150.3 ± 180.8	0.3651 ± 0.0017	3.72 ± 0.02	1.26 ± 0.02
500	ADP-VFA Dispatch	4.11 ± 0.12	540.0k ± 0.8k	36,090.8 ± 181.3	0.3622 ± 0.0018	3.70 ± 0.02	1.41 ± 0.04
500	ClusterHopper-RH	4.28 ± 0.13	541.9k ± 0.7k	36,381.0 ± 178.3	0.3635 ± 0.0018	3.74 ± 0.02	1.47 ± 0.01
500	MMA without Relocation	4.02 ± 0.11	538.9k ± 0.9k	36,077.1 ± 196.6	0.3631 ± 0.0018	3.70 ± 0.02	1.44 ± 0.02
500	DP-OTM	4.04 ± 0.14	539.1k ± 0.8k	36,461.9 ± 137.0	0.3601 ± 0.0018	3.74 ± 0.02	2.36 ± 0.03
650	Greedy Nearest	3.50 ± 0.14	540.0k ± 1.1k	27,693.3 ± 117.7	0.3602 ± 0.0017	2.82 ± 0.01	7.12 ± 0.09
650	Fixed-Interval Batch	1.25 ± 0.08	555.9k ± 0.8k	33,126.9 ± 150.3	0.3605 ± 0.0018	3.30 ± 0.02	1.30 ± 0.01
650	ADP-VFA Dispatch	1.25 ± 0.07	555.6k ± 0.8k	33,145.5 ± 169.1	0.3598 ± 0.0019	3.30 ± 0.02	1.44 ± 0.01
650	ClusterHopper-RH	1.29 ± 0.09	556.2k ± 0.7k	33,276.2 ± 180.2	0.3600 ± 0.0018	3.32 ± 0.02	1.50 ± 0.01
650	MMA without Relocation	1.24 ± 0.08	555.4k ± 0.8k	33,075.5 ± 128.4	0.3600 ± 0.0019	3.30 ± 0.01	1.46 ± 0.01
650	DP-OTM	1.25 ± 0.08	555.3k ± 0.8k	33,470.9 ± 112.8	0.3589 ± 0.0018	3.34 ± 0.01	2.57 ± 0.02
Chicago-B
900	Greedy Nearest	38.21 ± 0.24	2564.0k ± 10.6k	56,140.1 ± 808.4	0.3717 ± 0.0016	3.84 ± 0.02	5.35 ± 0.08
900	ADP-VFA Dispatch	35.52 ± 0.23	2965.4k ± 9.0k	102,000.5 ± 1221.4	0.2861 ± 0.0010	6.90 ± 0.04	12.93 ± 0.15
900	DTA-Guidance	41.59 ± 0.25	2725.0k ± 9.1k	97,998.3 ± 758.4	0.2182 ± 0.0012	5.69 ± 0.02	10.88 ± 0.08
900	ST-Batch	38.42 ± 0.56	2901.9k ± 21.0k	99,924.5 ± 1252.5	0.3500 ± 0.0010	7.21 ± 0.02	11.10 ± 0.10
900	MO-IGA-lite	35.81 ± 0.10	2950.0k ± 4.0k	112,141.7 ± 677.9	0.2470 ± 0.0006	7.33 ± 0.01	14.21 ± 0.13
900	MMA without Relocation	43.73 ± 0.32	2657.3k ± 14.0k	101,464.3 ± 975.7	0.3088 ± 0.0005	5.92 ± 0.02	10.39 ± 0.05
900	DP-OTM	33.31 ± 0.33	3024.0k ± 12.6k	97,847.4 ± 1273.7	0.2902 ± 0.0014	6.78 ± 0.03	21.84 ± 0.20
1200	Greedy Nearest	23.42 ± 0.46	3172.8k ± 19.1k	106,469.9 ± 1866.7	0.3710 ± 0.0008	5.01 ± 0.03	6.69 ± 0.15
1200	ADP-VFA Dispatch	21.50 ± 0.43	3462.3k ± 14.8k	149,621.5 ± 1704.6	0.3263 ± 0.0014	6.98 ± 0.03	16.31 ± 0.17
1200	DTA-Guidance	27.76 ± 0.33	3241.6k ± 11.6k	139,799.2 ± 891.1	0.2748 ± 0.0018	5.98 ± 0.02	13.87 ± 0.10
1200	ST-Batch	22.18 ± 0.45	3457.1k ± 15.4k	152,111.1 ± 1705.6	0.3665 ± 0.0012	7.24 ± 0.02	14.37 ± 0.26
1200	MO-IGA-lite	21.91 ± 0.44	3448.4k ± 15.1k	158,243.6 ± 1582.1	0.2990 ± 0.0014	7.30 ± 0.03	17.94 ± 0.29
1200	MMA without Relocation	28.37 ± 0.39	3212.3k ± 14.8k	145,168.6 ± 1399.8	0.3413 ± 0.0016	6.24 ± 0.02	13.58 ± 0.12
1200	DP-OTM	19.93 ± 0.28	3500.8k ± 9.5k	145,706.8 ± 1348.9	0.3315 ± 0.0009	6.85 ± 0.04	26.14 ± 0.37
1500	Greedy Nearest	13.92 ± 0.28	3571.9k ± 11.3k	159,895.7 ± 3090.7	0.3722 ± 0.0007	5.20 ± 0.05	8.95 ± 0.17
1500	ADP-VFA Dispatch	11.50 ± 0.24	3805.5k ± 7.8k	190,324.2 ± 2652.7	0.3485 ± 0.0004	6.47 ± 0.04	19.30 ± 0.20
1500	DTA-Guidance	15.92 ± 0.30	3652.4k ± 9.9k	179,414.3 ± 2774.6	0.3198 ± 0.0014	5.80 ± 0.04	16.45 ± 0.17
1500	ST-Batch	11.51 ± 0.23	3810.1k ± 7.6k	194,183.0 ± 3136.0	0.3704 ± 0.0003	6.54 ± 0.06	17.46 ± 0.16
1500	MO-IGA-lite	11.35 ± 0.22	3809.2k ± 6.9k	196,221.8 ± 2973.1	0.3326 ± 0.0004	6.67 ± 0.05	20.62 ± 0.24
1500	MMA without Relocation	16.09 ± 0.26	3626.1k ± 8.8k	189,428.3 ± 2536.0	0.3639 ± 0.0008	6.08 ± 0.04	16.96 ± 0.17
1500	DP-OTM	10.36 ± 0.25	3834.5k ± 7.9k	187,133.2 ± 3000.7	0.3504 ± 0.0007	6.33 ± 0.05	29.41 ± 0.40

reports the complete mixed advance-request dispatching results across the three operating settings, all evaluated fleet sizes, and all benchmark algorithms used in the experiments. The reported values include reject rate, revenue, empty miles, post-drop-off risk, wait time, and computational time, expressed as mean ± standard deviation over five random seeds. These detailed values complement the normalized multi-indicator comparison in Figure 14 and provide the numerical basis for comparing service efficiency, revenue performance, operational cost, and post-drop-off risk under different dispatching policies.

5. Discussion

This section discusses the main findings, methodological implications, practical relevance, and limitations of the proposed closed-loop prediction–dispatching framework. The results in Section 4 show that CC-STMT improves regional demand forecasting under the tested settings, and DP-OTM uses the predicted destination opportunity and low-opportunity risk to influence online assignment decisions. The discussion below examines how these findings should be explained and what they imply for mixed on-demand- and advance-request ride-hailing dispatching.

5.1. Main Findings

The first finding is that dispatch-oriented forecasting benefits from jointly modeling spatial structure, demand sparsity, and dispatch-induced supply feedback. In the forecasting experiments, CC-STMT achieves lower MAE and RMSE than the compared baselines across NYC, Chicago-A, and Chicago-B. The improvement is not only associated with the use of a neural architecture but also with the way the model represents the ride-hailing system. The physical-distance graph describes road-network accessibility, while the functional–semantic graph captures correlations among regions with similar urban functions or historical mobility patterns. These two relations are not equivalent: physically nearby zones may have different demand structures, and functionally similar zones may be spatially separated. The graph-structure sensitivity results in Figure 12 support the value of using the two graph views jointly.

The second finding is that en-route supply feedback contributes to the closed-loop nature of the forecasting task. In conventional demand forecasting, the model usually receives only historical demand, exogenous context, and possibly traffic states. In the proposed framework, previous dispatching decisions also enter the subsequent forecasting window through the expected future availability of vehicles. This feedback is important because a completed request changes the spatial state of the vehicle fleet. The closed-loop feedback analysis in Figure 11 indicates that removing this feedback weakens prediction performance in part of the tested settings. This result supports the view that ride-hailing demand forecasting and vehicle dispatching should not be treated as fully independent stages.

The third finding is that destination-aware predictive fields can influence post-drop-off vehicle placement. The destination-signal ablation in Figure 15, the risk-ranking diagnostics in Table 6, and the post-drop-off mechanism results in Table 7 show that the predicted opportunity and risk signals are not merely auxiliary forecasting outputs. When these signals are included in the dispatching cost, completed trips are less likely to leave vehicles in future low-opportunity regions, and more likely to end in areas with stronger subsequent service opportunities. This is reflected by the reduction in DERLow20 and the increase in PDO_H relative to Base-UOT in the reported settings.

The fourth finding is that DP-OTM should be understood as a trade-off method, rather than a method that optimizes all dispatching indicators simultaneously. The normalized multi-indicator comparison in Figure 14 shows that different algorithms have different strengths across rejection, revenue, empty mileage, waiting time, and risk. DP-OTM is designed to balance these factors by combining current service terms with future destination terms. Therefore, its value lies in producing a more destination-aware assignment profile, not in claiming the best result for every single metric under every fleet size and city setting.

5.2. Prediction–Dispatch Coupling

A central methodological implication of this study is that the interface between forecasting and dispatching should be explicitly designed. Many forecasting models produce point estimates of future demand. Such outputs are useful for evaluating prediction accuracy, but they are not always sufficient for downstream vehicle assignment. In the proposed framework, CC-STMT outputs a ZINB-based representation, which separates latent demand intensity, zero-inflation probability, and demand dispersion. This separation provides richer information than a single expected-demand value.

The expected demand $(1-\pi )\mu$ is suitable for point forecasting evaluation, while $\mu$ and $\pi$ have different operational meanings in dispatching. The latent demand intensity $\mu$ reflects potential future request opportunity, whereas the zero-inflation probability $\pi$ indicates the risk that a region belongs to a weak future service state. By using these two components separately, DP-OTM can distinguish between destinations with similar expected demand but different underlying opportunity-risk structures. This is particularly relevant in sparse or highly variable demand environments, where mean demand alone may obscure structural-zero-demand behavior.

5.3. Implications for Mixed On-Demand and Advance Requests

The mixed-request setting introduces an additional temporal layer into ride-hailing dispatching. On-demand requests require fast responses, whereas advance requests reveal future service pressure before their target pickup times. If an advance request is assigned too early, a vehicle may be removed from the current on-demand service pool prematurely. If advance information is ignored until the target pickup time, the system may fail to prepare sufficient nearby supply. The activation-window mechanism used in this study provides a practical compromise: advance requests become visible before execution, but they enter the active dispatching pool only when their pickup windows approach.

The results suggest that the value of advance-request information depends on how it is incorporated into the dispatching decision. Treating advance requests simply as earlier on-demand requests would overstate their urgency and could distort current vehicle allocation. Conversely, ignoring the destination consequences of serving an advance request would miss an important source of future supply redistribution. The proposed formulation handles both request types in a unified active pool while preserving their different timing rules.

5.4. Interpretation of the Low-Opportunity Risk Signal

The zero-inflation probability field ${\mathit{\pi }}^{t+h}$ is used in this study as a continuous low-opportunity risk signal. This interpretation should be made carefully. In the ZINB model, $\pi$ represents the probability that a zero observation comes from a structural-zero component. Operationally, a high value of ${\pi }_z^{t+h}$ suggests that the corresponding zone has a higher tendency toward weak future request activity. Therefore, it is reasonable to use $\pi$ as a destination-risk indicator for dispatching. In this study, destination risk refers exclusively to post-drop-off service-opportunity risk associated with weak future request activity; it does not represent road-safety or infrastructure risk related to road gradients, narrow roads, pavement conditions, traffic conflicts, or crash exposure.

However, $\pi$ should not be interpreted as a perfectly calibrated probability of a fixed event such as membership in the bottom-20% future demand group. The ROC analysis in Figure 16 evaluates whether $\pi$ can rank future low-opportunity zones effectively, rather than whether its numerical value is calibrated as an absolute event probability. This distinction is important for deployment. A useful dispatching risk signal does not necessarily need perfect probability calibration, but it should provide reliable ordering information so that high-risk destinations can be penalized relative to lower-risk alternatives.

5.5. Role of Unbalanced Optimal Transport

The UOT component in DP-OTM should be understood as a soft matching prior rather than as a replacement for executable assignment. In online dispatching, the number of available vehicles and active requests is usually unequal. A direct linear assignment can produce executable one-to-one matches, but it does not explicitly describe the relaxed coupling structure between supply and demand under imbalance. The UOT step fills this gap by generating a soft transport matrix from the normalized composite cost.

This soft prior has two functions. First, it provides a global view of vehicle–request compatibility before the final one-to-one assignment. Second, it calibrates the pair-wise cost matrix so that the final assignment is not determined only by raw local costs. The final output remains a binary assignment, which is necessary for actual dispatching. Therefore, UOT is not introduced because the final assignment is computationally impossible; rather, it is introduced to represent a relaxed global coupling under unequal supply and demand and to adjust the cost surface before the final linear assignment.

5.6. Practical Implications

The proposed framework has several practical implications for ride-hailing platforms and intelligent transportation systems. First, the results indicate that future destination states can be incorporated into online dispatching without abandoning executable one-to-one assignment. This is relevant for platforms that need to maintain real-time matching efficiency while reducing future idle time or weak-service exposure.

Second, the framework provides a way to use advance-request information without fully reserving vehicles too early. The activation-window mechanism allows the system to observe future service pressure while preserving current dispatching flexibility. This is particularly useful when advance requests and on-demand requests share the same vehicle pool.

Third, the post-drop-off indicators provide an interpretable way to evaluate dispatching policies. Conventional metrics such as reject rate, revenue, waiting time, and empty mileage describe immediate outcomes, but they do not directly show where vehicles end up after service. DERLow20 and PDO_H help describe whether a policy improves or weakens the spatial distribution of future vehicle availability.

Fourth, the matching weights can be calibrated through a staged operational procedure. The pickup-distance and request-urgency weights should first be adjusted to maintain acceptable pickup travel and service responsiveness. Within this feasible operating range, the destination-opportunity and low-opportunity-risk weights can then be increased gradually while monitoring rejection, revenue, empty mileage, wait time, risk, DERLow20, and PDO_H. Candidate profiles that improve destination-side indicators but cause substantial deterioration in immediate service metrics should be excluded. Among the remaining profiles, a Pareto-efficient or knee-point configuration can be selected according to the platform’s relative preference for current service efficiency and future vehicle placement. Because demand density, fleet availability, road-network structure, and service objectives differ across operating settings, this calibration should be conducted separately for each city or service region and repeated when the operating environment changes materially.

Fifth, the framework can be connected to a GIS or urban digital-twin platforms as a decision-support module through standardized interfaces for zone-level demand, vehicle, road-network, and contextual states. The same prediction–matching structure may also be adapted to autonomous fleets, demand-responsive public transport, logistics, courier and parcel-delivery services, rescue fleets, and shared electric vehicles, although the request representation, feasibility constraints, operational objectives, and safety requirements would need to be reformulated for each application.

5.7. Limitations and Future Work

Several limitations should be noted. First, the experiments are based on public trip records rather than internal platform logs. Public records contain completed trips but do not provide true reservation creation times, advance lead times, cancellation behavior, driver acceptance behavior, passenger no-shows, or real-time pricing. Therefore, the mixed on-demand- and advance-request streams in this study are constructed under unified simulation rules. This design supports controlled comparison across algorithms, but it cannot fully reproduce the operational process of a commercial ride-hailing platform.

Second, this study evaluates the framework in NYC and Chicago under three spatial settings. These settings include different cities and spatial resolutions, but they do not cover all possible urban structures, demand regimes, or platform policies. The performance of the framework may vary in cities with different road-network topology, different levels of ride-hailing penetration, different regulatory environments, or different reservation behavior.

Third, the dispatching cost uses fixed weights for pickup distance, revenue, waiting urgency, destination opportunity, and destination risk. Fixed weights make the experiments interpretable and reproducible, but real platforms may need adaptive weights that vary by time of day, local demand pressure, service-level targets, driver supply, or policy constraints. A fixed-weight design may not fully capture such dynamic operational priorities.

Future work can extend this study in several directions. Real platform reservation logs would allow the mixed-request model to use actual booking creation times, lead times, cancellations, passenger behavior, and driver acceptance outcomes. Adaptive objective weighting could also be introduced into DP-OTM, allowing the system to adjust the importance of waiting time, revenue, pickup distance, destination opportunity, and destination risk according to current system pressure. In addition, risk calibration and uncertainty quantification can be further developed so that the low-opportunity risk signal can support threshold-based operational decisions. Finally, larger-scale online evaluations under different demand regimes, fleet sizes, city layouts, and policy constraints would help determine when destination-aware risk signals provide the greatest operational value. Deployment-oriented extensions should also examine fallback localization and missing-state handling during GPS outages, rapid supply-state updates after large-scale vehicle unavailability, event-aware forecasting for sudden demand surges, periodic recalibration under long-term distribution shifts, and authenticated, privacy-preserving data interfaces.

6. Conclusions

This paper presented a risk-aware closed-loop prediction–dispatching framework for ride-hailing systems serving mixed on-demand and advance requests. The proposed framework contains two coupled modules. The forecasting module, CC-STMT, uses physical-distance and functional–semantic graphs, demand-gated speed denoising, en-route supply feedback, and ZINB-based multi-task learning to estimate latent demand intensity, low-opportunity risk, demand dispersion, and auxiliary speed states. The dispatching module, DP-OTM, converts the predicted destination opportunity and risk fields into vehicle–request matching costs, introduces an unbalanced optimal transport prior under unequal supply and demand, and generates executable one-to-one assignments through a calibrated linear assignment step.

Experiments using public ride-hailing records from New York City and Chicago were conducted under three operating settings: NYC, Chicago-A, and Chicago-B. The forecasting results show that CC-STMT achieves lower MAE and RMSE than the compared baselines in the tested settings. The component analyses indicate that dual-graph modeling and closed-loop supply feedback contribute to regional state prediction. The dispatching results further show that DP-OTM maintains a competitive balance among rejection, revenue, empty mileage, waiting time, and low-opportunity risk. The destination-signal ablation, risk diagnostics, and post-drop-off mechanism analyses indicate that the predicted risk signal provides useful ranking information for future low-opportunity regions and that destination-aware matching can reduce the proportion of vehicles dropping off in weak subsequent service areas while improving post-drop-off opportunity. The associated immediate operational effects remain city-dependent: stronger destination guidance can increase empty mileage, while the wait-time differences are generally favorable in NYC and Chicago-B but are smaller or occasionally adverse in Chicago-A. DP-OTM should therefore be interpreted as providing a destination-side risk–opportunity trade-off rather than as uniformly improving every operational metric.

This study also has clear boundaries. The mixed-request streams are constructed from completed public trip records because the public datasets do not include real platform-side reservation creation times, cancellations, driver acceptance behavior, or dynamic pricing. Therefore, the results should be interpreted as evidence from a controlled public-data simulation rather than as direct deployment-level performance. Future work will incorporate richer platform-side reservation and driver-behavior data, develop adaptive cost-weighting strategies, and evaluate the proposed framework under broader real-time operational conditions.