Skip to content

Develop CoRE Stack

This section is the main developer chapter for CoRE Stack.

If you are trying to get the backend running, start with Installer.

If you are already set up and want the computation path, continue into Pipeline Development.

This section is for questions like:

  1. where does a request move through the backend?
  2. how are the major subsystems organized?
  3. how do integrations with GEE, GeoServer, and AWS fit together?
  4. how do new pipelines move from local experimentation into stable platform surfaces?
  5. what standards should platform contributors follow?

Main Development Routes


Request Routing

graph TB
    A[Swagger or Client] --> B[nrm_app/urls.py]
    B --> C[geoadmin]
    B --> D[public_api]
    B --> E[computing]
    E --> F[Celery-backed pipeline modules]
    D --> G[GeoServer and DB-backed metadata]
    F --> H[GEE utilities]
    F --> I[GeoServer publishing helpers]
    C --> J[State, district, block models]
    D --> J

The top-level Django router is nrm_app/urls.py. It wires:


Runtime Layers

sequenceDiagram
    participant Client
    participant Django as Django API handler
    participant Celery as Celery task queue
    participant Pipeline as pipeline module
    participant GEE as GEE or GCS helpers
    participant GeoServer as GeoServer publishing

    Client->>Django: request
    Django->>Celery: apply_async(...)
    Celery->>Pipeline: run compute pipeline
    Pipeline->>GEE: read or export assets when needed
    Pipeline->>GeoServer: publish output layer
    Django-->>Client: immediate success response

What Each App Does

geoadmin

  • Implements auth-free location discovery in geoadmin/api.py
  • Backs state, district, and block lookup flows used before heavier computation

public_api

computing

utilities

Note

In operational terms, this means most compute deployments need a configured Django GEEAccount before pipeline execution will work reliably. The setup flow is documented in Google Earth Engine.