Stitching time series from neighbouring scenes

[bendv]

...just opening this issue to brainstorm a bit about the most effective way to combine raster time series from neighbouring scenes.

For example, if your AOI spans 4 different scenes, there should be a convenient way to store the pre-processed time series for that AOI in one object (RasterBrick or otherwise).

A single brick is possible, but is complicated by the fact that acquisition dates will differ (maybe only slightly) between scenes. I can think of a number of options:

1. a custom grid-based object where each cell has a pixel value and a date associated with it. This seems convenient, but would take up more storage space (to accommodate the date info per grid cell).
2. a extended RasterBrick, where NA's are assigned to cells from neighbouring scenes with no data acquired at that particular date. This seems a bit clumsy to me, but would work...
3. keep them as separate bricks and process them independently of each other. But then, how would we handle overlapping cells?

In cases where the scenes are combined (option 1 or 2), overlapping cells can easily be incorporated by simply 'densifying' the time series at those locations. In some cases, the pixel values will have been acquired on the same date, in which case either a summary value (mean) is used, or preference is given to one of the overlapping values.

Ideas?

[loicdtx]

For small extents option two is the way to go. If working on 4 entire scenes option 1 seems more appropriate. The challenge is in the re-projection. And I'm also not sure to what extent overlapping pixels belonging to two different scenes are similar geometrically after reprojection and therefore whether they can be compared with confidence...

[bendv]

For large area mapping applications this is indeed an issue, but I'm also not sure how important it is if only 2-4 neighbouring scenes are involved.

See methods of Potapov et al. (2012). Quantifying forest cover loss in Democratic Republic of the Congo, 2000–2010, with Landsat ETM+ data. Remote Sensing of Environment, 122, 106–116. --> images were mapped to a pre-defined pixel grid.

[loicdtx]

OKay, that's a bit complex. The potential illumination and geometric artifacts need to be tested, as well as the feasibility of warping so much data.

[GreatEmerald]

This would indeed be useful. In some cases (like mine) the area of interest is on the boundary between two tiles, so making use of the information from both is quite important. If the date is the same, selecting the best pixel (max VI) makes the most sense.

I'm thinking that option 3 isn't that bad; trying to combine a lot of data into one leads to scalability issues real fast. You can still densify the time series (as long as the projections match) at the time of processing.

[loicdtx]

The way data can be ordered via espa partly addresses this issue. If you order a tile (extent) that spans multiple scenes you end up with the scenario described in option 2 without any additional processing required. It's impossible to have twice the same date on the path overlap, and when you do on the row overlap it's actually the same observation, so you may chose either. Ingesting the data into a sparse array database (scidb, rasdaman, AGDC) is probably the way to go when working on very large areas spanning multiple scenes. But that's a very different story...