Supported operations#
GeoUtils supports scalable execution for most of its raster methods, including nearly all raster–point and raster–vector interface operations. Support for vector and point-cloud accessors is partially supported through Dask-GeoPandas and under development.
Chunked implementations can run through either Dask (via the Xarray and Pandas accessors) or Multiprocessing (via GeoUtils objects such as Raster).
Both object types (accessors or GeoUtils) expose the exact same API, and both chunked backends use the same internal logic, and all methods are tested to yield identical output as in-memory.
Table summary#
The table below summarizes the scalability support of GeoUtils operations with respect to their input and output behavior. Operations marked as chunked are also validated with inputs larger than the memory available to one worker.
If you are unfamiliar with chunked and lazy execution or deferred I/O, see the Concept definitions page.
Legend
Chunked — Processes in chunks, without loading (for input) and/or returning (for output) the full data. This is also lazy (deferred execution) when using Dask, but not when using Multiprocessing.
In-memory — Loads (for input) or returns (for output) full data in-memory.
Deferred I/O — Deferred input/output by updating internal metadata (as Xarray’s
isel()).
The ⟶ symbol denotes methods interfacing from one specific object type to another, with point-cloud type shortened to “Point”.
The memory usage column lists the number of input chunks loaded in memory for a given operation.
Method |
Input |
Output |
Memory usage (# chunks) |
|---|---|---|---|
Raster ⟶ Raster |
|||
Chunked |
Chunked |
~4 (with default output chunking) |
|
Deferred I/O |
Deferred I/O |
0 |
|
Deferred I/O |
Deferred I/O |
0 |
|
Deferred I/O |
Deferred I/O |
0 |
|
Chunked |
Chunked |
~2–3 (if small filter window) |
|
In-memory |
In-memory |
— |
|
Raster ⟶ Point |
|||
Chunked |
In-memory |
~1 |
|
Chunked |
In-memory |
~1 |
|
Chunked |
In-memory |
~1 |
|
Raster ⟶ Vector |
|||
Chunked |
In-memory |
~1–2 |
|
Raster ⟶ Other |
|||
In-memory |
In-memory |
— |
|
In-memory |
In-memory |
— |
|
Point ⟶ Point |
|||
In-memory |
In-memory |
— |
|
In-memory |
In-memory |
— |
|
In-memory |
In-memory |
— |
|
Chunked |
Chunked |
~1 point partition and nearby points within the search radius |
|
Point ⟶ Raster |
|||
Chunked |
Chunked |
~1 point partition and 1 output chunk |
|
In-memory |
In-memory |
— |
|
Vector ⟶ Raster |
|||
In-memory |
Chunked |
~1 |
|
In-memory |
Chunked |
~1 |
|
Vector ⟶ Point |
|||
In-memory |
In-memory |
— |
|
Point ⟶ Other |
|||
In-memory |
In-memory |
— |
Note that nearly all raster inputs/outputs methods support Chunked, while point and vector inputs/outputs are currently In-memory, as often less limiting.
For more insights into chunked implementation strategies and behaviour expected for each operation, see the Implementation strategies page.