Thanks so much for your detailed and constructive comments. Please see our below responses to your concerns one by one.

W1:

1) Computational costs

To evaluate computational cost, we tested the model’s inference time on progressively larger portions of the data—20%, 40%, 60%, 80%, and 100%—as shown in Table below.

Next, with the data scale fixed, we gradually increased the sequence length and measured inference time. Results are reported in Table below.

Combining the above tables, we observe that our model's computational cost grows linearly with data scale and is only slightly affected by sequence length. Memory cost is also insensitive to both data scale and sequence length.

2) Time complexity and efficiency

In below table, we report both inference and training times for CRAFT and the baselines. CRAFT includes two variants: CRAFT-DDPM and CRAFT-DDIM. As expected, diffusion-based models are generally slower in both training and inference than single-shot generative models. CRAFT-DDPM achieves comparable efficiency to other diffusion-based models such as DiT but remains slower than single-shot models like GMEL. CRAFT-DDIM improves the sampling strategy of the diffusion backbone, achieving efficiency comparable to, or even surpassing, some single-shot models (e.g., DFG).

In below table, we compare the performance of CRAFT-DDPM and CRAFT-DDIM. CRAFT-DDIM achieves performance close to CRAFT-DDPM and outperforms all other baselines. Therefore, for optimal performance, CRAFT-DDPM is preferred, while CRAFT-DDIM offers a better trade-off between performance and efficiency.

W2 & Q3: Can CRAFT generalize to more diverse domains?

We have added experiments on the Traffic4Cast[1] dataset, which contains vehicle flow spans diverse countries across Europe and Asia and exhibits greater inter-city variation. In addition, Traffic4Cast offers larger-scale and finer-grained data than the datasets used in our main paper. Specifically, we selected Moscow and Berlin to evaluate CRAFT. The results are shown in the table below.

The experimental results show that CRAFT not only generalizes well to the traffic4cast dataset but also achieves larger improvements over baselines compared to our original datasets, highlighting its strong generalization capability. We sincerely thank you for the suggestion and will include these results in the revised version.

[1] NeurIPS traffic4cast 2021

Q1：

1) Can CRAFT model inter-region relationships?

CRAFT has considered inter-region relationships. Specifically, our spatial encoder, a graph transformer, models the inter-region relationships among neighboring regions when representing geographic features.

2) Why does CRAFT focus on basic features such as POIs, roads, and population?

Flow magnitude is primarily determined by population size. Flow patterns are shaped by regional functionality which is indicated by the types and amounts of POIs and roads. In our original paper, to ensure the cross-city generalizability, we selelct only the most basic spatiotemporal features shared across all cities. Since cities share only a few fundamental geographic features and most other features differ significantly, incorporating too many features harms geographic feature alignment. This is a key challenge in cross-city flow generation: to reduce significant domain shifts, the generation must depend on a limited feature set.

Q2: How does the length of T affect the DDPM’s performance?

1) DDPM’s performance fluctuates with varying T As shown in paper’s Figure 7, DDPM’s performance varies within a narrow ±0.1 range as T increases. On the NY dataset, performance slightly decreases with larger T, while on the D.C. dataset, a clear improvement is observed. Among all baselines, DDPM exhibits the most stable performance trend.

2) Why does this fluctuation occur? How the performance variation with increasing T depends on the distribution of the target data. As T represents both the input sequence length (T_input) and the output sequence length (T_output). When T = 24, it denotes both input length and output length are 24. Thus, increasing T simultaneously increases task difficulty (due to longer output length per sample) but provides richer information per input sample (due to longer input length).

Specifically, detailed analysis can be shown in the below table, where we select Chicago as the target city and evaluate using NMAE (lower is better). We test various combinations of input and output lengths. For example, 24→48 denotes an input length of 24 and an output length of 48.

Within each row, with a fixed output length, model performance improves as input length increases; Within each column, with a fixed input length, performance degrades as output length increases.

Task difficulty is closely tied to the variance of the target data: higher variance—caused by larger fluctuations—leads to more challenging generation, while lower variance indicates easier generation. We computed the target variance across the four datasets, as shown in the table below：

As illustrated, the NY dataset has the highest variance, making long-sequence generation most difficult. In contrast, the D.C. dataset shows the lowest variance, making the task relatively easier.

