hydrodataset

A Python package for accessing hydrological datasets with a unified API, optimized for deep learning workflows.

• 🌊 Unified Interface: Consistent API across 27 hydrological datasets
• ⚡ Fast Access: NetCDF caching locally / Zarr caching on cloud for instant data loading
• 🎯 Standardized Variables: Common naming across all datasets
• 🔗 Built on AquaFetch: Powered by the comprehensive AquaFetch backend
• 📊 ML-Ready: Optimized for integration with torchhydro

Table of Contents

• Core Philosophy
• Installation
• Quick Start
• Local vs Cloud Data Access
• Supported Datasets
• Key Features
• Project Status
• Credits

Core Philosophy

This library has been redesigned to serve as a powerful data-adapting layer on top of the AquaFetch package.

While AquaFetch handles the complexities of downloading and reading numerous public hydrological datasets, hydrodataset takes the next step: it standardizes this data into a clean, consistent format — NetCDF (.nc) locally, Zarr on cloud object storage — optimized for seamless integration with hydrological modeling libraries like torchhydro.

One unified way to reach any dataset. Every dataset is addressed by a logical id ("camels_us", "bull", …) resolved through a single chain:

~/hydro_setting.yml (storage config) → resolve_data_path / open_dataset → absolute path or s3:// URI

You never construct a data path by hand. open_dataset(dataset_id, source="local"|"cloud") resolves the id, picks the right reader class, and returns an instantiated dataset — source is chosen per call, or defaults to storage.default_source. When you need the raw path or a specific class directly, resolve_data_path(dataset_id) + the class constructor remain available (see Quick Start).

The core workflow is:

1. Resolve: resolve_data_path / open_dataset turns a dataset id into an absolute local path or an s3:// URI, using the config in ~/hydro_setting.yml.
2. Standardize: The hydrodataset reader (backed by AquaFetch) fetches raw data and exposes it through a consistent, unified interface across all datasets.
3. Cache: On the first run, the data is processed into an xarray.Dataset and saved as .nc files (timeseries + attributes) in the local cache directory — or as Zarr stores on cloud storage for source="cloud".
4. Access: All subsequent requests read from the fast cache (NetCDF locally / Zarr on cloud), giving you analysis-ready data instantly.

Installation

We strongly recommend using a virtual environment to manage dependencies.

Using uv (Recommended)

We recommend using uv for fast, reliable package and environment management:

# Install uv if you haven't already
pip install uv

# Install hydrodataset with uv
uv pip install hydrodataset

For more advanced usage or to work on the project locally:

# Clone the repository
git clone https://github.com/OuyangWenyu/hydrodataset.git
cd hydrodataset

# Create virtual environment and install all dependencies
uv sync --all-extras

The --all-extras flag installs base dependencies plus all optional dependencies for development and documentation.

Using pip (Alternative)

If you prefer traditional pip:

# Create and activate a virtual environment
python -m venv .venv
source .venv/bin/activate  # On Windows: .venv\Scripts\activate

# Install the package
pip install hydrodataset

Quick Start

The primary goal of hydrodataset is to provide a simple, unified API for accessing various hydrological datasets. Here's a complete example showing the core workflow:

⚠️ Important Note on First-Time Data Download

If you haven't pre-downloaded the datasets, the first access will trigger automatic downloads via AquaFetch, which can take considerable time depending on dataset size:

• Small datasets (< 1GB, e.g., CAMELS-CL, CAMELS-COL): ~10-30 minutes
• Medium datasets (1-5GB, e.g., CAMELS-AUS, CAMELS-BR): ~30 minutes to 1 hour
• Large datasets (10-20GB, e.g., CAMELS-US, LamaH-CE): ~1-3 hours
• Very large datasets (> 30GB, e.g., HYSETS): ~3-6 hours or more

Download times vary based on your internet connection speed and server availability.

We strongly recommend downloading datasets manually during off-peak hours if possible.

After the initial download, all subsequent access will be fast thanks to NetCDF caching (locally) or Zarr caching (on cloud).

Basic Example

from hydrodataset import open_dataset

# open_dataset reads storage config from ~/hydro_setting.yml.
# Example hydro_setting.yml:
#
#   storage:
#     local:
#       root: D:/data/hydrodatasets
#
# source defaults to storage.default_source ("local" unless configured otherwise).
ds = open_dataset("camels_us")

# 1. Check which features are available
print("Available static features:")
print(ds.available_static_features)

print("Available dynamic features:")
print(ds.available_dynamic_features)

# 2. Get a list of all basin IDs
basin_ids = ds.read_object_ids()

# 3. Read static (attribute) data for a subset of basins
# Note: We use standardized names like 'area' and 'p_mean'
attr_data = ds.read_attr_xrdataset(
    gage_id_lst=basin_ids[:2],
    var_lst=["area", "p_mean"]
)
print("Static attribute data:")
print(attr_data)

# 4. Read dynamic (time-series) data for the same basins
# Note: We use standardized names like 'streamflow' and 'precipitation'
ts_data = ds.read_ts_xrdataset(
    gage_id_lst=basin_ids[:2],
    t_range=["1990-01-01", "1995-12-31"],
    var_lst=["streamflow", "precipitation"]
)
print("Time-series data:")
print(ts_data)

Explicit construction (advanced)

open_dataset is the recommended entry point. If you need the resolved path directly (e.g. to pass it somewhere) or want to instantiate a specific reader class, use resolve_data_path + the class constructor — this is equivalent and still fully supported:

from hydrodataset import resolve_data_path
from hydrodataset.camels_us import CamelsUs

data_path = resolve_data_path("camels_us")   # absolute local path (or s3:// URI)
ds = CamelsUs(data_path)                     # same object as open_dataset("camels_us")

Standardized Variable Names

A key feature of the new architecture is the use of standardized variable names. This allows you to use the same variable name to fetch the same type of data across different datasets, without needing to know the specific, internal naming scheme of each one.

For example, you can get streamflow from both CAMELS-US and CAMELS-AUS using the same variable name:

# Get streamflow from CAMELS-US
us_ds.read_ts_xrdataset(gage_id_lst=["01013500"], var_lst=["streamflow"], t_range=["1990-01-01", "1995-12-31"])

# Get streamflow from CAMELS-AUS
aus_ds.read_ts_xrdataset(gage_id_lst=["A4260522"], var_lst=["streamflow"], t_range=["1990-01-01", "1995-12-31"])

Similarly, you can use precipitation, temperature_max, etc., across datasets. See Standard Variables for the comprehensive list of standardized names and their coverage across datasets.

Local vs Cloud Data Access

hydrodataset can read the same datasets from either a local disk or cloud object storage (S3-compatible, e.g. Alibaba Cloud OSS). The backend is chosen per call with source="local" | "cloud"; when omitted, storage.default_source from ~/hydro_setting.yml is used (default: local).

Both backends share one configuration file, ~/hydro_setting.yml:

storage:
  default_source: local         # local | cloud — used when `source` is omitted
  local:
    root: D:/data/hydrodatasets # absolute local path; must exist
  cache: data/cache             # optional; relative paths resolve against local.root
  s3:
    bucket: hydrodataset        # required for cloud access
    prefix: ""                  # optional prefix inside the bucket
    endpoint_url: https://oss-cn-beijing.aliyuncs.com
    access_key_id: <your-access-key>
    secret_access_key: <your-secret-key>

Local

• resolve_data_path("camels_us", source="local") returns an absolute local path under storage.local.root.
• Readers cache analysis-ready data as NetCDF files ({dataset}_timeseries.nc, {dataset}_attributes.nc) in the cache directory (storage.cache, default ~/.cache/hydrodataset). Missing caches are generated automatically on first read.

Cloud

• resolve_data_path("camels_us", source="cloud") returns an S3 URI such as s3://hydrodataset/.
• Readers access the raw dataset directly on OSS via s3fs and cache analysis-ready data as Zarr stores at s3://<bucket>/zarr/{dataset}_timeseries.zarr and ..._attributes.zarr (with consolidated metadata). Missing Zarr stores are generated automatically on first read — typically on a cloud VM (ECS) using the internal OSS endpoint for bandwidth.

