shapeToRaster hits terra::rasterize error: "GDAL Error 1: Failed to compute min/max, no valid pixels found in sampling"

[SimonDedman]

Per this, fixed in terra dev version 1.2.8; v1.7-78 is CRAN latest so this should be solved if that really is the underlying cause?

Trying the following code, which, if successful, could be boiled into actel to simplify the spatial process for distance matrix:

install.packages("gbm.auto")
library(gbm.auto)
dir.create(file.path(loadloc, "actel", "NOAAcoastlines"))
basemap <- gbm.auto::gbm.basemap(bounds = c(min(spatial$Longitude),
                                            max(spatial$Longitude),
                                            min(spatial$Latitude),
                                            max(spatial$Latitude)),
                                 savedir = file.path(loadloc, "actel", "NOAAcoastlines"),
                                 extrabounds = TRUE)
base.raster <- actel::shapeToRaster(shape = file.path(loadloc, "actel", "NOAAcoastlines", "CroppedMap", "Crop_Map.shp"),
                                    size = 10,
                                    spatial = spatial,
                                    coord.x = "Longitude",
                                    coord.y = "Latitude",
                                    buffer = NULL)

The shapefile created by gbm.basemap opens fine in QGis.
Also potentially you could allow shapeToRaster$shape to accept R SF objects as inputs?

[SimonDedman]

This was with size=10 i.e. 10x10m pixels

M: Resulting pixel dimensions:
xmax ymax
2 2

changing to size=1 gets around the error.

xmax ymax
8 13

This sounds like 8x13 cells? If so, that seems peculiar given my areas is the whole SW coast of the US:

[SimonDedman]

raster::plot(base.raster) suggests that these units are maybe 100km?

[SimonDedman]

Ok so potentially a way to obviate this without actually fixing the underlying issue (which might not really need to be fixed) is to check & correct the documentation for shapeToRaster$size, since the user expecting metres will lead to initial values like 1000, whereas the proper value in my case was 0.01 for decent res that ran in distancesMatrix, or 0.001 for high res which crashed distancesMatrix.

[hugomflavio]

This is interesting. I think something might have been lost along the way with the demise of RGDAL and co.

The size argument works in whatever units the coordinate system works in (which is not always metres, despite what the documentation unhelpfully states). In your case, gbm.auto is obtaining the shapefile in a lat-lon format, so each unit of size is 1 degree (~110km).

The documentation needs to be updated so size has a proper description