test mukey.wcs against local calls to crop() on mukey grid #307
Comments
|
Initial tests suggest that the two methods give ever so slightly different grid topology, but identical values. |
|
@dylanbeaudette can you speak to what the internal extent of the whole grid stored in the WCS is? Basically I want to know if the entire WCS source is shifted, or if is this just a result of how cropping works? It seems odd to me that the WCS would return a result that doesn't conform to whatever the internal grid is... which suggests to me that the topology may not actually be identical to the original TIFF files. I think this may be fixable on the R side if we decide on the authoritative grid topology for each whole source. Since we already store a variety of metadata about each layer, it should be trivial to add a few more elements. In addition to native CRS and resolution we need a number of rows/columns and extent--with that we can re-align any grid with As far as the dimension differences, I think that in general we can't expect If we force alignment of the grid, nodata would be properly filled in for the case of a smaller grid projected to the larger dimensions. So, while the individual result dimensions will sometimes differ from WCS v.s. {terra}, the data and grid topology can be made to be identical to the source and each other. I imagine that conforming is less of an issue for ISSR800... but probably there should be an authoritative grid for everything, even if it is not an "official" product. Will open a PR to demo for the CONUS mukey sources, then will need to get the same info for Hawaii, Puerto Rico, etc. |
|
@dylanbeaudette Can you post the extent and number of rows/columns for rasters you uploaded to SoilWeb for Hawaii, Puerto Rico, and EDIT: got ISSR800 from soil properties download page GeoTIFFs x <- terra::rast("https://soilmap2-1.lawr.ucdavis.edu/800m_grids/rasters/caco3_kg_sq_m.tif")
x
#> class : SpatRaster
#> dimensions : 3621, 5770, 1 (nrow, ncol, nlyr)
#> resolution : 800, 800 (x, y)
#> extent : -2357200, 2258800, 276400, 3173200 (xmin, xmax, ymin, ymax)
#> coord. ref. : NAD83 / Conus Albers (EPSG:5070)
#> source : caco3_kg_sq_m.tif
#> name : caco3_kg_sq_m |
|
As far as I can tell, the gNATSGO and gSSURGO mukey grids have not been modified relative to the source on Box. Local files as downloaded from Box: Files on SoilWeb, and output from gdalinfo. gNATSGO: gSSURGO: |
|
Note that the HI and PR grids use their own, local CRS. HI: PR: |
OK. Well, then it seems WCS result/cropping appears to not respect the source grid. I think this approach to align to an authoritative reference makes sense, so we should implement it for the remaining sources outside CONUS. |
|
I suspect that the WCS is performing some alignment / cropping outside of our control, possibly a precision issue. I'll look into it some more this week. Related, but not yet a fix or alternative. As I continue to move content over to the new SoilWeb servers, I'll convert all TIFFs to COG and we can test parallel access: WCS and vsicurl. I don't know if this is efficient, but seems to work as expected: u <- '/vsicurl/https://soilmap2-1.lawr.ucdavis.edu/wcs-files/gSSURGO-mukey.tif'
x <- rast(u)
bb <- 'POLYGON((-118.6609 36.4820,-118.6609 36.5972,-118.3979 36.5972,-118.3979 36.4820,-118.6609 36.4820))'
a <- vect(wkt, crs = 'epsg:4326')
a <- project(a, 'epsg:5070')
z <- crop(x, a)
z <- as.factor(z)
plot(z)
lines(a)This appears to return data perfectly aligned with the source data, and closely follows the first example in the WCS tutorial. There are many features of the WCS that I prefer, especially limits on maximum result sizes, arbitrary resolution, etc.. The COG approach is cleaner, and I don't know if it can scale as efficiently as the WCS. Either way, having wrapper functions in soilDB seems like a good idea. |
Sure... IMO the cloud-optimized geotiff is far superior to all the stuff we are doing to make WCS work... but I guess I assumed the reason we didn't do COG from the beginning is because once it is out in the wild, possibly with a wrapper function, people are going to hammer it with requests. I have used COG for very large areas at fine resolution and I would guess it is at least as efficient as WCS in terms of time to download an area of interest. But I am not sure that is something you wanted the SoilWeb servers to be handling. |
|
Agreed on all points. |
|
OK, I can confirm that HI and PR (custom) SSURGO grids were accidentally created with non-integer extent. These were based on a BBOX around MLRA for those areas. I'll re-make those grids using integer extent, and push to WCS. updated grid systems. HI PR |
|
OK, new HI and PR grids created, and pushed to the WCS servers. Here are the source grid specs: HI PR |
No description provided.
The text was updated successfully, but these errors were encountered: