feat(tilepack): add first-pass OGC process API

[ZainabTravadi]

What type of PR is this? (check all applicable)

• 🍕 Feature
• 🐛 Bug Fix
• 📝 Documentation
• 🧑‍💻 Refactor
• ✅ Test
• 🤖 Build or CI
• ❓ Other (please specify)

Related Issue

Fixes #302

Describe this PR

This PR adds a minimal OGC-compatible process discovery and execution surface for the existing tilepack workflow.

It introduces:

• GET /processes to discover available processes
• GET /processes/tilepack to describe the tilepack process
• POST /processes/tilepack/execution to trigger the existing tilepack workflow

The new process API is implemented as a thin adapter over the existing tilepack execution path. It reuses the current validation, S3 idempotency/output handling, Kubernetes Job creation, and pgSTAC publication flow rather than introducing a separate execution framework or database.

The tilepack ingress is also updated to expose the new /processes routes.

This is intentionally a first-pass implementation focused on establishing the process API convention with one existing OAM workflow. Cross-service /processes routing, a global process registry, additional processing workflows, and a separate /jobs/{jobId} API are left for future work.

Screenshots

Not applicable. This PR adds backend API endpoints and deployment configuration without UI changes.

Alternative Approaches Considered

The issue discussion considered using ZOO-Project to provide the OGC Processes API and introducing a broader workflow/process layer.

For this first pass, I chose to keep the implementation within the existing tilepack service and adapt the current tilepack execution flow instead.

This avoids introducing a new execution framework or database before validating the API convention against a real OAM processing workflow.

A broader /processes registry or multi-service routing strategy can be addressed separately once the first process implementation has been reviewed.

Review Guide

The main areas to review are:

1. Process discovery:

   • GET /processes
   • GET /processes/tilepack
   • GET /processes/unknown → 404

2. Process execution:

   • POST /processes/tilepack/execution
   • Verify canonical {"inputs": {...}} request handling
   • Verify invalid JSON and invalid inputs are rejected

3. Backward compatibility:

   • Existing POST /tilepacks/{id} behavior remains unchanged
   • The new execution endpoint delegates to the same tilepack execution logic

4. Deployment:

   • Review the tilepack ingress routing for /processes

5. Tests:

   • go test ./...
   • go vet ./...

The implementation intentionally does not add a separate job registry; the existing tilepack execution/status behavior remains the source of truth for this first pass.

Checklist before requesting a review

• 📖 Read the OAM Contributing Guide: https://github.com/hotosm/openaerialmap/blob/main/CONTRIBUTING.md
• 📖 Read the HOT Code of Conduct: https://docs.hotosm.org/code-of-conduct
• 👷‍♀️ Create small PRs. In most cases, this will be possible.
• ✅ Provide tests for your changes.
• 📝 Use descriptive commit messages.
• 📗 Update any related documentation and include any relevant screenshots.

[spwoodcock]

Any thoughts on the comment in #302 before we go ahead and implement?

How could we plan to maintain modularity of OAM, when the /processes endpoint is maintained by the tilepack-api svc?

1. Should we rename tilepack-api into process-api?
2. How can we make other microservices discoverable via the single GET /processes if it's owned by a single microservice?
3. How to handle routing via Kubernetes Ingress or similar?

I don't have answers to these questions - hence the need for more discussion 😅

[ZainabTravadi]

I agree — I think these are the right architectural questions to settle before we go further with #309.

My current implementation was intentionally a first-pass adapter inside "tilepack-api", mainly to validate what an OGC Processes surface would look like against a real OAM workflow. But I agree that making "tilepack-api" the long-term owner of a global "/processes" endpoint could work against the modularity of the platform.

I think we should first decide where the process catalog/routing layer belongs:

• A dedicated "process-api" / gateway could own the global "/processes" discovery and route execution to the appropriate processing service.
• Individual processing services could continue owning their own process implementations.
• Kubernetes Ingress/API Gateway could potentially handle the service-level routing rather than making "tilepack-api" aware of every process in OAM.

I'm happy to pause #309 here and work on the architectural direction first rather than locking us into the current ownership model.

[spwoodcock]

First we need to know what GET /processes is supposed to return.

Perhaps we could implement this as a simple Nginx Ingress response if its simple enough