The fcdm from sepal-contrib

export the dataset without DDR

did not pick the date

FCDM tool did not pick the date selection

add custom forest mask

use a custom assetselect to provide custom assets

module 'ee' has no attribute 'Credentials'

when downloading an image

do we cap after or before the merge ?

When you use the landsat family you have 2 different behaviours :

L1863 you cap the nbr collection for each collection if index == 'change'
L1913 here for ìndex == 'NBR'`you cap after the merge.

Any specific reason for these two different behaviors ?

when to apply the landsat_7 improvement ?

starting from L1152 the landsat 7 receive a specific patch using the improve_threshold parameter.

This improvement is not applyed when dealing with the landsat family in L1667 is it normal ?

If yes then why applying it when the selected collections are L7, L78, L57 ?

products are outdated

Landsat products to perform the analysis have been deprecated:

dataset": {"toa": "LANDSAT/LE07/C01/T1_TOA", "sr": "LANDSAT/LE07/C01/T1_SR"}
dataset": {"toa": "LANDSAT/LC08/C01/T1_TOA", "sr": "LANDSAT/LC08/C01/T1_SR"}

The module will work however if the analysis and reference period falls below the following thresholds:

{
    "landsat 4": {"toa": "1993-02-14", "sr": "1993-02-14"},
    "landsat 5": {"toa": "2011-05-24", "sr": "2011-05-24"},
    "landsat 7": {"toa": "2021-12-30", "sr": "2021-12-30"},
    "landsat 8": {"toa": "2021-12-29", "sr": "2021-12-29"},
    "sentinel 2": {"toa": "2023-07-10", "sr": "2023-07-10"},
}

Some aspects to take into account:

the new products that replace the ones that were deprecated have different band names. In addition, in the past, for landsat 7, either TOA and SR had the same band names, but in the new, their names are mixed.

this will require:

be sure that the new products can perform the same results as the previous.
update sensors.py file and for landsat 8/7 not only change the original band names but distinguish between TOA and SR products as they are different.

control the available satellite based on the end and start dates

when should I use the kernel adjustment ?

The kernel_adjustment method is used a lot in the code but I cannot really understand when it's necessary. Several configuration exists :

in the first dataset combos "LXX" with Ìndex == 'change'`(like L990) you systematically adapt the kernel for base and second nbr collections.
in the first dataset combos "LXX" with Ìndex == 'NBR'`(like L1035) you just cap the collection without kernel adaptation.

would it change anything to the end result if I adapt the kernel for everyone ? (even if there is no comparaison between 2 collections)

my objective is to optimise the writting of the functions and I try to remove as many if as I can

Is it possible to merge S2 images with the others ?

In your script the S2 data are only treated from L1934 and have a slightly different data preparation process.

Is it formally impossible to merge it with the other satellites ? (maybe by adding some normalization steps)

implement the 2 merging methods inter and intras

what should be displayed to the end user ?

In your code every second or base map is displayed (so for the landsat family option, it's 5*2 maps) but with visibility set to false.

The only one that are always displayed are the final

NBR_difference_capped
NBR_Imagecollection_second_normalized_min (yearday and NBR bands) L2049
NBR_Imagecollection_base_normalized_min (yearday and NBR bands) L2004

On javascript side, a map with visiblity to false is in fact not requested from the server. It's not the same with the geemap lib (that provide the binding beween ipyleafletand the GEE API).

How much relevant are the extra map ?
Can I decide to only display and/or download the 5 main one ?

check if DDR is ever used

from Andreas :

So, regarding the DDR filtering: I tried the same study site with different settings but got exactly the same output (and it looks not filtered).

fix the basemap selectorfor preselected forest masks

use the roadless map forest mask

check that the dates are exported

bug in cloud buffering in coastal area

transfering an email from @Andi1974:

I just wanted to let you know that I realized that using the FCDM tool in SEPAL (here I used S2 Data and a forest mask with a coastline - see screenshot from an area in Papua) leads to (wrong) cloud buffering along the coastline. I checked the same area with the same settings with FCDM-optical 2.4.1 in GEE and it did not show this effect.

Can not picking the date

I can not picking the date seletion in the FCDM

display the loading of the map in a statebar

because it's simply too long

cap give a binary map ?

I f I read the code L845 I have the feeling the the output map is a binary map -1, 0 because you multiply the result of the where by -1.

But according to the comment :
"Capping at 0 and -1 (positive values are set to 0; values <= -1 are set to -1"

Who should I trust ?

check the names in the export statements

add disclaimer and proper credits

add the date of the event in the final delta_NBR layer

why using a -500 buffer on landsat filtering ?

In the script when the masking_2 method is applied (Masking Step 2: Masking of sensor errors and non-forest areas) you sometime use a negative buffer of -500 on the image geometry (like in L947) and sometime you don't (like in L1957.

From what I understand this is a difference between landsat and sentinel sensor but can you explain me why ?

change the event date display

In the current implementation the dates are stored in the following format: YYYYMMDD as pure integer.
It's convinient to human read this information but not very convenient for display as dates will rapidly be split appart.

In BFAST and CUSUM we use instead the following :
YYYY.year_fraction which is way much easier to interpret on a QGIS map.

example:
20120613 become 2012.51

What do you think ?

sepal-contrib / fcdm Goto Github PK

fcdm's People

Contributors

Stargazers

Watchers

Forkers

fcdm's Issues

Recommend Projects

Recommend Topics

Recommend Org