Thank you, I did a Pull Request.
Στις Πέμπτη, 28 Νοεμβρίου 2019, 01:25:38 μ.μ. EET, ο χρήστης Roger Bivand
έγραψε:
On Wed, 27 Nov 2019, Leonidas Liakos via R-sig-Geo wrote:
> Thank you for your help!
>
> I tried to fix stackApply according to your instructions.
>
> Now the indices of names are the same and consistent with indices
> enumeration (gist for validation and tests:
> https://gist.github.com/kokkytos/93f315a5ecf59c0b183f9788754bc170).
>
> I've attached a patch file here:
>
> https://gist.github.com/kokkytos/ca2c319134677b19900579665267a7a7
Thanks very much for contributing!
Please consider raising an issue on https://github.com/rspatial/raster
pointing to this thread and your patch. I had expected response from
raster developers here, but they may well be on field work, so raising an
issue on the development site should get their attention when there is
enough time for them to look. You might even fork raster, apply your patch
and file a PR in addition to the issue. In that case, a short test would
be helpful, and maybe edits to the documentation.
Roger
>
>> stackapply_mean
> class : RasterBrick
> dimensions : 300, 300, 9, 7 (nrow, ncol, ncell, nlayers)
> resolution : 500, 500 (x, y)
> extent : 0, 15, 0, 15 (xmin, xmax, ymin, ymax)
> crs : NA
> source : /tmp/Rtmp9W8UNc/raster/r_tmp_2019-11-27_191205_2929_20324.grd
> names : index_5, index_6, index_7, index_1, index_2,
> index_3, index_4
> min values : 444.6946, 440.2028, 429.6900, 442.7436, 440.0467, 444.9182,
> 437.1589
> max values : 565.8671, 560.1375, 561.7972, 556.2471, 563.8341, 561.7687,
> 560.4509
>
>> ver_mean
> class : RasterStack
> dimensions : 300, 300, 9, 7 (nrow, ncol, ncell, nlayers)
> resolution : 500, 500 (x, y)
> extent : 0, 15, 0, 15 (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
>
>
>
>
>
> On 11/26/19 10:58 PM, Vijay Lulla wrote:
>> Hmm...it appears that stackApply is using different conditions which
>> might be causing this problem. Below is the snippet of the code which
>> I think might be the problem.
>>
>> ## For canProcessInMemory
>> if (rowcalc) {
>> v <- lapply(uin, function(i) fun(x[, ind == i, drop = FALSE], na.rm
>> = na.rm))
>> }
>> else {
>> v <- lapply(uin, function(i, ...) apply(x[, ind == i, drop = FALSE],
>> 1, fun, na.rm = na.rm))
>> }
>>
>>
>> ## If canProcessInMemory is not TRUE
>> if (rowcalc) {
>> v <- lapply(uin, function(i) fun(a[, ind == uin[i], drop = FALSE],
>> na.rm = na.rm))
>> }
>> else {
>> v <- lapply(uin, function(i, ...) apply(a[, ind == uin[i], drop =
>> FALSE], 1, fun, na.rm = na.rm))
>> }
>>
>> I think they should both be same but it appears that they aren't and
>> that's what you've discovered. Maybe you can try fix(stackApply) to
>> see if it really is the problem and can tell us what you find.
>> Anyways, good catch...and...sorry for wasting your time.
>> Cordially,
>> Vijay.
>>
>> On Tue, Nov 26, 2019 at 2:53 PM Leonidas Liakos
>> mailto:leonidas_lia...@yahoo.gr>> wrote:
>>
>> Thank you!
>> The problem is not with the resulting values but with the index
>> mapping. Values are correct in all three cases.
>>
>> As I wrote in a previous post in the thread
>> (https://stat.ethz.ch/pipermail/r-sig-geo/2019-November/027821.html)
>> , stackApply behaves inconsistently depending on whether the
>> exported stack will remain in memory or it will be stored, due to
>> its large size, on the hard disk.
>>
>> In the first case the indices are identical to my function
>> (ver_mean) and the lubridate::wday indexing system (and are
>> correct) while in the second they are shuffled.
>>
>> So, while Sunday has index 1 and while in the first case (when the
>> result is in memory) stackApply returns the correct index, in the
>> second case (when the result is stored on the hard disk) it
>> returns index_4! So how can one be sure if index_1 corresponds to
>> Sunday or another day using stackApply since it sometimes
>> enumerates it with index_1 and sometimes index_4?
>>
>>
>> Try to run this example (when the resulting stack remains in
>> memory) to see that the indexes are identical (stackApply =
>> ver_median = lubridate::wday)
>> https://gist.github.com/kokkytos/5d554b5a725bb48d2189e2d1fa0e2206
>>
>> Thank you again
>>
>> On 11/26/19 9:00 PM, Vijay Lulla wrote:
>>> 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
