CostDistance "thread 'main' panicked at 'called `Option::unwrap()` on a `None` value'"

[alpha-beta-soup]

WhiteboxTools v2.3.0, Ubuntu 22.04.3 LTS, via Conda 23.7.2

I have two input rasters for the CostDistance tool.

• Source: A byte (8-bit unsigned integer) raster with 1 for source locations, and 0 (nodata) everywhere else.
• Cost: A byte raster with 1 for valid places, and 0 (nodata) everywhere else. (The cost value of 1 is intended to represent a simple constant friction value, i.e. distance on a plane).

I'm attempting to produce an output that expresses the "network distance" from the source pixels, with traversal limited to the cost pixels. So each non-0 (non-nodata) pixel in the cost raster will have a value of 0 in the output (where the source and cost rasters coincide), or an integer >1 where they are some distance from the source pixels. Nodata values (which are the same in the source and the cost) should remain nodata, and do not need to be considered. Both the source and the cost represent a combined rasterisation of coastlines, deep rivers, and lake edges. I'm attempting to measure traversal along these "edges", ignoring the possibility of over-land or over-water traversal—by modelling everything else as no data.

Blue = "source" (valid value is 1, everything else is nodata=0); red = "cost" (constant value of 1, everything else is nodata=0). Note that everything that has a value of 1 in source also has a value of 1 in cost, i.e. that blue is merely drawn on top of red values in these images.

export RUST_BACKTRACE=full && \
whitebox_tools -r="CostDistance" -v \
--source=navigable-water-within-distance-2018.tif \
--cost=navigable-water.tif \
--backlink=navigable-water-reachable-backlink-2018.tif \
--output=navigable-water-cost-distance-2018.tif

****************************
* Welcome to CostDistance  *
* Powered by WhiteboxTools *
* www.whiteboxgeo.com      *
****************************
Reading source data...
Reading cost data...
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', whitebox-raster/src/lib.rs:1361:69
stack backtrace:
   0:     0x5629038946c0 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hb070b7fa7e3175df
   1:     0x5629038bbd0e - core::fmt::write::hd5207aebbb9a86e9
   2:     0x562903890925 - std::io::Write::write_fmt::h3bd699bbd129ab8a
   3:     0x562903895ef3 - std::panicking::default_hook::{{closure}}::h04cca40023d0eeca
   4:     0x562903895bdf - std::panicking::default_hook::haa3ca8c310ed5402
   5:     0x56290389659a - std::panicking::rust_panic_with_hook::h7b190ce1a948faac
   6:     0x562903896451 - std::panicking::begin_panic_handler::{{closure}}::hbafbfdc3e1b97f68
   7:     0x562903894b6c - std::sys_common::backtrace::__rust_end_short_backtrace::hda93e5fef243b4c0
   8:     0x5629038961b2 - rust_begin_unwind
   9:     0x562902939ba3 - core::panicking::panic_fmt::h8d17ca1073d9a733
  10:     0x562902939a6d - core::panicking::panic::hf0565452d0d0936c
  11:     0x56290368e759 - whitebox_raster::get_raster_type_from_file::hf25ccc5692bcb5cf
  12:     0x56290368a1d2 - whitebox_raster::Raster::initialize_using_file::h36406f9b3422e3ff
  13:     0x5629034e7c02 - <whitebox_tools::tools::gis_analysis::cost_distance::CostDistance as whitebox_tools::tools::WhiteboxTool>::run::h9422b22018d68133
  14:     0x5629029c27d1 - whitebox_tools::tools::ToolManager::run_tool::he0e7e3beec1628e5
  15:     0x562902f27848 - whitebox_tools::run::h16c6dd715d7f4e31
  16:     0x562902f2489a - whitebox_tools::main::hc1836ef44cabc602
  17:     0x562902fdd413 - std::sys_common::backtrace::__rust_begin_short_backtrace::h2964d03e2a06fe43
  18:     0x56290309b2a9 - std::rt::lang_start::{{closure}}::h6a7b201fbcc3fca6
  19:     0x56290388bdff - std::rt::lang_start_internal::h6ba1bb743c1e9df9
  20:     0x562902f28a68 - main
  21:     0x7fdc7f12fd90 - __libc_start_call_main
                               at ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16
  22:     0x7fdc7f12fe40 - __libc_start_main_impl
                               at ./csu/../csu/libc-start.c:392:3
  23:     0x562902939ed5 - <unknown>

I don't know what is causing this error, but I have managed to get the tool to run by re-defining nodata in the cost raster as 255, but leaving my 0 as valid data. However this then produces garbage output, presumably because of a frictionless surface outside of the pixels with a value of 1, which I'm rather attempting to capture as nodata both in the input and the output, and which I'd expect the CostDistance tool to both respect and handle.

I wonder if this change is relevant: https://github.com/jblindsay/whitebox-tools/issues/32#issuecomment-479698371 ? (However, changing the data type of the cost raster from Byte to Float32 reuslts in the same error being thrown.)

I've included my data (~7MB total) if you're interested in using it to reproduce the issue.

navigable-water.zip

[alpha-beta-soup]

Changing both source and cost raster data types to Float32, and using ModifyNoDataValue to change the nodata value in the cost raster from 0.0 to 8000.0 also results in the same error. So contrary to my earlier experiments, I can't actually get this tool to work at all.

Edit, after further experimentation: keeping the above, and then also unsetting nodata (with gdal_edit) results in a semi-successful run (the error is not raised, but I have insufficient RAM to complete computation). So it seems the issue is with nodata values in the cost raster, and/or the input data type, and/or a cost raster with 0 values.

[alpha-beta-soup]

The tool does run now, given the above workarounds, but now it mutates the input cost raster. There are long horizontal stripes of value 1 (pink), and where these new strips coincide with data in the input, the value is 2 (green). I don't know if this is perhaps an artifact from my choice of compression for the input data (LZW, predictor=2), or if the mutation is necessary for the algorithm, but it makes for wildly incorrect output, and it's surprising that the input cost data should be mutated at all. I can't see a pattern to these horizontal artifacts; it's not that the data is mutated so all isolated featurs are connected by a path, since there are still many isolated features.

The lines extend to the full right-hand extent of the input, but not to the left-hand side.

[katedd]

Whitebox Tools v. 2.3.0, ArcGIS Pro 3.1.2 on Windows 10 Enterprise v.22H2

I got the same error running the Unnest Basins Tool in the ArcGIS plugin. Input is a flow direction raster and a shape file of points. I tried using both the ESRI pointer scheme as True and False and I get the same results. The tool "succeeds" with a green check but does not produce any output and gives the message: thread 'main' panicked at 'called Option::unwrap() on a None value', whitebox-raster\src\lib.rs:1361:69

Full tool output message: .\whitebox_tools.exe --run="UnnestBasins" --d8_pntr='X:\projects\njwrap\Data\USGS_hydrology\FlowDirection\fdr' --pour_pts='X:\projects\njwrap\Task_2\Wetland_complexes\MyProject\c1a_pts.shp' --output='X:\projects\njwrap\Task_2\Wetland_complexes\MyProject\wbt_test_c1.tif' --esri_pntr -v --compress_rasters=False

---

• Welcome to UnnestBasins *
• Powered by WhiteboxTools *
• www.whiteboxgeo.com *

---

Reading data... thread 'main' panicked at 'called Option::unwrap() on a None value', whitebox-raster\src\lib.rs:1361:69 note: run with RUST_BACKTRACE=1 environment variable to display a backtrace Succeeded at Wednesday, October 4, 2023 8:39:18 AM (Elapsed Time: 0.92 seconds)