_validate_raster: complex dtype passes the numeric check

[brendancol]

Summary

xrspatial/utils.py _validate_raster() checks np.issubdtype(agg.dtype, np.number) to enforce a numeric dtype. np.complex64 and np.complex128 are subtypes of np.number, so the check passes for complex-valued DataArrays even though every consumer in the library expects real-valued raster data.

Reproducer

from xrspatial.utils import _validate_raster
import xarray as xr, numpy as np

raster = xr.DataArray(np.zeros((10, 10), dtype=np.complex128))
_validate_raster(raster, func_name="example")  # accepts silently

_validate_raster returns without raising. Downstream operations then run arithmetic, comparisons, and np.where(np.isnan(...)) on complex arrays. Some backends raise a confusing TypeError mid-kernel, others compute with the real component only and produce silently wrong outputs.

Expected

_validate_raster should reject complex dtypes with a clear error that names the offending parameter.

Fix

Tighten the dtype check to np.issubdtype(dtype, np.number) and not np.issubdtype(dtype, np.complexfloating), and update the docstring to say "real numeric (integer or float)".

Source

Found while auditing xrspatial/utils.py validators (Cat 6 input validation).