Therefore, when the target data exhibits high variance, the loss from a larger output length dominates, leading to performance degradation as T increases; conversely, when the variance is low, the gain from a longer input length prevails, resulting in improved performance with increasing T. This aligns with the results in Table 7 of the paper.

3) Why is CRAFT different from DDPM?

Regardless of the length of T, CRAFT’s RCA module consistently retrieves relevant historical data from source cities as reference, effectively smoothing fluctuations and enhancing input quality. As a result, CRAFT performs more stably and achieves superior results in most cases.

Thanks so much for your detailed and constructive comments. Please see our below responses to your concerns one by one.

W1: The novelty and contributions of our model

Cross-city flow generation is an emerging area with limited existing efforts. This is because flow generation itself is a challenging problem—it requires geographic features as input to map static spatial structures to dynamic flows. Moreover, the cross-city setting further requires the model to handle domain shifts in both static geographic features and dynamic flow patterns across different cities, even in a completely zero-shot manner.

Therefore, this area remains in its early stages and is still under explored. Existing works primarily focus on specific types of data, such as origin-destination (OD) data[1] or cellular signal data[2], which often come with type-specific priors that simplify the task.

In contrast, we targets generation on general flow types which is under-explored, and address two critical challenges: “severe domain shift” and “insufficient conditions”.

• To address domain shift, we were among the early efforts to introduce optimal transport theory into flow tasks and proposed the GFA module. Compared with prior alignment approaches, GFA adaptively selects the most relevant source regions for each target region, enabling finer-grained alignment.

• To address insufficient conditions, we adapted RAG for flow generation and developed the RCA module, which integrates dynamic flow information from source cities under zero-shot settings. Most prior works relied solely on static geographic features. RCA allows our model to adapt to more complex flow patterns, resulting in more accurate flow generation.

[1]A Large-scale Benchmark Dataset for Commuting Origin-destination Matrix Generation

[2]Deep Transfer Learning for City-scale Cellular Traffic Generation through Urban Knowledge Graph

W2 & Limitation 2: Detailed analysis of the retrieval augmented module (RCA)

For a given target region and timestamp, RCA retrieves the most similar historical flow segments from source cities based on two features: geographic similarity and temporal proximity.

We conducted ablations on each feature to assess their individual contributions. The results are shown in the table below. Specifically, we averaged the flow segments retrieved by RCA and measured their similarity to the ground-truth flow in the target city using Pearson, Spearman, and Kendall metrics.

Both geo and temporal features contribute significantly to performance improvements, with temporal proximity often playing a more dominant role. This indicates that flow patterns across regions are more strongly influenced by temporal periodicity, while also being shaped by static geographic features.

W3 & Limitation 2:

1) Can CRAFT utilize non-grid data?

Yes, actually datasets used in our paper is in graph format, where each node is a grid. CRAFT is not limited to grid-based data. It only requires that each basic geographic unit—regardless of its shape—provides complete information of POIs, roads, and population. In practice, such units are usually implemented as grids.

2) Can CRAFT generalize to more diverse cities?

We have added experiments on the Traffic4Cast[3] dataset, which contains vehicle flow spans diverse countries across Europe and Asia and exhibits greater inter-city variation. In addition, Traffic4Cast offers larger-scale and finer-grained data than the datasets used in our main paper. Specifically, we selected Moscow and Berlin to evaluate CRAFT. The results are shown in the table below.

The experimental results show that CRAFT not only generalizes well to the traffic4cast dataset but also achieves larger improvements over baselines compared to our original datasets, highlighting its strong generalization capability. We sincerely thank you for the suggestion and will include these results in the revised version.

[3] NeurIPS traffic4cast 2021

Q1 & Limitation 1: Enriching geographical features via network topology and intersection connectivity

Thank you for your comment. We computed each node’s space syntax features[4], including degree, closeness centrality, and betweenness centrality, to capture explicit road topology and intersection connectivity. Results are shown in the table below, where CRAFT + syntax denotes CRAFT augmented with explicit topology and intersection connections.

Experimental results show that space syntax features provide certain gains on the CHI and Toronto datasets, but lead to slight performance drops on DC and NYC. This is because DC and NYC have the simplest and most complex road network structures, respectively, among the four datasets.

