-
Notifications
You must be signed in to change notification settings - Fork 88
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
terra::predict() fails with NAs in input, and multiple returns #998
Comments
Thank you. What happens it that terra needs to find out the shape of the output data. It does that with a sample. In an extreme case like this, the sample will only have NAs and then with na.rm=TRUE there is nothing to test with. random numbers are now used in that case. That will probably work for most models. You should have been able to use The below works now:
|
Thanks for the quick fix! |
I'm hitting this issue (or similar) again with some odd shaped data in my predict pipeline. There are quite a few layers in the raster here, and I couldn't quite pin down exactly what is strange about this raster to produce a synthetic reprex so I just supplied the data as is. Hopefully it's not impossible for you to track down what's going on here. Thank you! library(terra)
#> Warning: package 'terra' was built under R version 4.1.3
#> terra 1.7.6
x <- tempfile()
download.file('https://github.com/rspatial/terra/files/10580924/reprex.zip', x)
x <- unzip(x)
x <- rast(x)
as.data.frame(x) |> na.omit() |> nrow()
#> [1] 4680
p_fun <- function(object, newdata, ...) {
return(data.frame(x = rep(1, nrow(newdata)), y = rep(0, nrow(newdata))))
}
terra::predict(x, list(), fun = p_fun, na.rm = TRUE)
#> Error: [predict] the number of values returned by the predict function does not match the input. Created on 2023-02-03 with reprex v2.0.2 |
Thanks very much for reporting that and your patience. This happened because the check for NA values was did not consider variation between layers. In this case the ecozones layer has many NAs where other layers do not. Fixed now.
With this example you could of course have used |
Awesome, thank you! Yes, I'm using a few models but I think the |
That is correct. "ranger" has a major design flaw. Instead of |
Here's another example (I promise I'm not trying to find these!) where most layers in the raster stack are fully populated but a few are very sparse. Thanks so much for sorting all of this out – it makes my life much much easier when terra handles library(terra)
#> Warning: package 'terra' was built under R version 4.1.3
#> terra 1.7.6
x <- tempfile()
download.file('https://github.com/rspatial/terra/files/10608770/reprex_2.zip',
x)
x <- unzip(x)
x <- rast(x)
as.data.frame(x) |> na.omit() |> nrow()
#> [1] 155
terra::ncell(x)
#> [1] 111222
p_fun_bad <- function(object, newdata, ...) {
return(data.frame(x = rep(1, nrow(newdata)), y = rep(0, nrow(newdata))))
}
p_fun_good <- function(object, newdata, ...) {
return(data.frame(x = rep(1, nrow(newdata))))
}
terra::predict(x, list(), fun = p_fun_good, na.rm = TRUE)
#> class : SpatRaster
#> dimensions : 333, 334, 1 (nrow, ncol, nlyr)
#> resolution : 30, 30 (x, y)
#> extent : 1866945, 1876965, 2217285, 2227275 (xmin, xmax, ymin, ymax)
#> coord. ref. : +proj=aea +lat_0=23 +lon_0=-96 +lat_1=29.5 +lat_2=45.5 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs
#> source(s) : memory
#> name : lyr1
#> min value : 1
#> max value : 1
terra::predict(x, list(), fun = p_fun_bad, na.rm = FALSE)
#> class : SpatRaster
#> dimensions : 333, 334, 2 (nrow, ncol, nlyr)
#> resolution : 30, 30 (x, y)
#> extent : 1866945, 1876965, 2217285, 2227275 (xmin, xmax, ymin, ymax)
#> coord. ref. : +proj=aea +lat_0=23 +lon_0=-96 +lat_1=29.5 +lat_2=45.5 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs
#> source(s) : memory
#> names : x, y
#> min values : 1, 0
#> max values : 1, 0
terra::predict(x, list(), fun = p_fun_bad, na.rm = TRUE)
#> Error in m[i, ] <- r: number of items to replace is not a multiple of replacement length Created on 2023-02-04 with reprex v2.0.2 |
Thanks, fixed now. This was the corner case of having just one cell without NAs in the test data. |
As always, thanks for such a great tool. I use it almost every day.
This is pretty odd, and seems to be related to
NA
s in the input data and a predict function that would result in multiple output bands.Created on 2023-02-02 with reprex v2.0.2
The text was updated successfully, but these errors were encountered: