Even Faster Geosocial Reachability Queries

Geosocial reachability queries (\textsc{RangeReach}) determine whether a given vertex in a geosocial network can reach any spatial vertex within a query region. The state-of-the-art 3DReach method answers such queries by encoding graph reachability through interval labelling and indexing spatial vertices in a 3D R-tree. We present 2DReach, a simpler approach that avoids interval labelling entirely. Like 3DReach, 2DReach collapses strongly connected components (SCCs) into a DAG, but instead of computing interval labels, it directly stores a 2D R-tree per component over all reachable spatial vertices. A query then reduces to a single 2D R-tree lookup. We further propose compressed variants that reduce storage by excluding spatial sinks and sharing R-trees between components with identical reachable sets. Experiments on four real-world datasets show that 2DReach achieves faster index construction than 3DReach, with the compressed variant yielding the smallest index size among all methods. 2DReach delivers competitive or superior query performance with more stable response times across varying query parameters.

💡 Research Summary

Paper Overview
The paper addresses the RangeReach problem in location‑based social networks (LBSNs): given a query vertex u and an axis‑aligned rectangle R, determine whether u can reach any spatial vertex whose location lies inside R. The state‑of‑the‑art solution, 3DReach, first collapses strongly connected components (SCCs) into a directed acyclic graph (DAG), then assigns each component a set of post‑order intervals (interval labeling). Spatial vertices are mapped to 3‑dimensional points (x, y, post) and indexed in a 3‑D R‑tree. A query is answered by issuing one 3‑D range query per interval label of the query component. While effective, 3DReach suffers from two major drawbacks: (1) the interval‑label construction is computationally expensive, and (2) the 3‑D R‑tree incurs larger bounding boxes (six floats per node) and more complex range predicates than a 2‑D structure.

Key Idea of 2DReach
2DReach eliminates interval labeling entirely. After SCC decomposition, each DAG node c directly stores the set of all spatial vertices reachable from c. This set is built by processing the DAG in reverse topological order: for each node, merge the reachable sets of its children and add its own spatial vertices. Then a conventional 2‑D R‑tree is built on that merged set. Query processing becomes trivial: locate the SCC containing the query vertex, retrieve its associated 2‑D R‑tree, and perform a single 2‑D range query against R. No graph traversal, no interval checks, and only one spatial index lookup are required.

Compression Variants
Real LBSNs often contain spatial vertices that are sinks (no outgoing edges). The authors propose two compression techniques:

1. Sink Exclusion – During SCC decomposition, spatial sinks are omitted from the DAG; instead, they are attached directly to the parent component that points to them. This reduces the number of nodes d in the DAG.
2. R‑Tree Sharing – If two or more components have identical reachable spatial sets, they share a single R‑tree instance. A pointer or bit‑vector maps each component to its shared tree.

These mechanisms produce the “Compressed 2DReach” variant (2DReach‑Comp) and a further pointer‑optimized version (2DReach‑Pointer) that stores pointers only for non‑spatial components, further shrinking memory overhead.

Theoretical Analysis
Let d be the number of SCCs, p the number of spatial vertices, n the total number of vertices, and e the number of edges in the DAG.

• Space: In the worst case each component stores a 2‑D R‑tree containing up to p points, yielding O(d·p) space. The compressed version does not increase this bound.
• Construction Time: Building the SCC decomposition is linear. Merging reachable sets across the DAG costs O(d·p·(d + log p)) because each merge may insert up to p points and each R‑tree build costs O(p·log p). Empirically this is far lower than the O(|V|·|E|) interval labeling of 3DReach.
• Query Time: A single 2‑D R‑tree lookup costs O(log M p) on average (M = max entries per node). The worst‑case is O(p) if the tree degenerates, matching the theoretical bound of a naïve scan.

Experimental Evaluation
Four real LBSN datasets were used: Yelp, Foursquare, Gowalla, and Weeplaces. All experiments were run on a laptop with 64 GB RAM and a 3.8 GHz CPU. Methods compared: 3DReach, 3DReach‑Rev (single 3‑D query variant), standard 2DReach, 2DReach‑Comp, and 2DReach‑Pointer.

• Index Construction: 2DReach variants built indexes 2–4× faster than 3DReach. The compressed version added negligible overhead while still outperforming 3DReach.
• Storage: Standard 2DReach required ~30 % less space than 3DReach because 2‑D R‑trees store four floats per node versus six in 3‑D. The compressed variant reduced total size further (up to 55 % reduction) by eliminating sinks and sharing trees.
• Query Performance: Average query latency for 2DReach ranged from 0.2 ms to 0.5 ms, comparable to or better than 3DReach‑Rev (which already reduces to a single 3‑D query). When the query region was small or the query vertex had low out‑degree, 2DReach consistently outperformed 3DReach because the latter must issue multiple 3‑D range queries (one per interval label).
• Stability: Across varying region extents, vertex degrees, and spatial selectivity ratios, 2DReach’s response times showed less variance, indicating more predictable performance for real‑time applications.

Conclusions and Impact
2DReach demonstrates that interval labeling—a cornerstone of many graph reachability indexes—can be bypassed for the specific case of geosocial reachability when the spatial dimension is two‑dimensional. By precomputing reachable spatial sets per SCC and storing them in lightweight 2‑D R‑trees, the method achieves faster index construction, smaller memory footprints, and query times that are at least as good as the best existing solutions, with far more stable latency. The compression techniques exploit typical LBSN characteristics (spatial sinks, duplicate reachable sets) to further shrink the index, making 2DReach highly suitable for deployment in large‑scale, latency‑sensitive location‑based services such as POI recommendation, geo‑targeted advertising, and contact‑tracing analytics.