Edzer Pebesma
Thanks! The `st_agr()` problem is gone; how can I reproduce the `key.width too small` problem?
`key.width` is next.
- [x] gtfstools - [x] h3jsr - [x] sfdct - [x] osmextract - [x] spqdep - [x] CSHShydRology - [x] starsExtra - [x] MapGAM - [x] nngeo - [x] transfR.
Not unlikely that this is related to #2131
Thanks! > "covers the whole planet" crosses the antemeridian.
> Maybe, but that does not really prove it, as the sf function directly uses the GDAL tool ([gdalbuildvrt](https://gdal.org/programs/gdalbuildvrt.html)) whereas terra calls the C interface [GDALBuildVRT](https://gdal.org/api/gdal_utils.html#_CPPv412GDALBuildVRTPKciP12GDALDatasetHPPCKcPK19GDALBuildVRTOptionsPi). No, see https://github.com/r-spatial/sf/blob/main/src/gdal_utils.cpp#L345
Do you also see the problems with the `sf` approach after setting `sf_proj_network(TRUE)` ?
I get ```r > stars::read_stars(paste0("/vsicurl/", url)) area, lat_bnds, lon_bnds, msk_rgn, pr, tas, time_bnds, ua, stars object with 2 dimensions and 2 attributes attribute(s): Min. 1st Qu. Median Mean 3rd Qu....
These are messages emitted by the GDAL library, a component `sf` and `terra` share; it looks like `terra` suppresses such messages, where `sf` emits them. Loading `sf` before `terra` lets...
This also triggers the warnings, without `sf`: ```r library(terra) gdal(warn = 1) a