Recommended usage: open_dataset(dataset_id, source=...) — one call to resolve and construct, source picks the backend per call. resolve_data_path(dataset_id, source=...) is for when you need the raw path or URI explicitly (e.g. to inspect or pass it on). Both share the same source semantics:

from hydrodataset import resolve_data_path, open_dataset

# Local
local_uri = resolve_data_path("camels_us", source="local")
ds = open_dataset("camels_us", source="local")
ts = ds.read_ts_xrdataset(
    gage_id_lst=["01013500"],
    t_range=["1990-01-01", "1995-12-31"],
    var_lst=["streamflow", "precipitation"],
)

# Cloud
cloud_uri = resolve_data_path("camels_us", source="cloud")
print(cloud_uri)  # e.g. s3://hydrodataset/
ds_cloud = open_dataset("camels_us", source="cloud")
ts_cloud = ds_cloud.read_ts_xrdataset(
    gage_id_lst=["01013500"],
    t_range=["1990-01-01", "1995-12-31"],
    var_lst=["streamflow"],
)

The CLI exposes the same --source switch:

hydrodataset config                                    # show effective config (secrets masked)
hydrodataset resolve camels_us --source local
hydrodataset resolve camels_us --source cloud
hydrodataset info camels_us --source cloud
hydrodataset read-ts bull --source cloud --gages BULL_10004 --vars precipitation -o ts.nc

Notes:

• The config file lives in your home directory (~/hydro_setting.yml). A project-level .hydro_setting.yml in the project root is also supported and overrides user-level settings.
• storage.s3.* contains credentials — never commit it to a repository.
• Readers constructed with an s3:// URI skip local path validation and are treated as cloud readers (_is_cloud()).

Supported Datasets

hydrodataset currently provides unified access to 27 hydrological datasets across the globe. Below is a summary of all supported datasets:

Key Features

🎯 Unified API Across All Datasets

Access any dataset using the same method calls:

# Same API works for all datasets
ds.read_object_ids()                          # Get basin IDs
ds.read_attr_xrdataset(...)                   # Read attributes
ds.read_ts_xrdataset(...)                     # Read timeseries

⚡ Fast Caching (NetCDF locally, Zarr on cloud)

First access processes and caches data; all subsequent reads are instant:

• Local: NetCDF files {dataset}_timeseries.nc / {dataset}_attributes.nc
• Cloud: Zarr stores {dataset}_timeseries.zarr / {dataset}_attributes.zarr (with consolidated metadata)
• Configured via ~/hydro_setting.yml (storage.cache locally, storage.s3 for cloud)

🔄 Standardized Variable Names

Use common names across all datasets:

• streamflow - River discharge
• precipitation - Rainfall
• temperature_max / temperature_min - Temperature extremes
• potential_evapotranspiration - PET
• And many more...

📊 xarray Integration

All data returned as xarray.Dataset objects:

• Labeled dimensions and coordinates
• Built-in metadata and units
• Easy slicing, selection, and computation
• Compatible with Dask for large datasets

🌐 Station Network Connectivity (LamaH-CE)

LamaH-CE dataset supports querying stream network topology between gauging stations:

from hydrodataset import resolve_data_path
from hydrodataset.lamah_ce import LamahCe

ds = LamahCe(resolve_data_path("lamah_ce"))

# Read station connectivity data
stations = ds.read_stations_xrdataset(station_id_lst=["3", "4"])
print(stations)
# Returns: NEXTDOWNID, dist_hdn, elev_diff, strm_slope

See LamaH-CE API documentation for detailed variable descriptions and usage examples.

Project Status

hydrodataset provides unified access to 27 hydrological datasets, all implemented on the HydroDataset base class with the ADR 0001 path-resolution architecture (resolve_data_path → absolute URI → reader). CAMELS-US and CAMELS-AUS serve as the reference implementations; every other supported dataset follows the same pattern.

New datasets and features are added continuously. Please check the Changelog for the latest updates.

Credits

This package was created with Cookiecutter and the giswqs/pypackage project template. The data fetching and reading is now powered by AquaFetch.