We've built a service to search stac-geoparquet with a STAC API query. A development version is available at https://stac-geoparquet.labs.eoapi.dev/.
@gadomski presented on this lab at the 2025 Cloud-Native Geospatial Conference. His slides are here. The companion blog post is here.
Warning
This project was a science experiment, and will not be actively maintained after April 2025. These instructions and code will bitrot and fall out-of-date. We preserve them in case they're useful to future adventurers.
Get uv, then:
git clone [email protected]:developmentseed/labs-375-stac-geoparquet-backend.git
cd labs-375-stac-geoparquet-backend
uv sync --all-groups
Our "katas" live in docs/katas. These are notebooks that exercise stac-fastapi-geoparquet and stac-fastapi-pgstac and report performance metrics.
We use the AWS Cloud Development Kit (CDK) for Infrastructure-as-Code (IaC). The code is located in infrastructure/aws. See Releasing and deploying for how we normally do deploys.
During development, you might want to run cdk
yourself.
First, install it.
Then:
source .venv/bin/activate
cd infrastructure/aws
cp .env.local .env
# Make sure you're using the eoAPI sub-account
aws sso login --profile eoapi && eval "$(aws configure export-credentials --profile eoapi --format env)" # or however you configure your AWS sessions
cdk diff # to show any differences
Our deploys are triggered by Github releases (or by workflow dispatch, in a pinch). To create a release:
scripts/release
This will create a draft release in Github and print its url to the console. The release will target the current main branch. Go to the Github URL, edit the release as you see fit, then publish it to trigger a deploy. If you need to manually release, use the Github releases interface to cut one.
We use CalVer with the following scheme: vYYYY.MM.DD.n
, where n
is the release count for the day.
If you're releasing more than ten times in a day, stop, take a breath, and come back tomorrow.
We love 🌳. Almost everything's in a hierarchy:
- Issue 1 is the tree root
- Under Issue 1 there are several phases, which may run simultaneously
- Phases are composed of User stories
- Finally, tasks are the leaves. Tasks might live here, or they might be issues on other repos.
graph TD
issue_1 --> phase_0
issue_1 --> phase_1
phase_1 --> story_0
phase_1 --> story_1
story_1 --> task_0
story_1 --> task_1
issue_1["Issue 1"]
phase_0["Phase 0"]
phase_1["Phase 1"]
story_0["User story 0"]
story_1["User story 1"]
task_0["Task 0"]
task_1["Task 1"]
Milestones are checkpoints and are used to group phases. Bugs and one-off tasks can live outside of the hierarchy.