Skip to content

View or edit on GitHub

This page is synchronized from doc/Google-Cloud-Platform.md. Last modified on 2026-09-20 13:50 CEST by Nicolas Martin. Please view or edit the original file there; changes should be reflected here after a midnight build (CET time), or manually triggering it with a GitHub action (link).

Google Cloud Platform (GCP), Gemini and Earth Engine

Using Gemini

There are a number of ways to interact with Gemini:

  • Gemini web app (gemini.google.com/): For general use, like a conversational chatbot.
  • Gemini AI Studio playground (aistudio.google.com/): For exploring the models and prototyping apps without needing to write any code. This web interface is always free to use, but comes with certain usage restrictions.
  • Vertex AI Studio (console.cloud.google.com/vertex-ai/studio): For developing AI applications and accessing more advanced features.
  • API: For integrating Gemini into your own scripts and accessing paid features without rate limitations.

Accessing Gemini via the API

You can do this via either an API key or a Application Default Credentials (ADC). We strongly recommend ADCs. An API key is scoped to a whole project, while ADCs are tied to a user or service account. ADCs support granular IAM roles, and handle credential rotation automatically. API keys are static, broad in scope, and easier to leak or misuse.

To generate an ADC see README.md – Section D: If you are going to be interacting with Google Cloud. You may need the role roles/aiplatform.user. If you are not able to do this then ask on the #data-systems channel on Slack.

The API can then be used as follows from Python:

from google import genai

client = genai.Client(vertexai=True, project="trase-396112", location="global")

prompt = "Write a short essay about what a great person I am"
response = client.models.generate_content(model="gemini-2.5-flash", contents=prompt)
answer = response.text.strip()

or from R:

# install.packages(c("httr2", "gargle"))  # if needed
library(httr2)
library(gargle)

project  <- "trase-396112"
location <- "global"
model    <- "gemini-2.5-flash"

prompt <- "Write a short essay about what a great person I am"

# Load credentials (assumed to have already been created e.g. by `gcloud auth application-default login`)
tok <- gargle::credentials_app_default(
  scopes = "https://www.googleapis.com/auth/cloud-platform"
)
access_token <- tok$credentials$access_token

# Vertex AI Generative endpoint for Gemini
endpoint <- paste0(
  "https://", location, "-aiplatform.googleapis.com/v1/",
  "projects/", project,
  "/locations/", location,
  "/publishers/google/models/", model, ":generateContent"
)

# Build request body
body <- list(
  contents = list(
    list(
      role  = "user",
      parts = list(list(text = prompt))
    )
  )
)

# Call the API
resp <- request(endpoint) |>
  req_headers(Authorization = paste("Bearer", access_token)) |>
  req_body_json(body) |>
  req_method("POST") |>
  req_perform()

# Extract the text response
dat <- resp_body_json(resp)
answer <- tryCatch(
  dat$candidates[[1]]$content$parts[[1]]$text,
  error = function(e) ""
)
cat(trimws(answer))

Google Earth Engine (GEE)

Trase uses Earth Engine through two separate access mechanisms:

  1. The Cloud project
  2. What lives there: Assets under projects/trase-396112/assets/...
  3. Access is governed by: Google Cloud IAM on the trase-396112 project

  4. To grant access: Grant IAM roles on the project

  5. The legacy trasegis account

  6. What lives there: Code Editor script repositories (users/trasegis/indicators, users/trasegis/tools, …) and legacy assets (users/trasegis/STORAGE/...)
  7. Access is governed by: Earth Engine's own per-repository and per-asset sharing, which we point at the trasegis Google Group
  8. To grant access: Add them to the trasegis Google Group

Since 13th November 2024 every request to Earth Engine has to go through a registered Cloud project: you select trase-396112 in the Code Editor's project picker, or pass ee.Initialize(project="trase-396112") from Python. That is true even if all you are doing is opening a script from users/trasegis/... or reading a legacy asset. The project is what authorises the request and what the compute usage is counted against.

