feat: support streaming processing of binary search tree

.cursor/rules/general.mdc

@@ -1,7 +1,7 @@
 ---
 description: General rules about the project and coding guidelines
 globs: 
-alwaysApply: false
+alwaysApply: true
 ---
 # Important Rules for LLM
 
@@ -11,6 +11,7 @@ alwaysApply: false
 - If a test fails more than twice in a row, analyze the current situation and collaborate with the user to determine a solution. Avoid trial-and-error testing without a hypothesis.
 - The user has extensive knowledge gained from GitHub and can implement individual algorithms and libraries faster than Cline and Cursor. Code should be written while explaining to the user, using test cases to verify correctness.
 - However, Cline and Cursor is not good at handling processing logic based on the current context. If the context is unclear, confirm with the user.
+- Once I ask you to do "memory it", you should update [general.mdc](mdc:.cursor/rules/general.mdc) or other corresponding document files such as [productContext.md](mdc:.cursor/rules/memory/productContext.md), [specification.md](mdc:.cursor/rules/memory/specification.md), [progress.md](mdc:.cursor/rules/memory/progress.md) so they are kept update to date. Even I don't ask, you should ask me to save memory or not when you think it's needed.
 
 ---
 
@@ -23,23 +24,26 @@ I am a specialized software engineer with a distinct characteristic: my memory r
 All files are stored under [productContext.md](mdc:.cursor/rules/memory/productContext.md), [progress.md](mdc:.cursor/rules/memory/progress.md), [specification.md](mdc:.cursor/rules/memory/specification.md) and `.cursor/memory/*`. The memory bank consists of mandatory core files and optional context files, all formatted in Markdown. 
 
 ### Core Files (Mandatory)
-1. **`productContext.md`**
+1. **`productContext.md`** [productContext.md](mdc:.cursor/rules/memory/productContext.md)
    - Explains the purpose of the project.
    - Identifies the problem it solves.
    - Describes expected functionality and user experience goals.
 
-2. **`specification.md`**
+2. **`specification.md`** [specification.md](mdc:.cursor/rules/memory/specification.md)
    - Explains the detail of FlatCityBuf specification
    - Describes its encoding strategy and decisions made
 
-2. **`progress.md`**
+3. **`progress.md`** [progress.md](mdc:.cursor/rules/memory/progress.md)
    - Completed features and pending tasks.
    - Current status.
    - Known issues.
 
+4. **`tdd-guideline`** [tdd-rust-guidelines.md](mdc:.cursor/rules/memory/tdd-rust-guidelines.md)
+   - Explains the guidline about Test Driven Development
+
 ### Additional Context Files
 
-Additional files and folders can be created inside `memory-bank/` if they aid in organization:
+Additional files and folders can be created inside `memory/rules/memory*` if they aid in organization:
 - Documentation for complex features.
 - Integration specifications.
 - API documentation.

.cursor/rules/memory/productContext.md

