Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HLS crazy suggestion #506

Open
bhbraswell opened this issue Apr 9, 2019 · 1 comment
Open

HLS crazy suggestion #506

bhbraswell opened this issue Apr 9, 2019 · 1 comment

Comments

@bhbraswell
Copy link

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
Copy link
Collaborator

ircwaves commented Apr 9, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants