GeoAI Workbench Instructions

Scope

These instructions apply to the entire repository at E:\AllWorkProject\geoai-workbench.
Read PROJECT_CONTEXT.md before planning or changing a capability.

Project Definition

• In this repository, GeoAI means workflows based on opengeos/geoai (geoai-py), not every spatial-intelligence feature.
• Keep the capability boundary explicit:
• A: directly provided or documented by geoai-py.
• B: built with geoai-py plus geospatial or AI ecosystem libraries.
• C: a product/service capability that consumes GeoAI outputs.
• Verify current APIs against the installed package, source, or official documentation. Do not label B or C work as a built-in GeoAI function.
• Treat the user as a beginner who supplies goals, sample data, and visual feedback. Explain decisions in clear Chinese and handle implementation, environment work, debugging, and verification end to end.

Repository Conventions

• Keep one capability in capabilities/<number>-<name>/.
• Every capability must have a README.md and requirements.txt; add code, tests, configs, and examples only when needed.
• Share compatible dependencies through requirements/base.txt. Use .venvs/<capability> for isolated environments when needed.
• Use Python 3.12 for GeoAI and deep-learning capabilities. Do not install project dependencies into system Python.
• Store reusable code in src/geoai_common/ only after it is genuinely shared.
• Keep raw data, processed data, weights, caches, and generated outputs out of Git and under the existing shared/ layout.

Capability Workflow

1. Read the root documentation, PROJECT_CONTEXT.md, and the target capability README.
2. Classify the capability as A, B, or C and identify the exact role of geoai-py.
3. Define a runnable Demo with real input, inspectable output, structured metadata, and measurable acceptance criteria.
4. Inspect hardware and existing environments before installing dependencies. Default to CPU because no NVIDIA CUDA is available.
5. Validate one normal and one difficult representative sample before running a full directory.
6. Visually inspect generated images, maps, documents, or spreadsheets.
7. Record model, package, dataset, and weight licenses independently before suggesting commercial use.
8. Update the capability README and PROJECT_CONTEXT.md after verified changes.

Engineering Rules

• Prefer existing project patterns and geoai-py APIs over new abstractions.
• Preserve geospatial coordinates only when the input has a valid CRS and transform. Ordinary JPEG results remain pixel coordinates.
• Report false positives, misses, runtime, and unsupported classes honestly. Do not hide limitations by lowering thresholds.
• Do not batch-run large datasets until a representative validation indicates that the approach is suitable.
• Do not delete or overwrite source imagery, model weights, results, or unrelated user changes.
• Do not commit unless the user explicitly asks.