Skip to content

Latest commit

 

History

History
80 lines (50 loc) · 5.13 KB

example_7.md

File metadata and controls

80 lines (50 loc) · 5.13 KB

Gazing at the clouds: which dates to download RS data for?


Independentely of the temporal resolution of the chosen satellite sensor, optical remote sensing data will always be affected by atmospheric effects such as clouds. These lead to a loss of spatial and temporal information (figure 1) and, more than often, a loss of time. Search for good quality pixels forces us to download large amounts of data in order to compensate for those pesky clouds. So, how can we make this selection of remote sensing information for efficient? For this, we developed moveCloud().


Figure 1 - Variability of monthly cloud cover fraction between February 2000 and July 2017. This product was derived with MODIS data (credits: NASA's Earth Observations)


moveCloud() uses MODIS based 10km daily fractional cloud cover information provided through NASA's Earth Observations (NEO) to evaluate the cloud cover over a movement track. For each GPS point, the function extract the cloud percent cover for the corresponding acquisition date providing information on sample specific cloud cover. Additionaly, the function alows the user to define a temporal buffer which will report on the variability of the percent cloud cover. Keep in mind that due to the scale at which this product is provided there might still be some useful pixels within cloudy images. However, atmosheric effects such as clouds affect the surface at a regional scale. This means that if the cloud cover is high (e.g. > 50%) we can expect that apparantely clear pixels might be contaminated by missed clouds (figure 2) or other related effects such as haze.


Figure 2 - Example of a landsat cloud mask based on its native quality information. The image shows that while dense "puffy" clouds are captured, low altitude, shadowed and thin cloud cover is missed (credits: Hao Liang Yu)


To demonstrate the applicability of moveCloud() lets use the example data provided by the package. We will use the example data for 2013-08-04. In addition, we will read one of the example images. This will be used to define the spatial projection of the movement data.


# read raster data
r <- raster(system.file('extdata', 'tcb_1.tif', package="rsMove"))

# read movement data
moveData <- read.csv(system.file('extdata', 'konstanz_20130804.csv', package="rsMove"))
moveData <- SpatialPointsDataFrame(moveData[,1:2], moveData, proj4string=crs(r))

# define observation dates
o.dates <- as.Date(moveData@data$date)

Now lets run moveCloud(). We will use a buffer of 7 days. The function allows us to adjust the buffer size so that the user can prioritize images acquired in the past or in the future. In this example, we will use a equal sized buffer for both directions.


c.cover <- moveCloud(xy=moveData, o.time=o.dates, d.path=".", b.size=c(7,7))

The function informs us that the tracking day was fully cloud covered. Looking at the period with the temporal buffer, it also informs us on the cloud cover for the considered dates (figure 3) and on the dates with the lowest cloud cover within the 15 day window. Based on the output, we can see that the closest days before and after the observation date with a cloud cover of 0% were, respectively, 2013-08-01 and 2013-08-05. Figure 4 shows us the graphical output provided by the function which describes the temporal variability of cloud cover within this window (NOTE: to know for which of these dates rsMove can provide data for, check satTime() function).


Figure 3 - Table output of moveCloud() showing the cloud cover for the sample observation date (day.cover) and the date in the past (p.date.before) and in the future (p.date.after) with the lowest cloud cover for the specified temporal window (p.cove.before and p.cover.after).


Figure 4 - Temporal variability of percent cloud cover within a 7 day buffer of the GPS tracking date


Click here to get back to rsMove.