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
This was discussed at the meeting last week. Currently in our implementation of CPC we use a downsampling based method, where we just take the 30x30m per pixel resolution JRC data, filter per LUC we care about (there's only two), and from that we build a coarsened low resolution raster of 1200x1200m per pixel, by just taking 40x40 pixel square at JRC resolution and summing them up and dividing by the number of pixels used (this allows for the source raster not to be perfectly round to the nearest 40 pixels).
It turns out that in @swinersha's implementation he uses this style of raster for the first two uses of CPC, and then for the final pixel matching he uses a "true" CPC raster, which is where for each pixel at the JRC resolution you make a circle around that pixel of 1200m and then filter by LUC and average. This is more accurate, but more costly to calculate - I guess that's why it's only done at the end, because by this point you've got rid of a lot of data.
However, given it's a one time cost we could pre-calculate, we could in theory do this JRC scale "true" CPC raster once in our pipeline per JRC update. In the meeting on Friday it was agreed that the eventual aim would be to use "true" CPC for all three stages where CPC in needed in the methodology.
Thus there are the following tasks to do:
1: Write some code to generate "true" CPC rasters at JRC scale.
2: Start using those in Find Pairs to match Tom's current implementation.
3: Eventually replace all CPC usage with these new rasters.
The text was updated successfully, but these errors were encountered:
Michael. Thanks for summarising the issue. That sounds correct to me.
The only thing to not is that it would be good to run some sensitivity tests on what size neighbour hood to use. So at some point we might need to compute a few versions using different neighbourhood sizes.
@swinersha@mdales I just wanted to note that an (approximate) gaussian blur would be much quicker to calculate, so we could do that if it would be better. No worries if not, at least we only have to do this once.
Given the process we've been through thus far in testing, I suspect the first step would be to implement something basic and then check It matches Tom's GEE data, assuming we can extract it, and then improve from there.
This was discussed at the meeting last week. Currently in our implementation of CPC we use a downsampling based method, where we just take the 30x30m per pixel resolution JRC data, filter per LUC we care about (there's only two), and from that we build a coarsened low resolution raster of 1200x1200m per pixel, by just taking 40x40 pixel square at JRC resolution and summing them up and dividing by the number of pixels used (this allows for the source raster not to be perfectly round to the nearest 40 pixels).
It turns out that in @swinersha's implementation he uses this style of raster for the first two uses of CPC, and then for the final pixel matching he uses a "true" CPC raster, which is where for each pixel at the JRC resolution you make a circle around that pixel of 1200m and then filter by LUC and average. This is more accurate, but more costly to calculate - I guess that's why it's only done at the end, because by this point you've got rid of a lot of data.
However, given it's a one time cost we could pre-calculate, we could in theory do this JRC scale "true" CPC raster once in our pipeline per JRC update. In the meeting on Friday it was agreed that the eventual aim would be to use "true" CPC for all three stages where CPC in needed in the methodology.
Thus there are the following tasks to do:
1: Write some code to generate "true" CPC rasters at JRC scale.
2: Start using those in Find Pairs to match Tom's current implementation.
3: Eventually replace all CPC usage with these new rasters.
The text was updated successfully, but these errors were encountered: