Overhaul Raster Calculator

WalkerKB — Sat, 25 Jan 2025 15:48:16 GMT

Raster Calculator is an amazing toolset, but it seems antiquated and clunky. It's processes are comparatively slow and there is little to no multi-threading or GPU enabled processing. There are a number of python tools that have emerged over the last decade and a number of new requirements with stacked data. One example of clunkiness is there is no "Round" function only work arounds like int(raster + 0.5).

All in all an overhaul would be a significant level of effort, but would better align with broader trends in scientific computing, data science, and big raster analytics.

Here are some additional options that ChatGPT came up with:

1. Adopt more Pythonic Syntax

A single unified module instead of map algebra behind arcpy.sa... make it single module e.g. import arcgis.raster as rt. building on that bring in direct python functions like rt.round(raster) so that all the logic fits.

2. Full Integration of Python Built-Ins
One of the biggest frustrations is that not all Python functions (like round() or advanced math functions from math or numpy) are directly usable in Raster Calculator. Esri could:

Embed a Python interpreter that truly compiles or interprets your expressions as standard Python code, rather than parsing them in a specialized subset.
Expose safe versions of built-in Python functions (round, floor, ceil, hypot, sqrt, etc.) as first-class citizens for raster math.
Support standard libraries like NumPy or SciPy in a restricted sense (like numpy.sin(raster) or numpy.clip(raster, 0, 255)) without forcing users to do the manual RasterToNumPyArray round trip.

3. Advanced Array Operations (à la NumPy / xarray)
Many advanced raster operations in data science rely on array-like manipulations—stacking layers, broadcasting operations, rolling or shifting windows, etc. Currently, you can do some of this with arcpy.sa.Con, FocalStatistics, etc., but it can get verbose. An overhaul might include:

True xarray-like operations (like ds.sel(x=..., y=...) or ds.mean(dim='time') for time-enabled or mosaic datasets).
Named dimension support for multi-band or multi-dimensional rasters, so you can do myRaster.sel(band="NDVI") or myRaster.sel(time="2025-01-01").
Lazy evaluation or chunked processing behind the scenes, so large raster calculations do not crash memory.

4. Extend Raster Functions to a More Open, Composable Model
ArcGIS has Raster Functions and Function Chains, but they are somewhat tied to the ArcGIS Pro GUI or mosaic datasets. An overhaul might unify:

Raster Functions = First-class Python objects that you can chain in code (like pipeline operators in NumPy or dask).
On-the-fly execution or deferred execution: Let users build a function graph (chain) and only compute when calling .save() or .compute().
Parameterizable function templates that can be saved, shared, or integrated into code, so that writing “my custom slope function” is as simple as creating a Python function

5. Better Error Messaging & Logging
Currently, when Raster Calculator fails, we often see vague messages like ERROR 010240: Could not save raster dataset .... A more modern approach would provide:

Clear stack traces that identify which part of the expression or function failed.
Warnings if dimension limits or data type constraints might be exceeded.

6. Leverage Multicore & GPU Processing
ArcGIS Pro has made progress with multi-threaded or distributed raster analysis, but from a user’s perspective, it’s mostly hidden. A “next generation” map algebra could:

Let users run certain operations on GPU if supported (like a gpu=True parameter).
Scale across multiple cores or machines for big data automatically, if the environment (ArcGIS Enterprise, Portal, or distributed computing) is configured.
Provide transparent out-of-core or chunk-based processing for extremely large rasters, similar to dask.

7. Backwards Compatibility
While a full overhaul could break older scripts, Esri typically needs to maintain continuity. Likely, they would keep the old Raster Calculator tool as-is, but introduce a new advanced environment (like “Raster Analysis Next Gen” or arcpy.rnx) that offers:

A pure-Python approach (or partial rewriting in .NET with Python hooks).
Direct usage of new features while continuing to support old map algebra expressions for older workflows.

Conclusion
In summary, a thorough modernization of the Raster Calculator / Map Algebra stack could:

1. Adopt a more Pythonic approach that allows direct usage of standard Python math (including round()).
2. Integrate with array-based libraries and named dimensions (à la xarray) for modern data science workflows.
3. Provide consistent chunk-based or GPU-accelerated computations for large data.
4. Simplify user expressions while still delivering advanced raster operations.

idea Overhaul Raster Calculator in ArcGIS Pro Ideas

Overhaul Raster Calculator