Sentinel2.mask_clouds_and_shadows add optional argument fill value

[orianif]

It would be great if the method Sentinel2.mask_clouds_and_shadows would have an optional argument to specify the filling value, which for now is 0 by default. In case raw pixel values are extracted and treated programmatically one may want to label missing values differently (e.g. as nans).

Best,
Fabio

[orianif]

Hi Lukas, what about a datatype check on the user entry? Fabio Oriani Researcher - Agroscope, Mountain Grassland Team Earth Observation for Agroecosystems (EOA) Team https://www.eoa-team.nethttps://www.eoa-team.net/profile/FabioOriani/ Associate Editor - Computers & Geosciences https://www.journals.elsevier.com/computers-and-geosciences/ Inviato da Proton Mail mobile

…

-------- Messaggio originale -------- Il 5 mag 2023, 20:14, Lukas Valentin Graf ha scritto:

Hi ***@***.***(https://github.com/orianif) this is a great idea. The only challenge that I see here is the data type issue. E.g., 'nan' requires floating points but many remote sensing data sources use integers. So the question is, would should happen if a user fills in a "wrong" fill value in terms of data type? Casting data might be not efficient/ desired. Any suggestions? Cheers, Lukas — Reply to this email directly, [view it on GitHub](#54 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AISYTSCSV472OOIONBJV4TDXEU7QFANCNFSM6AAAAAAXUGS3QQ). You are receiving this because you were mentioned.Message ID: ***@***.***>

[lukasValentin]

Hi @orianif

thanks for the suggestions. While I think we can discuss about fill values, I have two comments:

First: The mask method actually should not alter data values. It uses np.ma.MaskedArray to mask out pixels by setting their entry in the mask part of the MaskedArray to False. Operations in EOdal always check for the is_masked_array attribute to handle these arrays correctly. So, it should not happen that data values are set to zero (which is the no-data value of Sentinel-2 defined by ESA by the way). In case it happens, could you please post a code snippet for reproducing the issue?

Second, I think a major issue with using custom fill values is the data type. 'nan' will produce an error when working with integer values, which are widely used for remote sensing data products (e.g., 16bit integers for Sentinel-2). So, the question would be how to handle such "wrong" fill values?

Best,
Lukas

[lukasValentin]

Hi @orianif, is this issue still applicable? If so, can you please post a minimum reproducible example so that I can see what's going on in your case?