raster: stackApply problems..
Why do they seem logical since they do not match? Check for example index 1 (Sunday). The results are different for the three processes
stackapply_mean
class????? : RasterBrick dimensions : 300, 300, 90000, 7? (nrow, ncol, ncell, nlayers) resolution : 500, 500? (x, y) extent???? : 0, 150000, 0, 150000? (xmin, xmax, ymin, ymax) crs??????? : NA source???? : /tmp/RtmpkRMXLb/raster/r_tmp_2019-11-26_191359_7710_20324.grd names????? :? index_5,? index_6,? index_7,? index_1,? index_2,? index_3,? index_4 min values : 440.0467, 444.9182, 437.1589, 444.6946, 440.2028, 429.6900, 442.7436 max values : 563.8341, 561.7687, 560.4509, 565.8671, 560.1375, 561.7972, 556.2471
ver_mean
class????? : RasterStack dimensions : 300, 300, 90000, 7? (nrow, ncol, ncell, nlayers) resolution : 500, 500? (x, y) extent???? : 0, 150000, 0, 150000? (xmin, xmax, ymin, ymax) crs??????? : NA names????? :? layer.1,? layer.2,? layer.3,? layer.4,? layer.5,? layer.6,? layer.7 min values : 442.7436, 440.0467, 444.9182, 437.1589, 444.6946, 440.2028, 429.6900 max values : 556.2471, 563.8341, 561.7687, 560.4509, 565.8671, 560.1375, 561.7972
z
class????? : RasterBrick dimensions : 300, 300, 90000, 7? (nrow, ncol, ncell, nlayers) resolution : 500, 500? (x, y) extent???? : 0, 150000, 0, 150000? (xmin, xmax, ymin, ymax) crs??????? : NA source???? : /tmp/RtmpkRMXLb/raster/r_tmp_2019-11-26_191439_7710_04780.grd names????? :?????? X1,?????? X2,?????? X3,?????? X4,?????? X5,?????? X6,?????? X7 min values : 440.0467, 444.9182, 437.1589, 444.6946, 440.2028, 429.6900, 442.7436 max values : 563.8341, 561.7687, 560.4509, 565.8671, 560.1375, 561.7972, 556.2471 ?????????? : 1, 2, 3, 4, 5, 6, 7
On 11/26/19 7:03 PM, Vijay Lulla wrote:
If you read the code/help for `stackApply` and `zApply` you'll see
that the results that you obtain make sense (at least they seem
sensible/reasonable to me).? IMO, if you want to control the ordering
of your layers then just use sapply, like how you've used for
ver_mean.? IMO, this is the only reliable (safe?), and quite a
readable, way to accomplish what you're trying to do.
Just my 2 cents.
-- Vijay.
On Tue, Nov 26, 2019 at 11:19 AM Leonidas Liakos via R-sig-Geo
<r-sig-geo at r-project.org <mailto:r-sig-geo at r-project.org>> wrote:
I added raster::zApply in my tests to validate the results.
However, the
indices of the names of the results are different now. Recall that the
goal is to calculate from a raster stack time series the mean per
day of
the week. And that problem I have is that stackApply, zApply and
calc/sapply return different indices in the result names. New code is
available here:
https://gist.github.com/kokkytos/93f315a5ecf59c0b183f9788754bc170
I'm really curious about missing something.
On 11/20/19 3:30 AM, Frederico Faleiro wrote:
> Hi Leonidas,
>
> both results are in the same order, but the name is different.
> You can rename the first as in the second:
> names(res) <- names(res2)
>
> I provided an example to help you understand the logic.
>
> library(raster)
> beginCluster(2)
> r <- raster()
> values(r) <- 1
> # simple sequential stack from 1 to 6 in all cells
> s <- stack(r, r*2, r*3, r*4, r*5, r*6)
> s
> res <- clusterR(s, stackApply, args =
list(indices=c(2,2,3,3,1,1), fun
> = mean))
> res
> res2 <- stackApply(s, c(2,2,3,3,1,1), mean)
> res2
> dif <- res - res2
> # exatly the same order because the difference?is zero for all
layers
> dif
> # rename
> names(res) <- names(res2)
>
> Best regards,
>
> Frederico Faleiro
>
> On Tue, Nov 19, 2019 at 4:15 PM Leonidas Liakos via R-sig-Geo
> <r-sig-geo at r-project.org <mailto:r-sig-geo at r-project.org>
<mailto:r-sig-geo at r-project.org <mailto:r-sig-geo at r-project.org>>>
wrote:
>
>? ? ?I run the example with clusterR:
>
>? ? ?no_cores <- parallel::detectCores() -1
>? ? ?raster::beginCluster(no_cores)
>? ? ??????? res <- raster::clusterR(inp, raster::stackApply, args =
>? ? ?list(indices=c(2,2,3,3,1,1),fun = mean))
>? ? ?raster::endCluster()
>
>? ? ?And the result is:
>
>? ? ?> res
>? ? ?class?????????? : RasterBrick
>? ? ?dimensions : 180, 360, 64800, 3?? (nrow, ncol, ncell, nlayers)
>? ? ?resolution : 1, 1?? (x, y)
>? ? ?extent???????? : -180, 180, -90, 90?? (xmin, xmax, ymin, ymax)
>? ? ?crs?????????????? : +proj=longlat +datum=WGS84 +ellps=WGS84
>? ? ?+towgs84=0,0,0
>? ? ?source???????? : memory
>? ? ?names?????????? : layer.1, layer.2, layer.3
>? ? ?min values :???????? 1.5,???????? 3.5,???????? 5.5
>? ? ?max values :???????? 1.5,???????? 3.5,???????? 5.5??
>
>
>? ? ?layer.1, layer.2, layer.3 (?)
>
>? ? ?So what corrensponds to what?
>
>
>? ? ?If I run:
>
>? ? ?res2 <- stackApply(inp,c(2,2,3,3,1,1),mean)
>
>? ? ?The result is:
>
>? ? ?> res2
>? ? ?class? ? ? : RasterBrick
>? ? ?dimensions : 180, 360, 64800, 3? (nrow, ncol, ncell, nlayers)
>? ? ?resolution : 1, 1? (x, y)
>? ? ?extent? ? ?: -180, 180, -90, 90? (xmin, xmax, ymin, ymax)
>? ? ?crs? ? ? ? : +proj=longlat +datum=WGS84 +ellps=WGS84
+towgs84=0,0,0
>? ? ?source? ? ?: memory
>? ? ?names? ? ? : index_2, index_3, index_1
>? ? ?min values :? ? ?1.5,? ? ?3.5,? ? ?5.5
>? ? ?max values :? ? ?1.5,? ? ?3.5,? ? ?5.5
>
>? ? ?There is no consistency with the names of the output and obscure
>? ? ?correspondence with the indices in the case of clusterR
>
>
>? ? ?? ? ? ? [[alternative HTML version deleted]]
>
>? ? ?_______________________________________________
>? ? ?R-sig-Geo mailing list
>? ? ?R-sig-Geo at r-project.org <mailto:R-sig-Geo at r-project.org>
<mailto:R-sig-Geo at r-project.org <mailto:R-sig-Geo at r-project.org>>
? ? ? ? [[alternative HTML version deleted]]
_______________________________________________
R-sig-Geo mailing list
R-sig-Geo at r-project.org <mailto:R-sig-Geo at r-project.org>
https://stat.ethz.ch/mailman/listinfo/r-sig-geo