whitebox installation no longer working

[bceaton]

Just tried to update on R Studio for whitebox. Not working after the update

I updated the r package

then

installed the new whitebox tools using: whitebox::install_whitebox()

Still the same error:

thread 'main' panicked at 'No such file or directory (os error 2)', whitebox-tools-app/src/main.rs:72:21
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

Error running WhiteboxTools (HypsometricallyTintedHillshade)
whitebox.exe_path: '/Users/bretteaton/Library/Application Support/org.R-project.R/R/whitebox/WBT/whitebox_tools'; File exists? TRUE
Arguments: --run=HypsometricallyTintedHillshade --dem='lidar-dem_keremeos.tif' --output='lidar-dem_keremeos_THS.tif' --altitude=45 --hs_weight=0.75 --brightness=0.5 --atmospheric=0 --palette=soft -v

System command had status 101

---

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

---

Reading data...
hypsometrically_tinted_hillshade - Elapsed Time: NA [did not run]

Also ran the wbt_init() command, and verified that the the executable was in the expected path

Any help would be appreciated.

[giswqs]

This tool might need a WBT extension license. Do you have a license?

[bceaton]

the base tools do not need a license (just the extensions), and were working fine in R prior to the update, without a licence.

[jblindsay]

I can confirm that this tool does not require a license. It's in the WbT open core.

[jblindsay]

Try running the tool in the Whitebox Runner and see if it works there with your data. If so, then we can confirm that it's an issue with the R frontend, and if not, then the issue lies in the backend. My suspicion here is that it's a frontend issue though.

[bceaton]

the whitebox_runner does not work in the folder where it was downloaded by the whitebox::install() command. It fails to open. I also downloaded a version of the WBT Open Core (just now) from https://www.whiteboxgeo.com/download-whiteboxtools/ and tried whitebox_runner from that download. It works and generated output. It does not look like the R frontend is finding the right download file?

WORK AROUND: I copied the \WBT directory that I downloaded from https://www.whiteboxgeo.com/download-whiteboxtools/ and used it to replace the \WBT directory in "~/Support/org.R-project.R/R/whitebox" directory created by the R Frontend. Now the R frontend works for me and produces output.

[brownag]

This does not appear to be related to the executable or the installation directory. I am wondering if there was a regression in file path code here. Can you try adding ./ Before the input filenames and see if your files are found? I think I may have noticed this issue myself and hadn't had a chance to check into it.

[brownag]

See updates in below comment.

[brownag]

The problem is not related to install_whitebox() but rather relative paths without a whitebox working directory set, or the wrong whitebox working directory set.

When you first install whitebox, the working directory in settings.json is "/Users/johnlindsay/Downloads/"... which probably does not exist.

Therefore you cannot use paths relative to it. You must specify "./" so the command is executed relative to the command line call (executed in R working directory).

A convenience method provided for making the WBT settings.json match up with your R session working directory is wbt_wd(".")

Consider these examples. This assumes you (at least initially) have never customized your settings.json file in the installed WBT folder.

library(whitebox)
library(terra)

wbt_verbose(TRUE)
x <- rast(sample_dem_data())
writeRaster(x, "foo.tif", o=T)

# works
wbt_slope("./foo.tif", "slope.tif")

# doesnt work
wbt_slope("foo.tif", "slope.tif")

# works
wbt_slope(normalizePath("foo.tif"), "slope.tif")

# works
wbt_wd(".") # this is shorthand for wbt_wd(getwd())
wbt_slope("foo.tif", "slope.tif")

unlink("foo.tif")

For now either use "./slope.tif", an absolute path, or set your working directory to your current directory (e.g. wbt_wd(".") to set to current R working dir) and you can use paths without the ./.

I will see if I can fix this, but you may always run into this issue if you happen to have a settings.json pointing your WBT working directory elsewhere.

[bceaton]

Ah, I see the problem now. Thanks for the examples that demonstrate how to specify the input file correctly / set the working directory. Very much appreciated!

The problem is not related to install_whitebox() but rather relative paths without a whitebox working directory set, or the wrong whitebox working directory set.

When you first install whitebox, the working directory in settings.json is "/Users/johnlindsay/Downloads/"... which probably does not exist.

Therefore you cannot use paths relative to it. You must specify "./" so the command is executed relative to the command line call (executed in R working directory).

A convenience method provided for making the WBT settings.json match up with your R session working directory is wbt_wd("")

Consider these examples. This assumes you (at least initially) have never customized your settings.json file in the installed WBT folder.

library(whitebox)
library(terra)

wbt_verbose(TRUE)
x <- rast(sample_dem_data())
writeRaster(x, "foo.tif", o=T)

# works
wbt_slope("./foo.tif", "slope.tif")

# doesnt work
wbt_slope("foo.tif", "slope.tif")

# works
wbt_slope(normalizePath("foo.tif"), "slope.tif")

# works
wbt_wd("") # this is shorthand for wbt_wd(getwd())
wbt_slope("foo.tif", "slope.tif")

unlink("foo.tif")

For now either use "./slope.tif", an absolute path, or set your working directory to your current directory (e.g. wbt_wd("") to set to current R working dir) and you can use paths without the ./.

I will see if I can fix this, but you may always run into this issue if you happen to have a settings.json pointing your WBT working directory elsewhere.

[brownag]

One option I have considered is to make it default part of wbt_init() to sync up with the R working directory. However, I have thought that this is a bit of an overstep into the user's R and/or WBT environment, as the package has never done that before. It can cause problems, as users have reported, to trigger changes to settings.json at all if privileges are limited (e.g. a system install of whitebox_tools shared by multiple users). I do not know whether such changes to force WBT to respect the R/system call working dir would break anyone's current usage...

Between wbt_wd(), or setting wd via wbt_init(), or a system environment variable... I've made a few choices available for the user to opt into managing their WBT wd. It would be nice to add some sort of magic fix for this, but I worry that I would break some other behavior by making some new rule. I have worried folks who do use setwd() function to set their working directory could possibly run into unexpected behavior if we started arbitrarily setting their WBT working directories based on the R working directory at some other time

I suppose if it was synced before every tool call, accounting for any additional settings of wd flag to the tool, this could theoretically be done, but I need to think on it a bit more

[bceaton]

I was able to reproduce your results, except for the wbt_wd(""), which I had to write explicitly as wbt_wd(getwd()).

Perhaps this is not relevant, and just a peculiarity of my system, but I thought I would pass it along in case this result is useful. I feel like a have a handle on how to proceed, and help my students who are using this package in a lab that they are doing. Thanks again for the quick response!

For me:

library(whitebox)
library(terra)

wbt_verbose(TRUE)
x <- rast(sample_dem_data())
writeRaster(x, "foo.tif", o=T)

works

wbt_slope("./foo.tif", "slope.tif")

doesnt work

wbt_slope("foo.tif", "slope.tif")

works

wbt_slope(normalizePath("foo.tif"), "slope.tif")

doesnt works

wbt_wd("") # this is shorthand for wbt_wd(getwd())
wbt_slope("foo.tif", "slope.tif")

works

wbt_wd(getwd()) # this is shorthand for wbt_wd(getwd())
wbt_slope("foo.tif", "slope.tif")

[brownag]

Sorry, I misspoke/mis-simplified my syntax, the "" is actually a special case that includes unsetting the --wd flag. I should not have said they were equivalent-- as implemented, they aren't quite so.
I will try and clean the message up from wbt_wd("") and document that behavior better.

What you can do is wbt_wd(".") as shorthand for wbt_wd(getwd())