raster does the wrong thing here in my opinion, the right outcome is to give a grid in index-extent (0, ncol, 0, nrow) and with no projection metadata (crs). There will be coordinate arrays in this file, and they need to be handled as though they are data (with local, x*y dependent values in every cell).
With brick() you can proceed to process the data with no problem (using stopIfNotEqualSpaced = FALSE), but you can't rely on the extent being relevant, or any function that works in geographic space to do the right thing. To map a layer of these data you might try grd <- raster(yourfile, stopIfNotEqualSpaced = FALSE) coords <- brick(raster(yourfile, varname = "lon"), raster(yourfile, varname = "lat")) ## but only you will know the names of these variables values "lon", "lat" (might be "TLON", "TLAT" ? ) In quadmesh there is a way to plot in geographic space that's not impossibly slow (possibly the coords will need a re-orientation transpose ...): quadmesh::mesh_plot(grd, coords = coords) It's likely that will "map" it properly, but CMIP is likely to wrap around an odd longitude (or something), and so cropping to your area and/or choosing a good project for the crs argument to mesh_plot is probably needed. You can investigate with plot(coords[[1]]) and plot(coords[[2]]) to get a sense of their layout. In the stars package this is all internalized, with stars::read_stars(yourfile) catching all the information required as much as possible, and with plotting methods - but variable choice and actual results vary widely, and depend a lot on very specific details. (angstroms package has similar helpers for the approach but is unlikely to help here without access to the file to try) To help us guess further you can use the "ncdump" output, raster will print this with print(raster("yourfile")) and from that we could provide better guesses at variable names and subsetting etc. But, as Edzer asked, nothing is as good as having the file - any chance you can share it? (Personally I think the world rather needs more R attention on climate model output.) Cheers, Mike. On Thu, Aug 22, 2019 at 1:53 PM Frederico Faleiro <fvfale...@gmail.com> wrote: > > Dear list, > > I am using some netCDF files from the CMIP5 climate models in raster > package, but I am having some issues with one model. > The netCDF file from the GFDL-ESM2G model (e.g. > http://aims3.llnl.gov/thredds/fileServer/css03_data/cmip5/output1/NOAA-GFDL/GFDL-ESM2G/rcp45/mon/atmos/Amon/r1i1p1/v20120412/pr/pr_Amon_GFDL-ESM2G_rcp45_r1i1p1_204101-204512.nc > ) > have the error message as in bellow example. > > #Example > library(raster) > s1 <- stack("pr_Amon_GFDL-ESM2G_rcp45_r1i1p1_204101-204512.nc") > Error in .rasterObjectFromCDF(x, type = objecttype, band = band, ...) : > cells are not equally spaced; you should extract values as points > > # I check some solutions that recomend force read the file with the > argument "stopIfNotEqualSpaced = F" as bellow. > sf <- stack("pr_Amon_GFDL-ESM2G_rcp45_r1i1p1_204101-204512.nc", > *stopIfNotEqualSpaced > = F*) > bf <- brick("pr_Amon_GFDL-ESM2G_rcp45_r1i1p1_204101-204512.nc", > *stopIfNotEqualSpaced > = F*) > > I performed some tests and only "works" with brick. However I did not find > any solution to check where is the problem and fix it in the file. > > How can I check if it is really an issue and fix it? > > sessionInfo() > R version 3.5.1 (2018-07-02) > Platform: x86_64-w64-mingw32/x64 (64-bit) > Running under: Windows 10 x64 (build 18362) > > Matrix products: default > > locale: > [1] LC_COLLATE=Portuguese_Brazil.1252 LC_CTYPE=Portuguese_Brazil.1252 > [3] LC_MONETARY=Portuguese_Brazil.1252 LC_NUMERIC=C > [5] LC_TIME=Portuguese_Brazil.1252 > > attached base packages: > [1] stats graphics grDevices utils datasets methods base > > other attached packages: > [1] raster_2.8-19 sp_1.3-1 > > loaded via a namespace (and not attached): > [1] compiler_3.5.1 rgdal_1.4-3 Rcpp_1.0.1 codetools_0.2-15 > ncdf4_1.16.1 > [6] grid_3.5.1 lattice_0.20-35 > > Best regards, > > Frederico > > [[alternative HTML version deleted]] > > _______________________________________________ > R-sig-Geo mailing list > R-sig-Geo@r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-geo -- Michael Sumner Software and Database Engineer Australian Antarctic Division Hobart, Australia e-mail: mdsum...@gmail.com [[alternative HTML version deleted]] _______________________________________________ R-sig-Geo mailing list R-sig-Geo@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-geo