Thanks for raising this issue up. Your example is actually very good for illustrating many of possible pitfalls

• ErosionTask: I would still let the user to have full control on how reference map is eroded (if eroded at all). Not performing erosion in patches with few labeled pixels could become problematic as well – i.e. single spurious labels can be of lower quality and not eroding them could increase the noise in labels in sampled training/test samples. Please note that at the moment the erosion can be label-specific – different type or strength of erosion can be applied for example to roads and forest classes.

• PointSamplingTask: your example points to another serious issue. Imagine that the 5 pixels you mentioned above wouldn’t get eroded and in the next step you would sample 2000 pixels. The result of the sampling task would be an array of length 2000 containing only 5 different pixels/points. The 5 pixels would be included multiple time which could potentially introduce problems in the model development stage. Solution to this problems requires changes in the sampling task.

Regards,

Anze

Explanation on ErosionTask makes perfect sense to me, and should be kept that way. The task fulfills precisely was is expected of it.

However, for PointSamplingTask, it is inevitable that some eopatches will have fewer available samples than the stated fixed n_samples, especially with sparsely available training data.
I see two solutions here therefore:

1. Find a way to consolidate the FEATURES_SAMPLED and LULC_SAMPLED with a dynamic n_samples (e.g. n_samples = 2000 if np.count_nonzero(FeatureType.MASK_TIMELESS['LULC']) >= 2000 else np.count_nonzero(FeatureType.MASK_TIMELESS['LULC']) ) . Currently, the way labels_training and features_training are prepared does not allow for a varying length, but I guess finding a solution for this would be relatively trivial.
2. Gap-fill the rest of the FEATURES_SAMPLED and LULC_SAMPLED values with NaNs instead of repeating the same samples over the entire n_samples length. I don’t know the implications of this solution, but I am assuming it could also easily be dealt with before the model development stage.

Interesting stuff in any case, and keep me (and the community) posted about what your intents are to deal with this problem.

Cheers,

William