[R-sig-Geo] raster: stackApply problems..

Tue Nov 26 20:00:24 CET 2019

I'm sorry for the miscommunication.  What I meant to say is that the output
from stackApply and zApply are the same (because zApply uses stackApply
internally) except the names.  The behavior of stackApply makes sense
because AFAIUI R doesn't automatically reorder vectors/indices that it
receives.  Your observation about inconsistent result with ver_mean is very
valid though!  And, that's what I meant with my comment that using sapply
with the explicit ordering that you want is the best way to control what
raster package will output.  In R the input order should be maintained
(this is the prime difference between SQL and R) but packages/tools do not
always adhere to this...so it's never clear how the output will be
ordered.  Sorry for the confusion.

On Tue, Nov 26, 2019 at 12:22 PM Leonidas Liakos <leonidas_liakos using yahoo.gr>
wrote:

> 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 using 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 using r-project.org <mailto:r-sig-geo using 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 using r-project.org <mailto:R-sig-Geo using r-project.org>
>> >     https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>> >
>>
>>         [[alternative HTML version deleted]]
>>
>> _______________________________________________
>> R-sig-Geo mailing list
>> R-sig-Geo using r-project.org
>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>
>
>
>

	[[alternative HTML version deleted]]