Feature request: option to disable water masking entirely

[yumorishita]

Summary

Phase unwrapping fails frequently (unwrap error) on AOIs that include water bodies (rivers, coastlines). We'd like an option to fully disable water masking in the workflow, rather than only being able to supply a custom mask file.

Example

With water mask (unwrap errors around river/coastline):

Without water mask:

Current behavior

Workflow._run_dolphin (src/sweets/core.py) always calls create_water_mask() as part of step 1, and passes the resulting raster to dolphin as mask_file:

mask_fut = pool.submit(
    create_water_mask,
    self.water_mask_filename,
    self._water_mask_bbox,
)
...
def _run_dolphin(self, gslc_files: list[Path]) -> "OutputPaths":
    mask = self.water_mask_filename if self.water_mask_filename.exists() else None
    return run_displacement(
        ...
        mask_file=mask,
        ...
    )

--water-mask-filename (CLI) lets a user point to a pre-existing mask raster, but there is no way to tell sweets to skip masking altogether — water_mask_filename always resolves to a path (<work_dir>/watermask.tif by default) and, if it doesn't exist yet, sweets downloads/builds one automatically via create_water_mask() in src/sweets/_water_mask.py.

For context: the water mask is built by mosaicking ASF's WATER_MASK/TILES product (https://asf-dem-west.s3.amazonaws.com/WATER_MASK/TILES/), which is itself a mosaic of OpenStreetMap + ESA WorldCover data. Any misclassification in those upstream sources (e.g. rivers/coastlines mapped incorrectly, or resolution mismatches after warping to the AOI) propagates directly into dolphin's mask_file and can contribute to unwrap errors around water boundaries.

Request

Add an explicit way to disable water masking, e.g.:

• A --disable-water-mask / --no-water-mask CLI flag (or a water_mask_filename=None-with-explicit-sentinel convention) that:
  • Skips the create_water_mask() call in step 1.
  • Passes mask_file=None to run_displacement in _run_dolphin, regardless of whether a file happens to exist at the default path.
    This is distinct from the existing --water-mask-filename option, which requires the user to prepare/supply a mask themselves — useful, but not a quick way to just turn masking off for troubleshooting or for AOIs where masking is doing more harm than good.

Why

• Diagnosing whether water masking is a contributing factor to frequent unwrap errors currently requires manually deleting/renaming watermask.tif (and re-running with starting_step tricks) rather than a documented, first-class option.
• Some AOIs may not need masking at all (e.g., no significant water bodies, or a user already trusts dolphin's unwrapper to handle it), so forcing a mask (auto-built or user-supplied) adds unnecessary friction.

Environment

• sweets @ 8e51d7c (2026-06-08)
• Relevant files: src/sweets/core.py, src/sweets/dem.py, src/sweets/_water_mask.py, src/sweets/cli.py

[scottstanie]

Interesting! Many times I've found that forgetting the water mask leads to unwrapping errors, but I can see how your example would create the separate zones, between which snaphu ignores. Adding a bridging here would also probably work, but I see no reason why disabling masking shouldn't be available too.

Just checking - could you post the sweets config that ran this, or was it just the defaults (I.e. that it was SNAPHU that unwrapped like this?)

[yumorishita]

Attached is the config file (my username was manually removed). I mostly used defaults.

sweets_config.yaml