Specifically, flow magnitude is primarily determined by population size, while flow patterns are shaped by regional functionality. When cities have similar road network complexity, incorporating syntax features improves performance. However, when complexity differs, such features may impede cross-city spatial alignment. In our original paper, to ensure generalizability, we used only the most basic spatiotemporal features shared across all cities.

[4]Space Syntax. Environment and Planning B: Planning and design

Q2 & W3 & Limitation1: Can CRAFT handle sudden changes in flow patterns, such as a holiday surge?

As existing public flow datasets lack information on incidents or extreme events. We constructed a dataset with sudden flow pattern changes based on the four datasets used in our paper.

Specifically, we kept all weekday (Monday to Friday) data in the training set, while using 80% of weekend and holiday data as the test set and adding the remaining 20% back into training. Additionally, we included a 0-1 one-hot vector as an event code to distinguish weekdays from holidays. We evaluated the impact of this event indicator on the RCA module’s performance, which is evaluated by similarity to the ground-truth flow in the target city using CPC, NMAE, NRMSE metrics. Results are in the table below:

Thank you for your detailed advice. The event indicator indeed improves the model’s ability to handle abrupt changes in flow patterns, such as holiday surges, thus enhancing CRAFT’s capacity for such scenarios. We will further extend this result and include it as a case study in the revised version.

Q3: The computational and memory costs when scaling to larger datasets

To evaluate computational cost, we tested the model’s inference time on progressively larger portions of the data—20%, 40%, 60%, 80%, and 100%—as shown in Table below.

Next, with the data scale fixed, we gradually increased the sequence length and measured inference time. Results are reported in Table below.

Combining the above tables, we observe that our model's computational cost grows linearly with data scale and is only slightly affected by sequence length. Memory cost is also insensitive to both data scale and sequence length.

Thanks so much for your detailed and constructive comments. Please see our below responses to your concerns.

W1: Data dependency

The data required for our model includes static geographical feature data of both the source and target cities, as well as traffic flow data of the source city. Specifically, the following static geographical features must be provided to use our model, with their acquisition and processing methods as follows:

• POI features: POIs of the source and target cities can be downloaded from OpenStreetMap and matched to the city's spatial units (in our experiments, grid regions are treated as spatial units). We then count the number of various types of POIs in each region and use the TF-IDF algorithm to calculate the score of each POI type in the region. Specifically, we treat POI categories as words, all POIs within a region as a document, and all POIs in the entire city as a corpus to compute TF-IDF scores. Finally, these scores are concatenated into a feature vector.
• Road network features: All road segments in the source and target cities can be downloaded from OpenStreetMap and matched to the city regions. We then calculate the total mileage of each type of road in each region and concatenate these values into a feature vector.
• Population features: Population statistics for the source and target cities are downloaded from WorldPop. The population count and population density in each region are calculated and included as part of the basic features of the region. These static geographical feature data all rely on public data sources, allowing researchers to easily obtain them for any city.

In addition, training our model requires traffic flow data covering all regions of the source city (including inflow and outflow for each region at each time slice), with a recommended time span of over 3 months. Traffic flow data can typically be derived from trajectory data, OD data statistics, or specialized traffic flow datasets. Our model is not restricted to specific traffic modes—it can handle bicycle, car, or pedestrian flow—but the generated flow for the target city should match the type used for the source city.

Extended static geographic features: The road network features used in the model do not include the topological structure of the road network. To verify whether topological structure information is helpful for traffic flow modeling, we later tried adding space syntax features (including degree, closeness and betweenness) that describe the road network topology to the geographic features and conducted the following experiments.

We found that on the Chicago and Toronto datasets, adding road network topological features helps improve the generation effect of the target city. However, this phenomenon does not occur on the DC dataset with a simple road network structure and the NYC dataset with a complex road network structure. When using our model, researchers can also try to expand the space syntax features of the road network.

W2: Writing

Adjacency Construction: Each region is modeled as a graph node. If two region rectangles share a common edge (i.e., are spatially adjacent), a bidirectional edge is established between them. The adjacency relationships among regions are represented as an adjacency matrix, which is encoded by a graph transformer and incorporated into the regional geographical representation. We will clarify this definition in the Preliminary section of the final version.

Geographical features of regions: In the Preliminary section, we only mentioned that each graph node has three types of geographical features but did not specify the details of each type. We provide formal definitions of the three feature types in the appendix and we will add explanations of these geographical features in the Preliminary section in the revised version.

W3: Experimental settings

Thank you for your suggestions, which are very helpful for us to improve the details and readability of the paper. Due to the length constraints of the paper, we used abbreviations for the names of cities (datasets) in some experimental figures and tables, but failed to explain them clearly.

In Figure 7 and Appendix Figures 11-12, DC, NY (NYC), and TRT stand for Washington, New York, and Toronto respectively. To ensure rigor, we will follow your suggestion to standardize the abbreviations in the experimental setup section to avoid ambiguity.

Thanks so much for your detailed and constructive comments. Please see our below responses to your concerns.

W1 & Q1:

1) Literature review of cross-city flow generation

Flow prediction and generation are different tasks. Flow prediction leverages historical flow data to forecast future flows, focusing on modeling temporal patterns. In contrast, flow generation uses geographic features as input, mapping static spatial structure to dynamic flows. The main challenge of cross-city prediction lies in flow pattern shifts in different cities. While Cross-city generation must simultaneously handle shifts in both static geographic features and dynamic flow patterns.

Some pioneer works [1][2] have explored cross-city flow prediction, the area remains underdeveloped, with existing efforts limited to specific types of data and tasks. [1] is an early effort to cross-city generation in origin-destination (OD) data, building a large-scale OD dataset for pretraining a universal OD flow model. However, OD data is a specific flow type with fixed patterns and strong periodicity, making [1] limited to OD flow and hard to generalized to tasks with broader flow types. [2]specialized for cellular signal data, as cellular stations inherently have unique priors and clear semantic links to surrounding geographic entities. Based on this character, [2] constructs a universal knowledge graph to guide cross-city transfer. Yet, this strategy is difficult to extend to general flow scenarios, where such structured priors are often unavailable.

Existing efforts focus on specific types of data and tasks, our work aims to explore more general scenarios which remain under explored . Our work may serve as an initial prob to such tasks.

[1]A Large-scale Benchmark Dataset for Commuting Origin-destination Matrix Generation

[2]Deep Transfer Learning for City-scale Cellular Traffic Generation through Urban Knowledge Graph

2) Transfer learning in cross-city flow tasks

Transfer learning in cross-city tasks mostly focused on few-shot flow prediction but rarely applied to zero-shot flow generation. Since most methods require certain amounts of target city data during training. Specifically, they can be categorized into below three paradigms

• meta-learning: [3][4] use meta-learning to obtain good model initialization from source cities. However, it requires few-shot adaptation on target cities and struggle with zero-shot tasks. But we targets zero-shot generation without any fine-tuning on target cities.

• adversarial training: [5][6] leverage a domain discriminator to enforce models only extract domain-shared features. But these methods usually suffer from limited generalization ability as training discriminators is hard and typically assumes distribution gaps between domains are not too large.

• feature alignment: uses an alignment loss to project source and target data into a shared feature space. Additionally, these methods typically employ feature decoupling to simplify alignment. [7], [8] decouple features along spatial-temporal dimensions, geographic structures, respectively. However, such methods are sensitive to hyper-parameters if alignment losses are too complex.

In conclusion, transfer learning can address few-shot flow prediction in cross-city scenarios, they cannot fully solve the zero-shot flow generation, as original meta-learning and adversarial training still require access to flow data of target cities during training. But transfer learning can partially support feature transfer for flow generation. Inspired by the feature alignment paradigm, we designed the Geographic Feature Alignment(GFA) module to align the static geographic features of the source and target cities.

[3]Cross-City Multi-Granular Adaptive Transfer Learning for Traffic Flow Prediction

[4]Spatio-Temporal Meta-Graph Learning for Traffic Forecasting

[5]Domain-Adversarial Training With Knowledge Transfer for Spatio-Temporal Prediction Across Cities

[6]Generating Origin-Destination Flow for New Cities Via Domain Adversarial Training

[7]Transferable Graph Structure Learning for Graph-based Traffic Forecasting Across Cities

[8]Exploiting Hierarchical Correlations for Cross-City Cross-Mode Traffic Flow Prediction

W2 & Q1: Why most baselines are general generative models & comparisons with task-specific baselines

As discussed in above literature review, cross-city flow generation is an emerging area with few baselines, most of which focus on specific data types. Thus, we selected general generative models as our baselines in the original paper.

Inspired by your comments on transfer-learning, we incorporated transfer learning techniques to enhance the general baseline, adapting it more "task-specific". These improvements are applied to the alignment of static geographical features between source and target cities.

Specifically, we applied two feature alignment losses:TCA and MMD, and an adapted adversarial training strategy(ADV). Experimental results are as follows:

Compared to the original results in our paper, incorporating transfer learning indeed improves the baselines’ cross-city transfer performance, allowing them to be more task-specific. However, CRAFT still consistently retains SOTA performance due to the proposed RCA module, which provides selected priors from source cities.

Q2: Time complexity and efficiency

In above table, we report both inference and training times for CRAFT and the baselines. CRAFT includes two variants: CRAFT-DDPM and CRAFT-DDIM. As expected, diffusion-based models are generally slower in both training and inference than single-shot generative models. CRAFT-DDPM achieves comparable efficiency to other diffusion-based models such as DiT but remains slower than single-shot models like GMEL. CRAFT-DDIM improves the sampling strategy of the diffusion backbone in the inference stage, achieving efficiency comparable to, or even surpassing, some single-shot models (e.g., DFG).

In above table, we compare the performance of CRAFT-DDPM and CRAFT-DDIM. CRAFT-DDIM achieves performance close to CRAFT-DDPM and outperforms all other baselines. Therefore, for optimal performance, CRAFT-DDPM is preferred, while CRAFT-DDIM offers a better trade-off between performance and efficiency.

Q3: Can our model expand to traffic4cast?

Due to limited time and computational resources, we selected Moscow and Berlin from the Traffic4cast[9] dataset to evaluate CRAFT. Compared to our initial datasets in the paper, Traffic4cast poses two main challenges:

• finer-grained and more numerous regions result in a larger data scale that makes training more difficult

• greater inter-city variation and lower similarity between regions across cities increase the risk of introducing irrelevant noise

To address these issues, we made two adaptations:

• we aggregated regions at the input stage to reduce region count, and used a linear layer at the output to map predictions back to the original resolution

• we halved the retrieval numbers of RCA to reduce the possibility of invovling irrelevant noise. Results are in below table

The experimental results demonstrate that CRAFT not only generalizes to the traffic4cast dataset but also shows bigger advantages over baselines than our original datasets, highlighting CRAFT’s strong generalization capability. We sincerely thanks for your suggestion and will include these results in the revised version. And we will also considering increasing the number of source cities in our future work.

[9] NeurIPS traffic4cast 2021

Dear Reviewers 6r4v,

We sincerely thank you for your time, thoughtful evaluation, and constructive comments on our work. We truly appreciate your recognition of our model. We hope that our responses can address your concerns, which we summarize as follows:

• To Weakness 1 and Question1: We conducted a more comprehensive review of flow generation and analyzed the unique challenges of cross-city scenarios, including the absence of task-specific baselines. These revisions help clarify that our contribution lies in serving as an initial probe into cross-city flow generation.

• To Weakness 2 and Question1: We clarified how our model relates to existing transfer learning approaches and integrated three representative methods to strengthen the existing baselines, along with corresponding comparison experiments.

• To Question 2: We conducted experiments on time complexity and efficiency. Specifically, we provide a detailed comparison of training and inference costs between our model and the baselines across all datasets.

• To Question 3: We expand our model to Traffic4Cast. Specifically, we select Berlin and Moscow from the traffic4cast to evaluate the generalization ability of our model. Additionally, we discuss the unique challenges posed by Traffic4cast and describe the targeted adaptations we have made to address them.

Thank you again for your valuable feedback. We truly appreciate the opportunity to clarify the motivations and contributions of our work. As the rebuttal phase comes to an end, we always welcome any additional comments or questions you may have. Please feel free to share them with us, and we are always glad to engage in continued discussion.

We hope that our responses have helped clarify your concerns. We would kindly ask if, you find our responses reasonable and aligned with your expectations, could you possibly reconsider and adjust the final score. We would be deeply grateful for your reconsideration.

Regardless, we always fully respect your final decision and sincerely appreciate the time and patience you have devoted to reviewing our paper.

Sincerely,

The Authors