The current Google Earth Engine (GEE) initialization logic in src/ingestion.py is tightly coupled with hardcoded project IDs and attempts interactive authentication as a default fallback. This creates dependencies on specific user environments and makes the module difficult to reuse in automated pipelines or remote servers without manual intervention.
Current Limitations
- Hardcoded Project ID: The variable my_gee_project is defined directly within
main(), requiring code changes for different environments.
- Interactive Auth Dependency: The try-except block assumes an interactive session for ee.Authenticate(), which fails gracefully in non-interactive builds.
- Side Effects: Initialization directly prints to stdout and doesn't provide a way to check status programmatically.
Proposed Solution
Refactor the initialization logic to be independent and configurable:
- Extract Initialization: Move initialize_gee to a dedicated utility module (e.g., src/utils/gee_utils.py).
- Configuration Injection: Accept the Project ID as an argument or read from an environment variable (e.g., GEE_PROJECT_ID).
- Robust Error Handling: Provide clear error messages for missing credentials instead of forcing interactive ee.Authenticate() in non-interactive contexts.
Pseudo Code
FUNCTION initialize_gee (INPUTS: gee_project, gee_key)
TRY:
IF key_path is provided AND file exists:
- Create a Service Account Credential using the JSON file.
- INITIALIZE Earth Engine using these specific credentials and the gee_project ID.
ELSE (No key file provided)
CATCH (any errors):
- PRINT: "Authentication required."
- EXECUTE: ee.Authenticate() to trigger a manual web-browser login flow.
- INITIALIZE Earth Engine using the newly generated manual token and the gee_project ID.
Logic Flow Summary
- Primary Path: Automated login via Service Account (Best for servers/headless).
- Secondary Path: Local environment initialization (Best for personal laptops).
- Fallback Path: Manual browser-based authentication (Interactive backup).
The current Google Earth Engine (GEE) initialization logic in src/ingestion.py is tightly coupled with hardcoded project IDs and attempts interactive authentication as a default fallback. This creates dependencies on specific user environments and makes the module difficult to reuse in automated pipelines or remote servers without manual intervention.
Current Limitations
main(), requiring code changes for different environments.
Proposed Solution
Refactor the initialization logic to be independent and configurable:
Pseudo Code
FUNCTION
initialize_gee(INPUTS:gee_project,gee_key)TRY:
IF
key_pathis provided AND file exists:ELSE (No key file provided)
CATCH (any errors):
Logic Flow Summary