Design of Spatial Query APIs for Road Network Applications

1. Design of Spatial Query APIs for Road Network Applications 2010/10

2. Introduction • Location-dependent spatial queries (LDSQs) • A fundamental data access operations for LBSs • Two common LDSQs • k-nearest neighbor (kNN) Search – e.g., Find the nearest bus station to the conference venue • Range search -- Find hotels within 10-minutes walk from the conference venue • The-state-of-the-art LDSQ works • Cannot accommodate diverse objects simultaneously • used to query one category in one database, e.g., parking lots and restaurants are indexed in different databases. Sometimes we would like to check the gas station while determining going to the preferred parking lot. • Cannot effectively support different distance metrics, e.g., road distance or travel time • Efficient solutions are only designed based on the Euclidean Distance rather than the real routing distance/time. • Extensions of the Dijkstra’s algorithm were devised but inevitably face performance impact in the large search space

3. Introduction • System is designed to support basic LDSQ, e.g., KNN query and range query, in Road Networks • We have designed a spatial query algorithm with optimized search structure. • The structure maintains skeleton description of shortest road paths in memory • Utilize the skeleton information can reduce most of shortest path calculation, which is especially effective in large road networks • The system is called as ROAD, abbreviated from Route Overlay and Association Directory, i.e., two major components in the framework.

4. Introduction (Cont’d) • The system will be designed as two parts • Server-side (our focus) • Functionality for constructing road network database (imported from the provided shape raw files) • Functionality for constructing skeleton information for the road networks • Functionality for location-dependent object query • Efficient network traversal methodology • Functionality for location-dependent object lookup in the road network • Client-side: interactive demonstration for query functions

5. Introduction (Cont’d) • ROAD system is designed based on a new idea. We call RNET • RNET is a region subset within the road network • The whole network can be partitioned into a set of disjointed RNETs • RNET contains pre-computed skeleton shortest path of data in the RNET

6. Introduction (Cont’d) • a RNET consists of • A subnet of the road network, i.e., a set of roads • A set of boundary nodes • A boundary node is a node connected/shared by two RNETs • shortcut information between any two boundary nodes in the RNET • shortcut consists of the shortest road paths from the start point to the end point. • Abstraction described what kinds of objects within the RNET

7. Introduction (Cont’d) • We consider to devise RNET as a level-wise structure • Wide regional RNET encloses a set of small regional RNETs.

8. System Architecture Road Database Rnet Hierarchy Association Directory UI Data Preprocessing candidate objects KNN Search/ Range Search Client side Data Collection Core Components Server side

9. Project Schedule • Current Status: • DataBase ready • Taiwan Road data was converted and imported into PostGIS/PostgreSQL successfully • JDBC Connection is ready. • Computation of RNET is ongoing • We are implementing the shortest-path algorithm, and the solution to partition road networks into RNETs.

10. Project Schedule (Cont’d)