tabrasel
commented
4 years ago From what I've picked up so far, I think that our grids are actually defined correctly. I'm pretty sure that--like you said--the issue might stem from cells being placed at their centers rather than corners. Unfortunately, the link to Andrew's grid is down right now so I can't tell yet why there's a difference between his and ours. I'll try to explain my thinking though using the NetCDF you demoed (modelName = "PNW-4km", modelRun = 2019100900):
We can find the NetCDF's origin (south-westernmost coordinate) in the original NetCDF with ncdump -h ~/Data/BlueSky/PNW-4km_2019100900.nc:
## netcdf PNW-4km_2019100900 {
## ...
## :XORIG = -128.550003051758 ;
## :YORIG = 39.75 ;
##. ...Let's convert the NetCDF, load it as a raster, and check out its extent:
> filePath <- bluesky_download(modelName = "PNW-4km", modelRun = 2019100900)
> v2Path <- bluesky_toCommonFormat(filePath, clean = FALSE)
> raster <- bluesky_load(localPath = v2Path)
> raster::extent(raster)
class : Extent
xmin : -128.57
xmax : -108.01
ymin : 39.73
ymax : 50.289997 The extent's south-westernmost coordinate (-128.57, 39.73) is different from the original NetCDF's (-128.550003051758, 39.75). It's shifted by (-0.01999694824, -0.02) which, incidentally, is about half of the raster's cell resolution (0.040000008, 0.039999987). That doesn't mean that anything is wrong with our grid placement though. Let's look at the actual coordinates of the South-westernmost cell:
> # South-westernmost cell's long/lat coordinates
> sw <- raster::cellFromRowCol(raster, raster@nrows, 1)
> raster::xyFromCell(raster, sw)
x y
[1,] -128.55 39.75The same as the original NetCDF! So conversion doesn't seem to be mutating the actual coordinates. So why was the extent of the raster off? Well, let's look at the extent of just the south-westermost cell:
> raster::extentFromCells(raster, sw)
class : Extent
xmin : -128.57
xmax : -128.53
ymin : 39.73
ymax : 39.77 The extent of a single cell is offset by the half the cell's resolution on each side. Therefore, cells are centered on their coordinates, and that's what the case is with the extent of the whole raster. It's borders surround the cell coordinates it contains with a bit of padding:
+---------------+
| * * * * |
| |
| * * * * |
| |
| * * * * |
+---------------+So unless our actual NetCDF coordinates are different from Andrew's, it seems that our raster is drawing its cells where it should be. I'm a bit confused then how Andrew's extent could contain (-128.55, 39.75) when cells are supposed to be defined at their center, not at their corner.
Today I found out that the v2 grids we are producing are slightly off in some cases. We need to review to make sure we are getting this right.
This issue will involve communication with USFS AirFire personnel which Jon can help expedite.
The final result should be an RMarkdown report describing what you learn about model grids and their raster representation.
People involved:
Model grid information we obtained from Robert is recreated in
R/AirFireModeling.Rasbluesky_modelInfo. We should check with Robert that these are correct and make sure we understand how they are interpreted -- edge of cell vs center etc.Then we should use the
ncdumpfacility to look at grid information from the models before and after we convert tov2to see if anything changes.ncdump -hof recent model outputncdump -hof older model outputbluesky_toCommonFormat()Here is the comparison of a population raster generated by Andrew Bailey using the correct grid and the grid information currently generated by AirFireModeling:
Here is a sample of how to do this work with the R "Console" and the Unix "Terminal":
Now, at the Unix terminal:
and, to see all the coordinate values:
So far it all looks good.
Reading things in with
raster::rasterBrick()gives us the suspect grid info:Why is
xminall of a sudden -128.57 instead of -128.55?