What the Cloud project does not do is grant access to anything in the users/trasegis/... namespace. Those resources are owned by the legacy trasegis Earth Engine account, which predates the Cloud project and has its own sharing model. Granting someone IAM roles on trase-396112 will not make the trasegis script repositories appear in their Code Editor, and removing those roles will not take them away. Most people need both.

Why we still have a legacy account

Two reasons, for the time being:

  • Storage. The trasegis account holds an uplifted free asset-storage quota (around 5 TB). An uplift granted on a legacy account is not transferred automatically when you move to a Cloud project — it has to be requested from Google separately — so migrating everything today would mean losing it. To see the current usage and limit, hover over the asset root in the Code Editor's Assets tab and click the usage icon.
  • Live code. A lot of code that is still in use lives in, or depends on, the trasegis script repositories and legacy assets, for example require('users/trasegis/tools:ghg_conversion_calculator/modules') and users/trasegis/STORAGE/BR/CARBON/... in trase/data/world/cdo/carbon_emissions.

New assets should nevertheless be written into the Cloud project (projects/trase-396112/assets/...), which is where most recent work already puts them.

1. Cloud project access (trase-396112)

Trase's project is trase-396112, the same project used for Gemini above, and assets owned by it are addressed as:

projects/trase-396112/assets/...

Access to those assets is governed by Google Cloud IAM, so adding someone to this half of GEE means granting them an IAM role on the project.

First, make sure the person has a Google account

IAM principals are Google accounts, so an account has to exist before there is anything to grant a role to. Our convention is a full @trase.earth Google Workspace user account:

  • A default-routing email alias is not sufficient: an alias is only a forwarding rule, there is no account behind it to sign in with. See G-Suite.md – Step 2: user account for how to create the account, and README.md – Section E for the credentials the user then generates for themselves.
  • Nothing stops you granting a role to an address that has no account behind it — gcloud accepts user:someone@trase.earth regardless — so a binding that looks right is not proof that anybody can actually use it.

Once the account exists, grant the roles below.

Which roles to grant

They need to… Roles
Read/view Trase assets only roles/earthengine.viewer
Read assets and run Earth Engine against Trase's project/quota roles/earthengine.viewer + roles/serviceusage.serviceUsageConsumer
Upload, modify or delete Trase assets roles/earthengine.writer (+ roles/serviceusage.serviceUsageConsumer to run code)

roles/earthengine.viewer ("Earth Engine Resource Viewer") lets a user view and list Earth Engine assets and tasks. roles/serviceusage.serviceUsageConsumer ("Service Usage Consumer") is required to consume the project's services — without it, ee.Initialize(project="trase-396112") will fail even if the user can see the assets. Use roles/earthengine.writer ("Earth Engine Resource Writer") instead of viewer where write access is needed; do not grant both.

Adding a user via the Cloud Console

  1. Open IAM & Admin → IAM for trase-396112.
  2. Check the project selector at the top reads trase-396112.
  3. Click Grant access.
  4. Under New principals, enter their email address, e.g. someone@trase.earth.
  5. Under Assign roles, add the roles from the table above.
  6. Click Save.

The same flow can be reached from the Earth Engine Code Editor: under Assets, hover over the Cloud project and click the share icon.

Adding a user via the CLI

Requires the gcloud CLI and enough permission on the project to modify the IAM policy (roles/resourcemanager.projectIamAdmin or owner).

gcloud projects add-iam-policy-binding trase-396112 \
  --member="user:someone@trase.earth" \
  --role="roles/earthengine.writer" \
  --condition=None

# Only if they need to run Earth Engine using Trase's project and quota:
gcloud projects add-iam-policy-binding trase-396112 \
  --member="user:someone@trase.earth" \
  --role="roles/serviceusage.serviceUsageConsumer" \
  --condition=None

Use roles/earthengine.viewer in place of roles/earthengine.writer if they only need read access.

Two things catch people out here:

  • --condition=None is required. Our project policy already contains conditional bindings, so gcloud refuses to add an unconditional binding silently and instead drops into an interactive prompt ("The policy contains bindings with conditions, so specifying a condition is required when adding a binding"). Passing --condition=None explicitly adds the binding with no condition, which is what we want — the existing conditional bindings belong to unrelated services and should be left alone.
  • The user: prefix is not optional. --member="someone@trase.earth" is rejected; it must be --member="user:someone@trase.earth".

For a service account rather than a person, use --member="serviceAccount:name@trase-396112.iam.gserviceaccount.com".

Check what someone currently has:

gcloud projects get-iam-policy trase-396112 \
  --flatten="bindings[].members" \
  --filter="bindings.members:someone@trase.earth" \
  --format="value(bindings.role)"

2. Legacy access (users/trasegis/...)

This is the older, pre-Cloud Earth Engine mechanism. The trasegis Earth Engine account owns two kinds of thing:

  • Script repositories, listed in the Code Editor's Scripts tab and browsable over git at earthengine.googlesource.com/users/trasegis: users/trasegis/indicators, users/trasegis/tools, users/trasegis/sei-pcs and so on. Earth Engine code is kept there rather than in this repository (see README.md) and is copied to GitHub occasionally as a backup (see Backups.md).
  • Legacy assets under users/trasegis/... — in full, projects/earthengine-legacy/assets/users/trasegis/... — such as users/trasegis/STORAGE/BR/CARBON/....

Access is granted per repository and per asset using Earth Engine's own sharing controls: the settings icon next to a repository in the Scripts tab, the Share dialog on an asset, or earthengine acl from the command line. None of this is Cloud IAM, and none of it appears in gcloud projects get-iam-policy.

In practice we share with the trasegis Google Group, so granting access is:

  1. Add the person's Google account to the group — normally the same @trase.earth account they use for the Cloud project, so that both halves work in a single browser session.

  2. Ask them to reload the Code Editor and look at the Scripts tab. The trasegis repositories should appear under Reader (or Writer, if they have been given write access):

    ▾ Reader (2)
    ▸ users/trasegis/indicators
    ▸ users/trasegis/tools

  3. If something they need is still missing, it was probably shared with individuals rather than with the group. Share it with them directly from the Code Editor, and consider re-sharing it with the group so it does not have to be done by hand again.

Being in the group is not on its own enough to run anything: they still need a Cloud project, as described in section 1 above.

Offboarding a user from GEE

Offboarding is not a single action: someone may hold access through IAM on the Cloud project (mechanism 1 above), through the trasegis Google Group (mechanism 2), and through assets and script repositories they own personally. Work through all three. This section is referenced from User-Offboarding.md, which covers every other system.

  1. Check what they currently hold on the project:

    gcloud projects get-iam-policy trase-396112 \
  --flatten="bindings[].members" \
  --filter="bindings.members:someone@trase.earth" \
  --format="value(bindings.role)"

  2. Remove each Earth Engine role returned above. Either delete the principal in the IAM Console (bin icon next to their entry), or:

    gcloud projects remove-iam-policy-binding trase-396112 \
  --member="user:someone@trase.earth" \
  --role="roles/earthengine.writer" \
  --condition=None

gcloud projects remove-iam-policy-binding trase-396112 \
  --member="user:someone@trase.earth" \
  --role="roles/serviceusage.serviceUsageConsumer" \
  --condition=None

    --condition=None is required here for the same reason as when adding, and the role string must match the binding exactly — removing roles/earthengine.writer does nothing if what they actually hold is roles/earthengine.viewer.

  3. Remove them from the trasegis Google Group. This is a separate grant from IAM and is what controls the legacy script repositories and assets under users/trasegis/.... Removing their IAM roles does not remove them from the group, and vice versa. If anything under users/trasegis/... was shared with them individually rather than with the group, that sharing has to be removed in the Code Editor as well.

  4. Check for assets and scripts they own personally. Anything in their own legacy namespace (users/their-username/...) rather than in projects/trase-396112/assets/... or users/trasegis/... leaves with them. If a pipeline depends on such an asset or script, copy it into the project before their account is deleted.

  5. Re-run the get-iam-policy command from step 1 and confirm it returns nothing.