Seasons

[kvantricht]

Base functionality added and also tests added. Seasons have been renamed to what they are supposed to become, however the old seasons are still in place. The major entry point at the moment should be worldcereal.seasons.get_processing_dates_for_extent(extent, year, season='tc-annual') which allows to infer processing dates for a specific extent, year and season. The latter is optional and defaults to tc-annual which is supposed to become the year ending at the latest season end (s2) and starting a year before.

Note that for the moment, no AEZs are defined, all seasonality is inferred from pixel-based calendars. This is done by taking the median EOS_DOY of the calendar pixels in the extent.

Now it should be as simple as:

from worldcereal.seasons import get_processing_dates_for_extent
from worldcereal import BoundingBoxExtent   # Should later be imported from gfmap

bounds = (574680, 5621800, 575320, 5622440)
epsg = 32631
year = 2021
extent = BoundingBoxExtent(*bounds, epsg)

start_date, end_date = get_processing_dates_for_extent(extent, year)

[kvantricht]

To further elaborate a bit: at the moment, Presto always expects a full year of data. That's why for now, regardless of season length we make sure that processing dates cover exactly a year.

[jdegerickx]

Nice work! Some comments from my side after quick checks:

• I'm not sure your current doy_from_tiff function correctly accounts for the no data value in the crop calendars? In phase I calendars, the nodata value is zero, whereas it seems in your function it is set to None by default? The new cropcalendars seem to have np.nan as nodata value, I'll ask the Valencia team to switch that to 0 and also switch the data type (it's float now).
• simply taking the median of EOS for a certain spatial extent can be dangerous in case EOS in the area is around end of december/beginning of January. Not sure this is properly accounted for currently.
• the names tc_s1 and tc_s2 should probably be changed because normally we're not mapping temporary crops in those seasons? ct_s1 and ct_s2 (referring to "crop type")?

[kvantricht]

@jdegerickx thanks! Some feedback already:

• I didn't change anything about the nodata handling so if it's wrong, it has always been up till now ... For the moment, I copied (though renamed) the old calendars, so indeed some changes on UV side to at least have 0 as nodata and dtype integer is required.
• About the median, I thought about this and thought that (for now) with median we're fine but you're right, we are not. I will think about this a bit more. Probably making a circular doy function first, taking median and then unfolding back to normal doy could resolve this.
• Not sure what you mean with the season naming. The tc- pattern was added in Phase I to indicate that all crop type products are mapped within the cropland (temporary crops) mask. Why would that no longer be the case?

[jdegerickx]

regarding the last point, ok, I didn't realize "tc" prefix indicated the mask. I'm fine with keeping the names as you proposed them!

[kvantricht]

@jdegerickx I implemented something for the median DOY computer and added some tests to see if it works. Still have to be careful with the function because obviously computing a median date on a very large range also doesn't make particular sense. But for now I think it's fine.

[jdegerickx]

Looks fine to me now, nice work!