Applied-GeoSolutions / gips

Geospatial Image Processing System
GNU General Public License v3.0
17 stars 5 forks source link

HLS crazy suggestion #506

Open bhbraswell opened 5 years ago

bhbraswell commented 5 years ago

I think that the HLS output which currently distinguishes between S30 and L30 should actually not do that. Unless I'm spacing some basic GIPS principle, files with different asset types will not be mosaicked together. However, they are almost never both available on the same day, and in the rare cases that they are, the differences are extremely small (meaning that the HLS algorithm is actually working). So I propose that S30 and L30 should actually be treated as practically the same thing, or that there should be an option to do so.

ircwaves commented 5 years ago

Let

L = {TILE}_{YYYYDDD}_L30_ndvi.tif
S = {TILE}_{YYYYDDD}_S30_ndvi.tif

be ndvi produced from spatio-(almost)temporally coincident HLS scenes.

It can be the case that

overlap_frac = sum( valid_data_mask(L) & valid_data_mask(S)) / (rows * columns)

is any value in [0, 1], with some likelihoods.

So, one could build in some mosaicking precedence to create a single LS sensor/asset flavor that depends on both L30 and/or S30, but that was out of scope for our first cut. Questions that start to pop up are about how to intertwine masking and mosaicking. For example, given that they are almost temporally coincident, the clouds from one will likely have moved for the other sensor.

Anyway, totally doable, but interested in your thoughts on scoping this out further.