1

Let's assume I have a raster representing the speed of movement in Km/h, and the raster cell size is, say, 500m. Am I correct in understanding that, in order for me to calculate the time it takes to cross one cell, I can use the following formula: t=space/speed? In this case, the time would be 500 divided by the speed in Km/h. While I believe that that is generally correct, what I cannot wrap my head around is if one has to account for cell size, e.g. multiplying (or dividing) the resulting figure by the cell size of the raster. I mean, space/speed in Km/H gives the time to cross 1km. But, since my raster cell size is 500m (i.e., less than a Km, actually half), is another step needed to account for the difference?

  • If your pixel size is 500m x 500m, the direction of travel adds a trigonometric component to the distance, up to sqrt (2)*500m, which will increase the time necessary to cross the pixel proportionately. – Vince Mar 17 '17 at 11:38
  • @Vince: Maybe. It depends on how what rules surround movement and what level of abstraction you are looking for in your answer. For example, stream modeling is done using a raster, although streams can and do move diagonally across raster cells, this is ignored when calculating the length of the stream. Its an assumption of the model that streams can only move in the cardinal directions. – SeldomSeenSlim Mar 17 '17 at 14:05
1

This depends on the rules you have for movement across your raster. Can one only move from adjacent cell to adjacent cell. Can one move in a non-cardinal manner between cells?

Following on what might be a simple case:

library(raster)

speed.rast<-raster(ncol=10, nrow=10, xmn=0, xmx=5000, ymn=0, ymx=5000)

speed.rast[]<-replicate(10,as.integer(runif(1:10)*15+1))

speed.rast

class       : RasterLayer 
dimensions  : 10, 10, 100  (nrow, ncol, ncell)
resolution  : 500, 500  (x, y)
extent      : 0, 5000, 0, 5000  (xmin, xmax, ymin, ymax)
coord. ref. : NA 
data source : in memory
names       : layer 
values      : 1, 15  (min, max)

Ok so we've got a raster to work with. Lets calculate the time it takes to cross the raster in the horizontal.

In a 10 cell raster that implies that the total distance across our raster is 5000m, 5km. The "speed" of a cell is going to be inversely proportional to the time it take to cross it. Makes sense right? The faster we go the more quickly we cross a cell

t= 1/Speed

Now we account for the size of a cell

t= ( 1/Speed )* distance

So lets say we want to cross 1 cell which has a speed of 1 km/hr

t= (1/1kmhr)*0.5km

Units cancel

t= 0.5hr

Ok. Sanity check complete. It takes us 0.5hr to cross a 500m cell at 1km/hr. A bit more sanity before we go too far..

speed.rast[1,1]
3

Cell 1,1 of our raster is speed 3.

(1/speed.rast[1,1])*5
0.1666667

So it should take us .17 hours to cross a 500m cell of speed 3. For a whole row:

(1/speed.rast[1,])*.5
[1] 0.16666667 0.04545455 0.06250000 0.07142857 0.04545455 0.04545455    0.03333333 0.03571429 0.10000000 0.07142857

sum((1/speed.rast[1,])*.5)
0.6774351

These results seem reasonable. Sum the inverse of the speed for a cell and multiply it by the resolution of the cell for the time it takes to cross a given cell. Sum this value over then cells crossed to get your travel time.

This works fine for simple travel over straight lines in cardinal directions. Let me know if this answers your question. I have a solution for the more complicated case of non-straight lines in many directions, but I want to see what you can come up with first.

  • Thank you for the detailed and informative response. That has clarified my doubts, which were centred on the fact that we have indeed to multiply the inverse of the speed by the cell resolution. Importantly, the latter has to be expressed as fraction of the distance unit used to express the speed (in this case, Km). Thanks – NewAtGis Mar 25 '17 at 11:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.