You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
The text was updated successfully, but these errors were encountered: