Reconciling Geospatial Prediction and Retrieval via Sparse Representations

Thank you for your careful reading and constructive feedback. We would like to address each point in turn.

W1. Running Example. We have added a concise running example to the Introduction to show how prediction and retrieval interact in practice: Suppose our system analyzes recent land‑use and economic data across a city and flags a particular neighborhood, home to several hundred restaurants and cafés, as an emerging “culinary hotspot”. When a user searches for “best sushi nearby”, the retrieval module does not simply return the most similar sushi bars city‑wide; it prioritizes those within the hotspot that have seen a surge in visits and searches over the past month. Likewise, a query for “top‑rated vegan restaurants” surfaces vegan venues in the same area that are gaining traction. By combining prediction (detecting dynamic hotspots) with retrieval (serving context‑aware results), the app delivers recommendations that are both timely and closely aligned with the city’s evolving landscape.

W2. Different spatial layouts and POI density. Handling spatial diversity and POI density is orthogonal to our core contribution, yet we appreciate the your concern and respond as follows:

1. Our Beijing dataset already spans more than 16 000 km² and includes urban, peri‑urban, and suburban zones, providing naturally diverse patterns. We will add a dedicated case study on a low‑density suburban region of Beijing in the revised Appendix.
2. We further evaluate UrbanSparse on the GeoGLUE benchmark (2 849 754 POIs) and show in Appendix F.1 that our model matches strong PLM‑based retrieval baselines (Recall@10 = 0.760 vs. 0.761 for DPR) while training in 54 minutes, more than twice as fast as DPR.

W3. Intuitive explanation for the Bloom‑filter contrastive learning. To clarify why our method works, we will insert the following intuitive explanation into Section 4:

1. Bit‑level InfoMax. A discriminator‑based (InfoMax) loss operates on individual Bloom filter bits. Negative POI pairs are discriminated on whether any bits are missing, mimicking the Bloom filter’s membership test, ensuring the detection of important bits.
2. Region‑level InfoMax: We group POIs into regions via administrative boundaries, and train a second discriminator to judge whether one region’s aggregated representation is contained within a larger region’s, also analogous to the Bloom filter’s membership test, ensuring spatial coherence across scales.

We hope this intuitive explanation clarifies the roles of the two contrastive objectives and resolves your concern.

Thank you for the careful reading. We would like to address your concern as follows:

W1 and Q1. Clarification of LambdaRank choice.

We clarify that loss‑function design is not our primary contribution, and we adopt LambdaRank (NIPS, 2016) because it is a well-known one in learning‑to‑rank practices. Nevertheless, we fully agree that ablation studies on loss functions would help us identify the source of performance gain. Hence, we conduct an ablation study on Beijing datasets. While a static ranking‑weight loss (true=1, false=0) fails to converge, a simple contrastive loss (the same as in DPR) leads to very close results, with 1.2% performance drop in NDCG@10 and 0.4% gain in NDCG@1. We are still investigating other loss functions and will provide additional results in the appendix.

W2 and Q2. Isolation of row/column selection benefits.

We apologize for the missing ablation studies. We have now conducted ablations on both optimizations:

The results show that both optimization leads to significantly less memory usage due to the sparsification of the dense matrix. As for training time, column selection alone yields a >4× speedup (214 -> 51 min) and >2× memory reduction (166.5 -> 71.9 MB) by computing only query-bit‑matched entries. Row selection only adds a smaller benefit (72 -> 51 min), as when POI Bloom filters have many bits, the PyTorch sparse‑dense matrix multiplication is not significantly faster than dense counterparts (due to memory access patterns). Thus, column selection provides the lion’s share of our efficiency gains, with row selection as a complementary, secondary optimization.

W3. Scalability and generalization.

We clarify that we have tested UrbanSparse's scalability on the GeoGLUE [1] benchmark (with 2.85 M POIs) in Appendix F.1. As shown in Table 10, UrbanSparse matches or slightly exceeds the strong multimodal baseline MGeo and trains in 54 min versus 131 min for DPR‑D :

We apologize for the lack of clarity in the main text and will add a concise reference in Section 5.5 to guide readers directly to these results.

Q3. Remaining inference bottlenecks

Thank you for pointing this out. Our detailed profiling shows that Bloom‑filter hashing adds negligible overhead. The primary cost arises from our custom CUDA kernels for sparse representation calculations: the non‑coalesced memory accesses in our kernel and an insufficiently optimized kernel dispatch strategy incur significantly higher latency than vendor‑optimized dense kernels from NVIDIA experts. Consequently, while we achieve a 50× reduction in parameters, the 4× QPS gain is bounded by these CUDA kernel inefficiencies. We anticipate that expert‑tuned CUDA kernels (particularly, leveraging shared memory with better parallelism) will further narrow this gap.

[1] Li et al. GeoGLUE: A geographic language understanding evaluation benchmark. arXiv:2305.06545, 2023.

Thank you for the careful reading and constructive feedback. We would like to address each weak point as follows:

Overall concern: We clarify that Urban Computing is not a niche application; it has become a cornerstone of real‑world AI applications, powering services such as Google Maps, Uber, and food‑delivery platforms that billions rely on daily. The technical challenges studied in our work, i.e., fusing large‑scale text search with spatio‑temporal forecasting, also appear in areas such as temporal recommender systems and video‑event search. More importantly, our unique integration of Bloom‑filter‑based representation and two-level contrastive learning are not confined by urban computing. Such strategy can be applied to the general text-based retrieval/recommender systems, unlocking the joint benefits of retrieval and prediction and bringing broader impact to the NIPS community.

W1. Method clarity. Thank you for your feedback. We will restructure Section 3 to center on our core innovation: the use of Bloom filters and tailored contrastive learning at both bit‑ and region‑level. We will also introduce a more intuitive figure to illustrate the overall framework, highlighting its core components and avoiding overwhelming training/optimization details.

W2. Bloom filters and false positives. We apologize for the oversight in the main text. A comprehensive study is already provided in Appendix E.1, including a definition of Bloom filters and ablation experiments varying bit‑vector length (m) and number of hash functions (k), which show that false positives are empirically mitigated when $m \geq 8192$, $k \geq 2$. We will add a concise reference in Section 4.1 to guide readers directly to these results.

W3. Dataset choice justification. Our primary goal is to explore the joint benefit of retrieval and prediction tasks, which requires datasets that support both. For this reason, we selected the Beijing and Shanghai benchmarks (from Liu et al. [2]), which provide over 160,000 realistic user queries paired with 120,000 POIs that uniquely enable industry-scale joint evaluation. In contrast, commonly used POI datasets (e.g., from OpenStreetMap or Foursquare) typically contain fewer than 30,000 POIs and lack user queries, making them unsuitable for retrieval tasks.

However, we understand that evaluating on additional benchmarks can further demonstrate generality. Therefore, we also assess UrbanSparse on the widely used GeoGLUE [1] benchmark, where UrbanSparse achieves retrieval performance comparable to strong PLM‑based models (see Appendix F.1). For population prediction, UrbanSparse also achieves the best $R^2 = 0.5344$, outperforming the next best method, CityFM ($R^2 = 0.4774$). Full results will be included in the revised manuscript.

W4. Baseline comparisons. In addition to general‑purpose models, we have already compared UrbanSparse against domain‑specific methods. Specifically, we compare with the latest versions of POI-based prediction methods HGI (ISPRS 2023) and CityFM (CIKM 2024), and retrieval methods DrW (SIGMOD 2023). While we fail to test ERNIE-GeoL (KDD 2022) and MGeo (SIGIR 2024) on our datasets due to reproducibility issue, we found that both methods are adapted from DPR (EMNLP 2020) with geospatial components. Hence, we combine DPR with geospatial distance to form DPR-D, which we believe to be a strong baseline (As demonstrated in Appendix F.1, DPR-D performs better than MGeo on GeoGLUE).

W5. GPS-based methods and datasets. Mobility-based methods often rely on multi-modal fusion, which is orthogonal to our primary objective of bridging retrieval and prediction. Datasets used in those works (e.g., NYC) contain rich mobility traces (>2,000,000 taxi records) but only a limited number of POIs (<30,000). Applying our method to such datasets would require major architectural changes to handle the mobility signal, which is beyond our current scope. For a fair comparison, we focus only on methods that use the same input modalities, leaving exploration of mobility-enhanced models to future work.

W6. Train/validation/test splits. We apologize for the lack of detail in the main text. The full settings are described in Appendix D:

• For retrieval, we adopt a fixed train/dev/test split of 0.81:0.09:0.10, following Liu et al. [2], and make our data and splits publicly available.
• For prediction, we follow standard unsupervised representation learning practice by evaluating embeddings with a scikit-learn RandomForestRegressor using 5-fold cross-validation across all urban regions.

We will bring these details into Section 4.3 for clarity and reproducibility.

W7. Ablation on unified vs. separate tasks. Tables 2–4 already report “w/o individual” (i.e., training only on prediction) and “w/o collective” (i.e., training only on retrieval), showing clear performance degradation when either task is omitted. We will highlight these rows and the corresponding discussion to emphasize the necessity and effectiveness of joint training.

We hope the revisions and additions can address your concern and improve the quality, robustness, and clarity of our work.

[1] Li et al. GeoGLUE: A geographic language understanding evaluation benchmark. arXiv:2305.06545, 2023.

[2] Liu et al. Effectiveness perspectives and a deep relevance model for spatial keyword queries. Proc. ACM on Management of Data, 1(1):1–25, 2023.

Thank you for your constructive feedback. We would like to address each of the specific questions as follows:

Q1: We clarify that handling extremely noisy or sparse inputs is a very different challenge out of the scope of this work. However, we agree that further validation would clarify UrbanSparse's robustness in such scenarios.

To address this, we have conducted additional evaluations using the established GeoGLUE [1] benchmark, containing 2,849,754 POIs, with over 50% deliberately introduced fake POIs and queries with shuffled coordinates. Results demonstrate that UrbanSparse achieves competitive POI retrieval performance comparable to strong PLM-based methods (detailed results in Appendix F.1). For the population density prediction task under noisy conditions, UrbanSparse still delivers superior performance ($R^2=0.5344$) compared to the second-best method, CityFM ($R^2=0.4774$). We attribute this to the integration of Bloom filters and contrastive learning, which effectively mitigates the impact of noise through mining useful text bits and ignoring useless information. As for sparse input, we clarify that the Beijing dataset does contain regions with highly sparse POIs, and our method performs the best among all tested methods, indicating a certain degree of robustness. We plan to add the corresponding case studies in these data-sparse regions to clarify the detailed impact of sparse input.

In addition, two straightforward strategies may be useful to strengthen robustness: (1) Integrating off-the-shelf query rewriting modules to reduce query noise. (2) Explicitly marking empty areas with special markers (e.g., random points) to better inform the model.

We will present the full results and detailed ablation studies on these strategies in the revised Appendix.

Q2: We have rigorously compared UrbanSparse with publicly available state-of-the-art baselines in both geospatial prediction and retrieval domains, including prominent methods such as HGI (IJGIS 2023), CityFM (CIKM 2024), and DrW (VLDB 2023). We omitted certain recent methods due to either reproducibility limitations or their exclusive reliance on specific data types (e.g., human-mobility data, taxi origin-destination pairs), which are not generally accessible for a fair comparison. In the revision, we will clearly articulate these points to better contextualize our comparisons.

Q3: Thanks for your feedback. We will clarify advanced concepts such as Bloom filters, contrastive learning, and mutual information maximization. In the revised manuscript, these concepts will be thoroughly defined with intuitive explanations and complemented by visual illustrations to facilitate understanding among readers unfamiliar with these technical details.

Q4: We recognize the importance of explicitly discussing potential negative societal impacts, especially considering the sensitivity of application domains like housing and urban planning. We will move the limitation section from the appendix to the main content, addressing possible issues such as prediction biases and unintended reinforcement of socioeconomic disparities.

We hope our clarifications and additional experiments can address your concern.

[1] Li et, al. Geoglue: A geographic language understanding evaluation benchmark. abs/2305.06545, Arxiv 2023.