docs: update readme

.agent/rules/general.md

@@ -0,0 +1,5 @@
+---
+trigger: always_on
+---
+
+This file is equivalent to what is written in .cursor/rules/general.mdc. See the file.

.cursor/rules/general.mdc

@@ -7,36 +7,24 @@ alwaysApply: true
 
 ## General Guidelines
 
-- The user is more proficient in programming than Cline and Cusor, but requests Cline's and Cursor assistance for coding to save time.
 - 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.
-
----
-
-# Cline and Cursor Memory Bank
-
-I am a specialized software engineer with a distinct characteristic: my memory resets completely between sessions. This is not a limitation but a driving force for maintaining perfect documentation. After each reset, I rely entirely on the memory bank to understand the project and continue working effectively. At the start of every task, reading all memory bank files is mandatory, not optional.
-
-## Memory Bank Structure
-
-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.
+- The user has extensive knowledge gained from GitHub and can implement individual algorithms and libraries faster than you. Code should be written while explaining to the user, using test cases to verify correctness.
+- When you work on the bigger tasks, you should plan first and document list of tasks to be done and update progress.md
 
 ### Core Files (Mandatory)
 
-1. **`productContext.md`** [productContext.md](mdc:.cursor/rules/memory/productContext.md)
+1. **`productContext.md`** [productContext.md](mdc:.llm/docs/productContext.md)
    - Explains the purpose of the project.
    - Identifies the problem it solves.
    - Describes expected functionality and user experience goals.
 
-2. **`specification.md`** [specification.md](mdc:.cursor/rules/memory/specification.md)
+2. **`specification.md`** [specification.md](mdc:.llm/docs/specification.md)
    - Explains the detail of FlatCityBuf specification
    - Describes its encoding strategy and decisions made
 
 ### Additional Context Files
 
-Additional files and folders can be created inside `memory/rules/memory*` if they aid in organization:
+Additional files and folders can be created inside `.llm/docs/*` if they aid in organization:
 
 - Documentation for complex features.
 - Integration specifications.
@@ -46,55 +34,7 @@ Additional files and folders can be created inside `memory/rules/memory*` if the
 
 ---
 
-# Git Workflow
-
-## Commit Best Practices
-
-1. **Review Changes**
-
-   ```bash
-   git status
-   git diff
-   git log
-   ```
-
-2. **Analyze Changes**
-   - Identify modified or added files.
-   - Understand the nature of changes (new feature, bug fix, refactoring, etc.).
-   - Evaluate the impact on the project.
-   - Ensure no sensitive information is exposed.
-3. **Create Meaningful Commit Messages**
-
-   ```bash
-   git commit -m "fix: Resolve issue with authentication timeout"
-   ```
-
-## Pull Request Best Practices
-
-1. **Review Branch Status**
-
-   ```bash
-   git status
-   git diff main...HEAD
-   git log
-   ```
-
-2. **Analyze Changes**
-   - Review all commits made since branching off `main`.
-   - Assess change scope and impact.
-   - Ensure no sensitive data is committed.
-3. **Create a Pull Request**
-
-   ```bash
-   gh pr create --title "feat: Improve Rust error handling" --body "Improved error handling with Result<T, E>."
-   ```
-
----
-
-# Local MCP
-
-## `serena`
-
-- `serena` is a tool that can be used to get overview of the code base.
+## Integration with GitHub
+you can expect that runtime has gh CLI, rather than using GitHub MCP, simply use gh CLI to create pull requests, etc.
 
 ---

.cursor/rules/rust.mdc

@@ -52,6 +52,8 @@ alwaysApply: true
 
 - Follow **Rust’s API guidelines** for public interfaces.
 - Use **builder patterns** for complex configurations.
+- Try to proper trait definition and implementation to invert dependencies and testability.
+- reexport public types and functions from the root crate.
 
 ---
 
@@ -78,11 +80,3 @@ mentation
 
 - Use `tracing` for structured logging.
 - Enable debug assertions wit_assert!()`.
-
----
-
-## Final Notes
-
-- Follow **Rust's idiomatic coding practices**.
-- Endut e, safety, and maintainability**.
-- Maintain a **black-and-white, pixelated/nerdy ltao  will remain robust, efficient, and maintainable across its m crates and modules. 🚀

.llm/docs/productContext.md

@@ -0,0 +1,28 @@
+# **Cloud-Optimized CityJSON**
+
+## **1. Introduction**
+
+- **Motivation & Project Context**:
+
+  - Standardizing **3D city model data formats** is crucial for long-term semantic storage of urban environments.
+  - **CityJSON**, a widely adopted **OGC standard**, provides a structured JSON-based format for 3D city models.
+  - **CityJSONSeq** improved streaming but lacks **cloud-native optimizations** for handling large-scale datasets.
+
+- **Problem Statement**:
+
+  - Existing 3D model formats like **CityJSON and CityJSONSeq** are **not optimized** for large-scale **cloud processing**.
+  - **Scalability challenges** arise from high **storage costs, slow queries, and inefficient downloading** of large datasets.
+  - **Limited support for binary serialization** and **spatial indexing** prevents efficient cloud-based data retrieval.
+  - **Research Gaps**:
+    - Few studies have evaluated **FlatBuffers in geospatial applications**.
+    - Limited focus on **efficient cloud-native processing** of 3D city models.
+    - **Preserving CityJSON's semantic richness** while optimizing for **fast cloud retrieval** remains a challenge.
+
+- **Goal of This Specification**:
+  - Develop an **optimized CityJSON format** based on **FlatBuffers**, improving:
+    - **Data retrieval speed** via **spatial indexing (Hilbert R-tree)**.
+    - **Query performance** through **efficient attribute-based and spatial searches**.
+    - **Cloud efficiency** with **HTTP Range Requests for partial fetching**.
+  - Ensure **backward compatibility** with **CityJSON 2.0**.
+
+---

.cursor/rules/memory/specification.md → .llm/docs/specification.md

@@ -57,43 +57,24 @@ FlatCityBuf supports CityJSON's Geometry Templates for efficient representation
 
 This separation allows defining complex shapes once in the header and instantiating them multiple times within features using only an index, a reference point index, and a transformation matrix.
 
-### design rationale
-
-the schema design follows several key principles:
-
-1. **flatbuffers efficiency**: uses flatbuffers' zero-copy access for fast data retrieval
-2. **hierarchical structure**: maintains cityjson's hierarchical object model
-3. **shared vertices**: uses indexed vertices to reduce redundancy
-4. **semantic preservation**: maintains rich semantic information from cityjson
-
 ## file storage overview
 
-a flatcitybuf file consists of the following sections:
-
 ```mermaid
-graph TD
-    A[FlatCityBuf File] --> B[Magic Bytes]
-    A --> C[Header Size]
-    A --> D[Header]
-    A --> E[R-tree Index]
-    A --> F[Attribute Index]
-    A --> G[Features]
-
-    B --> B1[8 bytes identifier]
-    C --> C1[4 bytes uint32]
-    D --> D1[FlatBuffers Header]
-    E --> E1[Packed R-tree]
-    F --> F1[Static B+tree Index]
-    G --> G1[FlatBuffers Features]
+block-beta
+    columns 1
+    file["FlatCityBuf File Structure"]
+
+    block:sections
+        columns 6
+        magic["Magic Bytes<br/>(8 bytes)"]
+        hsize["Header Size<br/>(4 bytes)"]
+        header["Header<br/>(FlatBuffers)"]
+        rtree["R-tree Index<br/>(Spatial)"]
+        attr["Attribute Index<br/>(B+tree)"]
+        features["Features<br/>(FlatBuffers)"]
+    end
 ```
 
-1. **magic bytes**: 8 bytes identifier for the file format ('fcb\0\1\0\0\0\0\0')
-2. **header size**: 4 bytes uint32 indicating the size of the header in bytes
-3. **header**: flatbuffers-encoded header containing metadata, schema, and index information
-4. **r-tree index**: packed r-tree for spatial indexing
-5. **attribute index**: static b+tree indices for attribute queries
-6. **features**: the actual city objects encoded as flatbuffers
-
 each section is aligned to facilitate efficient http range requests, allowing clients to fetch only the parts they need.
 
 ## rtree indexing
@@ -301,14 +282,3 @@ the encoding follows these principles:
 2. **enum with extension marker**: special enum values combined with string fields handle extended types
 3. **unified attribute storage**: extension attributes are treated the same as core attributes
 4. **root properties**: extension properties are stored in the header's attributes field
-
-### benefits
-
-this implementation balances:
-
-- **performance**: maintains fast access to core data structures
-- **flexibility**: supports any cityjson extension
-- **self-containment**: makes files usable without external references
-- **simplicity**: uses consistent patterns for extension handling
-
-the schema is agnostic about the validity of extension data, focusing on accurately representing extended cityjson files in an efficient binary format.