Skip to content

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

259 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Eozilla App

CI License: MIT TypeScript Vite License: MIT

Eozilla App is a Vite + React + TypeScript frontend for OGC API - Processes services.

It lets you connect to a OGC API - Processes service, browse processes, inspect jobs, and review inputs, outputs, and results in a split-panel interface.

Screenshot

At A Glance

  • Purpose: interact with OGC API - Processes services from a browser UI
  • UI library: Mantine
  • State management: Zustand
  • Data flow: service registry and provider adapters in src/service
  • Persistence: local app state in src/state
  • Testing: Vitest

What You Can Do

  • Select and load a service provider
  • Browse available processes
  • Inspect process descriptions, inputs, and outputs
  • View the job list and job details
  • Open job results and error tracebacks
  • Persist selected service and UI state locally

Repository Map

src/
  components/   UI building blocks, dialogs, and panels
  service/      OGC API - Processes models, providers, registry, and helpers
  state/        Persisted app state and related types
  store/        Zustand store, actions, and hooks
  utils/        General helpers, field utilities, and JSON/schema logic
  main.tsx      Application entry point

Useful entry points when exploring the code:

  • src/main.tsx initializes providers, notifications, and the app root.
  • src/components/Main.tsx defines the main split-panel layout.
  • src/service/index.ts re-exports service-related modules.
  • src/store/store.ts sets up application state.

Getting Started

Prerequisites

  • Node.js and npm
  • Optional: Pixi and a checkout of eozilla if you want to run the local Eozilla Dev-Service backend

Install Dependencies

npm install

Run The Frontend

npm run dev

Run With The Local Dev Service

The eozilla:dev script expects the eozilla-app repository to be checked out into the eozilla Python repository.

First do

git clone https://github.com/eo-tools/eozilla.git`
cd eozilla
pixi install

then

git clone https://github.com/eo-tools/eozilla.app.git`
cd eozilla-app
npm install

and finally

npm run eozilla:dev

and in a second terminal

npm run dev

In the app, select the Dev Service provider.

Useful Scripts

npm run dev            # Start the Vite dev server
npm run eozilla:dev    # Start the local wraptile API server for testing
npm run build          # Type-check and build production assets
npm run eozilla:build  # Type-check and build production assets into eozilla cuiman
npm run tests          # Run the Vitest suite
npm run checks         # Run TypeScript type checking and ESLint
npm run format         # Format source files with Prettier
npm run preview        # Preview the production build locally

Build Versioning

The footer displays the package version plus a release-relative build number:

v0.1.0-dev.0 build 12

The package version comes from package.json. The build number is resolved in this order:

  1. VITE_BUILD_NUMBER
  2. BUILD_NUMBER
  3. The number of commits since the latest reachable public release tag
  4. 0

Public release tags are expected to use the vX.Y.Z format, for example v0.1.0. Development or prerelease tags such as v0.1.0-rc.1 are ignored for the reset point.

To manually override the build number for local testing or deployment, set an environment variable before building:

$env:VITE_BUILD_NUMBER="12"
npm run build
VITE_BUILD_NUMBER=12 npm run build

Working On The Codebase

  • UI work usually belongs in src/components.
  • Process and service integration work usually belongs in src/service.
  • Shared app state and actions belong in src/store.
  • Persisted app state belongs in src/state.
  • Tests live next to the implementation as *.test.ts files.

For LLMs

  • Start with src/components/Main.tsx to understand the app layout.
  • Read src/service/* before changing request/response models or provider behavior.
  • Read src/store/* before changing cross-component state.
  • Keep OGC API - Processes terminology intact:
    • A Process describes a capability exposed by the service.
    • A Job is an execution instance of a process.
  • Prefer small, local changes over broad rewrites.
  • If you change behavior, run npm run checks and npm run tests before finishing.

License

MIT. See LICENSE.

About

A simple frontend for web services compliant with the OGC API - Processes

Resources

Code of conduct

Contributing

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages