raster2world very slow

[SarahBauduin]

This function is slow

r1 <- raster(extent(c(0, 20000, 0, 20000)), nrows = 100, ncols = 100)
res(r1) <- 200
r1[]<-runif(100)
r_land <- raster2world(r1, method = "ngb")

Why not use something like r_land <- createWorld(1, r1@ncols, 1, r1@nrows, data = r1[]) inside the function raster2world() instead of using the function resample() (which is the slow part I guess)

[eliotmcintire]

Seems like that would be fine. I don't recall if there was a good reason for resample() or it was just a decent solution.

[SarahBauduin]

I did a few tests and the proposed solution doesn't work when the resolution is not equal to 1. Maybe we can find another way to do the resample without using the function resample() which is slow.

[eliotmcintire]

Put in a test for resolution equals 1,if yes, use fast, if no use resample.

On Mon, Apr 8, 2019, 2:58 AM Sarah Bauduin notifications@github.com wrote:

I did a few tests and the proposed solution doesn't work when the resolution is not equal to 1. Maybe we can find another way to do the resample without using the function resample() which is slow.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/PredictiveEcology/NetLogoR/issues/38#issuecomment-480766523, or mute the thread https://github.com/notifications/unsubscribe-auth/ABDK2wg8StTGILtupaDOPg_42V7fxx2gks5vexKxgaJpZM4cZ1oX .

[achubaty]

any update on this?

[SarahBauduin]

Hi Alex, I didn't have time to work on this and I won't have time in the near future. As a few people contacting me because NetLogoR is not available and there is the workshop I'll give on IBM and NetLogoR in two weeks, I would say to submit the package like this. I'll try to work on something (if I can) during the summer. Thanks!

Sarah

---

De : Alex Chubaty @.> Envoyé : jeudi 10 juin 2021 20:41 À : PredictiveEcology/NetLogoR @.> Cc : Sarah Bauduin @.>; Author @.> Objet : Re: [PredictiveEcology/NetLogoR] raster2world very slow (#38)

any update on this?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/PredictiveEcology/NetLogoR/issues/38#issuecomment-858894842, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABRXE5MPEWS2FQRD73AQWSDTSEBOTANCNFSM4HDHLILQ.

[achubaty]

sounds good, i'll submit today

[eliotmcintire]

@SarahBauduin Revisiting this... In you example above, what is the world that you want, a 1m resolution world or a 200m resolution world? Recall, "world" doesn't have a resolution: it is always 1. So, my suspicion is that you want a world of 100 x 100 pixels, not this:

Browse[1]> worldRaster
class      : RasterLayer 
dimensions : 20001, 20001, 400040001  (nrow, ncol, ncell)
resolution : 1, 1  (x, y)

which is what this function is creating ... i.e., 20001 x 20001 pixels with 1m each...

Please confirm that you want a 101 x 101 pixel world and not a 20001 x 200001 pixel world

[eliotmcintire]

I believe this function was actually incorrect before, for rasters that were not res(raster) = c(1,1). Worlds have a 1 unit resolution always. What is not specified is the "units" of that 1x1. NetLogo, I believe, did not start with a "real planet Earth" world, so 1 unit could be "100m" or "5km" or whatever. In the example provided at the top of this issue, the resolution is 200m. The correct output of the raster2world is a 101 x 101 resolution world, which has a 1 unit resolution, but where each unit is 200m. This is a weird situation imposed by the fact that worlds always have 1 unit resolution. The incorrect output is a 1m resolution 400 million pixel world. That is both computationally prohibitive and an incorrect use of the information contained in the original 200m x 200m raster. If a user wants a 400 million pixel world, they can make a 400 million pixel raster.

[SarahBauduin]

Yes, in my example the point was to obtain a 100 100 pixel (i.e., patch) world (not a 101 101). The aim was to match the nrow and ncols of the raster, whatever the real unit is (it ends up to be 1 for the world). I don't understand why it produced a 20001 x 200001 pixel world ... Thanks for fixing it. I'll look at that and add some tests to be sure

[SarahBauduin]

It's confusing to convert a raster into a worldMatrix because, usually, in a raster, round coordinate values represent the edges of the raster cell, whereas for the worldMatrix, round coordintate values represent the patch center. I made this test and I think the function should create a worldMatrix with the same nrows, ncols and values as in the original raster

[eliotmcintire]

I thought that we had always resulted in 1 extra row and column for the "worldMatrix/worldArray" because the coordinates are "center" of pixel. If we pick the "same" number of rows and columns, then the whole thing will be shifted.

We are using the ngb ("nearest neighbour") to assign the values 1/2 a pixel away. If it matters where the pixels are in the real world (which is likely the case when we have rasters as a source of information --> and which we then want to change to worldMatrix), then we can't just "shift" the values.

Though, now that I walk through this sequence, using "ngb" actually does not interpolate, it just "shifts" the values. Maybe the correct thing to do is keep the number of rows/cols the same (as you suggest here). When we revert back to raster, e.g., with world2raster, then we just do the inverse operation to get it back to the real world.

@SarahBauduin what do you think? I am pretty sure we had been adding a col and row historically.

[SarahBauduin]

You're right, we did add a col and a row to the worldMatrix. In the Details of the function, it is written : "The raster is resampled to match the coordinates system and resolution of a worldMatrix or worldArray using the chosen method. The extent will be bigger by 1 on the width and on the height.". The idea was to add 1/2 cell on all borders of the raster to create a new grid cell with the round values at the center of the patches (instead of the edges as in the raster). Then, we assign values to the patches using the ngb or bilinear method. But I had the same thoughts as you when I created the test 2 days ago, because the actual coordinate values do not really matter in a worldMatrix, why do we add a new col and row and then reassign new values ? Can't we just take the grid as it is (nrow, ncol and values) from the raster, "shift" it of a 1/2 cell and "shift it" back of a 1/2 cell in the revert function. However, I wonder how this will work when raster cells aren't square or when the "bilinear" method is chosen. I think both thinking are correct, we just need to pick one.

[eliotmcintire]

I think we "pick" the one where we have the same number of pixels... so we do a "shift". This is essentially the same as "ngb", but without the need to create one column and one row of identical data to what is already there. If we were doing "bilinear", then it would be different, but I still think we should not be creating/modifying the input data. We just change the labels on the xcoord and ycoord, rather than do some unnecessary GIS.

We will have to change the documentation and say that this is what we are doing... of course.

[SarahBauduin]

Ok, I agree. I wonder why I made it so complicated back then ... I hope there wasn't a reason for it which I can't remember :) I updated raster2world() and the test. I didn't change world2raster() and so the raster returned has the same coordinate system as the worldMatrix (i.e., round coordinate values at the center of the cells). Do we change that ? However, we won't know the original extent and resolution of the raster so I don't know if it's worth to modify this function. My actual though is : is the function world2raster() relevant ?

[eliotmcintire]

Making a new issue...