@@ -245,14 +245,18 @@ async fn query_by_attribute(fcb_path: &str, field: &str, value: &str) -> Result<
 
 ### **12.4 HTTP Range Requests (JavaScript via WASM)**
 ```javascript
-import { HttpFcbReader } from 'fcb_wasm';
+import init, { HttpFcbReader, WasmAttrQuery } from './fcb_wasm.js';
 
 async function loadFeaturesFromUrl(url) {
+  // Initialize WASM module
+  await init();
+
   // Create HTTP reader
-  const reader = await FlatCityBufReader.fromUrl(url);
+  const reader = await new HttpFcbReader(url);
+  console.log('httpfcbreader instance created.');
 
   // Get header information
-  const header = await reader.getHeader();
+  const header = await reader.header();
   console.log(`loaded file with ${header.features_count} features`);
 
   // Perform spatial query (only downloads necessary parts)
@@ -261,11 +265,19 @@ async function loadFeaturesFromUrl(url) {
     max_x: 4.4, max_y: 52.1
   };
 
-  const features = await reader.queryBbox(
+  // Call the select_bbox method
+  const iter = await reader.select_bbox(
     bbox.min_x, bbox.min_y,
     bbox.max_x, bbox.max_y
   );
 
+  // Iterate through features
+  let features = [];
+  let feature;
+  while ((feature = await iter.next()) !== null) {
+    features.push(feature);
+  }
+
   console.log(`downloaded ${features.length} features using range requests`);
   return features;
 }

.cursor/rules/memory/tdd-rust-guidelines.md

@@ -0,0 +1,64 @@
+
+# Test-Driven Development (TDD) Basics in Rust
+
+## Core Concepts
+
+Test-Driven Development (TDD) follows this development cycle:
+
+1. **Red**: Write a failing test first.
+2. **Green**: Implement the minimum necessary code to pass the test.
+3. **Refactor**: Improve the code while ensuring tests still pass.
+
+## Key Principles
+
+- **Tests define the specification**: Test code expresses the expected behavior of the implementation.
+- **Follow the Arrange-Act-Assert pattern**:
+  1. **Arrange**: Set up the necessary test environment.
+  2. **Act**: Execute the functionality under test.
+  3. **Assert**: Verify the expected result.
+- **Test names should follow a "Condition → Action → Expected Result" format**. Example:
+  - `"Given a valid token, retrieving user information should succeed"`
+
+## Essential Tools for the Refactoring Phase
+
+Once tests pass, use the following tools to refine your code:
+
+### 1. **Static Analysis & Linting**
+   - Run `cargo check` for type checking and borrow checking.
+   - Use `cargo clippy` to detect potential issues and enforce best practices.
+
+### 2. **Dead Code Detection & Removal**
+   - Run `cargo deadlinks` to check for dead documentation links.
+   - Use `cargo udeps` to find unused dependencies.
+   - Run `cargo rustc -- -W dead_code` to detect unused functions.
+
+### 3. **Code Coverage Analysis**
+   - Install `cargo-tarpaulin` for test coverage measurement:
+     ```bash
+     cargo install cargo-tarpaulin
+     cargo tarpaulin --out html
+     ```
+   - Open the generated HTML report to review coverage.
+
+### 4. **Version Control with Git**
+   - Commit after each phase (test creation → implementation → refactoring).
+   - Review changes before committing:
+     ```bash
+     git status  # Check modified files
+     git add <relevant files>
+     git commit -m "<appropriate commit message>"
+     ```
+   - Use commit prefixes for clarity:
+     - `test:` - Adding or modifying tests
+     - `feat:` - Implementing new features
+     - `refactor:` - Code refactoring
+
+## Further Reading
+
+For more details on TDD practices in Rust, naming conventions for tests, and best practices for refactoring, refer to:
+
+```
+.docs/tdd-rust-guidelines.md
+```
+
+This file includes step-by-step instructions for test-first development, structuring test cases, and leveraging Rust’s testing framework efficiently.

.gitignore

@@ -64,3 +64,5 @@ src/rust/fcb_core/tests/data/
 .cursorrules
 
 *.fcb
+
+.cursor/mcp.json

src/rust/bst/Cargo.toml

@@ -5,7 +5,7 @@ edition = "2021"
 
 [features]
 default = ["http"]
-http = ["packed_rtree"]
+http = ["http-range-client", "async-trait", "bytes"]
 
 [dependencies]
 bincode = { workspace = true }
@@ -14,5 +14,13 @@ anyhow = { workspace = true }
 chrono = { workspace = true }
 ordered-float = { workspace = true }
 once_cell = { workspace = true }
-packed_rtree = { path = "../packed_rtree", optional = true }
 thiserror = { workspace = true }
+http-range-client = { workspace = true, optional = true, default-features = false }
+async-trait = { workspace = true, optional = true }
+bytes = { workspace = true, optional = true }
+
+[dev-dependencies]
+tokio = { workspace = true, features = ["rt", "macros"] }
+async-trait = { workspace = true }
+bytes = { workspace = true }
+tempfile = "3.10.1"