InVEST (Integrated Valuation of Ecosystem Services and Tradeoffs)

repository·main·Indexed 42 days ago

https://github.com/natcap/invest

A suite of tools and ecosystem service models designed to quantify the economic and societal values of natural capital. It provides a desktop application, a Python package (natcap.invest), and Docker images to help decision-makers assess tradeoffs between land-use scenarios and conservation strategies.

Tokens
38.4K
Snippets
133
Records
187
Agent score
54%

What's inside InVEST

  1. Overview of the InVEST Codesigning Service

    main

    The InVEST Codesigning Service is composed of three main components used to manage binary signing:

    1. Cloud Function (gcp-cloudfunc/): A Google Cloud Storage-backed function that acts as a high-latency queue.
    2. Enqueue Script (enqueue-binary.py): A Python script used to enqueue existing binaries located in GCS buckets.
    3. Systemd Service: A service running on a Debian machine (ncp-inkwell) that periodically polls the cloud function to dequeue and sign items.
  2. Overview of the InVEST scripting framework

    main
    The InVEST scripting framework is designed to help users automate batch runs of models or add custom functionality to the existing InVEST software suite. It allows for programmatic control over model execution, parameter studies, and data management.
  3. What is an InVEST plugin?

    main

    An InVEST plugin is a Python package that conforms to the natcap.invest plugin API. Conceptually, it represents an ecosystem services model or a workflow that composes multiple models.

    Plugins can be used to:

    • Implement new stand-alone models or variations of existing core InVEST models.
    • Perform pre-processing (data preparation) or post-processing (output manipulation) steps.
    • Wrap existing software tools implemented in other languages.

    Technically, because they conform to the plugin API, they can be executed via the InVEST workbench (GUI) and the invest command-line tool without requiring separate frontend development.

  4. Internationalization file structure and types

    main

    InVEST uses the gettext system for internationalization. The following files are used to manage translations:

    • messages.pot: The message catalog template. It contains all translatable strings from the source code without the actual translations. All .po files are derived from this.
    • locales/<lang>/LC_MESSAGES/messages.po: A human-readable catalog file where translators add msgstr values for the strings found in the template.
    • locales/<lang>/LC_MESSAGES/messages.mo: A machine-readable, compiled version of the .po file used by gettext at runtime. These are generated during the install process (via setup.py) and are not checked into version control.

    Directories under locales/ are named after ISO 639-1 language codes.

  5. Enable parallel processing in InVEST models

    main

    Most InVEST models support an optional n_workers key in the args dictionary to enable parallel processing.

    Supported values for n_workers:

    • -1: Synchronous execution (default).
    • 0: Threaded task management.
    • Positive integer: The number of processes to create (e.g., 4). A common recommendation is 2 * multiprocessing.cpu_count().

    CRITICAL WARNING: If you enable parallel processing, you must wrap your execution code in an if __name__ == '__main__': block. Failure to do so will result in a fork bomb.

    if __name__ == '__main__':
        args['n_workers'] = 4  # Use 4 processes
        
        # ... rest of your loop or execution logic
        natcap.invest.ndr.ndr.execute(args)
  6. Access Wind Energy model outputs via wind_energy_points.shp

    main

    In recent versions of the Wind Energy model, rasterized outputs have been removed to prevent invalid data interpolation in areas outside the input wind data coverage.

    Instead of looking for .tif files, users should retrieve all model results—including power density, harvested energy, and valuation data—from the wind_energy_points.shp vector file. Each point in this shapefile corresponds to a row in the input Wind Data Points CSV and contains the summarized values for that specific geographic coordinate.

    ### Expected Output Mapping
    
    | Previous Raster Output | New Location in `wind_energy_points.shp` |
    | :--- | :--- |
    | `density_W_per_m2.tif` | Point attribute |
    | `harvested_energy_MWhr_per_yr.tif` | Point attribute |
    | `carbon_emissions_tons.tif` (Valuation) | Point attribute |
    | `levelized_cost_price_per_kWh.tif` (Valuation) | Point attribute |
    | `npv.tif` (Valuation) | Point attribute |
  7. How InVEST interacts with plugins

    main

    InVEST supports plugins at both the Python library level and the Workbench UI level.

    Python Level

    When natcap.invest is imported, it automatically searches for installed Python packages that follow the plugin pattern. A package is identified as a plugin if:

    1. Its package name begins with invest.
    2. It contains the required attributes (such as MODEL_SPEC) described in the plugin developer's guide.

    Once identified, these plugins are recorded in natcap.invest.models and are accessible via natcap.invest just like core models.

    Workbench Level

    In the InVEST Workbench, plugins are installed via the "Manage Plugins" window. Users can provide a Git URL or a local path. The installation process follows these steps:

    1. Download pyproject.toml (if using a Git URL).
    2. Parse metadata from pyproject.toml.
    3. Create a micromamba environment containing python, git, and dependencies specified in tool.natcap.invest.conda_dependencies within the pyproject.toml.
    4. Install the plugin into that environment using pip.
    5. Import the plugin and access metadata from MODEL_SPEC.
    6. Save the plugin information to the workbench settings store.

    Note on Versioning: The Workbench identifies plugins using a hash of the model_id (from MODEL_SPEC) and the package.version (from pyproject.toml). This allows multiple versions of the same plugin to be installed simultaneously. However, at the Python level, only one plugin with the same package name can be active at a time.

  8. Select an InVEST container version for reproducibility

    main

    InVEST containers can be referenced using different types of tags. For scientific reproducibility, it is strongly recommended to use a SHA256 digest rather than a moving tag like latest.

    Available referencing methods:

    1. SHA256 Digest (Recommended for reproducibility): Refers to a specific, immutable version of the container.
      • Example: ghcr.io/natcap/invest@sha256:8a4a3c621c09e1df74821efa0eb8e2cd90ea6e228e393e953cb4ea0ff8d37454
    2. InVEST Version Tag: Refers to a specific InVEST release.
      • Example: ghcr.io/natcap/invest:3.16.2
    3. Git Commit SHA256: Refers to the specific git revision of the natcap/invest repository used to build the container.
      • Example: ghcr.io/natcap/invest:e756a7a43d598f2130199bf1c9ad4d2df4975cfd
    4. latest Tag: Points to the most recent build. Do not use this for reproducible analyses.
      • Example: ghcr.io/natcap/invest:latest
  9. How to modify or use specific components of an InVEST model

    main
    If you need to go beyond standard model execution—such as modifying the internal logic of a model or using only specific sub-components—you should refer to the complete API reference. The entrypoint functions are sufficient for standard runs, but the full API provides access to the underlying modular structure.
  10. Understand the structure of an InVEST Python script

    main

    InVEST Python scripts consist of two primary components:

    1. The argument dictionary (args): A dictionary where keys represent the model's input parameters (matching the UI labels) and values represent the input data or settings.
    2. The model execution call: A call to the model's execute function, which takes the args dictionary as its single parameter.

    API Pattern: Every InVEST model follows a consistent syntax: [module_name].execute(args). For example, the Nutrient Delivery Ratio (NDR) model is invoked via natcap.invest.ndr.ndr.execute(args).

    Output Registry: As of version 3.17.0, the execute function returns a dictionary summarizing all produced output files. This dictionary maps output IDs (defined in the model's MODEL_SPEC) to their absolute file paths, allowing for programmatic access to results.

    import natcap.invest.ndr.ndr
    
    args = {
        'biophysical_table_path': 'path/to/table.csv',
        'dem_path': 'path/to/dem.tif',
        # ... other parameters
    }
    
    if __name__ == '__main__':
        # execute returns a dictionary of output paths
        outputs = natcap.invest.ndr.ndr.execute(args)
  11. Manage dependencies in package.json

    main

    When managing dependencies for the Workbench, follow these rules to ensure correct packaging by electron-builder:

    • dependencies: Include ONLY Node modules used by the main process.
    • devDependencies: Include all dependencies for the Renderer and preload processes (e.g., react, bootstrap). These are required for production but are bundled via Vite, so electron-builder should ignore them to avoid double-packaging.
  12. Required input data for the Wave Energy Model

    main

    The Wave Energy Model requires three specific files for each location of interest. These files must be placed in the input/WaveData/ directory. Note that the relationship between UI dropdown selections and these data files is hardcoded; adding a new location requires a developer request.

    Required files:

    1. ww3_binary_data.bin: A binary file containing Wave Watch III data.
    2. wave_point_data.shp: A shapefile containing wave point data, including wave periods and wave height values.
    3. wave_point_bounding_area.shp: A polygon shapefile acting as a bounding box for wave_point_data.shp. This is used for clipping outputs and must cover all points in the wave point shapefile.