Skip to content

viewshed() mutates the caller's input DataArray (int16 becomes float64) #2786

@brendancol

Description

@brendancol

Describe the bug

viewshed() mutates the caller's input DataArray. The CPU path runs raster.data = raster.data.astype(np.float64, copy=False) at xrspatial/viewshed.py:1584, and the non-RTX CuPy fallback replaces raster.data with a NumPy array at xrspatial/viewshed.py:1735. After calling viewshed() on an int16 DataArray, the caller's array comes back as float64 (or as NumPy instead of CuPy). A function that reads a raster should not silently change the caller's dtype and backing buffer.

To Reproduce

import numpy as np
import xarray as xr
from xrspatial import viewshed

arr = xr.DataArray(
    np.arange(25, dtype=np.int16).reshape(5, 5),
    dims=("y", "x"),
    coords={"y": np.arange(5.0), "x": np.arange(5.0)},
)
print(arr.dtype)        # int16
viewshed(arr, x=2, y=2)
print(arr.dtype)        # float64  <-- input was mutated

Expected behavior

viewshed() should leave the caller's DataArray untouched: same dtype, same backing buffer. The float64 cast (and the CuPy to NumPy conversion in the fallback) should happen on a local copy.

Fix

Cast into a local variable instead of reassigning raster.data. The dask path already does this correctly via raster.copy().

Backends affected

numpy (CPU path) and cupy (non-RTX fallback). The dask path is already safe.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workinginput-validationInput validation and error messagesseverity:highSweep finding: HIGH

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions