Edzer Pebesma
> Is there interest to evaluate the use of CFtime in stars? Absolutely!
Do you also plan to provide `as.POSIXct()` and `as.Date()` methods for `CFtime` objects? This would be needed to make `as.POSIXct.stars()` work. I think that would be needed for integrating CF...
So, replacing `PCICt` with `CFtime` will limit the functionality of `stars` because the things you can now do (e.g. convert dates from a 360 day calendar to a POSIXct date/times)...
I think that is a great idea!
```r install.packages("starsdata", repos = "http://cran.uni-muenster.de/pebesma") ``` should do it and you may need to set `options(timeout = 600)` or so.
For me it checked clean under gdal 3.9.0beta1.
Nice ;-) We also have: ```r (x1 = stars::read_ncdf(file2)) # no 'var' specified, using temperature # other available variables: # lat, lon, time # Will return stars object with 54...
But also ```r identical(as.vector(x1[[1]]), as.vector(x2[[1]][,2:1,])) # [1] TRUE ``` so that is because GDAL reverts the y axis direction; and ```r stars::read_mdim(file2, raster = c("lon", "lat")) # stars object with...
@mdsumner or @dblodgett-usgs could one of you take a look at the `.get_dims()` issue?
@dblodgett-usgs thanks! > If I add standard_name and units it still gets the axis labels wrong. If you change `latidude` into `latitude`, we get ```r > stars::read_ncdf("x.nc") no 'var' specified,...